Section 5. RTSP Message

RTSP is a text-based protocol that uses the ISO 10646 character set
   in UTF-8 encoding per RFC 3629 [RFC3629].  Lines MUST be terminated
   by a CRLF.
      Text-based protocols make it easier to add optional parameters in
      a self-describing manner.  Since the number of parameters and the
      frequency of commands is low, processing efficiency is not a
      concern.  Text-based protocols, if used carefully, also allow easy
      implementation of research prototypes in scripting languages such
      as Python, PHP, Perl and TCL.
   The ISO 10646 character set avoids character-set switching, but is
   invisible to the application as long as US-ASCII is being used.  This
   is also the encoding used for text fields in RTCP [RFC3550].
   A request contains a method, the object the method is operating upon,
   and parameters to further describe the method.  Methods are
   idempotent unless otherwise noted.  Methods are also designed to
   require little or no state maintenance at the media server.
5.1.  Message Types
   RTSP messages are either requests from client to server or from
   server to client, and responses in the reverse direction.  Request
   (Section 7) and response (Section 8) messages use a format based on
   the generic message format of RFC 5322 [RFC5322] for transferring
   bodies (the payload of the message).  Both types of messages consist
   of a start-line, zero or more header fields (also known as
   "headers"), an empty line (i.e., a line with nothing preceding the
   CRLF) indicating the end of the headers, and possibly the data of the
   message body.  The ABNF [RFC5234] below is for illustration only; the
   formal message specification is presented in Section 20.2.2.
   generic-message = start-line
                   *(rtsp-header CRLF)
                     CRLF
                   [ message-body-data ]
   start-line = Request-Line / Status-Line
   In the interest of robustness, agents MUST ignore any empty line(s)
   received where a Request-Line or Status-Line is expected.  In other
   words, if the agent is reading the protocol stream at the beginning
   of a message and receives any number of CRLFs first, it MUST ignore
   all of the CRLFs.
5.2.  Message Headers
   RTSP header fields (see Section 18) include general-header, request-
   header, response-header, and message body header fields.
   The order in which header fields with differing field names are
   received is not significant.  However, it is "good practice" to send
   general-header fields first, followed by a request-header or
   response-header field, and ending with the message body header
   fields.
   Multiple header fields with the same field-name MAY be present in a
   message if and only if the entire field-value for that header field
   is defined as a comma-separated list.  It MUST be possible to combine
   the multiple header fields into one "field-name: field-value" pair,
   without changing the semantics of the message, by appending each
   subsequent field-value to the first, each separated by a comma.  The
   order in which header fields with the same field-name are received is
   therefore significant to the interpretation of the combined field
   value; thus, a proxy MUST NOT change the order of these field-values
   when a message is forwarded.
   Unknown message headers MUST be ignored (skipping over the header to
   the next protocol element, and not causing an error) by an RTSP
   server or client.  An RTSP proxy MUST forward unknown message
   headers.  Message headers defined outside of this specification that
   are required to be interpreted by the RTSP agent will need to use
   feature tags (Section 4.5) and include them in the appropriate
   Require (Section 18.43) or Proxy-Require (Section 18.37) header.
5.3.  Message Body
   The message body (if any) of an RTSP message is used to carry further
   information for a particular resource associated with the request or
   response.  An example of a message body is an SDP message.
   The presence of a message body in either a request or a response MUST
   be signaled by the inclusion of a Content-Length header (see
   Section 18.17) and Content-Type header (see Section 18.19).  A
   message body MUST NOT be included in a request or response if the
   specification of the particular method (see Method Definitions
   (Section 13)) does not allow sending a message body.  In case a
   message body is received in a message when not expected, the message
   body data SHOULD be discarded.  This is to allow future extensions to
   define optional use of a message body.
5.4.  Message Length
   An RTSP message that does not contain any message body is terminated
   by the first empty line after the header fields (note: an empty line
   is a line with nothing preceding the CRLF.).  In RTSP messages that
   contain message bodies, the empty line is followed by the message
   body.  The length of that body is determined by the value of the
   Content-Length header (Section 18.17).  The value in the header
   represents the length of the message body in octets.  If this header
   field is not present, a value of zero is assumed, i.e., no message
   body present in the message.  Unlike an HTTP message, an RTSP message
   MUST contain a Content-Length header whenever it contains a message
   body.  Note that RTSP does not support the HTTP/1.1 "chunked"
   transfer coding (see Section 4.1 of [RFC7230]).
      Given the moderate length of presentation descriptions returned,
      the server should always be able to determine its length, even if
      it is generated dynamically, making the chunked transfer encoding
      unnecessary.