G.726 es un estándar de códec de voz ADPCM de la UIT-T que cubre la transmisión de voz a velocidades de 16, 24, 32 y 40 kbit /s. Se introdujo para reemplazar tanto a G.721, que cubría ADPCM a 32 kbit/s, como a G.723 , que describía ADPCM para 24 y 40 kbit/s. G.726 también introdujo una nueva velocidad de 16 kbit/s. Las cuatro velocidades de bits asociadas con G.726 se suelen denominar por el tamaño de bits de una muestra , que son 2, 3, 4 y 5 bits respectivamente. El códec de banda ancha correspondiente basado en la misma tecnología es G.722 .
El modo más comúnmente utilizado es el de 32 kbit/s, que duplica la capacidad de red utilizable al utilizar la mitad de la velocidad del G.711 . Se utiliza principalmente en troncales internacionales en la red telefónica y es el códec estándar utilizado en los sistemas telefónicos inalámbricos DECT . La principal aplicación de los canales de 24 y 16 kbit/s es para canales de sobrecarga que transportan voz en equipos de multiplicación de circuitos digitales (DCME). La principal aplicación de los canales de 40 kbit/s es transportar señales de módem de datos en DCME, especialmente para módems que funcionan a más de 4800 bit/s.
La norma G.721 se introdujo en 1984, mientras que la G.723 se introdujo en 1988. Se incorporaron a la G.726 en 1990.
G.727 se introdujo al mismo tiempo que G.726 e incluye las mismas velocidades de bits, pero está optimizado para el entorno de equipos de multiplexación de circuitos de paquetes (PCME). Esto se logra incorporando un cuantificador de 2 bits a un cuantificador de 3 bits y lo mismo para los modos superiores. Esto permite descartar el bit menos significativo del flujo de bits sin efectos adversos en la señal de voz.
Dado que el orden de bytes para los protocolos de datos en el contexto de Internet se definía generalmente como big endian y se denominaba simplemente orden de bytes de red , como se indica (entre otros) en el obsoleto RFC 1700, el obsoleto RFC 1890 tampoco definió explícitamente el orden de bytes del predecesor de G.726, G.721, en RTP. En cambio, en el obsoleto RFC 1890, el uso de big endian por el término orden de bytes de red se indicó nuevamente de manera general para todos los códecs mencionados:
"Para las codificaciones de múltiples octetos, los octetos se transmiten en orden de bytes de la red (es decir, el octeto más significativo primero)".
— IETF, la RFC 1890 obsoleta, sección 4.2
El tipo de carga útil para G.721 fue definido por el RFC 1890 obsoleto como 2 , por lo tanto a=rtpmap:2 G721/8000. En los borradores para la versión más nueva de este RFC, se reutilizó para G.726, es decir a=rtpmap:2 G726-32/8000.
Por el contrario, la UIT definió explícitamente el orden de bytes en sus recomendaciones relativas a G.726 o ADPCM respectivamente, pero de dos maneras diferentes. La recomendación X.420 establece que debe ser little endian, mientras que en el Anexo E de la recomendación I.366.2 debe ser big endian. Esto dio lugar a decisiones contradictorias en varias implementaciones, ya que algunos fabricantes optaron por little endian y otros por big endian. La consecuencia fue que estas implementaciones eran incompatibles, ya que la decodificación utilizando el orden de bytes incorrecto da como resultado una señal de audio muy distorsionada. Por lo tanto, la definición poco clara fue corregida por el RFC 3551, que reemplaza al RFC 1890. La sección 4.5.4 del RFC 3551 define los tipos MIME clásicos G726-16, 24, 32 y 40 como little endian e introduce nuevos tipos MIME para big endian, que son AAL2-G726-16, 24, 32 y 40. El tipo de carga útil se cambió a dinámico para evitar confusiones. En lugar del tipo de carga útil 2, se utilizará una carga útil dinámica en el rango de 96 a 127:
"Tenga en cuenta que la dirección "little-endian" en la que se empaquetan las muestras en octetos en los formatos de carga útil G726-16, -24, -32 y -40 especificados aquí es coherente con la Recomendación UIT-T X.420, pero es lo opuesto a lo que se especifica en el Anexo E de la Recomendación UIT-T I.366.2 para el transporte ATM AAL2. Un segundo conjunto de formatos de carga útil RTP que coinciden con la paquetización del Anexo E de la Recomendación I.366.2 e identificados por los subtipos MIME AAL2-G726-16, -24, -32 y -40 se especificará en un documento separado".
— IETF, RFC 3551, sección 4.5.4
"El tipo de carga útil 2 se asignó a G721 en RFC 1890 y a su sucesor equivalente G726-32 en versiones preliminares de esta especificación, pero su uso ahora está obsoleto y ese tipo de carga útil estática está marcado como reservado debido al uso conflictivo de los formatos de carga útil G726-32 y AAL2-G726-32 (consulte la Sección 4.5.4)"
— IETF, RFC 3551, sección 6
Las implementaciones más recientes respetan el RFC 3551 y distinguen claramente entre G726-xx (little endian) y AAL2-G726-xx (big endian). El teléfono IP DECT Gigaset C610, por ejemplo, genera el siguiente código en su SIP INVITE:
a=rtpmap:96 G726-32/8000→ tipo de carga útil dinámica 96 y G.726 según X.420, por lo tanto little endian, como se define en RFC 3551 a=rtpmap:97 AAL2-G726-32/8000→ tipo de carga útil dinámica 97 y G.726 según I.366.2 Anexo E, por lo tanto big endian, como se define en RFC 3551 a=rtpmap:2 G726-32/8000→ tipo de carga útil estática 2 y G.726 con endianidad impredecible, como G.721 según el obsoleto RFC 1890