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

18 Nov 2004

      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@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@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@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@sip.mycompany.com;user=phone;tag=0d5452e4bee210e3
To: "Andrew"
sip:9990010002@sip.mycompany.com;user=phone;tag=b73c75ac247b63db
Call-ID: 0d5bc1fb337cd7eb@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@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

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