[Serdev] SER as an extendable codebase/SIP stack - was: So who/what is SER for, anyway?

[Greger V. Teigre]

>> Dragos,
>> I think you have used ser for something it was not originally designed
>> for. At least, from own experience, I would imagine that in the early
>> days, the developers did not think that their code would some day be
>> used for implementing an open-source CSCF...
>>
>>     
> Well, many other people did so, it's just that we surfaced first and
> that we are trying to make the others converge with us. I would go back
> 2 years and explain the reasons why we did chose SER. Back then, we had
> some meetings with equipment manufacturers and out of the discussion
> came the following idea: If SER is representative for the performance of
> SIP proxies (see the "On SIP Performance" paper from Lucent), then we
> can derive that future NGN signaling switches (using SIP) would have a
> performance figure near to that of SER (I won't detail about hardware
> advances and extra software requirements). So if you would want to have
> a glimpse into what hardware would you need for IMS, then the easiest
> way would be to extend SER.
>   
Hm, interesting argument, but maybe relevant... :-)
>>     Andrei commented a while back that it should be possible to extract
>> a SIP stack from ser, and I have also seen many people asking if they
>> can use ser as a SIP stack. This is basically what SEMS is doing, using
>> the socket interface. I know there are plans for a new external
>> application interface that would make this usage easier.  However, I'm
>> not sure if this would help you in any way. CSCF is a full SIP server in
>> itself with lots of added stuff, not an application in need for SIP
>> proxy front-end.
>>
>>     
> But it's not just the SIP stack. There are a lot of other things that
> are common, so to me it seems natural to use SER. Yes, SER is not
> perfect for this role, as UAC is a little too basic, but UAS is great. I
> know that it is basically a SIP proxy and the whole architecture is
> centered around that, but couldn't we leverage the code base and build a
> UAC/UAS/Proxy/B2B out of it? There are already efforts, like the uac or
> presence_b2b modules.
>   
I think Jan commented on this, I'll comment on that instead of here.
>> I have some questions:
>>  * Why didn't you start out with a SIP stack as you mention?
>>
>>     
> 1. Because of the first requirement that I explained, related to the
> hardware performance evaluation.
> 2. Because the start-up would have been hard and because we never wanted
> to develop a rock-solid product (no big investment here). At the
> beginning we just wanted to play with IMS and as nobody had CSCFs, we
> wrote some.
> 3. Because it would have contained the same things: memory management,
> network operations, module operations, etc. Why reinvent the wheel?
> 4. Because the CSCFs are just standard IETF SIP Proxies, on which 3GPP
> recommends some usage patterns. it's not like 3GPP/IMS would reinvent
> SIP proxies. They are just usage patterns and if you would look at the
> RFC 4740, you would see the same architecture. If SER is a good SIP
> proxy, it should also be a good CSCF.
>   
Yes, I see the arguments. I also see why you have had frustrations :-) 
I'm not sure if SER "should also be a good CSCF" by virtue of being a 
good SIP proxy. Or maybe said differently: I think a more interesting 
question from a SER development perspective is: Should SER have a 
design/architecture that enables people to extend it with functionality 
like for example CSCF? And where do we stop before a good proxy has been 
turned into a bad "everything-for-all" ?
>>  * Would you use SER if you had to make the decision again?
>>
>>     
> Unfortunately, NO. Because at this point there are certain easy features
> that would take too much time to do them with SER than start over with a
> new architecture. What keeps me to SER now is just it's stability and
> the fact that a new base would be unstable for a long period of time
> (too long for our academical and research-only purposes).
>   
Thanks for being honest :-)
>>  * Has lack of documentation in any way influenced the experience?
>>
>>     
> yes, negatively. We are a research institute and as such we employ many
> students for research project. The fact is that unless those students
> had a background in writing kernel modules and compilers, they don't
> stand a chance for any SER related project. As such, we are seriously
> underpowered.
>
> But I wouldn't blame it all on the documentation. We tried to enforce
> doxygen and every function should be documented a little, in Open IMS
> Core. Now I am not sure that it helps much. The problem is that there
> are no clear internal interfaces/APIs (except the module and script
> ones) and as such you have to always dig through piles of code. And then
> someone changes that code and you have to dig again...
>   
Ok, I see.
>>  * Do you really think that it is a viable path to make ser into the
>> chosen codebase to extend for projects like your own?
>>
>>     
> I think it is. I don't think that my changes to the core were too exotic
> and some were accepted. Anyway, you know the ads with total flexibility
> through modules and script, right? So why not?
>   
>>  * And if you try to generalize, what would be the three most important
>> things to focus on?
>>
>>     
> more internal APIs, better&transparent standard compliance, extend the
> core with the most used ops in the modules
>   
I get the first one, the two last I'm a bit uncertain, but I'll pick it 
up in later posts and threads...
>> Without actually considering existing design, an interesting idea (if we
>> follow your suggestion, Dragos), would be to separate SER into three
>> components:
>> 1. The core "SIP stack", but keeping SER's values compared to "other SIP
>> stacks". This could be used for projects like yours
>> 2. The SIP server front-end with a ser.cfg utilizing the core
>> 3. The modules that extend both
>>
>>     
> I wouldn't go that far. I think that a clear modularization of the core
> would suffice. Like transport, SIP codec (or protocol codecs),
> transaction handling, state support (would be replicated), modules, etc.
> There are already good SIP stacks out there to add one more. But I think
> that standard functionality should be part of the core and all the
> control that is needed is in the form of flags and variables (I don't
> see why anyone would want to write a script that implements another
> transaction state machine as the RFC one).
>   
I hope Martin has by now showed you that somebody would actually want 
that and why ?!
g-)
> -Dragos
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/5e2e8326/attachment.htm