imported>Uncopy: /* RFC& 3551 (2003) */ Korrigiere kHz-Angaben in Veraltet-Spalte

2025-09-04T09:40:34Z

RFC& 3551 (2003): Korrigiere kHz-Angaben in Veraltet-Spalte

Neue Seite

'''G.726''' ist ein [[Adaptive Differential Pulse Code Modulation|ADPCM]]-basierter Schmalband-[[Codec]] (50 bis 4000 Hz) der [[Internationale Fernmeldeunion|Internationalen Fernmeldeunion]] (ITU-T) zur [[Datenkompression|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 [[Code-Excited Linear Prediction|CELP-basierten]] [[G.723.1]]) als deren Nachfolgestandard zusammen.

{| class="wikitable"
|-
! 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 [[Digital Enhanced Cordless Telecommunications|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-[[Datenkompression|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ögerung (Telekommunikation)|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 [[Switch (Computertechnik)#Unterschiedliche Arbeitsweisen|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:

{| class="wikitable"
|-
!colspan="2"| 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<nowiki /> 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 <nowiki>RFC 1890</nowiki> 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:

{{Zitat
|Text=For multi-octet encodings, octets are transmitted in network byte order (i.e., most significant octet first).
|Sprache=en
|Quelle=<nowiki>RFC 1890</nowiki>
|ref=<ref>{{RFC-Internet |RFC=1890 |Titel=RTP Profile for Audio and Video Conferences with Minimal Control |Datum=1996 |Abschnitt=4.2}}</ref>}}

Der Payload Type für G.721 in der historischen <nowiki>RFC 1890</nowiki><ref name="RFC1890" /> war ''2'', also <code>a=rtpmap:2 G721/8000</code>. Dieser wurde später in Entwürfen für die Nachfolger-RFC als <code>a=rtpmap:2 G726-32/8000</code> 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 ====
{{Zitat
|Text=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.
|Sprache=en
|Quelle=ITU-T
|ref=<ref>[https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-I.366.2-200011-I!!PDF-E&type=items 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 ====
{{Zitat
|Text=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.
|Sprache=en
|Quelle=ITU-T
|ref=<ref>[https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.420-199906-I!!PDF-E&type=items 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&<nowiki /> 3551 (2003) ===
In <nowiki>RFC 3551</nowiki><ref name="RFC3551" /> von 2003 (welche die <nowiki>RFC 1890</nowiki><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:

{{Zitat
|Text=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.
|Sprache=en
|Quelle=<nowiki>RFC 3551</nowiki>, Abschnitt 4.5.4
|ref=<ref>{{RFC-Internet |RFC=3551 |Titel=RTP Profile for Audio and Video Conferences with Minimal Control |Datum=2003 |Abschnitt=4.5.4}}</ref>}}

{{Zitat
|Text=Payload type 2 was assigned to G721 in <nowiki>RFC 1890</nowiki> 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)
|Sprache=en
|Quelle=<nowiki>RFC 3551</nowiki>, Abschnitt 6
|ref=<ref>{{RFC-Internet |RFC=3551 |Titel=RTP Profile for Audio and Video Conferences with Minimal Control |Datum=2003 |Abschnitt=6}}</ref>}}

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

Neuere Implementierungen halten sich nun an <nowiki>RFC 3551</nowiki>,<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 <nowiki>RFC 3551</nowiki>,<ref name="RFC3551" /> bietet aber an dritter Stelle zusätzlich immer noch G.726 nach der veralteten <nowiki>RFC 1890</nowiki><ref name="RFC1890" /> an:

<code>a=rtpmap:96 G726-32/8000</code> → X.420 (Little Endian) 
<code>a=rtpmap:97 AAL2-G726-32/8000</code> → I.366.2 Annex E (Big Endian) 
<code>a=rtpmap:2 G726-32/8000</code> → I.366.2 Annex E (Big Endian), wie G.721 nach veralteter <nowiki>RFC 1890</nowiki><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 <code>a=rtpmap:2 G726-32/8000</code> mit I.366.2 Annex E (Big Endian) und <code>a=rtpmap:{von 96 bis 127} G726-32/8000</code> 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>{{Webarchiv|url=http://wiki.snom.com/Codec_Overview_8.9.3.15 |wayback=20160804084829 |text=wiki.snom.com |archiv-bot=2025-03-19 05:03:08 InternetArchiveBot }}</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 <nowiki>RFC 3551</nowiki>“ 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 (Software)|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 ==
* [http://www.itu.int/rec/T-REC-G.726-199012-I/en ITU-Spezifikation]
* [http://www.siski.de/~carsten/audio/G726-correct-bitorder-decoded.wav G726-32-Sprachdaten in richtiger Bitreihenfolge dekodiert] ([[RIFF WAVE|WAV]]; 95 kB)
* [http://www.siski.de/~carsten/audio/G726-wrong-bitorder-decoded.wav G726-32-Sprachdaten in „falscher“ Bitreihenfolge dekodiert] ([[RIFF WAVE|WAV]]; 102 kB)

== Einzelnachweise ==
<references>
<ref name="RFC1890">
{{RFC-Internet |RFC=1890 |Titel=RTP Profile for Audio and Video Conferences with Minimal Control |Datum=1996}}
</ref>
<ref name="RFC3551">
{{RFC-Internet |RFC=3551 |Titel=RTP Profile for Audio and Video Conferences with Minimal Control |Datum=2003-07 |Obsoletes=1890}}
</ref>
</references>

[[Kategorie:Audiokompression]]
[[Kategorie:VoIP]]
[[Kategorie:Codec]]
[[Kategorie:ITU-Empfehlung]]

G.726 - Versionsgeschichte

imported>Uncopy: /* RFC& 3551 (2003) */ Korrigiere kHz-Angaben in Veraltet-Spalte