[Serusers] Revisted Error: force_rtp_proxy2: can't extract bodyfrom the message
Greger V. Teigre
greger at teigre.com
Thu Nov 18 21:16:00 CET 2004
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
>
>
>
>
More information about the sr-users
mailing list