Re: draft-ietf-sip-info-events-00: CANCEL???

Jeroen,

Re CANCEL of INFO, I don't see this any different than CANCEL of any 
other non-INVITE transaction: you are free to ask, but don't get your 
hopes up, because it probably won't work.

Re CANCEL of reINVITE: I already raised the issue of the need to define 
what happens to the negotiated info package state when a reINVITE fails. 
This is just an instance of that. (The issue is around the resulting 487 
response to the INVITE, not the CANCEL itself that is the issue.)

	Thanks,
	Paul

Jeroen van Bemmel wrote:
> All,
> 
> IMHO allowing CANCEL of INFO requests is a bad idea, it introduces a 
> RACE condition that any CANCEL will generally loose. It also introduces 
> semantic issues: what does it mean to cancel a given INFO event? For 
> INVITE it somewhat intuitively means stop ringing the phone and signal 
> to the callee that the call was aborted, it is not generally clear what 
> CANCEL for a generic INFO event would mean. For example, an INFO event 
> might trigger some action that is not "undoable" (e.g. a gaming move in 
> a multiplayer game, the final digit of a 4-digit access code, ... )
> 
> I do have a question regarding the - somewhat hypothetical - scenario of 
> a mid-dialog INVITE being CANCELed: How does that affect the INFO 
> negotiation mechanism state? I guess from a UAS perspective the 
> UAC-provided Send-Info and Recv-Info in the INVITE should be reverted 
> back to the last known values, and for the UAC the 487 response should 
> cause it to revert to the previous state?
> 
> Regards,
> Jeroen
> 
> [email protected] wrote:
>>    From: Paul Kyzivat <[email protected]>
>>
>>    I have a question regarding the following paragraph:
>>
>>        A UAC MAY CANCEL an INFO request.  A UAS receiving a CANCEL for an
>>        INFO request SHOULD respond to the INFO with a "487 Request
>>        Cancelled" response unless the UAC has already sent a final 
>> response.
>>        The UAS then MUST ignore future INFO requests.
>>
>>    Why would the CANCEL affect *future* info requests???
>>
>> I'm sure we *don't* want CANCEL to affect future INFO requests.  That
>> adds another bit of state that has to be remembered, and I'm sure it
>> will cause some weird complications.  (Among other things, what is it
>> to "ignore" an INFO request?  What response code is that?)
>>
>> Dale
>> _______________________________________________
>> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email protected] for questions on current sip
>> Use [email protected] for new developments on the application of sip
>>
>>   
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip