Huelsemann, Martin wrote:
> 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.
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
> 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 PROTECTED] [mailto:[EMAIL PROTECTED]
>> Im Auftrag von Paul Kyzivat
>> Gesendet: Dienstag, 27. Mai 2008 13:52
>> An: Hülsemann, Martin
>> Cc: [email protected]; Alexeitsev, Denis
>> Betreff: Re: [BLISS] Use of the PUBLISH transaction for the
>> SUS/RESprocedures
>>
>>
>>
>> Huelsemann, Martin wrote:
>>> 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.
>>
>> 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
>>
>>> BR, Martin
>>>
>>>
>>>
>>>>> 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
>>
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
