4. Audio

Audio

4.1 Kodierungsunabhängige Regeln

Da die Möglichkeit, Stille zu unterdrücken, einer der Hauptgründe für die Verwendung von Paketen zur Sprachübertragung ist, trägt der RTP-Header sowohl eine Sequenznummer als auch einen Zeitstempel, damit ein Empfänger zwischen verlorenen Paketen und Zeiträumen unterscheiden kann, in denen keine Daten übertragen wurden. Diskontinuierliche Übertragung (Stilleunterdrückung) KANN mit jedem Audio-Nutzlastformat verwendet werden. Empfänger MÜSSEN davon ausgehen, dass Sender Stille unterdrücken können, sofern dies nicht durch eine an anderer Stelle spezifizierte Signalisierung eingeschränkt wird. (Auch wenn der Sender Stille nicht unterdrückt, sollte der Empfänger darauf vorbereitet sein, Zeiträume zu behandeln, in denen keine Daten vorhanden sind, da Pakete verloren gehen können.)

Einige Nutzlastformate (siehe Abschnitte 4.5.3 und 4.5.6) definieren einen "Stille- Einfügungs-Deskriptor" oder "Komfortrauschen"-Rahmen, um Parameter für künstliches Rauschen zu spezifizieren, das während einer Stilleperiode erzeugt werden kann, um das Hintergrundrauschen an der Quelle anzunähern. Für andere Nutzlastformate wird ein generisches Komfortrauschen (CN)-Nutzlastformat in RFC 3389 [9] spezifiziert. Wenn das CN-Nutzlastformat zusammen mit einem anderen Nutzlastformat verwendet wird, unterscheiden unterschiedliche Werte im RTP-Nutzlasttyp-Feld Komfortrauschen-Pakete von denen des ausgewählten Nutzlastformats.

Für Anwendungen, die entweder keine Pakete oder gelegentlich Komfortrauschen- Pakete während der Stille senden, SOLLTE das erste Paket eines Sprechabschnitts, d. h. das erste Paket nach einer Stilleperiode, in der Pakete nicht kontinuierlich übertragen wurden, dadurch unterschieden werden, dass das Marker-Bit im RTP-Daten-Header auf eins gesetzt wird. Das Marker-Bit in allen anderen Paketen ist null. Der Beginn eines Sprechabschnitts KANN verwendet werden, um die Ausspielverzögerung anzupassen, um sich ändernde Netzwerkverzögerungen widerzuspiegeln. Anwendungen ohne Stilleunterdrückung MÜSSEN das Marker-Bit auf null setzen.

Die für die Generierung des RTP-Zeitstempels verwendete RTP-Taktrate ist unabhängig von der Anzahl der Kanäle und der Kodierung; sie entspricht normalerweise der Anzahl der Abtastperioden pro Sekunde. Für N-Kanal- Kodierungen erzeugt jede Abtastperiode (sagen wir, 1/8.000 Sekunde) N Abtastwerte. (Diese Terminologie ist Standard, aber etwas verwirrend, da die Gesamtzahl der pro Sekunde erzeugten Abtastwerte dann die Abtastrate mal die Kanalanzahl ist.)

Wenn mehrere Audiokanäle verwendet werden, werden die Kanäle von links nach rechts nummeriert, beginnend bei eins. In RTP-Audiopaketen gehen Informationen von Kanälen mit niedrigerer Nummer denen von Kanälen mit höherer Nummer voraus.

Für mehr als zwei Kanäle SOLLTE die Konvention des AIFF-C- Audioaustauschformats befolgt werden [3], unter Verwendung der folgenden Notation, sofern für eine bestimmte Kodierung oder ein bestimmtes Nutzlastformat keine andere Konvention festgelegt ist:

  l  links (left)
  r  rechts (right)
  c  mitte (center)
  S  Surround
  F  vorne (front)
  R  hinten (rear)

  Kanäle    Beschreibung  Kanal
                            1     2   3   4   5   6
  _________________________________________________
  2         Stereo          l     r
  3                         l     r   c
  4                         l     c   r   S
  5                        Fl     Fr  Fc  Sl  Sr
  6                         l     lc  c   r   rc  S

     Hinweis: RFC 1890 definierte zwei Konventionen für die Reihenfolge von vier
     Audiokanälen. Da die Reihenfolge implizit durch die
     Anzahl der Kanäle angegeben wird, war dies mehrdeutig. In dieser Revision
     wurde die als "quadrophonisch" beschriebene Reihenfolge eliminiert, um
     die Mehrdeutigkeit zu beseitigen. Diese Wahl basierte auf der Beobachtung,
     dass das quadrophonische Consumer-Audioformat nicht populär wurde,
     während Surround-Sound später populär wurde.

Abtastwerte für alle Kanäle, die zu einem einzigen Abtastzeitpunkt gehören, MÜSSEN im selben Paket sein. Die Verschachtelung von Abtastwerten verschiedener Kanäle hängt von der Kodierung ab. Allgemeine Richtlinien werden in Abschnitt 4.3 und 4.4 gegeben.

Die Abtastfrequenz SOLLTE aus dem Satz genommen werden: 8.000, 11.025, 16.000, 22.050, 24.000, 32.000, 44.100 und 48.000 Hz. (Ältere Apple Macintosh-Computer hatten eine native Abtastrate von 22.254,54 Hz, die mit akzeptabler Qualität in 22.050 umgewandelt werden kann, indem 4 Abtastwerte in einem 20-ms-Rahmen weggelassen werden.) Die meisten Audiokodierungen sind jedoch für einen eingeschränkteren Satz von Abtastfrequenzen definiert. Empfänger SOLLTEN darauf vorbereitet sein, Mehrkanal-Audio zu akzeptieren, KÖNNEN aber wählen, nur einen einzigen Kanal abzuspielen.

4.2 Betriebsempfehlungen

Die folgenden Empfehlungen sind Standardbetriebsparameter. Anwendungen SOLLTEN darauf vorbereitet sein, andere Werte zu verarbeiten. Die angegebenen Bereiche sollen Anwendungsentwicklern eine Orientierung geben und es ermöglichen, dass ein Satz von Anwendungen, die diesen Richtlinien entsprechen, ohne zusätzliche Aushandlung zusammenarbeiten kann. Diese Richtlinien sollen nicht die Betriebsparameter für Anwendungen einschränken, die einen Satz interoperabler Parameter aushandeln können, z. B. über ein Konferenzsteuerungsprotokoll.

Für paketiertes Audio SOLLTE das Standard-Paketierungsintervall eine Dauer von 20 ms oder einem Rahmen haben, je nachdem, was länger ist, sofern in Tabelle 1 (Spalte "ms/Paket") nichts anderes angegeben ist. Das Paketierungsintervall bestimmt die minimale Ende-zu-Ende-Verzögerung; längere Pakete führen zu weniger Header-Overhead, aber höherer Verzögerung und machen Paketverluste spürbarer. Für nicht-interaktive Anwendungen wie Vorlesungen oder für Verbindungen mit starken Bandbreitenbeschränkungen KANN eine höhere Paketierungsverzögerung verwendet werden. Ein Empfänger SOLLTE Pakete akzeptieren, die zwischen 0 und 200 ms Audiodaten darstellen. (Für gerahmte Audiokodierungen SOLLTE ein Empfänger Pakete mit einer Anzahl von Rahmen akzeptieren, die gleich 200 ms geteilt durch die Rahmendauer, aufgerundet, ist.) Diese Einschränkung ermöglicht eine vernünftige Pufferdimensionierung für den Empfänger.

4.3 Richtlinien für abtastwertbasierte Audiokodierungen

Bei abtastwertbasierten Kodierungen wird jeder Audioabtastwert durch eine feste Anzahl von Bits dargestellt. Innerhalb der komprimierten Audiodaten können Codes für einzelne Abtastwerte Oktettgrenzen überschreiten. Ein RTP-Audiopaket kann eine beliebige Anzahl von Audioabtastwerten enthalten, unter der Bedingung, dass die Anzahl der Bits pro Abtastwert mal die Anzahl der Abtastwerte pro Paket eine ganze Oktettzahl ergibt. Bruchteilskodierungen erzeugen weniger als ein Oktett pro Abtastwert.

Die Dauer eines Audiopakets wird durch die Anzahl der Abtastwerte im Paket bestimmt.

Für abtastwertbasierte Kodierungen, die ein oder mehrere Oktette pro Abtastwert erzeugen, SOLLTEN Abtastwerte von verschiedenen Kanälen, die zum selben Abtastzeitpunkt abgetastet wurden, in aufeinanderfolgenden Oktetten verpackt werden. Zum Beispiel ist für eine Zwei-Kanal- Kodierung die Oktettsequenz (linker Kanal, erster Abtastwert), (rechter Kanal, erster Abtastwert), (linker Kanal, zweiter Abtastwert), (rechter Kanal, zweiter Abtastwert), .... Für Mehr-Oktett-Kodierungen SOLLTEN Oktette in Netzwerk-Byte-Reihenfolge (d. h. höchstwertiges Oktett zuerst) übertragen werden.

Das Verpacken von abtastwertbasierten Kodierungen, die weniger als ein Oktett pro Abtastwert erzeugen, ist kodierungsspezifisch.

Der RTP-Zeitstempel spiegelt den Zeitpunkt wider, zu dem der erste Abtastwert im Paket abgetastet wurde, d. h. die älteste Information im Paket.

4.4 Richtlinien für rahmenbasierte Audiokodierungen

Rahmenbasierte Kodierungen kodieren einen Audioblock fester Länge in einen anderen Block komprimierter Daten, typischerweise ebenfalls fester Länge. Für rahmenbasierte Kodierungen KANN der Sender wählen, mehrere solcher Rahmen in einem einzigen RTP-Paket zu kombinieren. Der Empfänger kann die Anzahl der in einem RTP-Paket enthaltenen Rahmen feststellen, wenn alle Rahmen die gleiche Länge haben, indem er die RTP-Nutzlastlänge durch die Audio- Rahmengröße teilt, die als Teil der Kodierung definiert ist. Dies funktioniert nicht, wenn Rahmen unterschiedlicher Größe übertragen werden, es sei denn, die Rahmengrößen sind teilerfremd. Wenn nicht, MÜSSEN die Rahmen ihre Größe angeben.

Für rahmenbasierte Codecs ist die Kanalreihenfolge für den gesamten Block definiert. Das heißt, für Zweikanal-Audio SOLLTEN rechte und linke Abtastwerte unabhängig kodiert werden, wobei der kodierte Rahmen für den linken Kanal dem für den rechten Kanal vorausgeht.

Alle rahmenorientierten Audiocodecs SOLLTEN in der Lage sein, mehrere aufeinanderfolgende Rahmen innerhalb eines einzigen Pakets zu kodieren und zu dekodieren. Da die Rahmengröße für die rahmenorientierten Codecs gegeben ist, besteht keine Notwendigkeit, eine separate Bezeichnung für dieselbe Kodierung zu verwenden, jedoch mit einer unterschiedlichen Anzahl von Rahmen pro Paket.

RTP-Pakete MÜSSEN eine ganze Anzahl von Rahmen enthalten, wobei Rahmen entsprechend dem Alter innerhalb eines Pakets eingefügt werden, sodass der älteste Rahmen (der zuerst abgespielt werden soll) unmittelbar nach dem RTP-Paket-Header erscheint. Der RTP-Zeitstempel spiegelt den Zeitpunkt wider, zu dem der erste Abtastwert im ersten Rahmen abgetastet wurde, d. h. die älteste Information im Paket.

4.5 Audiokodierungen

Name der Abtast- Standard Kodierung Abtastwert/Rahmen Bits/Abtastwert rate ms/Rahmen ms/Paket

DVI4 Abtastwert 4 var. 20 G722 Abtastwert 8 16.000 20 G723 Rahmen N/A 8.000 30 30 G726-40 Abtastwert 5 8.000 20 G726-32 Abtastwert 4 8.000 20 G726-24 Abtastwert 3 8.000 20 G726-16 Abtastwert 2 8.000 20 G728 Rahmen N/A 8.000 2,5 20 G729 Rahmen N/A 8.000 10 20 G729D Rahmen N/A 8.000 10 20 G729E Rahmen N/A 8.000 10 20 GSM Rahmen N/A 8.000 20 20 GSM-EFR Rahmen N/A 8.000 20 20 L8 Abtastwert 8 var. 20 L16 Abtastwert 16 var. 20 LPC Rahmen N/A 8.000 20 20 MPA Rahmen N/A var. var. PCMA Abtastwert 8 var. 20 PCMU Abtastwert 8 var. 20 QCELP Rahmen N/A 8.000 20 20 VDVI Abtastwert var. var. 20

Tabelle 1: Eigenschaften von Audiokodierungen (N/A: nicht anwendbar; var.: variabel)

Die Eigenschaften der in diesem Dokument beschriebenen Audiokodierungen sind in Tabelle 1 dargestellt; sie sind in der Reihenfolge ihres Nutzlasttyps in Tabelle 4 aufgeführt. Während die meisten Audiocodecs nur für eine feste Abtastrate spezifiziert sind, können einige abtastwertbasierte Algorithmen (gekennzeichnet durch einen Eintrag "var." in der Abtastratenspalte von Tabelle 1) mit unterschiedlichen Abtastraten verwendet werden, was zu unterschiedlichen kodierten Bitraten führt. Bei Verwendung mit einer anderen Abtastrate als der, für die ein statischer Nutzlasttyp definiert ist, MÜSSEN Nicht-RTP-Mittel außerhalb des Geltungsbereichs dieses Memos verwendet werden, um einen dynamischen Nutzlasttyp zu definieren, und MÜSSEN die gewählte RTP-Zeitstempel-Taktrate angeben, die normalerweise dieselbe ist wie die Abtastrate für Audio.

4.5.1 DVI4

DVI4 verwendet ein Schema zur adaptiven Delta-Puls-Code-Modulation (ADPCM), das von der Interactive Multimedia Association (IMA) als "IMA ADPCM Wave Type" spezifiziert wurde. Die hier als DVI4 definierte Kodierung unterscheidet sich jedoch in drei Punkten von der IMA-Spezifikation:

o Der RTP-DVI4-Header enthält den vorhergesagten Wert anstelle des ersten Abtastwertes, der im IMA-ADPCM-Block-Header enthalten ist.

o IMA-ADPCM-Blöcke enthalten eine ungerade Anzahl von Abtastwerten, da der erste Abtastwert eines Blocks nur im Header (unkomprimiert) enthalten ist, gefolgt von einer geraden Anzahl komprimierter Abtastwerte. DVI4 hat nur eine gerade Anzahl komprimierter Abtastwerte und verwendet das `predict'-Wort aus dem Header, um den ersten Abtastwert zu dekodieren.

o Für DVI4 werden die 4-Bit-Abtastwerte so verpackt, dass der erste Abtastwert in den vier höchstwertigen Bits und der zweite Abtastwert in den vier niedrigstwertigen Bits liegt. Im IMA-ADPCM-Codec werden die Abtastwerte in umgekehrter Reihenfolge verpackt.

Jedes Paket enthält einen einzigen DVI-Block. Dieses Profil definiert nur die Version mit 4 Bit pro Abtastwert, während IMA auch eine Kodierung mit 3 Bit pro Abtastwert spezifizierte.

Das "Header"-Wort für jeden Kanal hat folgende Struktur:

  int16  predict;  /* vorhergesagter Wert des ersten Abtastwertes
                      aus dem vorherigen Block (L16-Format) */
  u_int8 index;    /* aktueller Index in der Schrittweitentabelle */
  u_int8 reserved; /* vom Sender auf null gesetzt, vom Empfänger ignoriert */

Jedes dem Header folgende Oktett enthält zwei 4-Bit-Abtastwerte, daher MUSS die Anzahl der Abtastwerte pro Paket gerade sein, da es keine Möglichkeit gibt, ein teilweise gefülltes letztes Oktett anzuzeigen.

Das Verpacken von Abtastwerten für mehrere Kanäle ist Gegenstand weiterer Untersuchungen.

Der IMA-ADPCM-Algorithmus wurde im Dokument IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (Version 3.0) beschrieben. Die Interactive Multimedia Association stellte jedoch 1997 den Betrieb ein. Ressourcen für eine archivierte Kopie dieses Dokuments und eine Softwareimplementierung der RTP-DVI4- Kodierung sind in Abschnitt 13 aufgeführt.

4.5.2 G722

G722 ist in der ITU-T-Empfehlung G.722, "7 kHz Audio-Codierung innerhalb von 64 kbit/s", spezifiziert. Der G.722-Encoder erzeugt einen Strom von Oktetten, von denen jedes in einem RTP-Paket oktguttausgerichtet sein MUSS. Das erste im G.722-Oktett übertragene Bit, das das höchstwertige Bit des oberen Teilband-Abtastwertes ist, MUSS dem höchstwertigen Bit des Oktetts im RTP-Paket entsprechen.

Obwohl die tatsächliche Abtastrate für G.722-Audio 16.000 Hz beträgt, beträgt die RTP-Taktrate für das G722-Nutzlastformat 8.000 Hz, da dieser Wert fälschlicherweise in RFC 1890 zugewiesen wurde und aus Gründen der Abwärtskompatibilität unverändert bleiben muss. Die Oktettrate oder Abtastwertpaar- Rate beträgt 8.000 Hz.

4.5.3 G723

G723 ist in der ITU-Empfehlung G.723.1, "Dual-rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s" (Dualraten-Sprachkodierer für Multimedia-Kommunikation mit 5,3 und 6,3 kbit/s) spezifiziert. Der G.723.1 5,3/6,3 kbit/s-Codec wurde von der ITU-T als obligatorischer Codec für ITU-T H.324 GSTN-Bildtelefon-Endgeräteanwendungen definiert. Der Algorithmus verfügt über eine Gleitkommaspezifikation in Anhang B zu G.723.1, einen Stille-Kompressionsalgorithmus in Anhang A zu G.723.1 und ein skalierbares Kanalcodierungsschema für drahtlose Anwendungen in G.723.1 Anhang C.

Diese Empfehlung spezifiziert eine kodierte Darstellung, die verwendet werden kann, um die Sprachsignalkomponente von Multimedia-Diensten bei einer sehr niedrigen Bitrate zu komprimieren. Audio wird in 30-ms-Rahmen kodiert, mit einer zusätzlichen Verzögerung von 7,5 ms aufgrund von Look-Ahead. Ein G.723.1-Rahmen kann eine von drei Größen haben: 24 Oktette (6,3 kb/s-Rahmen), 20 Oktette (5,3 kb/s- Rahmen) oder 4 Oktette. Diese 4-Oktett-Rahmen werden SID-Rahmen (Stille-Einfügungs-Deskriptor) genannt und dienen zur Spezifizierung von Komfortrauschen- Parametern. Es gibt keine Einschränkung, wie 4-, 20- und 24-Oktett- Rahmen gemischt werden. Die zwei niedrigstwertigen Bits des ersten Oktetts im Rahmen bestimmen die Rahmengröße und den Codec-Typ:

     Bits  Inhalt                       Oktette/Rahmen
  Hochraten-Sprache (6,3 kb/s)           24
  Niedrigraten-Sprache (5,3 kb/s)        20
  SID-Rahmen                             4
  reserviert

Es ist möglich, an jeder 30-ms-Rahmengrenze zwischen den beiden Raten zu wechseln. Beide Raten (5,3 kb/s und 6,3 kb/s) sind ein obligatorischer Teil des Encoders und Decoders. Empfänger MÜSSEN beide Datenraten akzeptieren und MÜSSEN SID-Rahmen akzeptieren, es sei denn, eine Einschränkung dieser Fähigkeiten wurde signalisiert. Die MIME-Registrierung für G723 in RFC 3555 [7] spezifiziert Parameter, die mit MIME oder SDP verwendet werden KÖNNEN, um auf eine einzelne Datenrate zu beschränken oder die Verwendung von SID-Rahmen einzuschränken. Dieser Codierer wurde optimiert, um Sprache mit nahezu gebührenpflichtiger Qualität bei den oben genannten Raten unter Verwendung einer begrenzten Menge an Komplexität darzustellen.

Das Verpacken des kodierten Bitstroms in Oktette und die Übertragungsreihenfolge der Oktette ist in Rec. G.723.1 spezifiziert und ist die gleiche wie die, die von der G.723-C-Code-Referenzimplementierung erzeugt wird. Für die Datenrate von 6,3 kb/s ist dieses Verpacken wie folgt dargestellt, wobei die Header (HDR)-Bits immer "0 0" sind, wie in Abb. 1 gezeigt, um den Betrieb bei 6,3 kb/s anzuzeigen, und das Z-Bit immer auf null gesetzt ist. Die Diagramme zeigen das Bitverpacken in "Netzwerk- Byte-Reihenfolge", auch bekannt als Big-Endian-Reihenfolge. Die Bits jedes 32-Bit- Wortes sind von 0 bis 31 nummeriert, wobei das höchstwertige Bit links ist und mit 0 nummeriert ist. Die Oktette (Bytes) jedes Wortes werden mit dem höchstwertigen Oktett zuerst übertragen. Die Bits jedes Datenfelds sind in der Reihenfolge der Bitstromdarstellung der Kodierung (niedrigstwertiges Bit zuerst) nummeriert. Die vertikalen Striche zeigen die Grenzen zwischen Feldfragmenten an.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSBPOS |Z|POS| MSBPOS | POS0 |POS| POS0 | | | | 0 | | | 1 | | |0 0 0 0 0 0 0|0|0 0|1 1 1 0 0 0|0 0 0 0 0 0 0 0|0 0|1 1 1 1 1 1| |6 5 4 3 2 1 0| |1 0|2 1 0 9 8 7|9 8 7 6 5 4 3 2|1 0|5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS1 | POS2 | POS1 | POS2 | POS3 | POS2 | | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 1 1|1 1 0 0 0 0 0 0|0 0 0 0|1 1 1 1| |9 8 7 6 5 4 3 2|3 2 1 0|3 2 1 0|1 0 9 8 7 6 5 4|3 2 1 0|5 4 3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | PSIG0 |POS|PSIG2| PSIG1 | PSIG3 |PSIG2| | | | 3 | | | | | |1 1 0 0 0 0 0 0|0 0 0 0 0 0|1 1|0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0| |1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2|2 1 0|4 3 2 1 0|4 3 2 1 0|5 4 3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Abbildung 1: G.723 (6,3 kb/s) Bitverpackung

Für die Datenrate von 5,3 kb/s sind die Header (HDR)-Bits immer "0 1", wie in Abb. 2 gezeigt, um den Betrieb bei 5,3 kb/s anzuzeigen.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | ACL0 |LPC| | | | | | | | |0 0 0 0 0 0|0 1|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACL2 |ACL|A| GAIN0 |ACL|ACL| GAIN0 | GAIN1 | | | 1 |C| | 3 | 2 | | | |0 0 0 0 0|0 0|0|0 0 0 0|0 0|0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |4 3 2 1 0|1 0|6|3 2 1 0|1 0|6 5|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAIN2 | GAIN1 | GAIN2 | GAIN3 | GRID | GAIN3 | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0|4 3 2 1|1 0 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS0 | POS1 | POS0 | POS1 | POS2 | | | | | | | |0 0 0 0 0 0 0 0|0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |7 6 5 4 3 2 1 0|3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS3 | POS2 | POS3 | PSIG1 | PSIG0 | PSIG3 | PSIG2 | | | | | | | | | |0 0 0 0|1 1 0 0|1 1 0 0 0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0|0 0 0 0| |3 2 1 0|1 0 9 8|1 0 9 8 7 6 5 4|3 2 1 0|3 2 1 0|3 2 1 0|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Abbildung 2: G.723 (5,3 kb/s) Bitverpackung

Das Verpacken von G.723.1-SID (Stille)-Rahmen, die durch die Header (HDR)-Bits mit dem Muster "1 0" angezeigt werden, ist in Abb. 3 dargestellt.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LPC |HDR| LPC | LPC | GAIN |LPC| | | | | | | | |0 0 0 0 0 0|1 0|1 1 1 1 0 0 0 0|2 2 1 1 1 1 1 1|0 0 0 0 0 0|2 2| |5 4 3 2 1 0| |3 2 1 0 9 8 7 6|1 0 9 8 7 6 5 4|5 4 3 2 1 0|3 2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Abbildung 3: G.723 SID-Modus Bitverpackung

4.5.4 G726-40, G726-32, G726-24, und G726-16

Die ITU-T-Empfehlung G.726 beschreibt unter anderem den Algorithmus, der für die Umwandlung eines einzelnen 64 kbit/s A-Law- oder Mu-Law-PCM- Kanals, der mit 8.000 Abtastwerten/s kodiert ist, zu und von einem 40, 32, 24 oder 16 kbit/s-Kanal empfohlen wird. Die Umwandlung wird auf den PCM-Strom unter Verwendung einer Transcodierungstechnik mit adaptiver differentieller Puls-Code-Modulation (ADPCM) angewendet. Die ADPCM-Darstellung besteht aus einer Reihe von Codewörtern mit einer Eins-zu-eins-Entsprechung zu den Abtastwerten im PCM- Strom. Die G726-Datenraten von 40, 32, 24 und 16 kbit/s haben Codewörter von 5, 4, 3 bzw. 2 Bits.

Die Kodierungen mit 16 und 24 kbit/s bieten keine gebührenpflichtige Sprachqualität. Sie sind für den Einsatz in überlasteten digitalen Schaltungs- Multiplikationsgeräten (DCME) konzipiert. ITU-T G.726 empfiehlt, dass die 16 und 24 kbit/s-Kodierungen mit Kodierungen höherer Datenrate abgewechselt werden sollten, um eine durchschnittliche Abtastgröße zwischen 3,5 und 3,7 Bits pro Abtastwert bereitzustellen.

Die Kodierungen von G.726 werden hier als G726-40, G726-32, G726-24 und G726-16 bezeichnet. Vor 1990 beschrieb G721 die 32 kbit/s-ADPCM- Kodierung und G723 beschrieb die 40, 32 und 16 kbit/s-Kodierungen. Somit bezeichnet G726-32 denselben Algorithmus wie G721 in RFC 1890.

Ein Strom von G726-Codewörtern enthält keine Informationen über die verwendete Kodierung, daher sind Übergänge zwischen G726-Kodierungstypen innerhalb einer Sequenz von verpackten Codewörtern nicht zulässig. Anwendungen MÜSSEN den Kodierungstyp der verpackten Codewörter aus dem RTP-Nutzlast- Identifikator bestimmen.

Es DÜRFEN KEINE nutzlastspezifischen Header-Informationen als Teil der Audiodaten enthalten sein. Ein Strom von G726-Codewörtern MUSS wie folgt in Oktette verpackt werden: Das erste Codewort wird so in das erste Oktett platziert, dass das niedrigstwertige Bit des Codewortes mit dem niedrigstwertigen Bit im Oktett übereinstimmt, das zweite Codewort wird dann so verpackt, dass sein niedrigstwertiges Bit mit dem niedrigstwertigen unbesetzten Bit im Oktett zusammenfällt. Wenn ein vollständiges Codewort nicht in einem Oktett platziert werden kann, werden die Bits, die die Oktett- grenze überlappen, in die niedrigstwertigen Bits des nächsten Oktetts platziert. Das Verpacken MUSS mit einem vollständig verpackten letzten Oktett enden. Die Anzahl der verpackten Codewörter ist daher ein Vielfaches von 8, 2, 8 und 4 für G726-40, G726-32, G726-24 bzw. G726-16. Ein Beispiel für das Verpackungsschema für G726-32-Codewörter ist wie gezeigt, wobei Bit 7 das niedrigstwertige Bit des ersten Oktetts ist und Bit A3 das niedrigstwertige Bit des ersten Codewortes ist:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |B B B B|A A A A|D D D D|C C C C| ...
     |0 1 2 3|0 1 2 3|0 1 2 3|0 1 2 3|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Ein Beispiel für das Verpackungsschema für G726-24-Codewörter folgt, wobei wiederum Bit 7 das niedrigstwertige Bit des ersten Oktetts ist und Bit A2 das niedrigstwertige Bit des ersten Codewortes ist:

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |C C|B B B|A A A|F|E E E|D D D|C|H H H|G G G|F F| ...
     |1 2|0 1 2|0 1 2|2|0 1 2|0 1 2|0|0 1 2|0 1 2|0 1|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Beachten Sie, dass die "Little-Endian"-Richtung, in der Abtastwerte in Oktette in den hier spezifizierten G726-16, -24, -32 und -40 Nutzlastformaten verpackt werden, mit der ITU-T-Empfehlung X.420 übereinstimmt, aber das Gegenteil dessen ist, was in der ITU-T-Empfehlung I.366.2 Anhang E für den ATM AAL2-Transport spezifiziert ist. Ein zweiter Satz von RTP-Nutzlastformaten, der der Paketierung von I.366.2 Anhang E entspricht und durch die MIME- Subtypen AAL2-G726-16, -24, -32 und -40 identifiziert wird, wird in einem separaten Dokument spezifiziert.

4.5.5 G728

G728 ist in der ITU-T-Empfehlung G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction" (Sprachkodierung bei 16 kbit/s unter Verwendung von Code-angeregter linearer Vorhersage mit geringer Verzögerung) spezifiziert.

Ein G.278-Encoder übersetzt 5 aufeinanderfolgende Audioabtastwerte in einen 10-Bit- Codebuchindex, was zu einer Bitrate von 16 kb/s für Audio führt, das mit 8.000 Abtastwerten pro Sekunde abgetastet wird. Die Gruppe von fünf aufeinanderfolgenden Abtastwerten wird Vektor genannt. Vier aufeinanderfolgende Vektoren, bezeichnet als V1 bis V4 (wobei V1 zuerst vom Empfänger abgespielt werden soll), bilden einen G.728- Rahmen. Die vier Vektoren zu je 40 Bit werden in 5 Oktette verpackt, bezeichnet als B1 bis B5. B1 MUSS als erstes im RTP-Paket platziert werden.

Bezugnehmend auf die Abbildung unten ist das Prinzip für die Bitreihenfolge "Erhaltung der Bitsignifikanz". Bits von einem älteren Vektor sind signifikanter als Bits von neueren Vektoren. Das MSB des Rahmens geht an das MSB von B1 und das LSB des Rahmens geht an das LSB von B5.

               1         2         3        3
     0         0         0         0        9
     ++++++++++++++++++++++++++++++++++++++++
     <---V1---><---V2---><---V3---><---V4---> Vektoren
     <--B1--><--B2--><--B3--><--B4--><--B5--> Oktette
     <------------- Rahmen 1 --------------->

Insbesondere enthält B1 die acht höchstwertigen Bits von V1, wobei das MSB von V1 das MSB von B1 ist. B2 enthält die zwei niedrigst- wertigen Bits von V1, das höherwertige der beiden in seinem MSB, und die sechs höchstwertigen Bits von V2. B1 MUSS als erstes im RTP-Paket und B5 als letztes platziert werden.

4.5.6 G729

G729 ist in der ITU-T-Empfehlung G.729, "Coding of speech at 8 kbit/s using conjugate structure algebraic-code-excited linear- prediction (CS-ACELP)" (Sprachkodierung bei 8 kbit/s unter Verwendung von linearer Vorhersage mit algebraischer Code-Anregung und konjugierter Struktur) spezifiziert. Dieser Codec wurde optimiert, um Sprache mit hoher Qualität darzustellen, wobei G.728 eine geringe Verzögerung und G.723.1 eine niedrige Bitrate aufweist. Der G.729-Encoder arbeitet mit Sprachrahmen von 10 ms, was 80 Abtastwerten bei einer Abtastrate von 8000 Abtastwerten pro Sekunde entspricht. Der erzeugte Bitstrom hat eine Bitrate von 8 kbit/s. Daher enthält jeder Rahmen 80 Bits.

Das Verpacken des kodierten Bitstroms in Oktette und die Übertragungsreihenfolge der Oktette ist in Rec. G.729 spezifiziert und ist die gleiche wie die, die von der G.729-C-Code-Referenzimplementierung erzeugt wird. Die Bits jedes 80-Bit-Rahmens sind von 1 bis 80 nummeriert, wobei das höchstwertige Bit links ist und mit 1 nummeriert ist. Die Oktette (Bytes) jedes Wortes werden mit dem höchstwertigen Oktett zuerst übertragen. Die Bits jedes Datenfelds sind in der Reihenfolge der Bit- stromdarstellung der Kodierung (niedrigstwertiges Bit zuerst) nummeriert. Die vertikalen Striche zeigen die Grenzen zwischen Feldfragmenten an.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | P1 | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P1 | P2 | C1 | S1 | C2 | S2 | P1 | | | | | | | | | |0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0 0 0 0| |9 8|4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0|7 6 5 4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 | C3 | S3 | C4 | S4 | | | | | | | |0 0 0|0 0 0 0 0|0 0 0|0 0 0 0 0|0 0 0| |4 3 2 1 0|c c c c c|3 2 1 0|c c c c c|3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Anhang A zu G.729 spezifiziert eine Version des G.729-Algorithmus mit reduzierter Komplexität. Der Anhang-A-Codierer erzeugt einen Bitstrom, der mit dem des G.729-Codierers identisch ist.

Anhang B zu G.729 definiert einen Stille-Kompressionsalgorithmus, der mit G.729 oder G.729 Anhang A verwendet wird. Bei Erkennung einer Stilleperiode überträgt der Encoder einen 2-Oktett-SID-Rahmen (Stille-Einfügungs-Deskriptor), der Komfortrauschen-Parameter spezifiziert. Es gibt keine Einschränkung, wie 10- und 2-Oktett-Rahmen gemischt werden. Der SID-Rahmen besteht teilweise aus Summen-Codebuchindizes und teilweise aus Parametern des Stille- Kompressionsalgorithmus. Die Felder des SID-Rahmens sind im Diagramm unten dargestellt.

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L0 | L1 | L2 | L3 | GAIN | | | | | | | |0|0 0 0 0 0 0 0|0 0 0 0 0|0 0 0 0 0|0 0 0 0 0| | |6 5 4 3 2 1 0|4 3 2 1 0|4 3 2 1 0|4 3 2 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Für G.729 Anhang B umfasst die kanalcodierte VAD/DTX-Erzeugung die Übertragung von Rahmen mit 1/16 Rate (800 bps), die nur 10 Bits lang sind (1,25 Oktette). Da diese nicht in eine ganze Zahl von Oktetten passen, bleibt das Verpacken dieser Rahmen für zukünftige Studien. Empfänger, die unter diesem Nutzlastformat arbeiten, MÜSSEN die 80-Bit- Sprachrahmen und die 16-Bit-SID-Rahmen akzeptieren. Der Empfänger KANN 10-Bit-Rahmen, falls vorhanden, verwerfen.

4.5.7 G729D und G729E

Anhang D zu G.729 definiert eine Erweiterung des Algorithmus mit niedrigerer Bitrate (6,4 kb/s). Der G.729-Anhang-D-Codierer erzeugt einen 64-Bit-Rahmen.

Anhang E zu G.729 definiert eine Erweiterung des Algorithmus mit höherer Bitrate (11,8 kb/s). Der G.729-Anhang-E-Codierer erzeugt einen 118-Bit-Rahmen.

Das Verpacken des kodierten Bitstroms in Oktette und die Übertragungsreihenfolge der Oktette ist in Rec. G.729 spezifiziert und ist die gleiche wie die, die von der G.729-C-Code-Referenzimplementierung erzeugt wird. Die Bits jedes 64-Bit- oder 118-Bit-Rahmens sind von 1 bis n nummeriert, wobei das höchstwertige Bit links ist und mit 1 nummeriert ist. Die Oktette (Bytes) jedes Wortes werden mit dem höchstwertigen Oktett zuerst übertragen. Die Bits jedes Datenfelds sind in der Reihenfolge der Bitstromdarstellung der Kodierung (niedrigstwertiges Bit zuerst) nummeriert.

ITU-T Rec. G.729 Anhänge D und E spezifizieren derzeit nicht, wie Sprach- aktivitätserkennung (VAD) und diskontinuierliche Übertragung (DTX) gehandhabt werden sollen. Daher SOLLTEN sie NICHT mit diesem Nutzlastformat verwendet werden.

4.5.8 GSM

GSM (Group Speciale Mobile) bezeichnet die europäische GSM 06.10-Norm für Vollraten-Sprachtranscodierung, ETS 300 961, die auf RPE/ LTP-Kodierung (Resident Pulse Excitation/Long Term Prediction) mit einer Rate von 13 kb/s basiert [11,12,13]. Der Text der Norm kann auf der Website des ETSI (Europäisches Institut für Telekommunikationsnormen) unter http://www.etsi.org abgerufen werden.

4.5.8.1 Allgemeine Verpackungsprobleme

Der GSM-Standard spezifiziert den vom Codec erzeugten Bitstrom, aber nicht, wie diese Bits für die Übertragung verpackt werden sollen. Im Gegensatz zu den Nutzlastformaten für die anderen in diesem Dokument spezifizierten Audiokodierungen verpackt das GSM-Nutzlastformat die Bytes anders als die Standarddarstellung, die von der GSM 06.10 C-Referenzimplementierung verwendet wird.

Die Standard-GSM-06.10-Implementierung verpackt die 260 Bits eines GSM-Rahmens in 33 Oktette (16 Wörter in 16-Bit-Systemen), wobei die Bits die niedrigstwertigen Bits jedes Bytes/Wortes belegen. Um diese in RTP zu übertragen, werden die 260 Bits in 33 Oktette verpackt, wie in ETSI TS 101 318 [4] definiert. Letzteres ist effektiv Standard für VoIP/VoFR/VoATM und entspricht dem "Toast"-Format, das von der in Abschnitt 13 zitierten GSM-Implementierung verwendet wird.

Im RTP-Nutzlastformat wird ein Rahmen in 33 Oktette (264 Bits) verpackt, indem die 4 freien Bits des letzten Oktetts mit Nullen aufgefüllt werden. Zwei Rahmen werden in 66 Oktette verpackt. Die Feldzuordnung ist in Tabelle 2 dargestellt.

4.5.8.2 GSM-Variablennamen und -Nummern

Die Parameter des GSM-Audiocodecs werden gemäß dem GSM 06.10-Standard wie folgt benannt.

                         Tabelle 2: GSM-Nutzlastformat

Feld Feldname Bits Oktett Bit

1 LARc[0] 6 1 0--5 2 LARc[1] 6 1, 2 6--7, 0--3 3 LARc[2] 5 2, 3 4--7, 0 4 LARc[3] 5 3 1--5 5 LARc[4] 4 3, 4 6--7, 0--1 6 LARc[5] 4 4 2--5 7 LARc[6] 3 4, 5 6--7, 0 8 LARc[7] 3 5 1--3 9 Nc[0] 7 5, 6 4--7, 0--2 10 bc[0] 2 6 3--4 11 Mc[0] 2 6 5--6 12 xmaxc[0] 6 6, 7 7, 0--4 13 xmc[0] 3 7 5--7 14 Nc[1] 7 8 0--6 15 bc[1] 2 8, 9 7, 0 16 Mc[1] 2 9 1--2 17 xmaxc[1] 6 9, 10 3--7, 0 18 xmc[1] 3 10 1--3 19 Nc[2] 7 10, 11 4--7, 0--2 20 bc[2] 2 11 3--4 21 Mc[2] 2 11 5--6 22 xmaxc[2] 6 11, 12 7, 0--4 23 xmc[2] 3 12 5--7 24 Nc[3] 7 13 0--6 25 bc[3] 2 13, 14 7, 0 26 Mc[3] 2 14 1--2 27 xmaxc[3] 6 14, 15 3--7, 0 28 xmc[3] 3 15 1--3

4.5.9 GSM-EFR

GSM-EFR ist in ETS 300 726 (GSM 06.60) spezifiziert. Dies ist ein verbesserter Vollraten-Sprachcodec (Enhanced Full Rate) mit der gleichen Taktrate (8000 Hz) und Bitrate (12,2 kb/s) wie der GSM-Codec.

4.5.10 L8

L8 bezeichnet lineare Audiodatenabtastwerte unter Verwendung von 8-Bit-Präzision mit einem Offset von 128, d. h. das negativste Signal wird durch den Wert 0 dargestellt, das Nullsignal durch den Wert 128 und das positivste Signal durch den Wert 255.

4.5.11 L16

L16 bezeichnet (16-Bit) vorzeichenbehaftete lineare Audiodatenabtastwerte. Lineare L16- Audioabtastwerte SOLLTEN in Netzwerk-Byte-Reihenfolge (höchstwertiges Oktett zuerst) übertragen werden.

4.5.12 LPC

LPC bezeichnet eine experimentelle lineare prädiktive Kodierung, die von Ron Frederick am Xerox PARC beigesteuert wurde und auf einer Implementierung basiert, die ursprünglich von Steve Casner am ISI geschrieben wurde. Der Quellcode für den Encoder und Decoder ist wie in Abschnitt 13 aufgeführt verfügbar.

4.5.13 MPA

MPA bezeichnet die Verwendung von MPEG-1- oder MPEG-2-Audio-Elementarströmen. Das RTP-Nutzlastformat ist wie in RFC 2250 [14], Abschnitt 3 spezifiziert.

4.5.14 PCMA und PCMU

PCMA und PCMU sind in der ITU-T-Empfehlung G.711 spezifiziert. Audio- daten werden nach logarithmischer Skalierung als acht Bits pro Abtastwert kodiert. PCMU bezeichnet Mu-Law-Skalierung, PCMA A-Law-Skalierung. Eine detaillierte Beschreibung wird von Jayant und Noll [15] gegeben. Jedes G.711-Oktett MUSS in einem RTP-Paket oktguttausgerichtet sein. Das Vorzeichenbit jedes G.711-Oktetts MUSS dem höchstwertigen Bit des Oktetts im RTP- Paket entsprechen (d. h. unter der Annahme, dass die G.711-Abtastwerte als Oktette auf der Hostmaschine behandelt werden, soll das Vorzeichenbit das höchstwertige Bit des Oktetts sein, wie durch das Hostmaschinenformat definiert). Die Modi 56 kb/s und 48 kb/s von G.711 sind für RTP nicht anwendbar, da PCMA und PCMU IMMER als 8-Bit-Abtastwerte übertragen werden MÜSSEN.

4.5.15 QCELP

Der Qualcomm Code Excited Linear Prediction (QCELP) Audiocodec ist in TIA/EIA IS-733, "TR45: High Rate Speech Service Option 17 for Wideband Spread Spectrum Communication Systems" spezifiziert.

Der QCELP-Codec wird für den TIA/EIA IS-95 CDMA-Mobilfunk- systemstandard verwendet. Der QCELP-Codec skaliert auf verschiedene Datenraten, die auf einer Rahmen-für-Rahmen-Basis ausgewählt werden können. Die maximale Datenrate beträgt 13 kbit/s. Dieses Nutzlastformat definiert keinen separaten stillen Rahmentyp, aber die Datenrate kann in stillen Perioden auf ca. 1 kbit/s reduziert werden.

Das RTP-Nutzlastformat ist in [16] spezifiziert.

4.5.16 RED

Das redundante Audio-Nutzlastformat "RED" ist in RFC 2198 [17] spezifiziert. Es definiert ein Mittel, mit dem mehrere redundante Kopien eines Audiopakets in einem einzigen RTP-Strom übertragen werden können.

4.5.17 VDVI

VDVI ist eine Version von DVI4 mit variabler Rate, die für die dynamische Zuweisung verfügbar ist. DVI4-Abtastwerte werden in Oktette verpackt, aber die Anzahl der Bits pro Abtastwert kann von Paket zu Paket variieren und wird im Paket-Header angegeben. Für VDVI ist das Nutzlasttyp-Feld des RTP- Headers ein dynamischer Typ, der auf "VDVI" abgebildet wird.

Jedes Paket enthält einen einzigen DVI-Block. Das "Header"-Wort für jeden Kanal hat folgende Struktur:

  int16  predict;  /* vorhergesagter Wert des ersten Abtastwertes
                      aus dem vorherigen Block (L16-Format) */
  u_int8 index;    /* aktueller Index in der Schrittweitentabelle */
  u_int8 sample_size; /* Anzahl der Bits pro Abtastwert */

Sample-size MUSS einer der Werte 3, 4 oder 5 sein. Wenn sample_size gleich 4 ist, ist das Verpacken der Abtastwerte das gleiche wie für DVI4. Wenn sample_size gleich 3 oder 5 ist, werden die Abtastwerte in die nächsten verfügbaren Bits des aktuellen Oktetts des Paketfensters gepackt, beginnend mit dem MSB. Wenn ein Abtastwert eine Oktettgrenze überspannt, werden die Bits in die LSBs des ersten Oktetts und die MSBs des zweiten Oktetts platziert. Der nächste Abtastwert wird dann beginnend beim ersten verfügbaren MSB des zweiten Oktetts verpackt. Der Prozess setzt sich für das gesamte Paket fort.