Subject: Re: SIP: CANCEL request/2xx-response to INVITE

From: John Hearty <[email-masked]>
Date: Thu, 03 Jun 1999 15:01 -0500 (CDT)

While this problem needs to be resolved, and it appears there is concensus
for the solution, I would like to reiterate what Lars brought up. 
If a caller truly wishes to drop the call, a BYE should be sent, not
a CANCEL.  This eliminates all these problems.  If they just want to
drop potential legs that have not responded back yet, a CANCEL is in
order.  My impression of the original intent of the CANCEL was for
forking proxies to drop legs that didn't provide a final response yet.
It seems unlikely a UAC would normally want to send a CANCEL, as it
wouldn't know if a request was forked or not, although sending a CANCEL
is allowed.  Perhaps a recommendation for UACs to send BYEs in this
scenario and avoid sending CANCELs should be added to a best practices
RFC?

John Hearty
MCI Worldcom

Date: Fri, 28 May 1999 02:38 -0500 (CDT)
From: Lars Berggren <[email-masked]>
Organization: Intertex Data AB
To: Jeff Mark <[email-masked]>
CC: "Adam B. Roach" <[email-masked]>,
    [email-masked]
Sender: [email-masked]
Subject: Re: SIP: CANCEL request/2xx-response to INVITE

Jeff Mark wrote:
....
> 
> Now since the proxy is acting as both the UAS and UAC it appears from
> reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
> rule.  Since the proxy "implements the server state machine when receiving
> requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
> noted in 12.3 applies to the client state machine of the proxy and was
> intended (from my reading) on preventing the proxy from ACKing an INVITE
> response.  So, if we abide by the server state machine, the proxy MUST NOT
> forward the INVITE 200 response (4.2.5).  Now since the proxy already
> accepted the cancellation of the call, it seems appropriate it should deal
> with the INVITE 200 it receives in step 5 by sending the BYE itself.
> Although this behavior is not mentioned in the spec, it seems like an
> appropriate action to take since the transaction has been canceled.
> 
> Perhaps the chain of messages in your example is the correct way to do
> things and the way the spec authors intended, but I think there needs to be
> a clarification on how to respond to a CANCEL if a server has already
> responded to the INVITE.  It just seems to me that sending a CANCEL 200
> response _after_ sending an INVITE 200 response is not consistent with the
> meaning of CANCEL.  Taking your proxy example I think the following exchange
> of messages would still be consistent with the spec.  In step 8 the proxy
> generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):
> 
>    UAC                       PROXY                       UAS
>  1  |----------INVITE--------->|                          |
>  2  |                          |----------INVITE--------->|
>  3  |----------CANCEL--------->|                          |
>  4  |<-------CANCEL 200--------|                          |
>  5  |                          |<-------INVITE 200--------|
>  6  |                          |----------CANCEL--------->|
>  7  |                          |<-------CANCEL 403--------|
>  8  |                          |------------BYE---------->|
>  9  |                          |<---------BYE 200---------|

When CANCELing an INVITE request it doesn't mean that the UAC wants to
terminate the call. It means that the UAC wants to terminate all
branches which have not sent a 2xx response. If the UAC wants to
terminate the call it sends a BYE instead of the CANCEL.

I interpret the part in the rfc that Igor quoted as that there are only
two possible final reponses to a CANCEL, 200 and 481. Is this correct?

A 200-CANCEL means that the transaction exists at the server and that it
will prevent all user agent servers that have not sent a 2xx to send
them. It does not mean that the original request really was cancelled,
and thus the UAC should still expect that 2xx to the original request
may arrive.

A 481-CANCEL means that the transaction does not exist at the server.

Thanks for the clarifications,
/Lars

Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414