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

From: Romel Khan <[email-masked]>
Date: Wed, 31 Oct 2001 10:26:52 -0500

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

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

inline

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 11:40 PM
> To: Shan Lu
> Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg'
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> 
> 
> Hi,
> 
> I understand the arguments for buffering. BUT, by waiting for 
> the first
> 1xx we still don't solve the CANCEL/200 race condition.

Yes, we've solved this one. More after the answer to the
scenario below.

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

Its more than a little like B2BUA - P1 cannot generate
a BYE on its own. Once you take that step, you are no
longer talking about proxies.

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

Neither.

The scenario you set up will play out as follows:

UAC            P1             UAS1            UAS2
 |INVITE        |              |               |
 |------------->| INVITE       |               |
 | 100          |------------->|               |
 |<-------------|              |  INVITE       |
 |              |----------------------------->|
 |              | 100          |               |
 | CANCEL       |<-------------|               |
 |------------->|              |               |
 | 200 (CANCEL) |              |               |
 |<-------------| CANCEL       |               |
 |              |------------->|               |
 |              | 200 (CANCEL) |               |
 |              |<-------------|               |
 |              | 487 (INVITE) |               |
 |              |<-------------|               |
 |              | ACK          |               |
 |              |------------->|               |
 |              |              |  200 (INVITE) |
 | 200 (INVITE) |<-----------------------------|
 |<-------------|              |               |
 | ACK          |              |               |
 |------------->| ACK          |               |
 |              |----------------------------->|
 |              |              |               |
 |              |              |               |
 |              |              |               |

CANCEL is hop-hop. All that a 200 means to a CANCEL
is that it got to the next hop, not that something
actually got cancelled. A CANCEL will never recieve
a 487 response (as you suggest in step 2 above. Those
only come in responses to requests that got cancelled.

Now, for the CANCEL 200 race condition - that's 
effectively what you set up with UAS2 above
(leave UAS1 out of the diagram). At the end
of the scenario, UAC knows that
1) The next hop got its CANCEL request, and
2) It didn't get to the far side in time to
   CANCEL the request (since it got a 200 to
   the INVITE).

Everyone is in sync - no crossing problem.

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

_______________________________________________
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

_______________________________________________
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 18:07:36 +0200

Hi,

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

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

> and no prov. response sent)?

Established dialogs are terminated using BYE.

Regards,

Gonzalo

---

From: "Shan Lu" <[email-masked]>
Date: Wed, 31 Oct 2001 11:45:23 -0500

Hi all,

> 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

I am not sure where the one second comes from. Yes, the UAS is required
to send 100 Trying under almost all situations in bis-05. But it does
not guarantee that the 100 Trying will be received by UAC in any time
frame. Yes, the UAC can and will continue to resend INVITE till any
response is received. But in the meantime the phone may be ringing off
the hook at the UAS side and the user may actually pick up before any
100 Trying arrives at UAC. This dead phone syndrome at the UAS side
should be avoided at all costs. 

I understand that there is race condition that the protocol needs to
resolve. In fact, there is a solution (BYE dialog if CANCEL beats out
INVITE) that minimizes interefence on user experiences.

Regards,

Shan Lu
sentitO Networks