Subject: Re: CANCEL -- I'm totally confused

From: "Scott Petrack"<[email-masked]>
Date: Thu, 2 Jul 1998 06:47:50 +0200

From: Scott Petrack@VOCALTEC on 07/02/98 06:47 AM

I believe that Mark and Jonathan agree on the rules for CANCEL.

>> 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?
>
>It returns a 200 OK to the CANCEL.

So in this case, the CANCEL has no effect except to generate the 200 OK
response. Nothing is actually CANCELed, correct?

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?

Personally, I would rather that a CANCEL message to a valid call in session
should
return some sort of error response which means "The server understood the
request but  has not canceled the call." A response like 403 Forbidden. It
seems wierd to me to
have a server return a successful OK to a request and then not do anything.
But this may just be some aesthetic problem on my part. If the above
exchange is considered a real problem, however, I would rather change the
rule slightly.

...

>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.

Ah, yes I forgot about the method tag. Maybe for us senile types you could
include in the section on CANCEL in the spec a sentence like this?

---

From: Mark Handley <[email-masked]>
Date: Thu, 02 Jul 1998 12:18:17 -0400

>response. Nothing is actually CANCELed, correct?

Correct.

>disagree rather violently on the state of the call. Is this a problem?

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.

If someone else answered first, then the second 200 OK would get back
to the caller, and it's then up to the caller whether they now send a
BYE, or an ACK and handle the multiway call that results.

>But this may just be some aesthetic problem on my part.

I think it's just aesthetics.  Think of the 200 response from the
cancel as saying "don't send me any more restransmissions of that
cancel".  It simply means it was received.  It does not mean anything
additional.  

Further responses may be forthcoming, but you can choose to ignore
them if you want or send an ACK or BYE if appropriate.  This applies
irrespective of whether you sent a CANCEL because CANCEL is purely an
optimization to allow state to be removed, prevent unnecessary ongoing
searches, and stop the phone ringing when it's no longer desired.

Mark

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Jul 1998 15:17:08 -0400

> disagree rather violently on the state of the call. Is this a problem?

CANCEL is *not* used to change call state at both ends. Rather, it is
used to indicate that a client (or proxy) is not interested in getting
any more responses. As you point out, there may be additional responses
which arrive even after a CANCEL is sent, but they should be minimized
as a result of the CANCEL. As Mark points out, it is an optimization.
Its main purpose is to give proxies a good idea about when it is
reasonably safe to destroy transaction state. Once a proxy receives and
forwards a CANCEL, it knows that it shouldn't receive any responses
except for those already in transit. It can therefore become stateless
(note that a stateless proxy will still forward responses upstream, but
it forwards all responses, including non-200) without causing a major
non-200 implosion problem.

-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