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

Greger V. Teigre greger at teigre.com
Thu Nov 18 18:40:15 CET 2004


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:
>> >>>>
>> >>>> onreply_route[1] {
>> >>>>
>> >>>>
>> >>>>
>> >>>>         if (isflagset(2) && status =~ "(183)|2[0-9][0-9]") {
>> >>>>
>> >>>>
>> >>>>
>> >>>>                 fix_nated_contact();
>> >>>>
>> >>>>
>> >>>>
>> >>>>                 xlog("L_ERR", "%mb");
>> >>>>                 force_rtp_proxy();
>> >>>>
>> >>>>
>> >>>>
>> >>>>         } else if (nat_uac_test("1")) {
>> >>>>
>> >>>>
>> >>>>
>> >>>>                 fix_nated_contact();
>> >>>>         };
>> >>>> }
>> >>>>
>> >>>>
>> >>>>
>> >>>>  0(27011) SIP/2.0 200 OK
>> >>>> Via: SIP/2.0/UDP 67.184.42.101;branch=z9hG4bKe7ac.628388e2.0
>> >>>> Via: SIP/2.0/UDP
>> >>>> 192.168.0.83;rport=5060;received=68.184.42.171;branch=z9hG4bKb4bfc6084f306712
>> >>>> From:
>> >>>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=0d5452e4bee210e3
>> >>>> To: "Andrew"
>> >>>> <sip:9990010002 at sip.mycompany.com;user=phone>;tag=b73c75ac247b63db
>> >>>> Call-ID: 0d5bc1fb337cd7eb at 68.184.40.199 CSeq: 26976 BYE User-Agent:
>> >>>> Grandstream BT100 1.0.5.11 Contact:
>> >>>> <sip:9990010002 at 68.184.40.199;user=phone> Allow:
>> >>>> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
>> >>>> Content-Length: 0
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> __________________________________
>> >>>> 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
>> >>>>
>> >>>
>>
> === 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