Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE
"Worley, Dale R (Dale)" <dworley@avaya.com> Fri, 29 October 2010 00:55 UTC
Return-Path: <dworley@avaya.com>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8813A69B6 for <bliss@core3.amsl.com>; Thu, 28 Oct 2010 17:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.437
X-Spam-Level:
X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 SfbqJWZBRBcv for <bliss@core3.amsl.com>; Thu, 28 Oct 2010 17:55:36 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DC6193A67FA for <bliss@ietf.org>; Thu, 28 Oct 2010 17:55:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,255,1286164800"; d="scan'208";a="215748217"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2010 20:57:28 -0400
X-IronPort-AV: E=Sophos;i="4.58,255,1286164800"; d="scan'208";a="534048153"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2010 20:57:27 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 28 Oct 2010 20:57:27 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Shida Schubert <shida@agnada.com>, BLISS <bliss@ietf.org>
Date: Thu, 28 Oct 2010 20:55:57 -0400
Thread-Topic: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE
Thread-Index: AQHLdwRBHUnIntjzwEKEq4Z2XvEU6Q==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22022889AB@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 00:55:37 -0000
We need to ensure that a PUBLISH for suspending/resuming a CC request reliably identifies the CECE in question. It seems that the optimal solution is to have the cc-URI provided in each NOTIFY (1) address the responsible monitor, and also (2) uniquely identify the CECE. As a fallback, the monitor can examine the From header of the PUBLISH. This causes no additional problems regarding how to operate subscriptions, as the cc-status value is already customized per-subscription. This method should be simple to implement using a suitable URI parameter. The Asterisk implementation is already using this method. I think we have removed the idea of sending the PUBLISH within the SUBSCRIBE dialog. Actually, I think we've already agreed on this change and this solution has been incorporated into the draft. But it seems that there are a few wording changes needed to finish the change. Section 5 (partial) The monitor may receive PIDF bodies [RFC3863], via PUBLISH requests directed at its URI. These PUBLISH requests are expected to be sent by subscribers to suspend and resume their CC requests. A CECE is identified by the request-URI (if it identifies the CECE) or the From URI of the request. Receipt of a PUBLISH with 'status' of 'open' ... Section 6.5 (partial) Each PUBLISH SHOULD be sent to (in order of preference) the URI value received in the NOTIFY bodies of the subscription, the monitor URI used to establish the subscription, the Contact address of the subscription notifier, or the original call request-URI. (This change is duplicated in section 6.6.) The URI line in the event package is now needed even when "state: queued": Section 7.5 (added) The monitor may receive PUBLISH requests to suspend or resume CC requests. The PUBLISH requests may be received via the URI it manages, any URI that it inserts into a Call-Info header, any contact URI it uses as a notifier for "call-completion" events, or any URI it returns as the "URI" line of "call-completion" event packages. The monitor should identify the addressed CECE by the request-URI of the request, or if that is not possible, by the From URI. Section 10.3 The cc-URI line provides a URI (possibly in the form of a name-addr) which the agent SHOULD use as the request-URI of the CC recall INVITE and of PUBLISH requests to suspend and resume the CC request. The URI line SHOULD be provided unless the expiration time indicated in the NOTIFY is zero. The URI SHOULD be globally routable. The URI SHOULD uniquely identify the CECE involved. The syntax provides for generic-params in the value, but this document defines no such parameters. Parameters that are not understood by the subscriber MUST be ignored. Dale
- Re: [BLISS] WGLC for draft-ietf-bliss-call-comple… Worley, Dale R (Dale)
- Re: [BLISS] WGLC for draft-ietf-bliss-call-comple… Christer Holmberg