Blog de Amazon Web Services (AWS)

Comunicación en Tiempo Real con CrazyCall usando AWS Global Accelerator

Por Pratik R. Mankad, Sr.Network Arquitecto de Soluciones

 

En el sector de las telecomunicaciones, la comunicación en tiempo real (RTC) se refiere a sesiones de medios en vivo entre dos puntos finales (endpoints) con latencia y fluctuación (jitter) mínimas. Estas sesiones pueden ser para voz, mensajería instantánea o video en directo.

Cada una de estas soluciones consiste en uno o más intercambios de mensajes de señalización que controlan la llamada (por ejemplo, autenticación, autorización y control de acceso, transcodificación o almacenamiento en búfer) y una o más transmisiones multimedia que transportan audio, vídeo u otros datos. Juntos, estas secuencias forman una sesión, que se coloca dentro de los paquetes del protocolo de Internet (IP).

Para aplicaciones que no son en tiempo real como descargar un archivo o acceder a un navegador, los retrasos, son en sí, inconvenientes, pero no dañan el resultado real. Las aplicaciones en tiempo real, por el contrario, son sensibles al tiempo. Los retrasos que podrían haber sido aceptables para aplicaciones que no son en tiempo real pueden degradar el rendimiento y la experiencia del usuario hasta el punto en que la aplicación no se pueda utilizar. Por ejemplo, imagine una conversación telefónica donde usted tiene que esperar un segundo o dos antes de recibir respuesta a declaraciones o preguntas. Está claro que eso no sería aceptable.

Las aplicaciones en tiempo real funcionan mejor cuando la conexión a Internet subyacente reduce la latencia y la fluctuación. El rendimiento de una red fiable y consistente ayuda a garantizar que los datos en tiempo real dentro de los paquetes IP se entreguen rápidamente y en el orden correcto. AWS Global Accelerator es un servicio que ayuda a reducir la latencia y la fluctuación de la red.

Global Accelerator mejora la disponibilidad y el rendimiento de las aplicaciones para usuarios locales o globales. Proporciona direcciones IP estáticas que actúan como puntos de entrada fijos para sus aplicaciones en una o varias regiones de AWS. Estos puntos de entrada fijos incluyen Balanceadores de Carga de aplicaciones (Application Load Balancers), Balanceadores de Carga de Red (Network Load Balancers), o incluso instancias de cómputo Amazon Elastic Compute Cloud (Amazon EC2).

El servicio Global Accelerator utiliza la red global de AWS (AWS Global Network) para optimizar la ruta de los usuarios a las aplicaciones, mejorando el rendimiento del tráfico TCP y UDP. Global Accelerator también supervisa continuamente el estado de los endpoints de la aplicación, detecta un endpoint en estado no disponible y redirige el tráfico a endpoints con mayor disponibilidad en menos de un minuto.

En este blog-post se describe cómo CrazyCall (una empresa de software para llamadas basada en la nube), mejora el rendimiento de su aplicación en tiempo real mediante el uso de Global Accelerator.

El software de CrazyCall permite a sus clientes crear fácilmente una línea de ayuda fiable, ponerse en contacto rápidamente con los clientes y atraer clientes potenciales directamente desde sitios web. CrazyCall sirve a empresas de todo tipo, centrándose en las pequeñas y medianas empresas que quieren utilizar la potencia del sistema telefónico y llegar a todo su público. CrazyCall se esfuerza en proveer una experiencia de alta calidad a todos sus clientes en cualquier parte del mundo.

El software de CrazyCall está basado en Kamailio y FreeSWITCH. Kamailio es un servidor de protocolo de inicio de sesión (SIP) de código abierto lanzado bajo GPL, capaz de manejar miles de configuraciones de llamadas por segundo. FreeSWITCH es una plataforma de comunicación de código abierto que permite conectarse a los clientes y puede ejecutarse en cualquier plataforma moderna.

 

Solución:

CrazyCall opera en una red multi-región. La configuración se implementa en dos regiones de AWS: eu-central-1 y eu-west-1. Es un entorno distribuido con el software de Kamailio ejecutándose en Amazon Elastic Container Service (Amazon ECS), y también RTPengine y FreeSWITCH que se ejecutan en instancias de Amazon EC2.

  • CrazyCall utiliza Kamailio como controladores fronterizos de sesión (SBC) delante de sus servidores FreeSWITCH. Esto permite que la implementación de CrazyCall actúe como un proxy web, como una puerta de enlace UDP, y a su vez también proporciona todas las características de un SBC.
  • El software WebRTC SIP client se conecta a Kamailio via HTTPS WebSocket.
  • Kamailio hace las comprobaciones de sanidad y seguridad del tráfico de señalización entrante y señalización de rutas desde el navegador/widget/aplicación móvil del usuario directamente a su granja de servidores FreeSWITCH.
  • FreeSWITCH actúa como un procesador de medios y permite a CrazyCall proporcionar diversas características a sus clientes como grabación de llamadas, IVR (Respuesta de Voz Interactiva), y música en espera.

 

Flujo de tráfico antes de integrarse con Global Accelerator:

 

Figura 1: CrazyCall sin el uso de Global Accelerator

 

Antes de integrarse con Global Accelerator, CrazyCall estaba utilizando el enrutamiento basado en latencia de Amazon Route 53, Elastic Load Balancing (ELB), y el sondeo de latencia HTTP para encontrar el enlace menos congestionado del usuario hacia una región de AWS:

  1. El usuario envía un requerimiento a sip.example.com.
  2. Amazon Route 53, en base al enrutamiento basado en latencia, reenvía el tráfico al ELB en las regiones de AWS más apropiadas.
  3. Luego el ELB reenvía el tráfico a Kamailio (Proxy SIP) y al RTPEngine.
  4. Finalmente, Kamailio direcciona el requerimiento hacia el FreeSWITCH.

 

Retos en la solución existente:

Para que su aplicación en tiempo real funcionara de manera óptima, CrazyCall dependía de una conexión a internet confiable con un rendimiento de red consistente. CrazyCall entendía que una forma de reducir la latencia y la fluctuación es reducir el número de saltos entre el usuario y la aplicación. Es importante señalar que los puntos mencionados más adelante en esta publicación son inherentes a todas las técnicas de enrutamiento basadas en DNS y no son específicos de Amazon Route 53.

  • Con el enrutamiento basado en latencia, los sistemas DNS como Amazon Route 53, basados en la IP fuente del usuario, pueden dirigir a los usuarios a los endpoints de CrazyCall de menor latencia. Los servidores DNS deciden, en función de las condiciones de red observadas recientemente, qué endpoints y en qué Regiones deben servir a determinados usuarios en particular. Un usuario en Londres probablemente será dirigido a un endpoint en la Región eu-west-1 y un usuario en Alemania probablemente será dirigido a un endpoint en la Región eu-central-1.
  • El enrutamiento basado en latencia se basa en la latencia aproximada entre el usuario y la región de AWS y no en la latencia entre el usuario y el servicio alojado. También, un servicio DNS como Amazon Route 53, recibe la dirección IP del proveedor de servicios de internet (ISP) del usuario o, si el resolver soporta la extensión edns-client-subnet para EDNS0, recibe una versión truncada de la dirección IP del usuario. Lo que realmente se quiere es la latencia entre el usuario y el endpoint al que se está tratando de conectar.
  • La latencia entre dos hosts en internet depende de la ruta de red y el número de saltos entre hosts. También, puede cambiar con el tiempo como resultado de cambios en la conectividad y el enrutamiento en la red.
  • El tráfico de los usuarios viajará la mayor parte del camino hasta el endpoint de CrazyCall a través del Internet público por medio de su proveedor de tránsito de Internet (ITP por sus siglas en inglés) antes de ingresar a la red global de AWS. Esto podría estar al otro lado del mundo. En consecuencia, la calidad dependerá de la ruta de tránsito definida por el proveedor de internet (ISP por sus siglas en inglés) que los paquetes recorrerán como se muestra en la Figura 2: Ruta en la red

Figura 2: Ruta en la Red

 

    • El nombre de dominio se queda en caché durante un tiempo predefinido por el parámetro TTL (Time to Live) en cada paso del proceso de resolución DNS. A medida que los usuarios se conectan a través de diferentes redes y servidores DNS, es difícil encontrar el umbral correcto para TTL. El almacenamiento en caché DNS puede ayudar a acelerar la entrega, pero en caso de que haya cambios en la red, también puede retardar el cambio a otro endpoint disponible ya que hay que esperar a que expire la caché DNS. Debido a esto CrazyCall no quería depender en el TTL del caché de DNS en el dispositivo cliente. Todos estos factores conducen a tener que administrar configuraciones de ruta, configuraciones DNS, complejidades de red y/o operativas en su conjunto.
    • Las direcciones IP para la búsqueda en DNS del dominio de CrazyCall pueden cambiar. Es posible que los usuarios no estén en la lista permitida de los rangos de direcciones IP. En tales situaciones el cambio en la dirección IP puede dificultar a los usuarios encontrar en la lista permitida recursos externos basados en direcciones IP.
    • Un balanceador de carga de aplicaciones (Application Load Balancer) orientado hacia internet puede aumentar su exposición a ataques provenientes de internet.

    Para hacer frente a estos desafíos, CrazyCall comenzó a explorar el enrutamiento Anycast. El enrutamiento Anycast es una regla de direccionamiento y enrutamiento de red en la que una única dirección de destino tiene múltiples rutas de enrutamiento hacia dos o más endpoints. Fue entonces cuando descubrieron que Global Accelerator usa el enrutamiento Anycast.

 

Como Global Accelerator ayuda a CrazyCall:

  • Global Accelerator proporciona direcciones IP estáticas que sirven como punto de entrada fijo a la aplicación en tiempo real de CrazyCall que puede estar alojada en cualquier número de regiones de AWS.
  • Estas direcciones IP estáticas son emitidas como anycast desde las ubicaciones de borde de AWS (AWS edge locations). Dichas IPs distribuyen el tráfico entrante de aplicaciones a través de múltiples endpoints en una o más regiones de AWS, lo que aumenta la disponibilidad de la aplicación de CrazyCall.
  • Las direcciones IP de Global Accelerator son estáticas y sirven como interfaz de entrada “front-end” a su aplicación. Global Accelerator detecta rápidamente interrupciones en los endpoints o desbordes de los mismos y re-dirige el tráfico IP a una región de AWS con mayor disponibilidad. El tráfico es dirigido sobre la ruta optimizada a la nueva ubicación en vez de continuar usando la ruta original a la ubicación original. Esto ayudó a CrazyCall a darse cuenta de la mejora en el rendimiento sin lidiar con complejidades operativas de la red.
  • Global Accelerator permitió a CrazyCall agregar un balanceador de carga de aplicaciones interno (ALB por sus siglas en inglés) como punto final. Al utilizar Global Accelerator como punto de acceso único orientado a Internet, CrazyCall ahora es capaz de proteger su aplicación, que se ejecuta en AWS, de ataques de denegación de servicio distribuido (DDoS) gracias a AWS Shield.

 

Flujo de tráfico con la integración de Global Accelerator:

CrazyCall integró en su implementación a Global Accelerator y Amazon Route 53 para lograr un mejor rendimiento de red. Global Accelerator dirige el tráfico de los usuarios al endpoint de la aplicación más cercana, reduciendo así la latencia y la fluctuación de Internet. El tráfico VoIP del usuario se direcciona a la ubicación de borde (edge location) más cercana vía Anycast. A continuación, el tráfico se dirige a la región de AWS más cercana que hospeda el entorno de CrazyCall utilizando la red global de AWS.

 

Figura 3: CrazyCall con el uso de Global Accelerator

 

Como se describe en la Figura 3, CrazyCall ahora cuenta con las siguientes características:

  1. Utiliza el modo anycast IP del Global Accelerator.
  2. Utiliza Amazon Route 53 para crear un registro CNAME para sip.example.com que haga referencia al nombre de host (hostname) DNS del Global Accelerator.
  3. Configura un balanceador de carga de aplicaciones interno (ALB) como el endpoint del Global Accelerator.
  4. El usuario envía el requerimiento hacia sip.exampl.com.
  5. Al utilizar la IP anycast de Global Accelerator, el tráfico ingresa a la red global de AWS a través de la ubicación perimetral (edge location) más cercana al usuario.
  6. Dentro de la ubicación perimetral, el tráfico es direccionado hacia el Global Accelerator.
  7. Global Accelerator reenvía el tráfico VoIP hacia un ELB (Elastic Load Balancer) en la Región más apropiada.
  8. El balanceador de carga de aplicaciones (ALB) reenvía el tráfico VoIP hacia Kamailio (SIP Proxy) y hacia el RTPEngine.
  9. Kamailio a su vez direcciona el tráfico de VoIP hacia FreeSWITCH.

 

Conclusión:

Con Global Accelerator y Amazon Route 53, CrazyCall ha podido utilizar direcciones IP de anycast estáticas en cuestión de minutos. Global Accelerator permite que el tráfico de usuarios ingrese a la red global de AWS más cercana al usuario. Global Accelerator habilitó a CrazyCall para implementar su software con baja latencia y un rendimiento mejorado en cuestión de días. Sin Global Accelerator, habría tardado meses en desplegar servicios de anycast. Además, la solución habría sido compleja y costosa de mantener e implementar para la escala de CrazyCall. Desde que se integró con Global Accelerator, CrazyCall ha notado una reducción en las llamadas de soporte de clientes que piden ayuda con problemas de rendimiento y calidad.

 “Nosotros utilizamos las IPs estáticas anycast de Global Accelerator y la red global de AWS para manejar el tráfico de Voz sobre IP (VoIP), asegurando así que nuestros clientes obtengan la mejor calidad de servicio.”

—Marcin Kowalczyk, AWS Architect, CrazyCall

 

Este artículo fue traducido del Blog de AWS en Inglés

 

Sobre el autor

Pratik Mankad es Sr.Network Arquitecto de Soluciones.

 

 

 

 

Revisor

Guillermo Fernandez es Senior Customer Solutions Manager.