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

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" &lt;greger(a)teigre.com&gt; 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" &lt;greger(a)teigre.com&gt; 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