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

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" &lt;greger(a)teigre.com&gt; 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 &lt;javarockx(a)yahoo.com&gt; 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@sip.mycompany.com;user=phone>;tag=0d5452e4bee210e3 >>> To: "Andrew" >>> <sip:9990010002@sip.mycompany.com;user=phone>;tag=b73c75ac247b63db >>> Call-ID: 0d5bc1fb337cd7eb(a)68.184.40.199 CSeq: 26976 BYE User-Agent: >>> Grandstream BT100 1.0.5.11 Contact: >>> <sip:9990010002@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(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serusers >>> >>