Subject: Re: CANCEL -- do I finally understand??

From: "Scott Petrack"<[email-masked]>
Date: Sat, 4 Jul 1998 22:48:50 +0200

From: Scott Petrack@VOCALTEC on 07/04/98 10:48 PM

Is the following correct:

A caller which sends a CANCEL really must also send a BYE afterwards if the
intent is to terminate the call. There may be UAS which responded 200 OK
out there which the client does not yet know about. So sending a CANCEL may
be a useful optimisation, but the user client will have to send a BYE as
well if the intent is that "never mind, I didn't really want there to be a
call at all."

Here is some text for the spec:

"The CANCEL method is available so that clients tell SIP proxies to cut
short searches for new user agent servers. If a caller wishes to terminate
a call in addition to cancelling searches for user agent servers, the
caller's client MUST send a BYE in addition to the CANCEL.

A User Agent Server which has responded to the CANCELed request with a
definitive response MUST return a 200 OK to a CANCEL, but otherwise MUST
NOT change call state.
A user agent which has not responded to the CANCELed request with a
definitive response SHOULD stop processing the original request and return
call state to before the receipt of the original request if possible."

----------------

About CANCEL-ing other methods, I would love to be able to cancel BYEs --
how many times have I started to hang up a call, and the immediately
regretted it, and in vain tried to quickly "cancel" by picking up the
phone. Of course, CANCELing the BYE can not be guaranteed to work, but if
it did it would be nice.

Mark's rules seem to say that if a User Agent Server gets a CANCEL to an
INVITE before it has done any processing and before it has issued any
response, it is reasonable for the UAS to just pretend that the INVITE
never arrived. So I think that the same should be true for a BYE or any
other method: if a UAS gets a CANCEL to a BYE before it has done any
processing and before it has issued any response, the UAS should just
pretend that the BYE never arrived. The client can't be guaranteed that it
will work, but it's a nice feature.

Finally, do we need to outlaw CANCEL-ing CANCELs??

----------------

BTW, in my example:

(Scott wrote:)
>>If this is the rule, then what happens if things happen in the following
>>order:
>>
>>1. Client sends INVITE to server.
>>2. Server responsds to INVITE with 200 OK.
>>3. The 200 OK response to the INVITE gets lost.
>>4. Client sends CANCEL right after sending INVITE.
>>5. Server responds to CANCEL with 200 OK.
>>
>>The client now thinks that the call was CANCELed, and the server
>>now thinks that the call is in session. Both sides are perfectly
satisfied,
>>but disagree rather violently on the state of the call. Is this a
problem?

(Mark answered:)
>I don't believe it's a problem.  This can only happen when the
>responder sending 200 to the INVITE is not the first responder to send
>a definitive response.  If no-one else had sent a definitive response
>(2xx or 6xx) then the client wouldn't send a CANCEL.  If it wanted to
>hang up it would have sent a BYE instead.

To clarify my example, the client sent an INVITE and then immediately
decided "never mind" (i.e. CANCEL). The client received no responses
between them.  It sent an INVITE, then sent a CANCEL, and then received an
OK to the CANCEL. The user agent server, on the other hand, received an
INVITE, responded 200 OK to it. Then the user agent server got a CANCEL, to
which it also responded ok.

According to Mark's rules, since the UAS sent a 200 OK to the INVITE, the
CANCEL has no effect. When the UAS receives no ACK for the 200 OK it sent
to the client for the INVITE, the UAS will retransmit the 200 OK for the
INVITE, and at this point the client will have to send a BYE.

So all that I was missing before was that in addition to sending a CANCEL
the user must also send a BYE.

(Mark also wrote:)
>- 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).

(Jonathan answered:)
>CANCEL is *not* used to change call state at both ends.
>....
>As Mark points out, it is an optimization.

This is the sort of thing that confused me. If CANCEL "cancels a call that
is currently being set up", then surely it might change the call state at
both ends. (It will certainly do so for example if the client sends INVITE
and then CANCEL to the UAS before the UAS ever responds).

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 05 Jul 1998 10:05:16 +0200

> well if the intent is that "never mind, I didn't really want there to be a

Close, but not quite. If all you want is terminate the call, you don't
need a CANCEL at all - just send a BYE to begin with. CANCEL allows you
to CANCEL any *incomplete* calls, typically after you've gotten all the
answers you want.

> phone. Of course, CANCELing the BYE can not be guaranteed to work, but if

This agrees with my earlier note on this topic.

> Finally, do we need to outlaw CANCEL-ing CANCELs??

You can't really CANCEL a CANCEL anyway, since CANCELs don't have their
own CSeq.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jul 1998 17:40:32 -0400

> and then CANCEL to the UAS before the UAS ever responds).

Sorry to confuse you; my point was that a CANCEL message doesn't affect
the UAS's view of the call state once it has responded.

-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