The only reason I removed the "if else" in favor of two (2) "if" statments was nothing more than code simplification. As I recall I was having to call fix_nated_contact in both branches anyhow.
Regards, Paul
--- "Greger V. Teigre" greger@teigre.com wrote:
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?r...
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@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@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:
- 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
=== message truncated ===
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com