RE: [Simple] SIP multisubscription

[Martin.Hynar at tietoenator.com]

Hi,


I understand that rfc 3265 does not specify what to do with particular event-template. My problem lies in fact that there is no event-package for working with resource-lists (that is the only AUID I'm supporting). The only possibility is to use the sipping-config which introduces some workaround. The subsequent problem is that on one hand it allows "too much liberty" when selecting the target of subscription and on the other hand it does not specify how to handle it. What I am asking is if there is some way how to solve it now without the specification but complying everything stated in e.g. rfc3261, rfc3265.


Imagine the fundamental problem,

1. user U_1 has three documents with resource-lists AUID
2. another user U_2 subscribes them in one SUBECRIBE request
   ...
   Event: sip-profile;app-id=resource-lists
   ...
3. user U_1 deletes one of his documents
4. user U_2 is notified with NOTIFY request
   ...
   Event: sip-profile;app-id=resource-lists;document=doc1
   Subscription-State: terminated;reason=noresource

Questions:
Shall now the user U_2 consider its dialogue as terminated or not, there are still some documents that could be subscribed in this dialogue.
Shall the server consider the dialogue terminated?


Thanks much for helping response.



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