[Serusers] [Serdev] loose_route behaviour, detecting single Route with myself

Nils Ohlmeier nils at iptel.org
Mon Jul 16 16:53:51 CEST 2007


On Monday 16 July 2007 14:04:31 Greger V. Teigre wrote:
> Ok, let me try to take a step back. This discussion is an example of why
> ser.cfg sometimes seems like black magic for most users. It's very
> complicated to get a generic config that works in most scenarios. What
> we really need to make sure is that people can use the recommended black
> magic in most cases, that it is intuitive how to add their own stuff,
> and that we make it difficult to "break".. phew...
>
> What would a "normal" user like to know in ser.cfg?
> 1. Do I need to process like an INVITE or do I t_relay?
> 2. How do I open or prevent relaying?
>
> Ex. I am sure quite a lot of configs will let an INVITE with a
> pre-loaded Route go through without authentication...

Which is not an issue as long as the RURI points to you. Because then you 
simply route the request to yourself with no Route header any more, and then 
it should be processed like a request without pre-loaded Route.

> I still feel that preloaded_route() and in_dialog() would be simpler to
> understand for most people.

Just to state it clearly: the names of these two function can not be 
implemented technically correct! Thus I would vote at least against the 
names.
If you use has_to_tag(), fine you should know what you are doing. But 
in_dialog() without being dialog statefull promisses to much.

> I agree with Martin that maybe having a 
> separate function checking/removing/failing a pre-loaded route is
> cleaner than letting loose_route() do it.

Ok. I'm still trying to evaluate if this is possible or not. See below for 
more details. But we are talking here about > 2.0 any way, right?

> The problem of "non-2xx ACK with a preloaded route looks exactly the
> same then a 2xx ACK" is a corner-case, and I don't see any solution
> either, than the  suggest uri param in the rr.

Just to make it clear to everybody: this "corner case" occurs in all setups 
with a stateless load balancer and where the INVITE gets challenged!

> So, could we 
> automaticlly add the rr param if and only if the original INVITE is
> forwarded statelessly?

I don't think so, because the rr module has no idea when you call 
record_route() how the request is going to be tramsitted.

I would prefer to have a general option for adding (or not adding) such a 
Route cookie. The only question would be then, what should be the default 
setting for this option.

> The above functions could thus look for the rr param to detect the
> corner-case and thus behave consistently.
> g-)
>
> Martin Hoffmann wrote:
> > Nils Ohlmeier wrote:
> >> On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:

[...]

> >> Sure, they are. But I currently do not really see any option for this
> >> problem.
> >
> > Possibly, the problem is that loose_route() is trying to be smart. Maybe
> > it should be split in two. One function removes the topmost Route if
> > present and pointing to this proxy (it can return false if the Route is
> > all wrong and we can reply 4xx then), another one that allows to check
> > if there is a Route left. The rest is done in config.
> >
> > Without reading 3261 again, I think this can be done in a way compatible
> > with strict routing.

Yes probably it could. The only problem with this approach is that you need to 
store some state between the calls of these two functions.
And I guess it should be allowed to call e.g. functions from the select 
framework in between. I'm assuming for example that would simply check with 
the select framework if their are still route headers present after you 
called the "remove topmost route" function, to see if it is necessary to call 
the second route function. This would mean that the changes of the 
first "remove topmost route" function would have to be applied to the 
message. And you hopefully know that this is not easily possible in SER.
Don't get me wrong. The approach sounds interesting. But currently the 
implementation looks tricky to me.

  Nils



More information about the sr-users mailing list