La semana pasada se anunció la nueva versión de Asterisk 21, una versión que aunque no es LTS (Long Term Support) promete algunos cambios que sentarán las bases de las futuras nuevas versiones y por lo tanto es muy interesante tenerla presente y ver los distintos cambios que traen.
A diferencia de otras versiones, más que analizar las características nuevas que trae, casi es mejor analizar las características que NO trae… me explico:
Eliminación de módulos obsoletos como:
chan_sip
app_macro
chan_skinny
app_osplookup
chan_mgcp
chan_alsa
pbx_builtins
app_cdr
res_monitor
Desaparece el users.conf (por si alguien aún lo usaba)
También mejora la negociación de códecs, ya la habían arreglado en Asterisk 17, pero se ve que aún tenía margen de mejora ante algunos casos muy concretos.
Cambios en muchos de las aplicaciones de dialplan que utilizaban parámetros que ejecutaban macros como el parámetro M de la aplicación Dial, que ya deja de existir, la opción de ejecutar una Macro al finalizar el MixMonitor, al dejar un mensaje en el VoiceMail, etc.
No os voy a engañar, llevo un par de años lejos del mundo Asterisk y mucho más cerca del mundo Kamailio, con lo que ando un poco más al día de los módulos y versiones de Kamailio que con las últimas versiones de Asterisk, no obstante, posibles cambios y nuevos proyectos pueden hacer que retome nuevamente este magnífico software y toque ponerme al día en las novedades de las versiones más actualizadas. Eso no significa que deje Kamailio de lado, todo lo contrario… los nuevos proyectos pueden incluso añadir nuevas herramientas que, aunque ampliamente conocidas, nunca había tenido la oportunidad de ponerla en práctica hasta ahora, así que, espero que hayan novedades muy pronto.
La versión de Debian Bookworm no incluirá los paquetes de Asterisk por falta de personas que se encarguen de crear los paquetes necesarios para ser incluidos.
La falta de mantenedores y los problemas con la biblioteca PJSIP parecen ser el problema. Los paquetes de Debian Asterisk ya se han quedado obsoletos con los parches de seguridad, por lo que hacen falta más personas que ayuden a compilar y empaquetarlo para esta versión de Debian.
Asterisk sigue siendo un software muy necesario en muchos ecosistemas de comunicaciones y aunque la mayoría de nosotros solemos compilar a mano las versiones que instalamos, hay muchas personas que prefieren utilizar el sistema de paquetes de Debian por facilidad a la hora de actualizar, configurar y buscar algo más de estabilidad con versiones bastante probadas.
La versión de Asterisk 20 (versión LTS), se espera que salga en el próximo mes de octubre pero desde Sangoma ya nos empiezan a avisar de las novedades que traerá y las más llamativas de momento no son las que traerá si no las características que no incluirá por llevar varias versiones marcadas como «obsoletas» y que, por lo tanto, ya no será posible utilizar en esta versión.
Por este motivo, si eres de los que utiliza una versión antigua como Asterisk 13 o anterior, es muy importante que vayas pensando en los cambios de las nuevas versiones o, de lo contrario, el salto para actualizar a la nueva versión de Asterisk será tan grande que más valdría rehacer de nuevo todo el sistema.
Adiós a las salas de conferencia Meetme.
Meetme nos ha acompañado creo, desde las primeras versiones de Asterisk, con un comportamiento excelente y una potencia y flexibilidad cada vez mayor, ya que cada versión nueva solía incluir alguna que otra mejora, alguna opción, mejor rendimiento y, para montar pequeñas «salas de conferencia de audio» es una herramienta tan práctica como eficaz.
En 2009 ya hablábamos que ConfBridge había venido para sustituir a Meetme. Una aplicación completamente escrita desde cero y que permitía muchas cosas que Meetme no incluye. No obstante, estas características hace que, en un principio, Meetme continuara siendo una aplicación mucho más sencilla de manejar y no sería hasta Asterisk 13 que ConfBridge incluiría todas las opciones que potenciaría en condiciones las salas de conferencias tal y como lo hacía Meetme, por lo tanto, Asterisk 13 fue la primera versión en la que ConfBridge realmente podía empezar a sustituir a Meetme.
No ha sido hasta la versión Asterisk 20 cuando realmente se ha planteado ConfBridge como una versión capaz de sustituir a Meetme, por lo que Meetme pasará a ser marcada como «obsoleta» y será retirada en la versión Asterisk 21.
Adiós a la aplicación Monitor para grabar llamadas.
Desde las primeras versiones de Asterisk, se incluían dos aplicaciones para grabar conversaciones: Monitor y Mixmonitor, realmente la segunda era una «versión» de la primera y es que, utilizando antes de una llamada la aplicación Monitor, éste genera dos archivos separados: in y out para posteriormente mezclarlos gracias a la herramienta soxmix y trabajar con él.
La segunda era idéntica a la primera (más limitada) pero mezclaba ambos audios y generaba un único archivo mientras se hacía la llamada. Por esta razón y por la carga extra que podía suponer mezclar audio durante una conversación, hacía que siempre haya preferido Monitor a MixMonitor.
No obstante, hace un par de años descubrí que MixMonitor realmente había incluido muchas más opciones y mejoras que Monitor no incluía, por lo que descubrí que era más interesante utilizar MixMonitor que Monitor.
En la versión Asterisk 20, Monitor también se marcará como obsoleto y no será hasta la versión de Asterisk 21 cuando realmente se retire oficialmente.
Adiós a las Macros en el dialplan.
Otro de los cambios que nos traerán de cabeza son las Macros, obsoletas ya desde hace algún tiempo pero que se resisten a ser eliminada debido a la gran dependencia que muchos usuarios tienen al seguir utilizándola. No obstante, aprovechando las últimas versiones que se están desarrollando, las Macros también nos dirán adiós en estas nuevas versiones.
La alternativa es 100 veces mejor: Gosub
Gosub incluye todo lo bueno de Macro pero mucho más completo ya que, por ejemplo: Macro entra siempre a la extensión ‘s’ mientras que Gosub es como un Goto (podemos acceder a la extensión que queramos) y también nos permite devolver un resultado con la aplicación Return(<valor>) cuyo valor es devuelto en la variable ${GOSUB_RETVAL}
Adiós a muchos otros módulos importantes.
La próxima versión de Asterisk incluirá otros módulos como obsoletos, quizá los módulos no sean muy frecuentemente utilizados, pero en muchos otros casos, ese módulo es vital para algunas instalaciones.
Módulos como chan_mgcp o chan_alsa son módulos muy especiales que también pasarán a estar obsoletos y que en algunos sistemas son vitales para proyectos especiales, lo cual implica que, no serán compilables por defecto y será necesario activarlo específicamente, aunque lo peor es que se quedarán sin soporte para bugs o mejoras (algo que estos módulos tampoco tienen ya desde hace algún tiempo).
Asterisk 19 no es LTS, pero aún así es una versión importante debido a que incluyen numerosas mejoras y añadidos como las que vamos a ver en este artículo. Muchas de estas funciones son curiosas pero otras son muy interesantes.
Recordamos que para sistemas en producción se recomienda Asterisk 18 por ser LTS y por que va a tener más tiempo de soporte y actualizaciones. Otro día podremos hablar de las ventajas que tiene mantener un sistema actualizado, pero es interesante saber que un Asterisk 11 sólo es posible ser instalado en una Debian 9 (una versión de Debian de hace 6 años), lo cual implica unas versiones muy antiguas de librerías y servicios, seguramente obsoletas y con fallos de seguridad, por lo que siempre es importante tener el sistema operativo actualizado y las versiones de Asterisk también acorde al sistema operativo.
Vamos a ver las ventajas que tiene esta nueva versión de Asterisk 19 que se ha presentado en la Astricon que está teniendo lugar ahora mismo.
Sangoma acaba de publicar la versión de Asterisk 18 aprovechando, como suele ser costumbre, su evento Astricon para este anuncio tan importante.
Por razones conocidas por todos, el evento no se ha podido celebrar físicamente, por lo que todo se ha hecho de forma telemática online y el anuncio no se ha hecho esperar:
#Asterisk 18.0.0, 17.8.0, 16.14.0, and 13.37.0 now available at https://t.co/kkl5FxRPnw and just a reminder that 13 and 17 go security fix only in approximately a week! One last bug fix release will occur for each. #ShipIt
El desarrollo de Asterisk 18 ha coincidido con el bloqueo ocurrido por el COVID, por lo que, aunque hay muchas novedades, no hay tantas como se esperaban. Lo que sí hay son muchos bug-fix que hacen de Asterisk 18 una de las más interesantes versiones hasta la fecha.
Entre las novedades principales hay dos documentadas bastante llamativas:
Soporte para multivideoconferencia Hasta ahora, Asterisk soporta videoconferencia entre varias personas, pero a diferencia de como estamos acostumbrados a hacerlas (viendo en todo momento a todo el mundo) Asterisk seleccionaba una única fuente de vídeo (generalmente quien hablaba) y era la que todo el mundo veía en todo momento. Esto en Asterisk 18 cambia y parece que sí vamos a poder ver a todo el mundo como se hacía antiguamente mediante un software que mezclara todos los streams y ofreciera una fuente de vídeo a cada participante. Ahora que la videoconferencia es un must con esto del teletrabajo y las reuniones a distancia, que Asterisk 18 incluya soporte de multivideoconferencia es todo un logro considerando que era una característica que se anunció en la Astridevcon 2007 para la «futura rama» Asterisk 1.6. Más información.
Soporte para negociación de códecs ¿Después de tanto tiempo pensando que Asterisk negociaba el códec y ahora te encuentras con esto? Pues si, el tema de la negociación de códecs es un debate interno y externo allá donde tiene que ver Asterisk y es que Asterisk sólo «deja pasar» pero no negocia, para eso se encargan los endpoints (telefonos), los gateways o los proveedores, hasta ahora Asterisk sólo «permite o no» uno o varios códecs determinado. En algunas versiones incluso definir el orden de estos códecs ayudaba a que la negociación seleccionara un códec frente a otro, pero hasta que no ha llegado Asterisk 18 (y PJSIP) el tema de la negociación de códecs no funcionaba como debería. Personalmente he hecho muchas pruebas y hasta cierto punto siempre he recomendado utilizar un único códec para evitar dicha «no-negociación«. Más información.
Por supuesto aquí tienes los enlaces directos al ChangeLog y al código fuente para que empieces a probarlo cuanto antes y nos cuentes qué te parece.
A raíz de una conversación y unas dudas sobre cómo trabajan los usuarios con Asterisk, hace una semana lanzamos una encuesta para conocer de primera mano y de forma anónima qué versión de Asterisk utilizan actualmente los usuarios y por qué razón.
Eramos conscientes de que muchísima gente utilizaba versiones de Asterisk antiguas y que eran pocas las que, de cara a una nueva versión, darían el salto y actualizarían. Los resultados de esta encuesta no son representativos más que de un porcentaje de lectores de Sinologic, aún así, se han recogido 410 respuestas, por lo que lo primero es dar las gracias a todos aquellos que habéis participado compartiendo vuestras opiniones y comentarios.
La versión más utilizada de los usuarios que han participado en la encuesta es Asterisk 13.
El 46% (casi la mitad) de los encuestados usan Asterisk 13. El 22% de los usuarios utilizan Asterisk 16. El 14% utilizan Asterisk 11. Y el 7% utiliza Asterisk 1.8. El 7% restante utilizan versiones más antiguas (Asterisk 1.6 y Asterisk 1.4)
Los resultados aunque esperados, nos han sorprendido ya que hay muchas más personas de las que esperábamos que trabajan con versiones más avanzadas de Asterisk 11 y las principales razones han sido:
Soporte PJSIP.
Soporte WebRTC.
La mayoría que utilizan Asterisk 16 deja claro que van a seguir actualizando las versiones, tienen confianza en los nuevos desarrollos y apuestan por mantener lo más actualizado posible sus sistemas. Otros en cambio dejan claro que es por compatibilidad con WebRTC y PJSIP.
Sobre las razones de por qué utilizan versiones más antiguas Asterisk 13 o inferiores, básicamente son:
Estabilidad. (casualmente la misma razón que han dado otros usuarios que han indicado que usan Asterisk 16)
Instalaciones heredadas (legacy code, compatibilidad con sistemas y desarrollos antiguos, deuda tecnológica, etc.)
También es llamativo que, de todas las respuestas, únicamente 1 persona trabaja con una versión NO LTS (Asterisk 15) indicando que es la versión que venía con la distribución. Por lo demás, TODAS las versiones indicadas en la encuesta eran LTS pese a que pusimos todas las versiones disponibles desde la 1.4 hasta la 16. De aquí también se descubre que la gente conoce bien qué versión es mejor para las instalaciones, que aun no siendo la última, son conscientes de la diferencia entre versiones LTS y no LTS.
Como bien ha comentado un usuario, Asterisk 13 es lo suficientemente antigua como para mantener una compatibilidad con software compatible con Asterisk 11, pero suficientemente moderna como para incluir algunas mejoras interesantes como PJSIP, ConfBridge, TLS, etc.
De las respuestas, podemos sacar algunas conclusiones, que es en definitiva lo que veníamos buscando de todo esto:
Utilidad de Asterisk
Los usuarios de Asterisk son muy conscientes de lo que instalan y qué esperan de la aplicación. No actualizan si no es estrictamente necesario ya que las versiones de hace 4 ó 5 años son suficientes para el trabajo que necesitan que hagan.
Sólo van a actualizar si hay algo que realmente sea necesario: como es el caso de WebRTC, o algún caso puntual de PJSIP (el 26% de los encuestados utilizan este stack SIP).
Rapidez y facilidad de configuración
La mayoría utilizan chan_SIP (el 66% de las respuestas) quizá porque PJSIP es algo menos intuitivo que chan_sip y no lo necesitan. Hay que recordar que en Asterisk 16 el módulo chan_sip está oficialmente obsoleto y se recomienda utilizar PJSIP en adelante.
Muchos usuarios nos indican que no actualizan porque todo lo desarrollado alrededor de su instalación está orientado a esa versión en particular y actualizar requiere modificar el código, rehacer configuraciones, etc, algo que no es prioritario si no implica algún valor añadido que realmente sea interesante.
Seguridad y estabilidad
Debido a que la mayoría de los comentarios han sido «estabilidad» tanto si utilizan Asterisk 11 como si utilizan Asterisk 16, entendemos que prácticamente cualquier versión LTS se puede considerar suficientemente estable para una instalación seria.
Sobre seguridad, es cierto que cuanto más actual, más segura es, ya que se habrán descubierto menos vulnerabilidades. No obstante, los problemas de seguridad reportados son muy puntuales y están bien notificados, por lo que la seguridad de unas versiones frente a otras tampoco es un factor relevante de cara a actualizar.
Por último, repetimos el agradecimiento a todos los que habéis participado y que esto nos sirva a todos para tener una visión que, si bien no tiene por qué ser representativa, si ha sido muy útil para entender ciertos aspectos en cuanto a la versión de Asterisk que utilizan los usuarios.
A la vista de que la próxima nueva versión LTS está a punto de salir (Asterisk 18), hace algún tiempo hablaba con un compañero sobre las razones por las que muchos usuarios habían continuado utilizando versiones obsoletas (Asterisk 1.8 y Asterisk 11 principalmente) en lugar de «abrazar» las nuevas versiones Asterisk 13 o Asterisk 16.
Se nos ocurrieron algunas posibles razones, aunque nuestras razones son muy personales orientadas principalmente por el trabajo que normalmente hacemos y las particularidades que pueden tener. Por esta razón, se nos ocurrió preguntar a los usuarios de Sinologic, de forma anónima, qué versión de Asterisk utilizan frecuentemente y en caso de que no sea la última posible y quiera participar, las razones que hay detrás de utilizar estas versiones.
Así que si os apetece participar en esta breve encuesta de 4 preguntas, (en la que tardaréis apenas 20 segundos) próximamente analizaremos y publicaremos los resultados obtenidos, estamos seguros que a más de uno le sorprenderá bastante.
Como suele ser habitual, aprovechando el Astricon (el evento de los usuarios y profesionales de Asterisk que organiza Digium Sangoma) también se dan cita los desarrolladores de Asterisk en lo que llaman la «AstriDevCon» y muestran sus avances, debaten cuestiones sobre el rumbo que debe seguir Asterisk y ponen cara y debaten sobre las grandes discusiones que suceden en las listas de correo de la comunidad.
En este caso, y como bien sospechábamos, acaban de publicar la versión Asterisk 17, una versión de Desarrollo orientada a poner en funcionamiento nuevas características que los usuarios y desarrolladores consideran interesantes, así que vamos a ver algunas de ellas:
Nuevos comandos: AttendedTransfer, BlindTransfer Ya existía el comando Transfer, pero con estos nuevos comandos se quiere dar un mejor tratamiento a las transferencias desde el propio Dialplan (y también desde otros interfaces como ARI, AMI o AGI)
Mejoras en el ConfBridge: Sorprendentemente aún hay usuarios que utilizan Meetme porque siguen sin ver el potencial de ConfBridge. Es cierto que un gran potencial requiere a veces de más tiempo para configurarlo y prepararlo, pero la solución no es quedarse clavado en el pasado, si no intentar mejorar las nuevas herramientas para que sean tan útiles y prácticas como las que pretende sustituir, y eso es justamente lo que trata de hacer ConfBridge desde la versión 10.
Soporte de RTP/ICE: Si bien Asterisk 16 ya soportaba RTP/ICE, en Asterisk 17 tendremos algunas mejoras en el protocolo que incidirán en mayor estabilidad y compatibilidad con la señalización de lo paquetes de audio/vídeo.
Seguramente pienses que no hace ni un año que salió Asterisk 16 y ya tenemos encima Asterisk 17, pero hay que recordar que Asterisk 16, al ser una versión LTS, vino para quedarse por un buen tiempo, es una versión LTS lo que significa que está orientada a añadir mejoras pero también con la mayor estabilidad posible, mientras que Asterisk 17 es una versión de Desarrollo, lo que significa que está pensada para incluir mejoras y puede que no sea la más recomendable para utilizarla como software en producción, aunque todo hay que decir, que estas versiones son también muy, muy estables.
Si bien Kamailio ya es un viejo conocido, cada nueva versión que nos traen sus desarrolladores nos parece más y más completa. No hay que mirar atrás, cada versión anterior tiene sus buenos pasos para llegar a convertirse en una de las grandes herramientas de software de comunicaciones que han convertido la VoIP en lo que es hoy día. Pero esta versión que acaban de publicar hoy incluye, no solo todo lo maravilloso de las versiones anteriores, si no varias características nuevas que estábamos esperando desde hace tiempo.
Entre las numerosas nuevas características que podéis ver en su listado, me llaman la atención dos de ellas que llevaba tiempo esperando ver y de las que estuve hablando con @Miconda el pasado mes de Febrero durante el Fosdem:
rtp_media_server – Funcionalidades para procesar «media» (poder hacer un play o conectar con una PBX incluyendo también varios códecs (entre ellos, el gran Opus)
secfilter – El módulo de seguridad que ya os presentamos a finales del año pasado, y que nos permite permitir o bloquear utilizando listas blancas o negras basadas en diversos aspectos (direcciones IP, países, dominios, etc…)
Así que, aprovechando que ya está disponible, es cuestión de probarlo y ver cómo funciona esta nueva versión que podéis descargar en su web.
Una nueva versión de Kamailio ha visto la luz esta semana, en esta ocasión es la versión 5.2.0, una nueva versión que incluye muchas mejoras que estábamos deseando ver y que otorga mucha mas versatilidad a un software ya de por sí, tan flexible como potente.
Entre las mejoras incluidas, nos llama la atención el soporte de backend sobre Redis (que en versiones anteriores ya permitía cierta compatibilidad con Redis pero no hasta el punto de poder utilizar la tablas con esta base de datos), así como sistemas ‘acc’ directamente en JSON permitiendo así independizarnos de bases de datos relacionales y poder jugar con nuevos sistemas más rápidos y orientados más al almacenamiento y acceso más rápido.
También es importante destacar las mejoras de estabilidad de algunos módulos KEMI que permiten utilizar (e incluso sustituir) el plan de routado de Kamailio por otro similar utilizando la gramática del lenguaje de programación que más nos guste: Python, Javascript, LUA, Ruby,… aquí hay mucho más que palabras, pero de momento nos quedaremos con que se mejora el soporte de este nuevo sistema.
Como sabemos que esto os puede parecer poco, aquí os mostramos la lista resumida (en inglés) de las novedades de esta nueva versión de Kamailio:
