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

[Jan Janak]

Dragos Vingarzan wrote:
> 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),

  Transport and protocol (if you mean things like sigcomp) is something
  that is being worked on, Andrei could tell you more.

> transaction handling, 

  I agree that transaction handling needs better interface.

> state support (would be replicated), modules, etc.

  Vaclav has been working on state support in the realm of presence
  modules

> 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 have a different opinion on this. SER core should stay as a simple
  message forwarder. There are certainly things that can be made better,
  such as the tm interface (functions called in the script), dialog
  support, and handling of multiple downstream branches, but in
  principle I think the current mechanism of implementing the routing
  logic in the script is right.

    Jan.