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

[Greger V. Teigre]

Klaus and Dragos,
I also agree on your statements/suggestions regarding the script, 
however, I realize that there is too much history (and hours and days of 
work) invested in ser.cfg. At least to radically strip ser.cfg.  That 
could quickly render ser useless for many setups where implementation 
errors have been corrected by "fixes" and where one has adapted to all 
the non-standard approaches...

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

This is exactly what I have spent a considerable amount of my time on 
the last months. I use m4 and set of template files + "hooks" in the 
template files where you can add your own code. Using this build system, 
you can manage a set of servers with common features, as well as be able 
to manage differences between servers.
It is built on the SER - Getting Started configuration files and I'm 
getting closer to releasing a first version. It will be commited to SER 
2.0 CVS as this has no code impact.

My goal is that ser.cfg should ALWAYS be auto-generated and that you can 
use switches in the configuration file together with code pieces for 
each hook (ex. detecting NAT) to modify the configuration.
g-)

Klaus Darilion wrote:
> 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
>
>