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

[Jan Janak]

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. 

  But this is how, for example, asterisk works. I have seen a couple of
  setups where the default behavior of nat traversal as you described it
  was not sufficient and I had to do custom changes -- being grateful
  for the flexibility we have.

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

  Probably not because noone knows haw a bug-free nat traversal should
  look like ;-).

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

  Yes, I think something like this is the right way to go. In addition
  to that we could use external configuration files for modules (such as
  the one for tls module) and the possibility to include other files in
  the configuration file.

    Jan.