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

[Dragos Vingarzan]

Greger V. Teigre wrote:
>
> 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.
>
>     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 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.
>
>  * 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).
>
>  * 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...
>
>  * 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
>
> 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).

-Dragos