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

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Nov 2010 20:44:37 +0100

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: [email-masked] [mailto:[email-masked]] 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>