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 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?