9. Änderungen gegenüber RFC 1890
- Änderungen gegenüber RFC 1890
Dieses RFC überarbeitet RFC 1890. Es ist weitgehend abwärtskompatibel mit RFC 1890, mit Ausnahme von Funktionen, die entfernt wurden, da keine zwei interoperablen Implementierungen gefunden wurden. Die Ergänzungen zu RFC 1890 kodifizieren die bestehende Praxis bei der Verwendung von Nutzlastformaten unter diesem Profil. Da dieses Profil verwendet werden kann, ohne eines der hier aufgeführten Nutzlastformate zu verwenden, beeinträchtigt das Hinzufügen neuer Nutzlastformate in dieser Überarbeitung nicht die Abwärtskompatibilität. Die Änderungen sind unten aufgeführt, unterteilt in funktionale und nicht-funktionale Änderungen.
Funktionale Änderungen:
o Abschnitt 11, "IANA Considerations", wurde hinzugefügt, um die Registrierung des Namens für dieses Profil zu spezifizieren. Dieser Anhang verweist auch auf einen neuen Abschnitt 3 "Registering Additional Encodings", der eine Richtlinie festlegt, dass keine zusätzliche Registrierung von statischen Nutzlasttypen für dieses Profil vorgenommen wird, die über die in dieser Überarbeitung hinzugefügten und in den Tabellen 4 und 5 enthaltenen hinausgehen. Stattdessen können zusätzliche Kodierungsnamen als MIME-Subtypen für die Bindung an dynamische Nutzlasttypen registriert werden. Nicht-normative Verweise wurden zu RFC 3555 [7] hinzugefügt, wo MIME-Subtypen für alle aufgeführten Nutzlastformate registriert sind, einige mit optionalen Parametern für die Verwendung der Nutzlastformate.
o Statische Nutzlasttypen 4, 16, 17 und 34 wurden hinzugefügt, um IANA-Registrierungen aufzunehmen, die seit der Veröffentlichung von RFC 1890 vorgenommen wurden, zusammen mit den entsprechenden Nutzlastformatbeschreibungen für G723 und H263.
o Nach Diskussionen in der Arbeitsgruppe wurden die statischen Nutzlasttypen 12 und 18 zusammen mit den entsprechenden Nutzlastformatbeschreibungen für QCELP und G729 hinzugefügt. Der statische Nutzlasttyp 13 wurde dem in RFC 3389 definierten Comfort Noise (CN) Nutzlastformat zugewiesen. Nutzlasttyp 19 wurde als reserviert markiert, da er vorübergehend einer früheren Version von Comfort Noise zugewiesen worden war, die in einigen Entwürfen dieses Dokuments vorhanden war.
o Das Nutzlastformat für G721 wurde nach der ITU-T-Umnummerierung in G726-32 umbenannt, und die Nutzlastformatbeschreibung für G726 wurde erweitert, um die Datenraten -16, -24 und -40 einzuschließen. Aufgrund von Verwirrung bezüglich Entwurfsüberarbeitungen dieses Dokuments packten einige Implementierungen dieser G726-Nutzlastformate Proben in Oktts beginnend mit dem höchstwertigen Bit anstatt dem niedrigstwertigen Bit, wie hier spezifiziert. Um diese Inkompatibilität teilweise zu beheben, werden neue Nutzlastformate namens AAL2-G726-16, -24, -32 und -40 in einem separaten Dokument spezifiziert (siehe Hinweis in Abschnitt 4.5.4), und die Verwendung des statischen Nutzlasttyps 2 wird wie in Abschnitt 6 erläutert abgelehnt.
o Die Nutzlastformate G729D und G729E wurden nach der ITU-T-Hinzufügung der Anhänge D und E zur Empfehlung G.729 hinzugefügt. Listen wurden für die Nutzlastformate GSM-EFR, RED und H263-1998 hinzugefügt, die in anderen Dokumenten nach RFC 1890 veröffentlicht wurden. Diese zusätzlichen Nutzlastformate werden nur durch dynamische Nutzlasttypnummern referenziert.
o Die Beschreibungen der Nutzlastformate für G722, G728, GSM, VDVI wurden erweitert.
o Das Nutzlastformat für 1016 Audio wurde entfernt und seine Zuordnung als statischer Nutzlasttyp 1 wurde als "reserviert" markiert, da keine zwei interoperablen Implementierungen gefunden wurden.
o Anforderungen für die Überlastungskontrolle wurden in Abschnitt 2 hinzugefügt.
o Dieses Profil folgt dem Vorschlag in der überarbeiteten RTP-Spezifikation, dass die RTCP-Bandbreite getrennt von der Sitzungsbandbreite und getrennt für aktive Sender und passive Empfänger spezifiziert werden kann.
o Die Zuordnung einer Benutzer-Passphrase-Zeichenfolge zu einem Verschlüsselungsschlüssel wurde aus Abschnitt 2 gelöscht, da keine zwei interoperablen Implementierungen gefunden wurden.
o Die Konvention der "quadrophonen" Probenanordnung für Vierkanal-Audio wurde entfernt, um eine Mehrdeutigkeit zu beseitigen, wie in Abschnitt 4.1 angemerkt.
Nicht-funktionale Änderungen:
o In Abschnitt 4.1 wird nun ausdrücklich darauf hingewiesen, dass die Stilleunterdrückung für alle Audio-Nutzlastformate zulässig ist. (Dies war schon immer der Fall und leitet sich aus einem grundlegenden Aspekt des Designs von RTP und den Motivationen für Paketaudio ab, wurde aber zuvor nicht ausdrücklich erwähnt.) Die Verwendung von Komfortrauschen wird ebenfalls erläutert.
o In Abschnitt 4.1 wurde das Anforderungsniveau für das Setzen des Marker-Bits im ersten Paket nach Stille für Audio von "ist" in "SOLLTE sein" geändert, und es wurde klargestellt, dass das Marker-Bit nur gesetzt wird, wenn Pakete absichtlich nicht gesendet werden.
o Ebenso wurde Text hinzugefügt, um zu spezifizieren, dass das Marker-Bit im letzten Paket eines Videobildes auf eins gesetzt werden SOLLTE und dass Videobilder durch ihre Zeitstempel unterschieden werden.
o RFC-Referenzen werden für Nutzlastformate hinzugefügt, die nach RFC 1890 veröffentlicht wurden.
o Die Sicherheitsüberlegungen und vollständigen Urheberrechtsabschnitte wurden hinzugefügt.
o Laut Peter Hoddie von Apple verwendeten nur Macintosh-Computer vor 1994 die Rate 22254,54 und keiner die Rate 11127,27, sodass letztere aus der Diskussion der vorgeschlagenen Abtastfrequenzen gestrichen wurde.
o Tabelle 1 wurde korrigiert, um einige Werte aus der Spalte "ms/packet" in die Spalte "default ms/packet" zu verschieben, wo sie hingehörten.
o Da die Interactive Multimedia Association den Betrieb eingestellt hat, wurde eine alternative Ressource für ein referenziertes IMA-Dokument bereitgestellt.
o Ein Hinweis wurde für G722 hinzugefügt, um eine Diskrepanz zwischen der tatsächlichen Abtastrate und der RTP-Zeitstempel-Taktrate zu klären.
o Kleine Klarstellungen des Textes wurden an mehreren Stellen vorgenommen, einige als Antwort auf Fragen von Lesern. Insbesondere:
- Eine Definition für "Medientyp" wird in Abschnitt 1.1 gegeben, um
die Erklärung des Multiplexing von RTP-Sitzungen in Abschnitt 6
bezüglich des Multiplexing mehrerer Medien klarer zu machen.
- Die Erklärung, wie die Anzahl der Audioframes in einem Paket aus der Länge bestimmt wird,
wurde erweitert.
- Mehr Beschreibung der Zuweisung von Bandbreite zu SDES-Elementen
wird gegeben.
- Ein Hinweis wurde hinzugefügt, dass die Konvention für die Reihenfolge der Kanäle,
die in Abschnitt 4.1 spezifiziert ist, durch eine bestimmte
Kodierungs- oder Nutzlastformatspezifikation außer Kraft gesetzt werden kann.
- Die Begriffe MUSS, SOLLTE, KANN usw. werden wie in RFC
2119 definiert verwendet.
o Ein zweiter Autor für dieses Dokument wurde hinzugefügt.