1. Einleitung

In Abschnitt 6.5.1 von [RFC3550] finden sich eine Reihe von Empfehlungen für die Wahl eines eindeutigen RTCP CNAME für einen RTP-Endpunkt. In der Praxis ist jedoch bei einigen dieser Methoden nicht garantiert, dass sie einen eindeutigen RTCP CNAME erzeugen. [RFC6222] aktualisierte die Richtlinien für die Auswahl von RTCP CNAMEs und ersetzte die in Abschnitt 6.5.1 von [RFC3550] vorgestellten. Leider sind einige Teile der neuen Algorithmen recht kompliziert und erzeugen zudem RTCP CNAMEs, die in manchen Fällen potenziell über mehrere RTCP-Sitzungen hinweg verknüpfbar sind, selbst wenn für jede Sitzung ein neuer RTCP CNAME generiert wird. Dieses Dokument spezifiziert einen Ersatz für den Algorithmus in Abschnitt 5 von [RFC6222], der diese Einschränkung nicht aufweist und zudem einfacher zu implementieren ist.

Eine Diskussion über die Verknüpfbarkeit von RTCP CNAMEs, die nach [RFC6222] erzeugt wurden, findet sich in [RESCORLA].

2. Anforderungsnotation

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

3. Mängel der früheren Richtlinien für die Auswahl eines RTCP CNAME

Die Empfehlung in [RFC3550] lautet, einen RTCP CNAME in der Form "user@host" für Mehrbenutzersysteme oder "host" zu generieren, falls der Benutzername nicht verfügbar ist. Der "host"-Teil ist als der vollqualifizierte Domänenname (FQDN) des Hosts spezifiziert, von dem die Echtzeitdaten stammen. Während diese Anleitung zum Zeitpunkt der Erstellung von [RFC3550] angemessen war, sind FQDNs heute nicht mehr notwendigerweise eindeutig und können manchmal in großen Service-Provider-Netzwerken für mehrere Endpunkte identisch sein. Dieses Dokument ersetzt die Verwendung des FQDN als RTCP CNAME durch alternative Mechanismen.

IPv4-Adressen werden in [RFC3550] ebenfalls zur Verwendung in RTCP CNAMEs vorgeschlagen, wobei der "host"-Teil des RTCP CNAME die numerische Darstellung der IPv4-Adresse der Schnittstelle ist, von der die RTP-Daten stammen. Wie in [RFC3550] angemerkt, kann die Verwendung von privatem Netzwerkadressraum [RFC1918] dazu führen, dass Hosts Netzwerkadressen haben, die nicht weltweit eindeutig sind. Darüber hinaus kann diese gemeinsame Nutzung derselben IPv4-Adresse bei öffentlichen IPv4-Adressen auftreten, wenn mehreren Hosts dieselbe öffentliche IPv4-Adresse zugewiesen wird und diese mit einem NAT-Gerät (Network Address Translation) [RFC3022] verbunden sind. Wenn sich mehrere Hosts dieselbe IPv4-Adresse teilen, egal ob privat oder öffentlich, führt die Verwendung der IPv4-Adresse als RTCP CNAME zu RTCP CNAMEs, die nicht notwendigerweise eindeutig sind.

In [RFC3550] wird auch darauf hingewiesen, dass Hosts mit privaten Adressen und ohne direkte IP-Konnektivität zum öffentlichen Internet, deren RTP-Pakete über einen Übersetzer auf RTP-Ebene an das öffentliche Internet weitergeleitet werden, am Ende nicht eindeutige RTCP CNAMEs haben könnten. Der Vorschlag in [RFC3550] lautet, dass solche Anwendungen eine Konfigurationsoption bereitstellen, die es dem Benutzer ermöglicht, einen eindeutigen RTCP CNAME zu wählen; diese Technik bürdet dem Übersetzer die Last auf, RTCP CNAMEs bei Bedarf von privaten Adressen in öffentliche Adressen zu übersetzen, um zu verhindern, dass private Adressen offengelegt werden. Die Erfahrung hat gezeigt, dass dies in der Praxis nicht gut funktioniert.