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

[Jan Janak]

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

  I think that this is a typical clash of priorities because people are
  trying to use the code for something it hasn't been designed for --
  due to various reasons. For example people who need a PBX-like system
  would typically use asterisk. People who are primarily dealing with
  SIP and need to implement more-complex SIP scenarios would use
  something like SER. People who need to develop their own (more complex
  than what can be done with ser scripting language and transactions)
  applications would probably you a SIP stack or application server with
  nicely designed layers and APIs.

  While SER can be pre-configured and pre-packaged to make it work out
  of the box, we cannot really turn it into an fully featured
  application server with layers of APIs unless we rewrite it from
  scratch.

  When thinking about future designs that we should develop in SER I
  always position it somewhere between asterisk and a full B2BUA-like
  application server.

  I do feel Dragos' pain with IMS-like scenarios implemented in SER as I
  have been partially exposed to it, but I really think that a B2BUA
  like application server would do a better job there.

> 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

  It surely would be possible, but quite complex, from my point of view.

> 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-)