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

[Martin Hoffmann]

Dragos Vingarzan wrote:
> Martin Hoffmann wrote:
> > 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 it spirals through your proxy, there surely is some reason for it. I
> think that there should be a dialog level, where you could just enable
> this always-on record-route. If you have reasons for the spirals, then
> just don't use this dialog level and build your own non-standard mechanism.

Actually, there is a dialog in each single turn of the wheel. Simple
example: Call forwarding by re-writing the Request-URI (easiest way to
do this except for 30x). a at example.com forwards to b at example.com
forwards to c at example.com. The SIP proxy of example.com sees the request
three times in different stages. In your view, would every stage have to
have a dialog assigned?

I don't actually want my proxy to be dialog aware. Only makes
reliability more difficult (more stuff to replicate).

> > 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.
> >   
> So the few lucky one that have used SER long enough know how to do it...

Well, the details of NAT traversal are one of our trade secrets.  Which
means that getting this right _is_ a big deal. It depends on your very
specific setup, the devices and networks involved and a lot of
twiddeling. There just is not a single truth here. You have to make
compromises etc.

There is a basic scheme to do things which is explained somewhere on
iptel.org. But because NAT traversal depends on so many things I need
the option to change stuff. And again, I don't wanna do this in code.

> No, this should be core functionality if SER would claim NAT traversal.

Well, you have to wait for outbound, anyways. Assuming that it will ever
get finished.

> > 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.
> >   
> indeed... so are you saying that we need a fork to be heard if we want
> more than you do? Isn't there a way to have both?

If that way includes taking away the flexibility of current SER: No.

Regards,
Martin