[SR-Users] nathelper-module and sdp offer in 200 OK

[Emil Kroymann]

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 at 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 at 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 at 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 at 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 at 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 at lists.sip-router.org
> >> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Emil Kroymann
> > VoIP Services Engineer
> >
> > Email: emil.kroymann at 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 at lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> 
> 
> 



-- 
Emil Kroymann
VoIP Services Engineer

Email: emil.kroymann at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20110210/9e2b67ec/attachment.pgp>