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

From: Romel Khan <[email-masked]>
Date: Fri, 2 Nov 2001 12:53:32 -0500

It's not just the phone ringing longer, but resources are also tied up for a
longer period.

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Friday, November 02, 2001 11:22 AM
To: 'IETF SIP Mailing List'
Subject: Re: [Sip] Bis-05 question: CANCEL -- Proposed solution

I'm sorry, but I am opposed to changing the way CANCEL works and add yet
another special case. The current methods put no excess burden on the UAC.
The UAC is already required to maintain transaction state until it completes
or times out.

I don't see having the called party's phone ring a few seconds longer when
there is congestion to be all that much of the problem. How many times have
you picked up your ringing phone and said "hello" and there is no one there?
It has happened to me twice this week and I don't get that many calls. I
don't blame the telephone company, I just figure the calling party hung up.

more comments below

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Shan Lu" <[email-masked]>
To: "'Christer Holmberg'" <[email-masked]>; "'Jonathan
Rosenberg'" <[email-masked]>
Cc: <[email-masked]>; "'IETF SIP Mailing List'" <[email-masked]>
Sent: Friday, November 02, 2001 10:43 AM
Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Christer Holmberg
> > Sent: Friday, November 02, 2001 3:45 AM
> > To: Jonathan Rosenberg
> > Cc: [email-masked]; 'IETF SIP Mailing List'
> > Subject: Re: [Sip] Bis-05 question: CANCEL
> >
> >
> > ANYWAY, if I'm the only one who doesn't like the wait-for-1xx idea I
> > think we should stop the discussion, use that mechanism, and move
> > forward. I am pretty sure there are lots of other, more important
> > issues, to solve :)
> >
>
> Count me as a firm second :-)
>
> Actually I believe there is a solution without having to wait for 1xx.
> We need two modifications on how to handle CANCEL:
>
> Mod 1) CANCEL is handled statelessly at the server side if there is no
> matching INVITE. In other words, a 481 response is sent and the
> transaction state is destroyed.
>
> Mod 2) CANCEL transaction client should retransmit CANCEL till 200
> response is received or a maximum retransmission number has been
> reached. In other words, a 481 response does not change the state to
> "Completed" (Figure 6).
>
> A brief note on Mod 1: stateful proxy already follows this rule in
> bis-05, see section 16.8, line 2449.
>
> With these two mods in mind, here is how CANCEL works:
>
> Case 1: No SF proxy
>
> UAC sends INVITE and then CANCEL. If INVITE beats CANCEL at UAS, CANCEL
> is responded with 200. Phone stops ringing if it has been ringing
> before. Everybody happy. If CANCEL beats out INVITE, CANCEL is responded
> with 481 statelessly (mod 1). Hence UAC will resend CANCEL (mod 2).
> Eventually a retransmitted CANCEL will arrive after INVITE.

The UAC is required to be re-transmitting the INVITE until it gets a 1xx.
Now you want it to keep retransmitting the CANCEL too? Sounds like you're
doing twice the work.

>
> Case 2: SF proxy between UAC and UAS
>
> UAC sends INVITE and then CANCEL. If the SF proxy receives INVITE and
> then CANCEL, the CANCEL will be responded with 200 and the proxy will
> generate CANCEL on all branches of INVITE. From there, we are back to
> Case #1. If the proxy receives CANCEL before INVITE, it will statelessly
> forward this CANCEL downstream and the UAS will respond with 481
> assuming the CANCEL beats out INVITE at the UAS. So UAC will retransmitt
> CANCEL which eventually will be received by the proxy after INVITE. Back
> to Case 1.

CANCEL is hop-by-hop. The SF proxy would respond with 481. It would not be
sent downstream. Do you see the extra burden you are placing on the proxies?

>
> We are already doing so many special things for CANCEL. I don't think
> these two mods are that much a big deal, especially they are transaction
> layer. Compared to wait-for-1xx, this approach maximizes the chance that
> INVITE can be cancelled in shortest time (and hence chance for dead
> phone syndrome).
>
> Comments/fire welcome.
>
> Regards,
>
> 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
>

_______________________________________________
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: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Nov 2001 16:56:52 -0000

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

> ----------
> From: 	Shan Lu[SMTP:[email-masked]]
> Sent: 	06 November 2001 16:31
> To: 	'Jonathan Rosenberg'; 'IETF SIP Mailing List'
	<snipped>
> > 
> > Maybe I missed something, but isn't the point of sending an 
> > INVITE to ring a
> > phone? Sure, people can change their mind, but it is not reasonable to
> > expect that they will be able to beat out the network and end 
> > up not causing
> > the phone to ring. This expectation does not exist in the PSTN today.
> 
> But the PSTN does NOT ring the phone each and every time a user dials a
> number and then immediately hangs up. That's what would happen when you
> wait-for-1xx-then-cancel. By the time the 1xx is received by the SF
> proxy or UAC, assuming it's not 100 Trying, the callee phone has already
> started to ring. It's true that CANCEL itself may be lost or the caller
> may just hang up too late. But I don't think the protocol should be
> designed in such a way that it is guaranteed to cause user-objectionable
> scenario and just hope user will put up with it. 
> 
Untrue.

If you complete the number, then the phone will ring. There is no way that
clears catch up with call requests and get absorbed in the modern PSTN/ISDN
signalling systems.

That Ring may be very short, but it happens.

The only way round this is to hang on to the callers requests until you are
sure he is not going to clear the call - surely that is something that ends
up being objectionable to the calling user. 

<remainder snipped>

Keith

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2001 17:22:00 -0500

> From: Shan Lu [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 9:55 AM
> Hello,
> > > wait-for-1xx-then-cancel. 
> > 
> > As Keith and others have pointed out, this is NOT the case in 
> > the PSTN. The
> > PSTN will have this exact problem.
> > 
> 
> No matter what has been said about PSTN, the simple fact is the phone
> doesn't ring if the caller hangs up quickly. Try it for yourself.  If
> you can not conclude one way or the other because the PSTN setup time
> tends to be very short and leaves little room for user to 
> "change mind",
> then make a call between your desktop phone and cell phone. There you
> have around one second to hang up before the phone starts to 
> ring.

You are introducing an expectation which won't be met even in the perfect
case where CANCEL doesn't beat INVITE. Lets say I send an INVITE, and its
not lost, and then I hangup. The INVITE will beat the CANCEL to the UAS
under ideal cases, and therefore the UAS will ring, if not briefly. 

If, instead, the CANCEL is lost, the phone will also ring briefly, until the
CANCEL is resent (500ms).

How would you propose we deal with those two? Should a phone not ring on
INVITE, in case the user sent a CANCEL? Rather, it should wait a second? 

-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: [email-masked]
Date: Mon, 12 Nov 2001 16:07:39 -0700

>INVITE, in case the user sent a CANCEL? Rather, it should wait a second? 

I would also like to point out that you might be dealing with inter-digit
timers in your test calls, where the originating PBX or CLASS 5 switch is
waiting for additional digits before launching the call.  Thus, hanging up
before an inter-digit timer expires results in no call being forwarded from
a PBX or CLASS 5 switch.

Anyone that hangs up after making a call is taking a chance the phone on the
other end will briefly ring.  Under ideal conditions, this ring may be so
brief as to not even allow the ring to be heard.  We can't design around
this type of potential human behavior in the protocol.  The possibilities
might be endless, and we need to strive to Keep It Simple.

It seems to me this issue has been debated enough.  There is no concensus
that it needs to be dealt with in the protocol.  Please let this thread die.

John Hearty
Level3

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2001 18:22:28 -0500

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 6:08 PM
> To: [email-masked]; [email-masked]; [email-masked]
> >If, instead, the CANCEL is lost, the phone will also ring 
> briefly, until
> the

By "no consensus that it needs to be dealt with in the protocol" - do you
mean that we should ditch the current text on waiting for 1xx before sending
CANCEL? I think that this is still required otherwise the phones will never
stop ringing, and thats bad...

-Jonathan R.

---

---

From: [email-masked]
Date: Tue, 13 Nov 2001 15:27:17 -0700

> From: Brett Tate [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 1:01 PM
> To: [email-masked]
> > Sorry I wasn't clear.  I fully support 
> > the bis-05 change here waiting for
> > 1xx before sending CANCEL.  That fixes an 
> > important problem.  I meant no one
> > else appears concerned with the issue of 
> > abandoned calls always ringing the
> > phone (though briefly).  This is a side 
> > affect of the fix introduced, and
> > the concensus seems to be this is acceptable 
> > given the potential human behaviour to change 
> > your mind and abandon a call.  The side 
> > affect is far more acceptable than the ring 
> > forever problem being corrected with the
> > bis-05 fix.
> 
> The solution only partially fixes the ring 
> forever problem.  It does not resolve the 
> issue related to a UAC unable to deliver 
> CANCEL because of network/proxy/UAC problems.
> Is this an item left to the implementer for
> resolution, or should a solution be 
> presented within the bis or extension draft?
> Solutions using Expires or periodic 100rel 
> could be documented in the bis.

 Good point.  The symptom is the same, but the cause differs and the fix
would differ.  This is certainly a scenario to consider, given the time it
may take for a final response to an Invite, increasing the chances of a
network or proxy problem arising during the transaction.  This seems like
something that should be added to the open issues for bis.

 Timer C would fire as discussed in 17.1.1.2 terminating the transaction at
a UAC (what the TU does when informed of the timeout is not specified -
CANCEL is what we are talking about).  A similar timer in the proceeding
state for the server transaction is not discussed in section 17.2.1 but is
needed, especially if an Expires header is included in the Invite.

 There is discussion of the UAS checking the Expires header when the Invite
is first received (section 13.3.1), but nothing about it expiring during
ringing.  The bis seems to rely on an expired transaction being CANCELed by
the UAC, and does not consider this scenario and what the UAS should do.

> 
> Bis-05 section 16.6 item 9 mentions that a 
> forking proxy only CANCELs "pending" branches.
> The bis should clearly state that the
> forking proxy MUST continue to retry the
> INVITE on the obsoleted branch.  Upon 
> finally getting a provisional response, 
> the proxy can send the CANCEL.  Text similar 
> to the "acting as a user agent" stuff around 
> lines 2447 should suffice.
> 

John Hearty
Level3

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2001 01:18:49 -0500

> Sent: Monday, November 19, 2001 3:10 AM
> To: [email-masked]
> > That said, yes, the UAS should indeed 
> > send a 487 or 408 after the Expires
> > header time has elapsed. That is not clear now but 
> > I think this is the reasonable treatment and 
> > I've marked that to be changed.
> 
> Would it be beneficial to document a 
> default Expires value for INVITE?  

I don't think its needed.

> Otherwise the value of infinity 
> would continue to be the assumption.

A UAS can always decide to send 408/487 at any time, there is no need to
document a specific recommended time.

-Jonathan R.
---