Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 2005 Ensuring that a PUBLISH affects the correct CECE

Christer Holmberg <> Thu, 04 November 2010 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 018213A692B for <>; Thu, 4 Nov 2010 12:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCalbLXAOrOp for <>; Thu, 4 Nov 2010 12:44:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D0FB43A6811 for <>; Thu, 4 Nov 2010 12:44:28 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b28ae00000135b-05-4cd30d266b4f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F2.79.04955.62D03DC4; Thu, 4 Nov 2010 20:44:38 +0100 (CET)
Received: from ([]) by ([]) with mapi; Thu, 4 Nov 2010 20:44:38 +0100
From: Christer Holmberg <>
To: "Worley, Dale R (Dale)" <>, Shida Schubert <>, BLISS <>
Date: Thu, 4 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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



> -----Original Message-----
> From: [] 
> 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