Subject: Re: [BLISS] Use of the PUBLISH transaction for the SUS/RESprocedures

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 3 Jun 2008 11:27:27 +0200

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.

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?

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Freitag, 30. Mai 2008 15:32
> An: Hülsemann, Martin
> Cc: [email-masked]; 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-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2008 08:38:24 -0400

> 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…

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 acceptab…

I'm inclined to invoke Occam's Razor here - the PUBLISH introduces extra 
machinery that (IMO) adds no extra value.)

	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 3 Jun 2008 16:05:38 +0200

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.

> Gesendet: Dienstag, 3. Juni 2008 14:38
> An: Hülsemann, Martin
> Betreff: Re: AW: AW: AW: [BLISS] Use of the PUBLISH 
> transaction for the SUS/RESprocedures
> 
> 
> 
> > 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.
> 
> > 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?
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 3 Jun 2008 16:18:38 +0200

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

> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Hülsemann, Martin
> Gesendet: Dienstag, 3. Juni 2008 16:06
> An: [email-masked]
> 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.
> 
> 
>  
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2008 16:12:27 -0400

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2008 16:12:58 -0400

> 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 befor…

I'm not sure I understand what you are saying here.

If the GW is too dumb to remember the CC state, then how is it going to 
handle a subscription?

How does separating sub/not from publishing for deactivate/resume solve 
the problem of multiple GWs? Are you thinking that the PUBLISH will be 
sent within the subscribe dialog? (That would be a first. AFAIK PUBLISH 
is always out of dialog.)

Assuming the callee is on SS7, can the state of this SS7 CC 'dialog' be 
queried by the GW? Or is this state "write only"?

	Thanks,
	Paul

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 4 Jun 2008 11:06:20 +0200

> If the GW is too dumb to remember the CC state, then how is 
It can handle a subscription dialog on the one side and a TCAP connection on the other side. But it will not be able to renember the CC state of the users, it can only interwork CC requests.

> is always out of dialog.)
The PUBLISH would be sent to the monitor URI in general or to the gateway URI in case of SS7 interworking. The URI was learned from the CC indication (Call-Info header) in the 486.

> queried by the GW? Or is this state "write only"?
It cannot be queried, so it is write only, in both directions.

/M.