Cómo calcular y controlar el consumo de ancho de banda VoIP en una red WAN

El consumo de ancho de banda de VoIP en una red de área amplia (WAN, por sus siglas en inglés) es uno de los factores más importantes a tener en cuenta al construir una infraestructura de VoIP. Si no se toman en cuenta los requisitos de ancho de banda de VoIP, se limitará gravemente la confiabilidad del sistema y se pondrá una gran carga en la infraestructura de la WAN. En este artículo, aprenderás cómo lidiar con los diferentes algoritmos de compresión de audio y las topologías de WAN. Una vez que aprendas a controlar y calcular la utilización del ancho de banda, podrás establecer la cantidad adecuada de asignación de ancho de banda para la calidad de servicio (QoS).

Tipos de códecs de VoIP

Comenzaremos con los códecs (compresión/descompresión) de VoIP más comunes y examinaremos sus características de ancho de banda y calidad. Ten en cuenta que MOS significa calificación media de opinión, que es una calificación subjetiva de la calidad del sonido.

Dealing with packet overhead

Existe un impuesto por el sobrecabezado de paquetes que debe considerarse además del ancho de banda bruto utilizado por los diversos códecs. También debemos tener en cuenta el sobrecabezado de paquetes de las diferentes tipos de conexiones. Dado que VoIP nunca consume más de 90 kbps en una línea Ethernet, casi nunca hay problemas de ancho de banda en una red de área local (LAN). Incluso una red conmutada de 10 mbps puede manejar 100 canales simultáneos de los códecs más pesados. El problema surge cuando los paquetes de VoIP deben atravesar la WAN o Internet, donde el ancho de banda está limitado típicamente de 64 kbps a 1,536 kbps en una conexión T1. Aunque muchas conexiones de banda ancha DSL o por cable prometen un rendimiento de 6 mbps o más, su velocidad de transmisión es el factor limitante, de 128 kbps a 1,000 kbps. Para conexiones limitadas a 64 kbps (a menudo el caso de cadenas minoristas) y que también deben soportar aplicaciones de datos, se deben tomar medidas especiales para hacer posible la VoIP.

El sobrecabezado de paquetes puede ser un problema grave si no se controla. Esto se debe a que se deben enviar al menos 50 paquetes de VoIP por segundo para mantener el retraso de paquetización al mínimo. Dado que los encabezados de IP, UDP y RTP en cada paquete de VoIP tienen 40 bytes (320 bits), 50 de ellos en un segundo significan que consumirá 16 kbps. El mecanismo de transporte físico y los protocolos que utilizan aumentarán aún más el sobrecabezado.

En una conexión de trama principal o T1, el sobrecabezado de paquete típico es de 18.8 kbps por canal. Esto puede no ser un gran problema para códecs de 64 kbps como G.711 o G.722, ya que es relativamente pequeño en comparación con la carga útil. Pero para códecs de 8 a 32 kbps, como G.729 y G.722.1, 18.8 kbps es enorme en comparación. El sobrecabezado de paquete para conexiones VPN IPSEC de sitio a sitio es mucho más grave. El sobrecabezado puede ir desde 35 kbps hasta 45 kbps por canal dependiendo del tipo de VPN implementada. Esto significa que cada llamada realizada a través de un túnel VPN recibe un impuesto de ~40 kbps encima de la velocidad de bits del códec.

Manejo del impuesto por el sobrecabezado de paquetes

Existen dos formas principales de manejar el impuesto por el sobrecabezado de paquetes, dependiendo de la topología de red. Podemos intentar reducir el tamaño de los encabezados de paquete con compresión o podemos agrupar múltiples flujos de voz en un solo paquete. La compresión de encabezados de paquetes puede reducir los encabezados de IP/UDP/RDP en un factor de 10 a 20 veces, pero solo funciona con conexiones de trama principal o protocolo punto a punto de enlace múltiple (MP, por sus siglas en inglés), y ambos lados de la conexión deben estar configurados para ello. La compresión de encabezados de paquetes es la solución ideal siempre que sea posible.

Cómo garantizar la validación local de los clientes en un dominio multi-sitio

Las conexiones MPLS no pueden usar compresión de encabezados porque no son conexiones punto a punto y deben pasar por una gran nube virtual a través de múltiples proveedores. MPLS tiene la ventaja de una topología de malla, donde cualquier sitio puede comunicarse directamente con cualquier otro sitio sin pasar por algún sitio central. Esto puede reducir la latencia en algunas situaciones. Las llamadas VoIP a través de Internet tampoco pueden usar compresión de encabezados de paquetes. Las conexiones VPN IPSec de sitio a sitio no solo pueden usar compresión de encabezados de paquetes, sino que también exacerban la situación al duplicar el sobrecabezado. La única solución que podemos utilizar para la topología de MPLS y VPN WAN es utilizar el agrupamiento de paquetes de VoIP.

El agrupamiento de VoIP es un método de tomar múltiples flujos de VoIP y fusionarlos en un solo flujo que comparte un solo encabezado de paquete. Entonces, en lugar de tener que multiplicar la velocidad de bits de sobrecabezado de paquete por el número de canales, es un costo fijo único para cualquier número de canales con la misma fuente y destino. Esto solo se puede hacer utilizando una pasarela de Asterisk PBX de código abierto en cada sitio remoto.

Este método funciona incluso si estás utilizando una PBX de VoIP y teléfonos IP propietarios, siempre y cuando puedan hablar los protocolos SIP o H.323. Asterisk puede traducirlos a su propio protocolo eficiente IAX2, que admite agrupamiento de canales, y volver a traducir a SIP o H.323 una vez que sale de la conexión de ancho de banda limitado. El agrupamiento de VoIP es la solución ideal siempre que no se pueda utilizar la compresión de encabezados de paquetes. En futuros artículos, veremos cómo implementar estas soluciones.

Casos de estudio y ejemplos

Consideremos un ejemplo en el que la topología de la WAN consiste principalmente en conexiones de trama principal o MP de 64 a 256 kbps. En este escenario, debemos utilizar principalmente códecs estrebanda G.729 de 8 kbps, y la compresión de encabezados es esencial. Podemos proporcionar soporte para un teléfono de conferencia de alta gama Polycom HD Voice que utiliza el códec G.722.1 Siren7 a 32 kbps, lo cual es justificable cuando se está llevando a cabo una reunión importante. Aquí tienes un desglose de cuánto ancho de banda admite un número dado de canales.

Aunque el retorno de la inversión (ROI) en el agrupamiento de canales no parece ser mucho como para justificar la construcción de una pasarela de Asterisk, podemos utilizar ese mismo dispositivo Linux como un proxy transparente y un compresor de contenido HTTP. Esto nos permite obtener mucho más provecho de nuestra conexión WAN. A veces podemos reducir el consumo de ancho de banda de datos en un factor de 4 o 10.

Ahora, veamos qué sucede en una topología de WAN MPLS o Internet.

Cuál es la mejor opción de protocolo de enrutamiento para una red empresarial

Como puedes ver, el agrupamiento de VoIP es la única forma de controlar el uso del ancho de banda para los códecs de 8 y 32 kbps, y una pasarela de Asterisk PBX es la única forma de resolver este problema.

Finalmente, veamos qué sucede en una topología de WAN de sitio a sitio con IPSEC VPN. Ten en cuenta que solo estamos utilizando un túnel IPSEC y no estamos utilizando GRE en la parte superior, para no aumentar aún más el sobrecabezado de paquete.

Como puedes ver, el agrupamiento de VoIP es la única forma de controlar el uso del ancho de banda para los códecs de 8 y 32 kbps, y una pasarela de Asterisk PBX es la única forma de resolver este problema.

Si deseas realizar tus propios cálculos, la versión descargable de este artículo incluye una plantilla de Excel que puedes utilizar.

Los 8 pasos para solucionar problemas de red y sistemas

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Redes, allí encontraras muchos artículos similares a Cómo calcular y controlar el consumo de ancho de banda VoIP en una red WAN , tenemos lo ultimo en tecnología 2023.