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

[Greger V. Teigre]

Hey Martin, that was great and really engaging writing!
Do you mind if I put your post on iptel.org as one of the descriptions 
on a new page "Is SER for you???!!"
g-)

Martin Hoffmann wrote:
> 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
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/633bb649/attachment.htm