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

Kim Liu wrote:

My take is that although CANCEL for non-INVITE is academic,
it should be allowed. Main reason is to not make special checks
in the state machine about original method and this CANCEL.

> 
> Limit CANCEL for INVITE only.  Trying to handle CANCELs
> for all/arbitrary methods otherwise is going to be prohibitively
> complex task -- it will end up as a bunch of special
> cases -- i.e. if CANCEL is allowed for all methods,
> how do you treat a CANCEL for a CANCEL?  A CANCEL for
> a BYE?  A CANCEL for an ACK?  That's ridiculous --
> you automatically end up with more special cases for
> handling CANCEL to handle CANCELs for methods where
> CANCEL makes no sense.
> 
> It's a case of confusing an application specific
> signal (trying to stop a service/application started
> by another method) with a generic procotol level
> signal (CANCEL).  Since only INVITE and BYE can
> start/change/stop a call, every other method almost
> has to be an application or service specific
> invocation, rather than session affecting -- if
> this assumption is made, then CANCEL, as a session
> level signal, is not apropriate for halting a
> service.
> 
> Kim
> 
> _______________________________________________
> 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

_______________________________________________
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