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

[Nils Ohlmeier]

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). 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).

But I agree that this seems to be an overspecified scenario were I would tend 
to ignore the spec.

Just my 2 cents
  Nils