Share via

3.2.5.8 Receiving a Play Request

  • Article

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

The Play request MUST follow the rules as specified in this section.

The server MUST check with the higher layer that the URL that the client specified in the request is valid. If it is not valid, this is an error, and the server MUST respond with some suitable RTSP error status code (as specified in [RFC2326] 7.1.1), such as 404.

The value of the State variable in the abstract data model MUST be set to PLAYING.

The value of the Pause-Allowed-In-READY variable MUST be set to 0.

The value of the Play-Expected-Before-Announce variable MUST be set to 0.

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

If the request specified the X-RTP-Info (section 2.2.6.27) header in the Play request, and the header does not adhere to the syntax in section 2.2.6.27, then the server SHOULD treat this as an error and specify status code 400 in the response.

If the request specified the X-Player-Lag-Time (section 2.2.6.19) in the header of the Play request, then the server SHOULD set the Specified-Lag-Time value to the value of X-Player-Lag-Time, otherwise the Specified-Lag-Time value SHOULD be set to 0.

If the request specified Bandwidth (section 2.2.6.1), then the server MUST store the value in Specified-Bandwidth.

The server SHOULD specify the X-Accelerate-Streaming (section 2.2.6.13) header in the response if the client sent that header in the Play request and if the server supports changing the transmission rate according to that header's presence in the request.<32> Otherwise, the server SHOULD NOT specify the X-Accelerate-Streaming header in the response.

The server is allowed to specify a value for AccelBandwidth parameter of the X-Accelerate-Streaming token 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.

The server is allowed to specify a value for AccelDuration parameter of the X-Accelerate-Streaming token that is less than or equal to the value that the client requested; however, it SHOULD NOT<33> specify a larger value than the one that is requested by the client.

The server SHOULD specify the X-Burst-Streaming (section 2.2.6.17) header in the response if the client sent that header in the Play request and if the higher layer indicates that it supports delivering the ASF packets for transmission at a faster than real-time rate. Otherwise, the server SHOULD NOT specify the X-Burst-Streaming header in the response.

The following rules apply to the case when the server specifies the X-Burst-Streaming header in the response:

  • The higher layer SHOULD specify the maximum bit rate at which it can deliver the ASF packets, and the server SHOULD specify a value for the BurstBandwidth parameter of the X-Burst-Streaming header that is the smaller of the bit rate value specified by the higher layer and the value that the client requested.

  • The server MUST NOT specify a larger value for the BurstBandwidth parameter than the one that is requested by the client.

  • The higher layer SHOULD specify how many milliseconds of content it can deliver at the rate that the server will specify on the BurstBandwidth parameter on the X-Burst-Streaming header, and the server SHOULD specify a value for BurstDuration parameter of the X-Burst-Streaming header that is the smaller of the millisecond value provided by the higher layer and the value that the client requested.

  • The server MUST NOT specify a larger value for the BurstDuration parameter than the one that is requested by the client.

If the value of the Client-features variable in the abstract data model indicates that the client supports the com.microsoft.wm.startupprofile (section 2.2.6.10.8) feature, and if the server is including the X-Accelerate-Streaming header in the response to the Play request, then the server SHOULD invoke the event specified in section 3.2.7.7 to compute the values for the X-StartupProfile (section 2.2.6.28) header. The value of the AccelDuration parameter on the X-Accelerate-Streaming header that the server sends in the response to this Play request SHOULD be provided as the input parameter to the event in section 3.2.7.7. If the server successfully computes the values for the X-StartupProfile header, then the X-StartupProfile header SHOULD be included in the response to the Play request.

If the request includes the X-Playlist-Seek-Id header, and if the value of this header is equal to the Previous-playlist-entry-id variable, but not 0, the server MUST assign this value to the Playlist-gen-id variable in the abstract data model. The server MUST set the value of the Previous-playlist-entry-id variable to 0, and MUST send an EndOfStream request immediately after sending the Play response.

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.

If the request specified X-Playlist header, then the server MUST provide the X-Playlist header and the Playlist-gen-id variable to the higher layer and check with the higher layer that the request is valid. If it is not valid (for example, if there is no next or previous playlist entry), this is an error and the server MUST respond with some suitable RTSP error status code (as specified in [RFC2326] 7.1.1), such as 400.

If the server will immediately send an EndOfStream request after this response (for example, this would normally happen if the client included the X-Playlist header in the Play request), the Play response MUST include the X-Playlist-Change-Notice (section 2.2.6.21) header.

After sending the response, the higher layer can deliver ASF packets that will be sent as RTP [RFC3550] packets to the client. The ASF packets are delivered as an event from the higher layer, specified in section 3.2.4.3.

If the value of the Use-UDP variable is 1, then the Idle-Timeout timer MUST be started. If the value of the Use-UDP variable is 0, then the Idle-Timeout timer MUST be stopped if it is running.

If the value of the Pending-ASF-File-Header variable is not NULL, then the server MUST set the value of the New-ASF-File-Header variable to the value of the Pending-ASF-File-Header variable and then the server MUST follow the rules specified in 3.2.4.2, using the New-ASF-File-Header value as the ASF File Header.

While sending RTP packets, the server MUST be prepared for another request to be received.

Any one or more of the following requests are possible: LogConnect, SelectStream, Pause, KeepAlive, SendEvent, or Teardown request. The server MUST also be prepared to receive RTCP [RFC3556] packets.

How to process a LogConnect request is specified in section 3.2.5.9.

How to process a SelectStream request is specified in section 3.2.5.6.

How to process a Pause request is specified in section 3.2.5.11.

How to process a KeepAlive request is specified in section 3.2.5.15.

How to process a SendEvent request is specified in section 3.2.5.16.

How to process a Teardown request is specified in section 3.2.5.17.

How to process RTCP packets is specified in section 3.2.5.10.