Modulo DAHDI en Elastix

Modulo DAHDI en ElastixDAHDI: Es el soporte para el hardware de telefonia en Asterisk-Elastix, en este modulo se encuentran los manejadores (Drivers) de las tarjetas interfaces con la red de telefonia publica PSTN. DAHDI es el nuevo nombre que se le dio a ZAPTEL a partir del 19 de Mayo del 2008, la razon del cambio de nombre se debio a un problema de registro de marcas, ya que anteriormente existia una empresa que tenia el nombre de ZAPTEL que precisamente se dedicaba a vender telefonos, cuyo propietario se comunico con Digium para notificarles que cuando se realizaban busquedas en Internet , no se presentaban los productos relacionados a su marca, por este motivo Digium se vio obligado a cambiarle nombre al modulo, es asi que a partir de la version 1.4 de Asterisk incorporo Dahdi y Zaptel mientras se realizaba la migracion y los usuarios se adaptaban a este cambio; a partir de la version Asterisk 1.6 en adelante se usa unica y exclusivamente DAHDI.

Asterisk 1.2 unicamente es compatible con Zaptel.
Asterisk 1.4 incorpora tanto el paquete Zaptel como DAHDI.
Asterisk 1.6 únicamente soporta DAHDI y todas las demas versiones de Asterisk posteriores a esta.

Las siglas DAHDI hacen referencia a Digium/Asterisk Hardware Device Interface, es decir, una interfaz para toda la lista de productos Digium (y compatibles) que conecta con el sistema Asterisk, considerando que hablamos de productos que conectan concretamente con la PSTN (Public Switched Telephone Network, o Red de Telefonía Conmutada), la telefonía clásica, de toda la vida.

Introducción Módulo DAHDI

La estructura del módulo DAHDI es la siguiente:

Considerando que Asterisk trabaja sobre un sistema *NIX (Linux por ejemplo), es necesario establecer una capa de abstracción entre el hardware provisto (las tarjetas Digium y compatibles), y nuestro sistema operativo. Para ello disponemos el paquete DAHDI, el cual provee principalmente de todo el sistema de interfaz entre estos dos elementos, y los Drivers específicos de las tarjetas para poder ser reconocidas por nuestro sistema en el arranque.

Modulo DAHDI en Asterisk - Elastix

Todo esto se concentra por defecto en el directorio /etc/dahdi. Dentro de este directorio existe cuatro archivos principales:

  • modules: Encargado de gestionar los modulos en el Linux Kernel, para que se inicien automáticamente en el arranque. Por defecto lo ideal es anular todos los modulos (comentando las lineas donde estan con el simbolo ‘#’, y habilitarlos conforme vayamos necesitandolo según las tarjetas que insertemos). Esto es mejor, porque además durante la carga del sistema, si no tenemos la tarjeta insertada, pero si el módulo activado, tarda un rato intentando detectar automáticamente la tarjeta, lo que retrasa largos segundos la carga del sistema.
  • system.conf: Aquí es donde se provee la información exacta sobre como se conectarán las interfaces con nuestras tarjetas y otros parámetros especificos de las mismas, como lo relacionado a los canceladores de echo, comportamientos por zonas mundiales, etc…
  • init.conf: Se pueden específicar la inicialización o descarga de ciertos modulos adicionales, y scripts shell que queramos que sean ejecutados en la carga de la aplicación dahdi en el inicio.
  • genconf_parameters: Existe una aplicación capaz de configurar un system.conf generico, según las tarjetas que se hayan reconocido a traves del modules, de forma totalmente automática. Con este fichero podemos modificar un poco este comportamiento automático a nuestra volutad, por ejemplo cambiar el cancelador de eco software por defecto a uno más profesional como el oslec, en vez del clásico MG2.

Por otro lado, tenemos que ver como se interfasa DAHDI considerando que es una “aplicación” independiente, con nuestra máquina Asterisk. Para ello utiliza un módulo especifico, de tipo canal llamado chan_DAHDI.so, y opera de forma muy parecida a los otros módulos de canal como SIP e IAX.

Todo esto se configuraría gracias a un fichero especifico dentro del directorio de Asterisk de archivos de configuración /etc/asterisk/, llamado chan_dahdi.conf.

La configuración de todo esto, es muy específica en función del tipo de Telefonía clásica a la que hagamos referencia, dentro de la Red de Telefonía Conmutada.

Acceso a la Red de Telefonía Conmutada

Primero es importante entender como conectarnos utilizando esta infraestructura. Hay que considerar y conocer algunos aspectos básicos sobre este entorno, dado que en la actualidad, aun existen muchas empresas que aun trabajan con estos servicios, dado que por regla general, ofrecen unos niveles de servicio superiores a los ITSP (Internet Telephony Service Providers, o proveedores del servicio de telefonía a traves de Internet, los comúnmente conocidos Proveedores IP.

En España, y Europa, existen tres tipos de lineas disponibles:

  • Red de Lineas Analógicas, también llamadas RTB (Red de Telefonía Básica).
  • Red de Lineas Dígitales, RDSI (ISDN), Red Digital de Servicios Integrados, una extensión de la RTB con cierto componente de “digitalidad” dado que incorpora ya múltiples servicios digitales.
    • Acceso Básico, BRI (Basic Rate Interface), compuesto de dos canales full-duplex de voz, y un tercero de señalización
    • Acceso Primario, en Europa, se trabaja con la Trama E1, compuesta de 30 canales de voz, y dos de señalización (en EEUU, Canada y Japon se trabaja con la Trama T1 que tiene 24 canales).

Lineas Analógicas

Dahdi FXO - FXSEl sistema más sencillo para entender la telefonía PSTN es a traves de las lineas básicas analógicas. Suelen considerarse una conexión punto a punto, con dos terminales, en un lado el terminal de la Central Conmutadora de Telefonía, tambien llamado FXS (Foreign eXchange Station, estación exterior de intercambio), y por otro lado, el punto donde se conecta un terminal de telefonía, o en nuestro caso, una tarjeta Digium para recibir la linea de teléfono de la operadora PSTN, llamado FXO (Foreign eXchange Office, oficina exterior de intercambio).

El supuesto clásico sería un Operador de Telefonía, ofrece una linea a un domicilio, en la toma se conecta un teléfono analógico normal, esa toma se consideraría FXO, y donde se conecta a la “Centralita” de la operadora de telefonía, sería el punto FXS.

Señalización

La señalización a través de esa línea, se realiza a traves de señales supervisoras, y en función de la forma de realizar esta “supervisión” se pueden clásificar de tres formas:

  • Ground Start (GS), Inicio cuando hay toma Tierra, el sistema utilizado por los teléfonos de monedas clásicos, que no incorporaban ningún tipo de reconocimiento digital, la misma moneda realizaba la conexión a tierra
  • Loop Start (LS), Inicio por rotura del bucle, básicamente se trataba de mandar una señal supervisora, en bucle que fuera y viniera desde la central al telefono, en el momento que este descolgaba, se rompia el bucle y por tanto se mandaba una señal de tono para la llamada.
  • Kewl Start (KS), Inicio por rotura del Bucle con Supervisión de Desconexión (Aviso de desconexión o Hung-up, señal de colgado). Es una mejora del LS, y es el metodo más utilizada actualmente.

Modulo Chan DAHDI

El módulo de canal DAHDI, se encarga de establecer la conexión entre la interfaz DAHDI y nuestro sistema Asterisk, en forma de canal genérico, preservando la filosofía de que Asterisk se comporta igual ante cualquier tipo de canal soportado.

La configuración de este Módulo se establece gracias al fichero chan_dahdi.conf

Archivo de Configuración

En el archivo de configuración se establece como se interfasan los canales configurados en el sistema DAHDI, con respecto al sistema Asterisk en forma de dispositivos (similar a otras implementaciones como las del protocolo SIP), aparte de configuraciones generales que afectan al comportamiento del entorno DAHDI, y adicionalmente parámetros específicos que afectan a cada uno de los “canales” establecidos.

Contrario a otros archivos de configuración de Asterisk, existen dos formas de establecer la configuración. Por un lado el entorno general, se definen dos contextos genéricos [trunkgroups], donde se pueden agrupar varios troncales por comodidad de gestión y por otro lado [channels] donde se establece toda la configuración general.

En cuanto a los dispositivos específicos (o canales) y su configuración concreta, hay que considerar un aspecto importante. Antiguamente existe un modulo llamado Zapata y de alguna forma, al convertirse en DAHDI, se preservaron muchos de los métodos de configuración para favorecer a los antiguos usuarios. Por ello la configuración específica de los canales se puede establecer de dos formas:

  1. La versión antigua: Separadas por el parámetro channel => que indica fin de configuración de los canales y paso a la siguiente configuración de nuevos canales
  2. La versión actual: Utilizando contextos individuales con el nombre que deseemos a voluntad, y luego especificando los canales concretos que afectan al mismo con un parámetro llamado dahdichan, esto se asemejaría mucho más al resto de los ficheros de configuración y ademas permite la ventaja de incorporar “contextos plantilla”, por si hubiera que configurar múltiples canales con una configuración específica compartida, y luego otra configuración específica concreta.

En ambos casos, a continuación se específica el número de los canales a los que queremos hacer referencia.

Parámetros generales de Canal

Para el módulo del canal DAHDI, podría decirse que existe literalmente una infinidad de parámetros posibles. Podría afirmar que es el módulo con más personalización a nivel de configuración que existe en todo el sistema Asterisk. Algunos de los parámetros más comunes son los siguientes:

  • language: Idioma que vamos a usar
  • usercallerid: Si queremos usar el identificativo de la llamada
  • cidsignalling: Señalización CID, como opciones tenemos v23 y también esta la opción bell
  • cidstart: Definimos es la señal de inicio de llamada. Aquí en caso de lineas RTB normales, ring es lo mas común, pero en caso de usar enlaces GSM analógicos, seria una buena idea poner otro sistema como polarity_IN (inversión de polaridad) por el propio funcionamiento de los mismos.
  • hidecallerid: Permitir ocultar nuestro número identificador de llamada.
  • callwaiting: Permitir poner llamadas en espera, utilizamos el botón Hook Flash (comúnmente visto en los teléfonos analógicos con una letra R aunque configurable en la mayoría de los casos) para saltar de una llamada en espera a otra
  • callwaitingcallerid: En caso de poder tener llamadas en espera, permitir ver el Identificador de llamada cuando vamos saltando de una a otra llamada
  • threewaycalling: Permitir la llamada a tres activada, hay que considerar especialmente para llamadas a través de la PSTN, que estos valores deben estar soportados adicionalmente por la misma y la mayoría de los operadores nacionales suelen cobrar por estos “”servicios adicionales”.
  • transfer: Permitir poder transferir llamadas, no tanto por limitaciones de nuestro Dialplan, sino por el de la PSTN como hablamos antes
  • canpark: Permitir poder aparcar llamadas, lo mismo. Diferencia entre poner una llamada en espera y aparcarla, es que en el segundo caso la utilidad es por ejemplo, recuperar la llamada desde otra extensión diferente
  • cancallfoward: Permitir poder “reenviar” la llamada
  • callreturn: Poder volver a recibir de vuelta una llamada reenviada sin éxito
  • echocancel: Cancelación de eco activado
  • echocancelwhenbridged: En caso que la llamada se quede dentro de la red local interna, por ejemplo, haciendo una llamada desde una extensión analógica hasta un equipo SIP, para que no cancele el eco en vano (ya que la llamada realmente con mínimo retardo no lo requiere). Es curioso porque esta opción viene activada “yes” por defecto, y tenemos que desactivarla en la mayor parte de las configuraciones, dado que la cancelación de eco innecesaria puede ser incluso contraproducente (a dar la posibilidad de empeorar la calidad del audio)
  • echotraining: Tiempo que permitimos en milisegundos para “averiguar” con cuanto retraso viene la llamada y que nivel de cancelación de eco debe aplicar. En el algoritmo intervienen variables como el retardo medio, y el jitter que viene a ser algo así como la desviación estándar sobre el retardo medio.
  • relaxdtmf: Damos la posibilidad de relajar la detección de tonos DTMF
  • rxgain/txgain: Ganancias en decibelios de la llamada entrante y saliente respectivamente, se miden en decimales, de -4.00 a +4.00
  • busydetect: Permitir detectar si el llamado esta comunicando, a traves del tono estandar de “BUSY”.
  • busypattern: Patrón específico que representa al tono de comunicando, esto es diferente en cada país y lo suele suministrar una norma de la PSTN que puede ser consultada en las normas del proveedor principal. En españa por ejemplo iria bien con los valores (200,200).
  • answeronpolarityswitch/hanguponpolariryswitch: Parámetros fundamentales para como comentamos antes, la gestión de las llamadas en función si trabajamos directamente sobre una linea RTB, o si utilizamos un enlace GSM. En el primer caso, serian las dos opciones a no, y en el segundo caso, a si (yes)
  • faxdetect=incoming: Para detectar faxes entrantes, por ejemplo el valor a incoming si vamos a utilizar ese canal para recibir Faxes. También esta both para detectar ambos sentidos. El hecho de detectar faxes tiene ciertas aplicaciones como IAXmodem y Hylafax como aplicaciones de recepción de FAX para Asterisk, o envíos automáticos de llamadas, y gestión de las mismas con Marcadores
  • mohinterpret: Música en Espera a utilizar, si elegimos la definida por defecto sería default
  • mohsuggest: Música en Espera sugerida cuando ponemos una llamada en espera para este canal en concreto, por defecto default

Parámetros específicos

Aparte de los parámetros generales, podemos definir una serie de parámetros específicos dentro de los contextos o utilizando el antiguo método de subdivisión con el parámetro channel =>, entre los cuales se encuentran:

  • context: Contexto al que se dirigirán las llamadas de este canal
  • signalling: Tipo de señalización del canal al que hace referencia, puede ser por ejemplo fxo_ks, o fxs_ks para lineas análogicas con señalización Kewlstart, pri_net, pri_cpe para troncales primarios, etc.
  • callerid: Identificador de llamadas propio del canal en concreto
  • mailbox: Buzón de voz del canal específico

15,718 total views, 5 views today



!!! AYUDANOS A MANTENER ESTE SITIO ACTIVO…!!!

Si piensas que te hemos ayudado y merecemos tu apoyo. !!! GRACIAS !!!

Cuando lo hagas tendras acceso inmediato a la documentacion en formato PDF para que la descargues. Encontraras tambien otros tutoriales mas avanzados no publicados en el sitio. Si no puedes o no quieres, no hay problema igual tendras acceso a toda la informacion publicada en este sitio.

!!CLICK AQUI.!! para ver Tutoriales a descargar

!!! GRACIAS POR TU DONACION !!!









Enlace permanente a este artículo: http://elastixtech.com/modulo-dahdi-en-elastix/

Deja un comentario