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

Greger V. Teigre greger at teigre.com
Mon Nov 22 16:46:23 CET 2004


A small follow-up comment to your config file.  You have the following in 
onreply_route in the config file you just sent:
 if (isflagset(2) && status =~ "(180)|(183)|2[0-9][0-9]") {
  if (!search("^Content-Length:\ 0")) {
   force_rtp_proxy();
  };
 };
 if (nat_uac_test("1")) {
  fix_nated_contact();
 };

Andrei pointed out that you should not do fix_nated_contact() within the 
first if-clause.  To my surprise, I found that one of my config files had 
exactly the same error!  After searching a bit, I found the source: The 
example file in the repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/etc/nathelper.cfg?rev=1.1.2.1&content-type=text/vnd.viewcvs-markup

I think many people use that config as a starting point. If it's wrong, 
maybe it should be corrected?!

Also, in that config you find that the nat_uac_test() has 'else if' in front 
of it, you also had it in your previous file.  Any reason you removed the 
else?

g-)

Java Rockx wrote:
> Greger,
>
> I believe the small change to the onfailure_route[] was the thing
> that made the difference. Andrei pointed out a small error to me
> where I was calling fix_nated_contact() for more messages than I
> should have. (THANKS ANDREI!!!)
>
> The other thing that made a **substantial** improvement was the fact
> that our PSTN gateway provider that uses Sonus equipment as added as
> an "alias" at the top of the ser.cfg. This caused ser to not include
> "Route:" headers on ACKs and this was causing the Sonus equipment to
> drop calls after two minutes.
>
> It's funny how such small changes to ser.cfg can have dramatic
> effects.
>
> I'd love to see a complete book published on ser. I'm sure, with the
> help of the maintainers and serusers participants this could become a
> reality. I mean this is the best damned SIP router I know of.
> Commercial solutions such as Sonus are not really a "solution"
> because they run as much as US$2 million per box and most small
> companies can't afford "one". And even if you could afford =>one<=
> you may not be able to afford others for scaling your VoIP platform -
> so whats the point of attempting VoIP if you can't scale?
>
> Our solution is modeled after the Google network whereby:
>
>   unlimited horizontal scalablity == unlimited cps (calls per second)
>
> And this equates to:
>
>   successful VoIP Company == retired employee
>
> If we can indeed do this for our implementation and do it on low end
> x86 or Opteron boxes (or blade servers), then the sky is the limit.
> Our engineer whom we acquired from RedHat a few months ago already
> has a full TCP/IP and UDP socket patch working so we can seperate ser
> and serweb and scale them independently of each other (over a VPN)
> since we don't need ser's existing FIFO.
>
> SEMS is a whole other beast. We are now working on this using the ivr
> module with sipums for a carrier-grade voicemail solution. Early
> indications is that we still have plenty to do in order to get
> 99.999% reliablity with sems. Our goal is to not have sems run on the
> same box as ser as we already know this is bad. Voicemail and SIP
> proxy cannot be the same box if you expect to be a big VoIP provider,
> IMHO.
>
> So our high-level VoIP platform uses the following as independent
> server farms:
>
> MySQL 4.1.7 (farm 1)
> ser-0.8.99-dev17 (farm 2)
> serweb on Apache2 farm 3)
> sems/ivr/sipums (farm 4, still a work in progress)
> Third party PSTN gateway *** see comment below
>
> All servers use Whitebox Linux Respin 1 and our network
> implementation allows us to completely administer all servers at any
> remote co-lo site --- even down to remote installation of the
> operating system. This includes make a change to the master ser.cfg
> and having it replicate to all ser proxies.
>
> Monitoring is a big part of this network architecture and we've only
> got basic monitoring right now, so this will become a focus of our
> efforts soon.
>
> We also use third parties for providing PSTN access. IMHO, PSTN
> gateways are much more trouble than their worth. We'd rather rely on
> multiple third parties for this than to try and do it ourselves. The
> cost of DSP boards is expensive, especially if you wanted to handle
> say 50,000 concurrent callers. For this very reason we use companies
> such as Level 3 and Global Crossing and all we have to do is simply
> monitor their QoS and route PSTN callers to other PSTN gateways as
> needed. And this is all at the network level, so ser is totally
> oblivious to this.
>
> Another thing I've love to see is a database whereby VoIP service
> providers can lookup 10-digit DIDs in a common database (much like a
> root DNS server) and determine if a callee is a VoIP user and route
> the SIP call directly from our SIP proxy to their SIP proxy rather
> than making a SIP->PSTN->SIP call. We have the Chairman of the IPCC
> deeply invovled in our company and he could get the ball rolling on
> this, but we don't want to get distracted right now.
>
> Anyhow, I've rambled long enough.
>
> Regards,
> Paul Hazlett
>
>
>
> We'll publish our
>
> --- "Greger V. Teigre" <greger at teigre.com> wrote:
>
>> Paul,
>> Thanks for posting your resulting config after so many hours of
>> testing! I did a diff and can see that you have done several
>> (smaller) changes. But what did the trick? (i.e. for Route problem)
>> g-)
>>
>> Java Rockx wrote:
>>> Greger,
>>>
>>> I finally got everything working without STUN and without an
>>> Outbound Proxy. I an only using rtpproxy/nathelper.
>>>
>>> I've tested these settings with the following SIP Phones/ATAs
>>>
>>> Sipura
>>> UTstarcom iAN-02EX
>>> Grandstream ATA486
>>> Grandstream BT100
>>> Cisco ATA186
>>> Cisco 7960G
>>> WorldAccxx ATA
>>> X-Ten Pro
>>> X-Ten Lite
>>>
>>> We are very happy with everything now. The only piece of the puzzle
>>> that I don't have working yet is sems/sipums for voicemail - but I'm
>>> working on that.
>>>
>>> Attached is my complete ser.cfg file that is working. Please note
>>> that I'm using ser-0.8.99-dev17 for this rather than ser-0.8.14
>>>
>>> If anyone finds problems in this ser.cfg then please let me know -
>>> but like I said before, things seem very stable right now with
>>> -dev17.
>>>
>>> Regards,
>>> Paul
>>>
>>>
>>>
>>> --- "Greger V. Teigre" <greger at teigre.com> wrote:
>>>
>>>> Good to get an authoriative answer on this.  I think I should
>>>> allocate some time to read the RFC thoroughly.
>>>> This leads back to my guess that it could be Paul's outbound proxy
>>>> setting that fixed the problem.  I would think that are some
>>>> Grandstream people this list, but anyway a bug report should be
>>>> submitted to Grandstream.  This was a hard bug to track.  Paul?
>>>> g-)
>>>>
>>>> Jan Janak wrote:
>>>>> No, ser does not change Record-Route to Route header field, user
>>>>> agents are supposed to do it. SER does only two things:
>>>>>
>>>>> 1) Adds Record-Route header fields with its own IP address (this
>>>>>   is what record_route function does)
>>>>> 2) Removes the topmost Route header field if it contains its own
>>>>>   IP address (according to the IP) and forwards the message to
>>>>>   the IP in the next Route header field if any. If there is no
>>>>>   other Route header field then the Request-URI would be used.
>>>>>
>>>>> If there are some Route header fields missing in ACK then this is
>>>>> a bug in the calling user agent, not SER.
>>>>>
>>>>>  Jan.
>>>>>
>>>>> On 18-11 21:16, Greger V. Teigre wrote:
>>>>>> I believe the changes are done in the rr module, in the loose.c
>>>>>> file. RFC3261 defines this (as mentioned by the Sonus guys).
>>>>>>    I remember vaguely reading something about equivalence between
>>>>>> defining outbund proxy on the client and a Route header, but I'm
>>>>>> way off stable ground here... However, if I remember correctly,
>>>>>> it is probably the outbound proxy and not the stun settings that
>>>>>>    does the trick. I have seen some discussions on loose routing
>>>>>> earlier this fall, maybe a search on loose routing in the
>>>>>> archives can turn up some new approaches?
>>>>>>
>>>>>> I'm afraid I don't have anything more to contribute here. From
>>>>>> all I can see, ser should change the Record-Routes to Route, but
>>>>>> doesn't, and I don't understand why.  I think we need somebody
>>>>>> with a more in-depth understanding of the ser inner workings.
>>>>>> 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 08:21 PM
>>>>>> Subject: Re: [Serusers] Revisted Error: force_rtp_proxy2: can't
>>>>>> extract bodyfrom the message
>>>>>>
>>>>>>
>>>>>>> Greger,
>>>>>>>
>>>>>>> Do you have any idea how SER decides to include a "Route:"
>>>>>>> versus a "Record-Route:" header? If so,
>>>>>>> which piece of code in ser would write the second ACK below?
>>>>>>>
>>>>>>> Here is a "200 OK" and two ACKs - The first ACK is good and the
>>>>>>> second ACK is bad because it
>>>>>>> should have a "Route:" header referring to the Sonus box.
>>>>>>>
>>>>>>> 100.99.99.99.99 is my SER proxy
>>>>>>> 100.10.10.10 is the public side of my firewall
>>>>>>> 216.50.50.50 is the ip of the Sonus box
>>>>>>>
>>>>>>> So the ACK from SER to Sonus is incorrect.
>>>>>>>
>>>>>>> Do you think this is worth posing to Jiri, Andrei, and company?
>>>>>>> All I know is that this ACK is bad
>>>>>>> when STUN is not used and it is good when STUN is used. I did
>>>>>>> upgrade my Grandstream, but that
>>>>>>> didn't help, and I've modified my nat_uac_test to use mode==19
>>>>>>> rather than mode==3, but still get
>>>>>>> the same results.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Paul
>>>>>>>
>>>>>>> U 2004/11/18 14:13:08.419098 100.99.99.99:5060 ->
>>>>>>> 100.10.10.10:5060 SIP/2.0 200 OK.
>>>>>>> Via: SIP/2.0/UDP
>>>>>>> 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0.
>>>>>>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
>>>>>>> From: "Paul (1002)"
>>>>>>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>>>>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
>>>>>>> CSeq: 21752 INVITE.
>>>>>>> Contact: sip:4075551212 at 216.50.50.50:5060.
>>>>>>> Record-Route: <sip:216.50.50.50:5060;lr>.
>>>>>>> Record-Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
>>>>>>> Accept: multipart/mixed, application/sdp, application/isup,
>>>>>>> application/dtmf,
>>>>>>> application/dtmf-relay.
>>>>>>> Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO.
>>>>>>> Supported: timer.
>>>>>>> Content-Disposition: session;handling=required.
>>>>>>> Content-Type: application/sdp.
>>>>>>> Session-Expires: 240;refresher=uas.
>>>>>>> .
>>>>>>> v=0.
>>>>>>> o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76.
>>>>>>> s=SIP Media Capabilities.
>>>>>>> c=IN IP4 100.99.99.99.
>>>>>>> t=0 0.
>>>>>>> m=audio 35552 RTP/AVP 18 101.
>>>>>>> a=rtpmap:18 G729/8000.
>>>>>>> a=rtpmap:101 telephone-event/8000.
>>>>>>> a=fmtp:101 0-15.
>>>>>>> a=sendrecv.
>>>>>>> a=nortpproxy:yes.
>>>>>>>
>>>>>>> #
>>>>>>> U 2004/11/18 14:13:08.428394 100.10.10.10:5060 ->
>>>>>>> 100.99.99.99:5060 ACK sip:4075551212 at 216.50.50.50:5060 SIP/2.0.
>>>>>>> Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d.
>>>>>>> Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
>>>>>>> Route: <sip:216.50.50.50:5060;lr>.
>>>>>>> From: "Paul (1002)"
>>>>>>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>>>>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
>>>>>>> Contact: <sip:9990010001 at 192.168.0.83;user=phone>.
>>>>>>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
>>>>>>> CSeq: 21752 ACK.
>>>>>>> User-Agent: Grandstream BT100 1.0.5.16.
>>>>>>> Max-Forwards: 70.
>>>>>>> Allow:
>>>>>>> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. .
>>>>>>>
>>>>>>> #
>>>>>>> U 2004/11/18 14:13:08.429879 100.99.99.99:5060 ->
>>>>>>> 216.50.50.50:5060 ACK sip:216.50.50.50:5060;lr SIP/2.0.
>>>>>>> Via: SIP/2.0/UDP
>>>>>>> 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0.
>>>>>>> Via: SIP/2.0/UDP
>>>>>>> 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d.
>>>>>>> From: "Paul (1002)"
>>>>>>> <sip:9990010001 at sip.mycompany.com;user=phone>;tag=92691bb29380c100.
>>>>>>> To: <sip:14075551212 at sip.mycompany.com;user=phone>;tag=069c9797.
>>>>>>> Contact: <sip:9990010001 at 100.10.10.10:5060;user=phone>.
>>>>>>> Call-ID: e37c04be3e50ea72 at 192.168.0.83.
>>>>>>> CSeq: 21752 ACK.
>>>>>>> User-Agent: Grandstream BT100 1.0.5.16.
>>>>>>> Max-Forwards: 16.
>>>>>>> Allow:
>>>>>>> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. .
>>>>>>>
>>>>>>>
>>>>>>> --- "Greger V. Teigre" <greger at teigre.com> wrote:
>>>>>>>
>>>>>>>> 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
>>
> === 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