[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Klaus Darilion]

Regarding the script I fully agree with Dragos!

IMO there are several things which should be hided from configuration. 
E.g. the terrible if(method!=REGISTER) record_route();

IMO we should have an option record_route=yes and we are done.

Also the whole NAT traversal. This should be handled globally too, e.g.

perform_nat_traversal=no/always/ifneeded (this of course automatically 
activates the rtp proxy - no need to check for replies with 183/200 - no 
need to check for reINVITEs, ...)

rtp_proxy=mediaproxy/rtpproxy

allow_preloaded_routesets=no/yes

And so on. I suspect there is no ser/openser installation out there 
(included mine) which is 100% RFC conform regarding or has a total 
bugfree NAT traversal (e.g. doing fix_nated_contact only for local SIP 
users) ...

Thus, there is lots of potential to make ser more user friendly. The 
above examples do not have any performance impact, but prevents users 
from having lots of bugs in their message handling and NAT traversal).

I already can year you crying that we will loose all the flexibility 
when doing this - but in the end we will have a very flexible SIP proxy 
which will be used by geeks and there will be not so flexible SIP 
proxies (asterisk, repro ...) which will be used by admins without a PhD 
in SIP.

regards
klaus

PS: We could start with a script which generates the ser config from a 
template file and a user configuration file as starting point for users 
(like the exim4 configuration in debian)


Greger V. Teigre wrote:
> Greger's comment: Dragos have several observations related to the core 
> design of SER, namely the process model, the parser, the lumps and the 
> script. Thus, the thread name: SER's core design features(process 
> model/parser/lumps/script).
> --------------------------------------
> 
> So let me be specific:
> - the process model
>    - believe it or not, I might want to write a module that needs more
> processes to be efficient. SER is no longer "just a SIP proxy".
>    - yes, I know about the FIFO, RPC and whatever other interfaces, but
> is anyone fully satisfied with that?
> 
> - the parser
>    - if SIP is an extensible protocol regarding the headers, why don't
> we have an equally easy to extend parser? For example, the header name
> parser could be auto-generated from a list of configurable header names.
>    - and do we really need it that fast anyway? I have seen some
> changes that push code clarity instead of insane performance, just keep
> them coming.
>    - in the end could we have a clear and nice API to work with SIP
> messages, headers and URIs? Because not everybody wants to deal with SIP
> syntax all the time, yet every module re-implements the hunt for header
> values.
> 
> - the lumps
>    - performance + memory concerns, ok, but the mechanism is a little
> perverse. First you do not (and can not) enforce even the RFC compliance
> of messages. Then if I do a change, another module can't see it and you
> just hope all will be fine.
>    - this goes then back to the point above - lack of an API, as an API
> would hide the internal structures in the core and let you modify and
> view modifications easily and transparently.
> 
> - the script
>    - great thing, but I think that it was designed pre-transactions,
> pre-dialogs, etc, right?
>    - lot's of opportunities there, but too many ways of breaking
> things. If this is designed for normal users, then maybe the range of
> actions should be restricted and piped through an API that would
> eliminate most of the conformance issues that might appear.
>    - Someone needs to step in and set some boundaries here. It's great
> for people without programming experience, that do not want to write a
> module to do something new, but it is often abused by the same people
> and then hacks propagate into the modules and core. Too much flexibility
> from my point of view. You want to do something complex, then write a
> module and interface it to the script, then have a small and clean
> linking script.
> 
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev


-- 
Klaus Darilion
nic.at