3.7.5.5 Generating a 200 OK or NOTIFY Response to an MSRTC SUBSCRIBE Request

The server MUST send out a 200 OK with the presence document if the Supported header field in the subscription request contains "ms-piggyback-first-notify". For details about "ms-piggyback-first-notify", see [MS-SIP] section 3.4.5.1. Otherwise, the server MUST generate a NOTIFY request in response to an MSRTC subscription request.

In addition, each operation that causes a change in the legacyInterop category instance or instances in the container that the request resolved to, generates a NOTIFY response on an MSRTC subscription dialog. An example of such an operation is an endpoint that publishes a new presence state that changes the value of a legacyInterop category instance by the computing function. These operations can also be server actions, such as the expiration of publications.

While the MSRTC NOTIFY response is generated, the server checks all SubscriptionDialogEntry instances of type MSRTC that involve this publisher and sends a NOTIFY response to the subscribing endpoints of the subscriber with the new data.

A sample 200 OK response to a SUBSCRIBE request is found in section 4.11.

The Content-Type header field MUST be set to "text/xml+msrtc.pidf".

The server retrieves the legacyInterop category instance from a resolved container for this subscription. For details, see section 2.2.2.7.6.

The server MUST create the XML body for the MSRTC NOTIFY response with the following elements and attributes. For details on the format of this XML, see section 2.2.2.9.

availability: The server SHOULD generate this element with the following attribute.

aggregate: The server SHOULD generate the value of this attribute as shown in the table that follows this list.

activity: The server SHOULD generate this element with the following attribute.

aggregate: The server SHOULD generate the value of this attribute as shown in the table that follows this list.

displayName: The server SHOULD generate this element with the following attribute.

displayName: Display name of the publisher. The server MAY get the value of this attribute from a Directory Service (DS)<39>.

email: The server SHOULD generate this element with the following attribute.

email: E-mail address of publisher. The server MAY get the value of this attribute from a DS<40>.

phoneNumber: The server SHOULD generate this element with the following attribute.

number: Phone number of publisher. The server MAY get the value of this attribute from a DS<41>.

aggregate: The server SHOULD generate this element with the states subelement.

state: The server SHOULD generate this element with the following attributes. The server MUST generate the value of this element as shown in the table that follows this list. The return value MUST equal the token value retrieved from the legacyInterop category instance.

avail: The server SHOULD generate the value of this attribute as shown in the table that follows this list.

xsi:type: The value SHOULD be "userState".

The server MUST use the availability and token attribute values from the legacyInterop category instance to create MSRTC elements and attributes as shown in the following table.