Antes de ponernos manos a la obra un poco de teoria rápida. Todo el mundo parece saber que necesitas tener una tarjeta o el driver dummy de DAHDI en Asterisk, pero no todos saben porque. Asterisk necesita una fuente de timing para lo siguiente:

• Generar el audio saliente. Asterisk utiliza la fuente de tiempo disponible a la hora de enviar los paquetes de audio saliente. En ausencia de una fuente de tiempo fiable Asterisk puede utilizar el audio entrante como referencia, pero si el audio entrante viene con jitter por ejemplo, el saliente tambien lo tendrá, por lo que no es una buena idea ir por la vida sin una fuente fiable de tiempo.
• IAX trunking. El IAX trunking es un método gracias al cual Asterisk puede ahorrarnos algo de ancho de banda en un enlace entre dos servidores ya que si tenemos 10 llamadas entre el servidor A y el servidor B nos ahorramos mandar 9 de las 10 cabeceras. Para que esto funcione correctamente la temporizacion ha de ser precisa, por lo que necesitaremos una fuente fiable de tiempo. ¿Pero quién usa IAX? Esto en realidad no nos interesa.

Alguno pensara que me he olvidado de MeetMe. Pues no. MeetMe necesita DAHDI por otra razón: el motor de conferencias que usa MeetMe se encuentra en DAHDI. Podría decirse que MeetMe es un wrapper de la aplicación de conferencias de DAHDI. Por lo tanto, MeetMe siempre dependerá de DAHDI, aunque ya veremos que hay algunas alternativas.

Las mejoras de Asterisk 1.6.2 en cuanto a timing

Asterisk dispone de un API genérico de timing desde la version 1.6.1. La idea es disponer de diversos módulos que provean a Asterisk de una fuente de tiempo fiable, siendo DAHDI un simple módulo más. En Asterisk 1.6.2 tenemos lo siguiente módulos de timing:

• res_timing_dahdi (desde Asterisk 1.6.1): Utiliza DAHDI como fuente de tiempo. Si no tenemos tarjetas podemos utilizar este módulo junto a dahdi_dummy para tener timing fiable.
• res_timing_pthread (desde Asterisk 1.6.1): Utiliza la librería POSIX pthread para obtener el timing. Su rendimiento no es el tan bueno como el de DAHDI, pero tiene una ventaja importante: es portable. Con ésta fuente de tiempo es posible utilizar IAX trunking en FreeBSD o MacOSX por ejemplo. How cool is that?!
• res_timing_timerfd (nuevo en Asterisk 1.6.2): Éste es el bueno. Utiliza TimerFD, un nuevo mecanismo del Kernel de Linux (>= 2.6.27) para proporcionar timing. También necesita de una version reciente de glibc (>= 2.8) pero a cambio nos ofrece una fuente de tiempo muy fiable y sin DAHDI. dahdi_dummy, te quedan dos telediarios.

Sustituyendo MeetMe

Hasta ahora he comentado el nuevo API de timing, pero no hemos solucionado el que MeetMe dependa de DAHDI. Obviamente no podemos utilizar MeetMe así que tenemos un par de alternativas:

• AppKonference: Digamos que es un MeetMe con esteroides. Soporta VAD y video y no necesita DAHDI. El único problema (si es que lo consideramos un problema) es que no es una aplicación oficial.
• ConfBridge: Se trata de una nueva aplicación que incluye Asterisk 1.6.2 perteneciente al nuevo API de bridging. No he hecho unas pruebas demasiado intensas, pero de momento no he tenido problemas.

Habilitar el timing interno

Para terminar, tenemos que habilitar el timing interno en Asterisk. Para ello editamos el fichero asterisk.conf y descomentamos la opción internal_timing=yes de la sección [opcions].

Esto es todo por hoy, es una buena excusa para probar Asterisk 1.6 ¿no?

Durante el Amoocon Kevin Fleming me comentó que en la nueva versión de DAHDI eso ya so sería necesario y acabo de comprobar que es cierto.

En DAHDI 2.2 se ha eliminado el RTC como fuente de tiempo para el subsistema DAHDI, ya que su funcionamiento era errático en ocasiones. En su lugar se utiliza el timming del propio kernel. Vamos a verlo:

Tras compilar y cargar dahdi_dummy 2.2 SIN modificar vemos que carga correctamente:

[2548770.332063] dahdi: Telephony Interface Registered on major 196
[2548770.332075] dahdi: Version: 2.2.0-rc5
[2548771.512873] dahdi: Registered tone zone 0 (United States / North America)


Comprobemos la fuente de tiempo:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# cat /proc/dahdi/1
Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: Linux26) 1" (MASTER)


Y un dahdi_test para ver que todo va bien:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.996% 99.997% 99.998% 99.996% 99.999% 99.996% 100.000% 99.996%
99.999% 99.995% 99.999% 99.997% 99.997% 99.998% 99.999% 99.996%
100.000% 99.999% 99.995% 100.000% 99.614% 99.610% 99.614% 99.612%
99.616% 99.609% 99.614% 100.000% 99.997% 99.612% 99.613% 99.610%
99.614% 99.610% 99.614% 99.610% 99.614% 99.609% 100.000% 99.614%
99.610% 99.613% 99.611% 99.613% 99.610% 99.614% 99.609% 100.000%
99.614% 99.609% 99.614% 99.610% 99.614% 99.998% 99.610% 99.614%
99.611% 99.999% 99.614% 99.610% 99.614% 99.610% 99.613% 99.610%
99.613% 99.609% 99.614% 99.610% 100.000% 99.614% 99.610% ^C
--- Results after 71 passes ---
Best: 100.000 -- Worst: 99.609 -- Average: 99.758634, Difference: 99.998285


DAHDI 2.2 todavía está en estado de release candidate, pero pronto se espera una versión estable.

Podéis descargar dahdi-linux y dahdi-tools aquí.

PD: La foto se la tomo prestada a Elio.

El problema que tenemos a la hora de compilar ztdummy o dahdi_dummy en Xen es la fuente de timming. En las versiones actuales de Zaptel y DAHDI el timming (cuando no tenemos tarjetas) se puede obtener de tres fuentes:

1. El HPET.
2. El RTC.
3. El tick del sistema (opción CONFIG_HZ)

En Xen (si usamos el kernel oficial 2.6.18 parcheado) no tenemos disponibles ni la primera ni la segunda opción, pero Zaptel se cree que SÍ que tenemos acceso al RTC, y por tanto falla.

Para solucionarlo tenemos que editar el fichero ztdumy.c o dahdi_dumy.c y localizar la siguiente sección:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
#define USE_RTC
#endif
#else
#if 0
#define USE_RTC
#endif
#endif
#endif

Si os fijáis el comentario ya nos indica lo que tenemos que hacer: comentar las líneas correspondientes para que no se defina el flag USE_RTC. Para ello modificamos el código anterior dejándolo así:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
//#define USE_RTC
#endif
#else
#if 0
//#define USE_RTC
#endif
#endif
#endif

De esta manera, Zaptel o DAHDI compilarán sin problemas en un entorno Xen y podremos utilizar el dummy driver necesario para MeetMe o el IAX trunking.

En casa tengo un servidor con Xen y el kernel oficial, un 2.6.18 parcheado. Esta versión no tiene soporte para HPET, por lo que se usaría el RTC, pero como en Xen tampoco funciona eso es necesario comentar las líneas en las que pone:

#define USE_RTC

al principio del fichero dahdi_dummy.c.

Tras hacer lo propio, me encuentro con el siguiente problema al compilar DAHDI:

CC [M]  /usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.o
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c: In function ‘dahdi_dummy_timer’:
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c:223: warning: implicit declaration of function ‘hrtimer_set_expires’

Mirando el código de dahdi_dummy, me encuentro lo siguiente:

/* use kernel system tick timer if PC architecture RTC is not available */
static void dahdi_dummy_timer(unsigned long param)
{
hrtimer_set_expires(timer, jiffies + 1);
add_timer(&timer);
...

Al parecer el error viene porque se está utilizando una función del HPET cuando realmente debería usarse el system tick. Rápidamente me he dirigido al visor del repositorio de Subversion, para ver qué había cambiado desde DAHDI 2.0.0, ya que esa versión me funcionaba correctamente. Al acceder al visor me he encontrado con que había un nuevo tag: DAHDI 2.1.0.1! :-O Al mirar el ChangeLog veo que han solucionado justo el bug que había encontrado!

Por lo tanto, si estás tratando de instalar DAHDI 2.1.0 en Xen mejor que utilices DAHDI 2.1.0.1, ya que sino se producirán errores de timming. De momento no hay paquetes comprimidos de esta última versión, por lo que es necesario obtenerla del repositorio de Subversion:

svn co http://svn.digium.com/svn/dahdi/linux/tags/2.1.0.1 dahdi-linux-2.1.0.1
svn co http://svn.digium.com/svn/dahdi/tools/tags/2.1.0.1 dahdi-tools-2.1.0.1

Enjoy!

Desde Digium animan a los usuarios a probar estos nuevos drivers con el fin de estabilizarlos lo antes posible y teniendo en cuenta los últimos dolores de cabeza que he tenido a cuenta de Kernels > 2.6.24 y mISDN espero que estos drivers funcionen…

Para probar estos drivers es necesario tener una versión superior a la 1.4.4 de libPRI y 1.6.0 de Asterisk. Podéis descargar en nuevo DAHDI aquí:

• dahdi_linux-2.1.0-rc3 (todavía no disponible)
• dahdi_tools-2.1.0-rc3 (todavía no disponible)
• dahi_complete(2.1.0-rc3+2.1.0-rc3)

En en el fichero system.conf tenéis un ejemplo de la configuración necesaria.

NOTA: Todavía no están disponibles los tarballs para dahdi_linux y dahdi_tools de manera separada, así que es necesario bajarse el dahdi_complete u obtener las versiones a través del SVN.

Vía VentureVoIP

Asterisk 1.4.22

Incluye muchos bugs solucionados, además de soportar DAHDI. En esta release se soportan tanto Zaptel como DAHDI. Podéis consultar las implicaciones que tiene este cambio aquí.

Toda lista de cambios esta disponible aquí, y podéis descargar esta versión donde siempre.

Asterisk 1.6.0

Sin duda la release más esperada. Trae muchos cambios y nuevas funcinalidades, así que es importante consultar los ficheros CHANGES y UPGRADE.

Otra de las novedades que trae Asterisk 1.6.0 además de no soportar Zaptel en favor de DAHDI: el nuevo modelo de desarrollo. En Asterisk 1.4, se mantenía un único branch para toda la versión 1.4, por lo que no se añadían nuevas funcionalidades. Esto no hacía posible la inclusión de nuevas funcionalidades hasta las major releases, por lo que tardaban demasiado en ver la luz.

Con el nuevo modelo de desarrollo se creará un branch por cada release. Actualmente ya están creados los branches para Asterisk 1.6.0 y Asterisk 1.6.1. Al contrario que en Asterisk 1.4, en Asterisk 1.6 sí que se añadirán nuevas funcionalidades en Asterisk 1.6.1, Asterisk 1.6.2 y sucesivas versiones. Se espera que el tema de el CallerID en las transferencias este solucionado en Asterisk 1.6.1, y que Asterisk 1.6.2 incluya soporte para IPv6.

Según comentaropn Russell Bryant y Kevin P. Flemming en el AstriCon, se dará soporte a las 3 minor releases anteriores, de manera que tras la salida de Asterisk 1.6.1 solo se dará soporte para las 3 últimas versiones de Asterisk 1.6.0.X. Esperemos que esto sea algo positivo…

DAHDI 2.0.0

DAHDI es el reemplazo de Zaptel ya que la marca Zaptel es propiedad de otra empresa dedicada a la venta de tarjetas minutos de telefonía.

DAHDI viene dividido en 2 paquetes, aunque es posible desacargar uno que agrupa ambos: dhadi-linux y dahdi-tools.

dahdi-linux contiene los módulos del kernel para el manejo de las tarjetas de telefonía, y dahdi-tools las herramientas que susituyen a ztcfg, zttool, etc.

Esta separaciónhace posible que si se detecta un bug en una aplicación no sea necesario hacer una release que incluya los módulos del kernel y vice versa.

Pues por fín tenemos estas nuevas versiones disponibles, aunque obviamente no recomiendo que os pongáis a actualizar a Asterisk 1.6.0 y DAHDI hoy

Pues resulta que me despisto un día, y justo cuando sacan las nuevas versiones de todo!

Como seguro que todos os sabéis la noticia por el blog de Elio, o el de Russell, no la voy a repetir, y por cambiar un poco voy a opinar un poco sobre el tema

Lo primero comentar que me ha sorprendido ver tanta “rc” en los releases, lo cual quiere decir: “No isntale esto en un servidor en producción.” Últimamente Digium ha metido la pata un par de veces seguidas, así que dese hace no demasiado, se me ha curado un poco la “versionitis” y soy más cuteloso.

Se suponía que Asterisk 1.4.22 iba a estar listo la semana pasada (según mails en la lista de developers) y la versión que ha salido es la RC! Entiendo que el tema de DAHDI les vaya a traer más de un dolor de cabeza, pero a veces tengo la sensación de estar llendo a la aventura cuando pruebo una nueva versión de Asterisk.

Por lo tanto, he decido congelar mi cerebro en la 1.4.21.1, que no me ha dado problemas (de momento) a la espera de necesitar algún cambio. Esto no quier decir que haya dejado de probar cosas nuevas o cosas bleeding-edge (escribo desde una Debian Sid dist-upgradeada ayer, y en casa tengo Asterisk 1.6.1 xD), pero hay que curarse en salud

Espero que las nuevas versiones de Asterisk traigan novedades, así como muchas resoluciones de bugs (los prefiero a las features, que ya tiene bastantes), que me ayuden a dormir más tranquilo.

:wq

Mientras tanto, ya tenemos nueva release de Asterisk, la 1.4.20, una release que yo, al menos, estaba esperando, ya que no me gustan los releases de emergencia del tipo 1.4.X.Y.

Esta versión tiene muchísimos bugs resueltos, ya parece que lo del IAX esta del todo bien, aunque ya se ‘solucionó’ en la 1.4.19.2… Mirando el ChangeLog, veo que ha habido bastante movimiento en el chan_sip y en mi amado chan_local

Habrá que probarla antes de lanzarse al vacío, no sea que pase como con la 1.4.19, pero parece que para esta se lo han currado bien!

Podéis descargarla donde siempre:  http://downloads.digium.com/pub/telephony/asterisk/

Por otro lado, como se podía leer ayer en toda la blogokosa, Digium ha renombrado el proyecto Zaptel a DAHDI (Digium Asterisk Hardware Device Interface), así que habrá algo de lío en las versiones de Asterisk 1.4, que utilizarán tanto Zaptel como DAHDI,  mientras que Asterisk 1.6 utilizará solo DAHDI. El anuncio oficial, más detallado, lo tenéis aquí: http://blogs.digium.com/2008/05/19/zaptel-project-being-renamed-to-dahdi/