What SER is and isn’t
Source: snapvoip.blogspot.com
VoIP IP Telephony @ http://snapvoip.blogspot.com
Sys Admins view of SER guts!
The following information is from SER site news report, which in turn plucked from a discussion on a Developers mailing list. It is so important so that I have entirely reproduced the post, for my own reference.
"Consider a more simple SIP proxy like repro. All you can do there is start the damn thing and give it the user data (what would be subscribers, aliases, and parts of the usr_preferences in SER 0.9). Sounds all nice and simple.
Now, as an VoIP operator, my world will be a little bit more complicated. I may have different services that run on separate proxy farms. I may have interesting add-on services like call forwarding, voicemail, IVRs, whatever else product management comes up with. Somewhere in a dark corner, I have some PSTN gateways or, instead, I have an agreement with some telco to do that for me.
If you draw this, you’ll get at least half a dozen boxes with weird connections between. If this doesn’t scare you, start sketching the call flows. You will suddenly find little funny quirks, that of course you can put into C code but if why? SER provides you with the opportunity to solve pretty much all of them in a very simple language.
Better yet: You write your script, you do a test call. If it doesn’t work, you make a trace, you fix your script and try again. No compiling, no packaging, just a restart (BTW, something for the wish list: reloading the config on a SIGHUP). Another trace, another round.
Now we fast forward a bit. Your system is running just fine. But one of your PSTN interconnect partners updates their software and — surprise — all the calls to them fail. Sure, you could use another partner. But your friends in billing will tell yet that their prices for some destinations are just insane. We _really_ have to have that first partner.
Sure, you quickly figure out what the problem is. Sure, you call them and try to explain to the unfortunate fellow on the other end how SIP works and why their stuff isn’t really SIP. Sure, after a while they give in and promise to fix it. But can they do that quickly? Nope. They have to go and talk to whoever delivers their software.
Half a year passes and nothing much happens.
Now, with SER all I need to do is find the route for the specific partner, do the magic with subst() and maybe some other horrible things and voila, it works. Everyone is happy. And should the partner actually ever get their stuff fixed, I can just remove those three lines I had to add.
With repro, things would have been quite different. I have to know enough C++ to actually grok their design or have to have someone doing this. Implementing the three line fix, testing it, producing it easily takes a man-day. With SER I did that in three minutes. Including
the test call.
What it comes down to is, that there is no universal thing. For NATi, there isn’t six funny devices that you find a work around, report to the good folks at iptel, who then add another flag. NAT routers change with every software revision. Old things go away, new things pop up. It is your responsibility as a provider to stay close. That’s what people pay you good money for.
Sure, SER is hard to get into as a beginner. If you want to stay a beginner and don’t care about SIP, use repro. It’ll probably work for you out of the box. If you expect to have to do more, invest the time, learn SIP, learn the ser.cfg. It will pay off later. Everything will be "SER gut" (Sorry, that just had to happen)."
