Etiqueta: dialplan

  • Ley Kari, o por qué lo estamos haciendo al revés

    Ley Kari, o por qué lo estamos haciendo al revés

    Por este tweet de @Servitux, me entero de una nueva Ley Kari que a pesar de llevar en circulación más de 4 años, fue aprobada en 2018 y entra obligatoriamente en vigor en los EEUU el próximo 16 de Febrero de 2020 y obliga a todas las centralitas telefónicas a modificar su dialplan para que llamar a los servicios de emergencia no requiera marcar de ningún prefijo.

    Esta Ley de Kari comenzó en diciembre de 2013, cuando una mujer (Kari Hunt), fue asesinada por su esposo. La hija de Hunt, de 9 años, intentó marcar el número de emergencias «9-1-1», pero no pudo hacer dicha llamada ya que el teléfono requería marcar el prefijo «9» para poder acceder a una línea exterior. La familia de la mujer asesinada han estado trabajado incansablemente desde entonces para lograr que esto no vuelva a ocurrir.

    Por desgracia, actualmente no siempre es así

    En España ( y seguro que en Latinoamérica también) es habitual, y una guerra constante, el hecho de utilizar un prefijo similar para «obtener línea externa» y poder hacer llamadas al exterior. Muchas de las centralitas antiguas ya acostumbraron a todos a utilizar un prefijo (generalmente en ‘0’) para obtener línea y poder hacer llamadas salientes, mientras que si se marca un número sin el prefijo, generalmente se considera que es una extensión.

    Siempre he defendido el hecho de poder llamar al exterior sin necesidad de prefijo, «como si llamaras desde casa» lo suelo llamar yo, aunque eso puede dar lugar a ciertas colisiones, ya que la CNMC tiene dispuestos números muy variados que hacen difícil no coincidir, pero para eso, lo mejor es conocer los rangos y ver qué podemos utilizar para que no haya conflictos.

    Hace varios años conocí una empresa con muchas extensiones y cuando vi que las extensiones tenían el rango 1xx, pregunté qué pasaba si alguien quería llamar a emergencias y marcaba el 112, rápidamente me dijeron que en ese caso, sonaría el teléfono de «Enrique» (nombre ficticio) que gustosamente les vendería algo. En un momento de angustia y necesidad, poder llamar a un número de emergencia desde cualquier teléfono debería ser algo rápido para cualquiera que sea o no de la empresa.

    Hasta los fabricantes de teléfonos lo tienen claro

    De hecho, los teléfonos VoIP suelen venir de fábrica con un «dialplan de marcación rápida» que, al marcar un número de emergencia (911, 112, etc.) el teléfono no espera los típicos 3 segundos de cortesía antes de lanzarla llamada, por lo que si, por ejemplo, queremos marcar el número 1124, veremos como la llamada se lanza antes de marcar el 4, haciendo la llamada al 112 anterior si no hemos deshabilitado esta opción previamente. Esta opción suele deshabilitarse a mano en la configuración justo porque hay empresas que usan como extensiones las 1XX en lugar de las 2XX que debería ser lo habitual.

    Propuestas sencillas

    En una empresa normal con menos de 100 extensiones quizá lo más habitual son las llamadas internas, por lo que en lugar de marcar un prefijo, suelen usar las extensiones 1XX. En este caso siempre es más recomendable utilizar los 2XX, 3XX, 4XX, 5XX, 6XX, 7XX, 8XX o 9XX que están libres de ser asignados en el exterior.

    Si la empresa tiene más de 1000 extensiones, siempre se pueden usar las extensiones del 2000 hasta el 9999. (son 7999 extensiones disponibles). Aún así, hay quien todavía configura la centralita para tener que marcar el ‘0’ antes de un número externo obligando a alguien a adaptar su marcación habitual en función de dónde se encuentre. A partir de 5000 extensiones, es mejor trabajar directamente con DIDs geográficos en el peor de los casos.

    Para servicios internos (loguearse en una cola, una prueba de eco, escuchar una grabación, etc.) es cuando podemos utilizar los prefijos como *XXX (por ejemplo) o bien algun prefijo no asignado como el 22XXX, 33XXX o 44XXX.

    El lado contrario de todo esto…

    Por el contrario, en otro viaje en el extranjero conocí una empresa en el que cualquier trabajador podía usar cualquier teléfono de la empresa pero para desbloquearlo tenía que meter su código pin de 6 dígitos (que no quedaba reflejado en la pantalla) y posteriormente el número de teléfono destino. Esas llamadas quedaban reflejadas en la lista de llamadas de dicho empleado. En aquel entonces, como nosotros no éramos empleados de la empresa no podíamos ni siquiera hacer llamadas de emergencias al no disponer de ningún código válido. Este tipo de causas son las que se quieren evitar con esta nueva ley que, seguro que tarde o temprano llegarán a Europa.

    Plataforma change.org con la petición: https://www.change.org/p/require-all-mlts-pbx-phones-dial-911-easily-help-enact-kari-s-law

  • Cómo utilizar variables JSON en el dialplan de Asterisk

    Cómo utilizar variables JSON en el dialplan de Asterisk

    coding-header

    Nuestro amigo Diogo Serra nos enseña un proyecto muy interesante para trabajar con variables en el dialplan. Consiste en una función que interpreta una cadena JSON obtenida tras consultar un servicio web (utilizando la función CURL o similar) y lo convierte en variables de canal, permitiendo hacer uso de ellas en nuestro dialplan.

    Aquí podéis ver una idea básica de esta función:

    exten => s,n,set(json=${CURL(http://api.dataprovider.com/somefunction?param=value)})
    exten => s,n,set(myvariable=${JSONELEMENT(json,path/to/element)})

     

    La función CURL devuelve una cadena JSON del tipo: {«nombre»:»Elio Rojano», «role»:»usuario»} y con la función JSONELEMENT podemos preguntar por los campos del JSON y asignarlo a variables de canal que pueden ser utilizadas en nuestro dialplan.

    Gracias a esta función (que tiene ya su tiempo) y que está disponible en Github, podemos crear dialplan algo más complejos de los habituales y personalizados para determinados usuarios consultando esta información en servicios web que serán las que nos devuelvan el JSON adecuado en cada momento.

    Más información: https://github.com/drivefast/asterisk-res_json

     

  • Por qué es mejor editar tus propios archivos de configuración

    Siguiendo una línea de opinión personal, y tal y como prometí en el anterior artículo Porqué recomiendo Debian y no CentOS, escribo sobre porqué es mejor configurar Asterisk mediante archivos de configuración y no mediante un intefaz web generalista como FreePBX.

    Como digo, esta es una opinión personal, no es una tautología ni espero llevar razón en todo. Cuando hablo de interfaces web, hablo principalmente de interfaces web de configuración de Asterisk de forma generalista: FreePBX, Asterisk-GUI, y en cierta medida, el interfaz web de configuración de Elastix entre otros, por ser los más comunes. Fuera quedan interfaces web propios, desarrollados con una orientación especial por empresas para sus clientes, o incluso otros generalistas pero orientados de forma particular tal y como explicaré a continuación que si bien me parecen sistemas ideales para alguien que quiere configurar «su propio Asterisk» para hacer pruebas, o incluso para su propia empresa, no lo veo eficiente, serio ni profesional como para ser incluido dentro de un sistema profesional de comunicaciones.

    Dar gracias a todos aquellos que esperaban impacientemente un artículo como este, bien por ser un «tema flame» que causa ampollas entre los defensores de los interfaces webs y los defensores de la línea de comandos. No hay necesidad de ser extremo en ningún punto, ni ser «pro-interfaces» ni ser «pro-consola«, aquellos que son «pro-interfaces» saben que a menudo (y más frecuentemente de lo que quisieran) necesitan de una consola, y aquellos que son «pro-consola» seguro que tienen instalado un interfaz gráfico donde impera KDE o Gnome o incluso XFce o WindowMaker.

    Quiero dejar claro que trabajo a diario con interfaces webs, por lo que conozco bastante FreePBX, Asterisk-GUI y otros interfaces generalistas de facturación, de grabación y algunos otros, menos conocidos, que considero proyectos perfectos para la función que deben tener: un sistema de comunicaciones pequeño, bien controlado, bien configurado y sabiendo qué hacen y cómo lo hacen además hacer lo que debe hacer. Este artículo va en otro sentido, y no critico ningún proyecto opensource que, como siempre dijo, merecen todo mi respeto y admiración tanto por parte de sus desarrolladores como el de sus usuarios.

    Cuando hablo de «editar tus propios archivos de configuración» me refiero principalmente a crear tu propia configuración a mano, y no crearlo utilizando un interfaz web, no significa que la configuración deba ser mediante archivos de configuración, también puede ser vía base de datos o cualquier otra forma de configuración que permita realizar cualquier acción que deseemos o necesitemos y podamos controlar a la perfección tal y como a continuación explico.

    (más…)

  • Actualización importante en los dialplans de Asterisk

    De vez en cuando, tenemos que hacernos eco de vulnerabilidades importantes que nos obligan a actualizar o a protegernos y necesitamos estar preparados o bien tener siempre a alguien a mano para llevar a cabo estas actualizaciones y evitarnos algún que otro susto.

    Esta vez, no es ninguna vulnerabilidad, simplemente que ayer, la CMT anunció que un nuevo prefijo para móviles empezaba a funcionar en España, son los números de móviles que comienzan por 7 además de por 6.

    exten => _6XXXXXXXX,1,NoOp(Llamada a Móviles)
    exten => _6XXXXXXXX,n,…

    Hay que cambiarlo por:

    exten => _[67]XXXXXXXX,1,NoOp(Llamada a Móviles)
    exten => _[67]XXXXXXXX,n,…

    Además de esto, hay que recordar que los números fijos nacionales en España, no empiezan únicamente por 9 si no también por 8, así que deberíamos tener algo como:

    exten => _[89]ZXXXXXXX,1,NoOp(Llamada a Números Fijos)
    exten => _[89]ZXXXXXXX,n,…

    Puede parecer algo evidente, pero si estos cambios no son tenidos en cuenta en nuestros sistemas, es probable que muy pronto recibamos alguna llamada de algún cliente furioso porque no puede llamar a los nuevos prefijos, y como siempre, es mejor prevenir que curar.

  • Visual Dialplan se hace mayor: Visual Dialplan 3

    Mucho ha llovido ya desde que presentamos la versión 1.2 de este software visual para programar dialplans y mucho ha cambiado desde entonces.

    Entre otras mejoras, la compatibilidad con Linux es una de las necesidades básicas y requerimientos mínimos por lo que dejé de probarlo, ahora por fin dispone de una versión Linux (hace ya tiempo, aunque no lo había vuelto a ver desde entonces).

    La nueva versión 3 incorpora soporte de bases de datos MSSQL, MySQL, Postgres, Sybase, HSQL, … además de servicios y servidores de email como Gmail, Sendmail, Exim etc. a la vez que mejora la integración con otros interfaces y distribuciones como FreePBX, PBX-in-a-Flash, PIAF o Elastix.

    Parece ser que han mejorado bastante la integración con Colas, faxes, CDR y soporte de DAHDI y SIP. 🙂

    Como ya dije la otra vez, no soy muy amigo de los interfaces gráficos, simplemente porque creo que sabiendo cómo funcionan las cosas, es más rápido escribir con el teclado que moviendo el ratón y pulsando botones. Además los interfaces gráficos limitan bastante la potencia (pese a que todos mencionen el ‘*_custom.conf‘) soy de los que prefiero un dialplan sencillo, limpio y fácil de entender en lugar de algo «fácil de hacer» pero imposible de depurar, quizá por esto nunca me ha hecho gracia los interfaces web y mucho menos para algo profesional o del que dependa una empresa.

    No obstante Visual Dialplan 3 combina ambos casos:

    – No ensucia el dialplan (ya que no incluye nada propio, y únicamente traduce lo «visual» a «texto simple»).
    – Es más atractivo para alguien acostumbrado a «los botones» y a manejarse con Windows.

    Además incorpora de una ayuda contextual para aquellos que no sepan muy bien el funcionamiento de alguna aplicación o alguna función de Asterisk. 🙂

    Podéis descargar una demo de 30 días para Windows o para Linux en su página web:
    http://www.apstel.com/download/

  • Una nueva versión de Asterisk corrige el dialplan injection

    Hace una semana Olle Johansson anunció un fallo de seguridad bastante interesante, pero no me atreví a escribir sobre él hasta que no lo hubiésemos probado y al fín lo hicimos, y los resultados son escalofriantes:

    Imaginemos que utilizamos un terminal IP (o softphone) con una cuenta limitada a extensiones SIP, en principio sólo podríamos llamar a extensiones SIP, pero el bug explica cómo aprovechar una mala programacion del dialplan y poder llamar a donde queramos:

    El fallo de seguridad ocurre principalmente si tenemos una línea como esta:

    exten=>_X.,1,Dial(SIP/${EXTEN})

    De manera que cualquier número que marquemos, intentará llamar por SIP:

    Si marcamos 800, en el dialplan se ejecutará: exten=>800,1,Dial(SIP/800)
    Si queremos llamar hacia el exterior, marcamos 952123456, y en el dialplan se ejecutará: exten=>952123456,1,Dial(SIP/952123456)

    Claro, que si no tenemos una extensión SIP con ese número, no hará nada y colgará la llamada.
    Pero como todos ‘deberíamos’ saber, el comodín punto ‘.’ admite cualquier cosa y tantas como queramos (símbolos, letras, etc) por lo que si en lugar de utilizar un terminal IP utilizamos un softphone, podríamos llamar a nombres o a cualquier cosa que podamos escribir:

    Si marcamos 3pepota, en el dialplan se ejecutará:
    exten=>3pepota,1,Dial(SIP/3pepota)

    Tampoco llamará a nadie, ya que la extensión 3pepota no existe.

    (más…)

  • Lo que el usuario de una distribución con Asterisk no vé

    A menudo recibo emails donde gente muy preparada y con muchos conocimientos sobre redes e informática buscan ayuda para solucionar algún problema que les ocurre cuando configuran su sistema Trixbox, Elastix, AsteriskNow, y no funciona como ellos esperaban.

    Es entonces cuando la gente que responde a estos emails le preguntan acerca de paquetes SIP, parámetros de configuración, o le sugieren determinados valores a ciertos parámetros que no han escuchado ni visto en su vida. Ocurre que tras estas respuestas el usuario se vé en la necesidad de tener que entrar a mano a una consola en modo texto y editar un archivo o ejecutar un comando, algo que, en el 80% de los usuarios que utilizan este tipo de distribuciones para montar su sistema de comunicaciones, no saben cómo se hace o directamente jamás lo han hecho.

    Los usuarios de distribuciones controladas por interfaces web suelen olvidar (o no quieren reconocer) que toda interfaz web es creada con un objetivo: simplificar la configuración y gestión de una aplicación (en este caso, de Asterisk), esta simplificación tiene un efecto muy negativo, impide realizar tareas que no han sido previamente preparadas por los creadores de dicho interfaz o incluso han sido desechadas por su complejidad y poco útil para un público general, se dice entonces que esa distribución está «a merced» de lo que permita hacer el interfaz web. En muchos casos he visto cómo gente con grandes conocimientos de redes, Asterisk y voip, han dicho que XXXXX no se puede hacer, simplemente porque el interfaz web no lo permite. Esto, además de no dejar en buen lugar a Asterisk, demuestra una falsa limitación que el comercial, conociendo las características de una aplicación tan versatil como es Asterisk, sí que anunció que era posible a su cliente.

    Alguna que otra vez me he encontrado con mensajes de usuarios con Trixbox o Elastix que no podían hacer transferencias, o que cuando intentaban llamar a una extensión esta no se encontraba disponible pese a haberse configurado corréctamente. La solución de estos problemas y otros miles, se podría solucionar de una forma muy sencilla mirando la configuración y comprobando que estos parámetros son correctos, o simplemente comprobando que el dialplan hace lo que se supone que debería hacer, pero para hacer un interfaz web que ayude a simplificar la configuración se requieren de macros, includes y variables extras que ayuden a convertir lo que el usuario quiere hacer a través de una web, a un código medianamente funcional y limitado a lo que se pueda hacer.

    Esa limitación no existe en un usuario final que únicamente quiere configurar 5 extensiones y 2 líneas analógicas que atiendan a una cola, pero en usuarios «avanzados» y «profesionales» esa limitación, no únicamente limita su trabajo, si no que le impide «controlar» el verdadero funcionamiento que está realizando su sistema Asterisk.

    Cuando un usuario se encuentra con algún problema, puede ser debido a un fallo de configuración –y de conocimiento– como colocar «inband» en lugar de «outofband» en alguna pestaña del interfaz web porque desconoce para qué sirve estos parámetros, pero el usuario avanzado, que sí sabe lo que significan, debe poder entrar en Asterisk y ver en la consola –que para eso está– qué es exáctamente lo que Asterisk está ejecutando, para poder encontrar el error, y el simple hecho de utilizar un interfaz web que, para simplificar la configuración, utilice macros, includes y variables, se hace inviable su lectura por la cantidad de código que escribe un FreePBX para hacer una simple llamada.

    En muchos casos, y después de comentar este problema con compañeros que trabajan con distribuciones de este tipo, suelen contestar que sus clientes necesitan de un interfaz web para poder añadir extensiones o cambiar el dialplan, es entonces cuando se llega al kit de la cuestión, –¿qué usuario final cambia su dialplan?- ¿es la responsabilidad de un usuario final poder cambiar un dialplan? ¿qué usuario final sabe para qué sirve cada valor de cada pestaña de cada campo necesario para añadir una extensión o crear una cola? Lo único que el usuario final sabe es que quiere añadir una extensión y no quiere prestar atención a los distintos parámetros que conlleva esta decisión, es por eso por lo que hay dos posibilidades:

    – Hacerle un interfaz web a medida que le permita entrar y añadir lo que el usuario avanzado quiera que añada. (para eso hay diferentes maneras: AJAM, AMI, PHP, etc…)

    – Que llame por teléfono y diga que quiere añadir una extensión, en cuyo caso será el usuario avanzado el que lo haga y sea responsable de estos cambios. (quizá no sea lo más agradable, pero el usuario final lo agradecerá y el usuario avanzado controlará que todo sigue funcionando corréctamente).

    IMHO.

    P.D.: Esto por supuesto es a nivel general, siempre hay excepciones.

  • Curso de Asterisk Bootcamp: dia 3

    Otro día frenético, si yo he acabado reventado no me quiero ni imaginar como habrán acabado los pobres asistentes del curso.

    Dialplan, más dialplan, más dialplan aún y mañana aún más, muchos conceptos y muchos laboratorios donde la gente tiene que aprender para continuar adelante con nuevos conceptos.

    Pufff, espero que la gente descanse para mañana que haremos la gran Asterisk Night Party, y el día siguiente más Bootcamp y el examen dCap.


  • DialogPallete: Un programador visual de dialplan libre

    Bytecoders nos presenta una aplicación bastante curiosa que nos permite programar un dialplan para Asterisk de forma completamente visual como el conocido VisualDialplan pero a diferencia de este último, su código fuente se distribuye bajo licencia GPL: DialogPallete.

    Como podeis ver, este tipo de aplicaciones son muy espectaculares a la hora de hacer un dialplan sencillo, aunque dudo bastante de la potencia ante algunas configuraciones más complicadas, no obstante su función la cumple: facilitar la programación y edición de un dialplan a manos de usuarios sin conocimientos avanzados.

    DialogPallete funciona bajo Linux y ha sido desarrollado en C++ y Python junto con las librerías QT3.

    En el foro de DialogPallete podeis encontrar ayuda sobre cómo instalarlo y configurarlo aunque, como bien indica Bytecoders, el desarrollo parece haber sido suspendido ya que la última versión salió hace más de 2 años.

    La verdad es que me llama la atención la similitud de VisualDialplan y DialogPallete, aunque tras echar un rápido vistazo descubro que los autores no son los mismos y de hecho están en diferentes países por lo que puede ser simplemente casualidad el parecido entre estas dos aplicaciones y parece que VisualDialplan lleva la delantera al ser un proyecto activo y con continuas actualizaciones (la última versión soporta Asterisk 1.4) algo muy importante hoy día es mantener este tipo de proyectos bien actualizados. Pero encontrar una versión libre puede hacer renacer este tipo de aplicaciones tanto por el autor como por cualquier otro usuario interesado en continuar el proyecto, esto ratifica el hecho de que el software libre ayuda a evolucionar y a mejorar. 🙂

    Enlace: http://dialogpalette.sourceforge.net/

  • Cómo ver tu dialplan gráficamente

    Leyendo Asterisk-Java me encuentro que el autor acaba de desarrollar una aplicación de código abierto (cómo no, escrita en Java) que lee nuestro archivo ‘extensions.conf‘ y nos genera un grafo con la estructura de nuestro dialplan.

    Desconozco realmente la finalidad de esta aplicación, aunque imagino que puede estar bien para descubrir contextos que no están enlazados y por lo tanto, que «ensucian» y dificultan la lectura.

    La aplicación que permite «dibujar» los grafos base se llama Egonet y en la página de Asterisk-Java teneis el código fuente.