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 PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Huelsemann, Martin > Sent: Friday, May 30, 2008 5:18 AM > To: [EMAIL PROTECTED] > Cc: [email protected]; Alexeitsev, D > Subject: Re: [BLISS] Use of the PUBLISH transaction for the > SUS/RESprocedures > > > 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. > > > > BR, Martin > > > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
