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

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 16 May 2008 12:00:51 +0200

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. 

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 May 2008 08:29:07 -0400

> 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 PUBL…

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?

> 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 par…

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.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 20 May 2008 13:50:38 +0200

Hi Paul,

Comment below.

>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.

>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.

>proposal for the candidate caller to unsubscribe when it doesn't want
to 

Why? Could you describe the issue?

Greetings,
Denis Alexeitsev

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 27 May 2008 06:28:01 +0200

The proposal to sort of publish to caller's supension and resumption state was also resulting from previous comments, that just unsubscribe to the call-completion information won't (or better: has not to) change the CC state. So when the monitor calculates who's next for CC, a unsubscribed caller ('s agent) would still be considered to be the next candidate for the CC call somehow if he is on top of the queue, which then of course would reduce the performance of the service.
To avoid this publishing sus/res information seems to be a valid and explicit solution.

BR, Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 May 2008 07:52:26 -0400

> To avoid this publishing sus/res information seems to be a valid and explicit solution.

IMO the unsubscribe was fine for this. It doesn't change the state of 
the callee, or of the queue of call attempts. But it removes the former 
subscriber from the list of those that are candidates for being 
notified. So a failed call attempt that is in the queue may remain at 
the head of the queue, but a call lower on the queue may be notified if 
there are no current subscribers for the higher entries.

I don't see how that impacts performance, aside from the hopefully 
negligible need to keep the entries with no subscribers in the queue.

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 28 May 2008 07:01:18 +0200

Hi Paul,

I think we agree that the unsubscribe won't change the CC state of any queue entries. So what will happen is that after some time the state of a certain entry will change from just 'queued' to 'ready-for-CC', idependently from if there is a subscription or not.
So for some time the entry will stay in the 'ready-for-CC' state, but no CC INVITE will arrive, and according to the service logic the entry will fall back to the 'queued' state.

As the user's agent only subscribes to a certain entry's CC state, no notification will be sent when this entry reaches the top of the queue. The time will pass, the entry will fall back to queued, the next entry reaches the top of the queue, and the monitor will notify that entry, if there is a subscription.

So I think we need a dedicated procedure to suspend an entry, which actually will change the state of an entry to 'suspended'.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Dienstag, 27. Mai 2008 13:52
> An: Hülsemann, Martin
> Cc: [email-masked]; Alexeitsev, Denis
> Betreff: Re: [BLISS] Use of the PUBLISH transaction for the 
> SUS/RESprocedures
> 
> 
> 
> > The proposal to sort of publish to caller's supension and 
> resumption state was also resulting from previous comments, 
> that just unsubscribe to the call-completion information 
> won't (or better: has not to) change the CC state. So when 
> the monitor calculates who's next for CC, a unsubscribed 
> caller ('s agent) would still be considered to be the next 
> candidate for the CC call somehow if he is on top of the 
> queue, which then of course would reduce the performance of 
> the service.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 May 2008 08:29:04 -0400

> So for some time the entry will stay in the 'ready-for-CC' state, but no CC INVITE will arrive, and according to the service logic the entry will fall back to the 'queued' state.

My assumption is that things move up the queue based on time and the 
removal of old and completed entries. So there could indeed be an entry 
at the top of the queue for which there is no subscription and so no 
notification. In that situation I would assume that you would notify the 
next lower entry in the queue that has a subscription, and accept the 
resulting call.

If the caller at the top of the queue eventually resubscribes, 
presumably it would receive a notification as soon as the notifier 
hasn't committed its resources to something else.

	Thanks,
	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 30 May 2008 06:18:01 +0200

> next lower entry in the queue that has a subscription, and accept the 

But if you notify the 2nd entry in the queue, that can only mean that the state of the this entry has changed from 'queued' to 'ready-for-CC', otherwise there would be no notification. And that change of the state of the 2nd can only have resulted from a change of the state of the top entry, which must have changed from 'queued' to 'suspended' somehow. The only event what could have changed the state is the receiving of the unsubscribe, which means that there is some kind of RPC combined with the unsubsribe.

This was approximately the argumentation of some colleagues when we discussed this some time ago, when our proposal also was to simply un-subscribe and re-subscribe for sus/res. And that's why we came up with a proposal for the explicit sus/res procedures now.

BR, Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 May 2008 09:32:08 -0400

> This was approximately the argumentation of some colleagues when we discussed this some time ago, when our proposal also was to simply un-subscribe and re-subscribe for sus/res. And that's why we c…

My take on this is that there should be no *direct* causative connection 
between the subscription and the state of the element being subscribed. 
As I recall, and early proposal had a parameter on the subscribe request 
that manipulated the state explicitly, and that seemed very wrong.

But IMO there is nothing wrong with the server having a *policy* for 
determining the state of the entries in the queue. And the policy can 
take into account whatever data it wants, including the presence of 
subscriptions to particular entries in the queue.

So for instance suppose that A, B, and C have made unsuccessful call 
attempts, and have been queued in that order. Each subscribed 
immediately after its attempt, and received an initial notification, but 
the callee has remained busy, so none has been given permission to do 
CC. All entries are in the 'queued' state.

Then A becomes busy and unsubscribes. This doesn't change its formal 
state at all, but then it doesn't matter, since nobody is observing it 
anyway. Its still queued. Non-visible state, available to the policy 
engine but not subscribers, indicates that there is no subscription.

At that point, the callee becomes available. The policy engine examines 
the queue and picks an entry to be the CC candidate. It chooses B, based 
on queue ordering and presence of a subscription. So the state of B's 
entry is changed to 'ready-for-CC'. Because that entry's state has 
changed, it generates a NOTIFY.

Now at that point, before B's CC attempt has succeeded or timed out, A 
may subscribe again. This does not change the event state of A's entry 
immediately. So the initial NOTIFY for this subscribe still says 'queued'.

Lets suppose that B never responds, and so the window of opportunity for 
B closes. The policy engine in the server may then change the state of 
B's entry back to 'queued', or may remove it. Lets assume its removed. B 
gets a final notification to that effect.

Now the policy engine notes that the callee is still available and 
nobody in the queue has been chosen for CC. So again it uses queue order 
and presence of subscription to pick an entry. This time it picks A. So 
A's entry state is changed to 'ready-for-CC' and A gets a NOTIFY to that 
effect.

Does that make sense?

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 30 May 2008 17:27:11 +0200

I get the impression here that Paul thinks there is some ordering in the
queue.

There is no requirement that this is so. While it may make sense that
oldest entries are processed first, the normal PSTN/ISDN service
requirements are only about completing calls between two available
parties. 

So in summary, I consider it incorrect to talk about the top of the
queue, or next entry in the queue. Entries in the queue may be selected
and processed by any algorithm that makes sense to the operator /
implementor.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Huelsemann, Martin
> Sent: Friday, May 30, 2008 5:18 AM
> To: [email-masked]
> Cc: [email-masked]; Alexeitsev, D
> Subject: Re: [BLISS] Use of the PUBLISH transaction for the 
> SUS/RESprocedures
> 
> > removal of old and completed entries. So there could indeed be an 
> > entry at the top of the queue for which there is no 
> subscription and 
> > so no notification. In that situation I would assume that you would 
> > notify the next lower entry in the queue that has a 
> subscription, and 
> > accept the resulting call.
> 
> 
> But if you notify the 2nd entry in the queue, that can only 
> mean that the state of the this entry has changed from 
> 'queued' to 'ready-for-CC', otherwise there would be no 
> notification. And that change of the state of the 2nd can 
> only have resulted from a change of the state of the top 
> entry, which must have changed from 'queued' to 'suspended' 
> somehow. The only event what could have changed the state is 
> the receiving of the unsubscribe, which means that there is 
> some kind of RPC combined with the unsubsribe.
> 
> This was approximately the argumentation of some colleagues 
> when we discussed this some time ago, when our proposal also 
> was to simply un-subscribe and re-subscribe for sus/res. And 
> that's why we came up with a proposal for the explicit 
> sus/res procedures now.
> 
> 
> 
> BR, Martin
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 May 2008 13:58:36 -0400

Keith,

Yes, I agree. My implication of an ordering has no material bearing on 
the discussion. The policy logic in the server needs to pick somebody to 
be given the opportunity to complete. It will probably want to take into 
account whethere there is a subscription so a notify can be sent, and 
other things, perhaps including age.

	Paul