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
