Subject: [Sip] Bis-05 question: CANCEL

From: "Shan Lu" <[email-masked]>
Date: Mon, 29 Oct 2001 16:59:02 -0500

Hi all,

Section 9.1, line 1180 "CANCEL MUST NOT be sent if no provisional
response has been received".

Why?

If my user dials a number and then hangs up, I want to cancel the invite
ASAP. 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, an INVITE can only be
cancelled AFTER the phone has been rung. I think this is an unnecessary
requirement. Sure the the CANCEL immediately following INVITE might
arrive at the UAS before the INVITE. So be it. 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. 

Shan Lu

sentitO Networks

_______________________________________________
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: Tue, 30 Oct 2001 15:32:58 -0500

<snip>

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

This is obviously wrong. Disregard the comment.

Shan Lu
sentitO Networks

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Oct 2001 19:44:07 -0000

On the ISDN/PSTN if I have a massive set of timeouts and dropouts across the
network for the transmission of a message, then ultimately I could well get
a delay of 30 seconds on propagation of the second message, over and above
the delay in the propagation of the SETUP/IAM.

The answer is that this does not happen very often, so infrequently as to be
unnoticeable. 

If there is a 30s difference in getting messages the clear message through,
due to delay in receiving a provision response at the calling UA, then the
end to end propagation delay of signalling messages is also of the order of
that. Any system that tries to control telecommunications that consistently
gives 30s delays in end to end transmission of signalling messages is not
going to be used for telecommunications. The user will throw it in the bin
and go back to tin cans and string.

Most calling users do not even allow a phone to ring for 30s when it is not
answered. 

Keith

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

> ----------
> From: 	Shan Lu[SMTP:[email-masked]]
> Sent: 	31 October 2001 19:27
> To: 	'Drage, Keith (Keith)'
> Cc: 	'IETF SIP Mailing List'
> Subject: 	RE: [Sip] Bis-05 question: CANCEL
> 
> 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
> 
> > -----Original Message-----
> > 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'
> > 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
> > > >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 31 Oct 2001 18:29:14 -0500

> Sent: Wednesday, October 31, 2001 12:39 PM
> To: Bob Penfield
> >>I understand the arguments for buffering. BUT, by waiting 
> for the first
> >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.
> 
> 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.

CANCEL is not the same thing as BYE. CANCEL terminates *all* pending
branches, BYE terminates a specific one. As such, the UAC would need to
continue to BYE individual 1xx as they arrive, until it has finally received
a 1xx from all UAS that got the INVITE (and some may never send a 1xx), or
gets a final response. This can potentially take quite a while - resulting
in the phones on the callee sides ringing for quite some time. That is
unacceptable, IMHO.

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

Absolutely it does. The 2xx will trigger CANCELs at proxies on all other
branches, which will either generate a final response to the INVITE (487
usually), or do nothing if a final response is coming. 

-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: Anders Kristensen <[email-masked]>
Date: Wed, 31 Oct 2001 23:35:22 -0500

There may be a third option that I don't remember having been discussed,
namely that the client sends the CANCEL immediately but the server just
sliently drops it if it cannot associate it with a request. That is, it
doesn't respond and doesn't install transaction state. The client will
continue retransmitting CANCEL and the original request in parallel (as
per usual) and the CANCEL will continue to be dropped by the server
until the original request is actually received. Same procedure would
apply to proxy servers.

This will no doubt be violently hated by some and I'm not necessarily
proposing it anyway ;).  Apart from treating CANCEL even more specially
than is already the case it means a UAS might ring the phone even though
the call was cancelled. Although actually, that should be no worse than
if the INVITE has been received immediately and no worse than waiting
for a 1xx.

Anders

Jonathan Rosenberg wrote:
> 
> >
> > One alternative is to queue the CANCEL
> > at UAS/proxy waiting for the associated
> > request.
> 
> Right. The issue with that is that is that it opens a DoS attack. CANCEL
> can't be authenticated like other requests since its hBh. Thus, its
> authenticated by having it come from the same place the request came from
> (and so tls, for example, could be used). This means you trust it if you
> trust the request its cancelling. If you buffer at the server, you would
> have to buffer the cancel even before an authenticated request arrived. THis
> means that someone can send CANCEL to establish state at the server, and
> then never send a corresponding request. There is no easy way to defeat this
> except to prevent it as we have proposed.