Subject: Re: [Sip] Bis-05 question: CANCEL

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Oct 2001 09:52:10 +0200

Hi,

>>Section 9.1, line 1180 "CANCEL MUST NOT be sent if no provisional
>>response has been received".
>>
>>Why?
> 
>Because of a race condition. Lets say a user sends an INVITE, and then
>immediately hangs up. So, a CANCEL is sent. The INVITE is lost, but the
>CANCEL is not. The CANCEL arrives at the UAS, but there is not a matching
>INVITE. So, a 481 is sent in response to the CANCEL, and the transaction is
>discarded. Then, the INVITE arrives, and is accepted a few minutes later.
> 
>The result is that a loss (or delay) of the original request can basically
>eliminate the effectiveness of the CANCEL.

If the INVITE gets to the UAS AFTER the CANCEL, and starts generating
provisional responses, the UAC can send a new CANCEL.

We have the same situation if the UAS doesn't generate provisional
responses at all. It may accept the INVITE and return 200, so in that
case the UAC will have to ACK/BYE. This is also the case for the
CANCEL/200 race condition mentioned later in the mail.
 
>>If my user dials a number and then hangs up, I want to cancel
>>the invite ASAP.
>Please do not confuse user interfaces with protocols. Of course a user can
>hang up immediately.

The question is: do we really want to add all this "buffering" into the
protocol? We need it for PRACK, and that's bad enough. Isn't it better
to define procedures how these race conditions should be handled
instead, ie by sending CANCEL/ACK/BYE/whatever...?
 
>The restriction on not sending CANCEL until 1xx is a protocol issue. If the
>user hangs up immediately, the UA has to buffer the CANCEL until a 1xx or
>until the transaction times out altogether, due to some error or something.
>I will point out that this is nothing more than implementing an HOL blocking
>scheme to provide sender-side ordering. If SIP were run over TCP, and we did
>not introduce this explicit requirement, but merely stated that all requests
>for a call go over the same tcp connection, we would get exactly this
>effect. Since SIP can't always run over TCP, I need to introduce it here.

I just wonder how a client using TCP is going to handle call setup
situations with PRACKs, COMETs and INFOs....

>>If the destiation is a PSTN number, I don't want it to allocate
>>resources and ring the phone, if at all possible. According to section
>>9.1, it seems that in absence of 100 Trying,
>
>If a server can't offer a final answer in 200ms, its supposed to send a 100
>Trying. Bis-05 firms this, and places transmission of the 100 into the
>transaction layer itself, so that its basically always sent. So, there will
>not be a case of the absence of a 100 trying, at least. I think pretty much
>all stateful proxies I know of send 100 immediately.

Even if the PROXY does send 100, and the UAC sends CANCEL after that, it
still doesn't mean that the UAS is going to receive the INVITE before
the CANCEL, does it (even if they are using the same route from a SIP
application point of view)?

>>Sure the the CANCEL immediately following INVITE might
>>arrive at the UAS before the INVITE. So be it.
>Well, except that it doesn't work. Someone needs to maintain ordering - the
>client or the server. It makes a lot more sense for the client to do it,
>since the burden should, in fact, be on it as the requestor of the service
>(there are DoS attacks opened up otherwise). Furthermore, you can have this
>problem at a proxy in addition to a UAS. The state problem is more
>troublesome there.

I still think that the easiest solution, if the UAC receives a non-487
response to a INVITE it tried to CANCEL, is to simply ACK and BYE(if it
was a 200 OK final response). No buffering at all...
 
>>If you worry about the ordering so much, you might as well worry that the
>>provisional response may get lost or the CANCEl may get crossed with 200 OK.
>Provisional responses are not meant to be reliable in SIP, so there loss is
>not important for correctness. CANCEL/2xx crossing is indeed handled; if
>this happens the UAC sends a BYE.

Exactly! So, why can't it always do so?
 
>There is an additional race condition we have found, which is 2xx to INVITE
>and BYE crossing on the wire. In this case, its a similar restriction - the
>BYE cannot be sent until the ACK has been received. Otherwise, the BYE may
>beat the 2xx, and be discarded since it does not match a call leg.

Again. The BYE may fail, but when the final response to the INVITE is
received the UAC ACK and BYE again. Simple, and no buffering needed...

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Oct 2001 02:26:39 -0500

> -----Original Message-----
> From: Shan Lu [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 4:59 PM
> To: IETF SIP Mailing List
> Subject: [Sip] Bis-05 question: CANCEL
> 
> 
> Hi all,
> 

> the invite
> ASAP. 

> an INVITE can only be
> cancelled AFTER the phone has been rung. I think this is an 
> unnecessary
> requirement.

As I said, this is nothing more than the same ordering we would see with
usage of a persistent tcp connection.

> If you worry about the
> ordering so much, you might as well worry that the 
> provisional response
> may get lost or the CANCEl may get crossed with 200 OK.

> 
> If the rule is there to take care of CANCEL for non-INVITEs, then it
> should say so. In any case, "MUST NOT" is way too strong. 

No, the rule is there primarily for INVITE. I believe the MUST NOT is
appropriate in order to guarantee correctness. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Oct 2001 18:17:39 +0200

Hello,

> provisional responses, the UAC can send a new CANCEL.

Since the first CANCEL was answered with a 481, its retransmisssions
will be also answers with a 481. Basically, if the CANCEL was received
before the INVITE, the UAC wouls not have a way to CANCEL the
transaction. That's why the UAC has to wait until a 100 Trying is
received.

> application point of view)?

Christer, remember that CANCEL is a hop by hop method. Every proxy in
the path waits until it has received the 100 Trying from the next proxy
(or from the UAS) before sending the CANCEL.

Regards,

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 30 Oct 2001 15:17:10 -0500

Hi all,

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gonzalo Camarillo
> Sent: Tuesday, October 30, 2001 11:18 AM
> To: Christer Holmberg
> Cc: IETF SIP Mailing List; Jonathan Rosenberg; 'Shan Lu'
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> 
> Hello,
> 
> Christer Holmberg wrote:
> 
> will be also answers with a 481. 

I don't think it's a retransmission. It's going to be a NEW CANCEL
(cseq.num++).

>Basically, if the CANCEL was received

If you want to wait for 1xx from UAS, you run the danger of waiting a
bit too long. 1xx might just get lost and the next thing you will see is
200 OK. This effectively renders the CANCEL useless.

So wait or not to wait, you have the same risk of nullifying CANCEL. I
don't think one risk is bigger than the other. And not to wait is
obvious simple and clean. 

Shan Lu
sentitO Networks

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 30 Oct 2001 23:47:30 +0200

Hi,

> I don't think it's a retransmission. It's going to be a NEW CANCEL

You should read how CANCEL works in SIP. The CANCEL request has always
the same Cseq as the request being cancelled.

> 200 OK. This effectively renders the CANCEL useless.

If the 100 Trying gets lost you will be retransmitting the INVITE until
you get it.

Regards,

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 30 Oct 2001 16:37:57 -0500

> the same Cseq as the request being cancelled.
So noted.  

> If the 100 Trying gets lost you will be retransmitting the 

Nobody disputes this. But the point here is that a loss or delay of 1xx
may render the CANCEL useless.

Regards,

Shan Lu
sentitO Networks

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 31 Oct 2001 00:22:54 +0200

Hello,

> may render the CANCEL useless.

As I stated previously, if the CANCEL arrives to the server before the
INVITE, the UAC will not have any way to cancel the request. Then it
would have to wait until the INVITE is answered in order to send a
BYE... and this can really take very long.

Therefore, we have to avoid that situation. In order to do that, we can
either buffer at the client side or at the server side. TCP, for
instance, buffers at the server side.

However, we have decided to buffer at the client side because doing so
at the server side creates potential DoS attacks. Upon reception of an
out of the blue CANCEL a server might have to store state waiting for
the matching INVITE. Since this is unacceptable, the only solution is
the one proposed in bis-05.

I hope this clarifies everything realted to this issue.

Regards.

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Tue, 30 Oct 2001 18:06:20 -0500

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Tuesday, October 30, 2001 5:23 PM
> To: Shan Lu
> Cc: 'Christer Holmberg'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg'

Why can't BYE be sent for an early dialog to terminate the dialog?

Shan Lu
sentitO Networks

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 07:40:15 +0200

Hi,

I understand the arguments for buffering. BUT, by waiting for the first
1xx we still don't solve the CANCEL/200 race condition.

Also, consider the following case:

         |------- UAS 1
UAC --- P1
         |------- UAS 2

Now, the UAC sends an INVITE, which gets forked by P1. P1 also sends 100
back to UAC. Then, the UAC decides to terminate the setup, so it sends
CANCEL.

Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL
there.

HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do
that. Instead, the UAS 2 returns 200 OK immedeately. So, what does P1 do
now? Creates a BYE transaction to UAS 2 - and when it receives a
response to that it sends 200 for the CANCEL to the UAC??? This sounds a
little like B2BUA behaviour to me...

AND, the following (easier case) could also have happened in the
scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when P1 sends a
CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? 

1. Create a BYE to both UAS 1 and UAS 2? 

2. Forward the 200 response for the INVITE to the UAC, and sends 487 for
the CANCEL to the UAC?

>Why can't BYE be sent for an early dialog to terminate the dialog?
 
This has been discussed before, and the UAC CAN use BYE to terminate a
dialog, assuming it has received a 1xx with a To header tag.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 31 Oct 2001 09:56:41 -0500

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Shan Lu" <[email-masked]>
Cc: "'Gonzalo Camarillo'" <[email-masked]>; "'IETF SIP
Mailing List'" <[email-masked]>; "'Jonathan Rosenberg'"
<[email-masked]>
Sent: Wednesday, October 31, 2001 12:40 AM
Subject: Re: [Sip] Bis-05 question: CANCEL

> 1xx we still don't solve the CANCEL/200 race condition.

The solution to the CANCEL/200 race condition has always been for the UAC to
be prepared to ACK and BYE if it gets a 200 instead of a 487. There is no
difference here. The UAC must always wait for the final response to the
INVITE.

> little like B2BUA behaviour to me...

Unless P1 is a B2BUA (i.e. maintaining dialog state and CSeq#s for
requests), it cannot send the BYE. P1 must pass the 200-OK back to the UAC.
Now, since the UAC has not received a final response to the INVITE, it must
be prepared to send the ACK and BYE when it gets the 200-OK. This is still
the classic "CANCEL and 200-OK passing on the wire". Their is no special
behaviour required here.

> 2. Forward the 200 response for the INVITE to the UAC, and sends 487 for

Both 200s must be forwarded to the UAC. 487 is not used as a response to a
CANCEL. It is the response to an INVITE when an invite request has been
cancelled. The CANCEL gets an immediate 200 response unless the request
being cancelled is no longer present (then it gets a 481).

> dialog, assuming it has received a 1xx with a To header tag.

Yes, that is true. But that's no reason to send a CANCEL before receiving a
1xx response. The main benefit of BYE for early dialog is terminating
unwanted dialogs when a UAC gets 1xx/2xx responses from multiple UASs.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 19:39:00 +0200

Hi,

>difference here. The UAC must always wait for the final response to the

I KNOW what the solution is. What I am saying is that since we DO have
to THAT case into consideration in any case, we can use the SAME
mechanism if we receive a 200 to an INVITE we have tried to CANCEL - ie
we simply ACK and BYE it.

My point is: does it really matter if the CANCEL reaches the UAS before
the INVITE, OR if the CANCEL reaches the UAS after the 200 has been
sent? In BOTH cases the UAC can use the same mechanism - ACK and BYE.
 
>requests), it cannot send the BYE. P1 must pass the 200-OK back to the UAC.

So, the UAC will receive 200 BOTH for the INVITE AND for the CANCEL,
since the CANCEL did reach UAS 1?

>the classic "CANCEL and 200-OK passing on the wire". Their is no special

I never said that (from a UAC point of view). Again, what I am saying
that we could use the same ACK/BYE mechanism if a CANCEL reaches the UAS
before the INVITE...

>Both 200s must be forwarded to the UAC. 487 is not used as a response to a

Sorry, my misstake. I meant that 200 was sent for the CANCEL, and 487
for the INVITE.

>It is the response to an INVITE when an invite request has been

So, in this case we again receive 200 both for the INVITE and CANCEL,
right?

>1xx response.

Maybe not, but I still don't see a reason why I MUST wait for a 1xx
before I send a CANCEL :) Again, I DO understand the idea behind waiting
for 1xx, but I still think we already have mechanisms to handle
situations that may occur even if we do NOT wait for the 1xx...

Regards,

Christer Holmberg
Ericsson Finland