[Sip] grouping bis open issues: CANCEL related

[Rohan Mahy <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip