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(a)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(a)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(a)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: