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

[Greger V. Teigre]

> 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. 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
As mentioned in an earlier post, I think this might be a bit 
unrealistic. However, I agree that something should be done, and we have 
discussed naming a formal group of developers (hitherto referred to as 
"core developers") as a technical board. I think it is inevitably, it is 
just that we are so busy getting SER 2.0 into release quality...
>    - eliminate SER's arrogance towards inexperienced users. Come on
> guys, SIP becomes more and more a commodity these days than a
> specialist's tool
Here, Martin, you should comment! You argued for SER as a professionals' 
tool, Dragos challenge you...
And Jiri, you mentioned service providers as the most important current 
group of SER users.
To both: This is maybe how it is today, is it this way we want it to be 
tomorrow?
>    - 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).
Yes, as far as I can see, most people have agreed that this flexibility 
can be a problem. The issue is more what should we do about it?
>
> 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?
Interesting, you are arguing that SIP is becoming a commodity, but still 
claim that advanced users would go for a SIP stack. I would think that 
SIP becoming a commodity would mean the major weight will be on 
applications of SIP and all kinds of "everyday" usage, not on developing 
many variants of SIP servers?

So, the question would rather be, should a project use onDo, repro, SER, 
Asterisk, ... for their new SIP business or need?  Can ever SER satisfy 
guys who even consider writing their own SIP stack for their next project?
I would say no, and I would prefer to focus on applications of SIP, not 
implementations of SIP proxies, application servers etc. I think we 
should collaborate with Olle and Asterisk as Olle suggests and try to 
define the segment where SER can bring value.

However, that being said, I believe the usability of ser.cfg, as well as 
the module interface/API have clear impact on SER's usability in 
real-life SIP applications, now and in the future.
> 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'm a bit uncertain when you say NGN. It is very operator-centric (of 
course, IMS is...)  I'm very uncertain on the place of open-source in 
the telco world beyond interoperability, testbeds etc.  I don't think 
that's where the primary innovation will be. On the other hand, smaller 
startups developing applications and real-world SIP stuff FOR operators 
may very well need open-source SIP components.
And then we have those focused on Internet-centric/IETF based SIP 
applications...

But of course I agree, I think SER has a place in the world of SIP as an 
enabling protocol for all sorts of applications, not only voice.
g-)