[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Martin.Hynar at tietoenator.com 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 martin.hynar at tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava
www.tietoenator.com

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple





_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple