Re: draft-ietf-sip-info-events-00: CANCEL???
Anders Kristensen <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
Paul Kyzivat wrote: > 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. 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 > > 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 > _______________________________________________ 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