Re: [BLISS] Use of the PUBLISH transaction for the SUS/RES procedures

 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
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss