Explicit Congestion Notification (ECN) for RTP over UDP — RFC 6679

RFC 6679 has been published, describing a standard for use of ECN with RTP over UDP/IP. It describes how ECN marks can be used with RTP data packets, and defines a new RTCP Extended Report (XR) block for periodic ECN reporting, a new RTCP transport feedback message of timely reports of congestion events, and STUN/ICE extensions to probe usability of ECN on a path. SDP extensions to negotiate ECN support are also specified. The standard works with both unicast and multicast RTP sessions, and in point-to-point and group communication scenarios.

Why is ECN for RTP useful?

Without ECN, the Internet responds to network congestion by dropping packets to reduce the load. The transport layer notices this, and reacts by reducing its sending rate, and by retransmitting or otherwise recovering the lost data. This works well for TCP, which can retransmit lost packets to ensure reliability, and makes no timing guarantees. It works less well for interactive RTP traffic, since the delay bounds required for a good user experience don't leave time to retransmit the dropped packets, leaving the application to compensate for lost data, and so impairing the media quality.

When ECN is used, the network marks packets at the onset of congestion, rather than dropping packets. This allows the transport to notice and react to congestion before the network becomes so overloaded that it must drop packets. If the transport and application cooperate, as is typical in tightly coupled RTP implementations, this lets the application choose how it reduces its sending rate, and what data is discards. This can improve the user experience, compared to reacting to unexpected packet drops.


RTP is a framework protocol that has some important differences from the other transport protocols for which ECN has been specified. These include:

These differences significantly alter the shape of ECN support in RTP over UDP compared to ECN support in TCP, SCTP, and DCCP.

Summary of protocol mechanisms

Use of ECN with RTP and SIP

There are four steps to using ECN with RTP over UDP/IP. RTP endpoints start by advertising their capability to use ECN in the signalling exchange. For example, if SDP is used, the offer would include an "a=ecn-capable-rtp:" attribute to indicate willingness to use ECN and to signal its preferred mechanism for initiating use of ECN. If the answer also includes this attribute, this signals that the receiver also supports and wants to use ECN. This step is performed using standard SDP mechanisms, for example as part of a SIP dialogue, and does not use ECN itself.

The second step, if both endpoints agree to use ECN with RTP, is to initiate use of ECN and check that the path can pass ECN-marked RTP packets. Since use of ECN with RTP in UDP/IP is a new standard, it's possible that firewalls, NATs, or other middleboxes might block ECN-marked RTP packets. Accordingly, endpoints do not immediately start using ECN, but rather probe the path to determine if ECN is correctly passed, before fully committing to use ECN. There are two ways of probing the path: either by sending a small fraction of non-essential RTP packets with ECN marks (e.g., comfort noise for speech) and watching the RTCP reports to check if the ECN-marked RTP packets were received; or by sending ECN-marked STUN packets as candidates in an ICE exchange.

If the path successfully passes ECN-marked packets, the RTP endpoints start marking all RTP packets with ECN marks. RTCP packets, and other control packets multiplexed on the same UDP port, are not ECN marked (RTCP is used to provide feedback on whether ECN is working, and we don't want ECN failure reports to fail to be delivered because they use ECN). The specification defines RTCP extensions to provide scheduled reports on reception of ECN-marked packets (via a new RTCP XR block) and immediate reports of ECN-CE marks indicating congestion (via an RTP/AVPF ECN Feedback Report). RTP senders respond to congestion notifications by reducing their sending rate, by the same amount as they would in response to packet loss.

Finally, the RTP sender has to monitor the ongoing performance of the session, to detect and react to failures should they occur. It is possible, for example, that a route change in the network, due to a link failure, could cause traffic to switch from a path that supports use of ECN to one that does not, so the sender must always be prepared to fall back to sending RTP packets without ECN marks, should conditions change.

Taken together, these four mechanisms provide a robust means of using ECN with RTP running over UDP/IP. The standard also gives guidelines for how RTP middleboxes can process ECN marked data packets and RTCP ECN feedback, and on implementation considerations.