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

[Jiri Kuthan]

At 11:24 17/07/2007, Nils Ohlmeier wrote:
>On Tuesday 17 July 2007 10:24:56 Jiri Kuthan wrote:
>> At 16:18 16/07/2007, Klaus Darilion wrote:
>> >Martin Hoffmann wrote:
>> >> 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.)
>
>I assume the authors were not so much concerned about adding new bindings 
>during a transaction, because I can not see any harm in sending an ACK or 
>CANCEL to a new binding which hasn't received the INVITE.
>But if the binding for the original INVITE disappeared (expire, or was 
>removed), then a non-2xx ACK could pontentially do not reach its target 
>(which is not a big harm either, it just causes lots of retransmissions).

a true case indeed, still like the other not a BIG issue I think.

> But 
>if a CANCEL is not forwarded to its target that is not nice (allthough the 
>UAC would have to send a BYE anyway if it would receive a late 200 for this 
>INVITE, and a non-200 reply would result in retrnasmissions - see above).

how likely it is that a phone being rung up is suddenly re-registered at
a different location?

perhaps we would be able to find even more cases, but without explicitely
doing that I think they would be marginal and your conclusion is notwistanding
the completeness of a marginal-error-catalogue holding right.

-jiri


>But I agree that this seems to be an overspecified scenario were I would tend 
>to ignore the spec.
>
>Just my 2 cents
>  Nils



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