[Serusers] Revisted Error: force_rtp_proxy2: can't extract bodyfrom the message
Java Rockx
javarockx at yahoo.com
Thu Nov 18 17:55:44 CET 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ser.cfg
Type: application/octet-stream
Size: 9257 bytes
Desc: ser.cfg
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20041118/2002ae33/attachment.obj>
More information about the sr-users
mailing list