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. More about this later... Dale _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
