Sobre Asterisk 13, poco qué decir… en mi opinión, es una versión LTS basada en Asterisk 12 pero con características que no terminan de ser todo lo estables que deberían para un entorno de producción. Eso no quiere decir que no se pueda utilizar Asterisk 13 en un entorno de producción, pero las características más importantes de Asterisk 13 (PJSIP, ARI, Codec Negotiation, SIP sobre Websocket, etc…) aún no son todo lo estables que a mí me gustaría para un entorno en producción. Ahora bien, si no se utilizan estas características, el sistema es similar a Asterisk 11 con las ventajas de una versión superior, por ahí todo perfecto.
Con Asterisk 14 volveremos a la senda del desarrollo de nuevas características y eso me choca, ya que soy consciente que muchos usuarios de Asterisk tampoco utilizan las nuevas características de Asterisk 13 por lo que continuar añadiendo nuevas características a Asterisk sin conseguir que la comunidad asimile las características de Asterisk 13 creo que es un error, no obstante, la lista de características ya es pública, así que vamos a ver en qué consisten:
Soporte para hacer Text to Speech desde el sistema ARI.
De esta manera, podemos utilizar Asterisk para generar audio en base a un texto enviado mediante REST. Esto no significa que Asterisk haga de TTS, si no que hará uso de un sistema TTS conectado a Asterisk pero que Asterisk incluirá las herramientas para hacer uso del TTS mediante comandos REST (muy práctico si el TTS que utilicemos no soporta REST).
POST http://localhost:8088/ari/channels/12345/play/p1?media=tts:dude%20where%20is%20my%20car
Soporte para reproducir archivos en un canal desde el sistema ARI.
Imaginemos que estamos hablando con alguien, y una aplicación detecta que llevamos hablando demasiado tiempo y nos alerta del tiempo que llevamos hablando. Para ello, la aplicación se conectará al sistema ARI y nos enviará una serie de locuciones para indicarnos el tiempo que llevamos hablando:
POST /channels/12345/play?media=sound:usted+lleva&media=number:30&media=sound:minutos+hablando
También se buscará la posibilidad de reproducir archivos remotos HTTP en un canal, bien desde dialplan, AGI o desde el sistema ARI, como en el siguiente ejemplo:
Dialplan:
same => n,Playback(http://myserver.com/monkeys.wav)
AGI:
CONTROL STREAM FILE http://myserver.com/monkeys.wav «» 3000
ARI:
http://localhost:8088/ari/channels/12345/play/p1?media=uri:list
Content-Type: text/uri-list
http://myserver.com/monkeys.wav
Esto puede ser una opción muy interesante a la hora de centralizar locuciones entre varios servidores Asterisk, o bien, pensando en la posibilidad de disponer de un TTS que genere archivos wav, posibilidad de acceder a estos archivos situados en un servidor externo.
Módulo Beacon
Esta es una antigua idea que parece que va a tomar forma en Asterisk 14. La idea consiste en centralizar esfuerzos en mejorar aquellas características que sean más utilizadas por los usuarios y abandonar aquellas que apenas tengan uso, pero ¿cómo saber cuales son las más o las menos utilizadas?
En eso consiste el «módulo Beacon», un módulo que enviará información de forma completamente anónima a «https://beacon.asterisk.org» informando cada cierto tiempo de los módulos utilizados por nuestros Asterisk y así informar a los desarrolladores cuales son los componentes más necesarios de mejorar.
Como la información es anónima, no es necesario ningún tipo de identificación ni autorización, pero se deben tomar medidas para evitar ataques, información falsa y proveer de ciertas medidas de seguridad, cifrado, etc…
API y cliente DNS interno
Hasta ahora, Asterisk hace uso del cliente DNS del sistema operativo de manera que si hacemos una petición a un hostname y este no resuelve temporalmente, al ser un proceso bloqueante, esa petición quedará «paralizada» temporalmente hasta que responda. No obstante, esa no es la razón por la que desarrollar esta funcionalidad, si no porque cada vez más, se hacen uso de características avanzadas de DNS en la VoIP: round-robin, dns-srv, naptr, tanto en IPv4 como IPv6 y para eso, mejor contar con herramientas que permitan utilizar dichas características de forma interna en cualquier módulo de Asterisk gracias a esta nueva API.
Más cambios y más interesantes…
Además de estos cambios, hay muchos otros aunque, al ser una versión orientada a desarrollo, estos cambios están pensadas para nivel interno y no son tan «interesantes» desde el punto de vista del usuario:
- Nuevo sistema de reemplazo del motor RTP.
Hasta ahora, Asterisk utiliza un módulo res_rtp_engine y se quiere sustituir este módulo que gestiona el RTP por una API que permita crear nuevos módulos RTP más convenientes para según qué tarea.
De esta manera, se mejoraría el soporte de algunas características como RTCP, ICE, DTLS y de paso mejoraría considerablemente el soporte para ofrecer WebRTC en Asterisk. - Nueva gestión de módulos.
Actualmente se utiliza el modules.conf para decidir qué módulos debe cargar Asterisk.
Se plantea una nueva forma de indicar qué módulos deben ser cargados, y aprovechando esto, también dónde, cuando, qué archivos de configuración son los asociados a cada módulo (lo que implicaría una modificación de todos los módulos para adaptar el sistema al nuevo. - y algunas cosas más…
Como decía al principio, Asterisk 14 es una versión de desarrollo, y al igual que cuando ocurría con Asterisk 12, la mayor parte de los cambios son internos, orientados a ofrecer un entorno de trabajo mejor para los desarrolladores y preparar el marco necesario para cambios que sí verían la luz en futuras versiones de cara al usuario. Los cambios en Asterisk 12 fueron demasiado numerosos e impactantes lo que llevó a generar una gran cantidad de características que fueron hechas realidad en Asterisk 12 y Asterisk 13. No obstante, estos cambios son tan importantes que harán falta más versiones para poder hacer uso en condiciones y con seguridad de estas características.
Me alegra ver que al menos, todavía hay gente que utiliza en producción Asterisk 11 como mínimo y ya no ocurre como antes que los usuarios utilizaban versiones 1.2 y 1.4 simplemente porque funcionaban.