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
>