Hi Paul, Comment below.
>I'm struggling to make sense of this conceptually. >Having the To contain one address, and the R-URI have some entirely >unrelated address seems very bizarre. >It sounds like you are trying to model this as if the monitor, which is >an agent of the callee, was a presence server for the caller. That >doesn't make much sense to me. But perhaps I'm just not thinking about >it correctly. Is there a better way to conceptualize this? You are exactly right in you perception that the monitor (that manages the queue) is the callee agent and presence server aggregates the presence state of the caller. This is the whole concept of the current service architecture. We were trying to solve the dilemma of active change of the queue state of the callee by the caller. The queue state at the monitor is the property of the callee and thus can/shall not be directly affected by the caller. Yet we need this possibility to influence the queue state during the suspend/resume procedures. The use of the PUBLISH requests with monitor as R-URI target allows to route the information about the suspend/resume to the monitor. The monitor than can use status of the caller identified by the To: header to suspend or resume the callers place in the queue. In this case monitor implements both queue management and presence functionalities. The overall concept allows the queue function and the presence server function to be coupled in the monitor or they can be decoupled using the SUB/NOT procedures. The coupled option allows the service to be free from dependency on the availability of the presence server on the caller side. The decoupled option gives the greater flexibility. For the coupled option to work we came with the idea of having different URIs in the R-URI and To header. R-URI points to the monitor coupled with the presence server and To: header indicates that this s the presence information of the caller. The monitor than can use the received presence status of the caller to change it's state in the queue. >Having the monitor subscribe to the presence of its subscribers seems >acceptable. Its just a matter of figuring out how to arrange it. I don't >think there need be any passing of a special URI for the presence >server, because the caller's AOR should serve that purpose. Knowing that >the caller supports presence could be handled using >callerprefs/calleecaps. (In this case it would really be caller >capabilities.) Another way would be for the caller to REFER the monitor >to a SUUBSCRIBE for presence. REFER is a clear procedure, but it can be considered as a bit of an overkill. Passing an indication of some sort like caller-prefc/caps in the initial SUBSCRIBE to the monitor looks good to me. >OTOH, its far from clear to me that this is preferable to the existing >proposal for the candidate caller to unsubscribe when it doesn't want to >be called back. Why? Could you describe the issue? Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
