Un poco de Historia …
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 2Nos 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 2Apuntamos 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.
Por ejemplo, si nuestro terminal IP utiliza códec Alaw, no es práctico que el archivo de audio se encuentre en GSM, ya que Asterisk tendrá que «traducir» el archivo codificado como ‘gsm’ a ‘alaw’ para que nuestro terminal pueda reproducirlo y nosotros escucharlo. Esto consume procesador y memoria que, multiplicado por el número de archivos que se pueden llegar a reproducir a la vez, pueden causar una carga excesiva y nada justificada.
