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

["Kevin P. Fleming" <[e-mail]>]

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [e-mail]
Check us out at www.digium.com & www.asterisk.org