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

Greger V. Teigre greger at teigre.com
Sun Nov 21 14:28:30 CET 2004


Paul,
Thanks for posting your resulting config after so many hours of testing!
I did a diff and can see that you have done several (smaller) changes. But 
what did the trick? (i.e. for Route problem)
g-)

Java Rockx wrote:
> 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 




More information about the sr-users mailing list