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

From: [email-masked]
Date: Mon, 12 Nov 2001 16:34:18 -0700

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

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.

John Hearty
Level3

_______________________________________________
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: Tue, 13 Nov 2001 15:00:57 -0500

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

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.