4. Auswahl eines RTCP CNAME

Es ist für einen Host schwierig und in einigen Fällen unmöglich festzustellen, ob zwischen ihm und seinem RTP-Partner ein NAT vorhanden ist. Darüber hinaus können sogar einige öffentliche IPv4-Adressen von mehreren Hosts im Internet gemeinsam genutzt werden. Die Verwendung der numerischen Darstellung der IPv4-Adresse als "host"-Teil des RTCP CNAME wird NICHT EMPFOHLEN (NOT RECOMMENDED).

4.1. Persistente RTCP CNAMEs versus sitzungsbezogene RTCP CNAMEs

Der RTCP CNAME kann entweder über verschiedene RTP-Sitzungen für einen RTP-Endpunkt hinweg persistent sein oder pro Sitzung eindeutig sein, was bedeutet, dass ein RTP-Endpunkt für jede RTP-Sitzung einen anderen RTCP CNAME wählt.

Ein RTP-Endpunkt, der mehrere zusammengehörige RTP-Ströme sendet, die am anderen Endpunkt bzw. an den anderen Endpunkten synchronisiert werden müssen, MUSS denselben RTCP CNAME für alle zu synchronisierenden Ströme verwenden. Dies erfordert einen kurzfristig persistenten RTCP CNAME, der über mehrere RTP-Ströme und potenziell über mehrere zusammengehörige RTP-Sitzungen hinweg identisch ist. Ein häufiges Beispiel für eine solche Verwendung tritt bei der Synchronisierung von Audio- und Videoströmen in einer Multimedia-Sitzung auf, wobei ein einziger Teilnehmer denselben RTCP CNAME für seine Audio-RTP-Sitzung und für seine Video-RTP-Sitzung verwenden muss. Ein weiteres Beispiel könnte die Synchronisierung der Schichten eines geschichteten Audio-Codecs sein, wobei für jede Schicht derselbe RTCP CNAME verwendet werden muss.

Wenn die mehreren RTP-Ströme in einer RTP-Sitzung nicht zusammengehören und daher keine Synchronisierung erfordern, kann ein RTP-Endpunkt unterschiedliche RTCP CNAMEs für diese Ströme verwenden.

Ein längerfristig persistenter RTCP CNAME ist manchmal nützlich, um die Überwachung durch Dritte zu erleichtern, im Einklang mit [RFC3550]. Eine solche Verwendung könnte darin bestehen, Netzwerkmanagement-Tools die Korrelation der laufenden Dienstgüte für einen Teilnehmer über mehrere RTP-Sitzungen hinweg zur Fehlerdiagnose und zum Verständnis langfristiger Netzwerk-Performance-Statistiken zu ermöglichen. Ein Anwendungsentwickler, der diese Art der Überwachung durch Dritte unterbinden möchte, kann für jede RTP-Sitzung oder Gruppe zusammengehöriger RTP-Sitzungen, denen die Anwendung beitritt, einen eindeutigen RTCP CNAME generieren. Ein solcher sitzungsbezogener RTCP CNAME kann nicht zur Verkehrsanalyse verwendet werden und bietet somit eine gewisse begrenzte Form der Privatsphäre. Beachten Sie, dass es Nicht-RTP-Mittel gibt, die von Dritten verwendet werden können, um RTP-Sitzungen zu korrelieren, sodass die Verwendung sitzungsbezogener RTCP CNAMEs einen entschlossenen Verkehrsanalysten nicht daran hindern wird, solche Sitzungen zu überwachen.

Dieses Memorandum definiert mehrere verschiedene Wege, auf denen eine Implementierung einen RTCP CNAME wählen kann. Es ist möglich und legitim, dass unabhängige Implementierungen unterschiedliche Wahlen für den RTCP CNAME treffen, wenn sie auf demselben Host laufen. Dies kann die Überwachung durch Dritte behindern, es sei denn, es wird ein externes Mittel bereitgestellt, um eine persistente Wahl des RTCP CNAME für diese Implementierungen zu konfigurieren.

Beachten Sie, dass in diesem Memorandum kein Problem mit der Abwärtskompatibilität (mit Implementierungen, die zu [RFC3550] kompatibel sind) eingeführt wird, da die RTCP CNAMEs für entfernte Partner opake Zeichenfolgen sind.

4.2. Anforderungen

RTP-Endpunkte können wählen, ob sie persistente oder sitzungsbezogene RTCP CNAMEs generieren. Ein RTP-Endpunkt, der einen persistenten RTCP CNAME generieren möchte, MUSS eine der folgenden zwei Methoden verwenden:

• Um einen langfristig persistenten RTCP CNAME zu erzeugen, MUSS ein RTP-Endpunkt einen Universally Unique IDentifier (UUID) [RFC4122] generieren und speichern, der als "host"-Teil seines RTCP CNAME dient. Die UUID MUSS Version 1, 2 oder 4 sein, wie in [RFC4122] beschrieben, wobei das Präfix "urn:uuid:" entfernt wird, was zu einer 36 Oktett langen druckbaren Zeichenfolgendarstellung führt.

• Um einen kurzfristig persistenten RTCP CNAME zu erzeugen, MUSS ein RTP-Endpunkt einen Identifikator generieren und verwenden, indem er das in Abschnitt 5 beschriebene Verfahren befolgt. Dieses Verfahren wird mindestens einmal pro Initialisierung der Software durchgeführt. Nach Erhalt eines Identifikators SOLLTEN (SHOULD) zumindest die niederwertigsten 96 Bits unter Verwendung der Base64-Kodierung [RFC4648] in ASCII umgewandelt werden (um einen Kompromiss zwischen Paketgröße und Eindeutigkeit zu finden – siehe Abschnitt 6.1). Wenn 96 Bits verwendet werden, ist die resultierende Zeichenfolge 16 Oktette lang. Beachten Sie, dass der Base64-kodierte Wert die maximale RTCP-CNAME-Länge von 255 Oktetten [RFC3550] nicht überschreiten darf.

In den beiden oben genannten Fällen KANN der Teil "user@" des RTCP CNAME auf Einbenutzersystemen weggelassen werden und KANN auf Mehrbenutzersystemen durch ein opakes Token ersetzt werden, um die Privatsphäre zu wahren.

Ein RTP-Endpunkt, der einen sitzungsbezogenen RTCP CNAME generieren möchte, MUSS die folgende Methode verwenden:

• Für jede neue RTP-Sitzung wird ein neuer RTCP CNAME nach dem in Abschnitt 5 beschriebenen Verfahren generiert. Nach Durchführung dieses Verfahrens SOLLTEN zumindest die niederwertigsten 96 Bits unter Verwendung der Base64-Kodierung [RFC4648] in ASCII umgewandelt werden. Der RTCP CNAME darf sich während der Lebensdauer einer RTP-Sitzung nicht ändern [RFC3550]. Der Teil "user@" des RTCP CNAME wird weggelassen, wenn sitzungsbezogene RTCP CNAMEs generiert werden.

Es wird davon ausgegangen, dass das Erreichen von Eindeutigkeit (mit hoher Wahrscheinlichkeit) eine wichtige Eigenschaft ist, die eine sorgfältige Bewertung der Methode erfordert. Dieses Dokument bietet eine Reihe von Methoden an, von denen mindestens eine für jedes beliebige Einsatzszenario geeignet wäre. Dieses Dokument sieht daher nicht vor, dass der Implementierer eine alternative Methode definiert und auswählt.

Eine zukünftige Spezifikation könnte eine alternative Methode zur Generierung von RTCP CNAMEs definieren, solange die vorgeschlagene Methode eine angemessene Eindeutigkeit aufweist und Konsistenz zwischen den Methoden besteht, die für mehrere zu korrelierende RTP-Sitzungen verwendet werden. Eine solche Spezifikation muss jedoch vor dem Einsatz geprüft und genehmigt werden.

Die in diesem Dokument beschriebenen Mechanismen sind zur Generierung von RTCP CNAMEs zu verwenden und dürfen nicht zur Generierung allgemeiner eindeutiger Identifikatoren verwendet werden.

5. Verfahren zur Generierung eines eindeutigen Identifikators

Um lokal einen eindeutigen Identifikator zu erzeugen, generiert man einfach einen kryptographisch pseudozufälligen Wert, wie in [RFC4086] beschrieben. Dieser Wert MUSS mindestens 96 Bits lang sein.

Der größte Engpass bei der Implementierung dieses Algorithmus ist die Verfügbarkeit eines geeigneten kryptographisch sicheren Pseudozufallszahlengenerators (CSPRNG). In jeder Umgebung, die bereits über einen sicheren PRNG verfügt, ist dieser beschriebene Algorithmus viel einfacher als der in Abschnitt 5 von [RFC6222] beschriebene. SIP-Stacks [RFC3261] müssen kryptographische Zufallszahlen verwenden, um To- und From-Tags zu generieren (Abschnitt 19.3). Implementierungen für Echtzeit-Kommunikation im Web (RTCWEB) [ARCH] benötigen sichere PRNGs zur Implementierung von ICE [RFC5245] und DTLS-SRTP [RFC5764]. Und natürlich unterstützt im Wesentlichen jeder Webbrowser bereits TLS, was einen sicheren PRNG erfordert.