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

[Jan Janak]

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.

  Like every other open-source project. Most open source projects evolve
  gradually, you can never made everybody happy. Note that SER is only 6
  years old, compared to other significant oss projects it is still an
  infant.

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

   What exactly is so wrong with the process model? You can write a
   module that needs more processes, there are modules doing it.

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

  Because nobody except you was complaining about that. Maybe you could
  write it and contribute a patch?

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

  Well, if you do not need the performance you do not have to extend the
  parser. Traversing the list of headers and comparing their names
  byte by byte is simple. If you still think this is not simple enough
  then maybe you could describe what the perfect API you are looking for
  should look like.

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

  If you want a SIP proxy then you do not need to deal with dialogs. I
  don't understand why everything should be put into the core.

> - transport
>     - no interface here, so defining new transports or new ways of
> handling messages is impossible.

   This is being worked on.

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

  I am just afraid that "architecture that takes into account.." means
  that you want SER to be easy to use in common IMS scenarios, which
  anything but mildly complicated.

>     - eliminate SER's arrogance towards inexperienced users. Come on
> guys, SIP becomes more and more a commodity these days than a
> specialist's tool

  There are other tools like asterisk, siproxd, and others that are
  easy to use for beginners.

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

  This is a generic statement that may have different meaning to
  different people. I can argue that what you are proposing, i.e.
  turning SER into an application server with B2BUA capabilities (which
  is what you probably want) is not the right way to go. Such
  applications are available on the market.

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

  I think there might be some confusion, you probably mean IMS when you
  write SIP. I am not sure SER could play the "big role" in IMS
  scenarios due to the fact that the specifications are simply too
  complex and hard to implement.

     Jan.

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