Subject: Re: [Simple] SIP multisubscription

From: "Andrew Allen" <[email-masked]>
Date: Tue, 9 Aug 2005 17:23:26 -0400

Paul

Another one the number of refresh Subscriptions. Big battery issue for mobile devices.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Adam Roach <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Mon Aug 08 19:19:38 2005
Subject: Re: [Simple] SIP multisubscription

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:
> 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
> 
> [email-masked] wrote:
> 
>> 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
>>
>>  
>>
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

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