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

Jan Janak jan at iptel.org
Thu Nov 18 22:44:14 CET 2004


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