Additionally incase "immediately" did not mean "immediately after receiving a provisional response"...
RFC3261 section 9.1: "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Thursday, May 08, 2008 11:02 AM > To: Srinivas > Cc: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Sip-implementors] Regarding CANCEL behaviour > > > > Srinivas wrote: > > Hi All, > > I have a query on the behaviour of a UAS when it > receives CANCEL. > > We are using an UAS which says, they don't support the > CANCEL method. First of all, is it ok if the UAS doesn't > support CANCEL? > > > > The problem is, when I send an Invite to the UAS and a CANCEL > > immediately, I expect a 487 for the INVITE. But this UAS is > sending a 200 response, after dumping the CANCEL. Is this > behaviour ok from the UAS side? If so, how should be the UAC > behaviour in this case? > > It seems that the UAS is supporting CANCEL (its not sending a > 405), but not in the way you wish. > > There is always the potential of a race - with the CANCEL > arriving too late to be stopped. It is legal to respond with > a 200 to the CANCEL and then not actually cancel the request. > In fact this is what will typically happen if you attempt to > cancel non-INVITE requests. > > Its not very nice if the UAS acknowledges the CANCEL and > continues to send provisional responses to the INVITE, but > AFAIK it isn't illegal. > And it doesn't sound like that is your case. > > You always must be prepared to receive a 200 for a request > you tried to cancel. In that case, for an INVITE, you will > probably want to send a BYE. And in fact you must be prepared > to receive *more* than one 200 (on different dialogs) for an > INVITE even if you have attempted to cancel it. > > Paul > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
