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

[Jiri Kuthan]

At 16:18 16/07/2007, Klaus Darilion wrote:


>Martin Hoffmann wrote:
>> Jan Janak wrote:
>>> Martin Hoffmann wrote:
>>>> Klaus Darilion wrote:
>>>>> sl:
>>>>> (A) loose_route=true,  --> just forward
>>>>> (B) loose_route=false, --> lookup()*, forward
>>>>> (C) loose_route=true,  --> just forward
>>>>> (D) loose_route=true,  --> lookup()**, forward
>>>> Just a quick reminder that lookup() and forward don't go together. A
>>>> stateless proxy has to make the same decision for the same message (aka
>>>> re-sent request). Since entries in usrloc expire, there is a good chance
>>>> that a resent will be send somewhere else.
>>>   What makes you think that stateless proxies have to make the same
>>>   decision for the same message?
>> 
>> RFC 3261, section 16.11:
>> 
>> |    A stateless proxy MUST follow the request processing steps described
>> |    in Sections 16.4 through 16.5 with the following exception:
>> |
>> |      o  A stateless proxy MUST choose one and only one target from the
>> |         target set.  This choice MUST only rely on fields in the
>> |         message and time-invariant properties of the server.  In
>> |         particular, a retransmitted request MUST be forwarded to the
>> |         same destination each time it is processed.  Furthermore,
>> |         CANCEL and non-Routed ACK requests MUST generate the same
>> |         choice as their associated INVITE.
>
>That would mean that doing lookup() in a stateless proxy is practically 
>not allowed.

That's indeed what Martin suggested. The spec is vague in this, the idea in it
is that retransmissions don't get 'forked' if usrloc entry changes. That 
basically means there cannot be a statelss proxy unless it never changes
its routing data :-) Sound a bit like an overstandardization to me. (I hope
I don't offend those on mailing list, who consider RFC3261 too axiomatically.)

If one had a well articulated case for stateless proxy with userloc (does anyone 
have such?), I would not hesitate to do it. We have done such things in the
past, note for example that in default configuration SER's registrat is
stateless. This is tremendously important because of performance implications.
Nevertheless, if you look at the RFC3261, it actually says that the UAS
should be stateful in such case. Here we traded a minor consistency issue
against a significant performance gain. (still we preserve the 100%
bible-compliant option by the way of configuring stateful registrar script)

-jiri




--
Jiri Kuthan            http://iptel.org/~jiri/