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
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@voipembedded.com:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@isaco.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@voipembedded.com:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@bock.info:
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@isaco.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@voipembedded.com:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@bock.info:
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@isaco.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@voipembedded.com:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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
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@voipembedded.com:
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@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@bock.info:
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@isaco.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@voipembedded.com:
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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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@voipembedded.com:
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@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@bock.info:
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@isaco.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@voipembedded.com:
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@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@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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
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@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@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@voipembedded.com:
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@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@bock.info:
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@isaco.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@voipembedded.com:
> 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@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@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@lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > >
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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
Am Thu, 10 Feb 2011 09:23:51 -0500 schrieb Ovidiu Sas osas@voipembedded.com:
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@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@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@voipembedded.com:
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@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@bock.info:
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@isaco.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@voipembedded.com: > >> 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@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@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@lists.sip-router.org >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> > >> > >> > > > > -- > Emil Kroymann > VoIP Services Engineer > > Email: emil.kroymann@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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
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@isaco.de wrote:
Am Thu, 10 Feb 2011 09:23:51 -0500 schrieb Ovidiu Sas osas@voipembedded.com:
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@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@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@voipembedded.com:
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@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@bock.info:
> 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@isaco.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@voipembedded.com: > > > >> 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@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@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@lists.sip-router.org > >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >> > > >> > > >> > > > > > > > > -- > > Emil Kroymann > > VoIP Services Engineer > > > > Email: emil.kroymann@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@lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > > >
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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@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
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@isaco.de wrote:
Am Thu, 10 Feb 2011 09:23:51 -0500 schrieb Ovidiu Sas osas@voipembedded.com:
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@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@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@voipembedded.com:
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@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@bock.info:
> 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@isaco.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@voipembedded.com: > > > >> 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@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@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@lists.sip-router.org > >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >> > > >> > > >> > > > > > > > > -- > > Emil Kroymann > > VoIP Services Engineer > > > > Email: emil.kroymann@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@lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > > > >
-- Emil Kroymann VoIP Services Engineer
Email: emil.kroymann@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@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@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
-
Carsten Bock -
Emil Kroymann -
Ovidiu Sas