asterisk_12_pre2

Después de llevar tantos años detrás de un proyecto como Asterisk, conociendo sus características, estando al día en cuanto a novedades, su evolución, cambios, problemas, propuestas y mejoras, casi podría decir que me había acostumbrado a la velocidad de crecimiento de Asterisk en cuanto a características, y cuando crees que ya lo has visto todo sobre Asterisk y que nada puede hacerte cambiar de opinión, que uno empieza a “creer” que Asterisk empieza a ser un proyecto aburrido donde solo le queda mejorar en aquellos puntos donde flaquea, aparecen una serie de personas con aires renovados y mucha ilusión y vuelven a sorprendernos proponiéndonos cosas que jamás habríamos pensado que pudiera “caber” dentro de un proyecto como Asterisk.

Cierto es, que tras la unificación de Asterisk-SCF con Asterisk, las posibilidades empezaron a multiplicarse tanto que, personalmente, me empezó a entrar miedo sobre la cantidad de cosas que veía que iban a cambiar en un corto plazo de tiempo. Tanto me asusté que empecé a seguir detenidamente la lista de desarrolladores, leyendo cuidadosamente los distintos temas, observando como Matt Jordan poco a poco, y con un “brillo” hasta ahora desconocido, iba iluminando a tantos desarrolladores para trabajar en una versión que pondría los cimientos de un cambio radical para Asterisk, algo que hará que aquellos usuarios que no estén al día de los cambios, se queden completamente desfasados y sin posibilidad de retomarlo.

Asterisk 12 está en esa etapa en la que el proyecto crece o se estanca, y quizá no sea una versión “estrella” desde el punto de vista de “características revolucionarias“, pero sí que es una versión que asentará unas bases para un crecimiento y una energía que permitirá un sinfín de características que no solo serán revolucionarias, si no que volverá a llamar la atención de todos aquellas personas que siguen el proyecto y que estaban un poco “aburridos”.

Asterisk 12 se va a convertir, con muchísimo esfuerzo (todo hay que decirlo) en una versión mucho más orientada a desarrolladores, entre otras cosas por las novedades que trae, no solo de cara a los usuarios, si no también por los cambios que hace al código existente, que cualquiera que desarrolle sobre Asterisk sabrá que, aunque es muy sencillo hacer aplicaciones que interactúen con Asterisk, a cierta profundidad, la cosa se complica bastante y no precisamente por algo intrínseco al mundo de las comunicaciones o algo particular del propio Asterisk, si no por la forma en la que los desarrolladores hicieron las cosas en su momento y que llega la hora de rehacer por completo para seguir creciendo.

Hay decenas de emails en la lista de desarrolladores de Asterisk donde se explica de forma larga y tendida los cambios internos sobre el código existente, no obstante estoy convencido que, si bien el lector puede considerar un poco tedioso que empecemos a hablar (por poner un ejemplo) sobre funciones internas de el código de bridgeado de canales, vamos a pasar directamente a las características más notables de esta versión y si alguien tiene alguna duda más acerca del código y sus novedades, puede seguir la documentación que se está creando para explicar todo lo que se está haciendo. Esta documentación se encuentra en el Doxygen de Asterisk y en su propio Wiki. Mucha documentación, mucha transparencia, mucha participación.

Vamos a ver con todo el detenimiento que nos permite un artículo, ver las principales características de Asterisk 12:

 

Nuevo Canal SIP

Desde siempre, Asterisk ha contado con un módulo dedicado al protocolo SIP (el conocido chan_SIP), quizá siempre ha funcionado convenientemente, permitiendo que cualquier teléfono IP, softphone y operador funcionase correctamente con Asterisk, pero hay que decir, en honor de la verdad, que el protocolo SIP que implementaba Asterisk no siempre ha sido “100% SIP Compliant“. Fue en Asterisk 1.8 cuando se empezó a tocar el módulo SIP (chan_sip.so) para ofrecer una compatibilidad 100% con el estándar, añadiendo el “pedantic=yes” por defecto en la configuración, algo que para muchos usuarios les parece perfecto hasta que su softphone de toda la vida empieza a dar problemas por no cumplir tampoco el estándar. En cierta manera, desde Asterisk 1.8 se empezó a obligar a seguir el estándar SIP o por lo menos, a ir acostumbrando a los usuarios que deben seguirlo. Para colmo, cualquier “alma valiente” que se atreviese a hacer algún cambio en el módulo chan_sip podría comprobar lo que, sin lugar a dudas, se considera un ejemplo típico y característico de “spaguetti code“.

Atención: Nótese la ventaja de poder decir que un código es un ejemplo de ‘spaguetti code’ porque está a la vista, se puede leer, comentar, criticar y mejorar… cualquier software sin código público puede tener exactamente el mismo código spaguetti o incluso mucho más, ya que no tienen que dar explicaciones a nadie.

Empezar a desarrollar un nuevo canal SIP para Asterisk es algo titánico: comenzar desde cero, hacer pruebas, seguridad, fallos de implementación, etc… mucho trabajo para tan poco tiempo … así que se ha optado por la mejor decisión posible: aprovechar el software libre para conectar Asterisk con un proyecto que ya implementa una pila SIP que funciona perfectamente: PJProject.

Por ello, se ha hecho un fork del pjsip orientado a Asterisk, de forma que se pueda mantener un proyecto paralelo, mucho más manejable y que permita realizar cambios en algo tan importante como el canal SIP de Asterisk. Ya hablamos de esto cuando se hizo oficial.

¿Qué ventajas traerá este nuevo canal SIP?

Sin duda, en Asterisk 12 seguramente no encontraremos muchas novedades de cara al usuario, pero no hay que olvidar que Asterisk 12 es una versión orientada a “desarrollo” no una LTS “Long Term Support” por lo tanto, estos cambios están orientados a ofrecer funcionalidades que serán aprovechadas en futuras versiones como por ejemplo: Soporte de SIP MESSAGE para la gestión de mensajería instantánea vía SIP, mejor soporte de NAT (ICE, TURN, STUN, etc…), mayor compatibilidad (o por lo menos, una compatibilidad más correcta), y un largo etcétera que dará que hablar en próximos artículos.

 

Soporte de REST

El protocolo HTTP ha pasado a tener un valor mucho más allá del que estamos acostumbrados. Si bien conocemos HTTP como un protocolo por el que enviar páginas HTML y por consiguiente otros tipos de archivos como Javascript, CSS, etc… el protocolo HTTP también se puede utilizar para enviar y recibir otro tipo de información, ejecutar aplicaciones remotas, recibir resultados, etc.

Esa ejecución de aplicaciones remotas se hace mediante llamadas a “webservices”. Cuando un usuario llama a un webservice que se encuentra en un servidor remoto, este ejecuta una acción y devuelve información sobre lo que se ha ejecutado.

Actualmente, los sistemas WebServices más conocidos son: SOAP y REST

No voy a entrar en qué son cada uno de estos sistemas, porque no es fácil si no se tiene ciertos conocimientos de programación, pero podríamos decir que hoy día prácticamente cualquier sistema software requiere de cierta compatibilidad con algún sistema WebService (ya sea SOAP o REST) y Asterisk no podría ser menos, por esa razón, Asterisk 12 incorporará Soporte de REST para poder ejecutar acciones de forma remota mediante llamadas HTTP.

Desde la aparición de AJAM (Asterisk Javascript Asyncronous Manager) con Asterisk 1.4, los desarrolladores de Asterisk siempre han (hemos) buscado una forma de conectar la web con Asterisk (no nos referimos a hacer llamadas vía web, que eso es otra cosa), es decir, controlar Asterisk mediante páginas webs, llamadas Javascript sin necesidad de hacer malabares como programar scripts en PHP, Python o Perl que generen archivos .call que llamen a contextos del dialplan que generen archivos, y ….  Si no algo mucho más directo, más sencillo. Por ese motivo, el soporte de REST es algo muy necesario, algo que abrirá Asterisk a un nuevo horizonte de posibilidades en nuevos proyectos. Quizá llega algo tarde, pero como se suele decir, más vale tarde que nunca.

 

Mejora en el soporte Multiempresa

Uno de los usos más novedosos de este último año, es el conocido como “soporte multi-tenant”, también conocido como “soporte multi-empresa” o la capacidad de ofrecer servicio a varias empresas de forma independiente con un mismo sistema Asterisk. Esto ha tenido un gran auge este último año, principalmente porque se ha ofrecido el servicio PBX hosteado, permitiendo ahorrar costes al no tener que instalar ni mantener un sistema PBX físico en local, no teniendo que pagar electricidad, seguridad, etc., por este motivo, muchas empresas han empezado a ofrecer este servicio y buscan que Asterisk pueda ofrecerlo.

Si bien Asterisk ya dispone de algunas formas de ofrecer estos servicios utilizando unos mínimos conocimientos sobre configuración, es cierto que para algunos casos, Asterisk es bastante mejorable en este entorno, por lo que se ha hecho un esfuerzo extra en el desarrollo de Asterisk 12 para poder ofrecer este tipo de servicios: transferencias únicamente entre los usuarios de una empresa, capturas, parking, buzones de voz, colas, etc… evitando que una empresa pueda llegar a acceder a los servicios de otra y mejorando el rendimiento ante un gran número de empresas.

 

Soporte de nuevas capas de acceso de datos

Lo que pasará a conocerse como DAL (Data Access Layer) es algo de lo que hemos hablado en otras ocasiones, concretamente cuando hablábamos de una API unificada.

Dentro de las tareas que realiza el núcleo de Asterisk (y por lo tanto, algo que es difícil de modificar), se encuentra el tema de la configuración y es que actualmente tenemos muchas formas de configurar un Asterisk:

  • Mediante archivos de configuración
  • Mediante tablas en bases de datos
  • Directamente en la consola de Asterisk – AstDB-
  • Mediante el Asterisk Manager Interfaz (AMI)
  • y algunas formas más.

Cuando se realizan cambios y se desea actualizar la configuración, Asterisk “parsea” cada tipo de configuración con sus propias funciones. Con el nuevo sistema DAL, estas funciones que “dan de alta un usuario”, “modifican una contraseña”, etc… pasan a ser las mismas, permitiendo una capa de abstracción superior que sea quién realmente realice los cambios y unifique los sistemas de configuración para evitar que cada “tipo de configuración” haga lo que quiera.

 

Creación de la API Stasis

Finalmente, uno de los cambios más complejos que incluirá el nuevo Asterisk 12, será el sistema de API “Stasis” un conjunto de APIs que permitirá a cualquiera, desarrollar en Asterisk de una forma mucho más sencilla.

No solo incluye una reescritura completa del interfaz AMI utilizando el interfaz REST del que hemos hablado antes, si no que también incluye una serie de nuevas API’s para poder desarrollar “dentro” del propio Asterisk: nuevos canales, nuevos recursos, nuevos formatos, … en definitiva nuevos módulos utilizando un conjunto de herramientas, funciones y librerías mucho más rápidas y fáciles que las actuales.

Una de las características más llamativas de la nueva API Stasis es la distribución extendida de eventos en distintos formatos, para que puedan ser leídos, parseados y utilizados desde distintas plataformas, aplicaciones y sistemas.

Nuestro colega Tomás Sahagún nos envía un ejemplo de evento de petición de información del sistema Asterisk recibido en JSON mediante WebSocket aprovechando la unión de las APIs que hemos visto antes (DAL, REST y entrega mediante Stasis):

{“status”:{“startup_time”:”2013-08-07T11:01:53.010+0200″,”last_reload_time”:”2013-08-07T11:06:07.918+0200″},”build”:{“user”:”root”,”options”:”LOADABLE_MODULES, BUILD_NATIVE”,”machine”:”x86_64″,”os”:”Linux”,”kernel”:”3.2.0-4-amd64″,”date”:”2013-08-07 06:35:48 UTC”},”system”:{“version”:”SVN-trunk-r396347″,”entity_id”:”ea:40:2c:37:12:b4″},”config”:{“default_language”:”en”,”name”:””,”setid”:{“user”:””,”group”:””}}}

 

Una versión puramente para desarrollo

Estas son algunas de las novedades más importantes de Asterisk 12. Como decía al comienzo, están orientadas a desarrolladores, a asentar unas bases para un mejor despliegue, mantenimiento y seguridad aunque como es lógico, no está pensado para ser instalado donde se requiera de una estabilidad máxima, un mantenimiento constante y continuo… , para eso están las versiones LTS (Asterisk 1.8, Asterisk 11 y Asterisk 13). Considero que esta versión es impresionante, abre muchísimas posibilidades y si vemos todos los cambios desde un punto de vista objetivo, Asterisk 12 podría ser la versión que hizo adulto a Asterisk.

 

7 Comentarios

  • Hola Elio.

    He leído algunos artículos sobre el multi-tenant, pero no he podido leer nada técnico. ¿Tienes algún enlace?

    Gracias.

    • Multi-tenant es un término “comercial” de llamar a un sistema que tiene soporte para “varias empresas a la vez” lo que, como es lógico, orientado a algo “técnico” y más hablando a nivel de ‘software’ no tiene mucho sentido.
      No obstante, si en Asterisk 1.8 ya se permitía la creación de “slots de parkings” independientes para distintos “grupos” o “empresas”, en Asterisk 12, y más con el soporte de PJSIP, se permite un mejor control de “dominios SIP” que permitirán gestionar mucho mejor marcos y entornos de usuarios (o lo que viene a ser empresas independientes en el mundo real).

  • No sabes si tendra soporte para mongodb nativo???

    • No he visto nada relativo a soporte nativo de MongoDB aunque viendo que Asterisk-SCF traía soporte y que las novedades de Asterisk 12 están orientadas para proporcionar soporte a muchos “backends” estoy convencido que está muy cerca.

  • Hola Elio, Felicitaciones por este artículo. La verdad te pasaste. Tiene muy buena pinta Asterisk 12 vamos a tener que actualizarnos mucho para no quedar atrás. Saludos

    • Gracias Federico,
      El tema está en que hoy (16 de Agosto) aún no han sacado una versión estable, únicamente han congelado las características y novedades que va a traer, y habrá que esperar un poco antes de probarlo de forma seria o podemos llevarnos algún que otro disgusto. 🙂

  • Un buen artículo como siempre. Felicidades Elio!

Archivos

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales