Path MTU Discovery (PMTUD) for RTP/RTCP
Impedance Mismatch
marc@petit-huguenin.org
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park
NC
27709
United States
gsalguei@cisco.com
ART
DISPATCH
This document describes an implementation of the Path MTU Discovery (PMTUD) protocol for RTP sessions.
The Guidelines for Writers of RTP Payload Formats (RFC 2736,BCP 36) states in Section 4 that "[i]f a codec’s frame size is larger than the MTU, the payload format must not rely on IP fragmentation."
Similarly, RFC 3550 states that "…only the subset [of RR packets into one compound RTCP packet] that will fit into one MTU SHOULD be included in each interval."
These statements can be extended to the Path MTU, as fragmentation along the media path is no better than fragmentation on the first link-layer.
RTP and RTCP were not designed with a mechanism to discover the Path MTU, so this document describes a way to add this capability by using the PMTUD protocol defined in .
Multiplexing between RTP/RTCP packets and STUN packets is a well-known technique used for example to discover the IP address of a NAT or to check connectivity .
The PMTUD mechanism for RTP/RTCP uses either the Simple Probing Mechanism described in Section 4.1 of or the Complete Probing Mechanism described in Section 4.2.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
Real-time media protocols (SIP, Jingle [XEP-0166]) that are using the Offer/Answer protocol signals their support of this specification by the usage of an "a:x-pmtud" attribute in the SDP.
This attribute can be used at the session-level or at the media-level.
An Offerer indicates the support of this specification by adding an "a:x-pmtud" attribute in the SDP sent.
An Answerer receiving an SDP containing an "a:x-pmtud" attribute and supporting this specification can immediately start probing for the PMTU, as described in Section 5.2 of .
Even if the SDP received by an Answerer does not contain an "a:x-pmtud" attribute, an Answerer supporting this specification MUST insert an "a:x-pmtud" attribute in the SDP it will send.
Realtime media protocols that support ICE (i.e. WebRTC, in addition to the protocols listed above) MAY signal that a specific candidate support for this specification differs from what is declared at the session-level or media-level of the SDP by inserting an extension attribute with values "pmtud on" or "pmtud off" in the candidate line.
When initiating the Probe transactions, as described in Section 4.1 of , the RTP/RTCP client MUST use the same IP address and port destination that are used as the destination for the RTP or RTCP packets.
The server side MUST be prepared to demultiplex the Probe Requests from the RTP/RTCP packets and other STUN messages.
When sending the Probe Indications, the RTP/RTCP client MUST use the same source IP address and port and same IP address and port destination that are used for the RTP or RTCP packets.
Any STUN message sent along the RTP/RTCP packets, like ICE connectivity checks, media keep-alive, or consent packets MUST be used to populate the identifier list described in Section 4.2.3 of .
For a STUN message, the identifier is made up of the first 12 bytes of the Transaction ID.
For an RTP packet, the identifier is made up of the SSRC concatenated with the Sequence Number, for a total of 12 bytes.
For an RTCP packet, the identifier is made up of the Reporter SSRC concatenated with the last 4 bytes of the Extended Highest Sequence Number Received, for a total of 12 bytes.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RTP: A Transport Protocol for Real-Time Applications
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]
An Offer/Answer Model with Session Description Protocol (SDP)
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]
Session Traversal Utilities for NAT (STUN)
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489. [STANDARDS-TRACK]
Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)
This document describes a Session Traversal Utilities for NAT (STUN) Usage for Path MTU Discovery (PMTUD) between a client and a server.
Guidelines for Writers of RTP Payload Format Specifications
This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]