Códec G.711: μ-law, A-law y audio telefónico a 8 kHz

Rene, Kabir Goel 
Códec G.711: μ-law, A-law y audio telefónico a 8 kHz

G.711 es el códec que oye tu agente de voz en la mayoría de las llamadas telefónicas. Muestrea el audio 8.000 veces por segundo, guarda cada muestra en 8 bits con una de dos curvas logarítmicas, μ-law o A-law, y envía el resultado a 64 kbit/s. La UIT lo publicó por primera vez como Recomendación G.711 en 1972, y sigue siendo el formato por defecto en la red telefónica pública, en la mayoría de troncales SIP y en los media streams de Twilio.

Si construyes algo que toque audio telefónico, tarde o temprano manejarás bytes G.711. Esta guía explica cómo funciona el códec, cómo distinguir μ-law de A-law, cómo decodificarlo y codificarlo en pocas líneas de código, qué errores convierten a quien llama en ruido y cómo meter y sacar audio de 8 kHz de los modelos de voz sin conversiones de más. Está escrita para ingenieros que conectan una línea telefónica con reconocimiento de voz, un LLM y texto a voz.

G.711 de un vistazo

PropiedadValor
Frecuencia8.000 Hz
Bits por muestra8 (logarítmicos, no lineales)
Tasa de bits64 kbit/s por sentido
Banda de audioDe unos 300 a 3.400 Hz
Variantesμ-law (PCMU) y A-law (PCMA)
Carga útil RTPPCMU = 0, PCMA = 8, ambos con reloj de 8.000 Hz
Paquete de 20 ms160 muestras, 160 bytes de carga útil
Retardo del códecUna muestra (0,125 ms), sin anticipación
Bytes de silencioμ-law 0xFF, A-law 0xD5

El paquete de 20 ms viene de la RFC 3551, que fija 20 ms como intervalo de paquetización por defecto para PCMU y PCMA. La mayoría de operadores y PBX lo usan, así que 160 bytes por paquete es la cifra que verás en las capturas.

Cómo funcionan μ-law y A-law

Una muestra lineal de 16 bits puede describir 65.536 niveles. La voz no necesita tantos escalones iguales. Necesita detalle fino a volumen bajo, donde está casi toda la información de una voz, y escalones gruesos a volumen alto, donde el oído no nota errores pequeños.

G.711 hace exactamente eso. Lleva cada muestra a una curva logarítmica, un proceso llamado compansión (comprimir y luego expandir al decodificar). Cada código de 8 bits tiene tres partes: un bit de signo, tres bits que eligen uno de ocho segmentos y cuatro bits que eligen un escalón dentro del segmento. Cada segmento cubre el doble de rango que el anterior, así que el tamaño del escalón se duplica a medida que sube la señal.

Las dos variantes reparten los escalones de forma distinta:

  • μ-law parte de una muestra lineal de 14 bits y se usa en Norteamérica y Japón. También es el único formato que envían y aceptan los Media Streams de Twilio.
  • A-law parte de una muestra lineal de 13 bits y se usa en Europa, India y la mayoría de los demás países. Da algo más de resolución a las señales suaves.

Las dos guardan un rango dinámico de 13 o 14 bits en 8 bits, y por eso G.711 suena como una llamada normal y no como un walkie-talkie. Cuando una llamada pasa de un país μ-law a uno A-law, la red la convierte, y el estándar dice que el enlace entre ambos va en A-law.

Cómo saber cuál tienes

Normalmente no se puede saber solo con los bytes. Los dos son una secuencia de valores sin signo de 8 bits y sin cabecera. Mira los metadatos que los rodean:

  • SDP. a=rtpmap:0 PCMU/8000 es μ-law. a=rtpmap:8 PCMA/8000 es A-law.
  • Twilio Media Streams. El mensaje start siempre dice "encoding": "audio/x-mulaw" y "sampleRate": 8000. La documentación de mensajes WebSocket de Twilio deja claro que esto no cambia nunca.
  • Archivos WAV. La etiqueta de formato del bloque fmt es 7 para μ-law y 6 para A-law. ffprobe muestra pcm_mulaw o pcm_alaw.
  • Silencio. En una línea en silencio, los bytes μ-law se quedan cerca de 0xFF y 0x7E, y los A-law alternan entre 0xD5 y 0x55. Un búfer lleno de 0xFF es casi seguro silencio μ-law, no un flujo corrupto.

Si te equivocas, se nota. Cuando codificamos un tono de 440 Hz como μ-law y lo decodificamos como A-law, la salida conservaba solo la mitad de correlación con el original en todos los volúmenes que probamos, y su sonoridad oscilaba entre la mitad y el doble según el nivel de entrada. El audio con la ley equivocada es lo bastante inteligible como para hacerte buscar el fallo en otra parte, y lo bastante áspero como para arruinar el reconocimiento de voz.

Decodificar y codificar G.711 en código

La vía más rápida es FFmpeg, que lee y escribe las dos leyes como flujos crudos:

# μ-law crudo de una llamada a un WAV de 16 bits que puedes escuchar
ffmpeg -f mulaw -ar 8000 -ac 1 -i call.ulaw call.wav

# Cualquier archivo de audio a μ-law crudo de 8 kHz, listo para enviar a Twilio
ffmpeg -i prompt.wav -ar 8000 -ac 1 -f mulaw prompt.ulaw

# A-law: cambia el nombre del formato
ffmpeg -f alaw -ar 8000 -ac 1 -i call.alaw call.wav

En Python, la biblioteca estándar lo hacía con audioop, pero audioop se eliminó en Python 3.13. El paquete audioop-lts lo recupera. Si prefieres no depender de él, μ-law cabe en unas pocas líneas de NumPy:

import numpy as np

def linear_to_mulaw(pcm: np.ndarray) -> bytes:
    """16-bit signed PCM samples -> G.711 mu-law bytes."""
    x = pcm.astype(np.int32) >> 2                    # 14-bit magnitude range
    mask = np.where(x < 0, 0x7F, 0xFF)
    x = np.minimum(np.abs(x), 8158) + 33             # clip, then add the bias
    segment = np.floor(np.log2(x)).astype(np.int32) - 5
    code = (segment << 4) | ((x >> (segment + 1)) & 0x0F)
    return (code ^ mask).astype(np.uint8).tobytes()

def mulaw_to_linear(data: bytes) -> np.ndarray:
    """G.711 mu-law bytes -> 16-bit signed PCM samples."""
    u = ~np.frombuffer(data, dtype=np.uint8).astype(np.int32) & 0xFF
    segment, mantissa = (u >> 4) & 0x07, u & 0x0F
    magnitude = (((mantissa << 3) + 0x84) << segment) - 0x84
    return np.where(u & 0x80, -magnitude, magnitude).astype(np.int16)

Comprobamos las dos funciones contra audioop con todos los valores de entrada de 16 bits y los 256 códigos μ-law, y coinciden exactamente. Los codificadores no siempre coinciden entre sí en los límites de segmento (FFmpeg y audioop difieren en 512 de las 65.536 entradas), y no pasa nada: la diferencia es de un escalón en la curva y no se oye.

Errores que convierten a quien llama en ruido

La mayoría de los problemas con G.711 vienen de que los bytes son una cosa y el código cree que son otra.

  • La ley equivocada. μ-law decodificado como A-law, o al revés. El audio suena fuerte, áspero y a medias inteligible. Revisa el SDP o el mensaje start del flujo, no lo que supones del operador.
  • Tratar G.711 como PCM lineal de 8 bits. Una biblioteca que ve muestras de 8 bits y las supone lineales reproduce ruido con la voz enterrada debajo. Decodifica a PCM lineal de 16 bits antes de remuestrear, mezclar o pasar detección de actividad de voz.
  • Una cabecera de archivo dentro del flujo. Twilio dice que el media.payload de salida no debe llevar bytes de cabecera de archivo de audio. Envía la cabecera de 44 bytes de un WAV y tendrás un clic o una ráfaga de ruido al principio de cada mensaje. Quítala o pide al modelo de voz una salida cruda.
  • Una frecuencia de muestreo mal etiquetada. Audio de 8 kHz etiquetado como 16 kHz suena al doble de velocidad y una octava más agudo. Al revés suena como una cinta ralentizada. Los dos se decodifican sin errores, y por eso estos fallos sobreviven a la revisión de código.
  • Remuestrear más de una vez. Un pipeline que toma μ-law a 8 kHz, lo pasa a 16 kHz para un servicio, a 24 kHz para otro y luego otra vez a μ-law a 8 kHz añade latencia y artefactos de filtrado en cada paso. Elige formatos para que cada ruta de audio convierta una vez o ninguna.
  • Sobremuestrear para “mejorar” la calidad. Pasar audio de 8 kHz a 16 kHz no recupera nada por encima de 4 kHz. Las muestras nuevas son interpoladas. Puede servir para un modelo que solo acepta 16 kHz, pero no hará que la “f” de quien llama se parezca menos a una “s”.

Qué significa 8 kHz para los agentes de voz

La banda de 300 a 3.400 Hz es la parte de la voz que la mayoría necesita para entender palabras, y por eso las llamadas funcionan. También le falta buena parte de lo que separa “f” de “s” y “m” de “n”. Un modelo de voz a texto probado solo con audio limpio de navegador a 16 kHz puede rendir bastante peor con las mismas palabras en una línea telefónica. La guía de troncales SIP lo explica desde el lado del operador.

Tres hábitos ayudan:

  • Evalúa con audio telefónico. Graba llamadas de prueba a través de tu operador real, o al menos pasa tu conjunto de pruebas por una ida y vuelta a μ-law de 8 kHz, antes de comparar modelos. La guía de WER explica cómo leer los resultados sin engañarte.
  • Confirma los datos importantes. Repite nombres, correos y números de cuenta, y ofrece el teclado para cadenas largas de dígitos. Las pulsaciones DTMF no dependen de que el códec capte bien una consonante.
  • Envía la voz en el formato que pide la línea. Un texto a voz generado a 44,1 kHz y comprimido a μ-law de 8 kHz cuesta una conversión en cada fragmento. Si el modelo puede producir μ-law a 8 kHz directamente, pídeselo.

Algunas llamadas llevan audio de banda ancha. G.722 (“voz HD”) muestrea a 16 kHz, y las llamadas WebRTC suelen usar Opus. Pero en cuanto una llamada toca la red telefónica pública, cuenta con G.711.

G.711 con Cartesia

Los modelos de voz de Cartesia aceptan y producen G.711 de forma nativa, así que un pipeline telefónico no necesita su propio paso de códec.

Texto a voz. Sonic devuelve μ-law o A-law crudo a 8 kHz si se lo pides. Define el formato de salida en cualquier petición de TTS:

{
	"container": "raw",
	"encoding": "pcm_mulaw",
	"sample_rate": 8000
}

Usa pcm_alaw para líneas A-law. La documentación de formatos de salida recoge todas las codificaciones y frecuencias. Los fragmentos crudos del WebSocket de TTS llegan en base64, que es la misma forma que Twilio espera en media.payload, así que la guía de integración con Twilio los reenvía sin decodificarlos.

Voz a texto. Ink acepta μ-law y A-law por la API de streaming, incluido el endpoint con detección de turnos pensado para agentes de voz. Declara el formato al conectarte:

wss://api.cartesia.ai/stt/turns/websocket?model=ink-2&encoding=pcm_mulaw&sample_rate=8000&cartesia_version=2026-08-14

El servidor decodifica tus bytes exactamente según lo que declares, y puede que no devuelva un error si la declaración es incorrecta. La documentación de entrada de audio muestra cómo guardar un flujo y revisarlo con ffplay, lo que detecta una ley o frecuencia equivocada en segundos.

Managed Agents. Managed Agents contesta llamadas en números de Cartesia, Twilio o tu propio troncal SIP y gestiona el audio de la llamada por ti. Si en cambio conectas tu propia telefonía a un agente, el WebSocket de agentes acepta entrada mulaw_8000 directamente. Las llamadas de agente cuestan 0,06 $ por minuto, y puedes crear uno en el playground y llamarlo desde tu teléfono.

Si solo necesitas convertir unas cuantas grabaciones, FFmpeg ya lo hace bien y no necesitas ninguna API de voz.

Guías relacionadas

Preguntas frecuentes

¿Qué es el códec G.711?

G.711 es el estándar de la UIT-T para transmitir voz como modulación por impulsos codificados a 64 kbit/s: 8.000 muestras por segundo y 8 bits por muestra. Cada muestra se comprime con una curva logarítmica, μ-law o A-law, para que los sonidos suaves conserven más detalle que los fuertes. Se publicó por primera vez en 1972 y sigue siendo el códec por defecto en la mayoría de redes telefónicas y troncales SIP.

¿Qué diferencia hay entre μ-law y A-law?

Las dos son curvas de compansión de G.711 que meten una muestra lineal más ancha en 8 bits. μ-law (PCMU) se usa en Norteamérica y Japón; A-law (PCMA), en Europa y la mayoría de los demás países. Usan fórmulas distintas, así que un audio codificado con una suena distorsionado si lo decodificas con la otra. Cuando una llamada cruza entre las dos regiones, la red la convierte.

¿Qué son PCMU y PCMA?

Son los nombres RTP de G.711. PCMU es μ-law y usa el tipo de carga útil estático 0; PCMA es A-law y usa el tipo 8. Los dos funcionan con un reloj de 8.000 Hz y un canal. Los verás en ofertas SDP, en la configuración de tu PBX y en la de tu troncal SIP.

¿G.711 es lo mismo que PCM?

No exactamente. El PCM lineal guarda cada muestra como un número simple, normalmente de 16 bits. G.711 es PCM con compresión logarítmica: cada muestra ocupa 8 bits, la mitad que el PCM de 16 bits a la misma frecuencia. Para procesar audio G.711 en la mayoría de herramientas, primero lo decodificas a PCM lineal de 16 bits.

¿G.711 empeora el reconocimiento de voz?

Limita lo que el reconocedor puede oír. G.711 transmite más o menos de 300 a 3.400 Hz, así que los sonidos que viven más arriba, como la diferencia entre "f" y "s", cuestan más de distinguir. Sobremuestrear el audio no recupera esas frecuencias. Usa un modelo de voz a texto que acepte μ-law o A-law a 8 kHz directamente y pruébalo con grabaciones de tu línea telefónica real.