[Serusers] Revisted Error: force_rtp_proxy2: can't extractbodyfrom the message

Java Rockx javarockx at yahoo.com
Sat Nov 20 22:05:30 CET 2004


Greger,

I finally got everything working without STUN and without an Outbound Proxy. I an only using
rtpproxy/nathelper.

I've tested these settings with the following SIP Phones/ATAs

Sipura
UTstarcom iAN-02EX
Grandstream ATA486
Grandstream BT100
Cisco ATA186
Cisco 7960G
WorldAccxx ATA
X-Ten Pro
X-Ten Lite

We are very happy with everything now. The only piece of the puzzle that I don't have working yet
is sems/sipums for voicemail - but I'm working on that.

Attached is my complete ser.cfg file that is working. Please note that I'm using ser-0.8.99-dev17
for this rather than ser-0.8.14

If anyone finds problems in this ser.cfg then please let me know - but like I said before, things
seem very stable right now with -dev17.

Regards,
Paul



--- "Greger V. Teigre" <greger at teigre.com> wrote:

> Good to get an authoriative answer on this.  I think I should allocate some
> time to read the RFC thoroughly.
> This leads back to my guess that it could be Paul's outbound proxy setting
> that fixed the problem.  I would think that are some Grandstream people this
> list, but anyway a bug report should be submitted to Grandstream.  This was
> a hard bug to track.  Paul?
> g-)
> 
> Jan Janak wrote:
> > No, ser does not change Record-Route to Route header field, user
> > agents are supposed to do it. SER does only two things:
> >
> > 1) Adds Record-Route header fields with its own IP address (this is
> >   what record_route function does)
> > 2) Removes the topmost Route header field if it contains its own IP
> >   address (according to the IP) and forwards the message to the IP in
> >   the next Route header field if any. If there is no other Route
> >   header field then the Request-URI would be used.
> >
> > If there are some Route header fields missing in ACK then this is a
> > bug in the calling user agent, not SER.
> >
> >  Jan.
> >
> > On 18-11 21:16, Greger V. Teigre wrote:
> >> I believe the changes are done in the rr module, in the loose.c file.
> >> RFC3261 defines this (as mentioned by the Sonus guys).
> >>    I remember vaguely reading something about equivalence between
> >> defining outbund proxy on the client and a Route header, but I'm way
> >> off stable ground here... However, if I remember correctly, it is
> >> probably the outbound proxy and not the stun settings that does the
> >>    trick. I have seen some discussions on loose routing earlier this
> >> fall, maybe a search on loose routing in the archives can turn up
> >> some new approaches?
> >>
> >> I'm afraid I don't have anything more to contribute here. From all I
> >> can see, ser should change the Record-Routes to Route, but doesn't,
> >> and I don't understand why.  I think we need somebody with a more
> >> in-depth understanding of the ser inner workings.
> >> g-)
> >>
> >>
> >> ----- Original Message -----
> >> From: "Java Rockx" <javarockx at yahoo.com>
> >> To: "Greger V. Teigre" <greger at teigre.com>; "ser users"
> >> <serusers at lists.iptel.org> Sent: Thursday, November 18, 2004 08:21 PM
> >> Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't
> >> extract bodyfrom the message
> >>
> >>
> >>> Greger,
> >>>
> >>> Do you have any idea how SER decides to include a "Route:" versus a
> >>> "Record-Route:" header? If so,
> >>> which piece of code in ser would write the second ACK below?
> >>>
> >>> Here is a "200 OK" and two ACKs - The first ACK is good and the
> >>> second ACK is bad because it
> >>> should have a "Route:" header referring to the Sonus box.
> >>>
> >>> 100.99.99.99.99 is my SER proxy
> >>> 100.10.10.10 is the public side of my firewall
> >>> 216.50.50.50 is the ip of the Sonus box
> >>>
> >>> So the ACK from SER to Sonus is incorrect.
> >>>
> >>> Do you think this is worth posing to Jiri, Andrei, and company? All
> >>> I know is that this ACK is bad
> >>> when STUN is not used and it is good when STUN is used. I did
> >>> upgrade my Grandstream, but that
> >>> didn't help, and I've modified my nat_uac_test to use mode==19
> >>> rather than mode==3, but still get
> >>> the same results.
> >>>
> >>> Regards,
> >>> Paul
> >>>
> >>> U 2004/11/18 14:13:08.419098 100.99.99.99:5060 -> 100.10.10.10:5060
> >>> SIP/2.0 200 OK.
> >>> Via: SIP/2.0/UDP
> >>> 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0.
> >>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
> >>> From: "Paul (1002)"
> >>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> >>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
> >>> CSeq: 21752 INVITE.
> >>> Contact: sip:4075551212 at 216.50.50.50:5060.
> >>> Record-Route: <sip:216.50.50.50:5060;lr>.
> >>> Record-Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
> >>> Accept: multipart/mixed, application/sdp, application/isup,
> >>> application/dtmf,
> >>> application/dtmf-relay.
> >>> Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO.
> >>> Supported: timer.
> >>> Content-Disposition: session;handling=required.
> >>> Content-Type: application/sdp.
> >>> Session-Expires: 240;refresher=uas.
> >>> .
> >>> v=0.
> >>> o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76.
> >>> s=SIP Media Capabilities.
> >>> c=IN IP4 100.99.99.99.
> >>> t=0 0.
> >>> m=audio 35552 RTP/AVP 18 101.
> >>> a=rtpmap:18 G729/8000.
> >>> a=rtpmap:101 telephone-event/8000.
> >>> a=fmtp:101 0-15.
> >>> a=sendrecv.
> >>> a=nortpproxy:yes.
> >>>
> >>> #
> >>> U 2004/11/18 14:13:08.428394 100.10.10.10:5060 -> 100.99.99.99:5060
> >>> ACK sip:4075551212 at 216.50.50.50:5060 SIP/2.0.
> >>> Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d.
> >>> Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
> >>> Route: <sip:216.50.50.50:5060;lr>.
> >>> From: "Paul (1002)"
> >>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> >>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
> >>> Contact: <sip:9990010001 at 192.168.0.83;user=phone>.
> >>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
> >>> CSeq: 21752 ACK.
> >>> User-Agent: Grandstream BT100 1.0.5.16.
> >>> Max-Forwards: 70.
> >>> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
> >>> .
> >>>
> >>> #
> >>> U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060
> >>> ACK sip:216.50.50.50:5060;lr SIP/2.0.
> >>> Via: SIP/2.0/UDP
> >>> 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0.
> >>> Via: SIP/2.0/UDP
> >>> 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d.
> >>> From: "Paul (1002)"
> >>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
> >>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
> >>> Contact: <sip:9990010001 at 100.10.10.10:5060;user=phone>.
> >>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
> >>> CSeq: 21752 ACK.
> >>> User-Agent: Grandstream BT100 1.0.5.16.
> >>> Max-Forwards: 16.
> >>> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
> >>> .
> >>>
> >>>
> >>> --- "Greger V. Teigre" <greger at teigre.com> wrote:
> >>>
> >>>> A few comments/questions after having looked at your config file:
> >>>> - You are using 1.0.5.11 firmware on your Grandstream. 1.0.5.16 is
> >>>> the latest and a lot of things have happened since 11. I would
> >>>> suggest you upgrade the firmware before you spend more time on it.
> >>>> - The SIP conversation you sent earlier shows a conversation
> >>>> without using
> >>>> STUN.  In later messages you write about setting outbound and then
> >>>> stun. Have you tried setting outbound, but not stun?  Any
> >>>> difference in Route?
> >>>> - From 1.0.5.7, Grandstream started to send stun-detected ip and
> >>>> port when
> >>>> symmetric NAT was found.  My experience is that if stun is set on
> >>>> such a phone, you will not be able to catch the REGISTER with
> >>>> nat_uac_test("3"), but need to add the "rport different from src"
> >>>> test (16) found in the cvs (and then use ("19")).  If you contrary
> >>>> to what I have seen are able to catch the Grandstream as behind
> >>>> NAT with nat_uac_test("3"), I would love to
> >>>> see the trace of that conversation...
> >>>> - I don't have much experience with proxying, so this is a shot in
> >>>> the dark:
> >>>> It looks like the ACKs get rewritten by ser because the ACK is
> >>>> part of a nat'ed conversation.  Could fix_nated_contact() be doing
> >>>> this?  I haven't had time to check the code yet.  What would
> >>>> happen if you added a search on
> >>>> Route:
> >>>>
> >>>>  if (method=="REGISTER" || (!search("^Record-Route:")) ||
> >>>> (!search("^Route:"))) ) {
> >>>>
> >>>>   fix_nated_contact();
> >>>>
> >>>> The way I read the mesage from the Sonus guys, the ACK with Route
> >>>> in it should not be touched. Or am I wrong?  However, I'm pretty
> >>>> sure that such a
> >>>> exception to fix_nated_contact is not common...
> >>>>
> >>>> Well, my 2c worth...
> >>>> g-)
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Java Rockx" <javarockx at yahoo.com>
> >>>> To: "Greger V. Teigre" <greger at teigre.com>; "ser users"
> >>>> <serusers at lists.iptel.org>
> >>>> Sent: Thursday, November 18, 2004 05:55 PM
> >>>> Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't
> >>>> extract bodyfrom the message
> >>>>
> >>>>
> >>>>> Thanks Greger!
> >>>>>
> >>>>> Yes, I'd love another set of eyes. Attached is my entire ser.cfg
> >>>>> (bogus IPs of course).
> >>>>>
> 
=== message truncated ===


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ser.cfg
Type: application/octet-stream
Size: 10528 bytes
Desc: ser.cfg
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20041120/3f20782d/attachment.obj>


More information about the sr-users mailing list