Zum Hauptinhalt springen

6. Definitionen der Nutzlasttypen

  1. Definitionen der Nutzlasttypen

Die Tabellen 4 und 5 definieren die statischen Nutzlasttypwerte dieses Profils für das PT-Feld des RTP-Daten-Headers. Darüber hinaus KÖNNEN Nutzlasttypwerte im Bereich 96-127 über ein Konferenzsteuerungsprotokoll dynamisch definiert werden, was über den Umfang dieses Dokuments hinausgeht. Ein Sitzungsverzeichnis könnte beispielsweise festlegen, dass für eine gegebene Sitzung der Nutzlasttyp 96 die PCMU-Kodierung, 8.000 Hz Abtastrate, 2 Kanäle angibt. Einträge in den Tabellen 4 und 5 mit dem Nutzlasttyp "dyn" haben keinen statischen Nutzlasttyp zugewiesen und werden nur mit einem dynamischen Nutzlasttyp verwendet. Der Nutzlasttyp 2 wurde in RFC 1890 G721 zugewiesen und in Entwurfsversionen dieser Spezifikation seinem gleichwertigen Nachfolger G726-32, aber seine Verwendung ist jetzt veraltet und dieser statische Nutzlasttyp ist aufgrund der widersprüchlichen Verwendung für die Nutzlastformate G726-32 und AAL2-G726-32 (siehe Abschnitt 4.5.4) als reserviert markiert. Der Nutzlasttyp 13 gibt das in RFC 3389 [9] spezifizierte Comfort Noise (CN) Nutzlastformat an. Der Nutzlasttyp 19 ist als "reserviert" markiert, weil einige Entwurfsversionen dieser Spezifikation diese Nummer einer früheren Version des Comfort-Noise-Nutzlastformats zugewiesen haben. Der Nutzlasttypbereich 72-76 ist als "reserviert" markiert, damit RTCP- und RTP-Pakete zuverlässig unterschieden werden können (siehe Abschnitt "Zusammenfassung der Protokollkonstanten" der RTP-Protokollspezifikation).

Die derzeit in diesem Profil definierten Nutzlasttypen sind genau einer von drei Kategorien oder Medientypen zugeordnet: nur Audio, nur Video und solche, die Audio und Video kombinieren. Die Medientypen sind in den Tabellen 4 und 5 als "A", "V" bzw. "AV" gekennzeichnet. Nutzlasttypen verschiedener Medientypen DÜRFEN NICHT innerhalb einer einzelnen RTP-Sitzung verschachtelt oder gemultiplext werden, aber mehrere RTP-Sitzungen KÖNNEN parallel verwendet werden, um mehrere Medientypen zu senden. Eine RTP-Quelle KANN während einer Sitzung Nutzlasttypen innerhalb desselben Medientyps ändern. Siehe den Abschnitt "Multiplexing RTP Sessions" von RFC 3550 für zusätzliche Erklärungen.

           PT   Kodierungs- Medientyp   Taktrate     Kanäle
name (Hz)
___________________________________________________
0 PCMU A 8.000 1
1 reserviert A
2 reserviert A
3 GSM A 8.000 1
4 G723 A 8.000 1
5 DVI4 A 8.000 1
6 DVI4 A 16.000 1
7 LPC A 8.000 1
8 PCMA A 8.000 1
9 G722 A 8.000 1
10 L16 A 44.100 2
11 L16 A 44.100 1
12 QCELP A 8.000 1
13 CN A 8.000 1
14 MPA A 90.000 (siehe Text)
15 G728 A 8.000 1
16 DVI4 A 11.025 1
17 DVI4 A 22.050 1
18 G729 A 8.000 1
19 reserviert A
20 nicht zugew. A
21 nicht zugew. A
22 nicht zugew. A
23 nicht zugew. A
dyn G726-40 A 8.000 1
dyn G726-32 A 8.000 1
dyn G726-24 A 8.000 1
dyn G726-16 A 8.000 1
dyn G729D A 8.000 1
dyn G729E A 8.000 1
dyn GSM-EFR A 8.000 1
dyn L8 A var. var.
dyn RED A (siehe Text)
dyn VDVI A var. 1

Tabelle 4: Nutzlasttypen (PT) für Audiokodierungen

PT Kodierungs- Medientyp Taktrate
name (Hz)
_____________________________________________
24 nicht zugew. V
25 CelB V 90.000
26 JPEG V 90.000
27 nicht zugew. V
28 nv V 90.000
29 nicht zugew. V
30 nicht zugew. V
31 H261 V 90.000
32 MPV V 90.000
33 MP2T AV 90.000
34 H263 V 90.000
35-71 nicht zugew. ?
72-76 reserviert N/A N/A
77-95 nicht zugew. ?
96-127 dynamisch ?
dyn H263-1998 V 90.000

Tabelle 5: Nutzlasttypen (PT) für Video- und kombinierte
Kodierungen

Sitzungsteilnehmer einigen sich durch Mechanismen, die über den Umfang dieser Spezifikation hinausgehen, auf den Satz von Nutzlasttypen, die in einer gegebenen Sitzung erlaubt sind. Dieser Satz KANN beispielsweise durch die Fähigkeiten der verwendeten Anwendungen definiert, durch ein Konferenzsteuerungsprotokoll ausgehandelt oder durch Vereinbarung zwischen den menschlichen Teilnehmern festgelegt werden.

Audioanwendungen, die unter diesem Profil arbeiten, SOLLTEN mindestens in der Lage sein, die Nutzlasttypen 0 (PCMU) und 5 (DVI4) zu senden und/oder zu empfangen. Dies ermöglicht Interoperabilität ohne Formataushandlung und gewährleistet eine erfolgreiche Aushandlung mit einem Konferenzsteuerungsprotokoll.