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

Huelsemann, Martin wrote:
> Hi, 
> 
> the use of the PUBLISH transaction to control the suspension and resume of a Call Completion queue position was previously discussed at the mail list. The outcome was, that it is not appropriate to change the state of the queue by targeting the information to the monitor's AOR.
> 
> At the last IETF meeting a different approach was discussed off-line. The caller sends it's own status information in PUBLISH with his own AOR in To: and From: headers. The Request-URI of this PUBLISH request contains the monitor AOR as received in the Call-Info header of the 486 response. 

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?

> In this case there is no change in the CC monitor (the queue) state done by the PUBLISH request directly, but either an indirect change of the state based on the information about the caller status. The CC monitor acts as a kind of a state composer, composing the state of the queue from the states of the different callers.
> 
> This architecture can even be extended to support the presence service directly. The caller (or the CC agent on behalf of the caller) can send the URI of his presence server to the monitor in a parameter of the initial CC SUBSCRIBE request. The monitor would then subscribe to this URI and receive the presence status of the caller from his presence server. The caller UA (CC agent) would than have to send his presence information only to his regular presence server.

This makes more sense to me. But I might spin it a little differently.

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.

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.

> The interworking of the SUS/RES procedures from the PSTN/TCAP are also quite simple when the PUBLISH method is used. Appropriate TCAP SUSPEND indication would be mapped to the "closed" presence PIDF state and RESUME to the "open" PIDF state transported in the PUBLISH method.
> 
> Comments are welcome. 
> 
> 
> BR, Martin
> 
> 
> 
> 
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
> 
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss