VoIP que suena bien

El reclamo llega siempre con las mismas palabras: "se escucha como robot". El gerente estaba cerrando un negocio por teléfono y la voz del otro lado se convirtió en un metalizado incomprensible. Lo primero que revisó el equipo de soporte fue el ancho de banda — y sobraba con creces. Ahí está la trampa de la voz IP: casi nunca es un problema de peso. Una llamada es de los tráficos más livianos que cruzan tu red, pero es de lejos el más impaciente. No pide espacio: pide puntualidad.

Puntualidad, no peso

Pongámosle números al "liviano". Una llamada G.711 — el códec clásico, sin compresión — consume 87,2 kbps por dirección con todo su overhead de Ethernet. Un solo stream de video HD de 5 Mbps equivale a 57 llamadas simultáneas. En cualquier enlace moderno, el volumen de la voz es anecdótico.

Lo que la voz exige es otra cosa. Piensa en un pedido de sushi a domicilio: no importa que el pedido sea pequeño, importa que llegue fresco y que los rolls lleguen en orden. La recomendación ITU-T G.114 fija el presupuesto: 150 ms como máximo de boca a oído (en un sentido). Hasta ahí la conversación fluye; pasado eso, los dos hablan encima del otro y la llamada se vuelve walkie-talkie. A eso súmale dos límites más: jitter bajo 30 ms (la variación entre llegadas de paquetes) y pérdida bajo 1 %.

¿Por qué tan estricto? Porque la voz viaja en RTP sobre UDP, sin retransmisiones. Es una decisión correcta: una palabra que llega tarde ya no sirve — reproducirla dos segundos después sería un eco absurdo, así que el paquete atrasado simplemente se descarta. TCP, con su "¿me repites?", es perfecto para archivos e inútil para conversar. La consecuencia práctica: en VoIP nadie te salva de una red impuntual. O llega a tiempo, o no llega.

Anatomía del paquete: 160 bytes de voz, 58 de papeleo

Abramos una llamada G.711 con bisturí. El códec muestrea el audio 8000 veces por segundo con 8 bits por muestra: 64 kbps de voz pura. El teléfono no manda muestra por muestra: junta 20 ms de audio — 160 bytes — y los despacha en un paquete. Eso da 50 paquetes por segundo por cada dirección de la llamada.

Cada uno de esos 160 bytes viaja con comitiva: 12 bytes de RTP (número de secuencia y timestamp, para reordenar y medir jitter), 8 de UDP y 20 de IP. Total en capa 3: 200 bytes, que a 50 paquetes por segundo son 80 kbps. Y en la LAN falta el sobre exterior: la trama Ethernet agrega 18 bytes más (cabecera y FCS), dejando 218 bytes en el cable — es decir, 87,2 kbps reales por dirección.

Fíjate en la proporción: el 26,6 % del paquete es burocracia. Y ojo con un clásico de terreno: la llamada es bidireccional, así que en un enlace simétrico reserva 87,2 kbps en cada sentido. Puedes jugar con códecs, paquetización y overhead de capa 2 en la calculadora de ancho de banda VoIP.

Códecs: la garganta de la llamada

El códec decide cuánto pesa la voz y cómo suena. Tres nombres cubren el 95 % de lo que verás en terreno:

• G.711 — el abuelo confiable (1972 y sigue firme). No comprime: 64 kbps de bitrate y calidad de teléfono fijo de toda la vida. Su MOS de 4,1 es la vara contra la que se mide el resto. Gasta, pero casi no agrega retardo ni CPU.
• G.729 — el ahorrador. Comprime la voz a 8 kbps (¡8 veces menos!) a cambio de un MOS de 3,9, algo de CPU y 15 ms de retardo algorítmico. Suena levemente "apretado", pero correcto. Nació para enlaces WAN caros y ahí sigue teniendo sentido.
• Opus — el moderno. Libre de regalías, bitrate variable y wideband: captura hasta el doble de espectro de la voz humana, y por eso su MOS de 4,3 supera al "teléfono de toda la vida". Es el códec de WebRTC, así que ya lo usas en cada videollamada de navegador.

Mira la paradoja de la tabla: comprimir 8 veces (G.729) solo reduce el consumo real a un tercio, no a un octavo. La culpa es de los 58 bytes de cabeceras, que no se comprimen: mientras más pequeño el payload, más pesa el papeleo en proporción. La comparación completa — con AMR-WB, G.722 y compañía — está en la calculadora de códecs de voz.

MOS y sus tres asesinos

El MOS (Mean Opinion Score) es la nota con que un oído humano califica la llamada, de 1 (inentendible) a 5 (perfecta). Sobre 4,0 nadie nota que es VoIP; bajo 3,5 empiezan los reclamos y la gente corta y vuelve a llamar. Los códecs parten con su nota de fábrica — la del termómetro — y la red solo puede bajarla desde ahí.

¿Y qué la empuja hacia abajo? Tres asesinos, en este orden de percepción:

• Retardo — el que más molesta y el primero que se nota. No degrada el sonido: degrada la conversación. Pasados los 150 ms de ida, los turnos se pisan; a 300 ms hablas por walkie-talkie. Y se acumula en silencio: códec, paquetización, colas, distancia (la fibra suma unos 5 ms por cada 1000 km) y el propio jitter buffer.
• Jitter — los paquetes salen cada 20 ms exactos, pero llegan a ritmo de baterista con jet lag: 18, 25, 19, 40… El jitter buffer los re-alinea, hasta que la variación supera lo que el buffer tolera y empieza a desechar los atrasados. Sobre 30 ms de jitter, ya está descartando.
• Pérdida — la más tolerada, gracias al PLC (packet loss concealment) que "rellena" huecos interpolando. Hasta 1 % en pérdidas sueltas casi no se oye; una ráfaga de 3 paquetes seguidos son 60 ms de sílaba desaparecida, y eso sí se nota.

La buena noticia: los tres se miden con una captura. Los propios paquetes RTP llevan número de secuencia y timestamp, así que Wireshark o tshark calculan jitter y pérdida por ti:

$ tshark -q -z rtp,streams -r llamada.pcap
========================= RTP Streams =========================
Src 10.1.20.14:16384 → Dst 190.98.x.x:18210   SSRC 0x4C3A11F2
Payload: g711U   Pkts: 2890   Lost: 6 (0,2 %)
Max jitter: 11,3 ms   Mean jitter: 4,1 ms     [OK]

¿Cuántas troncales? Erlang sin sufrir

Hasta aquí hablamos de una llamada. La otra pregunta de todo proyecto de telefonía es cuántas llamadas simultáneas debes soportar — o sea, cuántas troncales contratar. La respuesta tiene apellido desde 1917: Erlang B, la fórmula con que Agner Erlang dimensionó las centrales de Copenhague. La unidad es el Erlang: 1 Erlang equivale a una línea ocupada el 100 % del tiempo.

La intuición tramposa es pensar "5 Erlangs de tráfico = 5 líneas". No: las llamadas llegan cuando quieren, no coordinadas. A veces habrá 3 en curso, a veces 8. Erlang B calcula la probabilidad de que un pico de llamadas encuentre todas las troncales ocupadas — el bloqueo — y tú decides cuánto bloqueo tolera el negocio. Un ejemplo completo:

1. Mide el tráfico de la hora cargada. Tu central registra 100 llamadas por hora, de 3 minutos promedio: 100 × 3 = 300 minutos de conversación por hora. En Erlangs: 300 ÷ 60 = 5 Erlangs.
2. Fija la meta de servicio. Bloqueo ≤ 1 %: a lo más 1 de cada 100 llamadas de la hora punta escucha tono de ocupado.
3. Descarta la intuición. Con 5 troncales para 5 Erlangs, Erlang B da 28,5 % de bloqueo: más de una de cada cuatro llamadas rechazada. La aleatoriedad cobra caro.
4. Itera hacia arriba. Con 8 troncales el bloqueo baja a 7,0 %; con 10 llega a 1,84 % — cerca, pero aún no cumple.
5. Con 11 troncales: 0,83 %. Es la primera cantidad que baja del 1 %. Respuesta: 11 troncales — más del doble del tráfico promedio, y ese margen es exactamente lo que pagas por absorber los picos.
6. Tradúcelo a ancho de banda. Si la troncal es SIP con G.711: 11 × 87,2 kbps = 959 kbps ≈ 1 Mbps simétrico reservado para voz. Comprueba todo el ejercicio en la calculadora Erlang — y de paso mira Erlang C, que responde la pregunta hermana: cuántos agentes necesita un call center.

QoS: la voz viaja en primera clase

Ya sabes qué necesita la llamada (puntualidad) y cuántas caben (Erlang). Falta garantizarlo cuando el enlace se llena — porque se va a llenar, justo durante la llamada importante. La receta estándar tiene tres ingredientes:

• Marca la voz como EF (Expedited Forwarding, DSCP 46) lo más cerca posible del teléfono, y la señalización SIP como CS3. El conversor DSCP/QoS traduce entre todas las notaciones cuando el equipo pide el número en otra moneda.
• Cola prioritaria estricta para EF en cada salida que se congestione — típicamente el router WAN. Prioridad estricta significa que la voz sale primero, siempre; el policer que la acompaña evita que un tráfico mal marcado disfrazado de EF mate al resto. El detalle fino — colas, shaping, token buckets — está en la guía QoS en serio.
• Jitter buffer bien dimensionado en el extremo receptor. Es un trueque, no un ajuste gratis: cada milisegundo de buffer absorbe jitter pero se suma al retardo de boca a oído, o sea, gasta presupuesto G.114. Los adaptativos modernos se mueven solos entre 30 y 50 ms; dimensiona el tuyo y verifica el retardo total con la calculadora de jitter buffer.

Una advertencia de frontera: tu marca DSCP manda dentro de tu red, pero el ISP la suele borrar o reescribir al cruzar su borde. En enlaces de Internet la prioridad real la pones tú en tu router de salida, encolando antes del cuello de botella — no esperes que la nube respete tu EF.

Resumen operativo: reserva 87,2 kbps por llamada G.711 (o 39 con Opus) en cada sentido, dimensiona troncales con Erlang B en vez de adivinar, marca EF y encola con prioridad antes del cuello de botella. Con retardo bajo 150 ms, jitter bajo 30 y pérdida bajo 1 %, la llamada suena a persona y no a robot — y el gerente cierra su negocio sin enterarse de que existes, que es la definición de éxito en telefonía.