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: [email protected] Check us out at www.digium.com & www.asterisk.org _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
