3.2.5.1 Receiving a Request (All Request Types)

This section specifies common steps that MUST be performed whenever the server receives a request from a client. These steps MUST be performed prior to any processing that is specific to a particular request type.

The server MUST validate that the request is of one of the types specified in section 2.2.7 and that the request is using the appropriate RTSP request method. If the validation fails, the server MUST respond with an appropriate RTSP error status code, as specified in [RFC2326] section 7.1.1.

The server SHOULD invoke the local event specified in section 3.2.7.6 to report to the higher layer that a RTSP request has been received. If, as a result of invoking the event in section 3.2.7.6, the higher layer specifies that the RTSP request is rejected, the server MUST delete the session state, if any, and close the TCP connection to the client.

When receiving a request other than Play and Teardown where the X-Playlist-Gen-Id (section 2.2.6.22) header is present, and the value on that header is both not equal to 0 and does not match the value of the Playlist-gen-id variable in the abstract data model (section 3.1.1), then the server SHOULD treat this as an error and respond with RTSP status code 412.

If the request is not a SendEvent request and the request includes the Session header then the server MUST load the state associated with the RTSP session ID specified on that header. If the matching state cannot be found then the server MUST treat this as an error and respond with status code 454 (as specified in [RFC2326] section 12.37). If the request includes the Session header and the length of the session-id field on that header exceeds 20 characters then the server SHOULD treat this as an error and respond with status code 454.

The server SHOULD obtain the total number of streams in the content from the higher layer, referred to as the Total Number of Streams. If this information is not known by the higher layer, the Total Number of Streams SHOULD be 3.

If the RTSP request method is SETUP, then the value of the TransactionsSETUP variable in the Abstract Data Model SHOULD be incremented by 1.

If the value of the TransactionsTEARDOWN variable is 1, or if the value of the TransactionsTEARDOWN variable is greater than or equal to the Total Number of Streams, then the value of the TransactionsPerHeartBeat variable SHOULD be incremented by 1.

If the RTSP request method is not SETUP, TEARDOWN, SET_PARAMETER, or GET_PARAMETER, then the value of the TransactionsSETUP variable SHOULD be set to 0 and the value of the TransactionsTEARDOWN variable SHOULD be set to 0.

If the value of the TransactionsPerHeartBeat variable is greater than or equal to 240, then the server SHOULD treat this as an error and respond with status code 503.

The server MUST process the Supported (section 2.2.6.10) header, if present. Each feature token on the header MUST be added to the Client-features variable in the abstract data model. If the header is present, any feature token not listed on the header MUST be removed from the Client-features variable.

If the If-Match (2.2.6.5) header is present in the request and the If-Match header does not adhere to the syntax in 2.2.6.5, then the server SHOULD treat this as an error and respond with status code 412.

If the If-None-Match (2.2.6.6) header is present in the request and the If-None-Match header does not adhere to the syntax in 2.2.6.6, then the server SHOULD treat this as an error and respond with status code 400.

If the Idle-Timeout timer is running, it MUST be stopped.

If the Heartbeat timer is not running, it SHOULD be started and set to expire at an interval of once every 30,000 milliseconds.