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

[Martin Hoffmann]

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.

Jesus, no! The point of having optional record routing on a per-request
basis is that you can only have record routing if you need this.

Consider an INVITE request spiraling through your proxy for whatever
reason. Do I need to see the BYE six times? No. But I want see it once.

	if (method != "REGISTER && src_ip != myself) {
		record_route ();
	}

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

So your NAT traversal strategy is the same as mine? I do have a couple
of special things which I can only do because the script allows me to do
whatever I want.

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

Yes. And now please explain what is wrong with this. I need a proxy that
suits my needs as a large ITSP. I really don't care about a twenty
people office. If "my" proxy can be used by them as well, fine. But I do
not see why I should use an inferior product just to please some people
for whom there already are perfectly fine alternatives.

That's just my sixteen øre as someone who gets all the strange
interoperability problems on his desk and needs fix them. Ultimately,
the fate of SER is in the hands of the core developers.
 
> 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 is working on it. What I've seen of it is very promising,
so bear with him.

Regards,
Martin