Section 14. Embedded (Interleaved) Binary Data

In order to fulfill certain requirements on the network side, e.g.,
   in conjunction with network address translators that block RTP
   traffic over UDP, it may be necessary to interleave RTSP messages and
   media-stream data.  This interleaving should generally be avoided
   unless necessary since it complicates client and server operation and
   imposes additional overhead.  Also, head-of-line blocking may cause
   problems.  Interleaved binary data SHOULD only be used if RTSP is
   carried over TCP.  Interleaved data is not allowed inside RTSP
   messages.
   Stream data, such as RTP packets, is encapsulated by an ASCII dollar
   sign (36 decimal) followed by a one-octet channel identifier and the
   length of the encapsulated binary data as a binary, two-octet
   unsigned integer in network octet order (Appendix B of [RFC791]).
   The stream data follows immediately afterwards, without a CRLF, but
   including the upper-layer protocol headers.  Each dollar sign block
   MUST contain exactly one upper-layer protocol data unit, e.g., one
   RTP packet.
      Note that this mechanism does not support PDUs larger than 65535
      octets, which matches the maximum payload size of regular, non-
      jumbo IPv4 and IPv6 packets.  If the media delivery protocol
      intended to be used has larger PDUs than that, a definition of a
      PDU fragmentation mechanism will be required to support embedded
      binary data.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 36      | Channel ID    | Length in octets              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Binary data (Length according to Length field)                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 1: Embedded Interleaved Binary Data Format
   The channel identifier is defined in the Transport header with the
   interleaved parameter (Section 18.54).
   When the transport choice is RTP, RTCP messages are also interleaved
   by the server over the TCP connection.  The usage of RTCP messages is
   indicated by including an interval containing a second channel in the
   interleaved parameter of the Transport header (see Section 18.54).
   If RTCP is used, packets MUST be sent on the first available channel
   that is higher than the RTP channel.  The channels are bidirectional,
   using the same Channel ID in both directions; therefore, RTCP traffic
   is sent on the second channel in both directions.
      RTCP is sometimes needed for synchronization when two or more
      streams are interleaved in such a fashion.  Also, this provides a
      convenient way to tunnel RTP/RTCP packets through the RTSP
      connection (TCP or TCP/TLS) when required by the network
      configuration and to transfer them onto UDP when possible.
     C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: npt, smpte, clock
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 2
           Date: Thu, 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6
           Session: OccldOFFq23KwjYpAnBbUr
           Accept-Ranges: npt
           Media-Properties: Random-Access=0.2, Immutable, Unlimited
     C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
           CSeq: 3
           Session: OccldOFFq23KwjYpAnBbUr
           User-Agent: PhonyClient/1.2
     S->C: RTSP/2.0 200 OK
           CSeq: 3
           Session: OccldOFFq23KwjYpAnBbUr
           Date: Thu, 05 Jun 1997 18:57:19 GMT
           RTP-Info: url="rtsp://example.com/bar.file"
             ssrc=0D12F123:seq=232433;rtptime=972948234
           Range: npt=0-56.8
           Seek-Style: RAP
     S->C: $005{2 octet length}{"length" octets data, w/RTP header}
     S->C: $005{2 octet length}{"length" octets data, w/RTP header}
     S->C: $006{2 octet length}{"length" octets  RTCP packet}