Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport
Extracted elements (17)
Because the framing method uses TCP as its transport, it inherently competes fairly with other TCP flows, satisfying the RTP/AVP basic congestion control requirement from RFC 3551 without additional mechanism.
Reliable TCP delivery does not imply contiguous RTP sequence numbers: if TCP tunnels a UDP stream through a middlebox, sequence numbers reflect any loss or reordering on the UDP segment of the path. The framing method intentionally does not specify packet-stream properties such as loss, reordering, or out-of-band semantics.
The framing method does not use frame markers (a preceding octet of constant value) that would aid LENGTH-field error detection. Instead, receivers are directed to monitor predictable RTP/RTCP header fields. This reflects the design inherited from earlier RTP/AVP versions.
The 'TCP/RTP/AVP' proto token and Offer/Answer setup via [COMEDIA] are new mechanisms not defined by earlier RTP/AVP versions; the framing encoding itself (LENGTH + packet) was present in earlier versions and is already in use in several implementations.
Because the framing method has no frame marker, receivers SHOULD monitor the RTP and RTCP header fields whose values are predictable (e.g., the RTP version number) to detect errors in the LENGTH field.
Both directions of a TCP connection MUST carry the same type of packets (RTP or RTCP), and packets MUST exclusively code the RTP or RTCP streams specified on the associated media line(s).
If a direction of a connection carries RTCP packets, the streams carried in that direction MUST support the use of multiple SSRCs in those RTCP packets.
If a direction of a connection carries RTP packets, the streams carried in that direction MUST support the use of multiple synchronization sources (SSRCs) in those RTP packets.
If a sender does not wish to send RTCP, it MUST add both 'b=RS:0' AND 'b=RR:0' lines to the media description. If both offer and answer contain these lines, an RTCP TCP flow MUST NOT be created; otherwise endpoints MUST establish two TCP connections (one RTP, one RTCP).
Session management protocols using SDP with Offer/Answer MUST use the methods described in [COMEDIA] (RFC 4145) to set up RTP/AVP streams over TCP; the use of Offer/Answer is REQUIRED.
The <fmt> tokens following <proto> in an SDP media line MUST be unique unsigned integers in the range 0 to 127, specifying RTP payload types associated with the stream.
The TCP port on the media line carries RTP packets; if RTCP is used, a second TCP connection carries RTCP packets, with the port chosen per [SDP] or [RFC3605].
The value coded in the LENGTH field MUST equal the number of octets in the RTP or RTCP packet that follows it.
The SDP <proto> token value 'TCP/RTP/AVP' is defined to signal an RTP/AVP stream that uses the framing method over TCP. For any other RTP profile xyz, the token MUST be 'TCP/RTP/xyz'.
This document registers the new SDP proto token 'TCP/RTP/AVP' for use in SDP media (m=) lines, signalling RTP/AVP framed over TCP as defined in Section 2.
Attackers may send framed packets with large LENGTH values to exploit buffer overflows; implementations MUST handle packets of any length, from a NULL packet (LENGTH == 0) to the maximum 64K-octet packet (LENGTH == 0xFFFF). Implementors should also read the Security Considerations of RFC 3550 and RFC 3551, and of [COMEDIA] for connection-oriented session-specific issues.
The framing method prepends a 16-bit unsigned integer LENGTH field, coded in network byte order (big-endian), to each RTP or RTCP packet. If LENGTH is non-zero, the RTP or RTCP packet immediately follows; LENGTH == 0 codes the null packet.