3.2.5.16 Receiving a SendEvent Request

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

The SendEvent request MUST follow the rules as specified in section 2.2.7.11.

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 an appropriate RTSP error status code (as specified in [RFC2326] 7.1.1), such as 404.

The SendEvent request does not require any server state. Therefore, if the Session header is missing, this MUST NOT be treated as an error.

The server SHOULD communicate the logging information submitted by the client to the higher layer.

The SendEvent response MUST follow the rules as specified in sections 3.2.5.2 and 2.2.7.11.

After sending the response, the server MUST wait for another request to be received.

If the value of the State variable is READY, then any one or more of the following requests are possible: SelectStream, Play, LogPlay, KeepAlive, SendEvent, or Teardown request.

If the value of the State variable is PLAYING, then any one or more of the following requests are possible: LogPlay, SelectStream, Pause, KeepAlive, SendEvent, or Teardown request. The server MUST continue transmitting RTP packets while in the PLAYING state and MUST be prepared to receive RTCP packets.

How to process a LogPlay request is specified in section 3.2.5.12.

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

How to process a Play request is specified in section 3.2.5.8.

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.