El desarrollo de aplicaciones de voz es un concepto muy amplio que engloba desde desarrollos básicos de centralitas, programación de IVR, programación de entornos de red orientados a protocolos VoIP, gestión de paquetes, desarrollo de códecs, criptografía, programación de chatbots, y un largo etcétera que no tendría fin.
A pesar de esto, y centrándonos en este artículo en un desarrollo básico, vamos a hablar sobre los tres modos de desarrollar soluciones más comunes, utilizando herramientas conocidas por todos: Asterisk, Kamailio y WebRTC.
En próximos artículos hablaremos sobre otras técnicas y herramientas no tan conocidas pero que nos ofrecerán soluciones diferentes a las que se pueden llevar a cabo utilizando una de estas herramientas.
Asterisk
Asterisk nació como un software de centralita, pensada desde un principio como una herramienta software para actuar como PBX: (central de teléfonos) y con opciones incluidas en su código tan básicas como la música en espera (music-on-hold), buzón de voz (voicemail), transferencia de llamadas, grabación de llamadas, colas y agentes, reproducción de locuciones, IVR, etc. No obstante, cualquiera que desee una centralita al uso e instale un Asterisk por primera vez seguramente se encuentre con grandes frustraciones:
- Nada más instalarlo, requiere de una gran cantidad de configuración para llegar a tener un sistema telefónico que cumpla mínimamente con lo que se requiere en una PBX estándar.
- Requiere de unos conocimientos básicos nada básicos para alguien profano en la materia que desconoce cómo funcionan protocolos, códecs, dialplan, etc. para llegar a configurarlo de una forma mínimamente decente.
- No incluye una herramienta que facilite la configuración a la vez que el mantemiento, teniendo que optar por soluciones externas como FreePBX, Issabel o soluciones comerciales.
Dicho lo cual, Asterisk dejó de ser un «software de PBX» para convertirse en una herramienta para la creación de aplicaciones de Voz (entre lo que se incluye, lógicamente, la creación de sistemas PBX). Gracias a esto, Asterisk hoy día es más conocido entre desarrolladores que necesitan crear su propia solución a medida, que entre empresas que necesitan una PBX tal cual. Y es por esta razón por la que Asterisk se podría considerar una de las mejores herramienta para desarrollar soluciones VoIP a medida, ya que incluye muchos medios y canales con los que poder desarrollar prácticamente cualquier solución que necesitemos.
Hemos hablado hasta la saciedad de los «interfaces» con los que cuenta Asterisk:
- CLI (Command Line Interface), que es la forma más básica de acceder a Asterisk desde el terminal de consola y nos permite ejecutar comandos simplemente tecleando lo que queremos.
- AGI (Asterisk Gateway Interface), un pseudo-lenguaje que nos permite externalizar acciones ejecutadas desde el propio Asterisk. De esta manera Asterisk «ejecuta» una aplicación externa a él mismo, permitiéndole acceder a recursos que, de otra manera, no sería posible al no tener soporte el propio Asterisk.
- AMI (Asterisk Manager Interface), un puerto TCP al que nos podemos conectar para enviar comandos y recibir eventos de todo lo que sucede en el Asterisk, gracias a un protocolo muy sencillo para cualquiera que sepa mínimamente programar.
- ARI (Asterisk REST Interface), un interfaz REST que permite tanto a Asterisk como a una aplicación, interactuar con canales, llamadas, usuarios, bridges, etc. de forma asíncrona y utilizando una conexión WebSocket para la comunicación de órdenes y datos mediante JSON.
Estos son los interfaces con los que cuenta Asterisk para desarrollar cualquier solución que se necesiten. Cada una de ellas realmente tiene ejemplos muy sencillos, pero también verdaderamente avanzados, ya que cualquiera de ellas permite una gran cantidad de posibilidades y flexibilidad para ayudarnos a crear cualquier cosa.
Pese a todo el potencial que tienen estos interfaces, existen limitaciones en todos y cada uno de ellos. Hay necesidades que los AGI no pueden satisfacer y hay que acudir al AMI. Hay soluciones que el AMI es difícil y es mejor recurrir a ARI y hay necesidades que podemos ahorrar mucho tiempo y esfuerzo si utilizamos simplemente el CLI.
Kamailio
No obstante, existen necesidades y proyectos en los que Asterisk no es la herramienta ideal, Asterisk siempre puede ayudar, pero llega un momento que hay que mirar más allá y ver qué otras soluciones se pueden utilizar.
Por poner un ejemplo rápido y fácil de entender, podemos echarle un vistazo al proyecto HOMER.
HOMER es una herramienta muy conocida por todos, y cuya función se basa en recopilar, clasificar y gestionar el tráfico SIP, permitiéndonos llevar un control perfecto de todo lo que sucede en uno o varios servidores. ¿Cómo hace esto? Necesita de una herramienta que pueda capturar el tráfico SIP y enviarlo a un sistema que pueda clasificarlo y ejecutar código por cada paquete que le llegue. ¿Qué herramienta hace esto? ¿Asterisk?
Podría… pero en este caso, un Asterisk manejando un gran volumen de llamadas SIP podría necesitar de grandes recursos, así que la solución que optaron para la versión HOMER 5 fue: Kamailio.
Kamailio es un servidor SIP PROXY / SIP REGISTRAR / etc. que se encarga de recibir paquetes SIP y procesarlos uno a uno. Al ser una herramienta orientada a esto, es muy, pero que muy eficiente, ya que no ha de manejar el audio RTP, ni hacer grabaciones, ni escuchar tonos DTMF, ni manejar transferencia, ni nada de nada, simplemente se centra en procesar cada paquete SIP que le llega. Por esta razón, un Kamailio es una herramienta supereficiente de procesamiento de paquetes SIP y la herramienta seleccionada por HOMER 5 para esta tarea.
La idea es fantástica si en nuestro desarrollo necesitamos procesar paquetes SIP (analizar los campos From, To, Contact, PAI, etc.) ya que podremos utilizar el archivo de configuración para programar qué queremos hacer ante cualquier paquete SIP que nos llegue.
WebRTC
No obstante, nos estamos centrando en desarrollo de aplicaciones de Voz basados en SIP pero ¿y si nuestro proyecto está por encima de este requisito? ¿Y si queremos desarrollar un proyecto pero no tenemos por qué hacerlo con extensiones SIP? En ese caso, otra de las soluciones que habría que estudiar es una librería muy famosa llamada WebRTC.
Aunque de WebRTC hemos hablado largo y tendido, hay que conocer bien lo que es para entender bien su alcance. Normalmente WebRTC está asociado a varios términos: Navegador Web moderno y/o softphone web.
WebRTC es mucho más que esto… aunque suene a descripción de la wikipedia, WebRTC es una librería de herramientas que nos permitirá desarrollar todo tipo de aplicaciones en las que intervenga cualquier tipo de «media» en tiempo real (eso puede ser audio, vídeo o también texto, archivos, captura de pantalla, etc.) utilizando para ello un navegador web.
No obstante, WebRTC nos permite crear aplicaciones en las que intervengan voz, audio o cualquier otro tipo de dato en tiempo real conectándonos a un servidor mediante WebSockets, lo que nos permite interactuar con cualquier aplicación remota que pueda conectarse vía WebSocket, eso elimina la necesidad de utilizarla «entre» navegadores web y nos abre las posibilidades con prácticamente cualquier otro dispositivo, desde herramientas de IoT, robots, domótica, seguridad, y un largo etcétera.
Por lo tanto, y aunque soy consciente que la curva de aprendizaje de WebRTC no es fácil, que requiere de muchos conocimientos previos bastante avanzados de Javascript, pero las posibilidades son realmente ilimitadas y son justamente éstas las que nos abrirán las puertas (y las están abriendo ahora mismo) con los nuevos proyectos que están surgiendo hoy día y que facilitarán la vida en los próximos años.
¿Conoces otras herramientas que pueden ser prácticas para desarollar aplicaciones, soluciones y proyectos VoIP?
Anímate y escríbelas en los comentarios.