Saltearse al contenido

Parte 3: El Mundo Real: Redes, Calidad y Troubleshooting

Problemas de calidad VoIP, cálculos de ancho de banda y soluciones NAT - Parte 3

🚀 Presentación 3 (Parte 3): Fundamentos VoIP para la Era IA

Sección titulada «🚀 Presentación 3 (Parte 3): Fundamentos VoIP para la Era IA»

💡 El Mundo Real: Redes, Calidad y Troubleshooting

Sección titulada «💡 El Mundo Real: Redes, Calidad y Troubleshooting»

1. La Teoría vs. La Realidad: Cuando las Redes Atacan

Sección titulada «1. La Teoría vs. La Realidad: Cuando las Redes Atacan»

En un entorno de laboratorio perfecto, cada llamada es cristalina. Pero en el mundo real, internet es un lugar caótico. La voz, al viajar en paquetes, es susceptible a los mismos problemas que afectan a cualquier otro dato. Para la VoIP, hay tres enemigos mortales que debemos conocer y combatir.


Estos son los culpables detrás del 99% de los problemas de “mala calidad de audio”.

  • 1. Latencia (El Eco Interminable)

    • ¿Qué es? El tiempo que tarda un paquete de voz en viajar desde tu boca hasta el oído de la otra persona. Se mide con el RTT (Round Trip Time), el tiempo de ida y vuelta.
    • La Analogía: Es como una conversación con un corresponsal de noticias internacional por satélite. Hay un retraso notable que hace que se interrumpan el uno al otro.
    • El Límite Humano: El cerebro humano puede tolerar hasta unos 200-250 milisegundos (ms) de RTT. Por encima de 300ms, la conversación se vuelve antinatural y frustrante.
    • Comando para medirla: ping <direccion_ip_del_otro_extremo>
  • 2. Jitter (La Conversación Tartamuda)

    • ¿Qué es? Es la variación en la latencia. No es el retraso en sí, sino la imprevisibilidad de ese retraso. Algunos paquetes llegan en 20ms, otros en 80ms, otros en 40ms.
    • La Analogía: Es como hablar con alguien que de repente acelera, luego frena, luego habla a trompicones. Es imposible seguir el ritmo.
    • ¿Por qué es tan malo? Los teléfonos y sistemas VoIP tienen un pequeño “buffer de jitter” para reordenar los paquetes que llegan fuera de secuencia. Si la variación es demasiado grande, el buffer se desborda o se vacía, y escuchas audio entrecortado o con “glitches”.
    • El Límite: Un jitter superior a 100ms es generalmente inaceptable y destroza una conversación.
  • 3. Pérdida de Paquetes (Las Palabras que Desaparecen)

    • ¿Qué es? Es exactamente lo que parece: paquetes de audio que se pierden en el camino y nunca llegan a su destino.
    • ¿Por qué pasa? Por congestión en la red, malos cables, routers sobrecargados, etc.
    • La Clave Técnica: RTP, el protocolo que transporta la voz, usa UDP (User Datagram Protocol). A diferencia de TCP (usado para la web y el email), UDP no garantiza la entrega. Prioriza la velocidad sobre la fiabilidad. Si un paquete se pierde, no se retransmite. Simplemente… desaparece.
    • El Impacto: Escuchas sílabas o palabras enteras que se desvanecen. Una pérdida de paquetes superior al 1-2% es muy notable.

3. La Verdadera Huella Digital: Calculando el Ancho de Banda Real

Sección titulada «3. La Verdadera Huella Digital: Calculando el Ancho de Banda Real»

Un error común es pensar que el ancho de banda de una llamada es solo el del códec. La realidad es que cada paquete de audio lleva consigo una “mochila” de información de red.

La Fórmula: Ancho de Banda Total = Carga Útil del Códec + Overhead de Protocolos

Veamos un ejemplo con el códec G.711:

  • Carga Útil del Códec: 64 Kbps
  • Overhead de la Mochila:
    • Encabezado RTP: ~4.8 Kbps
    • Encabezado UDP: ~3.2 Kbps
    • Encabezado IP: ~8 Kbps
    • Encabezado Ethernet: ~15.2 Kbps
    • Total Overhead: ~31.2 Kbps

Cálculo Final: 64 Kbps (Voz) + 31.2 Kbps (Mochila) = ~95.2 Kbps por llamada

Lección Práctica: Cuando planifiques la capacidad de tu red, nunca uses solo el valor del códec. Siempre calcula el consumo real con el overhead. Una conexión que “debería” soportar 15 llamadas G.711, en realidad podría soportar solo 10. Para facilitar este cálculo, existen herramientas en línea como el Asterisk Guru Bandwidth Calculator.


4. El Gran Muro: Firewalls y NAT (Network Address Translation)

Sección titulada «4. El Gran Muro: Firewalls y NAT (Network Address Translation)»

NAT es el culpable del problema más común y frustrante en VoIP: el audio en una sola dirección.

  • El Problema Original: NAT se creó para que muchos dispositivos en una red privada (con IPs como 192.168.1.x) pudieran compartir una única IP pública para salir a internet.

  • ¿Por qué rompe la VoIP?

    1. Tu teléfono (en 192.168.1.50) envía un INVITE a Asterisk.
    2. Dentro del “contrato” SDP de ese INVITE, tu teléfono anuncia: “¡Hey! ¡Envíame el audio a 192.168.1.50!”.
    3. Asterisk, que está en internet, recibe esa instrucción y diligentemente intenta enviar el audio RTP a 192.168.1.50… una dirección privada que no existe en la red pública.
    4. Resultado: Tú puedes escuchar a la otra persona (porque tu router “abrió” una puerta de salida), pero ella no puede escucharte a ti (porque su audio se está perdiendo al intentar llegar a tu IP privada).
  • Las Soluciones (El Kit de Supervivencia de PJSIP):

    • Configuraciones de NAT en PJSIP: Asterisk tiene parámetros en el endpoint como force_rport,comedia que le dicen: “Ignora la IP que el teléfono anuncia en el SDP y, en su lugar, responde a la dirección IP y puerto de donde realmente vino el paquete”. Esto soluciona la mayoría de los casos simples.
    • STUN (Session Traversal Utilities for NAT): Un servidor STUN es un servicio público que tu teléfono puede consultar para preguntarle: “Oye, ¿cuál es mi IP pública?”. Luego puede anunciar esa IP pública en el SDP.
    • TURN (Traversal Using Relays around NAT): Cuando todo lo demás falla (especialmente con firewalls muy restrictivos), un servidor TURN actúa como un intermediario o “relé” de medios. Ambos teléfonos envían su audio RTP al servidor TURN, y este se lo reenvía al otro. Garantiza la conexión, pero a costa de mayor latencia y consumo de recursos.
    • ICE (Interactive Connectivity Establishment): Es el estándar moderno que usa PJSIP y WebRTC. ICE es un framework inteligente que prueba todas las estrategias (conexión directa, STUN, TURN) simultáneamente y elige el camino más eficiente que funcione.

5. ¿Cómo Medimos la Calidad? El MOS (Mean Opinion Score)

Sección titulada «5. ¿Cómo Medimos la Calidad? El MOS (Mean Opinion Score)»

La calidad de una llamada puede ser subjetiva. Para estandarizarla, se creó el MOS.

  • ¿Qué es? Una escala del 1 al 5 que representa la calidad percibida de la voz en una llamada.
  • La Escala:
    • 5: Excelente. Calidad de CD. Indistinguible del original.
    • 4: Bueno. Calidad de línea telefónica fija. Muy claro. (G.711 tiene un MOS de ~4.1).
    • 3: Aceptable. Calidad de llamada móvil con buena señal. (G.729 tiene un MOS de ~3.9).
    • 2: Pobre. Conversación difícil de entender.
    • 1: Inaceptable. Imposible comunicarse.

El MOS es una métrica clave para el monitoreo de la red. Si el MOS promedio de tus llamadas comienza a bajar, es una señal de alerta de que tienes problemas de latencia, jitter o pérdida de paquetes en tu red.


6. Conexión Final con la IA: La Fragilidad de la Inteligencia

Sección titulada «6. Conexión Final con la IA: La Fragilidad de la Inteligencia»

Hemos visto los problemas que afectan a la voz humana. Ahora, pensemos en cómo afectan a un oído artificial, que es mucho menos tolerante a los errores.

  • Latencia alta: No afecta directamente a la IA, pero degrada la experiencia del usuario, generando frustración que la IA de sentimiento sí detectará.
  • Pérdida de Paquetes: CATASTRÓFICO. Si se pierde la sílaba “no” en la frase “yo no autorizo el cargo”, la IA transcribirá lo contrario al significado real. Un 1% de pérdida de paquetes puede ser un 100% de error en la intención.
  • Jitter: PELIGROSO. El audio entrecortado o distorsionado puede hacer que la IA confunda fonemas similares (“caja” vs “tasa”). Esto introduce errores sutiles pero críticos en la transcripción.
  • Problemas de NAT (Audio Unidireccional): INUTILIZA EL ANÁLISIS. Si solo grabamos el audio del agente y no el del cliente, nuestro sistema de análisis de sentimiento solo analizará a nuestro propio personal. Es un sistema ciego.

La Lección Definitiva: La integración de IA en la VoIP traslada el estándar de calidad de “suficientemente bueno para un humano” a “matemáticamente preciso para una máquina”. Una red estable y de alta calidad ya no es una recomendación, es el requisito fundamental para que nuestra inversión en inteligencia artificial tenga sentido.


Con estos tres pilares de conocimiento, ya no solo saben qué es Asterisk, sino que entienden cómo funciona el ecosistema VoIP a un nivel profundo. Están listos para enfrentarse a los problemas del mundo real y para construir su primera PBX en el próximo taller, sabiendo exactamente qué sucede detrás de cada línea de configuración.