[asterisk-dev] [Code Review] sip: ignore CANCEL request after having already received final response to INVITE

[David Vossel]

----- Original Message -----
> From: "Klaus Darilion" <klaus.mailinglists at pernau.at>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Cc: "David Vossel" <dvossel at digium.com>
> Sent: Wednesday, June 9, 2010 6:35:30 AM
> Subject: Re: [asterisk-dev] [Code Review] sip: ignore CANCEL request after having already received final response to
> INVITE

> Am 08.06.2010 22:35, schrieb David Vossel:
> >
> > ----------------------------------------------------------- This is
> > an automatically generated e-mail. To reply, visit:
> > https://reviewboard.asterisk.org/r/697/
> > -----------------------------------------------------------
> >
> > Review request for Asterisk Developers.
> >
> >
> > Summary -------
> >
> > RFC 3261 section 9 states that a CANCEL has no effect on a request
> > to a UAS that has already given a final response. This patch checks
> > to make sure there is a pending invite before allowing a CANCEL
> > request to be processed, otherwise it responds to the CANCEL with a
> > "481 Call/Transaction Does Not Exist".
> 
> I just wonder if this is necessary at all? IIRC the response code for
> the CANCEL is totally irrelevant. Relevant is only the response code
> of the INVITE transaction.
> 
> If a client receives a 200 OK on the INVITE, the dialog is established
> - regardless if the client sent CANCEL and received any responses.
> 
> 
> regards
> Klaus

The response code may be irrelavant, but the response is not.  A response must be provided for the CANCEL else it will be retransmitted, and if we are going to respond, it should at least make sense.  In this case, a 481 makes sense to me because the transaction that is trying to be canceled is already completed.

David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev