[Serdev] A suggestion for how SER should focus - was: So who/what is SER for, anyway?

[Andrei Pelinescu-Onciul]

On Jan 25, 2007 at 09:41, Greger V. Teigre <greger at teigre.com> wrote:
> Greger's comment: And finally, I interpret the last part of Dragos' post 
> as a suggestion for how SER should focus and thus for whom SER should be 
> for. Thus, I chose the thread name: A suggestion for how SER should focus.
> -------------------------------------
> 
> 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.

If by current standards you mean IMS you  might be right. As far as pure
sip is concerned I think ser is exactly at the right level (you can do
both low and high level stuff).

> 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

Writing ser from scratch would be a huge effort and with very little
benefit.  There are still lots of problems that needs solving in the
current ser version and you'd want us through everything away and start
again, waisting a lot of time.
I believe in a gradual evolution.

>    - design an improved architecture that takes into account the
> changes in the last years in the usage patterns

Could you detail the changes 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

Ser is not an exclusivist tool (you can start it with a pre-existing good
config, so even inexperienced users could use it for simple stuff), but
 if you want special configs, then yes you have to know a little about
 sip, ser configs and modules.

>    - consider that SER might be used as a platform for other projects
> and as such nicely interface with upper layer applications

This depends on what you mean by upper layer applications. Anyway ser
tries to be good as a proxy and not as a sip application platform.

>    - enforce that design by refusing compromises and hacks that do not
> improve the initial design

Easier said then done :-)

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

Actually I'm very curious what the OpenSer developers would say about
this. It might be that only you see the need for a big change.

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

Some of us are not really interested into what you call NGNs and don't
have a good opinion about IMS in general (on the contrary).
As far as I'm concerned ser is a very flexible and fast sip proxy and
the version number indicate improvement and not re-orientation.


Andrei