Subject: [Simple] SIP multisubscription

From: [email-masked]
Date: Mon, 8 Aug 2005 12:25:53 +0200

Hi all,

because of some misunderstandings in handling of multisubscription there becomes a need to some discussion.

What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE request from the client side that does not specify document parameter in its Event header. The request is then considered as subscription to all documents that owns the user specified in To header. As far as I know, no specification explains sufficiently how this request should be interpreted. 

There are three fundamental ways how to process the request.

1. Process the multisubscription as it is, so treat it as single subscription in single dialogue. One initial Notification is sent; the client is informed about changes in this dialogue.

2. Internaly divide the multisubscription into several single subscriptions to single documents but the subscription is served in single dialog. In case the user owns N document, there is sent N initial subscription, each expires individually; the client is then informed about changes of single documents.

3. Internaly divide the multisubscription into several single subscriptions to single documents and establish multiple diagolues. The client is then informed about changes in separate dialogues. Rest of behavior is the same as in the previous case.

However, in the subsequent handing there could occur some problems.

(ad1) If we consider the multisusbcription as the subscription to all documents in-one then what about the documents that are created after that subscription. Should the server subscribe document created after the subscribe request ? Another problem: notification shall contain information about affected document and header Subscription-State holds the state of the subscription. If more changes occur (one document is deleted, one document is modified) - the diff format holds both changes but contains only one Subscription-State header.

(ad2) If we divide multisubscription into separate subscriptions how to handle subsequent multisubscription refreshment if some of these subscriptions changed its state (e.g. the document was deleted), or one of them has been expired during subscription refresh activity (ie. there is an inconsistence in state of the subscriptions).

(ad3) This option is from the logical point of view the most suitable, but it not used because it is little bit unnatural according to model: 1 request - 1 confirmation.

The general question could be stated as "How to handle the multisubscription with the respect to subsequent events involving documents removal, subscription refreshments and expirations?".

Thanks for suggestions, explanataions, comments in advance,

Martin Hynar 

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail [email-masked]

Technologicka 372/2
CZ-708 00 Ostrava 

www.tietoenator.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Aug 2005 13:59:11 -0500

After we nailed down the requirements, I was actually going to propose 
something very similar (except that the requested packages would be 
explicitly specified -- you don't want a devices getting MWI unless it 
supports it, for example). My initial thoughts are that the mechanism 
would be nearly identical to the work we did in the event-list 
specification.

However, I think it would be prudent to defer the discussion of 
mechanism until after we come to agreement on requirements. And, once we 
do get to mechanism, I believe we'll want to pursue most of the 
specification in SIP rather than SIMPLE. (We made what appears, in 
retrospect, to be a mistake in pursuing event-list in SIMPLE, and it has 
suffered some severe procedural delays as a consequence).

After this and a few related conversations converge, I will likely be 
starting a discussion in SIP around spinning up a 3265bis draft -- both 
to fix know errors in the existing specification and to take into 
account additional requirements that have been discovered as a result of 
operational experience. Given that such work is likely to start 
relatively soon, I would be inclined to include the ability to subscribe 
to multiple event packages in a single subscription in that updated 
draft rather than pursue it as a separate effort.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Aug 2005 19:19:38 -0400

I would like to emphasize the need to carefully address requirements. 
While lots of people seem interested in some form of unsolicited NOTIFY, 
or implicit subscription, or multisubscrption, or register coupled 
subscription, and all seem to want this in order to minimize 
*something*, its pretty clear that all the people aren't thinking of 
minimizing the same thing. Some things that may be large for a lot of 
subscriptions that might want to be optimized are:

- total number of watcher messages
- total number of notifier messages
- watcher bandwidth
- notifier bandwidth
- amount of watcher subscription state
- amount of notifier subscription state
- total number of message hops overall
- peak message rate at some event
   (e.g. at initial registration)
   experienced at:
   - watcher
   - notifier
   - state agent
- minimizing reliance on network servers
- maximizing reliance on network servers

The ideal mechanism will depend on which optimization we are trying to 
achieve.

	Paul

Adam Roach wrote:
>> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE 
>> request from the client side that does not specify document parameter 
>> in its Event header. The request is then considered as subscription to 
>> all documents that owns the user specified in To header. As far as I 
>> know, no specification explains sufficiently how this request should 
>> be interpreted.
>> 1. Process the multisubscription as it is, so treat it as single 
>> subscription in single dialogue. One initial Notification is sent; the 
>> client is informed about changes in this dialogue.
>>
>> 2. Internaly divide the multisubscription into several single 
>> subscriptions to single documents but the subscription is served in 
>> single dialog. In case the user owns N document, there is sent N 
>> initial subscription, each expires individually; the client is then 
>> informed about changes of single documents.
>>
>> 3. Internaly divide the multisubscription into several single 
>> subscriptions to single documents and establish multiple diagolues. 
>> The client is then informed about changes in separate dialogues. Rest 
>> of behavior is the same as in the previous case.
>>
>> (ad1) If we consider the multisusbcription as the subscription to all 
>> documents in-one then what about the documents that are created after 
>> that subscription. Should the server subscribe document created after 
>> the subscribe request ? Another problem: notification shall contain 
>> information about affected document and header Subscription-State 
>> holds the state of the subscription. If more changes occur (one 
>> document is deleted, one document is modified) - the diff format holds 
>> both changes but contains only one Subscription-State header.
>>
>> (ad2) If we divide multisubscription into separate subscriptions how 
>> to handle subsequent multisubscription refreshment if some of these 
>> subscriptions changed its state (e.g. the document was deleted), or 
>> one of them has been expired during subscription refresh activity (ie. 
>> there is an inconsistence in state of the subscriptions).
>>
>> (ad3) This option is from the logical point of view the most suitable, 
>> but it not used because it is little bit unnatural according to model: 
>> 1 request - 1 confirmation.
>>
>> The general question could be stated as "How to handle the 
>> multisubscription with the respect to subsequent events involving 
>> documents removal, subscription refreshments and expirations?".
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Aug 2005 09:19:20 -0400

Based on your clarification in another message I think I now understand 
enough to comment. Inline...

	Paul

> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE request from the client side that does not specify document parameter in its Event header. The request is then considered as subs…

The parameters that refer to documents are strictly a part of the 
sip-profile event package, not a feature of the general event mechanism.

> 3. Internaly divide the multisubscription into several single subscriptions to single documents and establish multiple diagolues. The client is then informed about changes in separate dialogues. Re…

 From the point of view of 3265, this is a single subscription. The 
parameters to the event type merely qualify how the notifier processes 
this subscription. They cannot cause it to become more than one 
subscription, or more than one dialog.

> (ad1) If we consider the multisusbcription as the subscription to all documents in-one then what about the documents that are created after that subscription. Should the server subscribe document c…

The interpretation of how the parameters affect the subsequent 
processing is something that must be addressed by the specification of 
the particular event package. It must simply specify under what 
circumstances it will send notifications and what they will contain.

> (ad2) If we divide multisubscription into separate subscriptions how to handle subsequent multisubscription refreshment if some of these subscriptions changed its state (e.g. the document was delet…

IMO, as noted above, there is way this can be a valid interpretation of 
what is to be done.

> (ad3) This option is from the logical point of view the most suitable, but it not used because it is little bit unnatural according to model: 1 request - 1 confirmation.

Same comment as for ad2.

	Paul