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."
;-) 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
