VoIP sobre VPN: Evita audio robótico con MTU, jitter y fundamentos de QoS

Un modelo mental que realmente predice fallos

Si recuerdas una sola cosa: la voz es un flujo en tiempo real que viaja sobre una red de mejor esfuerzo. Una VPN añade cabeceras, oculta las marcas QoS internas a menos que las preserves deliberadamente, y puede alterar el ritmo de los paquetes.
Los modos de fallo habituales no son misteriosos. Son física y colas.

Qué suele ser “audio robótico”

“Robótico” rara vez es un problema de “calidad” del códec. Es la pérdida de paquetes y la ocultación en acción.
El audio RTP llega en paquetes pequeños (a menudo 20 ms de audio por paquete). Pierdes unos cuantos, el jitter se dispara, el buffer de jitter se estira, el decodificador adivina y oyes al robot.
La voz puede sobrevivir cierta pérdida; simplemente no la oculta con elegancia.

La pila VoIP-sobre-VPN en un diagrama (conceptual)

Piensa en el paquete como un conjunto anidado de sobres:

• Interior: señalización SIP + medios RTP (a menudo UDP) con marcas DSCP que te gustaría conservar
• Luego: tu envoltura VPN (WireGuard/IPsec/OpenVPN) añade overhead y puede cambiar la MTU
• Exterior: colas del ISP e internet (donde vive el bufferbloat) y donde la QoS puede o no funcionar
• Endpoints: softphone o teléfono IP, y una PBX/ITSP

La rotura suele ocurrir en uno de tres lugares:
(1) tamaño (MTU/fragmentación),
(2) temporización (jitter/colas),
(3) priorización (QoS/DSCP y shaping).

Parafraseando a W. Edwards Deming: “Sin datos, solo eres otra persona con una opinión.” Trata los problemas de voz como incidentes: mide, aísla, cambia una variable y vuelve a medir.

Guía rápida de diagnóstico

Cuando el CEO dice “las llamadas están rotas”, no empiezas debatiendo códecs. Empiezas limitando el radio afectado y localizando la cola.
Aquí está el orden que encuentra las causas raíz rápidamente.

Primero: confirma si es pérdida, jitter o MTU

1. Revisa las estadísticas RTP en el cliente/PBX: % de pérdida, jitter, paquetes tardíos. Si no tienes esto, captura paquetes y calcúlalo (más tarde).
   Si ves incluso 1–2% de pérdida durante los momentos “robóticos”, trátalo como un problema de red hasta que se demuestre lo contrario.
2. Ejecuta una prueba rápida de path MTU a través de la VPN. Si PMTUD está roto, obtendrás paquetes grandes que se pierden, especialmente en VPNs basadas en UDP.
3. Revisa el retardo de cola bajo carga en el enlace más estrecho (generalmente la subida del usuario). El bufferbloat es el asesino silencioso de la voz.

Segundo: aísla dónde se rompe

1. Evita la VPN para una llamada de prueba (split tunnel o política temporal). Si la voz mejora drásticamente, céntrate en el overhead del túnel, MTU y manejo de QoS en los bordes del túnel.
2. Compara cableado vs Wi‑Fi. Si Wi‑Fi es peor, estás en terreno de contención de airtime y retransmisiones. Arregla eso por separado.
3. Prueba desde una red conocida buena (un circuito de laboratorio, otro ISP o una VM en la nube con un softphone). Si eso está limpio, el problema está en el borde del usuario.

Tercero: aplica las “soluciones aburridas”

• Configura explícitamente la MTU de la interfaz VPN y clampa TCP MSS donde sea relevante.
• Aplica gestión de colas inteligente (fq_codel/cake) en el verdadero cuello de botella y haz shaping ligeramente por debajo de la tasa de línea.
• Marca el tráfico de voz y priorízalo donde controles la cola (a menudo el borde WAN), no solo en tus sueños.

Broma #1: Una VPN es como una maleta—si sigues metiendo cabeceras extra, eventualmente la cremallera (MTU) se rinde en el peor momento.

MTU, MSS y fragmentación: por qué “robótico” a menudo significa “pérdida pequeña”

Los problemas de MTU no siempre parecen “no puede conectar”. Pueden parecer “conecta, pero a veces suena embrujado”.
Eso se debe a que la señalización puede sobrevivir mientras ciertos paquetes de medios o re-invites se pierden, o porque la fragmentación aumenta la sensibilidad a la pérdida.

Qué cambia cuando añades una VPN

Cada túnel añade overhead:

• WireGuard añade una cabecera UDP/IP externa más overhead de WireGuard.
• IPsec añade overhead ESP/AH (más posible encapsulado UDP para NAT‑T).
• OpenVPN añade overhead en espacio de usuario y puede añadir enmarcado extra según el modo.

El paquete interior que antes cabía con MTU 1500 puede ahora no entrar. Si tu ruta no permite fragmentación como crees, algo se pierde.
Y UDP no retransmite; simplemente te decepciona en tiempo real.

Path MTU discovery (PMTUD) y cómo falla

PMTUD depende de mensajes ICMP “Fragmentation Needed” (para IPv4) o Packet Too Big (para IPv6). Muchas redes bloquean o limitan la tasa de ICMP.
Resultado: envías paquetes demasiado grandes, los routers los descartan y tu emisor nunca se entera. Eso se llama “PMTUD black hole”.

Por qué RTP usualmente no es “demasiado grande” — pero igual sufre

Los paquetes de voz RTP suelen ser pequeños: decenas a un par de centenas de bytes de payload, más cabeceras. Entonces, ¿por qué los problemas de MTU afectan las llamadas?

• Señalización y cambios de sesión (SIP INVITE/200 OK con SDP, registros TLS) pueden ser grandes.
• La encapsulación VPN puede fragmentar incluso paquetes moderados, aumentando la probabilidad de pérdida.
• Los picos de jitter ocurren cuando fragmentación y reensamblado interactúan con colas congestionadas.
• Algunos softphones agrupan o envían UDPs más grandes en ciertas configuraciones (comfort noise, SRTP o ptime inusual).

Orientación accionable

• Para WireGuard, empieza con MTU 1420 si no estás seguro. No es magia; es un valor conservador que evita problemas comunes de overhead.
• Para OpenVPN, sé explícito con la MTU del túnel y clampa MSS para los flujos TCP que atraviesan el túnel.
• No “bajes la MTU en todas partes” a ciegas. Puedes arreglar una ruta y perjudicar otra. Mide y luego ajusta.

Jitter, bufferbloat y por qué las pruebas de velocidad engañan

Puedes tener 500 Mbps de bajada y aun así sonar como si llamaras desde un submarino. La voz necesita baja variación de latencia, no cifras para presumir.
El enemigo práctico más grande es el bufferbloat: colas sobredimensionadas en routers/modems que se llenan bajo carga y añaden cientos de milisegundos de retardo.

Jitter vs latencia vs pérdida de paquetes

• Latencia: cuánto tarda un paquete de extremo a extremo.
• Jitter: cuánto varía esa latencia paquete a paquete.
• Pérdida: paquetes que nunca llegan (o llegan demasiado tarde para importar).

Los códecs de voz usan buffers de jitter. Esos buffers pueden suavizar la variación hasta cierto punto, a costa de añadir retardo.
Cuando el jitter se vuelve feo, los buffers o crecen (aumentando retardo) o tiran paquetes tardíos (aumentando pérdida). En ambos casos: audio robótico.

Dónde nace el jitter

La mayor parte del jitter en incidentes VoIP-sobre-VPN no es “internet”. Es la cola del borde:

• Router doméstico del usuario con un buffer ascendente profundo
• Cortafuegos de sucursal corporativa que hace inspección y buffering
• CPU del concentrador VPN saturada causando retardo en la programación de paquetes
• Contención/retransmisiones Wi‑Fi (parece jitter y pérdida)

Gestión de colas que realmente funciona

Si controlas el cuello de botella, puedes arreglar la voz.
Los algoritmos de gestión de colas inteligentes (SQM) como fq_codel y cake evitan activamente que las colas crezcan sin límite y mantienen la latencia estable bajo carga.

El truco: debes hacer shaping un poco por debajo de la tasa real del enlace para que tu equipo, no el módem del ISP, sea el cuello de botella y por tanto controle la cola.
Si no lo haces, estás pidiendo educadamente al módem que se comporte. No lo hará.

Broma #2: Bufferbloat es lo que pasa cuando tu router atesora paquetes como si fueran antigüedades coleccionables.

Fundamentos de QoS/DSCP para voz a través de VPNs (y qué se pierde)

QoS no es una casilla mágica de “mejorarlo”. Es una forma de decidir qué se sacrifica primero cuando el enlace está congestionado.
Eso es todo. Si no hay congestión, QoS no cambia nada.

DSCP y el mito de “QoS extremo a extremo”

La voz suele marcar RTP como DSCP EF (Expedited Forwarding) y SIP como CS3/AF31 según tu política.
Dentro de tu LAN eso puede ayudar. A través de internet la mayoría de proveedores lo ignorará. A través de una VPN, puede que ni siquiera sobreviva la encapsulación.

Qué puedes controlar

• Borde LAN: prioriza la voz desde teléfonos/softphones hacia tu gateway VPN.
• Egreso WAN del gateway VPN: aplica shaping y prioridad a los paquetes exteriores que corresponden a flujos de voz.
• Borde de sucursal/usuario: si lo gestionas, despliega SQM y marca la voz localmente.

VPN en detalle: marcas internas vs externas

Muchas implementaciones de túnel encapsulan paquetes internos en un paquete exterior. El paquete exterior es lo que ve el ISP.
Si el paquete exterior no está marcado (o si está marcado pero luego se lo quitan), tu “EF” interno es solo decorativo.

El enfoque práctico:

• Clasifica la voz antes de cifrar cuando sea posible, luego aplica prioridad al flujo cifrado (cabecera exterior) en el egress.
• Preserva DSCP a través del túnel si tu equipo lo soporta y tu política lo permite.
• No confíes en Wi‑Fi WMM para salvarte si la cola de subida se está derritiendo.

Precaución con QoS: puedes empeorarlo

Una política QoS mala puede dejar sin recursos el tráfico de control, o crear micro‑picos y reordenamientos. La voz necesita prioridad, pero también estabilidad.
Mantén las clases simples: voz, interactivo, bulk. Luego aplica shaping.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas “ejecuta ahora”. Cada una incluye un comando, qué te dice la salida y qué decisión tomar.
Úsalas en endpoints Linux, gateways VPN o hosts de troubleshooting. Ajusta nombres de interfaz e IPs para tu entorno.

Tarea 1: Confirma la MTU de la interfaz del túnel VPN

cr0x@server:~$ ip link show dev wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Significado: wg0 MTU es 1420. Buen punto de partida conservador para WireGuard.
Decisión: Si la MTU es 1500 en un túnel, asume problemas a menos que hayas probado que la ruta lo soporta. Si el audio robótico se correlaciona con ciertas rutas, prueba MTU más bajas.

Tarea 2: Mide path MTU con ping “do not fragment” (IPv4)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1380 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=18.4 ms
1380 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=18.7 ms
1380 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=18.2 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Significado: El paquete de 1400 bytes (incluyendo cabeceras) pasa sin fragmentación.
Decisión: Aumenta -s hasta que falle para encontrar el máximo. Establece la MTU del túnel de forma segura por debajo de eso menos el overhead de encapsulación.

Tarea 3: Observa síntomas de fallo PMTUD (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1013ms

Significado: La MTU de tu interfaz local es 1420; el kernel se niega a enviar más grande con DF activado.
Decisión: Si las apps envían paquetes más grandes de todos modos (la encapsulación UDP VPN puede hacerlo), clampa o configura MTU/MSS para que no lo hagan.

Tarea 4: Revisa reglas de clamp TCP MSS (iptables)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i mss
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: Los SYN TCP tienen MSS clamped según PMTU.
Decisión: Si llevas SIP sobre TCP/TLS por la VPN y ves stalls o retransmisiones, habilita esto. No arregla RTP (UDP), pero estabiliza la señalización.

Tarea 5: Verifica marcas DSCP en paquetes salientes

cr0x@server:~$ sudo tcpdump -ni eth0 -vv udp and portrange 10000-20000 -c 5
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.112233 IP (tos 0xb8, ttl 63, id 44211, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
12:10:41.132244 IP (tos 0xb8, ttl 63, id 44212, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186

Significado: TOS 0xb8 corresponde a DSCP EF (46). Tu host está marcando RTP.
Decisión: Comprueba si la marca sobrevive la encapsulación y si tu cola WAN la respeta. Si desaparece en el paquete exterior, necesitas QoS en el egress del túnel, no esperanzas.

Tarea 6: Confirma DSCP en el paquete externo del VPN

cr0x@server:~$ sudo tcpdump -ni eth0 -vv udp port 51820 -c 5
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:12:03.220011 IP (tos 0x00, ttl 64, id 12001, offset 0, flags [DF], proto UDP (17), length 208) 203.0.113.5.51820 > 203.0.113.9.51820: UDP, length 180
12:12:03.240022 IP (tos 0x00, ttl 64, id 12002, offset 0, flags [DF], proto UDP (17), length 208) 203.0.113.5.51820 > 203.0.113.9.51820: UDP, length 180

Significado: Los paquetes externos no están marcados (tos 0x00). Incluso si el RTP interno es EF, el ISP solo ve el exterior.
Decisión: Aplica clasificación en el gateway VPN: identifica flujos de voz antes del cifrado (o por heurísticas de puerto/peer) y establece DSCP/prioridad en egress.

Tarea 7: Identifica el verdadero cuello de botella y el qdisc actual

cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Significado: fq_codel está activo. Eso es una buena línea base para latencia bajo carga.
Decisión: Si ves pfifo_fast o un qdisc profundo del proveedor en el borde WAN, planifica desplegar shaping + fq_codel/cake donde ocurre la congestión.

Tarea 8: Revisa estadísticas qdisc por drops/overlimits (problemas de shaping)

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 98234123 bytes 84521 pkt (dropped 213, overlimits 0 requeues 12)
 backlog 0b 0p requeues 12
  maxpacket 1514 drop_overlimit 213 new_flow_count 541 ecn_mark 0

Significado: Ocurrieron algunas caídas. Las caídas no siempre son malas—las caídas controladas pueden prevenir latencia masiva. Pero caídas + audio robótico sugiere que estás perdiendo RTP, no bulk.
Decisión: Añade clasificación para que la voz tenga prioridad (o al menos aislamiento), y asegúrate de que la tasa de shaping coincida con la subida real.

Tarea 9: Chequeo rápido de jitter y pérdida con mtr (línea base)

cr0x@server:~$ mtr -rwzc 50 203.0.113.9
Start: 2025-12-28T12:20:00+0000
HOST: server                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.0.2.1                         0.0%    50    1.1   1.3   0.9   3.8   0.6
  2. 198.51.100.1                      0.0%    50    8.2   8.5   7.9  13.4   1.1
  3. 203.0.113.9                       0.0%    50   19.0  19.2  18.6  26.8   1.4

Significado: Sin pérdida, latencia estable, bajo jitter (StDev). Buena línea base.
Decisión: Si ves pérdida en el salto 1 bajo carga, es tu LAN/Wi‑Fi/router. Si la pérdida empieza más adelante, es upstream—aun así quizá solucionable con shaping en tu borde.

Tarea 10: Comprueba si la CPU del gateway VPN causa retardo en la programación de paquetes

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (vpn-gw) 	12/28/2025 	_x86_64_	(8 CPU)

12:21:01     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
12:21:02     all   18.20    0.00   22.40    0.10    0.00   21.70    0.00    0.00    0.00   37.60
12:21:02       0   20.00    0.00   28.00    0.00    0.00   30.00    0.00    0.00    0.00   22.00

Significado: Softirq alto puede indicar procesamiento intensivo de paquetes (cifrado, forwarding).
Decisión: Si softirq está al máximo durante los problemas de llamadas, considera habilitar multiqueue, usar crypto más rápido, añadir CPU disponible o reducir overhead VPN (offloads).

Tarea 11: Inspecciona NIC offloads (pueden romper capturas, a veces el timing)

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'tso|gso|gro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Significado: Offloads están habilitados. Usualmente están bien, pero pueden confundir capturas de paquetes y en algunos casos interactuar mal con túneles.
Decisión: Para un troubleshooting preciso, deshabilita temporalmente GRO/LRO en un host de prueba y vuelve a probar. No deshabilites offloads al azar en gateways con mucho tráfico sin un plan.

Tarea 12: Revisa errores y drops de recepción UDP

cr0x@server:~$ netstat -su
Udp:
    128934 packets received
    12 packets to unknown port received
    0 packet receive errors
    4311 packets sent
UdpLite:
IpExt:
    InOctets: 221009331
    OutOctets: 198887112

Significado: Errores de recepción UDP son cero. Bien.
Decisión: Si los errores de recepción suben durante llamadas, podrías estar alcanzando límites de buffer de socket o drops del kernel; ajusta buffers, soluciona saturación de CPU o reduce la contención de tráfico.

Tarea 13: Verifica la tasa de paquetes SIP/RTP durante una llamada (chequeo de sentido común)

cr0x@server:~$ sudo tcpdump -ni any udp portrange 10000-20000 -ttt -c 10
tcpdump: listening on any, link-type LINUX_SLL2, snapshot length 262144 bytes
 0.000000 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.019884 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.020042 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.019901 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186

Significado: Tiempo entre paquetes alrededor de 20 ms sugiere ptime=20ms (común). Grandes huecos indican jitter o retrasos en la programación.
Decisión: Si el timing es irregular en el punto de captura cerca del emisor, investiga CPU del emisor/Wi‑Fi. Si es regular en el emisor pero irregular en el receptor, es red/colas.

Tarea 14: Identifica si el tráfico va por la VPN o la evita

cr0x@server:~$ ip route get 198.51.100.20
198.51.100.20 via 10.10.0.1 dev wg0 src 10.10.0.2 uid 1000
    cache

Significado: La ruta al endpoint de medios usa wg0.
Decisión: Si tu prueba de “evitar VPN” aún enruta por wg0, no evitaste nada. Arregla el policy routing/split tunnel y luego compara calidad de llamada.

Tarea 15: Confirma MTU en la interfaz WAN física (y detecta mismatch de jumbo)

cr0x@server:~$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Significado: La interfaz WAN es MTU estándar 1500.
Decisión: Si estás en PPPoE o ciertos enlaces celulares, la MTU WAN puede ser menor (1492, 1428, etc.). Eso te empuja a bajar la MTU del túnel.

Tarea 16: Detecta bufferbloat bajo carga con un ping simple mientras saturas la subida

cr0x@server:~$ ping -i 0.2 -c 20 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=210.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=245.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=198.1 ms

--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3812ms
rtt min/avg/max/mdev = 18.4/156.2/265.1/72.9 ms

Significado: La latencia salta masivamente bajo carga: clásico bufferbloat.
Decisión: Despliega SQM shaping en la subida y prioriza voz; no pierdas tiempo persiguiendo códecs.

Tres microhistorias corporativas desde las trincheras

Incidente #1: La suposición equivocada (MTU “no puede ser, usamos 1500 en todas partes”)

Una empresa mediana migró un centro de llamadas a softphones sobre una VPN full‑tunnel. Funcionó en el piloto. Luego lo desplegaron a unos cientos de agentes remotos.
En el plazo de un día, la cola del helpdesk se convirtió en un segundo centro de llamadas—pero con peor audio.

La primera suposición del equipo de red fue clásica: “MTU no puede ser; Ethernet es 1500 y la VPN está bien configurada.”
Se centraron en el proveedor SIP, luego culparon al Wi‑Fi doméstico y después intentaron cambiar códecs.
Las llamadas mejoraban de forma aleatoria, lo peor porque fomenta superstición.

El patrón que resolvió el caso: el audio robótico se disparaba en ciertos flujos—transferencias, llamadas de consulta y cuando el softphone renegociaba SRTP.
Ahí la señalización aumentaba, y en algunos escenarios la ruta del túnel requería fragmentación. ICMP “fragmentation needed” estaba bloqueado en el borde del usuario por una configuración de “seguridad”.
PMTUD black holes. Nada glamuroso. Muy real.

La solución fue aburrida y decisiva: establecer una MTU conservadora en el túnel, clamar MSS para señalización TCP y documentar “no bloquear todo ICMP” en la base de acceso remoto.
También añadieron una prueba de una página: ping DF a través del túnel a un endpoint conocido. Detectó regresiones después.

Lección: “1500 en todas partes” no es un diseño. Es un deseo.

Incidente #2: La optimización que salió mal (priorizar voz… acelerando todo)

Otra organización tenía un gateway VPN capaz y quería “calidad premium de voz.” Alguien activó aceleración hardware y fast‑path en el firewall de borde.
El throughput subió. La latencia en una prueba sintética bajó. Todos celebraron.

Dos semanas después, quejas: “Audio robótico solo durante grandes subidas de archivos.” Ese detalle importaba.
Bajo carga, el fast path evitaba partes de la pila QoS y de gestión de colas. El tráfico bulk y la voz aterrizaban en la misma cola profunda en el lado del WAN.
La aceleración mejoró el pico de throughput, pero eliminó el mecanismo que mantenía la latencia estable.

Los ingenieros hicieron lo típico: añadieron más reglas QoS. Más clases. Más matches. Empeoró.
La clasificación costaba CPU en el slow path, mientras que el fast path seguía pasando la mayor parte del tráfico a la misma cola del cuello de botella.
Ahora tenían complejidad y seguían con bufferbloat.

La solución final no fue “más QoS.” Fue: hacer shaping de la subida justo por debajo de la capacidad real, habilitar un qdisc moderno y mantener el modelo de clases simple.
Luego decidir si la aceleración era compatible con esa política. Donde no lo era, la voz ganó.

Lección: optimizar por throughput sin respetar el comportamiento de colas es construir una forma más rápida de sonar terrible.

Incidente #3: La práctica aburrida que salvó el día (tests estándar + control de cambios)

Una compañía global ejecutaba voz sobre IPsec entre sucursales y HQ. Nada sofisticado. La diferencia clave: trataban la voz como un servicio de producción.
Cada cambio de red tenía una checklist preflight y postflight, incluyendo un puñado de pruebas relevantes para VoIP.

Un viernes, un ISP cambió equipos de acceso en una oficina regional. Los usuarios notaron “ligero robot” en las llamadas.
El equipo local corrió las pruebas estándar: ping en reposo vs bajo carga de subida, pings DF para MTU y una comprobación rápida de DSCP en egress WAN.
No debatieron. Midieron.

Los datos mostraron que PMTUD estaba roto en el nuevo acceso, y que el buffer upstream era más profundo que antes. Dos problemas. Ambos accionables.
Bajaron la MTU del túnel ligeramente, habilitaron MSS clamping y ajustaron el shaping para mantener la latencia estable. Las llamadas se estabilizaron inmediatamente.

El lunes, escalaron al ISP con evidencia precisa: timestamps, umbral de fallo MTU y gráficos de latencia bajo carga.
El ISP arregló el manejo de ICMP más tarde. Pero la empresa no tuvo que esperar para recuperar voz usable.

Lección: la característica de fiabilidad más efectiva es una prueba repetible que realmente ejecutes.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: audio robótico durante subidas o uso compartido de pantalla

• Causa raíz: bufferbloat en upstream; paquetes de voz atrapados detrás de tráfico bulk en una cola profunda.
• Solución: habilitar SQM (fq_codel/cake) y shape ligeramente por debajo de la subida; añadir prioridad simple para RTP/SIP en egress WAN.

2) Síntoma: la llamada conecta, luego el audio cae o se vuelve cortado después de un minuto

• Causa raíz: PMTUD/MTU black hole activado por rekey, renegociación SRTP o aumento del tamaño en re-INVITE SIP.
• Solución: fijar MTU del túnel explícitamente; permitir ICMP “frag needed”/PTB; para señalización TCP, clamar MSS.

3) Síntoma: audio unidireccional (tú los oyes, ellos no te oyen)

• Causa raíz: problema de NAT traversal o enrutamiento asimétrico; RTP fijado a la interfaz equivocada; tiempos de espera/estado UDP en firewalls.
• Solución: asegurar settings NAT correctos (SIP ALG normalmente off), confirmar rutas, aumentar timeout UDP en dispositivos stateful y validar RTP simétrico si está soportado.

4) Síntoma: bien en cable, mal en Wi‑Fi

• Causa raíz: contención de airtime, reintentos o comportamiento power‑save; la VPN añade overhead y sensibilidad al jitter.
• Solución: mover llamadas a 5 GHz/6 GHz, reducir contención de canal, deshabilitar power save agresivo en dispositivos de voz, preferir cable para roles con muchas llamadas.

5) Síntoma: solo usuarios remotos en cierto ISP tienen problemas

• Causa raíz: shaping/upstream del ISP, comportamiento CGNAT, mal peering o filtrado ICMP que afecta PMTUD.
• Solución: reducir MTU del túnel, aplicar shaping en el borde del usuario si está gestionado, probar transporte/puerto alternativo y recolectar evidencia para escalar.

6) Síntoma: “QoS está habilitado” pero la voz degrada bajo carga

• Causa raíz: QoS configurado en LAN mientras la congestión está en WAN; o DSCP marcado en paquetes internos pero no en los externos del túnel.
• Solución: priorizar en la cola de egress que realmente está congestionada; mapear/clasificar voz a paquetes exteriores; verificar con tcpdump y estadísticas qdisc.

7) Síntoma: bursts esporádicos de robot, especialmente en horas pico

• Causa raíz: microbursts y oscilación de colas; contentión de CPU en el concentrador VPN; o congestión upstream.
• Solución: revisar softirq/CPU, habilitar pacing/SQM, asegurar suficiente headroom en gateway y evitar jerarquías de clases demasiado complicadas.

8) Síntoma: llamadas bien, pero “hold/resume” falla o transfers fallan

• Causa raíz: fragmentación de señalización SIP o problemas MTU que afectan mensajes SIP más grandes; a veces SIP sobre TCP/TLS afectado por MSS.
• Solución: clamar MSS, reducir MTU, permitir ICMP PTB y validar settings SIP (y deshabilitar SIP ALG si mangla paquetes).

Listas de verificación / plan paso a paso

Paso a paso: estabiliza VoIP sobre VPN en una semana (no un trimestre)

1. Elige un usuario representativo que falle y reproduce el problema a demanda (subir archivos mientras estás en llamada suele ser suficiente).
   Sin reproducibilidad, no hay progreso.
2. Recopila estadísticas de voz (desde softphone/PBX): jitter, pérdida, concealment, RTT si está disponible.
   Decide: ¿motivado por pérdida (red) vs CPU (endpoint) vs señalización (transporte SIP/MTU)?
3. Confirma el enrutamiento: asegúrate de que los medios realmente atraviesan la VPN cuando crees que lo hacen. Arregla confusión de split tunnel temprano.
4. Mide path MTU a través del túnel usando pings DF a endpoints conocidos.
   Decide una MTU segura (conservadora vence a teórica).
5. Establece MTU del túnel explícitamente en ambos extremos (y documenta por qué).
   Evita el ajuste “auto” a menos que lo hayas probado en todos los tipos de acceso (banda ancha doméstica, LTE, Wi‑Fi de hotel, etc.).
6. Clampa TCP MSS en el túnel para flujos TCP reenviados (SIP/TLS, provisioning, management).
7. Encuentra el verdadero cuello de botella (usualmente la subida). Usa ping‑under‑load para confirmar regresión por bufferbloat.
8. Despliega SQM shaping en el cuello de botella, ligeramente por debajo de la tasa de línea, con fq_codel o cake.
9. Mantén las clases QoS simples y prioriza la voz solo donde importa: la cola de egress.
10. Verifica el manejo DSCP con capturas: marca interna, marca externa y si la cola la respeta.
11. Re-prueba el caso original (llamada + subida) y confirma mejoras en jitter/pérdida.
12. Despliega gradualmente con un grupo canario y un plan de rollback. Los cambios en voz son visibles para usuarios al instante; trátalo como un deploy en producción.

Checklist operativa: cada vez que toques VPN o WAN

• Registra las MTU actuales (WAN + túnel) y políticas qdisc/shaping.
• Ejecuta la prueba MTU DF through tunnel a un endpoint estable.
• Ejecuta ping en reposo vs ping bajo carga para medir regresión por bufferbloat.
• Captura 30 segundos de RTP durante una llamada de prueba y revisa pérdidas/picos de jitter.
• Confirma DSCP en el paquete exterior en el lado WAN (si dependes de marcado).
• Revisa softirq de CPU del gateway bajo carga.

Datos interesantes y contexto histórico

• Dato 1: RTP (Real-time Transport Protocol) se estandarizó a mediados de los 90 para transportar medios en tiempo real sobre redes IP.
• Dato 2: SIP creció en popularidad en parte porque se parecía a HTTP para llamadas—basado en texto, extensible—ideal para funciones, a veces doloroso para MTU.
• Dato 3: Gran parte del dolor de PMTUD viene de prácticas de filtrado ICMP que se hicieron comunes como respuesta de seguridad en la era temprana de internet.
• Dato 4: Los despliegues tempranos de VoIP a menudo confiaban en marcas DiffServ (DSCP) dentro de redes empresariales, pero “QoS a través del internet público” nunca fue ampliamente fiable.
• Dato 5: La adopción de VPN creció para trabajo remoto, y las quejas sobre la calidad de voz siguieron porque los enlaces de consumo suelen ser el segmento más estrecho y con más bufferbloat.
• Dato 6: WireGuard se hizo popular en parte porque es ligero y rápido, pero “crypto rápido” no cancela “colas malas”.
• Dato 7: Bufferbloat se identificó y nombró porque el equipo de consumo venía con buffers demasiado grandes que mejoraban benchmarks de throughput mientras destrozaban aplicaciones sensibles a latencia.
• Dato 8: Qdiscs modernos de Linux como fq_codel se desarrollaron específicamente para mantener la latencia acotada bajo carga, importante para voz y juegos.
• Dato 9: Muchos diseños VPN empresariales históricamente asumieron un underlay de 1500 bytes; PPPoE, LTE y apilamiento de túneles hicieron esa suposición cada vez más frágil.

Preguntas frecuentes

1) ¿Por qué el audio es “robótico” y no solo bajo o retrasado?

Porque estás oyendo concealment por pérdida de paquetes. El decodificador adivina tramas faltantes. Volumen bajo o silencioso suele ser ganancia o problema de dispositivo; robótico suele ser pérdida/jitter.

2) ¿Qué porcentaje de pérdida se vuelve audible en VoIP?

Depende del códec y del concealment, pero incluso ~1% de pérdida puede notarse, especialmente si es en ráfagas. Un 0.1% estable puede estar bien; 2% en ráfagas a menudo no.

3) ¿La MTU es solo un problema de TCP? RTP es UDP.

La MTU también afecta a UDP. Si los paquetes exceden la path MTU y PMTUD está roto, se descartan. Además, la fragmentación aumenta la sensibilidad a pérdida y el jitter cuando los fragmentos compiten en las colas.

4) ¿Debo simplemente fijar MTU a 1200 y ya?

No. Reducirás eficiencia y podrías romper otros protocolos o rutas innecesariamente. Mide path MTU, elige un valor seguro y documéntalo. Conservador, no extremo.

5) ¿Marcar DSCP ayuda en internet público?

A veces dentro del dominio de un ISP, a menudo no de extremo a extremo. La ganancia confiable es priorizar donde controlas la cola: tu egress WAN y bordes gestionados.

6) ¿Puede QoS arreglar pérdida de paquetes por mal ISP?

QoS no crea ancho de banda. Puede prevenir pérdidas/jitter auto infligidos al gestionar tus propias colas. Si el ISP está descartando upstream, necesitas mejor ruta o proveedor distinto.

7) ¿Por qué solo falla cuando alguien sube un archivo?

La subida satura el upstream. Las colas upstream se hinchan, la latencia y jitter explotan y el RTP llega tarde. Las pruebas de velocidad rara vez lo detectan porque premian buffers profundos.

8) ¿WireGuard es automáticamente mejor que OpenVPN para voz?

WireGuard suele tener menos overhead y es más fácil de razonar, pero la calidad de voz depende sobre todo de corrección MTU, gestión de colas y enrutamiento estable. Puedes romper voz en cualquier VPN.

9) ¿Cuál es la política QoS más simple que realmente funciona?

Haz shaping del WAN un poco por debajo de la tasa real y prioriza la voz (RTP) por encima del bulk. Mantén el modelo de clases pequeño. Verifica con estadísticas qdisc y pruebas de llamadas reales.

10) ¿Cómo demuestro que es MTU y no “el códec”?

Reproduce con pings DF para ver umbrales y observa fallos alrededor de tamaños de paquete específicos; correlaciona con eventos de llamada que aumentan señalización; corrige MTU y verifica que el problema desaparece sin cambiar códecs.

Pasos prácticos siguientes

Si quieres llamadas que suenen humanas, trata la voz como un SLO de latencia, no como una vibra.

1. Ejecuta la guía rápida de diagnóstico en un usuario afectado y captura evidencia: MTU, jitter bajo carga, comportamiento DSCP.
2. Fija la MTU del túnel explícitamente (empieza conservador), y clampa MSS para rutas de señalización TCP.
3. Despliega SQM shaping en el cuello de botella uplink con fq_codel/cake y prioriza la voz en esa cola.
4. Verifica con mediciones (estadísticas qdisc, tcpdump DSCP, mtr y estadísticas de jitter/pérdida del cliente), no con sensaciones.
5. Documenta: la MTU elegida, por qué se eligió y las pruebas de regresión. El tú del futuro estará cansado e indiferente.

La mayoría de los “misterios” VoIP‑sobre‑VPN son solo redes haciendo cosas de red. Haz los paquetes más pequeños, mejora las colas y haz que tus prioridades sean reales donde ocurre la congestión.