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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Oct 2001 18:26:56 -0000

None of this supposedly disastrous scenario for the SIP environment is any
different to what happens in the PSTN/ISDN today. If you send a call request
(SETUP/IAM or whatever) with full address into the PSTN/ISDN today, and then
follow it up with a release, the first message will invariably reach the end
terminal (and be processed there) before the second is received. There is
therefore even today the chance that such a call is answered before the
clear is received.

This has been the case for years, and nobody has noticed.

Will it really be a problem for SIP.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Romel Khan[SMTP:[email-masked]]
> Sent: 	31 October 2001 15:26
> To: 	'Robert Sparks'; 'Christer Holmberg'; Shan Lu
> Cc: 	'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg
> Subject: 	RE: [Sip] Bis-05 question: CANCEL
> 
> 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
> 

_______________________________________________
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: "Shan Lu" <[email-masked]>
Date: Wed, 31 Oct 2001 14:27:41 -0500

The only difference is that in PSTN you don't keep ringing the phone 30s
after the caller has hung up, do you?

Shan Lu
sentitO Networks

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Drage, Keith (Keith)
> Sent: Wednesday, October 31, 2001 1:27 PM
> To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan'