Etiqueta: DAHDI

  • Entendiendo un PRI INTENSIVE DEBUG SPAN X

    Una línea de primario no es un tipo de línea que podamos tener cómodamente en casa ya que está pensado principalmente para empresas con un gran número de llamadas entrantes y/o salientes, por lo que muchos de los usuarios que no trabajan con este tipo de líneas se encuentran con un gran vacío de documentación útil que pueda ayudarles a detectar dónde están los errores. Desde Sinologic vamos a dar algunas claves importantes para detectar errores, y evitar el «choque» que puede presentarse con el operador cuando una línea de este tipo no funciona como debiera.

    No deberíamos decir siquiera que, un primario es una comunicación entre dos sistemas (nuestro Asterisk y el operador) y, como tal, debemos tener en común los distintos parámetros que conforman la configuración de este tipo de líneas. De poco nos sirve que el operador nos provea de un primario y no nos indique la señalización, quién actúa como fuente de reloj o si disponemos de CRC4 o no. También hay que tener en cuenta que, mientras en Europa, Ásia y África se sigue un estándar bastante estricto sobre los parámetros, en América, Australia o Japón no existe esta «ventaja» y hay que conocer bastante bien todos los parámetros de la línea de primarios que nos ofrece el operador para conseguir configurarla correctamente.

    Pero aún así nos encontramos con que, aun habiendo configurado «aparentemente» bien el primario, aparecen errores, caídas de llamadas, bloqueos de canales, imposibilidad de realizar llamadas, etc. Lo primero que hemos hecho es aumentar el debug del sistema buscando errores que puedan darse (en el archivo /etc/asterisk/logger.conf, habilitando el parámetro ‘debug‘ en ‘console’ o en ‘full’) de esta forma podremos ver si aparece algún mensaje de error que no debería ser, identificándola, entendiendo qué dice y buscando información sobre qué significa y cómo solucionarla.

    (más…)

  • Los foneBridge2 de Redfone serán soportados por DAHDI

    Después de más de 2 años con los primeros intentos de incluir los módulos de los foneBridge2 en el paquete oficial de DAHDI, parece ser que por fín se ha logrado incluir estos en la versión trunk que incluye los principales cambios que en cierto tiempo pasarán a formar parte de la versión estable.

    Un de los «mínimos inconvenientes» a la hora de instalar un foneBridge2 es, sin duda, tener que utilizar un paquete DAHDI especial que siempre se ha venido descargando de la página de soporte de Redfone, y gracias a la documentación y a los distintos paquetes que podemos encontrar, la instalación siempre ha sido bastante sencilla y rápida. No obstante el uso de un foneBridge2 siempre ha requerido de algunos «trucos» que nos pueden extrañar poco habituales como la obligación de desinstalar el script de inicio que incluye DAHDI cuando se instala el paquete y sustituirlo por uno especial de Redfone para evitar mensajes extraños o fallos de incompatibilidad entre el módulo tdmoe que ya trae DAHDI con el módulo tdmoe multiframe que es el que utiliza Redfone, algo que podremos evitar una vez sea incluido en el driver oficial.

    Esto sin duda mejorará el soporte y la sensación general de que nuestro dispositivo está bien soportado. Ya lo estaba por supuesto ya que hay una gran cantidad de usuarios con excelentes opiniones y críticas sobre este dispositivos, y aquellos que tienen alguna incidencia, la gente del soporte técnico de Redfone hace lo imposible para que el cliente quede satisfecho. Esto es realmente digno de admirar hoy día y ofrece una total tranquilidad y seguridad a aquellos usuarios que optan por esta solución.

    En la página de cuestiones de Asterisk se puede ver el nuevo módulo que ha sido añadido por JBenden al trunk de Asterisk: https://issues.asterisk.org/view.php?id=13483

    Muchas gracias a Jorge Churio por el aviso.

  • Nueva versión de DAHDI incluye muchas novedades

    La nueva versión de DAHDI 2.2.1, además de mejorar algunas características muy importantes como el rendimiento de las tarjetas Digium de primarios y analógicas, añade soporte para tarjetas RDSI Básicas de otras marcas.

    No podía ser de otra forma, parecía que no iban a llegar nunca las modificaciones realizadas por Tzafrir y Odicha (y otros), al driver que da soporte a las Digium B410P para que fuese compatibles con otras tarjetas RDSI como las Junghanns, Beronet y Openvox, eso sí el soporte de BRI mediante DAHDI en Asterisk sigue estando en la versión 1.6 (o en 1.4 mediante Asterisk-ES-RSP).

    Otra de las modificaciones interesantes es una mejora en el cancelador de eco hardware de las tarjetas Digium analógicas.

    La lista completa de cambios de esta nueva versión la podeis encontrar en el ChangeLog correspondiente.

    Y por supuesto, el enlace para descargarlo aquí:
    http://downloads.asterisk.org/pub/telephony/dahdi-linux

  • Cómo actualizar Asterisk

    Lo primero que hay que saber antes de actualizar un Asterisk es si la versión a la que vamos a actualizar es la más conveniente. Partiremos de la base de que cuanto más avanzada sea una versión, más estable será.

    Siempre hemos sido de la opinión que cuando un sistema funciona, no debemos cambiarla a menos que:
    – Exista un fallo de seguridad que esté solucionado en la siguiente versión.
    – Necesitemos alguna característica que no venga incluida en la versión actual.

    upgrade_AsteriskPara aquellos que trabajan con Asterisk 1.0 o incluso Asterisk 1.2 la actualización es prácticamente necesaria por las mejoras en el funcionamiento de muchos servicios y de hecho, se aconseja pasar a la 1.4 o incluso a la 1.6.

    Para aquellos que trabajan con Asterisk 1.4 la actualización debería ser siempre a la última disponible (cierto que han existido algunas versiones un poco ‘verdes’ -de la 1.4.23 a la 1.4.26- pero parece ser que cualquier otra versión superior se considerará suficientemente estable para un sistema en producción.
    Para aquellos que trabajan con Asterisk 1.6.0 la actualización debe seguir dentro de la misma rama (en un sistema en producción, nunca saltar a la 1.6.1 hasta que se considere estable).

    Si realmente estais interesados en actualizar Asterisk por algún motivo, vamos a ver qué tenemos que tener en cuenta y cómo podemos hacerlo.

    (más…)

  • Cómo instalar una tarjeta RDSI BRI con DAHDI

    Un poco de Historia …

    Billion RDSI

    Las líneas RDSI Básicas siempre han sido una gran alternativa a las líneas analógicas por muchos motivos: flexibilidad, calidad de audio, ausencia de ruidos, ausencia de problemas de eco, y un largo etcétera que forman una de las mejores alternativas calidad-precio para aquellas empresas que quieren tener varias líneas con el mismo número.

     

    No obstante, el hecho que en EEUU y en algunos países de sudamérica las RDSI Básicas (también conocidas como BRI) no sea un tipo de línea muy extendido ha hecho que muchos fabricantes no lo hayan tomado en serio a la hora de desarrollar sus soluciones hardware, es por esto por lo que los primeros fabricantes que ofrecieron tarjetas RDSI Básicas compatibles con Asterisk a bajo coste fueron justamente los alemanes Junghanns y Beronet, un país donde las líneas BRI son tan habituales como las analógicas en cualquier otro país.

     

    Estos fabricantes no sólo crearon el hardware necesario si no también desarrollaron los drivers necesarios para utilizar dichas tarjetas con Asterisk. Así Junghanns creó su famoso paquete BriStuff y Beronet se centró en otro sistema llamado mISDN.

    Cuando Digium lanzó su conocida tarjeta B410P, se tuvo que decantar por utilizar el sistema de Junghanns o el de Beronet y finalmente se decidió por mISDN, un controlador RDSI BRI basado en estándares abiertos y compatible no únicamente con Asterisk si no con otras aplicaciones.

    Sangoma también creó su tarjeta A500 para RDSI BRI y en lugar de utilizar las opciones disponibles, continuaron utilizando su propio paquete de drivers basados en la idea de que sirviera no solo para voz, si no también para datos: wanpipe.

    Junghanns dejó de ofrecer actualizaciones de su BriStuff tan habitualmente como lo venía haciendo y se echaba en falta drivers para utilizar sus tarjetas con las últimas versiones de Asterisk. Beronet por contra utiliza mISDN que actualmente no tiene apenas actualizaciones y tras las últimas versiones de Kernel de Linux (los kernels superiores al 2.6.18) ha perdido la compatibilidad y no funciona como se espera.

    En este momento de incertidumbre, varios desarrolladores Digium, Xorcom, y algunos más empezaron a desarrollar los nuevos drivers para tarjetas BRI bajo DAHDI basándose en el driver de Junghanns (qozap y zaphfc) para crear el nuevo driver para la B410P bajo el nombre wcb410x dentro del paquete DAHDI.

    Pero ocurre que este añadido, suponía darle soporte de BRI también al Asterisk 1.4 cuando esta versión había sido «congelada» y únicamente se puede modificar para solucionar bugs y no para añadir nuevas características, así que el soporte BRI de DAHDI sólo está disponible para Asterisk 1.6.

    Entonces ahora mismo nos encontramos con un kernel >2.6.18, Qozap con una versión para Asterisk 1.2 o Asterisk 1.4 compatible sólo para tarjetas Junghanns, mISDN que no funciona corréctamente y el soporte BRI en DAHDI sólo para Asterisk 1.6. ¿Qué hacemos si queremos instalar una tarjeta RDSI BRI en 1.4?

    Ahí es donde buscamos las soluciones y hay dos posibilidades:

    – Actualizar a Asterisk 1.6.0.
    Con lo que ya tendríamos soporte BRI con DAHDI y las tarjetas BRI serían dispositivos del mismo tipo que cualquier tarjeta analógica.

    – Actualizar a Asterisk-ES-RSP 1.4.
    Con lo que tendremos una versión de Asterisk 1.4 modificado con el soporte para tarjetas y señalización BRI.

    Esta es sin duda la elección a tener en cuenta ya que el resto de opciones son bastante más complicadas (como por ejemplo desactualizar el kernel para que mISDN siga funcionando, o utilizar una versión antigua de Asterisk para utilizar BriStuff).

    La pega de estas soluciones es que el soporte de BRI en DAHDI, tanto en 1.6 como en 1.4 es que cada fabricante utiliza un identificador para cada versión de su tarjeta, y DAHDI aún no las tiene todas, de manera que, aunque DAHDI sea compatible con Junghanns y Beronet, puede que haya una versión de la tarjeta que aún no haya sido incluida como soportada.

     

    Dando soporte a una tarjeta BRI no reconocida por DAHDI…

    Para ello, si disponemos de una tarjeta con chipset HFC y DAHDI no la reconoce podemos añadirle nosotros mismos el soporte de manera temporal editando el código fuente del driver y haciendo una simple modificación:
    (Odicha tiene una explicación bastante más técnica en su página)

    En el directorio del código fuente de DAHDI:

    root@localhost:/usr/src/dahdi-linux-2.x.x.x/# cd drivers/dahdi/wcb4xx
    root@localhost:/usr/src/dahdi-linux-2.x.x.x/drivers/dahdi/wcb4xx/# ls -la
    total 132
    drwxr-xr-x  3 root root  4096 2009-08-25 12:40 .
    drwxr-xr-x 15 root root  4096 2009-08-25 12:40 ..
    -rw-r--r--  1 root root 83581 2009-08-25 12:40 base.c
    -rw-r--r--  1 root root   116 2009-08-25 12:40 Kbuild
    -rw-r--r--  1 root root   181 2009-08-25 12:40 Makefile
    -rw-r--r--  1 root root 20494 2009-08-25 12:40 wcb4xxp.h

    Con el comando de Linux ‘lspci -vb‘ buscamos nuestra tarjeta:

    02:0b.0 ISDN controller: Digium, Inc. Unknown device b410 (rev 01)
         Subsystem: Digium, Inc. Unknown device b410
         Flags: medium devsel, IRQ 10
         I/O ports at e400
         Memory at fbffb000 (32-bit, non-prefetchable) [disabled]
         Capabilities: [40] Power Management version 2

    Nos fijamos en la posición que ocupa esta tarjeta (02:0b.0) y volvemos a ejecutar el comando con otros parámetros ‘lspci -vn’:

    02:0b.0 0204: d161:b410 (rev 01)
         Subsystem: d161:b412
         Flags: medium devsel, IRQ 10
         I/O ports at e400 [size=8]
         Memory at fbffb000 (32-bit, non-prefetchable) [disabled] [size=4K]
         Capabilities: [40] Power Management version 2

    Apuntamos el texto marcado en ‘azul’ y el ‘verde’ nos fijamos en el archivo base.c y casi por el final del archivo nos encontraremos con unas líneas como estas:

    static struct pci_device_id b4xx_ids[] __devinitdata =
    {
    { 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
    { 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
    { 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },

    Cada línea representa el identificador que buscará el driver para reconocerlo como una tarjeta compatible de manera que creamos una nueva línea con la misma forma que las anteriores y colocamos los valores que nos han salido en el ‘lspci’ en las posiciones correctas.

    static struct pci_device_id b4xx_ids[] __devinitdata =
    {
    { 0xd161, 0xb410, 0xd161, 0xb412, 0, 0, (unsigned long)&wcb4xxp },
    { 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
    { 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
    { 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },

    El último campo (el de color violeta) corresponde al tipo de tarjeta que vamos a configurar:

    – Las Digium: ‘wcb4xxp
    – Las Junghanns 2 puertos: ‘hfc2s‘, Junghanns 4 puertos: ‘hfc4s‘, Junghanns 8 puertos: ‘hfc8s
    – Las Beronet 2 puertos: ‘hfc2s_BN‘,  Beronet 4 puertos: ‘hfc4s_BN‘, Beronet 8 puertos: ‘hfc8s_BN
    – Las Openvox 2 puertos: ‘hfc2s_OV‘, 4 puertos: ‘hfc4s_OV‘, 8 puertos ‘hfc8s_OV
    – etc.

    De esta manera, ya sea la versión de la tarjeta que queramos añadir (siempre que el fabricante esté soportado) podemos modificar el driver para darle soporte.

    Para terminar, tan solo debemos compilar DAHDI y probar a cargar el módulo:

    /etc/init.d/dahdi restart

    Y al ejecutar el comando ‘dmesg’ debemos ver que la tarjeta ha sido encontrada corréctamente:

    [122429.745539] wcb4xxp 0000:09:01.0: Identified Wildcard B410P (controller rev 1)
    [122429.745539] wcb4xxp 0000:09:01.0: VPM 0/1 init: chip ver 33
    [122429.759405] wcb4xxp 0000:09:01.0: VPM 1/1 init: chip ver 33
    [122429.771406] wcb4xxp 0000:09:01.0: Hardware echo cancellation enabled.
    [122429.771406] wcb4xxp 0000:09:01.0: Port 1: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 2: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 3: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 4: TE mode

    Mi idea no es dar un curso sobre programación ni sobre DAHDI, tan solo mostrar cómo saltar un pequeño obstáculo que puede complicar la existencia a más de uno.

    Configurando DAHDI para utilizar la tarjeta con Asterisk …

    Una vez que veamos en el ‘dmesg’ que la tarjeta ha sido reconocida corréctamente, necesitamos configurarla, para ello vamos a editar el archivo ‘/etc/dahdi/system.conf’ y añadir las siguientes líneas para una tarjeta de 4 puertos:

    span=1,1,0,ccs,ami
    span=2,2,0,ccs,ami
    span=3,3,0,ccs,ami
    span=4,4,0,ccs,ami
    
    bchan=1,2
    hardhdlc=3
    
    bchan=4,5
    hardhdlc=6
    
    bchan=7,8
    hardhdlc=9
    
    bchan=10,11
    hardhdlc=12
    
    loadzone = es
    defaultzone = es

    Si tuviesemos una tarjeta con 2 puertos, sería más simple:

    span=1,1,0,ccs,ami
    span=2,2,0,ccs,ami
    bchan=1,2
    hardhdlc=3
    
    bchan=4,5
    hardhdlc=6
    loadzone = es
    defaultzone = es

    Para una OctoBRI pues puedes usar el sentido común para averiguar cómo sería el system.conf. ;P

    El archivo /etc/asterisk/chan_dahdi.conf  es prácticamente igual que cualquier zapata pero con algunas diferencias:

    Para crear un grupo con nuestros canales ya configurados tan solo debemos añadir algo como esto:

    group=1
    switchtype=euroisdn
    signalling=bri_cpe  ;; bri_cpe si son punto-a-punto ó bri_cpe_ptmp si son punto-multi-punto.
    context=default
    callgroup=1
    pickupgroup=1
    channel => 1,2,4,5,7,8,10,11

    Fácil ¿verdad? 🙂

    Reiniciamos de nuevo DAHDI y Asterisk y deberíamos tener ya la tarjeta perféctamente configurada y funcionando. 😀

    Puedes probarlo entrando en la consola de Asterisk y escribiendo…

    asterisk*CLI> dahdi show status
    Description                 Alarms IRQ
    B4XXP (PCI) Card 0 Span 1   OK     0
    B4XXP (PCI) Card 0 Span 2   OK     0
    B4XXP (PCI) Card 0 Span 3   RED    0
    B4XXP (PCI) Card 0 Span 4   RED    0

    Si teneis algún problema, no dudeis en dejar un comentario.

  • Nueva tarjeta de Digium

    La Digium TCE400B es la versión PCI-Express de la conocida tarjeta de procesamiento de trascoding G.729 y G.723 para Asterisk, la TC400B.
    No hay diferencia salvo el tipo de slot. Comentar que este tipo de tarjetas (en su versión PCI) es de las pocas que no consumen interrupciones hardware cuando no se utilizan y las va solicitando en función del número de canales que utilizan la tracodificación y únicamente para transmitir el audio, ya que para el procesamiento, esta tarjeta incorpora su propio procesador de cálculo flotante para realizar esta laboriosa tarea que consume tanto procesador.

    tce400bEsta tarjeta incorpora 120 licencias G.729 (es decir, para 120 llamadas simultaneas que precisen de convertir conversaciones G.729 a otro códec) y también 92 licencias G.723.

    No obstante, por el procesador que incluye, no es posible utilizar las 120 licencias G.729 Y las 92 licencias G.723 a la vez, si no que tendremos que escoger entre 120 licencias G.729, o bien 92 licencias G.729 y G.723.

    Esta elección se realiza mediante un parámetro a la hora de cargar el módulo DAHDI de esta tarjeta, pero bueno, esto lo podeis ver más detalladamente en el manual del usuario.

    Más información: http://www.digium.com/en/products/voice/tce400b.php

  • Nueva distribución con Asterisk basada en Debian

    debpbxFederico Pereira, un lector de Sinologic.net me ha enviado un email para informarme que ha desarrollado una distribución que, a diferencia de la gran mayoría de distribuciones que podemos encontrar, no está basada en CentOS si no en Debian (concretamente en Lenny 5.0):

    • Asterisk v1.4.22
    • Sonido Castellano (De la gente asterio.com.ar)
    • Libpri v1.4.7
    • Asterisk Addons v1.4.7
    • DAHDI v2.1.0.4+2.1.0.2
    • FreePBX v2.5.1
      • Modulos
        • Config Editor v1.0.3
        • PhpMyAdmin v2.11.9.4.1
        • SyS Info v2.5.5
        • Vmail Admin v2.5.7
    • A2billing v1.3.4c

    La idea de que esté basada en Debian me ha gustado (soy un debianero confeso) y busca comentarios y sugerencias para continuar desarrollando esta distribución.

    Como comentario personal y con el fin de que esta distribución le pueda ser interesante a más personas se me ocurren algunas sugerencias como añadir las locuciones de VoIPNovatos, añadir las fuentes del kernel de linux que utilice, así como las herramientas necesarias para poder compilar y así actualizar los paquetes DAHDI, LibPri y Asterisk sin estar atado a una versión en concreto. (posiblemente ya lo traiga incluido :D)

    Puedes probar la distribución descargándotela desde su web:
    http://www.opentecnologic.com/

  • Digium lanza soporte de T.38 a Asterisk

    El més pasado, Malcolm Davenport solicitaba a través del blog de Asterisk algunas personas interesadas en testear un nuevo producto que está preparando Digium sobre faxes.

    Por supuesto, esto es interesante si aún tienes la mala fortuna de tener que utilizar estos anticuados artilugios bicentenarios que consumen papel y tinta por doble partida (mucha gente que conozco, para enviar un documento que tienen en el ordenador, lo imprimen por la impresora y lo envían por fax), además con un coste tonto… si claro, como tienes tarifa plana seguro que no te cuesta enviarlo… bueno, no voy a seguir con este tema cansino.

    Pues la idea es que Digium acaba de anunciar un software comercial para hacer de origen y terminación de faxes compatible con tarjetas analógicas y/o digitales mediante DAHDI y T.38!!!  a una velocidad de 14.400 bps, (como curiosidad, iaxmodem funciona a 9.600bps).

    Me pregunto entonces… teniendo la maravillosa unión iaxmodem+hylafax ¿es interesante esta unión?

    Quizá la respuesta sea que generalmente puede que no (depende del coste total) aunque estamos hablando de un canal que permite enviar faxes por T.38 (por internet o red local, sin requisitos de velocidad, con corrección de errores, sin problemas de latencia, … vamos… muy interesante si tienes una línea de mala calidad, si tus faxes generalmente se cortan o si recibes muchos faxes).

    Por cierto, según algunos comentarios de Alberto, funciona muy, muy bien. 🙂

    Entonces es a veces, cuando llega un momento que la solución más sencilla puede ser la apropiada.

    Podeis encontrar más información en la web de Digium:
    http://www.digium.com/en/products/software/faxforasterisk.php

  • AsteriskNOW 1.5.0 estable Released!

    Aunque ayer fue 1 de Abril (día de los inocentes en los países anglosajones) Digium publicó la versión estable de AsteriskNOW 1.5.0.

    Digium publicó su primera beta de esta versión en Octubre de 2008 y ya iba siendo hora de que lo actualizaran.

    Los principales cambios:

    • Distribución CentOS actualizado.
    • Web basada en httpd y FreePBX
    • Asterisk 1.6 con soporte de DAHDI.
    • Versiones x86 (32 bits) y x64 (64 bits)

    Podeis descargarlo de aquí:
    http://www.asterisknow.org/downloads

  • Publicado tutorial paso a paso sobre OpenR2

    «OpenR2 es una libreria que implementa señalización MFC/R2 sobre líneas E1 usando la interfaz  de telefonía Zapata, DAHDI y próximamente la librería de abstracción TDM OpenZAP.»

    Así empieza la guía que ha publicado Moises Silva y Alexandre Alencar sobre cómo configurar pasito a pasito un sistema Asterisk para tener soporte de señalización MFC/R2 sobre líneas E1.

    Podeis descargarlo de aquí:
    http://www.nucleum.com.mx/extras/openr2_guide_spanish.pdf