RFC 3550 - Appendix B. Changes from RFC 1889

Appendix B - Änderungen gegenüber RFC 1889 (Changes from RFC 1889)

Der größte Teil dieses RFC ist identisch mit RFC 1889. Es gibt keine Änderungen an den Paketformaten auf dem Übertragungsweg, sondern nur Änderungen an den Regeln und Algorithmen, die die Verwendung des Protokolls steuern. Die größte Änderung ist eine Erweiterung des skalierbaren Timer-Algorithmus zur Berechnung des Zeitpunkts für das Senden von RTCP-Paketen:

o Der in den Abschnitten 6.2 und 6.3 beschriebene und in Anhang A.7 veranschaulichte Algorithmus zur Berechnung des RTCP-Sendeintervalls wurde um eine „Neubetrachtung" (reconsideration) ergänzt, um die Übersendung über die beabsichtigte Rate hinaus zu minimieren, wenn viele Teilnehmer gleichzeitig einer Sitzung beitreten, sowie um eine „umgekehrte Neubetrachtung" (reverse reconsideration), um Häufigkeit und Dauer von falschen Teilnehmer-Timeouts zu verringern, wenn die Zahl der Teilnehmer schnell sinkt. Die umgekehrte Neubetrachtung wird ebenfalls verwendet, um die Verzögerung vor dem Senden eines RTCP-SR bei einem Wechsel vom passiven Empfänger zum aktiven Sender-Modus möglicherweise zu verkürzen.

o Abschnitt 6.3.7 legt neue Regeln fest, die steuern, wann ein RTCP-BYE- Paket gesendet werden soll, um eine Flut von Paketen zu vermeiden, wenn viele Teilnehmer gleichzeitig eine Sitzung verlassen.

o Die Anforderung, den Zustand inaktiver Teilnehmer für einen Zeitraum zu halten, der typische Netzwerkpartitionen überbrückt, wurde aus Abschnitt 6.2.1 entfernt. In einer Sitzung, in der viele Teilnehmer für kurze Zeit beitreten und es versäumen, BYE zu senden, würde diese Anforderung eine deutliche Überschätzung der Teilnehmerzahl bewirken. Der in dieser Überarbeitung hinzugefügte Neubetrachtungs-Algorithmus gleicht die große Zahl gleichzeitig beitretender neuer Teilnehmer aus, wenn eine Partition heilt.

Es ist zu beachten, dass diese Erweiterungen nur dann eine deutliche Wirkung haben, wenn die Zahl der Sitzungsteilnehmer groß (tausende) ist und die meisten Teilnehmer zur gleichen Zeit beitreten oder gehen. Dies macht das Testen in einem Live-Netzwerk schwierig. Der Algorithmus wurde jedoch einer gründlichen Analyse und Simulation unterzogen, um seine Leistung zu verifizieren. Darüber hinaus wurde der erweiterte Algorithmus so entworfen, dass er mit dem Algorithmus in RFC 1889 interoperabel ist, sodass das Ausmaß der Reduzierung der überschüssigen RTCP-Bandbreite während eines sprungartigen Beitritts proportional zum Anteil der Teilnehmer ist, die den erweiterten Algorithmus implementieren. Die Interoperabilität beider Algorithmen wurde experimentell in Live-Netzwerken verifiziert.

Weitere funktionale Änderungen waren:

o Abschnitt 6.2.1 legt fest, dass Implementierungen nur eine Stichprobe der SSRC-Bezeichner der Teilnehmer speichern dürfen, um die Skalierung auf sehr große Sitzungen zu ermöglichen. Algorithmen sind in RFC 2762 [21] spezifiziert.

o In Abschnitt 6.2 wird festgelegt, dass die RTCP-Sender- und Nicht-Sender-Bandbreiten als separate Parameter der Sitzung und nicht als strenger Prozentsatz der Sitzungsbandbreite gesetzt werden können und auf Null gesetzt werden dürfen. Die Anforderung, dass RTCP für RTP-Sitzungen mit IP-Multicast zwingend war, wurde gelockert. Es wurde jedoch ebenfalls klargestellt, dass das Abschalten von RTCP NICHT EMPFOHLEN wird.

o In den Abschnitten 6.2, 6.3.1 und Anhang A.7 wird festgelegt, dass sich der Anteil der Teilnehmer, unterhalb dessen Sendern dedizierte RTCP- Bandbreite zugewiesen wird, vom festen 1/4 auf ein Verhältnis ändert, das auf den RTCP-Sender- und Nicht-Sender-Bandbreitenparametern basiert, sofern diese angegeben sind. Die Bedingung, dass keine Bandbreite Sendern zugewiesen wird, wenn keine Sender vorhanden sind, wurde entfernt, da dies ein vorübergehender Zustand erwartet wird. Es verhindert zudem, dass Nicht-Sender die Sender-RTCP-Bandbreite nutzen, wenn dies nicht beabsichtigt ist.

o Ebenfalls in Abschnitt 6.2 wird festgelegt, dass das minimale RTCP-Intervall für Sitzungen mit hoher Bandbreite auf kleinere Werte skaliert werden kann und dass die anfängliche RTCP-Verzögerung für Unicast-Sitzungen auf Null gesetzt werden darf.

o Das Timeout eines Teilnehmers soll auf Inaktivität über eine Anzahl von RTCP-Berichtsintervallen basieren, die mit dem RTCP-Bandbreitenanteil des Empfängers berechnet werden, selbst für aktive Sender.

o Die Abschnitte 7.2 und 7.3 legen fest, dass Übersetzer und Mischer BYE-Pakete für die Quellen senden sollen, die sie nicht mehr weiterleiten.

o Regeländerungen für geschichtete Kodierungen sind in den Abschnitten 2.4, 6.3.9, 8.3 und 11 definiert. Im letzten davon wird darauf hingewiesen, dass die Adress- und Portzuweisungsregel mit der SDP-Spezifikation, RFC 2327 [15], in Konflikt steht, es ist jedoch beabsichtigt, diese Einschränkung in einer Überarbeitung von RFC 2327 zu lockern.

o Die Konvention zur Verwendung von geraden/ungeraden Portpaaren für RTP und RTCP in Abschnitt 11 wurde klargestellt und bezieht sich nun auf Zielports. Die Anforderung, ein gerades/ungerades Portpaar zu verwenden, wurde entfernt, wenn die beiden Ports explizit angegeben sind. Für Unicast-RTP-Sitzungen können unterschiedliche Portpaare für die beiden Enden verwendet werden (Abschnitte 3, 7.1 und 11).

o Ein neuer Abschnitt 10 wurde hinzugefügt, um die Anforderung an die Stauungskontrolle (congestion control) in Anwendungen, die RTP verwenden, zu erklären.

o In Abschnitt 8.2 wurde die Anforderung gelockert, dass ein neuer SSRC-Bezeichner GEWÄHLT WERDEN MUSS, sobald sich die Quell-Transportadresse ändert, und stattdessen festgelegt, dass ein neuer SSRC-Bezeichner GEWÄHLT WERDEN KANN. Entsprechend wurde klargestellt, dass eine Implementierung

  bei einer SSRC-Kollision zwischen zwei anderen Teilnehmern wählen
  darf, Pakete der neuen Quelladresse statt der vorhandenen Quelladresse
  beizubehalten, und dies SOLLTE für Anwendungen wie Telefonie tun, bei
  denen einige Quellen wie mobile Einheiten ihre Adressen im Verlauf
  einer RTP-Sitzung ändern können.

o Ein Einrückungsfehler im RFC-1889-Druck des Pseudocodes für den Kollisionserkennungs- und -auflösungsalgorithmus in Abschnitt 8.2 wurde durch Übersetzung der Syntax in eine Pseudo-C-Sprache behoben, und der Algorithmus wurde geändert, um die Einschränkung zu entfernen, dass sowohl RTP als auch RTCP von derselben Quellportnummer gesendet werden müssen.

o Die Beschreibung des Padding-Mechanismus für RTCP-Pakete wurde klargestellt, und es wird festgelegt, dass Padding NUR auf das letzte Paket eines zusammengesetzten RTCP-Pakets angewendet werden muss.

o In Abschnitt A.1 wurde die Initialisierung von base_seq korrigiert auf seq statt seq - 1, und der Text wurde korrigiert, sodass die fehlerhafte Sequenznummer plus 1 gespeichert wird. Die Initialisierung von max_seq und anderen Variablen für den Algorithmus wurde vom Text getrennt, um klarzumachen, dass diese Initialisierung zusätzlich zum Aufruf der Funktion init_seq() erfolgen muss (und einige bei der Verarbeitung des Dokuments von der Quell- zur Ausgabeform in RFC 1889 verlorene Wörter wurden wiederhergestellt).

o Die Begrenzung der Anzahl verlorener Pakete in Abschnitt A.3 wurde korrigiert, um sowohl positive als auch negative Grenzen zu verwenden.

o Die Spezifikation des „relativen" NTP-Zeitstempels im RTCP-SR-Abschnitt definiert diese Zeitstempel nun basierend auf der gebräuchlichsten systemspezifischen Uhr, wie der Systemlaufzeit (system uptime), statt auf der Sitzungslaufzeit, die für mehrere zu unterschiedlichen Zeiten auf demselben Rechner gestartete Anwendungen nicht gleich wäre.

Nicht-funktionale Änderungen:

o Es wird festgelegt, dass ein Empfänger Pakete mit Nutzlasttypen, die er nicht versteht, ignorieren MUSS.

o In Abbildung 2 wurde der Fließkomma-NTP-Zeitstempelwert korrigiert, einige fehlende führende Nullen in einer Hexadezimalzahl ergänzt und die UTC-Zeitzone angegeben.

o Die Unwirksamkeit des Überlaufs von NTP-Zeitstempeln im Jahr 2036 wird erklärt.

o Die Richtlinie für die Registrierung von RTCP-Pakettypen und SDES-Typen wurde in einem neuen Abschnitt 15, IANA-Betrachtungen, klargestellt. Der Vorschlag, dass Experimentatoren die benötigten Nummern registrieren und dann diejenigen abmelden, die sich als unnötig erweisen, wurde zugunsten der Verwendung von APP und PRIV entfernt. Ebenfalls wurde die Registrierung von Profilnamen spezifiziert.

o Die Referenz für den UTF-8-Zeichensatz wurde von einer X/Open Preliminary Specification zu RFC 2279 geändert.

o Die Referenz für RFC 1597 wurde auf RFC 1918 aktualisiert und die Referenz für RFC 2543 wurde auf RFC 3261 aktualisiert.

o Der letzte Absatz der Einleitung in RFC 1889, der Implementierer warnte, die Bereitstellung im Internet zu begrenzen, wurde entfernt, da er als nicht mehr relevant erachtet wurde.

o Ein nicht-normativer Hinweis bezüglich der Verwendung von RTP mit Source-Specific Multicast (SSM) wurde in Abschnitt 6 hinzugefügt.

o Die Definition von „RTP-Sitzung" in Abschnitt 3 wurde erweitert, um anzuerkennen, dass eine einzelne Sitzung mehrere Ziel-Transportadressen verwenden kann (wie stets beim Übersetzer oder Mischer der Fall) und um zu erklären, dass das unterscheidende Merkmal einer RTP-Sitzung darin besteht, dass jede einem separaten SSRC-Bezeichnerraum entspricht. Eine neue Definition von „Multimedia-Sitzung" wurde hinzugefügt, um Verwirrung über das Wort „Sitzung" zu verringern.

o Die Bedeutung von „Abtastzeitpunkt" (sampling instant) wurde als Teil der Definition des Zeitstempelfelds des RTP-Headers in Abschnitt 5.1 detaillierter erklärt.

o Kleine Klarstellungen des Textes wurden an mehreren Stellen vorgenommen, einige als Reaktion auf Fragen von Lesern. Insbesondere:

  -  In RFC 1889 gingen die ersten fünf Wörter des zweiten Satzes von
     Abschnitt 2.2 bei der Verarbeitung des Dokuments von der Quell-
     zur Ausgabeform verloren, sind nun jedoch wiederhergestellt.

  -  Eine Definition für „RTP-Medientyp" wurde in Abschnitt 3
     hinzugefügt, um die Erklärung der Multiplexbildung von RTP-
     Sitzungen in Abschnitt 5.2 bezüglich der Multiplexbildung
     mehrerer Medien klarer zu machen.  Dieser Abschnitt erklärt nun
     ebenfalls, dass die Multiplexbildung mehrerer Quellen desselben
     Mediums basierend auf SSRC-Bezeichnern angemessen sein kann und
     bei Multicast-Sitzungen die Norm ist.

  -  Die Definition für „nicht-RTP-Mittel" wurde erweitert, um
     Beispiele für andere Protokolle zu umfassen, die nicht-RTP-Mittel
     darstellen.

  -  Die Beschreibung des Parameters für die Sitzungsbandbreite wird in
     Abschnitt 6.2 erweitert, einschließlich der Klarstellung, dass die
     Bandbreite des Kontrollverkehrs zusätzlich zur Sitzungsbandbreite
     für den Datenverkehr zu rechnen ist.

  -  Die Auswirkung variierender Paketdauern auf die Jitter-Berechnung
     wurde in Abschnitt 6.4.4 erklärt.

  -  Die Methode zum Beenden und Auffüllen einer Sequenz von
     SDES-Elementen wurde in Abschnitt 6.5 klargestellt.

  -  IPv6-Adressbeispiele wurden in der Beschreibung von SDES CNAME in
     Abschnitt 6.5.1 hinzugefügt, und „example.com" wurde anstelle
     anderer Beispiel-Domänennamen verwendet.

  -  Der Sicherheitsabschnitt fügte nun eine formale Referenz auf
     IPSEC hinzu, da dieses verfügbar ist, und sagt, dass die in dieser
     Spezifikation definierte Vertraulichkeitsmethode primär bestehende
     Praxis kodifiziert.  Es wird EMPFOHLEN, stärkere
     Verschlüsselungsalgorithmen wie Triple-DES anstelle des
     Standardalgorithmus zu verwenden, und es wurde festgestellt, dass
     das auf AES basierende SRTP-Profil in Zukunft die richtige Wahl
     sein wird.  Es wurde ein Hinweis auf die Schwäche des RTP-Headers
     als Initialisierungsvektor hinzugefügt.  Ebenfalls wurde
     festgestellt, dass nur-Nutzlast-Verschlüsselung notwendig ist, um
     Header-Kompression zu ermöglichen.

  -  Die Methode zur partiellen Verschlüsselung von RTCP wurde
     klargestellt; insbesondere wird SDES CNAME beim Aufteilen des
     zusammengesetzten RTCP-Pakets nur in einem Teil mitgeführt.

  -  Es wird klargestellt, dass pro Berichtsintervall nur ein
     zusammengesetztes RTCP-Paket gesendet werden sollte und dass, wenn
     es zu viele aktive Quellen für die Berichte innerhalb der MTU gibt,
     eine Teilmenge der Quellen round-robin über mehrere Intervalle
     ausgewählt werden sollte.

  -  Ein Hinweis wurde in Anhang A.1 hinzugefügt, dass Pakete während
     der RTP-Header-Validierung gespeichert und bei Erfolg zugestellt
     werden dürfen.

  -  Abschnitt 7.3 erklärt nun, dass ein Mischer, der SDES-Pakete
     aggregiert, aufgrund längerer Pakete mehr RTCP-Bandbreite verwendet,
     und ein Mischer, der RTCP durchleitet, naturgemäß Pakete mit einer
     höheren Rate als die Einzelquellenrate sendet, aber beide
     Verhaltensweisen gültig sind.

  -  Abschnitt 13 stellt klar, dass eine RTP-Anwendung mehrere Profile
     verwenden kann, typischerweise jedoch nur eines in einer gegebenen
     Sitzung.

  -  Die Begriffe MUST, SHOULD, MAY usw. werden wie in RFC 2119 definiert
     verwendet.

  -  Die Bibliographie wurde in normative und informative Referenzen
     unterteilt.