G.726
G.726 is an ADPCM -based narrowband codec (50 to 4000 Hz) of the International Telecommunication Union (ITU-T) for the compression of speech into digital telephone signals. The broadband codec based on the same technology is G.722 .
history
The standard was adopted in 1990 and includes the older G.721 from 1984 (32 kbit / s) and the G.723 from 1988 (24 and 40 kbit / s, not to be confused with the CELP-based G.723.1 ) as their successor standard together.
| kbit / s | Bits / sample 50 to 4000 Hz |
Bits / sample 4000 to 7000 Hz |
G.721 (1984) obsolete |
G.722 (1988) current |
G.723 (1988) obsolete |
G.726 (1990) current |
|---|---|---|---|---|---|---|
| 64 | 6th | 2 | - | + | - | - |
| 56 | 5 | 2 | - | + | - | - |
| 48 | 4th | 2 | - | + | - | - |
| 40 | 5 | 0 | - | - | + | + |
| 32 | 4th | 0 | + | - | - | + |
| 24 | 3 | 0 | - | - | + | + |
| 16 | 2 | 0 | - | - | - | + |
Technical specifications
The method is based on Adaptive Differential Pulse Code Modulation (ADPCM).
The codec supports bit rates of 16, 24, 32 and 40 kbit / s.
G.726 achieves a Mean Opinion Score (MOS) of around 4.2 for the 40 kbit / s variant and around 3.85 for the 32 kbit / s variant.
use
G.726 is also used for IP telephony , among other things .
The 32 kbit / s variant is used for narrowband telephony with DECT telephones. The DECT standard is specially tailored to G.726-32, so a DECT radio channel can transmit exactly 32 kbit / s. The decision for G.726 was also made because ADPCM is relatively insensitive to bit errors, which is of particular interest for radio applications. The 32 kbit / s variant also has the advantage that two interconnected channels result in 64 kbit / s, which makes it possible to transmit exactly one G.722 data stream (64 kbit / s) with two channels and thus HD- Telephony can also be implemented with ADPCM via DECT.
The codec is also used for international telephone network connections in the landline and mobile network infrastructure. The multiplex method used is usually DCME (Digital Circuit Multiplication Equipment) implemented in accordance with G.763 and uses the G.726 codecs with 16, 24, 32 and 40 kbit / s depending on the load on the international voice traffic. These compressions are also used internationally in some access networks for connecting private branch exchanges.
Data volume and delay times
For example, voice compression to 32 kbit / s results in a data volume of 240 kB per minute; a one-hour VoIP phone call results in 14.4 MB of voice data. This does not include the protocol data for communication in IP networks, which, depending on the number of data packet rates and the protocol, require up to 50% additional bandwidth. In circuit-switched networks, the protocol data are part of a separate signaling channel.
Delay times in IP networks depend on the transmission time (transmission delay ), the necessary buffering in the event of jitter (jitter buffering ), the number of interconnected nodes and their transmission rates ( transmission delay , unless they are cut-through switches ) as well as the encoding and Decoding (packetization time) of the language using the G.726 codec used here with the corresponding packet rate. In circuit-switched networks, there is only a delay due to transmission time, encoding and decoding.
Problem of endianness and payload type with RTP
Endianness
In computer science and telematics, endianness describes the byte order of data streams. Specifically, it is a question of whether a numerical value is noted starting with the highest or lowest digit or whether it is transmitted over a network:
| Five hundred and twenty-one | |
|---|---|
| Little endian: | 125 |
| Big Endian: | 521 |
If an audio signal compressed with G.726 is decompressed in the "wrong" bit order, speech will sound heavily distorted and will be difficult or impossible to understand.
Obsolete RFC 1890 (1996)
In the context of the Internet, Big Endian is the typical byte order. Big Endian is therefore simply referred to here as Network Byte Order . The outdated RFC 1890 from 1996 with the title "RTP Profile for Audio and Video Conferences with Minimal Control" defines so-called payload types for the RTP transmission protocol and confirms Big Endian as the standard byte order for all codecs:
"For multi-octet encodings, octets are transmitted in network byte order (ie, most significant octet first)."
The payload type for G.721 in the historical RFC 1890 was 2 , so a=rtpmap:2 G721/8000. This was later used in drafts for the successor RFC a=rtpmap:2 G726-32/8000.
Recommendations of the ITU-T
The ITU-T has the byte order explicitly set out in its recommendations for ADPCM in networks, but in two contradictory ways: The Recommendation X.420 Little Endian was written in Recommendation I.366.2 Annex E , however, Big Endian. As a result, some manufacturers have opted for little endian in their implementations, while others have chosen 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. "
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. "
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 of 2003 (which replaces RFC 1890 ) an attempt was made to resolve the problem of contradicting endianness by means of Section 4.5.4. Little Endian according to X.420 was assigned to the existing MIME types (G726-16, 24, 32 and 40); new MIME types were proposed for Big Endian according to I.366.2 Annex E (AAL2-G726-16, 24, 32 and 40). Additionally, to avoid confusion, Payload Type 2 has been deprecated. Instead, a dynamic payload type (freely selectable, from 96 to 127 ) should be used:
"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. "
"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) "
| Little Endian (X.420 and RFC 3551 ) |
Big Endian (I.366.2 Annex E and RFC 3551 ) |
obsolete according to 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
|
Newer implementations now adhere to RFC 3551 ; In other words , they clearly understand G726-xx as Little Endian and also offer AAL2-G726-xx , which they clearly interpret as Big Endian. With older implementations, which understand the G726-xx as Big Endian or Little Endian, depending on the interpretation, the problem of the distorted audio signal described above can therefore arise.
Implementations
Case study Gigaset
Gigaset (firmware 42.238) adheres to RFC 3551 , but still offers G.726 in third place after the outdated RFC 1890 :
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), like G.721 according to the outdated RFC 1890
The disadvantage of this approach is that many servers are not designed to understand the payload type trick; This means that they do not differentiate between a=rtpmap:2 G726-32/8000with I.366.2 Annex E (Big Endian) and a=rtpmap:{von 96 bis 127} G726-32/8000with X.420 (Little Endian). On the server side, X.420 and I.366.2 Annex E are mixed again.
One solution to the codec confusion that still exists in practice is to always give preference to AAL2-G726 when setting up a call on the server side, since you can be very sure that it is really Big Endian.
More hardware
SNOM also supports both the MIME-type G726 and AAL2-G726.
Some implementations, such as old versions of the AVM Fritz! Box , made it possible for the user to determine the bit order himself. With the checkbox "Provider supports G726 according to RFC 3551 ", the bit sequence could be switched by the user. The reason for this is that AVM used the MIME-type G726 instead of AAL2-G726 for Big Endian for a very long time and therefore a transitional regulation was necessary for behavior in accordance with the standards.
VoIP clients
- Twinkle : MIME-Type G726-40 , G726-32 , G726-24 and G726-16 , the user can switch between Big and Little Endian
VoIP provider
The following picture shows the VoIP providers who offer G.726:
- Betamax and offshoots: MIME-Type G726-32 with I.366.2 Annex E (Big Endian)
- Sipcall for incoming calls from the PSTN: MIME-Type G726-32 with I.366.2 Annex E (Big Endian)
Web links
- ITU specification
- G726-32 voice data decoded in the correct bit order (WAV file; 95 kB)
- G726-32 voice data decoded in "wrong" bit order (WAV file; 102 kB)