G.726

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 bit 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 utilizado es el de 32  kbit/s, que duplica la capacidad útil de la red al emplear la mitad de la velocidad de G.711 . Se utiliza principalmente en troncales internacionales de la red telefónica y es el códec estándar en los sistemas de telefonía inalámbrica DECT . La principal aplicación de los canales de 24 y 16  kbit/s es para canales de sobrecarga que transmiten voz en equipos de multiplicación de circuitos digitales (DCME). La principal aplicación de  los canales de 40 kbit/s es para transmitir señales de módem de datos en DCME, especialmente para módems que operan a más de 4800  bit/s.

El modelo G.721 se introdujo en 1984, mientras que el G.723 se introdujo en 1988. Ambos se fusionaron para formar el modelo G.726 en 1990.

El estándar G.727 se introdujo simultáneamente con el G.726 e incluye las mismas tasas de bits, pero está optimizado para entornos de equipos de multiplexación por circuito de paquetes (PCME). Esto se logra mediante la integración de 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 afectar negativamente la señal de voz.

• Frecuencia de muestreo: 8  kHz
• Velocidades de bits disponibles: 16  kbit/s, 24  kbit/s, 32  kbit/s y 40  kbit/s.
• Genera un flujo de bits , por lo tanto, la longitud del fotograma está determinada por el tiempo de empaquetamiento (normalmente 80 muestras para un tamaño de fotograma de 10 ms ). 
• El retardo algorítmico típico es de 0,125  ms, sin retardo de anticipación.
• G.726 es un codificador de voz de forma de onda que utiliza modulación de código de pulsos diferencial adaptativa ( ADPCM ).
• Las pruebas PSQM en condiciones ideales arrojan puntuaciones de opinión promedio de 4,30 para G.726 (32  kbit/s), en comparación con 4,45 para G.711 ( ley μ ).
• Las pruebas PSQM bajo estrés de red arrojan puntuaciones de opinión promedio de 3,79 para G.726 (32  kbit/s), en comparación con 4,13 para G.711 (ley μ).
• El protocolo G.726 de 40  kbit/s puede transmitir  señales de módem de 12000 bit/s y más lentas, mientras que  el G.726 de 32 kbit/s puede transmitir  señales de módem de 2400 bit/s y más lentas sin problemas, y señales de módem de 4800  bit/s con cierta degradación mayor que los códecs de canal claro.

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 indicaba (entre otros) en el RFC 1700 obsoleto, el RFC 1890 obsoleto tampoco definía explícitamente el orden de bytes del predecesor de G.726, G.721, en RTP. En cambio, en el RFC 1890 obsoleto, se volvió a indicar el uso de big endian con el término orden de bytes de red para todos los códecs mencionados:

"Para codificaciones de múltiples octetos, los octetos se transmiten en el orden de bytes de la red (es decir, el octeto más significativo primero)." — IETF, RFC 1890 (obsoleto), 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 de versiones más recientes 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 sobre G.726 o ADPCM, respectivamente, pero de dos maneras distintas. La recomendación X.420 establece que debe ser little endian, mientras que la recomendación I.366.2 Anexo E indica que debe ser big endian. Esto dio lugar a decisiones contradictorias en diversas implementaciones, ya que algunos fabricantes optaron por little endian y otros por big endian. La consecuencia fue que estas implementaciones resultaron incompatibles, puesto que la decodificación con un orden de bytes incorrecto produce una señal de audio muy distorsionada. Por lo tanto, la definición poco clara se corrigió mediante 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 debe usar 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 X.420 de la UIT-T, pero es la opuesta a la especificada en el Anexo E de la Recomendación I.366.2 de la UIT-T para el transporte ATM AAL2. Un segundo conjunto de formatos de carga útil RTP que coincidan con la empaquetació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 aparte.» — 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 para los formatos de carga útil G726-32 y AAL2-G726-32 (véase la Sección 4.5.4)" — IETF, RFC 3551, sección 6

Las implementaciones más recientes respetan la 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 endianness impredecible, como G.721 según el RFC 1890 obsoleto

• Lista de códecs
• Comparación de formatos de codificación de audio

• Página G.726 de la UIT-T
• Herramientas de software ITU-T G.191 para codificación de voz y audio, incluido el código C G.726.
• RFC 3551 - Perfil RTP para conferencias de audio y video con control mínimo, G726-40, G726-32, G726-24 y G726-16