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

[Dragos Vingarzan]

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...
-----------------------------------------------------------------