Deploy del componente RTPEngine

Como es sabido, RTPEngine implementa un script de fisrt_boot_installer.tpl, que puede ser invocado utilizando tecnología de provisioning o bien ser descargado y luego ejecutado sobre el Linux host en cuestión.

Para obtener nuestro script, lanzar el siguiente comando:

curl https://gitlab.com/omnileads/omlrtpengine/-/raw/master/deploy/first_boot_installer.tpl?inline=false > first_boot_installer.sh && chmod +x first_boot_installer.sh

Entonces, una vez que contamos con el script, pasamos a trabajar las variables, quitando comentarios y configurando sus valores dentro del propio script. Vamos a listar y explicar cada una de éstas variables que deben ser ajustadas antes de ejecutar el script.

Variables de instalación

  • oml_infras_stage: Se refiere al proveedor de infraestructura implicado. La idea es aprovechar las APIs de los proveedores cloud para determinar cuestiones como parámetros de la red. Si vamos a instalar onpremise o en alguna nube que no está dentro del listado, asignar onpremise como valor para la variable. Posibles valores: onpremise, aws, digitalocean, vultr, linode.
  • oml_nic: Aquí debemos indicar la interfaz de red sobre la que se levanta el puerto TCP 22222, que va a procesar las solicitudes provenientes desde Kamailio para establecer un SDP en la sesión WebRTC.
  • oml_public_nic: Este parámetro es opcional, y tiene que ver con el escenario en el cual se cuenta con 2 placas de red, una para LAN y otra WAN.
  • oml_rtpengine_release: Aquí debemos indicar qué versión del componente se desea desplegar.
  • oml_type_deploy: Aquí indicamos bajo qué escenario estará operando nuestro RTPEngine. Para entender esta variable, debemos repasar el funcionamiento de éste componente, ya que RTPEngine es quien concede los parámetros necesarios (dirección de red y puerto, entre otros) para acordar el streaming de audio con el usuario (agente o supervisor). Dependiendo del escenario dispuesto, los posibles valores son: LAN, CLOUD, HYBRID_1NIC, HYBRID_2_NIC.
    • LAN: Los agentes acceden a OMniLeads SOLAMENTE desde una red LAN.
    • CLOUD: Los agentes acceden a OMniLeads SOLAMENTE desde Internet.
    • HYBRID_1_NIC: Los agentes acceden tanto desde una LAN como desde INTERNET, mientras que el Linux host que aloja el componente posee una sola NIC.
    • HYBRID_2_NIC: Los agentes acceden tanto desde una LAN como desde INTERNET, mientras que el Linux host que aloja el componente posee 2 NICs (una para LAN y otra para WAN).

Ejecución de la instalación

Finalmente, podemos lanzar nuestro script first-boot-instaler.sh. Ésto lo podemos hacer como user_data de una instancia cloud, a través de alguna utilidad de línea de comandos para administrar la infraestructura, o bien directamente copiando el archivo hacia el Linux host destino y lanzando la ejecución del mismo.

Para comprobar que el componente se encuentra operativo, debemos lanzar el siguiente comando y observar la siguiente salida:

systemctl status rtpengine
_images/install_rtpengine_status.png

Como se remarca en la figura, es importante revisar que la dirección IP allí expuesta, coincida con vuestro escenario. Es decir, si estamos en un ambiente de usuarios que acceden desde LAN, tendrá que utilizar una IPv4 privada, y si los usuarios acceden desde Internet, deberá ser una IPv4 pública.