Huelsemann, Martin wrote:
>
> Also he was probably not thinking about call-completion, I think Kant
> supports me by introducing the counter-razor "The variety of beings should
> not rashly be diminished."
>
> ;-)
It would be hard to make the case that this decision is being made
rashly. :-)
Paul
> BR, Martin
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Im Auftrag von Hülsemann, Martin
>> Gesendet: Dienstag, 3. Juni 2008 16:06
>> An: [EMAIL PROTECTED]
>> Cc: [email protected]; Alexeitsev, Denis
>> Betreff: Re: [BLISS] Use of the PUBLISH transaction for the
>> SUS/RESprocedures
>>
>> In SS7 there is one 'dialog' during the whole lifetime of a
>> queue entry (incl. sus/res), and there are explicit requests
>> for suspending and resuming, which differ from activating and
>> deactivating CC.
>> So a SUBSCRIBE on the SIP side could be mapped to a
>> CcbsActivate or CcbsResume on the SS7/TCAP side. The
>> termination of the subscribe could be mapped to a CcbsCancel
>> or CcbsSuspend.
>>
>> Further most gateways are very simple machines, not capable
>> to renember a state regarding CC. So the gateway will not be
>> able to map a re-SUBSCRIBE to a CcbsResume if there was a
>> un-SUBSCRIBE before. And it's not clear if the re-SUBSCRIBE
>> will reach the same gateway once the subscription dialog was
>> terminated.
>>
>> So if we want to have a full interworkable CC solution I
>> think we need explicit sus/res requests also on the SIP side.
>>
>> /M.
>>
>>
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>> Gesendet: Dienstag, 3. Juni 2008 14:38
>>> An: Hülsemann, Martin
>>> Cc: [email protected]; Alexeitsev, Denis
>>> Betreff: Re: AW: AW: AW: [BLISS] Use of the PUBLISH
>>> transaction for the SUS/RESprocedures
>>>
>>>
>>>
>>> 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
>>
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
