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

From: Romel Khan <[email-masked]>
Date: Wed, 31 Oct 2001 13:15:08 -0500

Hi,
It's logical and ok for billing to have nothing to do with bis-05, but
service providers will be the ones to get stuck with any possible billing
repercussions from these requirements.

By the way, what is the probability that, using UDP, INVITE will be received
after CANCEL? I assume a very small percentage of the time. Therefore, it
would be preferrable that CANCEL be sent right away rather than consume
resources by waiting for provisional responses for a moot reason. How about
change "CANCEL must" wait for provisional response to "CANCEL should".

Or how about a new procedure to handle the small number of cases that CANCEL
may be received before INVITE: If 481 is received for a CANCEL, then the
INVITE request that the CANCEL is trying to Cancel will be cancelled. And
then apply a procedure related to call leg does not exist to the received
provisional and final responses for the INVITE.
(This probably is not consistent with current SIP philosophy of dealing with
transactions & responses, but food for thought.)

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 11:08 AM
To: Romel Khan
Cc: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'IETF SIP Mailing
List'; Jonathan Rosenberg
Subject: Re: [Sip] Bis-05 question: CANCEL

Hi,

Romel Khan wrote:
> 
> So the following scenario can happen with SIP bis 05, right?
> 
> A caller makes a call. An Invite is sent out. Caller hangs up right away
> before any provisional response comes back. So a CANCEL is not sent
because
> provisional response was not received. Callee starts ringing although
caller
> has already hung up (very very bizarre!). 180 is sent back but gets lost.

In the meantime, the INVITE is being retransmitted until the 100 Trying
arrives. In a typicaly scenario this will happen within one second.

> Callee picks up although caller is gone and a 200 OK is sent back (another
> very bizarre situation).
> Is it documented in SIP bis05 that the UAC will know to send a BYE in this
> scenario after receiving 200 OK right away and how can it be made sure
that
> the caller, who may be long gone, will not get billed?

Billing does not have anything to do with bis-05, and yes, it is
documented that CANCEL does not affect established dialog and that they
should be shut down using BYE.

> How will fast-connects be handled (UAS sends 200 OK after receiving
Invite,
> and no prov. response sent)?

Established dialogs are terminated using BYE.

Regards,

Gonzalo

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 31 Oct 2001 21:02:16 +0200

Hello,

> change "CANCEL must" wait for provisional response to "CANCEL should".

Don't you undestand that what the harm that you can produce by being
unable to hang up a call because the CANCEL made it before the INVITE is
much higher than having to wait for a provisional response?

About the chances of a CANCEL arriving before the INVITE, you only need
one single message lost (the first transmission of the INVITE) and the
caller hanging up in less than half a second... not a so strange
scenario, I believe.

> INVITE request that the CANCEL is trying to Cancel will be cancelled. 

Jonathan and I have already explained several times in this thread that
this causes DoS attacks.

Regards,

Gonzalo

---

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

Hi,

>much higher than having to wait for a provisional response?

First, maybe I don't get the point, but exactly what "harm" could this
produce?

Second, IF it will be a requirement to wait for the 1xx, then I think it
also must be a requirement to send a 1xx in the first plavce (ie "the
server MUST send 100/18x/whatever as soon as it receives the INVITE").
Otherwise there MAY be cases (if no 1xx is sent) where the UAC can't
terminate the call before it has received the 200 final response...
 
>caller hanging up in less than half a second... not a so strange

Which scenario? Loosing a message, or hanging up in less than half a
second? :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 01 Nov 2001 00:06:21 +0200

Hi,

> First, maybe I don't get the point, but exactly what "harm" could this

If you do not think that not being able to hang up a call is harmful
then we live in different worlds.

> also must be a requirement to send a 1xx in the first plavce 

bis-05 says that the server transaction MUST send a 100 Trying unless
another response will be sent in 200 ms.

(ie "the
> Which scenario? Loosing a message, or hanging up in less than half a

Both at the same time.

Regards,

Gonzalo

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 31 Oct 2001 19:44:53 -0500

> First, maybe I don't get the point, but 
> exactly what "harm" could this produce?

Otherwise a UAS could continue to ring 
and/or stream ringback/voice for longer 
amounts of time.  However since this 
situation still can occur for UAC and/or 
proxy failure, it only partially solves 
the problem.

I think that the bis-05 made an attempt
to address some of the race conditions
that can occur in SIP.  It is now up
to the SIP community to provide comments.

One alternative is to queue the CANCEL
at UAS/proxy waiting for the associated 
request.

Another alternative is for SIP devices 
to actually start using the Expires 
header and/or the UAS to remain in 
ringing for a "maximum" time.  I assume 
that most UAS implementations will 
not allow a call to remain in alerting
state any longer than 3 minutes unless
they are trying to use 182 type 
functionality.

> as it receives the INVITE").

Section 17.2.1 already mentions 
"MUST generate 100 response" 
if the UAS can't respond within 200ms.

> received the 200 final response...

Yes.  A malicious server could intentionally
delay sending a 1xx in an attempt to help 
produce a billing situation by delaying
the ability for the originator to CANCEL
the request.