Paul K. has suggested that we treat call-completion subscriptions as
being subscriptions to "the status of the queue" (the queue for the
destination AOR), but that filtering is in effect such that each
subscriber sees only the status of the queue entry that coresponds to
his subscription.
This idea seems to me to be enough to align our use of subscriptions
with the formal model of RFC 3265, and thus allow us to have
call-completion subscriptions operate like everyone wants them to
without adding any further machinery.
It also provides a way to add future extensions that provide
special subscriptions that show the entire queue.
Within that model, we need to make the following wording changes:
(I've shortened CECE ("calls eligible for completion entity") to CCE
("call-completion entity").)
Section 5
The callee's monitor manages CC for a single URI. This URI is
likely to be a published AOR, or more likely "an AOR without its
voicemail", but it may be as narrowly scoped as a single UA's
contact URI. The monitor manages a dynamic set of call-completion
entities (called "CCEs") which represent CC requests, or
equivalently, the existing incoming call-completion subscriptions.
This set is also called a queue, because a queue data structure
often aids in implementing the monitor's policies for selecting
CCEs for CC recall.
Each CCE has an availability state, which is either "available"
(for recall) or "not available" (for recall). It is not visible
via subscriptions.
Each CCE has a recall state which is visible via subscriptions.
The recall state is either "queued" or "ready".
Each CCE carries the From URI of the SUBSCRIBE request that caused
its creation.
CC subscriptions arrive at the the monitor by being addressed to
the managed URI, or URIs the monitor returns in Call-Info headers.
The request URI of the SUBSCRIBE request determines the queue to
which the resulting CCE is added. The resulting subscription
reports the status of the queue. The base event data is the status
of all the CCEs in the queue, but the data returned by each
subscription is filtered to report only the status of that
subscription's CCE. (Further standardization may define means for
obtaining more comprehensive information about a queue.)
When a CCE is created, it is given the availability state
"available" and recall state "queued".
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 CCE
is identified by the request-URI (if it was taken from a
call-completion event notification and identifies the CCE) or the
From URI of the request (matching the From URI recorded in the
CCE). Receipt of a PUBLISH with 'status' of 'open' sets the
availability state of the CCE to 'available'; 'status' of 'closed'
sets the availability state of the CCE to 'not-available'.
The monitor MUST select for recall only CC requests whose CCE's
have availability state 'available', and for which the callee
appears to be available considering the 'm' value of the CCE.
Within that constraint, the monitor's selections are determined by
its policy. Often, a monitor will choose the acceptable CCE that
has been in the queue the longest. When the monitor has selected a
CCE for recall, it changes the CCE's recall state from 'queued' to
'ready', which triggers a notification on the CCE's subscription.
If a selected subscriber then suspends its request by sending a
PUBLISH with status 'closed', the CCE becomes not-available, and
the monitor changes the CCE's recall state to 'queued'. This may
cause another CCE (e.g., that has been in the queue for less time)
to be selected for recall.
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
