Re: [BLISS] Call-completion issue 2005: PUBLISH destination

[Paul Kyzivat <[e-mail]>]

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.
>