Huelsemann, Martin wrote:
>> 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.
>
>
> 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.
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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
