9 Feb
2011
9 Feb
'11
4:48 p.m.
Hi,
We recently had a problem with the nathelper module and rtpproxy in a
scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer() functions
in appropriate places. The problem is, that the arguments sent to
the rtpproxy, when the ACK with the sdp answer arrives, seems to be not
in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag, from-tag to
rtpproxy. On the ACK, the nathelper module sends callid, from-tag,
to-tag (with different command prefixes, of course, but I cannot
remember them atm). The version of rtpproxy that we are using seems to
expect, that the order of arguments sent on the ACK request is the same
as on the 200 OK.
My question: are there any module parameters, to correct this behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
9 Feb
9 Feb
5:04 p.m.
I will check that and I will get back to you.
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
Hi,
We recently had a problem with the nathelper module and rtpproxy in a
scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer() functions
in appropriate places. The problem is, that the arguments sent to
the rtpproxy, when the ACK with the sdp answer arrives, seems to be not
in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag, from-tag to
rtpproxy. On the ACK, the nathelper module sends callid, from-tag,
to-tag (with different command prefixes, of course, but I cannot
remember them atm). The version of rtpproxy that we are using seems to
expect, that the order of arguments sent on the ACK request is the same
as on the 200 OK.
My question: are there any module parameters, to correct this behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:51 p.m.
The code seems to be correct. The to and from tags are switched for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
Hi,
We recently had a problem with the nathelper module and rtpproxy in a
scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer() functions
in appropriate places. The problem is, that the arguments sent to
the rtpproxy, when the ACK with the sdp answer arrives, seems to be not
in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag, from-tag to
rtpproxy. On the ACK, the nathelper module sends callid, from-tag,
to-tag (with different command prefixes, of course, but I cannot
remember them atm). The version of rtpproxy that we are using seems to
expect, that the order of arguments sent on the ACK request is the same
as on the 200 OK.
My question: are there any module parameters, to correct this behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10 Feb
10 Feb
8:40 a.m.
When I checked the code of the nathelper module that we are using,
it didn't seem to be the case, that to and from tags are switched
for the ACK request. Maybe, something has been changed after the
point we checked out sip-router. When was this code last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
The code seems to be correct. The to and from tags
are switched for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy
functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
Hi,
We recently had a problem with the nathelper module and rtpproxy in
a scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer()
functions in appropriate places. The problem is, that the arguments
sent to the rtpproxy, when the ACK with the sdp answer arrives,
seems to be not in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag, from-tag
to rtpproxy. On the ACK, the nathelper module sends callid,
from-tag, to-tag (with different command prefixes, of course, but I
cannot remember them atm). The version of rtpproxy that we are
using seems to expect, that the order of arguments sent on the ACK
request is the same as on the 200 OK.
My question: are there any module parameters, to correct this
behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
8:46 a.m.
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The ACK/SDP
contains then the rtp_answer.
Works like a charm for me....
Carsten
2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
When I checked the code of the nathelper module that
we are using,
it didn't seem to be the case, that to and from tags are switched
for the ACK request. Maybe, something has been changed after the
point we checked out sip-router. When was this code last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Büro (Verl) +49 5246 801427
Fax +49 40 34927218
mailto:carsten@bock.info
The code seems to be correct. The to and from
tags are switched for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy
functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
We recently had a problem with the nathelper module and rtpproxy in
a scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer()
functions in appropriate places. The problem is, that the arguments
sent to the rtpproxy, when the ACK with the sdp answer arrives,
seems to be not in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag, from-tag
to rtpproxy. On the ACK, the nathelper module sends callid,
from-tag, to-tag (with different command prefixes, of course, but I
cannot remember them atm). The version of rtpproxy that we are
using seems to expect, that the order of arguments sent on the ACK
request is the same as on the 200 OK.
My question: are there any module parameters, to correct this
behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:55 a.m.
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for ACK.
So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock <lists(a)bock.info>fo>:
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The ACK/SDP
contains then the rtp_answer.
Works like a charm for me....
Carsten
2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
When I checked the code of the nathelper module
that we are using,
it didn't seem to be the case, that to and from tags are switched
for the ACK request. Maybe, something has been changed after the
point we checked out sip-router. When was this code last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
The code seems to be correct. The to and from
tags are switched
for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy
functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
We recently had a problem with the nathelper module and rtpproxy
in a scenario where the SDP offer is sent only in the 200 OK. We
use sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer()
functions in appropriate places. The problem is, that the
arguments sent to the rtpproxy, when the ACK with the sdp answer
arrives, seems to be not in the order, that rtpproxy expects.
On the 200 OK, the nathelper module sends callid, to-tag,
from-tag to rtpproxy. On the ACK, the nathelper module sends
callid, from-tag, to-tag (with different command prefixes, of
course, but I cannot remember them atm). The version of rtpproxy
that we are using seems to expect, that the order of arguments
sent on the ACK request is the same as on the 200 OK.
My question: are there any module parameters, to correct this
behaviour?
Regards,
Emil
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:06 p.m.
Add some logs (print the message that you are processing and the rtp
command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for ACK.
So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock <lists(a)bock.info>fo>:
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The ACK/SDP
contains then the rtp_answer.
Works like a charm for me....
Carsten
2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
When I checked the code of the nathelper module
that we are using,
it didn't seem to be the case, that to and from tags are switched
for the ACK request. Maybe, something has been changed after the
point we checked out sip-router. When was this code last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
The code seems to be correct. The to and from
tags are switched
for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy
functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
> Hi,
>
> We recently had a problem with the nathelper module and rtpproxy
> in a scenario where the SDP offer is sent only in the 200 OK. We
> use sip-router 3.1 and rtp-proxy from git master. The sip-router
> configuration uses the rtpproxy_offer() and rtpproxy_answer()
> functions in appropriate places. The problem is, that the
> arguments sent to the rtpproxy, when the ACK with the sdp answer
> arrives, seems to be not in the order, that rtpproxy expects.
>
> On the 200 OK, the nathelper module sends callid, to-tag,
> from-tag to rtpproxy. On the ACK, the nathelper module sends
> callid, from-tag, to-tag (with different command prefixes, of
> course, but I cannot remember them atm). The version of rtpproxy
> that we are using seems to expect, that the order of arguments
> sent on the ACK request is the same as on the 200 OK.
>
> My question: are there any module parameters, to correct this
> behaviour?
>
> Regards,
>
> Emil
> --
> Emil Kroymann
> VoIP Services Engineer
>
> Email: emil.kroymann(a)isaco.de
> Tel: +49-30-203899885
>
> ISACO GmbH
> Kurfürstenstraße 79
> 10787 Berlin
> Germany
>
> Amtsgericht Charlottenburg, HRB 112464B
> Geschäftsführer: Daniel Frommherz
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:58 p.m.
I already added the log statements for late offer and answer and checked
that the messages where present in the ser logs. Also, I checked the
communication between sip-router and rtpproxy with ngrep. For the
200 OK, sip-router sends the 'U' command to rtpproxy and for the ACK
sip-router sends the 'L' command to rtpproxy, but with from- and to-tag
in the other order, as described in the initial mail in this thread. If
there was something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by building
the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From tag\n");
FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0)) {
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0) ||
(msg->first_line.type == SIP_REQUEST && offer == 0)) {
if (to_tag.len == 0) {
FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is the
same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
Add some logs (print the message that you are
processing and the rtp
command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for
ACK. So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock <lists(a)bock.info>fo>:
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The
ACK/SDP contains then the rtp_answer.
Works like a charm for me....
Carsten
2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
When I checked the code of the nathelper module
that we are
using, it didn't seem to be the case, that to and from tags are
switched for the ACK request. Maybe, something has been changed
after the point we checked out sip-router. When was this code
last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> The code seems to be correct. The to and from tags are switched
> for:
> - reply with offer (200ok with first SDP)
> - request with answer (ACK with second SDP)
>
> Are you sure that you are properly invoking offer/answer
> rtpproxy functions?
>
>
> Regards,
> Ovidiu Sas
>
> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
> <emil.kroymann(a)isaco.de> wrote:
> > Hi,
> >
> > We recently had a problem with the nathelper module and
> > rtpproxy in a scenario where the SDP offer is sent only in
> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
> > master. The sip-router configuration uses the
> > rtpproxy_offer() and rtpproxy_answer() functions in
> > appropriate places. The problem is, that the arguments sent
> > to the rtpproxy, when the ACK with the sdp answer arrives,
> > seems to be not in the order, that rtpproxy expects.
> >
> > On the 200 OK, the nathelper module sends callid, to-tag,
> > from-tag to rtpproxy. On the ACK, the nathelper module sends
> > callid, from-tag, to-tag (with different command prefixes, of
> > course, but I cannot remember them atm). The version of
> > rtpproxy that we are using seems to expect, that the order of
> > arguments sent on the ACK request is the same as on the 200
> > OK.
> >
> > My question: are there any module parameters, to correct this
> > behaviour?
> >
> > Regards,
> >
> > Emil
> > --
> > Emil Kroymann
> > VoIP Services Engineer
> >
> > Email: emil.kroymann(a)isaco.de
> > Tel: +49-30-203899885
> >
> > ISACO GmbH
> > Kurfürstenstraße 79
> > 10787 Berlin
> > Germany
> >
> > Amtsgericht Charlottenburg, HRB 112464B
> > Geschäftsführer: Daniel Frommherz
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> > mailing list sr-users(a)lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:11 p.m.
But this is how the code it is!
Can you provide more details about which version of the code are you using?
And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
I already added the log statements for late offer and
answer and checked
that the messages where present in the ser logs. Also, I checked the
communication between sip-router and rtpproxy with ngrep. For the
200 OK, sip-router sends the 'U' command to rtpproxy and for the ACK
sip-router sends the 'L' command to rtpproxy, but with from- and to-tag
in the other order, as described in the initial mail in this thread. If
there was something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by building
the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From
tag\n");
FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0))
{
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0)
|| (msg->first_line.type == SIP_REQUEST && offer == 0)) {
if (to_tag.len == 0) {
FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is the
same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
Add some logs (print the message that you are
processing and the rtp
command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for
ACK. So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock <lists(a)bock.info>fo>:
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The
ACK/SDP contains then the rtp_answer.
Works like a charm for me....
Carsten
2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
> When I checked the code of the nathelper module that we are
> using, it didn't seem to be the case, that to and from tags are
> switched for the ACK request. Maybe, something has been changed
> after the point we checked out sip-router. When was this code
> last changed?
>
> Am Wed, 9 Feb 2011 12:51:29 -0500
> schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
>
>> The code seems to be correct. The to and from tags are switched
>> for:
>> - reply with offer (200ok with first SDP)
>> - request with answer (ACK with second SDP)
>>
>> Are you sure that you are properly invoking offer/answer
>> rtpproxy functions?
>>
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
>> <emil.kroymann(a)isaco.de> wrote:
>> > Hi,
>> >
>> > We recently had a problem with the nathelper module and
>> > rtpproxy in a scenario where the SDP offer is sent only in
>> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
>> > master. The sip-router configuration uses the
>> > rtpproxy_offer() and rtpproxy_answer() functions in
>> > appropriate places. The problem is, that the arguments sent
>> > to the rtpproxy, when the ACK with the sdp answer arrives,
>> > seems to be not in the order, that rtpproxy expects.
>> >
>> > On the 200 OK, the nathelper module sends callid, to-tag,
>> > from-tag to rtpproxy. On the ACK, the nathelper module sends
>> > callid, from-tag, to-tag (with different command prefixes, of
>> > course, but I cannot remember them atm). The version of
>> > rtpproxy that we are using seems to expect, that the order of
>> > arguments sent on the ACK request is the same as on the 200
>> > OK.
>> >
>> > My question: are there any module parameters, to correct this
>> > behaviour?
>> >
>> > Regards,
>> >
>> > Emil
>> > --
>> > Emil Kroymann
>> > VoIP Services Engineer
>> >
>> > Email: emil.kroymann(a)isaco.de
>> > Tel: +49-30-203899885
>> >
>> > ISACO GmbH
>> > Kurfürstenstraße 79
>> > 10787 Berlin
>> > Germany
>> >
>> > Amtsgericht Charlottenburg, HRB 112464B
>> > Geschäftsführer: Daniel Frommherz
>> >
>> >
>> > _______________________________________________
>> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> > mailing list sr-users(a)lists.sip-router.org
>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >
>>
>
>
>
> --
> Emil Kroymann
> VoIP Services Engineer
>
> Email: emil.kroymann(a)isaco.de
> Tel: +49-30-203899885
> Mobile: +49-176-38389303
>
> ISACO GmbH
> Kurfürstenstraße 79
> 10787 Berlin
> Germany
>
> Amtsgericht Charlottenburg, HRB 112464B
> Geschäftsführer: Daniel Frommherz
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
2:23 p.m.
It seems that the s version of nathelper is the one that you are using
(I just checked the code and the bug is present there).
The rtpproxy functionality from the s version of nathelper module will
be removed soon (see the rtpproxy module). For now, please use the
nathelper and rtpproxy modules from modules_k.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:11 AM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
But this is how the code it is!
Can you provide more details about which version of the code are you using?
And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
I already added the log statements for late offer
and answer and checked
that the messages where present in the ser logs. Also, I checked the
communication between sip-router and rtpproxy with ngrep. For the
200 OK, sip-router sends the 'U' command to rtpproxy and for the ACK
sip-router sends the 'L' command to rtpproxy, but with from- and to-tag
in the other order, as described in the initial mail in this thread. If
there was something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by building
the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From
tag\n");
FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0))
{
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY && offer != 0)
|| (msg->first_line.type == SIP_REQUEST && offer == 0)) {
if (to_tag.len == 0) {
FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is the
same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
Add some logs (print the message that you are
processing and the rtp
command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for
ACK. So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock <lists(a)bock.info>fo>:
> Hi,
>
> just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
> SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
> 200 OK instead of the usual "rtp_answer" for the 200 OK. The
> ACK/SDP contains then the rtp_answer.
> Works like a charm for me....
>
> Carsten
>
> 2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
> > When I checked the code of the nathelper module that we are
> > using, it didn't seem to be the case, that to and from tags are
> > switched for the ACK request. Maybe, something has been changed
> > after the point we checked out sip-router. When was this code
> > last changed?
> >
> > Am Wed, 9 Feb 2011 12:51:29 -0500
> > schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> >
> >> The code seems to be correct. The to and from tags are switched
> >> for:
> >> - reply with offer (200ok with first SDP)
> >> - request with answer (ACK with second SDP)
> >>
> >> Are you sure that you are properly invoking offer/answer
> >> rtpproxy functions?
> >>
> >>
> >> Regards,
> >> Ovidiu Sas
> >>
> >> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
> >> <emil.kroymann(a)isaco.de> wrote:
> >> > Hi,
> >> >
> >> > We recently had a problem with the nathelper module and
> >> > rtpproxy in a scenario where the SDP offer is sent only in
> >> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
> >> > master. The sip-router configuration uses the
> >> > rtpproxy_offer() and rtpproxy_answer() functions in
> >> > appropriate places. The problem is, that the arguments sent
> >> > to the rtpproxy, when the ACK with the sdp answer arrives,
> >> > seems to be not in the order, that rtpproxy expects.
> >> >
> >> > On the 200 OK, the nathelper module sends callid, to-tag,
> >> > from-tag to rtpproxy. On the ACK, the nathelper module sends
> >> > callid, from-tag, to-tag (with different command prefixes, of
> >> > course, but I cannot remember them atm). The version of
> >> > rtpproxy that we are using seems to expect, that the order of
> >> > arguments sent on the ACK request is the same as on the 200
> >> > OK.
> >> >
> >> > My question: are there any module parameters, to correct this
> >> > behaviour?
> >> >
> >> > Regards,
> >> >
> >> > Emil
> >> > --
> >> > Emil Kroymann
> >> > VoIP Services Engineer
> >> >
> >> > Email: emil.kroymann(a)isaco.de
> >> > Tel: +49-30-203899885
> >> >
> >> > ISACO GmbH
> >> > Kurfürstenstraße 79
> >> > 10787 Berlin
> >> > Germany
> >> >
> >> > Amtsgericht Charlottenburg, HRB 112464B
> >> > Geschäftsführer: Daniel Frommherz
> >> >
> >> >
> >> > _______________________________________________
> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> >> > mailing list sr-users(a)lists.sip-router.org
> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Emil Kroymann
> > VoIP Services Engineer
> >
> > Email: emil.kroymann(a)isaco.de
> > Tel: +49-30-203899885
> > Mobile: +49-176-38389303
> >
> > ISACO GmbH
> > Kurfürstenstraße 79
> > 10787 Berlin
> > Germany
> >
> > Amtsgericht Charlottenburg, HRB 112464B
> > Geschäftsführer: Daniel Frommherz
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> > mailing list sr-users(a)lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
>
>
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
2:36 p.m.
Am Thu, 10 Feb 2011 09:23:51 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
It seems that the s version of nathelper is the one
that you are using
(I just checked the code and the bug is present there).
The rtpproxy functionality from the s version of nathelper module will
be removed soon (see the rtpproxy module). For now, please use the
nathelper and rtpproxy modules from modules_k.
Alright, I didn't look at the rtpproxy module, yet, but I did wonder,
why there was an rtpproxy module, when the functionality was already
handled by nathelper :-)
Thanks,
Emil
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:11 AM, Ovidiu Sas <osas(a)voipembedded.com>
wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
But this is how the code it is!
Can you provide more details about which version of the code are
you using? And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
I already added the log statements for late offer
and answer and
checked that the messages where present in the ser logs. Also, I
checked the communication between sip-router and rtpproxy with
ngrep. For the 200 OK, sip-router sends the 'U' command to
rtpproxy and for the ACK sip-router sends the 'L' command to
rtpproxy, but with from- and to-tag in the other order, as
described in the initial mail in this thread. If there was
something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by
building the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From
tag\n"); FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0)) {
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0) || (msg->first_line.type == SIP_REQUEST && offer ==
0)) { if (to_tag.len == 0) { FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is
the same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
Add some logs (print the message that you are
processing and the
rtp command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
> Hi,
>
> yeah, the script does call rtp_offer for 200 OK and rtp_answer
> for ACK. So, no problem there.
>
> Emil
>
> Am Thu, 10 Feb 2011 09:46:04 +0100
> schrieb Carsten Bock <lists(a)bock.info>fo>:
>
>> Hi,
>>
>> just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK,
>> the SDP-Offer is in the 200 OK, so you need to call
>> "rtp_offer" for the 200 OK instead of the usual
"rtp_answer"
>> for the 200 OK. The ACK/SDP contains then the rtp_answer.
>> Works like a charm for me....
>>
>> Carsten
>>
>> 2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
>> > When I checked the code of the nathelper module that we are
>> > using, it didn't seem to be the case, that to and from tags
>> > are switched for the ACK request. Maybe, something has been
>> > changed after the point we checked out sip-router. When was
>> > this code last changed?
>> >
>> > Am Wed, 9 Feb 2011 12:51:29 -0500
>> > schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
>> >
>> >> The code seems to be correct. The to and from tags are
>> >> switched for:
>> >> - reply with offer (200ok with first SDP)
>> >> - request with answer (ACK with second SDP)
>> >>
>> >> Are you sure that you are properly invoking offer/answer
>> >> rtpproxy functions?
>> >>
>> >>
>> >> Regards,
>> >> Ovidiu Sas
>> >>
>> >> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
>> >> <emil.kroymann(a)isaco.de> wrote:
>> >> > Hi,
>> >> >
>> >> > We recently had a problem with the nathelper module and
>> >> > rtpproxy in a scenario where the SDP offer is sent only in
>> >> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
>> >> > master. The sip-router configuration uses the
>> >> > rtpproxy_offer() and rtpproxy_answer() functions in
>> >> > appropriate places. The problem is, that the arguments
>> >> > sent to the rtpproxy, when the ACK with the sdp answer
>> >> > arrives, seems to be not in the order, that rtpproxy
>> >> > expects.
>> >> >
>> >> > On the 200 OK, the nathelper module sends callid, to-tag,
>> >> > from-tag to rtpproxy. On the ACK, the nathelper module
>> >> > sends callid, from-tag, to-tag (with different command
>> >> > prefixes, of course, but I cannot remember them atm). The
>> >> > version of rtpproxy that we are using seems to expect,
>> >> > that the order of arguments sent on the ACK request is
>> >> > the same as on the 200 OK.
>> >> >
>> >> > My question: are there any module parameters, to correct
>> >> > this behaviour?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Emil
>> >> > --
>> >> > Emil Kroymann
>> >> > VoIP Services Engineer
>> >> >
>> >> > Email: emil.kroymann(a)isaco.de
>> >> > Tel: +49-30-203899885
>> >> >
>> >> > ISACO GmbH
>> >> > Kurfürstenstraße 79
>> >> > 10787 Berlin
>> >> > Germany
>> >> >
>> >> > Amtsgericht Charlottenburg, HRB 112464B
>> >> > Geschäftsführer: Daniel Frommherz
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> >> > mailing list sr-users(a)lists.sip-router.org
>> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Emil Kroymann
>> > VoIP Services Engineer
>> >
>> > Email: emil.kroymann(a)isaco.de
>> > Tel: +49-30-203899885
>> > Mobile: +49-176-38389303
>> >
>> > ISACO GmbH
>> > Kurfürstenstraße 79
>> > 10787 Berlin
>> > Germany
>> >
>> > Amtsgericht Charlottenburg, HRB 112464B
>> > Geschäftsführer: Daniel Frommherz
>> >
>> >
>> > _______________________________________________
>> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>> > mailing list sr-users(a)lists.sip-router.org
>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> >
>> >
>>
>>
>>
>
>
>
> --
> Emil Kroymann
> VoIP Services Engineer
>
> Email: emil.kroymann(a)isaco.de
> Tel: +49-30-203899885
> Mobile: +49-176-38389303
>
> ISACO GmbH
> Kurfürstenstraße 79
> 10787 Berlin
> Germany
>
> Amtsgericht Charlottenburg, HRB 112464B
> Geschäftsführer: Daniel Frommherz
>
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
2:39 p.m.
The k version of nathelper was split in two:
- rtpproxy (dealing with the rtpproxy protocol);
- nathelper (dealing with NAT).
The same will be applied to s version.
In trunk, the rtpproxy module was moved to modules (it is a generic one now).
In 3.1.x, the rtpproxy module is in modules_k.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:36 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
Am Thu, 10 Feb 2011 09:23:51 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
It seems that the s version of nathelper is the
one that you are using
(I just checked the code and the bug is present there).
The rtpproxy functionality from the s version of nathelper module will
be removed soon (see the rtpproxy module). For now, please use the
nathelper and rtpproxy modules from modules_k.
Alright, I didn't look at the rtpproxy module, yet, but I did wonder,
why there was an rtpproxy module, when the functionality was already
handled by nathelper :-)
Thanks,
Emil
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:11 AM, Ovidiu Sas <osas(a)voipembedded.com>
wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
But this is how the code it is!
Can you provide more details about which version of the code are
you using? And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
I already added the log statements for late offer
and answer and
checked that the messages where present in the ser logs. Also, I
checked the communication between sip-router and rtpproxy with
ngrep. For the 200 OK, sip-router sends the 'U' command to
rtpproxy and for the ACK sip-router sends the 'L' command to
rtpproxy, but with from- and to-tag in the other order, as
described in the initial mail in this thread. If there was
something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by
building the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From
tag\n"); FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0)) {
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0) || (msg->first_line.type == SIP_REQUEST && offer ==
0)) { if (to_tag.len == 0) { FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is
the same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> Add some logs (print the message that you are processing and the
> rtp command that you are issuing).
> That should help you in troubleshooting your scenario.
>
> Regards,
> Ovidiu Sas
>
> On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
> <emil.kroymann(a)isaco.de> wrote:
> > Hi,
> >
> > yeah, the script does call rtp_offer for 200 OK and rtp_answer
> > for ACK. So, no problem there.
> >
> > Emil
> >
> > Am Thu, 10 Feb 2011 09:46:04 +0100
> > schrieb Carsten Bock <lists(a)bock.info>fo>:
> >
> >> Hi,
> >>
> >> just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK,
> >> the SDP-Offer is in the 200 OK, so you need to call
> >> "rtp_offer" for the 200 OK instead of the usual
"rtp_answer"
> >> for the 200 OK. The ACK/SDP contains then the rtp_answer.
> >> Works like a charm for me....
> >>
> >> Carsten
> >>
> >> 2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
> >> > When I checked the code of the nathelper module that we are
> >> > using, it didn't seem to be the case, that to and from tags
> >> > are switched for the ACK request. Maybe, something has been
> >> > changed after the point we checked out sip-router. When was
> >> > this code last changed?
> >> >
> >> > Am Wed, 9 Feb 2011 12:51:29 -0500
> >> > schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> >> >
> >> >> The code seems to be correct. The to and from tags are
> >> >> switched for:
> >> >> - reply with offer (200ok with first SDP)
> >> >> - request with answer (ACK with second SDP)
> >> >>
> >> >> Are you sure that you are properly invoking offer/answer
> >> >> rtpproxy functions?
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ovidiu Sas
> >> >>
> >> >> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
> >> >> <emil.kroymann(a)isaco.de> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We recently had a problem with the nathelper module and
> >> >> > rtpproxy in a scenario where the SDP offer is sent only in
> >> >> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
> >> >> > master. The sip-router configuration uses the
> >> >> > rtpproxy_offer() and rtpproxy_answer() functions in
> >> >> > appropriate places. The problem is, that the arguments
> >> >> > sent to the rtpproxy, when the ACK with the sdp answer
> >> >> > arrives, seems to be not in the order, that rtpproxy
> >> >> > expects.
> >> >> >
> >> >> > On the 200 OK, the nathelper module sends callid, to-tag,
> >> >> > from-tag to rtpproxy. On the ACK, the nathelper module
> >> >> > sends callid, from-tag, to-tag (with different command
> >> >> > prefixes, of course, but I cannot remember them atm). The
> >> >> > version of rtpproxy that we are using seems to expect,
> >> >> > that the order of arguments sent on the ACK request is
> >> >> > the same as on the 200 OK.
> >> >> >
> >> >> > My question: are there any module parameters, to correct
> >> >> > this behaviour?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Emil
> >> >> > --
> >> >> > Emil Kroymann
> >> >> > VoIP Services Engineer
> >> >> >
> >> >> > Email: emil.kroymann(a)isaco.de
> >> >> > Tel: +49-30-203899885
> >> >> >
> >> >> > ISACO GmbH
> >> >> > Kurfürstenstraße 79
> >> >> > 10787 Berlin
> >> >> > Germany
> >> >> >
> >> >> > Amtsgericht Charlottenburg, HRB 112464B
> >> >> > Geschäftsführer: Daniel Frommherz
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> >> >> > mailing list sr-users(a)lists.sip-router.org
> >> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Emil Kroymann
> >> > VoIP Services Engineer
> >> >
> >> > Email: emil.kroymann(a)isaco.de
> >> > Tel: +49-30-203899885
> >> > Mobile: +49-176-38389303
> >> >
> >> > ISACO GmbH
> >> > Kurfürstenstraße 79
> >> > 10787 Berlin
> >> > Germany
> >> >
> >> > Amtsgericht Charlottenburg, HRB 112464B
> >> > Geschäftsführer: Daniel Frommherz
> >> >
> >> >
> >> > _______________________________________________
> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> >> > mailing list sr-users(a)lists.sip-router.org
> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> > --
> > Emil Kroymann
> > VoIP Services Engineer
> >
> > Email: emil.kroymann(a)isaco.de
> > Tel: +49-30-203899885
> > Mobile: +49-176-38389303
> >
> > ISACO GmbH
> > Kurfürstenstraße 79
> > 10787 Berlin
> > Germany
> >
> > Amtsgericht Charlottenburg, HRB 112464B
> > Geschäftsführer: Daniel Frommherz
> >
> >
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
3:58 p.m.
Please test the latest trunk version. I removed the rtpproxy
functionality from nathelper s version.
You can safely use now nathelper from s with rtpproxy from generic.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:36 AM, Emil Kroymann <emil.kroymann(a)isaco.de> wrote:
Am Thu, 10 Feb 2011 09:23:51 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
It seems that the s version of nathelper is the
one that you are using
(I just checked the code and the bug is present there).
The rtpproxy functionality from the s version of nathelper module will
be removed soon (see the rtpproxy module). For now, please use the
nathelper and rtpproxy modules from modules_k.
Alright, I didn't look at the rtpproxy module, yet, but I did wonder,
why there was an rtpproxy module, when the functionality was already
handled by nathelper :-)
Thanks,
Emil
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:11 AM, Ovidiu Sas <osas(a)voipembedded.com>
wrote:
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
But this is how the code it is!
Can you provide more details about which version of the code are
you using? And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann
<emil.kroymann(a)isaco.de> wrote:
I already added the log statements for late offer
and answer and
checked that the messages where present in the ser logs. Also, I
checked the communication between sip-router and rtpproxy with
ngrep. For the 200 OK, sip-router sends the 'U' command to
rtpproxy and for the ACK sip-router sends the 'L' command to
rtpproxy, but with from- and to-tag in the other order, as
described in the initial mail in this thread. If there was
something wrong with the calls to rtpproxy_offer() and
rtpproxy_answer() in the sip-router script, the sent command codes
should be different, right?
Also, I could fix the problem in our development environment by
building the nathelper module with the following patch applied:
--- a/modules_s/nathelper/nathelper.c
+++ b/modules_s/nathelper/nathelper.c
@@ -2140,7 +2140,7 @@
LOG(L_ERR, "ERROR: force_rtp_proxy2: can't get From
tag\n"); FORCE_RTP_PROXY_RET (-1);
}
- if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0)) {
+ if (flookup != 0 || (msg->first_line.type == SIP_REPLY &&
offer != 0) || (msg->first_line.type == SIP_REQUEST && offer ==
0)) { if (to_tag.len == 0) { FORCE_RTP_PROXY_RET (-1);
}
With this patch applied the order of arguments send to rtpproxy is
the same for 200 OK and for ACK.
Regards,
Emil
Am Thu, 10 Feb 2011 08:06:43 -0500
schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> Add some logs (print the message that you are processing and the
> rtp command that you are issuing).
> That should help you in troubleshooting your scenario.
>
> Regards,
> Ovidiu Sas
>
> On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann
> <emil.kroymann(a)isaco.de> wrote:
> > Hi,
> >
> > yeah, the script does call rtp_offer for 200 OK and rtp_answer
> > for ACK. So, no problem there.
> >
> > Emil
> >
> > Am Thu, 10 Feb 2011 09:46:04 +0100
> > schrieb Carsten Bock <lists(a)bock.info>fo>:
> >
> >> Hi,
> >>
> >> just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK,
> >> the SDP-Offer is in the 200 OK, so you need to call
> >> "rtp_offer" for the 200 OK instead of the usual
"rtp_answer"
> >> for the 200 OK. The ACK/SDP contains then the rtp_answer.
> >> Works like a charm for me....
> >>
> >> Carsten
> >>
> >> 2011/2/10 Emil Kroymann <emil.kroymann(a)isaco.de>de>:
> >> > When I checked the code of the nathelper module that we are
> >> > using, it didn't seem to be the case, that to and from tags
> >> > are switched for the ACK request. Maybe, something has been
> >> > changed after the point we checked out sip-router. When was
> >> > this code last changed?
> >> >
> >> > Am Wed, 9 Feb 2011 12:51:29 -0500
> >> > schrieb Ovidiu Sas <osas(a)voipembedded.com>om>:
> >> >
> >> >> The code seems to be correct. The to and from tags are
> >> >> switched for:
> >> >> - reply with offer (200ok with first SDP)
> >> >> - request with answer (ACK with second SDP)
> >> >>
> >> >> Are you sure that you are properly invoking offer/answer
> >> >> rtpproxy functions?
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ovidiu Sas
> >> >>
> >> >> On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann
> >> >> <emil.kroymann(a)isaco.de> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > We recently had a problem with the nathelper module and
> >> >> > rtpproxy in a scenario where the SDP offer is sent only in
> >> >> > the 200 OK. We use sip-router 3.1 and rtp-proxy from git
> >> >> > master. The sip-router configuration uses the
> >> >> > rtpproxy_offer() and rtpproxy_answer() functions in
> >> >> > appropriate places. The problem is, that the arguments
> >> >> > sent to the rtpproxy, when the ACK with the sdp answer
> >> >> > arrives, seems to be not in the order, that rtpproxy
> >> >> > expects.
> >> >> >
> >> >> > On the 200 OK, the nathelper module sends callid, to-tag,
> >> >> > from-tag to rtpproxy. On the ACK, the nathelper module
> >> >> > sends callid, from-tag, to-tag (with different command
> >> >> > prefixes, of course, but I cannot remember them atm). The
> >> >> > version of rtpproxy that we are using seems to expect,
> >> >> > that the order of arguments sent on the ACK request is
> >> >> > the same as on the 200 OK.
> >> >> >
> >> >> > My question: are there any module parameters, to correct
> >> >> > this behaviour?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Emil
> >> >> > --
> >> >> > Emil Kroymann
> >> >> > VoIP Services Engineer
> >> >> >
> >> >> > Email: emil.kroymann(a)isaco.de
> >> >> > Tel: +49-30-203899885
> >> >> >
> >> >> > ISACO GmbH
> >> >> > Kurfürstenstraße 79
> >> >> > 10787 Berlin
> >> >> > Germany
> >> >> >
> >> >> > Amtsgericht Charlottenburg, HRB 112464B
> >> >> > Geschäftsführer: Daniel Frommherz
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> >> >> > mailing list sr-users(a)lists.sip-router.org
> >> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Emil Kroymann
> >> > VoIP Services Engineer
> >> >
> >> > Email: emil.kroymann(a)isaco.de
> >> > Tel: +49-30-203899885
> >> > Mobile: +49-176-38389303
> >> >
> >> > ISACO GmbH
> >> > Kurfürstenstraße 79
> >> > 10787 Berlin
> >> > Germany
> >> >
> >> > Amtsgericht Charlottenburg, HRB 112464B
> >> > Geschäftsführer: Daniel Frommherz
> >> >
> >> >
> >> > _______________________________________________
> >> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> >> > mailing list sr-users(a)lists.sip-router.org
> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> > --
> > Emil Kroymann
> > VoIP Services Engineer
> >
> > Email: emil.kroymann(a)isaco.de
> > Tel: +49-30-203899885
> > Mobile: +49-176-38389303
> >
> > ISACO GmbH
> > Kurfürstenstraße 79
> > 10787 Berlin
> > Germany
> >
> > Amtsgericht Charlottenburg, HRB 112464B
> > Geschäftsführer: Daniel Frommherz
> >
> >
>
--
Emil Kroymann
VoIP Services Engineer
Email: emil.kroymann(a)isaco.de
Tel: +49-30-203899885
Mobile: +49-176-38389303
ISACO GmbH
Kurfürstenstraße 79
10787 Berlin
Germany
Amtsgericht Charlottenburg, HRB 112464B
Geschäftsführer: Daniel Frommherz
4905
days inactive
4906
days old
12 comments
3 participants
participants (3)
-
Carsten Bock -
Emil Kroymann -
Ovidiu Sas