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“ definiert sogenannte Payload Typen für das Übertragungsprotokoll RTP und bekräftigt Big Endian als die Standard-Byte-Reihenfolge für alle Codecs:

“For multi-octet encodings, octets are transmitted in network byte order (i.e., most significant octet first).”

– RFC 1890

Der Payload Type für G.721 in der historischen RFC 1890 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

“The data unit format requires that G.726 outputs be accumulated over an interval of 1 ms to yield a sequence of 8 encoded values. These are concatenated in chronological order, with the earliest positioned at the most significant bit of the first octet.”

– ITU-T

 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. 

X.420

“The 4-bit code words of the G.726 encoding shall be packed into the octets of the OCTET STRING as follows: the first code word is placed in the four least significant bits of the first octet, with the least significant bit of the code word in the least significant bit of the octet; the second code word is placed in the four most significant bits of the first octet, with the most significant bit of the code word in the most significant bit of the octet. Subsequent pairs of code words shall be packed in the same way into successive octets, with the first code word of each pair placed in the least significant four bits of the octet. It is preferred that the voice sample be extended with silence such that the encoded value comprises an even number of code words. However, if the voice sample comprises an odd number of code words, then the last code word shall be discarded.”

– ITU-T

 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 

RFC& 3551 (2003)

In RFC 3551 von 2003 (welche die RFC 1890 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:

“Note that the ‘little-endian’ direction in which samples are packed into octets in the G726-16, -24, -32 and -40 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a separate document.”

– RFC 3551, Abschnitt 4.5.4

“Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4)”

– RFC 3551, Abschnitt 6

Little Endian (X.420 und RFC 3551)	Big Endian (I.366.2 Annex E und RFC 3551)	veraltet nach RFC 1890
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-16/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-16/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-16/8000

Neuere Implementierungen halten sich nun an RFC 3551, 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, bietet aber an dritter Stelle zusätzlich immer noch G.726 nach der veralteten RFC 1890 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

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.

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

1. RFC 1890 – RTP Profile for Audio and Video Conferences with Minimal Control. 1996 (englisch).
2. RFC 1890 – RTP Profile for Audio and Video Conferences with Minimal Control. 1996, Abschnitt 4.2 (englisch).
3. ITU-T I.366.2 (11/2000), Annex E
4. ITU-T Rec. X.420 (06/1999)
5. RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control. Juli 2003 (löst RFC 1890 ab, englisch).
6. RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control. 2003, Abschnitt 4.5.4 (englisch).
7. RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control. 2003, Abschnitt 6 (englisch).
8. wiki.snom.com