Subject: [Sip] draft-ietf-sip-info-events-00: CANCEL???

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 10:45:52 -0400

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???

	Paul
_______________________________________________
Sip mailing list  https://www.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: "Christer Holmberg" <[email-masked]>
Date: Wed, 22 Oct 2008 09:56:09 +0200

Hi,

I have the same question as Paul.

Also, I wonder whether the paragraph is needed in the first place. I
think INFO should follow the normal 3261 procedures as far as CANCEL is
concerned.

I also doubt that a UAS would send a 1xx response for an INFO, and
without that you can't CANCEL, right?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 21. lokakuuta 2008 17:46
To: SIP IETF; Eric Burger
Subject: [Sip] draft-ietf-sip-info-events-00: CANCEL???

    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.

	Paul
_______________________________________________
Sip mailing list  https://www.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
_______________________________________________
Sip mailing list  https://www.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: Eric Burger <[email-masked]>
Date: Wed, 22 Oct 2008 09:57:24 -0400

Cut-and-paste error.

---

From: [email-masked]
Date: Fri, 24 Oct 2008 13:32:37 -0400 (EDT)

From: Paul Kyzivat <[email-masked]>

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

---

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 25 Oct 2008 13:00:41 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Oct 2008 10:01:43 -0400

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

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 27 Oct 2008 12:08:56 -0700

> hopes up, because it probably won't work.

True, it's not different from other non-INVITE transactions but given 
the inability to challenge CANCELs maybe we'd be better off not 
perpetuating it's use. If it works, it's a potential security hole, if 
it doesn't then we don't loose anything by not having the option of 
canceling.

Thanks,
Anders

>> 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