Etiqueta: bri

  • Mediatrix: Gateways potentes y fiables a un buen precio

    Hace poco tuve la oportunidad de asistir a una conferencia sobre Mediatrix y, aunque me sonaba de haberla escuchado por las listas de Asterisk-ES, nunca llegué a ver qué ofrecían respecto a otras marcas como GrandStream, Epygi o VegaStream, hasta entonces.

    Los gateways Mediatrix están orientados a la pequeña y mediana empresa, con capacidades que rondan desde el modelo más básico de 1 RDSI Básica hasta 2 RDSI Primarios (2xE1).

    Mediatrix 2xE1

    Su configuración me recuerda bastante al de los modelos de VegaStream, sencillo en las distancias cortas, pero muy potentes y sorprendentemente configurables permitiéndonos hacer prácticamente cualquier cosa que necesitemos sin depender de un interfaz simple y limitado.

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

  • Asterisk-ES-RSP: Un Asterisk ideal para producción

    Hace varios meses Saúl Ibarra y Jon Bonilla propusieron una idea para un proyecto muy interesante:

    Congelar una versión de Asterisk y aplicar los parches necesarios para conseguir una versión verdaderamente estable y lo más segura posible basándose en las características más comunes para un Asterisk que funcione como centralita de comunicaciones.

    Quizá el debate en este sentido está servido, la versión de Asterisk que Saúl y Jon parchean está basado en Asterisk 1.4, actualmente la rama más peleada y conocida y por este motivo, esta versión pasó a llamarse Asterisk-ES-RSP (Rock Solid Patchset) y consiste en un Asterisk 1.4 con todo lo necesario que solucionan los bugs que se encuentren en las características más utilizadas como SIP, features, y DAHDI.

    Nuestro compañero Odicha, una mente inquieta que empezó desarrollando algunos parches para completar el soporte de tarjetas RDSI Básicas (BRI) en Asterisk 1.4 y que hoy día es de los desarrolladores más activos de la comunidad Asterisk-ES participa también en este proyecto aportando su granito de arena para conseguir facilitar la vida a aquellos que trabajan con estas tarjetas BRI y desean utilizar DAHDI.

    Otros como Javier Ximenez, desarrollando el soporte del cancelador de eco comercial SoftEco e integrándolo para simplificar el tiempo de instalación para los integradores.

    Y muchas otras personas (como Silvia, Ramoncio, Ramses, y un largo etcétera) que, a través de sus pruebas, comentario y sobre todo tiempo, han venido colaborando para documentar, detectar y mejorar todo lo posible esta versión.

    Cómo no, es mandatory decir que Asterisk-ES-RSP no es un fork ni tiene la intención de serlo, si no una versión de Asterisk a la que se le aplican las modificaciones para corregir los más pequeños errores que pueda tener sin añadir nuevas features que puedan provocar nuevos errores, Asterisk-ES-RSP no pertenece a ninguna empresa aunque muchas apoyan esta iniciativa, y está abierto a todo aquel que quiera participar mediante su lista de correos o su página web.

    Después de 6 meses de continuo testeo, pruebas y conversión de parches es de recibo reconocer la buena labor que estas personas están desarrollando, no sólo para conseguir una versión optimizada y segura, si no además la brillante intención de ponerlo a disposición de todos aquellos que quieran probarlo y utilizarlo en entornos de producción.

    Podría decir que actualmente Asterisk-ES-RSP es la versión de 1.4 más fiable que existe y la única que permite utilizar tarjetas RDSI Básicas basadas en el chipset HFC (Beronet, Digium, Junghanns, Billion, Openvox, etc) con DAHDI de una manera sencilla y sin líos de Kernel ni con el mISDN.

    Si estás interesado en probarlo, tan solo debes seguir los siguientes pasos:
    http://www.asterisk-es-rsp.org/doku.php/instalacion:instalacion_asterisk-es-rsp

  • Nueva tarjeta revolucionaria de Beronet (BRI+PRI+GSM)

    Pese a que conocía ya esta tarjeta, me he esperado a conocer todos los detalles, y es que Beronet llevaba prácticamente un año anunciando una tarjeta verdaderamente revolucionaria y solo disponible para betatesters y es que esta tarjeta tiene tantas novedades que hacía falta estudiarla tranquilamente y en serio para llegar a descubrir las ventajas y novedades que incorpora.

    Para empezar, comentar que esta tarjeta no es como el resto de las tarjetas que conocemos, es un nuevo concepto muy interesante y que si tiene acogida, seguramente lo veremos más a menudo con otros modelos y marcas.

    Se podría decir que, tras el fiasco de mISDN con los nuevos kernels, Beronet está preparando una tarjeta mucho más fácil de configurar que las anteriores, sin necesidad de compilar ningún módulo y que funciona, no sólo con Asterisk, si no también con otras aplicaciones como Kamailio, SER, y otras de dudosa calidad.

    Por lo tanto, Beronet ha lanzado la primera «tarjeta-gateway» del mercado: la Beronet Berofix.

    Una tarjeta con un comportamiento bastante interesante:

    Cuando instalamos esta tarjeta en nuestro equipo, el sistema la reconoce como una tarjeta de red  conectada a un gateway SIP, la gran sorpresa es que el gateway SIP se encuentra dentro de la propia tarjeta.

    Otra de las novedades es que utiliza módulos como los de las tarjetas analógicas de Digium, pero en esta ocasión los módulos son BRI, PRI y próximamente GSM, pudiendo disponer de una tarjeta con soporte BRI y PRI sin necesidad de disponer de 2 tarjetas diferentes.

    La conexión con Asterisk es trivial, tan solo debemos acceder vía web a la dirección IP de la tarjeta Berofix y configurar el gateway que incorpora para conectarse con un Asterisk, un Kamailio o incluso otro servidor situado en otro punto de la red (siempre que configuremos las rutas de red adecuadamente), por lo que esta tarjeta parece ideal para que varios equipos puedan hacer uso de la misma línea y no únicamente el que la tiene instalada.

    Más curiosidades (que esta tarjeta tiene bastantes novedades):

    • Soporta faxes mediante T.38 (V.27,V.29 y V.17)
    • Soporta QSig bajo BRI y PRI (implementación independiente de la que trae el LibPRI)
y antes de que alguien me lo pregunte… no, no soporta Call Replacement en BRI. 🙁 por lo que es prácticamente la misma implementación del LibPRI pero con soporte para BRI. 🙂 (CNIP,CNIR,CONP)
    • Cancelador de eco hardware (1024 taps = 128ms) – tener un buen eco cancel hardware merece la pena. 🙂
    • Dispone de 2 slots para módulos y existen módulos de 2, 4 BRI y 1, 2 y 4 PRI, y dentro de poco, módulos GSM, por lo que podríamos tener una tarjeta con 4 BRI y 4 PRI, o bien con 2 módulos de 4 PRI, una tarjeta de 8 PRI… 🙂
    • Capacidad de trascoding G.723.1 y Anexo A, G.729a, G.726, alaw y ulaw
    • Como dispone de un gateway interno en la tarjeta, todo el cálculo, se realiza DENTRO de la propia tarjeta, así que podemos olvidarnos de la carga del procesador.
    • El interfaz web de la tarjeta nos permite configurar un dialplan, pero es muy, muy básico… prácticamente nulo… como el de los gateways. 🙂
    • Soporta SIP bajo TCP y TLS.
    • Bus que permite conectar esta tarjeta con otras del mismo tipo y así hacer de puente sin llegar a enviar tráfico al sistema donde está hospedado (esto realmente lo traen todas las tarjetas, tanto de beronet, como de Digium y Junghanns, pero es la primera vez que se anuncia como tal).

    Si quereis ver la lista de especificaciones completa, teneis disponible la hoja de presentación.

    La tarjeta saldrá oficialmente a la venta en Agosto de este año y sobre cuanto cuesta… esa es una «sorpresa» que dejaré que descubrais vosotros cuando salga. 😉

  • DAHDI 2.1.0 Released!

    Esta nueva versión incluye:

    • El nuevo driver wcb4xxp para dar soporte a las tarjetas RDSI (basados en el chipset HFC)
    • Mejorada la integración con el cancelador de eco OSLEC
    • Corregidos algunos bugs

    Para ver la lista completa de cambios:
    http://downloads.digium.com/pub/telephony/dahdi-linux/ChangeLog-2.1.0

    Puedes descargarlo de:
    http://downloads.digium.com/pub/telephony/dahdi-linux-complete/

  • Todo lo que has querido saber de DAHDI (III)

    Visto el éxito de los anteriores artículos, esta es la tercera edición de «Todo lo que has querido saber de DAHDI» y como se lo he prometido a mi colega Silvia aquí viene la tercera. 😛

    Después de una semana dando el curso de Asterisk Advanced, el primer punto que me asustó fue leer «Asterisk 1.6 y DAHDI» en las primeras páginas del curso, algo que actualmente nadie en su sano juicio recomendaría en un entorno en producción y en cambio el curso se centra en estos dos «soles«.

    Claro, considerando que no he llegado a tener tiempo más que para echarle un vistazo más que por encima a Asterisk 1.6 y darme cuenta de cosas «curiosas» y algo más (por cuestión de trabajo) a DAHDI, me encuentro que tengo que aprender, no únicamente cómo funciona, si no detectar cualquier problema que pudiera ocasionar a los alumnos del curso para solucionarlo antes de que ellos lo encuentren y no sepa donde meterme.

    Tras una semana, explicando y resolviendo las posibles dudas sobre las diferencias físicas y lógicas entre Zaptel y DAHDI me doy cuenta que DAHDI está más avanzado de lo que en un principio pensaba y es que, no solo es perfectamente compatible con las tarjetas con las que damos el curso (primarios y analógicas) si no que en muchos aspectos es mucho más interesante que Zaptel.

    Mi logo de DAHDI xD
    Mi propuesta como logo de DAHDI. 🙂

    Como ya comenté, el archivo zaptel.conf es sustituido por /etc/dahdi/system.conf y aunque son prácticamente iguales por dentro, hay un pequeño detalle interesante, el cancelador de eco que se puede cargar y descargar dinámicamente y seleccionar independientemente para cada canal DAHDI, así si tenemos un primario E1 (30 canales de voz) podemos utilizar un cancelador de eco para los 10 primeros canales, otro cancelador de eco para los 10 siguientes y otro diferente para los 10 últimos. ¿utilidad? pues no se ahora mismo, pero seguro que alguien se lo encuentra. Por todo lo demás, es exáctamente igual. 🙂

    Por otro lado, el archivo zapata.conf ha pasado a ser /etc/asterisk/chan_dahdi.conf y le ocurre lo mismo, es prácticamente igual por dentro, las diferencias son mínimas y algunas bastante curiosas que os lo dejo para que lo descubrais vosotros. ;P

    Entre todas las personas que conozco que instalan Asterisk, en estos momentos «especiales» todas tienen algo en común: pese a existir la versión Asterisk 1.4.22, TODAS utilizan la versión de Asterisk 1.4.21.1 ¿porque? por que esta versión no incluye el zapata.conf.sample ni el chan_zap.so, si no chan_dahdi.conf y chan_dahdi.so. (WTF!)

    La próxima versión (la 1.4.23 que saldrá en breve), funcionará exáctamente igual que la 1.4.22 ¿que harán entonces? seguramente muchos empiecen a dar el salto, otros seguirán clavados en la 1.4.21.1 y así hasta que terminen dando el salto irremediablemente, porque nos guste o no… queridos amigos… Zaptel, ha muerto.

    Ahora bien, entramos en un punto curioso donde el 99% de las veces funciona todo como debe ser, pero existe un 1% donde ocurre algo donde las líneas RDSI Básicas, BRI, ISDN 2B o como quieran llamarla, aquella línea más utilizada en las empresas europeas que las propias analógicas se encuentran en un momento clave:

    – Por un lado, Junghanns continúa con su BriStuff (impasible ante todo lo que ocurra fuera).
    Sangoma con sus drivers que, continúan siendo Beta y que lo van modificando (que no siempre arreglando) a medida que la gente encuentra fallos.
    – mISDN 2.X.X, que aunque soluciona algunos problemillas de la 1.1.X, aún no está lo suficientemente maduro para lo que uno desea en este tipo de sistemas.
    – CAPI, ¿CAPI sigue vivo?
    – mISDN 1.1.X, el driver BRI más popular actualmente y que con las últimas versiones (>= 1.1.8) con algunas versiones de kernel, con algunas líneas, en las noches de luna llena, cuando saturno, venus y mercurio se alinean,… hacen raros (gestión extraña de capas, etc…)
    – alguna más…?

    … y de repente aparece otra alternativa, un nuevo archivo wcb4xxp.c en el arbol de desarrollo de DAHDI (Trunk), un driver DAHDI indicado para la tarjeta B410P de Digium y por lo general para cualquier otra que tenga el driver HFC con uno o más conectores. Aún está en desarrollo e incluso el actual DAHDI no la trae, ya que están haciéndole pruebas antes de lanzarla como versión estable en la siguiente versión y es entonces cuando se me plantean varias dudas o mejor dicho, una reflexión:

    Si en los EEUU no utilizan este tipo de líneas y nosotros sí ¿quien debería probar este driver y empezar a sacarle los posibles fallos antes de que lo saquen como versión estable y sea más difícil de corregir? ¿no deberíamos ser los que peleamos a diario con este tipo de tarjetas y estas líneas los que deberíamos ver dónde falla con nuestras penosas líneas de Telefónica, Tele2, Orange, Jazztel, etc… y colaborar para que solucionen los posibles fallos y que corrijan el driver de una vez por todas para que sea más que nunca un driver verdaderamente compatible con nuestras propias líneas?

    En principio este driver no va a hacer exclusiones de ningún tipo, por lo tanto llegará a ser un driver compatible con todo tipo de tarjetas HFCMulti, pero creo que ahora estamos en un momento idóneo para empezar a sacarle punta a este driver, antes de que lo terminen de «pulir» y veamos con desilusión que tiene más espinas de las que debería tener.

    Instalar DAHDI de la rama subversion no se tarda ni 3 minutos, en conectar la tarjeta a la línea y ver si falla, menos aún, si funciona será algo que tenemos ganado, si no lo hace o no lo hace corréctamente será el momento de hacer de «usuarios beta-tester» de los que tanto se enorgullece la comunidad y empezar a enviar lo que encontremos a Digium para que hagan un driver en condiciones. ¿o no? 🙂

    ¿y tú? ¿Has probado ya DAHDI con Asterisk 1.6?

  • LibPri 1.4.4: Soporte de RDSI Bri y TBCT QSig

    Esta semana, siguiendo los hilos de la lista Asterisk-Dev, me he encontrado con un anuncio que marqué para analizar cuando tuviera más tiempo. El anuncio lo daba Matthew Fredrickson de Digium, ya que es uno de los desarrolladores que se ocupa de mantener al día el paquete Zaptel y el LibPRI.

    Concretamente, el anuncio iba sobre el nuevo paquete LibPri (1.6.0) así lo anunciaban aunque finalmente ha pasado a ser el LibPri 1.4.4 y que incluye dos añadidos bastante interesantes que explicaré ahora.

    Soporte de tarjetas RDSI Bri:
    Algo que iba siendo hora, ya que en la actualidad, el soporte de RDSI Bri está en mano de mISDN y aunque es un driver que suele funcionar bien, el hecho de incorporar el soporte BRI al Zaptel es algo que mejora la «centralización» en la corrección de bugs, algo que actualmente no se hace.
    Si hay algún bug en mISDN, los encargados de arreglarlo son los desarrolladores de mISDN, no los del paquete Zaptel, aunque si el error está en el archivo ‘chan_misdn’ entonces sí.
    De momento, creo que solo permiten modo Punto-multi-punto.

    Soporte de TBCT/2BCT en QSig:
    Esto es algo muy interesante, que muchas personas lo han pedido y hasta ahora únicamente funcionaba en pocos sistemas.
    Cuando conectamos Asterisk a una PBX con extensiones, y estas extensiones se llaman entre sí, la llamada no tiene porqué llegar a Asterisk, pero si la llamada, después de una transferencia comienza y acaba en la PBX, Asterisk pasa a ocupar dos canales (uno para el origen y otro para el destino).
    Con el soporte TBCT, Asterisk reconoce que el origen y el destino vienen de la misma PBX y puentea los canales liberando ambos canales ocupados, permitiendo que el tráfico no llegue a Asterisk.
    Llevan preparando esta feature desde la Astricon del 2005. 😛

    Podeis descargar esta versión aquí:
    http://downloads.digium.com/pub/libpri

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