[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...
    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.

I am sure the SER developers share your pains, but many of them have 
worked on SER since the beginning, they know everything in detail, even 
why things historically were made that way.

I have some questions:
 * Why didn't you start out with a SIP stack as you mention?
 * Would you use SER if you had to make the decision again?
 * Has lack of documentation in any way influenced the experience?
 * Do you really think that it is a viable path to make ser into the 
chosen codebase to extend for projects like your own?
 * And if you try to generalize, what would be the three most important 
things to focus on?

And I'm particularly interested to hear from Jan, Andrei, and Jiri on 
SER as an extendable codebase/SIP stack.

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

This may be completely unrealistic the way I describe it, but this is 
basically the same reSIProcate did with repro, going the other way around...
g-)

Greger V. Teigre wrote:
> Greger's comment: I interpret the first part of Dragos post as a 
> frustration related to using SER's code base to realize another 
> SIP-related application, i.e. using SER instead of a SIP stack. Thus, 
> I call this thread: SER as an extendable codebase/SIP stack.
> ---------------------------------------
> Hi all,
>
> I am not sure if I should start this thread or not... recently some heat
> came up on the dev list ("usrloc loading") and the most important thing
> out of it (and neutral, because somehow the discussion included stuff
> like ser vs openser) is what Greger blogged here
> http://sipstuff.blogspot.com/2007/01/who-is-ser-for.html . I wouldn't
> have replied to any of it, but Greger pointed out that SER became the
> basis for other projects, like the Open IMS Core that I am working on at
> the moment and if SER's developers noticed us, maybe our experience and
> opinions might be of interest to them. (And the Open IMS Core is not the
> only one, not even the only IMS CSCF one...)
>
> Some of you might receive this as SER bashing. But please understand
> that I only want to point out the parts that I, for one, really hate, in
> the hope that the future would bring something good. I think that SER is
> a wonderful piece of software, but it just shows it's age and has some
> cans of worms here and there.
>
> So for the past years I have been working and playing with NGN concepts.
> Part of my work are some SER modules + scripts that would enable the use
> of SER as some sort of basic IMS CSCFs. However, the most annoying thing
> that I had to deal with is SER's "design". Whenever something does not
> work, you need to make changes in too many places and then suffer the
> consequences as you will surely break something else. With every new
> feature that you want to put it, you have to think about redesigning
> parts of SER. When you look at the code, you can understand the reasons
> for sure - like performance. But if you do not have a lot of
> digging-experience through SER's code, you won't be able to do much.Then
> it is almost impossible for me to assign even simple tasks to beginners
> and as such our progress is extremely slow.
>
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>