Hi Arunachalam,
Chapter 8.2.6 says:
"o A stateless UAS MUST ignore ACK requests.
o A stateless UAS MUST ignore CANCEL requests."
I guess this is what may confuse one, because the ACK IS ignored, in the sense
that it's "thrown away", while the CANCEL is treated like a CANCEL is always
treated, and responded to like it's always responded to, when a matching
transaction doesn't exist (chapter 9.2 in RFC3261).
Regards,
Christer Holmberg
Ericsson Finland
Arunachalam Venkatraman wrote:
> 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
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
