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