A SysOp's Perspective on SER's flexibility

This snippet was cut from the developer's mailing list during a discussion on seri.cfg, SERi's pride and most beginners' challenge... It will give you an insight into what SER is and isn't, and whether it might be for you :-)

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 VoIPi 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 PSTNi 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 wishlist: 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, productifying 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 resposibility 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).