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

[Greger V. Teigre]

Nils Ohlmeier wrote:
> 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.
>   
Right, but I was referring to the case where the ruri does not point to 
you, but (most probably) a PSTN GW.
>   
>> 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.
>   
I assume you here implicitly mean that they cannot be implemented 
technically correct for both stateful and stateless? I assumed in my 
suggestion that we can make an rr param work.
> If you use has_to_tag(), fine you should know what you are doing. But 
> in_dialog() without being dialog statefull promisses to much.
>
>   
Right, so maybe in_dialog should be found in tm?
>> 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?
>
>   
Indeed.
>> 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!
>
>   
Yes, "corner case" was maybe misphrased. My point was that it does not 
occur in every setup.
>> 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.
>   
Isn't uri params implemented differently in 2.0? Where the actual params 
are added before relaying (based on avp)?

g-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070717/338b362a/attachment.htm>