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

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

Nope, in PSTN with SS7, you will NEVER EVER have a case that a caller has
hung up and the phone still keeps ringing. More bizarre possibility with SIP
bis05 is that phone keeps ringing and callee picks up, but the caller has
long hung up. 
In PSTN with SS7, as soon as the caller hangs up, an ISUP REL will be sent
(Q.931 DISCONNECT with ISDN).

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 1:27 PM
To: 'Robert Sparks'; 'Christer Holmberg'; Shan Lu; 'Romel Khan'
Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; Jonathan Rosenberg
Subject: RE: [Sip] Bis-05 question: CANCEL

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: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 22:39:39 +0200

Hi,

First, I don't think we should "compare" SIP with ISUP, because we are
NOT trying to implement another ISUP, are we?

Since we are dealing with a protocol on an IP network, and we don't have
the same kind of reliability as a SS7 network, the fact is that we may
have packet losses, messages may be delivered in wrong order etc etc.

Now, the easiest way to solve this is to always only have one active
transaction, ie you don't send any new request before you have received
the response from the previous request. Well, I think we all agree that
that will NOT work for SIP, especially not during the session setup,
where we may have a number of different overlapping requests, maybe also
for different early legs. 

So, since we will have to live with the fact that the things above may
occur, I still think we should have mechanisms to handle these scenarios
- INSTEAD of trying to define case specific rules to try to prevent
them.

Just my personal thoughts...

Regards,

Christer Holmberg
Ericsson Finland

---

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

Hello,

The problem here is that people are mixing up layers. Take into account
that when we run SIP over UDP we are implementing a small transport
layer in the SIP (application) layer... more comments inline:

Romel Khan wrote:
> hung up and the phone still keeps ringing.

Actually it can perfectly happen. I make a call and I send an IAM. Then
I hung up, so my local exchange sends a REL. However, since there is
congestion (due to any reason), MTP2 cannot deliver my REL inmediately.
Therefore, until MTP2 does not manage to deliver the REL, the callee's
phone is ringing but the caller has hung up.

This is exactly the same situation that we are facing with SIP. Since
the network is cogested signalling messages are not getting thru. That's
why we do not receive the 100 Trying.

If the signalling transport works properly, both SIP and ISUP will
perform OK.

> More bizarre possibility with SIP

As I have said, under congestion, this scenario is perfectly possible in
both SIP and ISUP.

> (Q.931 DISCONNECT with ISDN).

Sending a REL does not ensure that the REL has been received by the
other party. If MTP2 cannot send the message the situation is the same
as if the UAC cannot send the message until congestion finishes (that
is, when the 100 Trying has been received).

Regards,

Gonzalo