While this is certainly possible, it *guarantees* that the CC
subscription will only that one caller's view of the queue.
It would be nice if the one event package could serve double duty,
providing not only that functionality, but also providing a view of the
complete queue to suitable privileged subscribers.
My suggestion to have the subscription be to the queue itself, but be
filtered according to the privilege of the subscriber, provides both
functions.
Thanks,
Paul
Kevin P. Fleming wrote:
On 07/22/2010 10:42 PM, WORLEY, Dale R (Dale) wrote:
We use PUBLISH to suspend and resume CC requests. But it seems to me that we
haven't got an effective way for the PUBLISH to identify which CC subscription
it modifies.
A very effective solution would be to send the PUBLISH in the subscription dialog, as
that would make it unambiguous which subscription the PUBLISH was for, but reusing
dialogs is not recommended any more. It also might be hard to implement within a
"subscribe/notify toolkit".
If the PUBLISH request is out-of-dialog, there are two general ways for it to
carry identification of the CC request: (1) the presentity in the PIDF body,
(2) the headers of the PUBLISH, and (3) the request-URI of the PUBLISH.
The PIDF presentity is probably not going to work, as it is likely to be
carried to the monitor unchanged from the agent. Given what SBCs are known to
do, there is no URI in the SUBSCRIBE which is assured of reaching the monitor
unchanged, so the monitor cannot effectively compare the PIDF presentity to any
feature of the subscriptions.
In regard to the headers of the PUBLISH, they are all subject to modifications
by SBCs. But I think we've previously discussed that SBCs are likely to make
*consistent* modifications to the From header, so that a SUBSCRIBE and a
PUBLISH coming from the same agent are very likely to arrive at the monitor
with the same From header, and requests coming from different agents are very
likely to arrive with different From headers.
Using the request-URI of the PUBLISH to identify the subscription has the advantage that the one thing SBCs must preserve is the actual destination of a URI. But to use it would require that each subscription be associated with a different URI.
For what it's worth, the implementation in Asterisk already provides a
unique request-URI for each CC subscription. Given the previous
discussion here on the list about having multiple subscribers see
different state even though they are subscribing to the same
request-URI, maybe a way to solve this in the draft is to just require
the creation of unique request-URIs whenever CC is offered.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
