http://www.sinologic.net/Como ya explicamos en este artículo sobre cómo funcionan las versiones de Asterisk, la versión Asterisk 14 es una versión orientada a incluir nuevas características, lo que se conoce como una versión de “desarrollo” y por lo tanto no es recomendable utilizada en entornos de producción. No obstante, es muy interesante conocer qué características va a incluir para ir desgranándola y viendo las posibilidades que tendrán nuevas y futuras versiones de Asterisk.

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.

 

3 Comentarios

  • Totalmente de acuerdo en muchas de las cosas que comentas. Asterisk 13 es exactamente igual de estable que Asterisk 11 y por lo tanto es totalmente válido para entorno de producción, pero la mayoría de sus características nuevas no funcionan suficientemente bien.

    Sobre las nuevas funcionalidades, creo que algunas de las novedades que plantean están muy bien pero se alejan totalmente de la realidad de la telefonía IP hoy en día. Sin duda alguna, hay que solucionar todo el tema de WebRTC y acompañarlo con una documentación clara y concisa que permita empezar a trabajar con esto ya mismo, porque las posibilidades son infinitas y marcarían realmente un antes y un después de la telefonía IP.

    • El tema del WebRTC aún falta mucho para que llegue a lo que muchos quieren.
      Para mucha gente WebRTC es lo que siempre ha sido la forma de tener un softphone web, y WebRTC está asentando las bases para ser mucho más que eso, mucho más que una manera de transmitir media entre dos puntos finales de la red sin preocuparse de NAT, seguridad, etc.

      Sobre WebRTC hay mucho que decir, quizá si nos viésemos todas las conferencias del VoIP2DAY, ElastixWorld, Astricon y KamailioWorld sobre WebRTC, podríamos entender realmente lo que se está moviendo en este mundo, pero créeme que es mucho más que "crear un softphone web para Asterisk" y por esa razón, no terminan de fijar un estándar y un funcionamiento estable como para ser incluido en un software como Asterisk.

      Asterisk ha sido compatible con WebRTC en varias ocasiones, pero esta compatibilidad debe estar "acordada" por los navegadores, porque al no ser así, como los navegadores tienen la fea costumbre de auto-actualizarse, la solución WebRTC que habías preparado, deja de ser compatible porque sí y eso no es viable.
      Hasta que los desarrolladores de WebRTC y de los navegadores no se pongan de acuerdo, será muy difícil encontrar algo WebRTC orientado a empresas sin que esté siendo actualizado a cada versión de navegador. 🙁

  • […] 14 además de las características que ya comentamos, incluirá otras nuevas que serán anunciadas en la versión Asterisk 14.0 que se proyecta, se […]

Dejar un comentario

Archivos

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales