[Serdev] So who/what is SER for, anyway?

[Greger V. Teigre]

Hi Dragos,
Thank you for taking the time to write about your experiences and 
frustrations!
You cover quite a lot and a thread following your post will quickly 
become unwieldy and difficult to follow.
I thus take the liberty to split your post into several sub-topics to 
allow people to follow those they feel like contributing to.
g-)

Dragos Vingarzan wrote:
> Hi all,
>
> I am not sure if I should start this thread or not... recently some heat
> came up on the dev list ("usrloc loading") and the most important thing
> out of it (and neutral, because somehow the discussion included stuff
> like ser vs openser) is what Greger blogged here
> http://sipstuff.blogspot.com/2007/01/who-is-ser-for.html . I wouldn't
> have replied to any of it, but Greger pointed out that SER became the
> basis for other projects, like the Open IMS Core that I am working on at
> the moment and if SER's developers noticed us, maybe our experience and
> opinions might be of interest to them. (And the Open IMS Core is not the
> only one, not even the only IMS CSCF one...)
>
> Some of you might receive this as SER bashing. But please understand
> that I only want to point out the parts that I, for one, really hate, in
> the hope that the future would bring something good. I think that SER is
> a wonderful piece of software, but it just shows it's age and has some
> cans of worms here and there.
>
> So for the past years I have been working and playing with NGN concepts.
> Part of my work are some SER modules + scripts that would enable the use
> of SER as some sort of basic IMS CSCFs. However, the most annoying thing
> that I had to deal with is SER's "design". Whenever something does not
> work, you need to make changes in too many places and then suffer the
> consequences as you will surely break something else. With every new
> feature that you want to put it, you have to think about redesigning
> parts of SER. When you look at the code, you can understand the reasons
> for sure - like performance. But if you do not have a lot of
> digging-experience through SER's code, you won't be able to do much.Then
> it is almost impossible for me to assign even simple tasks to beginners
> and as such our progress is extremely slow.
>
> To me, the whole thing looks like a pile of hacks. When was the last
> time that there was a overall design discussion? I think that modules
> and extensions just grew around, but nobody wanted or had the power to
> cut some dead branches, enforce some policies and specify some clear
> internal interfaces. If one person would take care of it end-to-end, OK,
> but it's not the case.
>
> So let me be specific:
> - the process model
>     - believe it or not, I might want to write a module that needs more
> processes to be efficient. SER is no longer "just a SIP proxy".
>     - yes, I know about the FIFO, RPC and whatever other interfaces, but
> is anyone fully satisfied with that?
>
> - the parser
>     - if SIP is an extensible protocol regarding the headers, why don't
> we have an equally easy to extend parser? For example, the header name
> parser could be auto-generated from a list of configurable header names.
>     - and do we really need it that fast anyway? I have seen some
> changes that push code clarity instead of insane performance, just keep
> them coming.
>     - in the end could we have a clear and nice API to work with SIP
> messages, headers and URIs? Because not everybody wants to deal with SIP
> syntax all the time, yet every module re-implements the hunt for header
> values.
>
> - the lumps
>     - performance + memory concerns, ok, but the mechanism is a little
> perverse. First you do not (and can not) enforce even the RFC compliance
> of messages. Then if I do a change, another module can't see it and you
> just hope all will be fine.
>     - this goes then back to the point above - lack of an API, as an API
> would hide the internal structures in the core and let you modify and
> view modifications easily and transparently.
>
> - the tm module
>     - this is standard RFC3261 behavior, yet is this complete now? I for
> one can not keep-up and understand all of it. One has to know very well
> the RFC and then through its code to use it, as it's up to the user to
> ensure conformance.
>     - isn't this core functionality? I just want to have a flag that
> would enable/disable/indicate transactions. Then 90% of the users would
> just enable that and forget about the over complicated scripts and the
> rest would just disable and enable it separately.
>
> - the dialogs
>     - again, this should be core. I think everything that is in RFC 3261
> (at least) should be core if we want a "SIP" proxy.
>
> - transport
>     - no interface here, so defining new transports or new ways of
> handling messages is impossible.
>
> - the script
>     - great thing, but I think that it was designed pre-transactions,
> pre-dialogs, etc, right?
>     - lot's of opportunities there, but too many ways of breaking
> things. If this is designed for normal users, then maybe the range of
> actions should be restricted and piped through an API that would
> eliminate most of the conformance issues that might appear.
>     - Someone needs to step in and set some boundaries here. It's great
> for people without programming experience, that do not want to write a
> module to do something new, but it is often abused by the same people
> and then hacks propagate into the modules and core. Too much flexibility
> from my point of view. You want to do something complex, then write a
> module and interface it to the script, then have a small and clean
> linking script.
>
>
>
> In the end, one of my conclusions would be that SER is too low level to
> be reliably usable in even mildly complicated scenarios by current
> standards. Would be great, I think, if one of the core developers would
> step-up and take a leadership role:
>     - gather features for the new SER
>     - design an improved architecture that takes into account the
> changes in the last years in the usage patterns
>     - eliminate SER's arrogance towards inexperienced users. Come on
> guys, SIP becomes more and more a commodity these days than a
> specialist's tool
>     - consider that SER might be used as a platform for other projects
> and as such nicely interface with upper layer applications
>     - enforce that design by refusing compromises and hacks that do not
> improve the initial design
>    
> When OpenSER was forked, I hoped that they will have the power to do
> that, but this did not really happen there either (let's not flame about
> SER/OpenSER now). What would it take for this to happen? Because in the
> current state SER's "flexibility" is killing SER itself by making it too
> hard to do high-level scenarios. Beginners use asterisk and experts just
> start from scratch with a simple SIP stack. For example, every time that
> I have to add a new feature in the Open IMS Core, dealing with simple
> things is so complicated that I constantly consider dropping SER as a
> base for my project and just use a normal SIP stack (like pjsip for
> example).
>
> Here is another question to Greger's blog about SER positioning - which
> users is SER targeted towards? Is it just for intermediates? The ones
> that grasped enough of SIP to handle it but are not yet so advanced to
> write their entire proxy from scratch?
>
> Is there a future in this sense of broadening its applicability and
> could SER 2.0 be more than just marketing? Or SER is just for handling
> VoIP? Because in my opinion, through the adoption of SIP as a next-gen
> signaling protocol, new opportunities open up for SER. Yet there is no
> clear signal that SER will continue to play this big role in NGNs as it
> does now with VoIP...
>
>
> Regards,
> Dragos Vingarzan
>
>
> FOKUS/NGNI
> Kaiserin-Augusta-Allee 31
> 10589 Berlin,Germany
> Phone +49 (0)30 - 3463 - 7385
> eMail vingarzan at fokus.fraunhofer.de
> Web www.fokus.fraunhofer.de
> We could change the world if God would give us the source code...
> -----------------------------------------------------------------
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>
>