Subject: CANCEL -- I'm totally confused

From: "Scott Petrack"<[email-masked]>
Date: Wed, 1 Jul 1998 14:30:20 +0200

From: Scott Petrack@VOCALTEC on 07/01/98 02:30 PM

Draft 7a.txt says:

Once a user agent server has received a  CANCEL, it MUST NOT issue a
   2xx response for the cancelled invitation.

A redirect server or user agent server returns 200 (OK) if the Call-
   ID exists and 481 (Invalid Call-ID) if not, but takes no further
   action. In particular, any existing call is unaffected.

Uh, doesn't the second sentence contradict the first?

What does the user agent return when it receives a CANCEL  for a call with
an existing Call-ID...
     ...in the case when the server previously returned 200 OK and the call
is in progress?
     ...in the case when the server previously returned 180 RINGING and has
never sent 200 OK?

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Jul 1998 09:33:20 -0400

> Uh, doesn't the second sentence contradict the first?

No. The idea is that CANCEL prevents further call acceptances from being
issued, but does not affect any existing 200 OK's which have already
been sent. 

>      ...in the case when the server previously returned 200 OK and the call

It returns a 200 OK to the CANCEL.

>      ...in the case when the server previously returned 180 RINGING and has

It also returns a 200 OK to the CANCEL, and must not send a 200 OK in
response to the original INVITE.

As both the CANCEL and INVITE have the same Call-ID and CSeq number, the
responses are distinguished by means of the method tag in the CSeq
header.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Mark Handley <[email-masked]>
Date: Wed, 01 Jul 1998 10:24:13 -0400

>>    action. In particular, any existing call is unaffected.

I'm not convinced the draft expresses CANCEL semantics clearly enough.
Let me see if I can summarise what I believe the rules are.  If we
agree this is the intention, then we can check that the draft actually
specifies the intention.

- when a SIP node sends a request, it expects to get back a response
  to all methods except ACK.  (There's no need with ACK because the UAS
  regenerates the response that triggers the ACK).

- CANCEL is unusual in that it can be originated both by UACs and by
  proxies.  Other requests are only generated by UACs.  In general
  it's generated by anyone that needs to stop further action being
  taken on any outstanding request.

- CANCEL generates a response.  The response it generates is either
  "200 OK" or "481 Invalid Call ID" depending _only_ on whether the
  call-ID is known by the responder.  The exception is if the CANCEL
  was multicast, in which case it does not generate a response to
  avoid implosions.

- SIP nodes that hold state generate a response to CANCEL.  These may
  either by a UAS or a stateful proxy.  Stateless proxies (those that
  relay deterministically and don't fork) do not need to generate a
  response to CANCEL because the CANCEL is passed straight through
  like all other requests.

- CANCEL effectively travels stateful-hop by stateful-hop.  On
  receiving a CANCEL, a proxy with callid state returns 200 OK and then
  originates its own CANCEL requests to downstream servers to which it had
  previously send the request being cancelled.  Responses to these new
  CANCEL requests don't propogate back towards the UAC because they
  were _originated_ by the proxy and so don't carry the full Via path
  that would be needed to get them back to the UAC.
	
- CANCEL cancels a call that is currently being set up.  It has no
  effect whatsoever on a UAS that has already send a 200 response to the
  INVITE (except to generate a 200 response to the CANCEL).  Thus a
  UAS that returned 200 to the INVITE but hasn't yet received an ACK
  would continue to resend a 200 response to the INVITE.  However a
  UAS that has not sent a 200 response to the INVITE is prevented from
  doing so in the future (treat this as the caller hung up).

- Servers generating reponses to the INVITE with codes of 300 or
  ngreater stop their response retransmission and clear call state
  when they get a CANCEL.

- 200 responses to INVITE and 200 responses to CANCEL are
  distinguished by the method in the Cseq header field, so there is no
  ambiguity.

I think that's it.  Henning, Eve, Jonathan, do you agree this is the
correct behaviour?

If so, does the draft say this clearly enough?

Mark

---

From: Eirik Maus <[email-masked]>
Date: Wed, 01 Jul 1998 16:37:20 +0200

>    2xx response for the cancelled invitation.

I thought this meant that no 2xx Response should be sent for the
INVITE-Request after reception of a CANCEL (and made no statement about
responses to CANCEL). 
This makes sense with the latter case below.

>      ...in the case when the server previously returned 180 RINGING and has

In my understanding the Server, in the latter case, should somehow stop
the ringing and return 2xx on the CANCEL. No further Responses should be
returned on the INVITE. 

What action that should be taken in the former case is unclear, however. 
A Redirect Server should not have returned 2xx on INVITE (if calling
through a RS is OK, then the RS is a Proxy). A User Agent returning 2xx
on INVITE indicates that the callee has "picked up the phone handset".

It is obvious that the message CANCEL (caller "putting on the phone
handset") has been sent before he noticed the callee "picking up the
handset" (2xx on INVITE).
The message is (thinking loudly) illegal in that state (a BYE should be
sent), or else BYE and CANCEL are equivalent. 
As the Client may have sent the CANCEL while the 2xx-response was
"travelling along the wire", it is a hard judgement to say the CANCEL is
illegal. It clearly wasn't at the time it was sent (at least the client
couldn't know).

But:
The caller has "put on the phone handset". 
So, he is no longer a part of the session.
So, he is neither speaking nor listening.
So, does he really care what kind of Response that was given?

The question is then: 
How should the callee be notified that the caller doesn't want to speak
to him after all?
INVITE in the opposite direction?

Eirik Maus
Norwegian Computing Center /IMEDIA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Jul 1998 10:54:35 -0400

>   distinguished by the method in the Cseq header field, so there is no

This distinguishing is necessary since the CANCEL and INVITE contain the
same CSeq number and CalliD. This is the case even if a UAC initiates
the INVITE, but a proxy initiates the CANCEL. Using the same
Call-ID/CSeq number allows a server to determine which transaction is
being cancelled by the CANCEL.

> I think that's it.  Henning, Eve, Jonathan, do you agree this is the

Yes. Two more clarifications, though: 

1. what happens if a CANCEL is sent referencing a non-INVITE
transaction? I think the same rules apply.

2. The -07a specification says that a CANCEL is forwarded by a proxy
only on branches which are still pending. I think a CANCEL should also
be sent on any branch which has returned a 200 OK response as well, as
more 200 OK's may still arrive along that branch. 

> If so, does the draft say this clearly enough?

Probably some clarification text (along the lines of your last email)
would be good.

-Jonathan R.

---

From: Mark Handley <[email-masked]>
Date: Wed, 01 Jul 1998 11:09:26 -0400

>transaction? I think the same rules apply.

The same rules would apply for other methods except ACK and BYE.  It's
not clear that CANCEL is meaningful for REGISTER, but I see no reason
to to prohibit it because that would just add unnecessary rules.

>more 200 OK's may still arrive along that branch. 

My understanding was that the 200 response to the INVITE would have
triggered any forking proxies on that branch to send CANCEL, so
there's no need to send another CANCEL that way.  This is specified in
11.4 under the description of 2xx responses.

Cheers,
	Mark

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Jul 1998 11:14:29 -0400

> to to prohibit it because that would just add unnecessary rules.

I see why it doesn't apply ACK, but why not BYE? 

> 11.4 under the description of 2xx responses.

Right, forgot about that. Thanks.

-Jonathan R.

---

From: Mark Handley <[email-masked]>
Date: Wed, 01 Jul 1998 11:36:40 -0400

>I see why it doesn't apply ACK, but why not BYE? 

In terms of protocol mechanisms, it wouldn't break anything to send a
CANCEL for a BYE request.  But in terms of protocol semantics, it just
doesn't make sense - BYE terminated the call.  CANCEL basically says
that if you haven't succeeded yet, don't bother anymore.  BYE says
don't bother anymore regardless of any previously success.  BYE
cancels all previous requests.  CANCEL can't add to this, so it makes
no sense to send it.

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Jul 1998 12:41:46 -0400

> cancels all previous requests.  CANCEL can't add to this, so it makes

Since we may add other request methods in the future, having a generic
"cancel this request" mechanism seems useful. Thus, CANCEL cancels the
request (typically, INVITE), not the pending call [the spec needs to be
clarified in this regard]. In the case of INVITE, this is the same
thing, in the case of REGISTER, it is not. CANCEL is an "ooops, I
changed my mind" type of request, in my view. In most cases, the BYE
will succeed immediately, so the CANCEL doesn't have much chance to do
anything useful, but restricting the usage doesn't seem to serve any
purpose beyond generating yet more special cases.