[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] 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, becausFrom sip-bounces at ietf.org Sat Oct 25 07:01:00 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 587C03A6A15;
Sat, 25 Oct 2008 07:01:00 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2D3253A69E9
for <sip at core3.amsl.com>; Sat, 25 Oct 2008 07:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.581
X-Spam-Level:
X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NH1wUp3m2frR for <sip at core3.amsl.com>;
Sat, 25 Oct 2008 07:00:57 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149])
by core3.amsl.com (Postfix) with ESMTP id D47D83A6A70
for <sip at ietf.org>; Sat, 25 Oct 2008 07:00:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,483,1220227200"; d="scan'208";a="25636925"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2008 14:01:44 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9PE1iDA018615;
Sat, 25 Oct 2008 10:01:44 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9PE1iR3011046;
Sat, 25 Oct 2008 14:01:44 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Sat, 25 Oct 2008 10:01:44 -0400
Received: from [10.86.249.64] ([10.86.249.64]) by xfe-rtp-201.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Sat, 25 Oct 2008 10:01:44 -0400
Message-ID: <490326C7.5010601 at cisco.com>
Date: Sat, 25 Oct 2008 10:01:43 -0400
From: Paul Kyzivat <pkyzivat at cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Jeroen van Bemmel <jbemmel at zonnet.nl>
References: <48FDEB20.9040109 at cisco.com> <200810241732.m9OHWbxv52636270 at shell01.TheWorld.com>
<4902FC59.3000303 at zonnet.nl>
In-Reply-To: <4902FC59.3000303 at zonnet.nl>
X-OriginalArrivalTime: 25 Oct 2008 14:01:44.0392 (UTC)
FILETIME=[3686E480:01C936AA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3045; t=1224943304;
x=1225807304; c=relaxed/simple; s=rtpdkim1001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=pkyzivat at cisco.com;
z=From:=20Paul=20Kyzivat=20<pkyzivat at cisco.com>
|Subject:=20Re=3A=20[Sip]=20draft-ietf-sip-info-events-00=3
A=20CANCEL??? |Sender:=20
|To:=20Jeroen=20van=20Bemmel=20<jbemmel at zonnet.nl>;
bh=7DzmUsrYjHUb4ZmsxcAZ4pvuDiSCmz6csRFw9ncf4Lk=;
b=I13xSC+Pi3stbYn+xj8mQjXc0sm0SsxgxBV5WsU5hZiWeAZaXbiBIjJNRl
+qhdiwSslj0F+JppZWW+V6hiA4YKtP8lwdQL7q/DceAkOczMYSKFhy0DLfmg
qPUN92yXE7;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat at cisco.com; dkim=pass (
sig from cisco.com/rtpdkim1001 verified; );
Cc: sip at ietf.org
Subject: Re: [Sip] draft-ietf-sip-info-events-00: CANCEL???
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 proe 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
Dale.Worley at comcast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
bably 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
Dale.Worley at comcast.net wrote:
From: Paul Kyzivat <pkyzivat at cisco.com>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip