Zum Hauptinhalt springen

8. SSRC Identifier Allocation and Use (SSRC-Identifikator-Zuweisung und -Verwendung)

Der im RTP-Header und in verschiedenen Feldern der RTCP-Pakete getragene SSRC-Identifikator ist eine zufällige 32-Bit-Zahl, die innerhalb einer RTP-Sitzung global eindeutig sein muss. Es ist entscheidend, dass die Zahl sorgfältig gewählt wird, damit Teilnehmer im selben Netzwerk oder mit gleichem Startzeitpunkt nicht wahrscheinlich dieselbe Zahl wählen.

Es genügt nicht, die lokale Netzwerkadresse (wie eine IPv4-Adresse) für den Identifikator zu verwenden, da die Adresse nicht eindeutig sein mag. Da RTP-Übersetzer und -Mischer die Interoperation zwischen mehreren Netzen mit unterschiedlichen Adressräumen ermöglichen, könnten die Zuweisungsmuster für Adressen innerhalb zweier Räume eine viel höhere Kollisionsrate ergeben als bei zufälliger Zuweisung.

Mehrere auf einem Host laufende Quellen würden ebenfalls in Konflikt geraten.

Es genügt auch nicht, einen SSRC-Identifikator einfach durch Aufruf von random() ohne sorgfältige Initialisierung des Zustands zu erhalten. Ein Beispiel, wie ein Zufallsidentifikator erzeugt wird, ist in Anhang A.6 angegeben.

8.1 Probability of Collision (Kollisionswahrscheinlichkeit)​

Da die Identifikatoren zufällig gewählt werden, ist es möglich, dass zwei oder mehr Quellen dieselbe Zahl wählen. Eine Kollision tritt mit der höchsten Wahrscheinlichkeit auf, wenn alle Quellen gleichzeitig gestartet werden, beispielsweise wenn sie automatisch durch ein Sitzungsverwaltungsereignis ausgelöst werden. Wenn N die Anzahl der Quellen und L die Länge des Identifikators (hier 32 Bits) ist, kann die Wahrscheinlichkeit, dass zwei Quellen unabhängig denselben Wert wählen, für großes N [26] approximiert werden als 1 - exp(-N2 / 2(L+1)). Für N=1000 beträgt die Wahrscheinlichkeit etwa 10**-4.

Die typische Kollisionswahrscheinlichkeit ist viel niedriger als der obige Worst-Case. Wenn eine neue Quelle einer RTP-Sitzung beitritt, in der alle anderen Quellen bereits eindeutige Identifikatoren haben, ist die Kollisionswahrscheinlichkeit nur der Bruchteil der aus dem Raum genutzten Zahlen. Wiederum, wenn N die Anzahl der Quellen und L die Länge des Identifikators ist, beträgt die Kollisionswahrscheinlichkeit N / 2L. Für N=1000 beträgt die Wahrscheinlichkeit etwa 2*10-7.

Die Kollisionswahrscheinlichkeit wird weiter verringert durch die Möglichkeit für eine neue Quelle, Pakete anderer Teilnehmer zu empfangen, bevor sie ihr erstes Paket (Daten oder Steuerung) sendet. Wenn die neue Quelle die anderen Teilnehmer (anhand des SSRC-Identifikators) verfolgt, kann sie vor dem Senden ihres ersten Pakets verifizieren, dass ihr Identifikator nicht mit einem empfangenen kollidiert, oder andernfalls neu wählen.

8.2 Collision Resolution and Loop Detection (Kollisionsauflösung und Schleifenerkennung)​

Obwohl die Wahrscheinlichkeit einer SSRC-Identifikatorkollision gering ist, MÜSSEN alle RTP-Implementierungen bereit sein, Kollisionen zu erkennen und angemessene Maßnahmen zu ihrer Auflösung zu ergreifen. Wenn eine Quelle jederzeit feststellt, dass eine andere Quelle denselben SSRC-Identifikator wie sie selbst verwendet, MUSS sie ein RTCP-BYE-Paket für den alten Identifikator senden und einen anderen zufälligen wählen. (Wie unten erklärt, wird dieser Schritt im Fall einer Schleife nur einmal durchgeführt.) Wenn ein Empfänger feststellt, dass zwei andere Quellen kollidieren, MAG er die Pakete der einen behalten und die der anderen verwerfen, wenn dies anhand unterschiedlicher Quell-Transportadressen oder CNAMEs erkannt werden kann. Die beiden Quellen werden erwartet, die Kollision aufzulösen, damit der Zustand nicht andauert.

Da die zufälligen SSRC-Identifikatoren für jede RTP-Sitzung global eindeutig gehalten werden, können sie auch zur Erkennung von Schleifen verwendet werden, die durch Mischer oder Übersetzer eingeführt werden können. Eine Schleife verursacht Duplizierung von Daten- und Steuerinformationen, entweder unverändert oder möglicherweise gemischt, wie in den folgenden Beispielen:

  • Ein Übersetzer kann ein Paket falschlicherweise an dieselbe Multicast-Gruppe weiterleiten, von der er es empfangen hat, entweder direkt oder über eine Kette von Übersetzern. In diesem Fall erscheint dasselbe Paket mehrmals, stammend von verschiedenen Netzwerkquellen.

  • Zwei falsch parallel konfigurierte Übersetzer, d. h. mit denselben Multicast-Gruppen auf beiden Seiten, würden beide Pakete von einer Multicast-Gruppe zur anderen weiterleiten. Unidirektionale Übersetzer würden zwei Kopien erzeugen; bidirektionale Übersetzer würden eine Schleife bilden.

  • Ein Mischer kann eine Schleife schließen, indem er an dieselbe Transportzieladresse sendet, auf der er Pakete empfängt, entweder direkt oder über einen anderen Mischer oder Übersetzer. In diesem Fall könnte eine Quelle sowohl als SSRC in einem Datenpaket als auch als CSRC in einem gemischten Datenpaket erscheinen.

Eine Quelle kann feststellen, dass ihre eigenen Pakete geschleift werden, oder dass Pakete einer anderen Quelle geschleift werden (eine Drittanbieter-Schleife). Sowohl Schleifen als auch Kollisionen bei der zufälligen Wahl eines Quellenidentifikators führen zu Paketen, die mit demselben SSRC-Identifikator, aber einer anderen Quell-Transportadresse eintreffen, die von dem das Paket erzeugenden Endsystem oder einem Zwischensystem stammen kann.

Daher KANN eine Quelle, wenn sie ihre Quell-Transportadresse ändert, auch einen neuen SSRC-Identifikator wählen, um nicht als geschleifte Quelle interpretiert zu werden. (Dies ist kein MUST, da in einigen RTP-Anwendungen Quellen während einer Sitzung Adressen ändern können.) Beachten Sie, dass, wenn ein Übersetzer neu startet und dadurch die Quell-Transportadresse (z. B. die UDP-Quellportnummer) ändert, auf der er Pakete weiterleitet, all diese Pakete bei den Empfängern so erscheinen, als wären sie geschleift, da die SSRC-Identifikatoren von der ursprünglichen Quelle angewandt werden und sich nicht ändern. Dieses Problem kann vermieden werden, indem die Quell-Transportadresse über Neustarts hinweg festgehalten wird, wird aber in jedem Fall nach einem Ablauf bei den Empfängern aufgelöst.

Schleifen oder Kollisionen, die auf der fernen Seite eines Übersetzers oder Mischers auftreten, können mittels der Quell-Transportadresse nicht erkannt werden, wenn alle Kopien der Pakete durch den Übersetzer oder Mischer gehen; jedoch können Kollisionen weiterhin erkannt werden, wenn Blöcke aus zwei RTCP-SDES-Paketen denselben SSRC-Identifikator, aber unterschiedliche CNAMEs enthalten.

Um diese Konflikte zu erkennen und aufzulösen, MUSS eine RTP-Implementierung einen Algorithmus ähnlich dem unten beschriebenen enthalten, obwohl die Implementierung eine andere Richtlinie wählen MAG, welche Pakete von kollidierenden Drittanbieter-Quellen behalten werden. Der unten beschriebene Algorithmus ignoriert Pakete von einer neuen Quelle oder Schleife, die mit einer etablierten Quelle kollidieren. Er löst Kollisionen mit dem eigenen SSRC-Identifikator des Teilnehmers durch Senden eines RTCP-BYE für den alten Identifikator und Wahl eines neuen auf. Wenn jedoch die Kollision durch eine Schleife der eigenen Pakete des Teilnehmers verursacht wurde, wird der Algorithmus einen neuen Identifikator nur einmal wählen und danach Pakete von der geschleiften Quell-Transportadresse ignorieren. Dies ist erforderlich, um eine Flut von BYE-Paketen zu vermeiden.

Dieser Algorithmus erfordert die Führung einer nach dem Quellenidentifikator indizierten Tabelle, die die Quell-Transportadressen aus dem ersten RTP-Paket und ersten RTCP-Paket, die mit diesem Identifikator empfangen wurden, sowie anderen Zustand für diese Quelle enthält. Zwei Quell-Transportadressen sind erforderlich, da beispielsweise die UDP-Quellportnummern bei RTP- und RTCP-Paketen unterschiedlich sein können. Es kann jedoch angenommen werden, dass die Netzwerkadresse in beiden Quell-Transportadressen dieselbe ist.

Jeder in einem RTP- oder RTCP-Paket empfangene SSRC- oder CSRC-Identifikator wird in der Quellenidentifikatortabelle nachgeschlagen, um diese Daten oder Steuerinformationen zu verarbeiten. Die Quell-Transportadresse aus dem Paket wird mit der entsprechenden Quell-Transportadresse in der Tabelle verglichen, um eine Schleife oder Kollision zu erkennen, falls sie nicht übereinstimmen. Für Steuerpakete erfordert jedes Element mit eigenem SSRC-Identifikator, beispielsweise ein SDES-Block, einen separaten Nachschlagevorgang. (Der SSRC-Identifikator in einem Empfangsberichtsblock ist eine Ausnahme, da er eine Quelle bezeichnet, die vom Berichtenden gehört wurde, und dieser SSRC-Identifikator steht in keinem Zusammenhang mit der Quell-Transportadresse des vom Berichtenden gesendeten RTCP-Pakets.) Wenn der SSRC oder CSRC nicht gefunden wird, wird ein neuer Eintrag erstellt. Diese Tabelleneinträge werden entfernt, wenn ein RTCP-BYE-Paket mit dem entsprechenden SSRC-Identifikator empfangen und durch passende Quell-Transportadresse validiert wird, oder nachdem für relativ lange Zeit keine Pakete angekommen sind (siehe Abschnitt 6.2.1).

Beachten Sie, dass, wenn zwei Quellen auf demselben Host zum Zeitpunkt des Beginns des Empfängerbetriebs mit demselben Quellenidentifikator senden, es möglich wäre, dass das zuerst empfangene RTP-Paket von einer der Quellen stammte, während das zuerst empfangene RTCP-Paket von der anderen stammte. Dies würde die falschen RTCP-Informationen mit den RTP-Daten verknüpfen, aber diese Situation sollte selten und harmlos genug sein, um ignoriert zu werden.

Um Schleifen der eigenen Datenpakete des Teilnehmers zu verfolgen, MUSS die Implementierung auch eine separate Liste der als konfliktierend befundenen Quell-Transportadressen (nicht Identifikatoren) führen. Wie in der Quellenidentifikatortabelle MÜSSEN zwei Quell-Transportadressen gehalten werden, um konfliktierende RTP- und RTCP-Pakete separat zu verfolgen. Beachten Sie, dass die Konfliktadressliste kurz sein sollte, meist leer. Jedes Element in dieser Liste speichert die Quelladressen plus die Zeit, zu der das zuletzt konfliktierende Paket empfangen wurde. Ein Element KANN aus der Liste entfernt werden, wenn für eine Zeit in der Größenordnung von 10 RTCP-Berichtsintervallen kein konfliktierendes Paket von dieser Quelle angekommen ist (siehe Abschnitt 6.2).

Für den gezeigten Algorithmus wird angenommen, dass der eigene Quellenidentifikator und Zustand des Teilnehmers in der Quellenidentifikatortabelle enthalten sind. Der Algorithmus könnte umstrukturiert werden, um zuerst einen separaten Vergleich gegen den eigenen Quellenidentifikator des Teilnehmers durchzuführen.

   if (SSRC or CSRC identifier is not found in the source
       identifier table) {
       create a new entry storing the data or control source
           transport address, the SSRC or CSRC and other state;
   }

   /* Identifier is found in the table */

   else if (table entry was created on receipt of a control packet
            and this is the first data packet or vice versa) {
       store the source transport address from this packet;
   }
   else if (source transport address from the packet does not match
            the one saved in the table entry for this identifier) {

       /* An identifier collision or a loop is indicated */

       if (source identifier is not the participant's own) {
           /* OPTIONAL error counter step */
           if (source identifier is from an RTCP SDES chunk
               containing a CNAME item that differs from the CNAME
               in the table entry) {
               count a third-party collision;
           } else {
               count a third-party loop;
           }
           abort processing of data packet or control element;
           /* MAY choose a different policy to keep new source */
       }

       /* A collision or loop of the participant's own packets */

       else if (source transport address is found in the list of
                conflicting data or control source transport
                addresses) {
           /* OPTIONAL error counter step */
           if (source identifier is not from an RTCP SDES chunk
               containing a CNAME item or CNAME is the
               participant's own) {
               count occurrence of own traffic looped;
           }
           mark current time in conflicting address list entry;
           abort processing of data packet or control element;
       }

       /* New collision, change SSRC identifier */

       else {
           log occurrence of a collision;
           create a new entry in the conflicting data or control
               source transport address list and mark current time;
           send an RTCP BYE packet with the old SSRC identifier;
           choose a new SSRC identifier;
           create a new entry in the source identifier table with
               the old SSRC plus the source transport address from
               the data or control packet being processed;
       }
   }

In diesem Algorithmus werden Pakete von einer neu konfliktierenden Quelladresse ignoriert und Pakete von der ursprünglichen Quelladresse behalten. Wenn für einen längeren Zeitraum keine Pakete von der ursprünglichen Quelle ankommen, läuft der Tabelleneintrag ab und die neue Quelle kann übernehmen. Dies könnte eintreten, wenn die ursprüngliche Quelle die Kollision erkennt und zu einem neuen Quellenidentifikator wechselt, aber im üblichen Fall wird ein RTCP-BYE-Paket von der ursprünglichen Quelle empfangen, um den Zustand ohne Warten auf einen Ablauf zu löschen.

Wenn die ursprüngliche Quelladresse über einen Mischer empfangen wurde (d. h. als CSRC gelernt) und später dieselbe Quelle direkt empfangen wird, ist der Empfänger gut beraten, zur neuen Quelladresse zu wechseln, es sei denn, andere Quellen im Mix gingen verloren. Ferner SOLLTE für Anwendungen wie Telefonie, bei denen einige Quellen wie mobile Entitäten Adressen während einer RTP-Sitzung ändern können, die RTP-Implementierung den Kollisionserkennungsalgorithmus modifizieren, um Pakete von der neuen Quell-Transportadresse zu akzeptieren. Um ein Hin-und-Her-Springen zwischen Adressen bei einer echten Kollision zu vermeiden, SOLLTE der Algorithmus Mittel zur Erkennung dieses Falls und zur Vermeidung des Wechsels enthalten.

Wenn ein neuer SSRC-Identifikator aufgrund einer Kollision gewählt wird, SOLLTE der Kandidat-Identifikator zuerst in der Quellenidentifikatortabelle nachgeschlagen werden, um zu sehen, ob er bereits von einer anderen Quelle verwendet wurde. Falls ja, MUSS ein anderer Kandidat erzeugt und der Prozess wiederholt werden.

Eine Schleife von Datenpaketen zu einem Multicast-Ziel kann zu schwerer Netzwerkflutung führen. Alle Mischer und Übersetzer MÜSSEN einen Schleifenerkennungsalgorithmus wie diesen implementieren, damit sie Schleifen unterbrechen können. Dies sollte den überschüssigen Traffc auf nicht mehr als eine duplizierte Kopie des ursprünglichen Traffcs begrenzen, was die Fortsetzung der Sitzung ermöglichen mag, damit die Ursache der Schleife gefunden und behoben werden kann. In extremen Fällen, in denen ein Mischer oder Übersetzer die Schleife nicht ordnungsgemäß unterbricht und hohe Traffic-Level resultieren, kann es notwendig sein, dass Endsysteme das Senden von Daten- oder Steuerpaketen vollständig einstellen. Diese Entscheidung kann von der Anwendung abhängen. Ein Fehlerzustand SOLLTE angemessen angezeigt werden. Die Übertragung KANN nach einer langen, zufälligen Zeit (in der Größenordnung von Minuten) periodisch erneut versucht werden.

8.3 Use with Layered Encodings (Verwendung mit geschichteten Kodierungen)​

Für auf separaten RTP-Sitzungen übertragene geschichtete Kodierungen (siehe Abschnitt 2.4) SOLLTE ein einzelner SSRC-Identifikatorraum über die Sitzungen aller Schichten hinweg verwendet werden, und die Kern- (Basis-)Schicht SOLLTE für die SSRC-Identifikator-Zuweisung und -Kollisionsauflösung verwendet werden. Wenn eine Quelle feststellt, dass sie kollidiert ist, überträgt sie ein RTCP-BYE-Paket nur auf der Basisschicht, ändert aber den SSRC-Identifikator auf den neuen Wert in allen Schichten.