Subject: [Sip] grouping bis open issues: CANCEL related

From: Rohan Mahy <[email-masked]>
Date: Sat, 08 Sep 2001 11:37:10 -0700

Hi,

Based on Jonathan's open issues presentation ( 
http://www.softarmor.com/sipwg/meets/ietf51/slides/pres-jdrosen-sip_bis_open 
-ietf51.ppt ), and the closure of 6 of those issues on the list last night, 
I count 19 open issues remaining, of which 7 are CANCEL related, and 7 are 
SDP related.  Perhaps if we discuss these in a group, we might close them 
faster.

The following open issues are all related to CANCEL.
I've addded my comments/proposals/2 cents inline:

#7   "CANCEL for non-INVITE"
 >Spec allows CANCEL for non-INVITE. Why is that silly?
 >Non-INVITE must be answered immediately, CANCEL usage therefore always a
 >race condition.
 >Why does it make sense? May still be human interaction, Timeouts – wish to
 >give up when no response comes
 >Proposal:  remove
[also reference recent list discussions]

rohan> i think CANCEL for non-INVITEs is a waste of bits in the spec.  if 
you get a cancel for non-INVITE, just send a 200 and be done.

#72  "CANCEL for multicast"
 >Spec says that servers send no response to a multicast CANCEL
 >How does client know when to stop retransmitting?  No way!
 >Proposals:
 >1) Never send CANCEL over multicast
 >2) Never send SIP over multicast
 >3) Just continue retransmitting until timeout
 >4) Send CANCEL responses over multicast (May need to limit scope)

rohan>  I propose the first option: (never cancel over multicast), although 
the second (deprecate SIP over Multicast) is also acceptable to me.

#118 "481 then BYE"  (OK not really a CANCEL issue, but similar)
 >Bis-04 says that if you get a 481 to INVITE, consider the call leg down
 >Question: should you send BYE?
 >Proposal: YES!
 >Why?  Don’t want to change fact that mid-call re-INVITE failures don’t
 >terminate call.  One way to terminate calls
 >[If media streams from A->B generate errors to A, or RTCP times out,
 >re-INVITE to B.  If that generates 481, then BYE]

rohan> I concur with the proposal.

#121 "reason codes for CANCEL/BYE"
 >Would like to have BYE/CANCEL Reason phrases/codes
 >- Compatible with PSTN
 >- Differing UA behaviors depending on reason for CANCEL
 >- UA hangup vs. other branch completed (drop to voicemail!)
 >- 3pcc treatments
 >Issue: what codes to use
 >Proposal: existing response codes/reason phrases
 >Mostly for 3pcc case
 >But: need more! Like why CANCEL was sent in forking case

rohan> This is new functionality, and does not belong in bis IMO.  Some 
draft such as Visited or cc-diversion could easily provide this type of 
information.

#122  "cancel on 200/600 strength"
 >When a forking proxy gets a 2xx/6xx on a branch, is CANCEL of other branches
 >a: 1) MAY, 2) MUST, or 3) SHOULD
 >Bis-03 and previous were MAY, -04 is SHOULD
 >Why?  Without cancellation, burden moves to UA; UA doesn’t know if proxy
 >forked!  Would always need to send CANCEL after 2xx
 >Why not?  Useful apps for not cancelling
 >Proposal:  change to MUST, MAY use caller-prefs to turn off

#130  "BYE vs. CANCEL"
 >To hang up a call before a final response, does the UAC
 >1) BYE, no tags
 >2) CANCEL, then BYE if 2xx
 >3) CANCEL + BYE no tags
 >Related: can CANCEL have tags to be “directed”
 >Related: can you send BYE for a 1xx “early leg”
 >Proposal:
 >CANCEL for all, then BYE on 2xx
 >You can terminate a particular early leg with BYE w/ tags
 >[CANCEL w/ tags is worse since: No bodies, Not e2e]

rohan> I concur with both proposals (#122 & #130)

thanks,
-rohan

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Sep 2001 03:07:03 -0400

I'd like to thank Rohan for taking a stab at closing these open issues,
since bis remains our most important deliverable, and the one that still
needs much work.

For ease of tracking and comments, I do think it makes sense to have
separate threads for each of these. So, I am going to take Rohans mail as a
starting point and respond to each in a separate thread, labeled with the
issue number.

-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

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Saturday, September 08, 2001 2:37 PM
> To: [email-masked]
> Subject: [Sip] grouping bis open issues: CANCEL related
> 
> 
> Hi,
> 
>  >Why does it make sense? May still be human interaction, 
> Timeouts - wish to
>  >Why?  Don't want to change fact that mid-call re-INVITE 
> failures don't
>  >Why?  Without cancellation, burden moves to UA; UA doesn't 
> know if proxy
>  >Related: can CANCEL have tags to be "directed"
>  >Related: can you send BYE for a 1xx "early leg"
>  >Proposal: