3. Registrierung zusätzlicher Kodierungen

3. Registrierung zusätzlicher Kodierungen

   Dieses Profil listet eine Reihe von Kodierungen auf, von denen jede aus einer bestimmten Mediadatenkomprimierung oder -darstellung sowie einem Nutzlastformat zur Kapselung innerhalb von RTP besteht. Einige dieser Nutzlastformate sind hier spezifiziert, während andere in separaten RFCs spezifiziert sind. Es wird erwartet, dass in Zukunft zusätzliche Kodierungen über die hier aufgeführten hinaus erstellt und in zusätzlichen Nutzlastformat-RFCs spezifiziert werden.

   Dieses Profil weist jeder Kodierung auch einen kurzen Namen zu, der von übergeordneten Steuerungsprotokollen wie dem Session Description Protocol (SDP), RFC 2327 [6], verwendet werden KANN, um Kodierungen zu identifizieren, die für eine bestimmte RTP-Sitzung ausgewählt wurden.

   In einigen Kontexten kann es nützlich sein, auf diese Kodierungen in Form eines MIME-Inhaltstyps zu verweisen. Um dies zu erleichtern, bietet RFC 3555 [7] Registrierungen für alle hier aufgeführten Kodierungsnamen als MIME-Subtypenamen unter den MIME-Typen "audio" und "video" über das in RFC 2048 [8] spezifizierte MIME-Registrierungsverfahren.

   Alle zusätzlichen Kodierungen, die für die Verwendung unter diesem Profil (oder anderen) spezifiziert sind, können auch Namen zugewiesen bekommen, die als MIME-Subtypen bei der Internet Assigned Numbers Authority (IANA) registriert sind. Dieses Register bietet eine Möglichkeit sicherzustellen, dass die den zusätzlichen Kodierungen zugewiesenen Namen eindeutig bleiben. RFC 3555 spezifiziert die Informationen, die für die Registrierung von RTP-Kodierungen erforderlich sind.

   Zusätzlich zur Zuweisung von Namen zu Kodierungen weist dieses Profil einigen von ihnen auch statische RTP-Nutzlasttypnummern zu. Der Nummernbereich für Nutzlasttypen ist jedoch relativ klein und kann keine Zuweisungen für alle bestehenden und zukünftigen Kodierungen aufnehmen. In den frühen Phasen der RTP-Entwicklung war es notwendig, statisch zugewiesene Nutzlasttypen zu verwenden, da kein anderer Mechanismus spezifiziert worden war, um Kodierungen an Nutzlasttypen zu binden. Es wurde erwartet, dass Nicht-RTP-Mittel außerhalb des Geltungsbereichs dieses Memos (wie Verzeichnisdienste oder Einladungsprotokolle) spezifiziert würden, um eine dynamische Zuordnung zwischen einem Nutzlasttyp und einer Kodierung herzustellen. Inzwischen wurden Mechanismen zur Definition dynamischer Nutzlasttypbindungen im Session Description Protocol (SDP) und in anderen Protokollen wie der ITU-T-Empfehlung H.323/H.245 spezifiziert. Diese Mechanismen verknüpfen den registrierten Namen des Kodierungs-/Nutzlastformats zusammen mit allen zusätzlich erforderlichen Parametern, wie der RTP-Zeitstempel-Taktrate und der Anzahl der Kanäle, mit einer Nutzlasttypnummer. Diese Verknüpfung ist nur für die Dauer der RTP-Sitzung wirksam, in der die dynamische Nutzlasttypbindung vorgenommen wird. Diese Verknüpfung gilt nur für die RTP-Sitzung, für die sie vorgenommen wird, daher können die Nummern für verschiedene Kodierungen in verschiedenen Sitzungen wiederverwendet werden, so dass die Begrenzung des Nummernraums vermieden wird.

   Dieses Profil reserviert Nutzlasttypnummern im Bereich 96-127 ausschließlich für die dynamische Zuweisung. Anwendungen SOLLTEN zuerst Werte in diesem Bereich für dynamische Nutzlasttypen verwenden. Diejenigen Anwendungen, die mehr als 32 dynamische Nutzlasttypen definieren müssen, KÖNNEN Codes unter 96 binden, in welchem Fall es EMPFOHLEN wird, zuerst nicht zugewiesene Nutzlasttypnummern zu verwenden. Die statisch zugewiesenen Nutzlasttypen sind jedoch Standardbindungen und KÖNNEN bei Bedarf dynamisch an neue Kodierungen gebunden werden. Das Neudefinieren von Nutzlasttypen unter 96 kann zu inkorrektem Betrieb führen, wenn versucht wird, einer Sitzung beizutreten, ohne Sitzungsbeschreibungsinformationen zu erhalten, die die dynamischen Nutzlasttypen definieren.

   Dynamische Nutzlasttypen SOLLTEN NICHT ohne einen wohl definierten Mechanismus verwendet werden, um die Zuordnung anzuzeigen. Systeme, die erwarten, mit anderen unter diesem Profil arbeitenden Systemen zu interagieren, SOLLTEN KEINE eigenen Zuweisungen von proprietären Kodierungen zu bestimmten, festen Nutzlasttypen vornehmen.

   Diese Spezifikation legt die Richtlinie fest, dass keine zusätzlichen statischen Nutzlasttypen über die in diesem Dokument definierten hinaus zugewiesen werden. Die Festlegung dieser Richtlinie vermeidet das Problem, Kriterien für die Annahme statischer Zuweisungen erstellen zu müssen, und fördert die Implementierung und Bereitstellung der dynamischen Nutzlasttypmechanismen.

   Der endgültige Satz statischer Nutzlasttypzuweisungen wird in den Tabellen 4 und 5 bereitgestellt.