Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
Extracted elements (13)
A NAT device performing port mapping provides no guarantee that the mappings of two separate ports preserve the sequencing or parity of the original port numbers; when the NAT manages a pool of IP addresses, RTP and RTCP ports may even be mapped to different addresses, motivating the explicit 'a=rtcp' attribute.
Multiple RTCP port support (for layered/hierarchical encoding) was deliberately omitted because layered encoding is rarely used in practice, and when used is mostly in conjunction with multicast transmission. The NAT translation issues this memo addresses apply uniquely to unicast transmission.
The authors considered expanding the SDP media description line (m=) to include the RTCP port but rejected it for two reasons: adding an extra port number and optional address in the media description would be awkward, and existing applications would have to reject the entire media description if they did not understand the extension. An attribute has a well-defined failure mode: unknown attributes are ignored.
Implementations of RTP adhering to the earlier RFC 1889 specification may not be able to make use of the SDP 'a=rtcp' attribute defined in this document, since RFC 1889 required RTCP ports to be derived algorithmically from the base media port.
Implementations that do not understand the 'a=rtcp' attribute will simply ignore it; they will fail to send RTCP packets to the specified address but will still be able to receive media in the RTP packets. This is the defined graceful failure mode for this attribute.
The RTCP attribute MAY be used as a media-level attribute; it MUST NOT be used as a session-level attribute.
The RTCP attribute SHOULD NOT be used for applications other than documenting port numbers as they appear after address translation by a port-mapping NAT.
The 'a=rtcp' SDP attribute documents the RTCP port (and optionally address) for a media stream when that port is not the next higher (odd) port number following the RTP port in the media line. The attribute name is the ASCII string 'rtcp' (lowercase) and follows the general 'a=<attribute>:<value>' SDP syntax.
The STUN protocol (RFC 3489) is described as one mechanism by which a host behind a NAT can discover its externally visible UDP port numbers for use in the 'a=rtcp' attribute. The four-step process involves allocating two UDP ports, sending to a STUN server, and parsing the reflected source address and port from the reply.
This document registers the new SDP attribute field 'rtcp' with IANA per RFC 2327. The attribute is designated for use at the media level only.
The 'a=rtcp' attribute is not believed to introduce significant security risk. A malevolent third party could use the extension to redirect RTCP traffic, but doing so requires intercepting and rewriting the signaling packet, at which point many more severe attacks (wholesale address and port substitution) are already possible.
To protect against attacks that modify the 'a=rtcp' attribute in SDP carried as application/sdp, end-to-end integrity using S/MIME (RFC 3369) is the recommended technical method. This approach is compatible with SIP (RFC 3261).
The RTCP attribute ABNF syntax is: rtcp-attribute = 'a=rtcp:' port [nettype space addrtype space connection-address] CRLF. The port, nettype, addrtype, and connection-address tokens are as defined in RFC 2327 Appendix A.