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

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: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Dienstag, 27. Mai 2008 13:52
> An: Hülsemann, Martin
> Cc: bliss@ietf.org; 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
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
> 
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss