Bob Thanks for your answers. Your explanation of why the stateless UAS will not have to handle a CANCEL offered the perspective that it cannot happen with a compliant UAC. My point was, though, that from a UAS perspective, a CANCEL for a statelessly processed request will not find a matching transaction in the UAS and it would send a 481, rather than "ignoring" it, as the spec mandates (MUST ignore CANCEL).
It is a minor nit, anyway, but it seems to be an unnecessary incoherence in the rfc. Venkat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bob Penfield Sent: Tuesday, July 16, 2002 6:50 AM To: Arunachalam Venkatraman; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] rfc3261 - Stateless UAS ----- Original Message ----- From: "Arunachalam Venkatraman" <[EMAIL PROTECTED]> > In 8.2.7 Stateless UAS Behavior > > o A stateless UAS MUST ignore CANCEL requests. > > o To header tags MUST be generated for responses in a stateless > manner - in a manner that will generate the same tag for the > same request consistently. For information on tag construction > see Section 19.3. > > Questions: > 1. Why should a stateless UAS ignore CANCEL? I would expect it to respond > with a 481he CANCEL. It is because the stateless UAS is not allowed to send a provisional response, and the UAC is not allowed to send a CANCEL unless it has received a provisional response. > 2. Why does a a stateless UAS need to generate the same TO tag? If the > request retransmits and the response has a different tag, it will only > appear (to the uac) to have forked. > Since the tag is just a gloablly random quantity and is not a hash of the > request parameters, it will not be the same. The stateless UAS MUST generate identical responses for identical requests, which includes the to-tag. Even though the UAS is stateless, the behaviour seen be the UAC should be the same as if the UAS was stateful. I think its a bit messy if the UAC thinks the request has forked when it really has not. Since the UAS is stateless, there can not be a dialog created by the transaction. Thus a UAS would only be stateless when responding to requests that do not establish a dialog, or when sending a non-success (non-2xx) response to the request, for example, when it issues a challenge response for an unauthenticated request. cheers, (-:bob _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
