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
