An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
Extracted elements (29)
Direct loopback (rtploopback) was provided as an alternative to encapsulated format to keep packet size equal in both directions when bandwidth is constrained. It sacrifices per-direction statistics and discards original RTP headers.
Encapsulated packet loopback (encaprtp) preserves the original RTP header so the loopback source can compute per-direction metrics by comparing sequence numbers and timestamps in the outer and inner headers. The tradeoff is a 16-byte overhead increase that may cause MTU issues and an increased reverse-path bitrate.
The loopback source is made responsible for congestion control in packet-level loopback, keeping the mirror implementation simpler. The source reduces its sending rate to control congestion on both forward and reverse paths.
A loopback source SHOULD only send one payload type per loopback RTP session when using direct (rtploopback) mode, because direct loopback does not retain the original RTP header and therefore provides no indication of the original payload type.
An answerer that is not compliant to this specification will ignore the loopback media attributes and treat the offer as a normal media request. The offerer MUST handle this case and may terminate the session if a normal RTP session is not desired.
A device performing rtp-media-loopback MUST transmit all received media back to the sender unless congestion feedback or lower-layer constraints prevent it. The media is treated as if it were to be played (e.g., PLC may be applied).
A loopback source MUST NOT send multiple source streams on the same 5-tuple, because there is no means for the mirror to identify which source stream corresponds to which in the mirrored packets.
All implementations MUST at minimum support rtp-pkt-loopback mode with direct media loopback (rtploopback) payload encoding, and all SDP offerer implementations MUST be able to act as loopback source, to ensure a minimal interoperability baseline.
Direction mode attributes 'recvonly' and 'sendonly' are incompatible with the loopback mechanism and MUST NOT be indicated when generating an SDP offer or answer. If received, the agent SHOULD treat it as a protocol failure and terminate or reject the session.
Dynamic payload type numbers MUST be used for both the encaprtp and rtploopback encoding names; there is no static payload type assignment. The binding is indicated via an SDP rtpmap attribute.
For any form of NAT traversal to function, symmetric RTP/RTCP (RFC 4961) MUST be used, unless the mirror can control the NAT(s) in its path to create explicit pinholes via a mechanism such as PCP.
For NAT traversal without ICE, if the mirroring entity is behind a NAT it MUST send some packets to the peer's address/port to open the NAT pinhole, since a mirror does not originate RTP and would otherwise never create the binding.
If SRTP is used for a loopback session, it MUST be used in both directions (to and from the mirror) with the same properties, to provide the same level of protection for both forward and reverse media flows.
If the SDP offer indicates rtp-pkt-loopback support, the offer MUST also contain at least one of the encapsulated (encaprtp) or direct (rtploopback) loopback encoding format names. If only rtp-media-loopback is offered, these encoding formats MUST NOT appear.
Loopback session requests are RECOMMENDED to be authenticated and the frequency of such sessions limited by the answerer to guard against denial-of-service attacks.
The receive timestamp in the encapsulated payload header MUST use the same clock rate as the encapsulated packet, and its initial value SHOULD be random for security reasons per RFC 3550 Section 5.1.
When an SDP answer contains multiple loopback-type choices, the answer MUST include only one of the loopback types accepted by the answerer, and the answerer SHOULD give preference to the first loopback-type listed in the offer.
'rtp-media-loopback' activates loopback as close as possible to the analog interface, after decoding and before re-encoding. The mirror re-encodes and retransmits the media; statistics are limited to what RTCP can provide.
'rtp-pkt-loopback' loops back RTP packets at a point before the encoder/decoder in the receive direction; encoding-related functions such as PLC MUST NOT be applied. Packets are returned with a new payload type using either the encapsulated or direct loopback format defined in Section 7.
The 'a=loopback:<loopback-type>' SDP media-level attribute indicates the agent wishes to perform loopback and specifies the type. Valid loopback-type values are 'rtp-pkt-loopback' (packet-level) and 'rtp-media-loopback' (codec-level). Multiple types may be listed in one attribute.
The 'a=loopback-mirror' SDP media-level property attribute indicates the generating entity will echo all received media back to the RTP stream sender. When a stream is offered with loopback-source, the corresponding response carries loopback-mirror, and vice versa.
The 'a=loopback-source' SDP media-level property attribute indicates the generating entity is the media source and expects the receiver to act as a loopback mirror. No media is generated by the mirror for transmission in the mirrored stream.
IANA registered eight new media types for loopback payload formats: audio/encaprtp, video/encaprtp, text/encaprtp, application/encaprtp (encapsulated RTP) and audio/rtploopback, video/rtploopback, text/rtploopback, application/rtploopback (direct loopback). All are framed, RTP-only, LIMITED USE, with required parameter 'rate'.
IANA registered three new SDP media-level attributes: 'loopback' (value attribute indicating loopback type), 'loopback-source' (property attribute indicating the sender is the media source), and 'loopback-mirror' (property attribute indicating the sender will echo received media).
End-user devices (e.g., mobile phones) answering loopback requests without authentication or user notification risk battery drain and denial of normal phone service; devices SHOULD notify the user of active loopback sessions and implement session timeouts or keepalive/refresh mechanisms.
Media loopback enables attack indirection: an attacker can create a loopback session as loopback source and use the mirror to reflect packets against a third-party target, potentially bypassing firewalls protecting that target.
Without authentication of the signaling, an attacker can establish a loopback session between two victim parties both acting as rtp-pkt-loopback mirrors to each other, causing a small number of initial RTP packets to loop infinitely between them and exhaust their resources and bandwidth.
The direct loopback RTP payload format defines no payload-specific headers. The loopback mirror copies only the RTP payload data from the received packet into a new RTP packet; all original RTP header information is discarded.
The encapsulated RTP payload header is 12 octets prepended to the original received RTP packet (header+payload). Fields: receive timestamp (32-bit), followed by a modified copy of the received RTP header where the first 2 bits are overwritten with the Fragmentation (F) field (2 bits: First=00, Last=01, None=10, Intermediate=11), then R (2 bits), CC, M, PT, sequence number, transmit timestamp (32-bit), SSRC, and optional CSRCs.