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

[Jiri Kuthan]

what is NGN? -jiri

At 20:16 24/01/2007, 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

--
Jiri Kuthan            http://iptel.org/~jiri/