Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
Extracted elements (20)
RTCP multiplexing (RFC 5761) is the recommended mechanism because it reduces the number of ports when RTP and RTCP are used, and it inherently accounts for RTCP aspects of the session, which the other mechanisms do not.
RTP keepalive is necessary because certain scenarios prevent normal RTP traffic from maintaining NAT bindings: unidirectional streams (recvonly/sendonly per RFC 3264), streams put on hold, and infrequent payload formats like text conversation (RFC 4103) whose inter-packet interval can exceed NAT binding timeouts.
This document is explicitly not applicable to ICE agents, because ICE together with STUN and TURN already solves the overall NAT traversal problem for media streams; this specification targets agents that need only a keepalive mechanism without full ICE.
NAT traversal constraints typically require that agents also use Symmetric RTP/RTCP (RFC 4961) in addition to the RTP keepalive mechanism described in this document.
RTCP multiplexed keepalive requires peer support for RTP/RTCP multiplexing (RFC 5761), and some RTCP monitoring tools expect RTCP to not be multiplexed; additionally, RTCP must be configured so that the Tmin value is less than or equal to the Tr interval.
The 'RTP packet with unknown payload type' mechanism may cause interoperability issues because the RFC 3550 requirement that receivers ignore unknown payload types is not always observed in practice, and some RTP payload formats do not handle gaps in RTP sequence numbers well.
An application supporting this specification MUST transmit either keepalive packets or media packets at least once every Tr seconds during the whole duration of the media session.
Any media type (e.g., audio, video, text) and any media format (e.g., G.711, H.263) MUST be supported by the keepalive mechanism.
Any type of transport (e.g., UDP, TCP) MUST be supported by the keepalive mechanism.
For functioning RTCP keepalive: (1) sufficient RTCP bandwidth must be provided such that Twc ≤ Tr; (2) if AVP or SAVP is used, Tmin must not exceed Tr / (1.5 / (e − 3/2)); (3) if AVPF or SAVPF is used, trr-min must not be set to a value greater than Tr / 3.
For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr SHOULD be configurable to larger values; for TCP, the recommended Tr value is 7200 seconds.
Keepalive packets within a particular RTP session MUST use the same 4-tuple (source IP, source port, target IP, target port) as the regular RTP packets.
The agent SHOULD only send RTP keepalive when it does not send regular RTP packets, to avoid unnecessary traffic.
The RECOMMENDED keepalive mechanism is RTCP packets multiplexed with RTP packets (Section 4.3); all other mechanisms (Sections 4.1, 4.2, 4.4, 4.5, 4.6) are NOT RECOMMENDED.
When a given media format does not allow the recommended RTCP-multiplexed keepalive solution, an alternative keepalive mechanism SHOULD be defined in the payload format specification for that media format.
When using RTCP packets multiplexed with RTP packets for keepalive, Tr MUST comply with the RTCP timing rules of RFC 3550.
RTCP flow keepalive requires two conditions: RTCP must be used bidirectionally and symmetrically per RFC 4961, and RTCP must be sent frequently enough that the worst-case interval Twc does not exceed the keepalive threshold Tr. The worst-case interval is calculated as: Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8.
Six alternative keepalive mechanisms are enumerated: (1) empty 0-byte transport packet, (2) RTP packet with comfort noise payload, (3) RTCP packets multiplexed with RTP packets, (4) STUN Binding Indication packet, (5) RTP packet with incorrect version number (set to zero), (6) RTP packet with unknown dynamic payload type of 0 length.
The RTP packet with unknown payload type keepalive (Section 4.6) uses 0-length payload, a dynamic payload type not negotiated in SDP, increments sequence number by one per packet, uses the same timestamp value as a media packet would have, sets marker bit to zero, and uses the same SSRC as the media stream.
RTP keepalive packets sent on the same path as regular RTP media packets may be perceived as an attack by a peer; however, RFC 3550 mandates that a peer ignore packets with payload types it does not understand, so a compliant peer will appropriately drop received keepalive packets.