17 Jul
2007
17 Jul
'07
5:24 a.m.
On Tuesday 17 July 2007 10:24:56 Jiri Kuthan wrote:
At 16:18 16/07/2007, Klaus Darilion wrote:
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
Martin Hoffmann wrote:
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.) 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.