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

[Greger V. Teigre]

Dragos Vingarzan wrote:
> 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?
>   
"replicating its transaction state", you mean a SIP transaction?  If 
that's what you mean, this is an example of why telco-apps get so 
expensive. What if the server goes down in the middle of the 
transaction?  It fails, hey, that's a bummer, so it has to be resent, by 
the UAS. Why would you spent an immense amount of money to make sure 
that the transaction can fail over?! 

So I think it is important here to determine which of "SIPs 
complexities" that we should "divide and control" and which we should 
just leave to the Ericssons...
g-)
>> 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
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/c7bb1327/attachment.html