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

Re: [Simple] SIP multisubscription

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

	Paul

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.

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

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.

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.

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.

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 deleted), or one of them has been expired during subscription refresh activity (ie. there is an inconsistence in state of the subscriptions).

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

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