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 protected] [mailto:[email protected]] > 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 protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
