[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Martin Hoffmann]

Dragos Vingarzan wrote:
>   
> OK, but what if when you discover a strange behavior you put it in and
> then have a flag, like "fix_the_stupid_X_nat". This flag being
> documented, would then save a lot of time for a lot of administrators
> that would bang their heads on the same X NAT. But having all these
> hacks here and there and having to put them in all other routes that do
> something completely different is just too hard to be a good solution.

I still think you don't really see the picture here. Let me try to
explain. 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 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 NAT,
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).

Regards,
Martin