G.726

G.726 ist ein ADPCM-basierter Schmalband-Codec (50 bis 4000 Hz) der Internationalen Fernmeldeunion (ITU-T) zur Komprimierung von Sprache in digitale Telefonsignale. Der auf derselben Technologie basierende Breitbandcodec ist G.722.

Geschichte

Der Standard wurde 1990 verabschiedet und fasst den älteren G.721 von 1984 (32 kbit/s) und den G.723 von 1988 (24 und 40 kbit/s, nicht zu verwechseln mit dem CELP-basierten G.723.1) als deren Nachfolgestandard zusammen.

kbit/s	Bits/ Sample 50 bis 4000 Hz	Bits/ Sample 4000 bis 7000 Hz	G.721 (1984) obsolet	G.722 (1988) aktuell	G.723 (1988) obsolet	G.726 (1990) aktuell
64	6	2	−	+	−	−
56	5	2	−	+	−	−
48	4	2	−	+	−	−
40	5	0	−	−	+	+
32	4	0	+	−	−	+
24	3	0	−	−	+	+
16	2	0	−	−	−	+

Technische Daten

Das Verfahren basiert auf Adaptive Differential Pulse Code Modulation (ADPCM).

Der Codec unterstützt Bitraten von 16, 24, 32 und 40 kbit/s.

G.726 erreicht einen Mean Opinion Score (MOS) von etwa 4,2 für die 40-kbit/s-Variante und etwa 3,85 bei der 32-kbit/s-Variante.

Verwendung

G.726 wird unter anderem auch bei IP-Telefonie eingesetzt.

Bei DECT-Telefonen wird für Schmalbandtelefonie die 32-kbit/s-Variante genutzt. Der DECT-Standard ist speziell auf G.726-32 abgestimmt, daher kann ein DECT-Funkkanal genau 32 kbit/s übertragen. Die Entscheidung für G.726 fiel auch deshalb, weil ADPCM relativ unempfindlich auf Bitfehler ist, was insbesondere für Funkanwendungen von Interesse ist. Die 32-kbit/s-Variante hat darüber hinaus den Vorteil, dass zwei zusammengeschaltete Kanäle 64 kbit/s ergeben, was es ermöglicht, mit zwei Kanälen genau einen G.722-Datenstrom (64 kbit/s) zu übertragen und so HD-Telefonie ebenfalls mit ADPCM über DECT zu realisieren.

Andere Verwendung findet der Codec bei internationalen Telefonnetzverbindungen der Festnetz- und Mobilfunknetzinfrastruktur. Das dabei verwendete Multiplexverfahren ist in der Regel DCME (Digital Circuit Multiplication Equipment) entsprechend G.763 implementiert und verwendet je nach Auslastung des internationalen Sprachverkehrs die G.726-Codecs mit 16, 24, 32 und 40 kbit/s. Diese Komprimierungen sind international auch in einigen Anschlussnetzen für die Anbindung von Nebenstellenanlagen in Gebrauch.

Datenaufkommen und Verzögerungszeiten

Beispielsweise entsteht für die Sprach-Komprimierung auf 32 kbit/s in einer Minute ein Datenaufkommen von 240 kB; ein einstündiges VoIP-Telefonat ergibt somit 14,4 MB an Sprachdaten. Nicht mitgerechnet sind hier die Protokolldaten zur Kommunikation in IP-Netzen, die abhängig von der Anzahl der Datenpaketrate und des Protokolls bis zu 50 % an zusätzlicher Bandbreite benötigen. In leitungsvermittelten Netzen sind die Protokolldaten Teil eines gesonderten Signalisierungskanals.

Verzögerungszeiten in IP-Netzen sind abhängig von der Übertragungszeit (Übertragungsdelay), der notwendigen Pufferung bei Jitter (Jitterbuffering), der Anzahl zwischengeschalteter Knoten und deren Übertragungsraten (transmission delay, sofern es sich nicht um Cut-Through-Switches handelt) sowie dem Encoding und Decoding (packetization time) der Sprache mittels des hier verwendeten G.726-Codec mit entsprechender Paketrate. In leitungsvermittelten Netzen entsteht nur eine Verzögerung durch Übertragungszeit, Encoding und Decoding.

Problematik der Endianness und Payload Type bei RTP

Endianness

Endianness bezeichnet in der Informatik und Telematik die Byte-Reihenfolge von Datenströmen. Konkret geht es darum, ob ein Zahlenwert beginnend mit der höchsten oder der niedrigsten Stelle notiert bzw. über ein Netzwerk übertragen wird:

Fünfhunderteinundzwanzig
Little endian:	125
Big Endian:	521

Wird nun ein mit G.726 komprimiertes Audiosignal in der „falschen“ Bitreihenfolge dekomprimiert, klingt Sprache stark verzerrt und ist nur schwer oder gar nicht verständlich.

Veraltete RFC 1890 (1996)

Im Kontext des Internets ist Big Endian die typische Byte-Reihenfolge. Big Endian wird hier deshalb einfach als Network Byte Order bezeichnet. Die veraltete RFC 1890 von 1996 mit dem Titel „RTP Profile for Audio and Video Conferences with Minimal Control“<ref name="RFC1890" /> definiert sogenannte Payload Typen für das Übertragungsprotokoll RTP und bekräftigt Big Endian als die Standard-Byte-Reihenfolge für alle Codecs:

– RFC 1890<ref>Vorlage:RFC-Internet</ref>

Der Payload Type für G.721 in der historischen RFC 1890<ref name="RFC1890" /> war 2, also a=rtpmap:2 G721/8000. Dieser wurde später in Entwürfen für die Nachfolger-RFC als a=rtpmap:2 G726-32/8000 weiterverwendet.

Empfehlungen der ITU-T

Die ITU-T hat in ihren Empfehlungen zu ADPCM in Netzwerken die Byte-Reihenfolge explizit festgelegt, allerdings auf zwei sich widersprechende Arten: In der Empfehlung X.420 wurde Little Endian festgeschrieben, in der Empfehlung I.366.2 Annex E jedoch Big Endian. Dies hat dazu geführt, dass sich einige Hersteller in ihren Implementierungen für Little Endian entschieden haben, andere dagegen für Big Endian.

I.366.2 Annex E

– ITU-T<ref>ITU-T I.366.2 (11/2000), Annex E</ref>

<syntaxhighlight lang="c">

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

┌─────────┬─────┐ ┌───────┬───────┐ ┌─────┬─────┬───┐ ┌───┬───┬───┬───┐ │A A A A A│B B B│ │A A A A│B B B B│ │A A A│B B B│C C│ │A A│B B│C C│D D│ │% 8 4 2 1│% 8 4│ 1 │8 4 2 1│8 4 2 1│ 1 │4 2 1│4 2 1│4 2│ 1 │2 1│2 1│2 1│2 1│ 1 ├───┬─────┴───┬─┤ ├───────┼───────┤ ├─┬───┴─┬───┴─┬─┤ ├───┼───┼───┼───┤ │B B│C C C C C│D│ │C C C C│D D D D│ │C│D D D│E E E│F│ │E E│F F│G G│H H│ │2 1│% 8 4 2 1│%│ 2 │8 4 2 1│8 4 2 1│ 2 │1│4 2 1│4 2 1│4│ 2 │2 1│2 1│2 1│2 1│ 2 ├───┴───┬─────┴─┤ ├───────┼───────┤ ├─┴─┬───┴─┬───┴─┤ └───┴───┴───┴───┘ │D D D D│E E E E│ │E E E E│F F F F│ │F F│G G G│H H H│ AAL2-G726-16 │8 4 2 1│% 8 4 2│ 3 │8 4 2 1│8 4 2 1│ 3 │2 1│4 2 1│4 2 1│ 3 ├─┬─────┴───┬───┤ ├───────┼───────┤ └───┴─────┴─────┘ │E│F F F F F│G G│ │G G G G│H H H H│ AAL2-G726-24 │1│% 8 4 2 1│% 8│ 4 │8 4 2 1│8 4 2 1│ 4 ├─┴───┬─────┴───┤ └───────┴───────┘ │G G G│H H H H H│ AAL2-G726-32 │4 2 1│% 8 4 2 1│ 5 └─────┴─────────┘

    AAL2-G726-40   [„%“ steht für 16, das Bit mit dem höchsten Wert]

┌───────────────┬───────────────┬───────────────┬───────────────┬───────────────┐ │1 2 3 4 5 6 7 8│9 A B C D E F G│H I J K L M N O│P Q R S T U V W│X Y Z a b c d e│ ├─────────┬─────┼───┬─────────┬─┼───────┬───────┼─┬─────────┬───┼─────┬─────────┤ │A A A A A│B B B│B B│C C C C C│D│D D D D│E E E E│E│F F F F F│G G│G G G│H H H H H│ │% 8 4 2 1│% 8 4│2 1│% 8 4 2 1│%│8 4 2 1│% 8 4 2│1│% 8 4 2 1│% 8│4 2 1│% 8 4 2 1│ └─────────┴─────┴───┴─────────┴─┴───────┴───────┴─┴─────────┴───┴─────┴─────────┘ Alternativdarstellung von AAL2-G726-40 als Datenstrom. </syntaxhighlight>

X.420

– ITU-T<ref>ITU-T Rec. X.420 (06/1999)</ref>

<syntaxhighlight lang="c">

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

┌─────┬─────────┐ ┌───────┬───────┐ ┌───┬─────┬─────┐ ┌───┬───┬───┬───┐ │B B B│A A A A A│ │B B B B│A A A A│ │C C│B B B│A A A│ │D D│C C│B B│A A│ │4 2 1│% 8 4 2 1│ 1 │8 4 2 1│8 4 2 1│ 1 │2 1│4 2 1│4 2 1│ 1 │2 1│2 1│2 1│2 1│ 1 ├─┬───┴─────┬───┤ ├───────┼───────┤ ├─┬─┴───┬─┴───┬─┤ ├───┼───┼───┼───┤ │D│C C C C C│B B│ │D D D D│C C C C│ │F│E E E│D D D│C│ │H H│G G│F F│E E│ │1│% 8 4 2 1│% 8│ 2 │8 4 2 1│8 4 2 1│ 2 │1│4 2 1│4 2 1│4│ 2 │2 1│2 1│2 1│2 1│ 2 ├─┴─────┬───┴───┤ ├───────┼───────┤ ├─┴───┬─┴───┬─┴─┤ └───┴───┴───┴───┘ │E E E E│D D D D│ │F F F F│E E E E│ │H H H│G G G│F F│ X.420 G726-16 │8 4 2 1│% 8 4 2│ 3 │8 4 2 1│8 4 2 1│ 3 │4 2 1│4 2 1│4 2│ 3 ├───┬───┴─────┬─┤ ├───────┼───────┤ └─────┴─────┴───┘ │G G│F F F F F│E│ │H H H H│G G G G│ X.420 G726-24 │2 1│% 8 4 2 1│%│ 4 │8 4 2 1│8 4 2 1│ 4 ├───┴─────┬───┴─┤ └───────┴───────┘ │H H H H H│G G G│ X.420 G726-32 │% 8 4 2 1│% 8 4│ 5 └─────────┴─────┘ X.420 G726-40 [„%“ steht für 16, das Bit mit dem höchsten Wert] ┌───────────────┬───────────────┬───────────────┬───────────────┬───────────────┐ │8 7 6 5 4 3 2 1│G F E D C B A 9│O N M L K J I H│W V U T S R Q P│e d c b a Z Y X│ ├─────┬─────────┼─┬─────────┬───┼───────┬───────┼───┬─────────┬─┼─────────┬─────┤ │B B B│A A A A A│D│C C C C C│B B│E E E E│D D D D│G G│F F F F F│E│H H H H H│G G G│ │4 2 1│% 8 4 2 1│1│% 8 4 2 1│% 8│8 4 2 1│% 8 4 2│2 1│% 8 4 2 1│%│% 8 4 2 1│% 8 4│ └─────┴─────────┴─┴─────────┴───┴───────┴───────┴───┴─────────┴─┴─────────┴─────┘ Alternativdarstellung von X.420 G726-40 als Datenstrom </syntaxhighlight>

RFC& 3551 (2003)

In RFC 3551<ref name="RFC3551" /> von 2003 (welche die RFC 1890<ref name="RFC1890" /> ersetzt) wurde versucht, die Problematik der widersprüchlichen Endianness durch Abschnitt 4.5.4 aufzulösen. Den bestehenden MIME-types (G726-16, 24, 32 und 40) wurde Little Endian nach X.420 zugeschrieben, für Big Endian nach I.366.2 Annex E wurden neue MIME-types vorgeschlagen (AAL2-G726-16, 24, 32 und 40). Um Verwirrung zu vermeiden, wurde darüber hinaus Payload Type 2 für veraltet erklärt. Stattdessen soll nun ein dynamischer Payload Type (frei wählbar, von 96 bis 127) verwendet werden:

– RFC 3551, Abschnitt 4.5.4<ref>Vorlage:RFC-Internet</ref>

– RFC 3551, Abschnitt 6<ref>Vorlage:RFC-Internet</ref>

Little Endian (X.420 und RFC 3551<ref name="RFC3551" />)	Big Endian (I.366.2 Annex E und RFC 3551<ref name="RFC3551" />)	veraltet nach RFC 1890<ref name="RFC1890" />
G726-16 a=rtpmap:{von 96 bis 127} G726-16/8000	AAL2-G726-16 a=rtpmap:{von 96 bis 127} AAL2-G726-16/8000	a=rtpmap:2 G726-16/8000
G726-24 a=rtpmap:{von 96 bis 127} G726-24/8000	AAL2-G726-24 a=rtpmap:{von 96 bis 127} AAL2-G726-24/8000	a=rtpmap:2 G726-24/8000
G726-32 a=rtpmap:{von 96 bis 127} G726-32/8000	AAL2-G726-32 a=rtpmap:{von 96 bis 127} AAL2-G726-32/8000	a=rtpmap:2 G726-32/8000
G726-40 a=rtpmap:{von 96 bis 127} G726-40/8000	AAL2-G726-40 a=rtpmap:{von 96 bis 127} AAL2-G726-40/8000	a=rtpmap:2 G726-40/8000

Neuere Implementierungen halten sich nun an RFC 3551,<ref name="RFC3551" /> d. h., sie verstehen unter G726-xx eindeutig Little Endian und bieten zusätzlich AAL2-G726-xx an, das sie eindeutig als Big Endian interpretieren. Mit älteren Implementierungen, die G726-xx je nach Interpretation als Big Endian oder Little Endian verstehen, kann es deshalb zum oben beschriebenen Problem des verzerrten Audiosignals kommen.

Implementierungen

Fallbeispiel Gigaset

Gigaset (Firmware 42.238) hält sich an RFC 3551,<ref name="RFC3551" /> bietet aber an dritter Stelle zusätzlich immer noch G.726 nach der veralteten RFC 1890<ref name="RFC1890" /> an:

a=rtpmap:96 G726-32/8000 → X.420 (Little Endian)
a=rtpmap:97 AAL2-G726-32/8000 → I.366.2 Annex E (Big Endian)
a=rtpmap:2 G726-32/8000 → I.366.2 Annex E (Big Endian), wie G.721 nach veralteter RFC 1890<ref name="RFC1890" />

Der Nachteil dieser Vorgehensweise ist, dass viele Server nicht darauf ausgelegt sind, den Trick mit dem Payload Type zu verstehen, d. h., sie unterscheiden nicht zwischen a=rtpmap:2 G726-32/8000 mit I.366.2 Annex E (Big Endian) und a=rtpmap:{von 96 bis 127} G726-32/8000 mit X.420 (Little Endian). Es wird also Serverseitig wieder zwischen X.420 und I.366.2 Annex E gemischt.

Eine Lösung für die praktisch nach wie vor bestehende Codecverwirrung ist, AAL2-G726 beim Gesprächsaufbau serverseitig immer den Vorzug zu geben, da man hier sehr sicher sein kann, dass sich dahinter wirklich Big Endian verbirgt.

Weitere Hardware

Auch SNOM unterstützt sowohl den MIME-type G726 als auch AAL2-G726.<ref>Vorlage:Webarchiv/WaybackVorlage:Webarchiv/archiv-botVorlage:Webarchiv/Wartung/URL</ref>

Manche Implementierungen, wie zum Beispiel alte Versionen der AVM Fritz!Box, ermöglichten es dem Benutzer, die Bitreihenfolge selber festzulegen. Mit der Checkbox „Anbieter unterstützt G726 nach RFC 3551“ konnte die Bitreihenfolge vom Benutzer umgeschaltet werden. Der Hintergrund dafür ist, dass AVM sehr lange den MIME-type G726 statt AAL2-G726 für Big Endian verwendet hat und daher eine Übergangsregelung hin zum standardkonformen Verhalten nötig war.

VoIP Clients

• Twinkle: MIME-Type G726-40, G726-32, G726-24 und G726-16, der Benutzer kann zwischen Big und Little Endian umschalten

VoIP Provider

Bei den VoIP-Anbietern, die G.726 anbieten, zeigt sich das folgende Bild:

• Betamax und Ableger: MIME-Type G726-32 mit I.366.2 Annex E (Big Endian)
• Sipcall bei eingehenden Gesprächen aus dem PSTN: MIME-Type G726-32 mit I.366.2 Annex E (Big Endian)

Weblinks

• ITU-Spezifikation
• G726-32-Sprachdaten in richtiger Bitreihenfolge dekodiert (WAV; 95 kB)
• G726-32-Sprachdaten in „falscher“ Bitreihenfolge dekodiert (WAV; 102 kB)

Einzelnachweise

<references> <ref name="RFC1890"> Vorlage:RFC-Internet </ref> <ref name="RFC3551"> Vorlage:RFC-Internet </ref> </references>