Re: [Sip] Open Issue #7: CANCEL for non-INVITE

James Undery wrote:
> 

> The problem I see here is the difference between complete immidately,
> and the ability to cancel before completion. For example this all
> started because of REGISTER, sending 100 then attempting to do the
> database magic (possibly over a network) makes sense to restrict
> retransmission, yet providing full rollback semantics to allow the
> REGISTER to cancel is trickier.

As I have tried to say numerous times before, nobody has to implement
CANCEL even under the current state of affairs. If CANCELing REGISTER is
difficult (which seems likely), just don't do it. CANCEL is advisory, an
optimization. Somehow the "doesn't work for all cases" seems to get
confused with "it's never useful".

There are three possible views of the non-INVITE world:

(1)everything must complete immediately (i.e., within 500 ms) -> no
1xx, no CANCEL

(2) most non-INVITE complete immediately almost all the time, but on
occasion they don't
  (2a) but these things are never cancellable (whether with CANCEL or
something else)
  (2b) for some cases, they are cancellable

I've argued for 2b, simply because I can't rule out this case and since
it seems to reflect reality in other spheres of life.

CANCEL makes sense for view 2b, although it has been argued that you
could also devise a new method for methods where 2b holds. (However,
that clearly only works if overlapping transactions are allowed.) That
is an approximation to CANCEL, but not quite functionally equivalent,
due to the different forking proxy behavior.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip