Como sabréis no es que yo sea super-fan pro Asterisk 1.6 precisamente, pero por fin he probado algo que me ha gustado, así que voy a comentarlo por estos lares.

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?