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

[Martin Hoffmann]

Greger V. Teigre quoted Dragos Vingarzan:
> 
> 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.

Pretty much all providers I have spoken to who do not use proprietary
hard- or software will tell you otherwise.

> 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

Have you looked at the development lately? SIP is becoming more complex
by the minute. According to the Hitchhikers Guide Draft, the core
specification is somewhere in the area of 750 pages. All the RFCs that
the guide mentions amount to more than 2500 pages. People used to favour
SIP over H.323 on grounds of it being more simple. Now, we may as well
just go back to H.323.

On top of that you have interoperability issues on a scale that is
mind-boggeling. The mere fact that there is something like SIPit is very
telling.

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

That's just not true. If all you want is an open source SIP proxy for a
medium to large scale operation, then (Open)SER is still your choice.
There used to be things it cannot do, but with SER 2.0 (and most likely
with whatever the OpenSER people are up to lately) there is a lot less
left. As I have stated on other posts, the flexibility is one of the
main selling points for SER.

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

That actually might be a viable option. If your IMS stuff demands more
than a simple proxy (and remember, technically a proxy isn't even
allowed to modify most existing header fields) you may need something
else than a simple proxy.

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

You obviously see this from a developer's perspective. As a service
provider, even if I am able to write my own proxy, I cannot afford to do
so. I need a reasonably stable, bug free product. SER is providing me
with that. I have my little fights with it and there have been days when
I wished I had never been introduced to it (you know, I want to be a
lumber jack ...), but in the long run, it gives me the best value for
money (TCO in this case) on the market.

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

Well, I'd rather not comment on this. There is enough ranting on my part
already.

Regards,
Martin