Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 04 November 2010 19:44 UTC
Return-Path: <christer.holmberg@ericsson.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 018213A692B for <bliss@core3.amsl.com>; Thu, 4 Nov 2010 12:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rCalbLXAOrOp for <bliss@core3.amsl.com>; Thu, 4 Nov 2010 12:44:29 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D0FB43A6811 for <bliss@ietf.org>; Thu, 4 Nov 2010 12:44:28 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b28ae00000135b-05-4cd30d266b4f
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F2.79.04955.62D03DC4; Thu, 4 Nov 2010 20:44:38 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 4 Nov 2010 20:44:38 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>, Shida Schubert <shida@agnada.com>, BLISS <bliss@ietf.org>
Date: Thu, 04 Nov 2010 20:44:37 +0100
Thread-Topic: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE
Thread-Index: AQHLdwRBHUnIntjzwEKEq4Z2XvEU6ZNhwfDQ
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502F2BC3C@ESESSCMS0356.eemea.ericsson.se>
References: <CD5674C3CD99574EBA7432465FC13C1B22022889AB@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <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
X-Brightmail-Tracker: AAAAAA==
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: Thu, 04 Nov 2010 19:44:30 -0000
Hi Dale, Regarding sending PUB inside the SUB dialog, one argument against that was dialog re-usage. However, we need to remember that PUB does not create a dialog. RFC 3903 also states that PUB requests can be sent in-dialog. Regards, Christer > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] > On Behalf Of Worley, Dale R (Dale) > Sent: 29. lokakuuta 2010 3:56 > To: Shida Schubert; BLISS > Subject: Re: [BLISS] WGLC for > draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a > PUBLISH affects the correct CECE > > 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 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >
- Re: [BLISS] WGLC for draft-ietf-bliss-call-comple… Worley, Dale R (Dale)
- Re: [BLISS] WGLC for draft-ietf-bliss-call-comple… Christer Holmberg