Etiqueta: basica

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

  • Alternativa al ZapHFC y mISDN para tarjetas ISDN

    Actualmente, si alguien tiene una tarjeta de RDSI del tipo Billion, Ovislink, etc, habrá observado que dispone de un chip genérico llamado Cologne HFC que permite ser programado por el fabricante para manipular los datos (unos y ceros) de una manera concreta, en este caso, para capturar las tramas RDSI Básicas.

    Billion RDSICada fabricante, además de reprogramar este chipset a su gusto también desarrolla unos drivers o módulos que permitan comunicarse con esta tarjeta. Este es el caso de Junghanns y sus módulos qozap.

    El proyecto mISDN comenzó con el objeto de establecer un estándar de módulos que permitan la comunicación con la mayoría de las tarjetas basadas en este chipset, pero llegar a controlar la gran cantidad de módulos necesarios para permitir esta compatibilidad con tantas tarjetas, hace que mISDN llegue a ser para muchos una operación bastante tediosa e incluso para «no-expertos» es incluso practicable pese a ser, en mi opinión, uno de los mejores sistemas para cualquier tipo de tarjeta RDSI Básica.

    Digium automatizó la instalación de los drivers mISDN para su tarjeta B410P de manera que instalarla sea algo tan sencillo como:

    cd /usr/src/zaptel-x.y.z
    ./configure
    make
    make b410p
    make install
    make config

    Pero para aquellos que tienen otras tarjetas, estos pasos a veces no son suficientes y prueban con alternativas como ‘zaphfc‘ del paquete briStuff o incluso se atreven con CAPI.

    BristuffA diferencia del módulo qozap para las tarjetas Junghanns, el zaphfc, es un módulo de linux ya anticuado (deprecated) y no mantenido más por Junghanns, por lo que muchos se han movilizado para continuar el desarrollo de este módulo aprovechando las ventajas que ofrece que sea un módulo basado en software libre.

    Como alternativas podemos encontrar:

    vzaphfc: http://xorcom-rapid.berlios.de/vzaphfc/
    El parche de Florz: http://zaphfc.florz.dyndns.org/
    Capi-cm:

    Incluso Tzafir (de Xorcom), otra persona que no duerme nunca 🙂 se ha aventurado a continuar con el proyecto briStuff en su propia web: http://updates.xorcom.com/astribank/bristuff/

    Realmente estos proyectos son la prueba que el software libre mantiene el desarrollo y permite evolucionar más rápidamente que el software propietario.