Diferencia entre revisiones de «DAHDI»

De Asterisk Wiki
Ir a la navegación Ir a la búsqueda
 
Línea 3: Línea 3:
 
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
 
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
  
 +
{{Centrar|{{#Widget:AdSense}}}}
  
 
__TOC__  
 
__TOC__  

Revisión actual del 17:39 6 jul 2014

Alert.png To Do
Esta página necesita ser completada.
Puedes revisar todas las páginas por completar en este enlace.


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.

Todo esto se concentra por defecto en el directorio /etc/dahdi. Dentro de este directorio existe cuatro ficheros 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[1], en vez del clásico MG2 [2]

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.

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 más detallados en el apartado SIP.

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

Gráfico FXO y FXS

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

Configuración DAHDI

Tarjeta TDM410P

Conociendo los aspectos básicos sobre las lineas de analógicas (Señalización y tipos de puntos terminales), es todo lo que necesitamos saber a priori, para establecer una conexión con nuestras interfaces de telefonía analógica y los teléfonos analógicos o lineas que nos provea nuestro operador.

La configuración que establecemos entre nuestro sistema Linux, y DAHDI se realizaría partiendo de los siguientes ficheros:

En Primer lugar, el fichero modules, tenemos que cargar el único módulo que hace referencia a una tarjeta analógica (estamos considerando un entorno en el que trabajamos con tarjetas principalmente Digium). Este módulo es el llamado wctdm24xxp

Archivo: /etc/dahdi/modules
# Digium TDM2400P/AEX2400: up to 24 analog ports
# Digium TDM800P/AEX800: up to 8 analog ports
# Digium TDM410P/AEX410: up to 4 analog ports
wctdm24xxp


Por otro lado, vamos a configurar DAHDI para que reconozca los puertos de esta(s) tarjeta(s). Considerando que existen varios módulos que se le pueden acoplar a las mismas, deberíamos indicar en cada puerto, si estamos haciendo referencia a módulos de tipo FXO o tipo FXS, ya que luego esta será la interfaz que conecte con el módulo de Asterisk para enviar la señal de telefonía.

Haciendo referencia al apartado de Digium sobre las tarjetas analógicas si nos encontramos por ejemplo ante una TDM410P, con dos módulos de color Rojo (FXO, X100M) en los zocalos 1 y 2, y dos módulos de color verde (FXS, S100M), en los zócalos 3 y 4, la configuración específica del fichero system.conf debería realizarse de la siguiente forma:

Archivo: /etc/dahdi/system.conf
loadzone=es
defaultzone=es
fxoks=1-2
fxsks=3-4


Y recargamos la configuración DAHDI:

# dahdi_cfg -vvv
DAHDI Version: 2.6.1
Echo Canceller(s):
Configuration
======================

Channel map:
Channel 01: FXO Kewlstart (Default) (Echo Canceler: none) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Echo Canceler: none) (Slaves: 02)
Channel 03: FXS Kewlstart (Default) (Echo Canceler: none) (Slaves: 03)
Channel 04: FXS Kewlstart (Default) (Echo Canceler: none) (Slaves: 04)

4 channels to configure.


Con esto ya tendríamos configurados los canales, listos para ser integrados en el módulo canal DAHDI.

Es posible además utilizar un cancelador de eco, una variante del KB1, llamado MG2, de tipo software, si añadimos las siguientes lineas al fichero de configuración system.conf:

Archivo: /etc/dahdi/system.conf
loadzone=es
defaultzone=es
fxoks=1-2
fxsks=3-4
echocanceller&#61mg2,1-4


Este cancelador de Eco no es demasiado potente y en caso de tener que trabajar con muchas lineas simultáneamente satura excesivamente el procesador. Existen otras alternativas como OSLEC ya comentado anteriormente, mucho más potentes, siempre considerando las grandes limitadores que los canceladores de Eco software ofrecen.

Módulo 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

Fichero de Configuración

En el fichero 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 ficheros 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

Referencias

  1. Cancelador de Eco OSLEC David Rowe (2008)
  2. Canceladores de eco Software Olle E. Johansson (3004)

Véase también

Enlaces Externos