Huelsemann, Martin wrote:
> Yes, describing it in the way you did it makes sense. So for a pure internet
> service also IMO it would work.
>
> But another nice side effect of the usage of PUBLISH would have been, that it
> would have been interworkable with solutions in (the usual) other networks,
> where there are explicit suspend and resume requests. And as the gateways
> won't be stateful regarding CC, it will not be possible to map a un-subscribe
> and re-subscribe in a suspend or resume request.
Why isn't the subscribe/unsubscribe sufficient for driving the
interworking with other networks?
> So for PUBLISH, do you think it's generally a bad implementation, or do you
> think it is too much overhead for only sus/res, but that under the aspect of
> interworking it could however be an acceptable solution?
I'm inclined to invoke Occam's Razor here - the PUBLISH introduces extra
machinery that (IMO) adds no extra value.)
Paul
> BR, Martin
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Gesendet: Freitag, 30. Mai 2008 15:32
>> An: Hülsemann, Martin
>> Cc: [email protected]; Alexeitsev, Denis
>> Betreff: Re: AW: AW: [BLISS] Use of the PUBLISH transaction
>> for the SUS/RESprocedures
>>
>>
>>
>> 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
