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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2001 00:27:39 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 5:27 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution
> 
> 
> 
> 
> > -----Original Message-----
> > From: Brett Tate [mailto:[email-masked]]
> > Sent: Tuesday, November 13, 2001 1:01 PM
> > To: [email-masked]
> > Subject: RE: [Sip] Bis-05 question: CANCEL -- Proposed solution
> > 
> > 
> > > 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.

I'm not sure. If the CANCEL is not delivered, this means some substantial
number of consecutive messages were lost - enough to signal a serious
network problem. All kinds of weird things will happen when you have major
network problems like this. We have not generally tried to deal with fixing
problems of this magnitude. If such a problem should occur, with the current
spec, the called party would pick up, no one would be there, and they'd hang
up. That would clean things up. Seems reasonable.

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

No, this is a different scenario. The timer is needed in the client case
since a state transition depends on a message from an external entity, which
may never arrive. Here, we depend on a message from the SAME entity, which
will arrive unless there is some kind of software problem or bug, and it is
not reasonable to specify timers to handle these cases.

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.

-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

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Mon, 19 Nov 2001 03:10:08 -0500

> 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?  
Otherwise the value of infinity 
would continue to be the assumption.
I guess infinity could be fine for 
some applications; however I assume 
that most applications would like the 
default to be somewhere between 
3 minutes and 1 day as means to
possibly avoid sending it.