Share via

3.2.5.6 Receiving a Play Request

  • Article

The server MUST first follow the steps specified in section 3.2.5.1.

The server MUST check with the higher layer that the URL that the client specified in the request is valid. If it is not, this is an error and the server MUST respond with a valid HTTP error status code, as specified in [RFC2616] section 10.

If the request specifies a client-id (section 2.2.1.4.5) token on a Pragma header, and the value matches the value of a Client-ID variable in some instance of the server's state, and the value of the corresponding Session-State variable is STREAMING, the server SHOULD treat this as an error and fail the request. The reason is that a Play request for a session that is already streaming could be an attempt to hijack a session.

If the request does not specify a client-id token on a Pragma header, the server MUST create new state by performing the initialization procedure defined in section 3.2.3.

If the request specifies a client-id token on a Pragma header, but the value of that token does not match the value of the Client-ID variable in any instance of the server's state, the server MUST either create new state by performing the initialization procedure specified in section 3.2.3 or fail the request. Also, in this case, if the request is successful, the response MUST specify the xResetStrm (section 2.2.1.4.37) token on a Pragma header.

The server MUST process the stream selection information specified on the stream-switch-entry (section 2.2.1.4.27) token on the Pragma header, if any. If the stream-switch-count (section 2.2.1.4.26) token is present on a Pragma header, and the value of the token is greater than zero, then the server MUST process the stream selection information specified on the stream-switch-entry (section 2.2.1.4.27) token on the Pragma header, if any.

The server MAY increment the value of the Incarnation variable by 1.

If the request does not contain a stream-switch-entry token on a Pragma header, and the client version is less than or equal to 5.0, as specified by the client on the User-Agent header, and the value of the client-token parameter on the User-Agent header is "NSServer", the server MUST assume that all streams in the content are selected.

Otherwise, if the request does not contain a stream-switch-entry token on a Pragma header, the server MUST assume that none of the streams in the content are selected.

If the request includes the playlist-seek-id, then the server SHOULD communicate the playlist-seek-id header submitted by the client to the higher layer.

The Play response MUST follow the rules as specified in section 3.2.5.2 and 2.2.2.6.

If the request specifies the stream-time token and the value of the stream-time token is not equal to 0 or 4,294,967,295, then the server MUST provide the value of the stream-time token to the higher layer.

If the request does not specify the stream-time token or the value of the stream-time token is equal to 0 or 4,294,967,295, then if the request specifies the packet-num token and the value of the packet-num token is not equal to 4,294,967,295, the server MUST provide the value of the packet-num token to the higher layer.

If the request does not specify the stream-time token or the value of the stream-time token is equal to 0 or 4,294,967,295, and if the request does not specify the packet-num token or the value of the packet-num token is equal to 4,294,967,295, then if the request specifies the stream-offset token and the two numerical values of the stream-offset token are not both equal to 4,294,967,295, the server MUST provide the numerical values of the stream-offset token to the higher layer.

If the request specifies the stream-time token and the value of the stream-time token is equal to 0, and if the request does not specify the packet-num token or the value of the packet-num token is equal to 4,294,967,295, and if the request does not specify the stream-offset token or the two numerical values of the stream-offset token are both equal to 4,294,967,295, the server MUST provide the value of the stream-time token to the higher layer.

If the request specifies the version11-enabled (section 2.2.1.4.30) token on a Pragma header and the value of the token is 1, the response SHOULD use HTTP 1.1 and Chunked Transfer Coding. Otherwise, Chunked Transfer Coding MUST NOT be used.

The value of the KeepAlive-Mode variable in the abstract data model MUST be updated to record if the pipelined or non-pipelined mode of the protocol is used.

The server MUST process the speed-up factor as specified on the speed (section 2.2.1.4.24) token on a Pragma header, and provide the resulting value to the higher layer.

The server SHOULD specify the AccelBW (section 2.2.1.4.1) token, the AccelDuration (section 2.2.1.4.2) token, the BurstBW (section 2.2.1.4.3) token, and the BurstDuration (section 2.2.1.4.4) token on a Pragma header in the response if the client sent the corresponding tokens on a Pragma header in the Play request, and if the server supports changing the transmission rate based on the respective tokens in the request. Otherwise, a server SHOULD NOT specify the tokens in the response.

The server is allowed to specify a value for AccelBW that is less than or equal to the value that the client requested; however, it MUST NOT specify a larger value than the one requested by the client. If the client version (as specified by the client in the User-Agent header) is greater than or equal to 8.0 but less than 9.0, the value of the AccelBW token that is sent by the server MUST NOT exceed 1,048,576.

The server is allowed to specify a value for AccelDuration that is less than or equal to the value that the client requested; however, it SHOULD NOT<72> specify a larger value than the one that is requested by the client.

The server SHOULD specify a value for BurstBW that is less than or equal to the value that the client requested, if the feature is enabled. However, it MUST NOT specify a larger value than the one that is requested by the client.

The server is allowed to specify a value for BurstDuration that is less than or equal to the value that the client requested. However, it MUST NOT specify a larger value than the one that is requested by the client.

If the client specifies support for the com.microsoft.wm.startupprofile feature on the Supported header, as specified in section 2.2.1.7.5, the server SHOULD specify the X-StartupProfile (section 2.2.1.12) header in the response if the server is able to compute the parameters on that header. It is the higher layer that computes these parameters and provides the server with values for the parameters as specified in X-StartupProfile (section 2.2.1.12).

The server MUST NOT specify the X-StartupProfile header in the response unless the client has specified support for the com.microsoft.wm.startupprofile feature.

The server SHOULD specify the Content-Type header with the application/x-mms-framed content-type (section 2.2.1.2.3 ).  The server MAY specify the Content-Type header with the application/octet-stream content-type.<73>

The value of the Session-State variable in the abstract data model MUST be set to STREAMING.

The server MUST set the value of the Data-Connection variable to the value of the Request-Connection variable.

If the client version is greater than or equal to 9.0, as specified by the client on the User-Agent header, and the server is specifying the value of the server-token parameter on the Server header as "Cougar", the server MUST send one or more $M (Metadata) packets (section 2.2.3.6).

The server MUST send the ASF header of the current playlist entry, encoded as one or more $H (Header) packets (section 2.2.3.5).

If the server specified the xResetStrm token on a Pragma header in the response, and the client version is less than 7.0, as specified by the client on the User-Agent header, and the value of the client-token parameter on the User-Agent header is "NSPlayer", and the client specified the request-context (section 2.2.1.4.23) token on the Pragma header, and the value of that token is 2, the server MUST send a $E (End-Of-Stream Notification) packet with the Reason field set to 1, followed by a $C (Stream Change Notification) packet with the Reason field set to 0, followed by the ASF header of the current playlist entry, encoded as one or more $H packets.

If the server specified the xResetStrm token on a Pragma header in the response, and the client version is less than 7.0, as specified by the client on the User-Agent header, and the value of the client-token parameter on the User-Agent header is "NSServer", and the client specified the request-context token on the Pragma header, and the value of that token is 3, the server MUST send a $E packet with the Reason field set to 1, followed by a $C packet with the Reason field set to 0, followed by the ASF header of the current playlist entry, encoded as one or more $H packets.

The server MUST then send the ASF packets of the current playlist entry, encoded as $D (Data) packets (section 2.2.3.3) packets. The ASF payloads in the ASF MUST be filtered such that only ASF payloads that belong to streams that have been selected by the client are included in the ASF packets.

If the server will send $M (Metadata) packets (section 2.2.3.6) and $H (Header) packets (section 2.2.3.5), as the first packets in the response to the Play request, and immediately follows with a $C packet and another $M and $H packet, then the server MUST specify the expect-new-header token in the Pragma header and set the value of the token to 1.

If the server will send $M (Metadata) packets (section 2.2.3.6) and $H (Header) packets (section 2.2.3.5), the server MAY set the Incarnation field (section 2.2.3.1.2) to the value of the Incarnation variable (section 2.2.2.6). If the server chooses to increment the Incarnation field, it MUST do it for both $M and $H packets so that the Incarnation field for both packet types stays synchronized.