Subject: [SIP] CANCEL problem ??

From: Bertil Engelholm <[email-masked]>
Date: Tue, 09 Jan 2001 13:31:07 +0100

Hi,

I have tried to implement CANCEL handling in our proxy
and by doing so I have come up with a problem I don't
know how to handle.

The way I have understood CANCEL is that it's sent hop
to hop which means when a proxy receives a CANCEL for
an ongoing transaction the proxy will send a 487 response
to the original request and then send a 200 OK response
to the CANCEL. The proxy will also send a CANCEL to all
branches it has created due to the original transaction.

I also interpret the specification so that if I have
already sent a final response to the original request I
should not cancel the transaction but still send a 200
response to the CANCEL request ??

The problem I don't know how to handle is the following :

------   ------   ------   ------
| Ca |---| P1 |---| P2 |---| Cb |
------   ------   ------   ------

If Ca sends e.g. an INVITE to Cb which is proxied through
P1 and P2. Cb returns 180 RINGING back to Ca.
Ca now sends a CANCEL to cancel the INVITE. The CANCEL 
reaches P1 which sends a 487 to the INVITE and a 200 to
the CANCEL and then sends a CANCEL to P2. If Cb answers
the call during this time a 200 OK is on it's way from
P2 to P1. So what should P1 do when it receives a 200
OK on the original request instead of a 487 ?? 
Should P1 ACK the 200 OK to avoid retransmission ??
What if the 200 response was lost between P2 and P1 ??
In case of a INVITE it will be retransmitted but what
if it's another type of request that was cancelled ?

Since P2 thinks the transaction is completed it will 
not do anything on the CANCEL except sending a 200
response to the CANCEL. This means that Ca and P1 
thinks the transaction is cancelled but P2 and Cb
thinks it still is going on ?? This also means that 
they will retransmit the 200 OK for quite a while.

Another question related to this case is when the
user at Cb hangs up can Cb cancel the transaction ?
Or is it only the side that originated a transaction
that can cancel it ??

/Bertil
 
-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 9 Jan 2001 12:48:10 -0000

> branches it has created due to the original transaction.

Almost.  The proxy should do as you say; however, it should
not send the 487; rather, it should wait for responses on
all branches as it normally would do.

There is an issue here, however, if a proxy happens to have
an "older" (i.e., non-487 aware) server at the end of one of
its branches.  In this case, it will probably not get a final
response to the INVITE (or whatever).  A solution to this is
to start a timer when a CANCEL has been issued, and if this
timer expires, then "imagine" that you got a 487 along that
branch.

The difficulty is what value to use for the timer.  There
was some discussion about this a while back. Have a look at
the thread entitled:
"CANCEL - response sequence issue (again)"
(it was mid-late October).

> response to the CANCEL request ??

Yup.

> The problem I don't know how to handle is the following :

Although what I said above already addresses this problem,
in any case, 200s (to INVITEs) should _always_ be forwarded,
and they certainly should not be ACK d by proxies.

> Or is it only the side that originated a transaction

Only the originating client, and intermediate proxies
(in the downstream "direction") can CANCEL.

HTH,

 - Jo.

---

From: Bertil Engelholm <[email-masked]>
Date: Tue, 09 Jan 2001 14:55:29 +0100

> (it was mid-late October).

OK, I have read the thread and I think I understand better know.
I thought that the 200 response to CANCEL meant that the CANCEL
was executed OK. From what you are saying and the above thread
I get the impression that the 200 OK to CANCEL is just a 
confirmation that you have received the CANCEL request. It's 
the final response to the original request that tells you if 
the cancelling actually was done or not. 
Is this correct understood ?

/Bertil

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 11 Jan 2001 09:07:50 -0000

> Is this correct understood ?

Sounds about right to me.  The thing is with CANCEL it doesn't
really matter what the response code is -- once it has been
acknowledged, what else can you realistically do?  (If you get
a non-200 -- say a 481 -- it means that either you messed up the
CANCEL request, or the responding server is a bit dull; in any
case, it's not realistically a recoverable situation.)  As far
as I'm concerned, a (final) response to a CANCEL only serves to
stop message retransmission.

Cheers,

 - Jo.