[Serusers] Revisted Error: force_rtp_proxy2: can't extractbodyfrom the message
Greger V. Teigre
greger at teigre.com
Fri Nov 19 08:20:42 CET 2004
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).
>>>>>
>>>>> Regards Paul.
>>>>>
>>>>>
>>>>>
>>>>> --- "Greger V. Teigre" <greger at teigre.com> wrote:
>>>>>
>>>>>> Paul,
>>>>>> I'm not sure if this went on the list? I get digests...
>>>>>>
>>>>>> Thanks for your answer on content-length, I'll try it out. I
>>>>>> went back
>>>>>> to
>>>>>> your original message on ACK and Route. I cannot understand how
>>>>>> ser should
>>>>>> process an ACK with STUN differently from without. If this
>>>>>> assumption is
>>>>>> correct, you would probably have a different execution path in
>>>>>> your ser.cfg
>>>>>> dependent on STUN or not. It could have something to do with
>>>>>> what I wrote
>>>>>> in my last email with regards to the error in Grandstream when
>>>>>> behind symmetric NAT. I use nat_uac_test("19") to catch
>>>>>> Grandstreams with firmware
>>>>>> 10.0.5.16 as the contact and via will be public_ip:portfromstun
>>>>>> while the
>>>>>> request comes from public_ip:portfromsiprequest.
>>>>>>
>>>>>> I'm not confident I can help here as this is at the edge of my
>>>>>> knowledge
>>>>>> of
>>>>>> the topic, but if you want an external look at your config, I'll
>>>>>> be happy
>>>>>> to
>>>>>> have a look at it.
>>>>>> g-)
>>>>>>
>>>>>>
>>>>>> Java Rockx wrote:
>>>>>>> I am using
>>>>>>>
>>>>>>> if(!(search("^Content-Length:\ 0")) {}
>>>>>>>
>>>>>>> in my ser.cfg and it seems to have eliminated all errors.
>>>>>>> Honestly, I
>>>>>>> still have yet to test this with inbound calls from our PSTN
>>>>>>> provider's Sonus equipment.
>>>>>>>
>>>>>>> My bigger issue is why would SER add "Route:" headers correctly
>>>>>>> to ACK messages that flow from my SER proxy to their Sonus box
>>>>>>> only when
>>>>>>> my IP phone is configured to use STUN?
>>>>>>>
>>>>>>> I am using nathelper and rtpproxy and everthing seems to work
>>>>>>> just fine inside or outside of our firewall and no IP phones
>>>>>>> seem to need STUN for SIP messages and RTP to play nice with
>>>>>>> our firewall or client's firewalls as as far as I can tell my
>>>>>>> ser.cfg is good.
>>>>>>>
>>>>>>> So IMHO one of two things is happening;
>>>>>>>
>>>>>>> * I have an error that I'm not aware of in my ser.cfg related to
>>>>>>> NATed versus non-NATed UACs * nathelper/rtpproxy is not usable
>>>>>>> when SER is interacting with other SIP proxies and STUN must be
>>>>>>> used.
>>>>>>>
>>>>>>> Has anyone ever gotten SER to talk with other SIP proxies using
>>>>>>> NATed
>>>>>>> clients?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Paul
>>>>>>>
>>>>>>> --- "Greger V. Teigre" <greger at teigre.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I've been following this thread as I have experienced the same
>>>>>>>> problems myself. When I get incoming calls (both from Cisco
>>>>>>>> IP-PSTN
>>>>>>>> gateway and from other SIP phones) to a Grandstream behind
>>>>>>>> symmetric
>>>>>>>> NAT, the messages you have noted can be seen in the log when
>>>>>>>> hanging
>>>>>>>> up.
>>>>>>>>
>>>>>>>> I was not certain as to the conclusion you ended with. Do you
>>>>>>>> use the filter:
>>>>>>>> if (!(search("^Content-Length:\ 0")) {
>>>>>>>> force_rtp_proxy();
>>>>>>>> };
>>>>>>>>
>>>>>>>> to avoid the errors? I have been thinking about testing on
>>>>>>>> method and not call force on BYE and ACK. Have you tried this?
>>>>>>>>
>>>>>>>> I also saw your question on RFC compliance and the Sonus
>>>>>>>> equipment: In order to make Grandstream phones register
>>>>>>>> properly when using STUN behind symmetric NAT, I had to patch
>>>>>>>> nathelper with the rport != port of received address check.
>>>>>>>> (I use 0.8.14 and I guess you already have the patch with the
>>>>>>>> development version). The reason is
>>>>>>>> that Grandstream attempts to rewrite the address using STUN
>>>>>>>> even though it correctly detects a symmetric NAT. I have
>>>>>>>> seen that this
>>>>>>>> was introduced in a new firmware not long ago (release notes).
>>>>>>>> This
>>>>>>>> pussles me as sources I have seen claims this to be invalid
>>>>>>>> behavior
>>>>>>>> (which seems correct to me).
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Greger
>>>>>>>>
>>>>>>>>
>>>>>>>> Java Rockx wrote:
>>>>>>>>> Hi All.
>>>>>>>>>
>>>>>>>>> I've hacked my ser.cfg but can someone comment on why I would
>>>>>>>>> be recieving a "200 OK" with a
>>>>>>>>>
>>>>>>>>> The change I made to my onreply_route is below. The only
>>>>>>>>> thing I can
>>>>>>>>> see about these messages versus others is that the CSeq says
>>>>>>>>> "CSeq:
>>>>>>>>> {some digits} BYE" with "Content-Length: 0".
>>>>>>>>>
>>>>>>>>> So for these messages I'm just not calling force_rtp_proxy().
>>>>>>>>>
>>>>>>>>> I don't know if this is a symptom of my Grandstream BT100
>>>>>>>>> only of if
>>>>>>>>> other ATAs or IP phones do this.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>> onreply_route[1] {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if (isflagset(2) && status =~ "(183)|2[0-9][0-9]") {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> fix_nated_contact();
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if (!(search("^Content-Length:\ 0")) {
>>>>>>>>> force_rtp_proxy();
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> } else if (nat_uac_test("1")) {
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> fix_nated_contact();
>>>>>>>>> };
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --- Java Rockx <javarockx at yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all.
>>>>>>>>>>
>>>>>>>>>> I've got nathelper and rtpproxy working very well with my
>>>>>>>>>> firewall.
>>>>>>>>>> However I do still recieve these messages in my syslog. I am
>>>>>>>>>> only catching 183 and 2xx errors in my onreply_route so I'm
>>>>>>>>>> very confused how to prevent these errors.
>>>>>>>>>>
>>>>>>>>>> I'm using ser-0.8.99-dev12. Can anyone give me some advise?
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>> NOTE: The SIP message that caused these errors is at the
>>>>>>>>>> bottom of
>>>>>>>>>> this message.
>>>>>>>>>>
>>>>>>>>>> 0(27011) ERROR: extract_body: message body has length zero
>>>>>>>>>> 0(27011) ERROR: force_rtp_proxy2: can't extract body from
>>>>>>>>>> the message 0(27011) ERROR: on_reply processing failed
>>>>>>>>>>
>>>>>>>>>> My onreply_route is here:
>>>>
>>> === message truncated ===
>>>
>>>
>>>
>>>
>>> __________________________________
>>> Do you Yahoo!?
>>> The all-new My Yahoo! - Get yours free!
>>> http://my.yahoo.com
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list