Partager via

3.3.5.1 Processing a Self SUBSCRIBE Request

  • Article

 

SIP protocol clients subscribe to self data after sending the REGISTER request as part of the sign-in sequencing rule. Self SUBSCRIBE is used to retrieve roaming self-state, which is containers, publications, subscribers and delegates, from the server. It is also used as the synchronization mechanism between multiple endpoints. That is, when another endpoint of the same user causes any self state, which is one of containers, subscribers, publications, or delegates, to change, all self subscribers are notified. An example is an endpoint that changes presence state from "online" to "busy." In such a case, all of the user's endpoints are expected to change state to "busy." State change, or category publication, causes all endpoints to be notified and to become synchronized as a result. Similarly, when an endpoint adds a container member, all other endpoints are notified so that the change is reflected in the user interface.

In the sample in section 4.4.1, the user subscribes to containers, categories, subscribers and delegates. It is possible to subscribe to any combination of the four roaming types, which are categories, containers, subscribers and delegates.<35> SIP protocol clients ordinarily subscribe to all four types.

The content of the SUBSCRIBE request is described by the XML schema that can be found in section 6. The schema allows the SIP protocol client to define, as well as subsequently modify, the list of roaming types, or scope, that are subscribed to. The roaming type list in each self SUBSCRIBE request that is sent using the same SUBSCRIBE dialog overwrites the roaming type list stored on the server. If an initial self SUBSCRIBE request lists "categories" and a subsequent request lists "subscribers", the resulting SUBSCRIBE dialog scope on the server will be "subscribers".

Each user endpoint creates a single self SUBSCRIBE dialog with the server with all four roaming types. The server SHOULD restrict the number of self subscription dialogs to one by allowing subsequent enhanced presence self SUBSCRIBE dialog creation requests from the same user endpoint while terminating the existing dialog by sending a NOTIFY with Expires set to zero.

After receiving a request to create a self SUBSCRIBE dialog, the server parses the "roamingList" to determine the scope defined by this request. Based on this scope, which is a combination of "containers", "categories", "subscribers", and "delegates", the server queries its internal state to gather the information necessary to generate the XML documents defined in section 2.2.2.3. If this is a dialog creation request, a new self subscription dialog, SelfSubscriptionDialogEntry, is created. Otherwise, the existing dialog is updated. The server MUST return all data defined in the scope, even in the case of a subscription refresh request.

If the UAC is in survivable mode, as specified in [MS-SIPREGE] section 3.1.1.5.1, the server MAY not create a new self subscription dialog, SelfSubscriptionDialogEntry, even if this is a dialog creation request.<36>

In the case of a polling self subscribe, the server MUST NOT store the SelfSubscriptionDialogEntry.

If the self subscription operation is successful, the server MUST return a 200 OK response. A typical SIP response to a self subscription appears in section 4.4.2. This is a piggybacked 200 OK response to a SUBSCRIBE request.