Etiqueta: Asterisk

  • Si utilizas Asterisk 13 o anterior, ve preparándote para una versión completamente diferente

    Si utilizas Asterisk 13 o anterior, ve preparándote para una versión completamente diferente

    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).

    Créditos imagen portada

  • Asterisk 19 Released

    Asterisk 19 Released

    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.

    (más…)
  • PhoneLink configura tus teléfonos Snom desde tu Asterisk

    PhoneLink configura tus teléfonos Snom desde tu Asterisk

    Hace varios años, Digium sacó un sistema que permitía configurar automáticamente los teléfonos sin tener que acceder a ellos, únicamente aprovechando el propio Asterisk y un módulo propio llamado DPMA (Digium Phone Module for Asterisk), es más… Digium estaba tan convencido de la utilidad de este módulo que incluso lo incluyó como el primer tema de su famoso Asterisk Advanced. No obstante, aunque la idea en sí era buena, la implantación no lo era tanto, ya que tenía ciertos requerimientos que lo complicaban tanto que, al final, casi era mejor acceder a cada uno de los teléfonos y configurarlos a mano. Pero la idea en sí era muy buena. Las empresas que hacen instalaciones de sistemas basados en Asterisk (con teléfonos, gateways, etc.) necesitan de un sistema que les ayude a configurar todos los teléfonos de una sentada sin tener que ir uno por uno y reduciendo el tiempo necesario para configurarlos.

    La solución estándar siempre ha sido muy sencilla: servidor DHCP + servidor FTP + plantillas de configuración, de manera que creando una plantilla, el teléfono al encenderse se conecta al servidor DHCP para que éste le de una dirección IP, y además le dice la ruta donde se encuentra el firmware y su configuración. El teléfono se conecta al servidor FTP, se descarga la configuración y punto.

    Pero hoy día en el que muchos teléfonos no se encuentran dentro de la red local del servidor, muchos fabricantes han optado por un sistema más automático: El teléfono nada más encenderse, se conecta a un servidor propio del fabricante donde se le indica: o bien el servidor donde se encuentra la configuración, o bien directamente la configuración del teléfono en función de su dirección MAC.

    Esto implica que haya que acceder a un servicio del fabricante del teléfono y configurar manualmente los valores que va a tener ese teléfono. Es una ventaja frente a tener que acceder remotamente al teléfono y configurarlo, pero aún así, si tienes 15 o más teléfonos, esta solución no ayuda tampoco.

    Para ello, Snom ha creado PhoneLink para Asterisk: una herramienta que hace uso de un sistema propio y remoto donde los teléfonos se van a conectar para buscar su configuración personal (SRAPS – Secure Redirection And Provisioning Service) y un módulo de Asterisk que lee la configuración que tengamos en el módulo PJSIP y la exporte al SRAPS para generar automáticamente la configuración para los teléfonos que tengamos dados de alta.

    Esquema de cómo funciona el sistema PhoneLink de Snom

    Para que esto funcione bien y que Asterisk se pueda comunicar con el servidor SRAPS, hace falta primero una configuración propia en Asterisk que haremos gracias a un módulo para el PJSIP.

    [1000]
    type = phoneprovr
    endpoint = endpoint_1000
    MAC = 000413928b88
    IPUI = 0x0328D661AB
    PROFILE = snom
    OTHERVAR = othervalue
    Aquí un ejemplo de cómo sería la configuración que PhoneLink procesaría y sincronizaría con el SRAPS

    Como podéis ver, hace uso del res_phoneprov para crear una configuración específica para ese teléfono y subirla al servidor SRAPS con la misma configuración que le hemos configurado en el PJSIP.

    Una de las ventajas es que es compatible con los teléfonos Snom ya sea de escritorio, DECT o de conferencia (que básicamente son los que utilizaremos con Asterisk) y que podemos configurar prácticamente cualquier parámetro del teléfono (hasta los botones de monitorización BLF) por lo que la configuración SIEMPRE estará sincronizada y nos ahorrará bastante tiempo a la hora de cambiar la configuración o añadir nuevos terminales.

    Toda la información la podéis ver en su página web: https://service.snom.com/display/wiki/PhoneLink+for+Asterisk

    Y aquí la web con el código del proyecto que se encarga de «capturar» la información particular de los teléfonos y subirla al servidor SRAPS: https://gitlab.com/publ2/phonelink_for_asterisk

    Una solución mucho más efectiva, práctica y rápida que el dichoso DPMA de Digium. Cierto que sólo funciona con los teléfonos SNOM, pero es otra de las ventajas de utilizar este tipo de teléfonos. ¿o no?

  • Cómo evitar las llamadas comerciales

    Cómo evitar las llamadas comerciales

    Hace unas semanas, estaba haciendo pruebas con varias tarjetas SIM nuevas recién-estrenadas (es decir, que no han tenido dueño ni nada por el estilo) y mientras hacía pruebas con un móvil empiezo a recibir llamadas procedentes de varios números móviles.

    El primer pensamiento que viene a mi mente en este momento es que alguien se ha podido equivocar al marcar y ha dado casualmente con el número móvil de esa tarjeta que jamás había sido dada de alta en ningún sitio, por lo que no descuelgo, no bloqueo, nada… simplemente dejo que suene y que se canse para que verifique el número para la próxima vez. Al día siguiente, a la misma hora vuelve a llamar el mismo número pero con otra terminación. Ummm. sospechoso… esta vez sí descuelgo y hablo con la persona que me llama. Rápidamente me respondió un comercial de una compañía eléctrica…

    -«Hola buenas tardes! ¿podría hablar con el titular de esta línea?»

    ¿cómo han conseguido este número? No ha sido dada de alta en ningún momento, tiene numeración nueva, por lo que no es posible que un anterior dueño la hubiera dado de alta en alguna empresa. Hablo con el agente y le explico que este número por casualidad no pertenece a nadie, que es un número interno de pruebas y que por favor, dejen de llamar ya que esta línea no tiene dueño.

    Muy amablemente terminamos la conversación y aún así, estuve más de dos semanas recibiendo llamadas todos los días desde prácticamente el mismo número (con diferente terminación) para venderme servicios de diferentes compañías: eléctricas, telefónicas, seguros,… vamos, alguna empresa de telemarketing había hecho un barrido de todos los números de teléfono y se había puesto a llamar a todos y cada uno de los números que no fuese rechazado.

    Desconozco de leyes lo suficiente como para no estar seguro de hasta qué punto eso es ilegal en España, aunque estoy seguro que la práctica de algunas empresas de llamar a todos los números y hacer una lista de qué números responden y qué números no, no debe ser muy legal, no obstante, lo que sí tengo es el sentido común para saber que la ética de esa empresa después de indicar que ese número no pertenecía a nadie y seguir llamando, les permitiría ser capaces de venderte a su mismísima abuela moribunda si con ello ganaban un contrato.

    La AEPD (Agencia Española de Protección de Datos) publica en su página web los expedientes y sanciones a las empresas que realizan prácticas ilegales tanto por publicidad indebida como por uso de datos no autorizados para la realización de campañas de marketing y es una manera como otra cualquiera de ganar entre 2000 y 2500€ por sanción ganada de media cada vez que te llama una empresa en la que no te has dado de alta.

    La Lista Robinson es un listado de números, cuentas de email, direcciones físicas, gestionado por Adigital (La Asociación Española de la Economía Digital) que se encarga de recoger gratuitamente los datos de las personas que no quieren recibir información comercial. Por lo que si un usuario no quiere recibir publicidad en su teléfono, tan solo tiene que darse de alta en la Lista Robinson y en un plazo de 3 meses desde el momento del alta, debería dejar de recibir esas molestas llamadas o se arriesgan a una demanda por contravenir la Ley de Protección de Datos Personales y garantía de los derechos digitales.

    Las empresas de publicidad y marketing deberán a su vez comprar, consultar y eliminar de sus bases de datos todos los números que figuran en la lista Robinson. Tras los tres meses desde su alta, cualquiera que reciba una llamada comercial puede ir a la AEPD y denunciar al número de teléfono que le llame, tras lo cual se abrirá una investigación y se procederá a una sanción si se comprueba que el usuario ha recibido llamadas comerciales tras su negativa.

    No obstante, en otros países la legislación no protege de igual forma, en el continente americano se permiten incluso las «robocalls«, llamadas automatizadas con grabaciones (ya vimos en Sinologic que las llamadas automáticas con locuciones en España están prohibidas) y entonces, a falta de una legislación en este sentido, toca tirar de imaginación y evitar esas llamadas de otras formas menos contundentes.

    Para ello, Asterisk cuenta con una herramienta tan antigua como práctica. En España no es muy común, aunque también funcionaría y es el conocido «Zapateller«:

    Zapateller es una aplicación del dialplan de Asterisk que genera un tri-tono (tono SIT )… un tipo de tono telefónico que debe sonar cuando alguien llama a un número de teléfono que no está en funcionamiento.

    Ejemplo de tri-tono (SIT tone)

    En el caso en que un marcador predictivo llame a un número y suene este «tri-tono», lo más probable es que entienda que el número de teléfono no sea correcto y lo elimine de la lista para evitar perder el tiempo con él.

    Esta aplicación se suele utilizar cuando se recibe una llamada con un número oculto o con algún número conocido como «comercial». En España no tiene sentido ya que, aunque no sea legal, muchas empresas utilizan números móviles para hacer esas llamadas comerciales, pero en el continente americano sí es bastante frecuente recibir llamadas comerciales de números anónimos, por lo que es una buena forma de, no sólo evitar la llamada comercial, si no de que te quiten de su lista de clientes a los que molestar.

    TIR-SHAKEN es lo último para combatir la suplantación de identidades en redes telefónicas. Es un protocolo que impide hacer llamadas utilizando un teléfono que no se corresponde con el tuyo. De esta manera se comprueba que quien te llama es el verdadero dueño del número y no que hayan utilizado un número al azar para hacer la llamada (algo también ilegal pero que técnicamente sí se puede hacer).
    En España, esta práctica (hacer llamadas con números de otras personas o empresas) no sólo está prohibida, si no también perseguida y, gracias a la buena estructura y comunicación entre los principales operadores de España, no es difícil identificar a la empresa que realiza estas prácticas y pararle los pies rápidamente y exigirle responsabilidades legales.

  • Probamos Vosk: un ASR gratuito, libre y que no necesita Internet

    Probamos Vosk: un ASR gratuito, libre y que no necesita Internet

    Hace unos días recibo por parte de el canal de anuncios de Issabel, la compatibilidad con Vosk, un ASR gratuito, libre y offline (no necesita internet para funcionar). Issabel vuelve a adelantarse a todas las distribuciones de comunicaciones esta vez con algo que mucha gente quiere y lo han incluido ya en sus sistemas.

    Leo el comunicado y pienso… ¿Cómo??? debe tener truco…
    Conozco varios sistemas que, aprovechando el boom de la inteligencia artificial y las redes neuronales, se han lanzado a crear modelos de reconocimiento de audio muy interesantes. Hace un par de años estuvimos en el Stand de Mozilla leyendo unos textos para ayudar a enseñar al motor. No obstante, este proyecto nos había pasado desapercibido y eso que posteriormente parecía haber pasado por delante en varias ocasiones sin haberme percatado de la joya que era.

    Efectivamente, no tiene truco, la gente de Issabel no solo ha estado muy atenta si no que ha incorporado, además de muchas herramientas con las que ya cuenta, un reconocedor de audio (ASR) completamente libre y gratuito y que, a diferencia de muchos otros, no depende de terceros como Google, Amazon, Microsoft, etc.

    Vosk es el motor, una aplicación escrita en Python y basada en redes neuronales que reconoce palabras en varios idiomas (según el diccionario que le cargues) y que funciona de forma independiente (no requiere conexiones a otros sistemas) por lo que instalas el servidor, cargas el diccionario del idioma que deseas, lo ejecutas y ya está el puerto listo para enviarle audio y que el motor lo convierta a texto.

    Investigando, me di cuenta que lo presentaron en la ClueCon 2020 (el año pasado) donde explicaron cómo funciona y qué ventajas tiene. Podéis ver la presentación aquí:

    He probado varios sistemas similares y por lo general, los ASR libres, en comparación con los sistemas comerciales, no eran muy competitivos, entiendo que un ASR es un sistema super-complejo y crear uno que funcione bien requiere de un gran esfuerzo económico que muchas veces sólo es posible si hay una empresa detrás, pero en esta ocasión la sorpresa ha sido mayúscula.

    Echándole un vistazo a su web, el proyecto es completamente transparente… publican todas las presentaciones, todas las fórmulas, ecuaciones y sistemas que utilizan para el entrenamiento y análisis de la voz y posterior conversión en palabras.

    También publican ejemplos y demos para que cualquiera pueda probarlo con varios comandos. Esto también lo conocía en otros sistemas, funciona muy bien en sus ejemplos pero luego uno prueba una conversación normal y no da con una traducción medianamente aceptable.

    Así que sin más… me he puesto manos a la obra y por probar una grabación mía:

    ejemplo de audio para comprobar la calidad del reconocedor de audio

    Ejecuto el comando que se conecta al servidor y devuelve lo siguiente:

    {
       "result" : [{
           "conf" : 0.572926,
           "end" : 0.900000,
           "start" : 0.660000,
           "word" : "hola"
         }, {
           "conf" : 0.976447,
           "end" : 1.427432,
           "start" : 1.151597,
           "word" : "hola"
         }, {
           "conf" : 0.841578,
           "end" : 1.830000,
           "start" : 1.530000,
           "word" : "esto"
         }, {
           "conf" : 0.998902,
           "end" : 1.890000,
           "start" : 1.830000,
           "word" : "es"
         }, {
           "conf" : 1.000000,
           "end" : 2.070000,
           "start" : 1.890000,
           "word" : "una"
         }, {
           "conf" : 1.000000,
           "end" : 2.460000,
           "start" : 2.070000,
           "word" : "prueba"
         }],
       "text" : "hola hola esto es una prueba"
     }

    Como podéis ver, aunque falta el primer «hola» (en la grabación eran 3 ‘hola’) el reconocimiento es perfecto y tampoco es que sea una conversación muy difícil.

    Probando algo más complejo:

    El resultado ha sido este:

     "text" : "una aplicación escrita en país y basada en redes neuronales que reconoce palabras en varios idiomas",
    "text" : "y que funciona de forma independiente por lo que instala servidor cargas en diccionario idioma que deseas lo ejecutas y ya hasta el puerto listo para enviarle el audio"
    }

    Como podéis ver… el reconocimiento es prácticamente perfecto. (si, fallan algunas palabras… pero ¿qué esperabas?)

    Instalación

    La instalación del servidor no puede ser más sencilla:

    docker run -d -p 2700:2700 alphacep/kaldi-es:latest

    Ejecutamos este docker que corre en background y nos abre el puerto 2700 para que nos conectemos vía websocket y enviarle el audio.

    Conectándonos al servidor Vosk

    Luego tan solo hay que descargar un cliente websocket para enviarle el archivo wav (formateado a 8Khz y mono)

    git clone https://github.com/alphacep/vosk-server
    cd vosk-server/websocket
    ./test.py test.wav

    Y si le pasáis el archivo wav que tengáis… veréis cómo lo reconoce.

    Usando Asterisk para conectar el ASR de Vosk

    La gente de AlphaCep ha publicado un módulo para Asterisk, FreeSwitch y Jigasi (el módulo que utiliza Jitsi)

    https://github.com/alphacep/vosk-asterisk

    De esta manera, podéis utilizar el reconocedor de audio directamente desde el Dialplan de Asterisk:

    [internal]
    exten = 1,1,Answer 
    same = n,Wait(1) 
    same = n,SpeechCreate 
    same = n,SpeechBackground(hello) 
    same = n,Verbose(0,Result was ${SPEECH_TEXT(0)})

    Eso sí, nos avisan en varios sitios que el sistema de reconocimiento requiere de un sistema potente, ya que consume bastante memoria y procesador cada vez que tiene que hacer un reconocimiento, pero eso es algo común en cualquier ASR hospedado por nosotros, así que a tenerlo en cuenta si queremos instalarlo en nuestro sistema de comunicaciones.

    Toda la información en la página de Vosk: https://alphacephei.com/vosk/
    Su página para estar al día: https://alphacephei.com/en/news.html
    Y la guía para configurarlo en Issabel: https://t.me/Issabel_channel/4

  • Desarrollo de aplicaciones VoIP

    Desarrollo de aplicaciones VoIP

    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.

  • Si utilizas PJSIP, probablemente deberías actualizar

    Si utilizas PJSIP, probablemente deberías actualizar

    Hace algún tiempo avisamos que Sinologic no publicaría noticias relacionadas con seguridad. Principalmente porque uno debe ser responsable de estar al día de todo lo que surge en cuanto a vulnerabilidades, fallos de seguridad, etc. Por este motivo, todos deberíamos tener en nuestras pantallas un sistema tipo «telex» que nos informe en tiempo real de los problemas que ocurren.

    No obstante, y por diversos motivos y proyectos personales, estoy un poco más en el día a día de ciertos temas relacionados con la seguridad, el fraude telefónico y cómo evitarlos, por lo que acabo de ver una vulnerabilidad que merece la pena comentar aquí:

    Una vulnerabilidad de PJSIP en un paquete INVITE malintencionado podría provocar un crash de Asterisk.

    https://downloads.asterisk.org/pub/security/AST-2020-001.html

    Concretamente, este repositorio lo explica con un ejemplo para probarlo:

    https://github.com/EnableSecurity/advisories/tree/master/ES2020-02-asterisk-tcp-invite-crash

    Este bug ha sido resuelto en las versiones: 13.37.1, 16.14.1, 17.8.1, y 18.0.1

    Así que si tenéis una versión anterior y utilizáis PJSIP como el 33% de los usuarios encuestados de Sinologic, os recomendamos actualizar a la siguiente versión cuanto antes.

  • Asterisk 18 ya disponible

    Asterisk 18 ya disponible

    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:

    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.

    ChangeLog: https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-18.0.0

    Descarga: https://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-18.0.0.tar.gz

  • Resultados de la 1ª encuesta sobre Asterisk…

    Resultados de la 1ª encuesta sobre Asterisk…

    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.

  • Preguntamos a los usuarios sobre Asterisk

    Preguntamos a los usuarios sobre Asterisk

    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.


    > 📋 Acceso a la encuesta


    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.