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

[Dragos Vingarzan]

Martin Hoffmann wrote:
>
> 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.
>
Well, if I look from the Application Level down towards SER, the pile of
things that you need to additionally put in, is huge. I am not talking
about a simple proxy, but let's look at a CSCF for example. I would've
expected that a SIP proxy would have, by default, the capability of
replicating its transaction state for reliability. Instead, you have to
later take care of it. This is why I think that by current standards and
what SIP proxies should do, it is too complex to work with. And by
current standards I mean things like what is actually the percentage of
people not using transactions so that they are considered non-core?
>
> 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.
>
I think that we should just get all that RFC in there and move over. I
still think that SIPs complexity could be handled if we divide and
control the subproblems.
>
> > 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.
>
power is nothing without control - Pirrelli ;-)
>
> > 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.
>
then should a CSCF control SER through RPC or something like that? do
you think that is a good idea? Why not accept all the things that people
are taking for granted now? Most of the problems that the SER developers
deal with day-to-day, like non-interoperability, should not bother them.
>
> > 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.
>
Of course, I had only the developer position in mind. And from my point
of view, I often loose the commercial requests, that you primarily seen
and it is great that you bring them up. I agree with you, you are right.

But also think in a "long"-er run about SER. In a few years voice will
be free - then VoIP would probably die as an alternative. Then what? SIP
is not only about VoIP and if SER would not be ready for you until then,
you will eventually loose.

-Dragos