1. Introduction

In Section 6.5.1 of [RFC3550], there are a number of recommendations for choosing a unique RTCP CNAME for an RTP endpoint. However, in practice, some of these methods are not guaranteed to produce a unique RTCP CNAME. [RFC6222] updated the guidelines for choosing RTCP CNAMEs, superseding those presented in Section 6.5.1 of [RFC3550]. Unfortunately, some parts of the new algorithms are rather complicated and also produce RTCP CNAMEs that, in some cases, are potentially linkable over multiple RTCP sessions even if a new RTCP CNAME is generated for each session. This document specifies a replacement for the algorithm in Section 5 of [RFC6222], which does not have this limitation and is also simpler to implement.

For a discussion on the linkability of RTCP CNAMEs produced by [RFC6222], refer to [RESCORLA].

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME

The recommendation in [RFC3550] is to generate an RTCP CNAME of the form "user@host" for multiuser systems, or "host" if the username is not available. The "host" part is specified to be the fully qualified domain name (FQDN) of the host from which the real-time data originates. While this guidance was appropriate at the time [RFC3550] was written, FQDNs are no longer necessarily unique and can sometimes be common across several endpoints in large service provider networks. This document replaces the use of the FQDN as an RTCP CNAME by alternative mechanisms.

IPv4 addresses are also suggested for use in RTCP CNAMEs in [RFC3550], where the "host" part of the RTCP CNAME is the numeric representation of the IPv4 address of the interface from which the RTP data originates. As noted in [RFC3550], the use of private network address space [RFC1918] can result in hosts having network addresses that are not globally unique. Additionally, this shared use of the same IPv4 address can occur with public IPv4 addresses if multiple hosts are assigned the same public IPv4 address and are connected to a Network Address Translation (NAT) device [RFC3022]. When multiple hosts share the same IPv4 address, whether private or public, using the IPv4 address as the RTCP CNAME leads to RTCP CNAMEs that are not necessarily unique.

It is also noted in [RFC3550] that if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator, they could end up having non-unique RTCP CNAMEs. The suggestion in [RFC3550] is that such applications provide a configuration option to allow the user to choose a unique RTCP CNAME; this technique puts the burden on the translator to translate RTCP CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed. Experience has shown that this does not work well in practice.