Subject: [SPIRITS] Subscribing to multiple DPs

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 15 Jan 2003 10:29:30 -0600

Any thoughts on subscribing to multiple DPs in one SUBSCRIBE request?
For instance, if I am implementing a presence capability on a black
phone, I would typically be interested in the following events:
answering calls and attempt to make a call.

So far in our discussion in the protocol I-D, we do not explicitly
prohibit subscriptions to multiple DPs, nor to we explicitly condone
it.  However, the examples in the text all have subscriptions to a
single DP.

Any thoughts and views would be appreciated.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 15 Jan 2003 11:07:27 -0600

I realize that multiple DP/events subscribe would be a handy thing to have.
In my opinion, single DP/event subscription is a much cleaner thing to 
do. If you need to implement a service that asks for multiple subscribes 
- just do exactly that: issue multiple SUBSCRIBE loops. Much, much 
easier to control and lighter on security threats. Drawback: creates 
more network traffic.
It is a good discussion, let's continue it.

-Alec

-- 
Alec Brusilovsky
[email-masked]
Naperville, IL USA
+1.630.369.8196

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 15 Jan 2003 11:19:42 -0600

Alec Brusilovsky wrote:
> - just do exactly that: issue multiple SUBSCRIBE loops. 

But all these SUBSCRIBEs logically belong to the same service.  I think
that we should we should physically end up representing the subscription
to each such DP in the same SUBSCRIBE request.  I would expect one, and
only one NOTIFY when any of these events occur.  What are my
expectations if I send multiple SUBSCRIBEs?  Am I getting multiple
NOTIFYs?

> Much, much 

Using a different SUBSCRIBE request for each DP which results in the
same service appears (to me, anyway) cumbersome and network and
processing intensive.  Furthermore, after the NOTIFYs arrive and the
subscription expires, it is easy to re-subscribe using the single
SUBSCRIBE request instead of sending a flurry of multiple SUBSCRIBEs.

Cheers,

- vijay

---

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 15 Jan 2003 11:41:30 -0600

So, where is the logical aggregation of the DPs (events) into one 
service happening? What is the same DP (event) is utilized in multiple 
servises? Than we are up to a real mess. Sometimes creating extra 
traffic is the lesser of evils...
-Alec

Vijay K. Gurbani wrote:

>> In my opinion, single DP/event subscription is a much cleaner thing 
>> to do. If you need to implement a service that asks for multiple 
>> subscribes - just do exactly that: issue multiple SUBSCRIBE loops. 
>
>
>> Much, much easier to control and lighter on security threats. 
>> Drawback: creates more network traffic.
>
>

-- 
Alec Brusilovsky
[email-masked]
Naperville, IL USA
+1.630.369.8196

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 15 Jan 2003 11:46:59 -0600

Alec Brusilovsky wrote:
> servises? Than we are up to a real mess. 

Ah, okay.  I see your point...

- vijay

---

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 16 Jan 2003 11:26:26 -0600

Vijay,

I also better see your point after our phone chat yesterday: aggregation 
of multiple DPs into a SET when SUBSCRIBE would open nice options for 
those SPIRITS services that require logical OR of the DPs.
In that case, I would like to propose to limit this option to the DPs, 
belonging to the same half of the BCSM (i.e., Originating or Terminating).
Example: OAA and O_Answer may be in one SUB/NOT; however, OAA and TAA 
may not.

Also, as you pointed, in case of NOTIFY, resulting from a "SET" 
SUBSCRIBE, the whole "SET" SUBSCRIBE is expired, even though only one of 
the DPs from the SET has been activated. In the case when the other DPs 
from the SET are of interest, specific NOTIFY has to be issued for the 
rest of DPs in the SET. In most cases it is easier to issue simple 
singular SUB/NOT pairs.

How does this sound?

-Alec

Vijay K. Gurbani wrote:

>> service happening? What is the same DP (event) is utilized in 
>> multiple servises? Than we are up to a real mess. 
>
>

-- 
Alec Brusilovsky
[email-masked]
Naperville, IL USA
+1.630.369.8196

---

From: Deepak Gandotra <[email-masked]>
Date: Fri, 17 Jan 2003 11:54:58 +0500 (GMT+0500)

Alec,

You have proposed to maintain the same half of the BCSM in one SUB message
but it may be desired to subscribe to both the OAA and the TAA DPs in
one SUB message as may be required for a "centralized charging" kind of
service which allows the user to make calls while the charges are
maintained/administered centrally. In this service all the incomming call
and the outgoing call instances have to be informed to the "server". It
would thus be required to allow the SUB message to carry the subscription
requests irrespective of the BCSM half.

Further I would propose that the "Expires" parameter be sent seperately
for all the DPs sent in the SUB message as they would have different
meaning to the service and thus may have a different "time to live" span. 

Another "Expires2" parameter may be sent in the SUB message, which would
would "bind" the Expires parameter associated with each DPs, indicating
the expiry time of the complete set of subscriptions in the SUB
message. This would mean that the DP subscriptions can expire before the
"Expires2" parameter and all the DP subscriptions would expire when
"Expires2" completes.  

DG,

Research Engineer,
CDOT, Delhi.

________________________________________________________________________________

           Whatever the mind can conceive and believe, it can achieve.
________________________________________________________________________________

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 17 Jan 2003 10:22:39 -0600

Deepak Gandotra wrote:
> Alec,
> 
> You have proposed to maintain the same half of the BCSM in one SUB 
> message but it may be desired to subscribe to both the OAA and the 
> TAA DPs in one SUB
[...]

I believe Alec wanted to err on the side of being overly cautious;
hence the DPs belonging to one half of the BCSM.  While I agree that
such a strategy leaves no ambiguity -- after all, as far as I can
see it, the DPs naturally follow a OR mechanism; i.e. if the DPs
are armed, they trigger sequentially -- I think we can do better.

The problem with having DPs from both halves is race condition.  Let
me illustrate with an example.  Let's say that a service provider
wants to implement some kind of presence service on a POTS device
(i.e. black phone).  Thus the events of interest are OAA (caller
attempts to make a call, which indicates presence), TA (callee gets
a call, which again indicates presence) and T_Busy [TB] (callee
already on a call, which indicates presence).  So, a SUBS will contain
the three DPs: OAA, TA, and TB.

Now, let's say that a user picks up the phone and makes a call (thus
triggering OAA in O_BCSM), and at the same time, a call arrives for
the user, resulting in a T_BCSM being initialized and either TA or, most
probably TB firing.  Note that the results of the race condition itself
are not egregious (certainly not life-threatning), but how the system
deals with this is interesting (more on this later).  Also note that we
would have the same race condition if two different SUBS were sent --
one with OAA and the other with TA and TB.  So, we cannot avoid the race
condition even if we sent two SUBS.

The question now boils down to what is the behavior of the SPIRITS
notifier when such a race condition occurs?  Should it collate both
of these events into one NOTIFY and send it out?  Or should it send
out separate NOTIFYs for each event?  The current SPIRITS protocol
I-D states that once a DP fires, the subscription is terminated (it
can be resurrected again if desired).  Thus this behavior dictates
that SPIRITS notifier wait for such race conditions to occur
before sending the NOTIFY.  Of course, the current I-D does not take
in account multiple DPs, so this behavior may be simplistic.

This leads us logically to your next point, which basically asks what
happens to the remaining DP when a DP from a set of DPs fire?

> meaning to the service and thus may have a different "time to live" span.

There are two ways to deal with this; one is as you suggest above.  How-
ever, the crucial part missing in this is the dialog created by the
initial SUBS.  To me, it seems logical that I associate a set of DPs
with a dialog.  When the dialog expires, the set of DPs that have not
fired yet should be disarmed.  Remember, the SPIRITS subscriber can
always re-arm the DPs through another SUBS.

If we associate an expiry duration with an individual DP, I think we
may run into feature interaction problems where a DP armed for a
previous service (but did not fire) now needs to be armed for a new
service.  Which service gets precedence?  Furthermore, if the dialog
has expired, does it make sense to keep the DP armed.

> "Expires2" parameter and all the DP subscriptions would expire when

But I believe that this type of mechanism complicates dialog and DP
management, not to mention adding a new header to the SIP dictionary.
I would like to avoid both of these if I can.  If you want the semantics
of n-1 DPs from a set being active after one fires, I think multiple
SUBS would be the best way to deal with it.

So, my proposal is that:

    (1) We allow subscription to multiple DPs (we can scope it as a
        MAY).  DPs can be drawn from both halves.
    (2) When any DP from this set fires, a NOTIFY is sent out immediately
    (3) The NOTIFY serves to terminate the SUBS and dis-arm the
        remaining DPs that did not fire.

The XML for subscription to multiple DPs can look as follows (working
from our 'presence' for POTS line example):

<?xml version="1.0"?>
<spirits-event>
     <DP INDPs="OAA" Mode="N">
       <CallingPartySubaddress>16302240216</CallingPartySubaddress>
     </DP>
     <DP INDPs="TA" Mode="N">
        <CalledPartySubaddress>16302240216</CalledPartySubaddress>
     </DP>
     <DP INDPs="TB" Mode="N">
        <CalledPartySubaddress>16302240216</CalledPartySubaddress>
</spirits-event>

Note the salient change is that there can now be more than one <DP>
element.  Any parameters that are part of that DP will now become
sub-elements of the <DP> element.  I think that this is powerful and
extensible enough that we can subscribe to 1 DP or multiple DPs.  At
the same time, we do not proscribe that "for black phone presence, thou
shalt use the following DPs..."  The selection of DPs is left to the
service provider.

Comments?

Thanks,

- vijay

---

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 17 Jan 2003 10:47:22 -0600

OK. Let me summarize the discussion that we just had:

    * It is important to be able to SUBSCRIBE to a SET of DPs and than
      get NOTIFY when ANY ONE of them becomes activated;
    * After subsequent NOTIFY the corresponding SUBSCRIBE is spent,
      regardless of the number of unencountered DPs. The SPIRITS Server
      needs to issue a new SUBSCRIBE in order to renew the subscription;
    * The safest way is to issue a single DP SUBSCRIBEs, so we are
      putting this SET of DPs SUBSCRIBE as a valid option and use MAY in
      the protocol specs.

Did I miss something?

Regards,
Alec

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 22 Jan 2003 11:40:54 -0600

>       putting this SET of DPs SUBSCRIBE as a valid option and use MAY in

Just to be pedantic one more thing: after the NOTIFY is sent out, the
unencountered DPs must be cleared (if they are EDPs of course).

Unless I hear otherwise from folks on the list, I will put this behavior
in the protocol I-D.

Thanks,

- vijay