Combate Analogico: Segundo Asalto

Han pasado ya varios meses desde aquel mensaje en el que perdia la primera batalla tratando de conectar mi tarjeta Digium TDM410P.

Pues bien, tras la tramitacion del RMA de la misma, fue aceptada, y al poco tiempo de ser enviada, recibi una de vuelta, que tristemente ha quedado en la estanteria casi todo este tiempo, hasta que recientemente, he tenido la oportunidad de trastear con ella.

Concretamente en estos ultimos dias, he vuelto a montar otra maquina sencilla de pruebas, ya que el servidor anterior ha pasado a un estado de “semi-produccion” con un total de 10 extensiones en funcionamiento, y una concurrencia de unas 3-4 llamadas en horario laboral. A esta nueva maquina le he conectado la tarjeta digium, y he procedido como vimos en anteriores mensajes a instalarle Asterisk version 1.6.2 (que a fecha es la que mayor estabilidad me reporta). Es curioso como ya paso mucho tiempo desde aquel mensaje en el que planteaba otras versiones y la velocidad a la que va creciendo esto.

Ahora empieza el segundo asalto. Lo mas importante como se vio en el primer asalto, es conectar la tarjeta en la ranura PCI y conectarle un molex de la fuente, si vamos a utilizar como es nuestro caso, un modulo FXS. Esto es asi, por el hecho de que debemos entregarle corriente al telefono analogico conectado a este modulo, si solo tuvieramos modulos FXO en esta tarjeta, no haria falta realmente este conector.

En este caso, disponemos de un modulo FXS conectado en el puerto 1 y un modulo FXO en el puerto 4. Si realizamos la instalacion correcta de dahdi-linux-complete, solo necesitariamos tener un modulo activado en el fichero de configuracion /etc/dahdi/modules para que nuestro sistema reconozca esta tarjeta de inmediato: wctdm24xxp

Por otro lado como vimos en su dia, lo necesario para configurar el fichero /etc/system.conf ya fue explicado. Solo hay que recordar el inciso que si el modulo es FXS ponemos fxoks y viceversa para el FXO, realmente indicamos lo que va a haber en el otro extremo, a mi personalmente me resulta un poco contra la logica sencilla, pero seguramente a otro nivel de logica, tiene mucho sentido, con el tiempo averiguare esto y si cabe os lo contare. Y tambien recordar que el FXS es el verde y el FXO el rojo.

Una vez hechas estas configuraciones, solo quedaria adaptar nuestro fichero chan_dahdi.conf de asterisk para poder trabajar con estos modulos (aparte de la consiguiente configuracion del Plan de Marcacion para dar un uso practico finalmente).

El fichero chan_dahdi puede ser tan sencillo o tan complejo como deseemos ya que permite una personalizacion casi milimetrica del sistema con respecto a la red telefonica.

El contexto principal en este fichero es [channels] y a partir de ahi surgen varias configuraciones basicas que voy a comentar a continuacion

[channels]
language=es
// Lenguaje que vamos a usar
usercallerid=yes
// Si queremos usar el identificativo de la llamada
cidsignalling=v23
// Señalizacion CID mas comun, tambien esta la opcion bell
cidstart=ring
// Cual es la señal de inicio de llamada. Aqui en caso de lineas RTB normales, ring es lo mas comun, pero en caso de usar enlaces GSM analogicos, seria una buena idea poner otro sistema como polarity_IN (inversion de polaridad) por el propio funcionamiento de los mismos que no viene al caso ahora, aunque yo los he probado con ring y tambien funciona aun con mas propensidad a fallos.
hidecallerid=no
// Autoexplicativo, si quieremos ocultar nuestro identificador de llamadas
callwaiting=yes
// Si podemos poner llamadas en espera, utilizamos el boton Hook Flash (comunmente visto en los telefonos analogicos con una letrita R aunque configurable en la mayoria de los casos) para saltar de una llamada en espera a otra
callwaitingcallerid=yes
// En el caso de poder tener llamadas en espera, poder ver el Identificativo de llamadas cuando vamos saltando de una a otra llamada
threewaycalling=yes
// Llamada a tres activada, hay que considerar especialmente para llamadas a traves de la PSTN, que estos valores deben estar soportados adicionalmente por la misma y la mayoria de los operadores (Telefonica) suelen cobrar por estos “servicios adicionales”.
transfer=yes
// Poder transferir llamadas, no tanto por limitaciones de nuestro Dialplan, sino por el de la PSTN como hablamos antes
canpark=yes
// 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 extension diferente
cancallfoward=yes
// Para poder “reenviar” la llamada
callreturn=yes
// Para poder volver a recibir de vuelta una llamada reenviada sin exito
echocancel=yes
// Cancelacion de eco activado
echocancelwhenbridged=no
// En caso que la llamada quede “dentro” de la red ejemplo, de una extension analogica a un equipo SIP, para que no cancele el eco en vano (ya que la llamada realmente con minimo retardo no lo requiere). Es curioso porque esta opcion viene activada “yes” por defecto, y tenemos que desactivarla en la mayor parte de las configuraciones chan_dahdi
echotraining=800
// Tiempo que tarda en ms para “aprender” como de “retardada” viene la llamada y que cancelacion de eco debe aplicar. En el algoritmo intervienen variables como el retardo medio, y el jitter que viene a ser algo asi como la desviacion estandar sobre el retardo medio.
relaxdtmf=yes
// Ya habiamos visto esto en la parte SIP… los dichosos DTMF suelen ser motivo de problemas especialmente partiendo de la base de que no sabemos que sistema lleva el llamante.
rxgain=1.0
txgain=2.0
// Ganancias en decibelios de la llamada entrante y saliente respectivamente
busydetect=yes
busypattern=200,200
// Con estas opciones, simplemente detectamos si el otro lado esta comunicando con un tono de comunicando clasico en nuestro auricular. Ademas podemos especificar la cadencia en ms de el tono de llamada a detectar. Esto es diferente en cada pais y lo suele suministrar una norma de la PSTN que puede ser consultada en las normas del proveedor principal, en caso de España, Telefonica por ejemplo
answeronpolarityswitch=yes
hanguponpolariryswitch=yes
// Esto es fundamental para como comentamos antes, la gestion de las llamadas en funcion 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, es util, si vamos a utilizar ese canal para recibir Faxes. Tambien esta both para ambos sentidos. El hecho de detectar faxes tiene ciertas aplicaciones como IAXmodem, Hylafax como aplicaciones de recepcion de FAX para Asterisk, o envios automaticos de llamadas, y gestion de las mismas con Autodialers.
mohinterpret=default
// Musica en espera por defecto
mohsuggest=default
// Musica en espera sugerida cuando ponemos una llamada en espera para este canal.

Para todo esto que he explicado, hay miles de opciones y configuraciones posibles. Aqui he puesto una configuracion valida de ejemplo para funcionar desde 0. Se pueden consultar las opciones directamente en las explicaciones mismas que trae el fichero de ejemplo proporcionado por el propio sistema generado por la opcion del make de Asterisk “samples”.

Finalmente, metemos la configuracion especifica de los canales para luego ser tratada desde nuestro Dialplan. En mi caso, he conectado un telefono Dect en el canal 1 (FXS), y un Enlace GSM en el canal 4 (por eso he puesto las opciones anteriores basadas en este caso en concreto). Asi quedaria:

group = 1
// Grupo de llamada, equivalente al fichero SIP
context= desde-movil
// El contexto al que sera dirigidas las llamadas entrantes por este canal
signalling = fxs_ks
// Señalizacion del canal, en este caso si es intuitivo
callerid=asreceived
// No se si recuerdan cuando se configuro el gateway Epygi, una de las opciones que habia que poner en la configuracion de las lineas ISDN es como pasar el Identificador de llamante al sistema. En este caso, tal como viene decimos
channel => 1

Asi por un lado quedaria configurado el canal 1, FXS. Por otro lado el canal 4 FXO quedaria asi:

group=4
context=extensiones
signalling=fxo_ks
callerid=”Telefono DECT” <101>
mailbox=101@extensiones
channel=>4

En este caso, como puede observarse es exactamente igual que la configuracion del fichero SIP en cuanto a lo que contexto, callerid, mailbox y demas pudiere referirse.

Con esto ya quedaria integramente configurado nuestro fichero chan_dahdi.conf. Para “recargarlo” desde la consola (CLI) Asterisk tenemos que utilizar el comando:
module reload chan_dahdi.so

Para la configuracion del Dialplan solo tomamos en cuenta una consideracion muy sencilla. Los canales analogicos por tarjetas se representan como DAHDI/X siendo X el canal. Asi que toda la configuracion del extensions.conf es equivalente a si pusieramos SIP/(nombre del contexto sip) pero con DAHDI

Ejemplo, para la extension 101 del telefono Dect

exten => 101,1,NoOp()
exten => 101,n,Answer
exten => 101,n,Dial(DAHDI/4)
exten => 101,n,Hangup

Asi de sencillo, asi mismo para enviar una llamada a traves del FXS creamos una regla para moviles en mi caso (Enlace GSM conectado al canal 1)

exten => _[67]XXXXXXXX,1,NoOp()
exten => _[67]XXXXXXXX,n,Dial(DAHDI/1/${EXTEN})
exten => _[67]XXXXXXXX,n,Hangup()

Por cierto ya que ha salido el tema, ¿os habeis enterado que como novedad este 2011 empezaran a salir numeros moviles que empiezan por el 7?

Finalmente creariamos el contexto [desde-movil] para recepcionar todas las llamadas entrantes, si es que llamasen al numero del movil en cuestion asociado al canal 1.

Y con esto ya hemos ganado el segundo Asalto, abordando un poco la cuestion relacionada a las tarjetas de Asterisk y su configuracion despues de lo que se sufrio en dias pasados. De todas formas esto no sera muy frecuente en mis sucesivos mensajes porque como comente, yo no soy nada partidario de utilizar tarjetas por los motivos que explique en su dia. Aunque es curioso que todo aquel que se quiera presentar a un dCAP (logico, porque digium solo fabrica principalmente tarjetas), ha de conocer esto en profundidad. Hay que ademas saber tratar con tarjetas BRI y PRI que tienen ciertas variaciones muy especificas. Pero para eso existe un comando todo poderoso que te hace la mitad del trabajo: dahdi_genconf. Basicamente te configura el fichero system.conf tras chequear que hay disponible entre la tarjeteria cargada en el sistema (Y que puede observarse con el comando dahdi_tools). Quiza vengan en un futuro mas detalles si tengo la oportunidad de trastear con otras tarjetas, sean BRI de otras marcas (¿Beronet?) o alguna tarjeta Primaria de Digium (creo que es la unica tarjeta que verdaderamente merece la pena en cualquiera de los casos).

Para terminar me gustaría sugerir a todo aquel seguidor de mi Blog, si tiene interés en que profundice o experimente en algún tema no dude en planteármelo como un comentario y procederé con la cuestión. Todo sea por mejorar la curva de aprendizaje de todos aquellos que me sigan tras el paso por este Blog a través de mi experiencia.

Combate Analogico: Primer Asalto

En estos dias, como ya adelante, he estado tratando de integrar la telefonia Analogica en la centralita de pruebas.

Para ello he utilizado la tarjeta que me ofrecieron en el curso, la Digium TDM410P y que nunca se llego a probar por problemas de tiempo (solo se explico por encima la idea de configuracion y varios de los atributos mas comunes).  Esta tarjeta trae dos modulos, uno Verde (FXS para conectar un telefono por ejemplo analogico) y una FXO (para conectar una fuente, una linea analogica de la PSTN, una extension de una centralita)

Como introduccion, comentar que en Asterisk, el mundo analogico se integra a traves de los modulos Dahdi, Dahdi-Linux-Complete fue el paquete que instale y que estaba compuesto por dos subpaquetes como comente en su dia

Por otro lado, hay que saber que Dahdi digamos que tiene dos formas de comunicacion: Una directamente con el sistema, con el Kernel de Linux, añadiendo los modulos y drivers de las tarjetas, y la configuracion especifica. La carga de modulos se especifica en el fichero /etc/dahdi/modules y los parametros de configuracion de las tarjetas en el Kernel en el fichero /etc/dahdi/system.conf

Concretamente en el fichero modules, el modulo que nos interesa seria el correspondiente a las tarjetas TDM410P, el wctdm24xxp. El resto los podriamos eliminar porque no vamos a usarlos eventualmente

Para la configuracion de la tarjeta, en el fichero system.conf  he utilizado lo siguiente, comentado, la explicacion sobre cada elemento:

# Puerto 1 tarjeta Analogica = Modulo FXS VERDE
fxoks=1
# Puerto 4 tarjeta Analogica = Modulo FXO ROJO
fxsks=4
loadzone=es
defaultzone=es
# Canceladores de Eco Software
echocanceller=mg2,1
echocanceller=mg2,4

Por otro lado, seria necesaria la configuracion del fichero que “intercomunica” los modulos de la tarjeta con nuestro sistema Asterisk. Esto se registra en el fichero /etc/asterisk/chan_dahdi.conf (Canal Dahdi, equivalente en este caso al Canal SIP que vimos con anterioridad).

Pero antes de esto estuve investigando a ver si realmente la tarjeta estaba totalmente operativa. Hay un comando, dahdi_tools que muestra el estado de la tarjeta y de sus modulos por encima, y pude observar como aparecia la Wildcard TDM410 correctamente.

Pero por otro lado, observe que conectando un telefono al puerto FXS, este no recibia ningun tipo de corriente. Entonces cai en la cuenta que era necesario aportarle corriente a la tarjeta TDM a traves de un conector Molex que integra la placa. Asi, hice la conexion oportuna y volvi a arrancar el sistema.

Y aqui empezó lo malo del dia: el telefono seguia sin recibir corriente. Dos de los LEDS de la tarjeta parecian encendidos indicando, que los modulos estaban operativos. Investigando un poco en los mensajes del Kernel durante el inicio (Comando: dmesg) encontre la siguiente Salida en relacion a la tarjeta

dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.3.0.1
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
wctdm24xxp 0000:05:08.0: PCI INT A -> Link[APC3] -> GSI 18 (level,
low) -> IRQ 18
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: ProSLIC on module 0 failed to powerup within
510 ms (0 mV only)
— DID YOU REMEMBER TO PLUG IN THE HD POWER CABLE TO THE TDM CARD??
wctdm24xxp 0000:05:08.0: Unable to do INITIAL ProSLIC powerup on
module 0
wctdm24xxp 0000:05:08.0: Port 1: FAILED FXS (FCC)
wctdm24xxp 0000:05:08.0: Port 2: Not installed
wctdm24xxp 0000:05:08.0: Port 3: Not installed
wctdm24xxp 0000:05:08.0: Port 4: Installed — AUTO FXO (FCC mode)

Aqui pude obsevar como exactamente, el puerto FXS no estaba recibiendo corriente. Investigando por el mundo Google, encontre, que podia ser causa de problemas en el conector Molex, que no estuviera recibiendo la corriente adecuada. Tenia yo la sensacion que esto no iba a ser cierto, ya que en esa misma maquina, otros Molex en otros dipositivos estaban funcionando perfectamente, y al conectar esos mismos Molex en la tarjeta seguian dando el mismo error.

Ademas para no desistir en el intento, probe varias combinaciones en los canales de la tarjeta, con los modulos, poniendo el FXS en practicamente los 4 canales, y lo mismo el FXO. El FXO daba el simbolo de correcto mientras que el FXS en todos los slots daba el mismo error.

Aun asi, todavia quedaban pruebas. Necesitaba comprobar que en el conector macho de la tarjeta, se estaba recibiendo la corriente necesaria para su fucionamiento (12V). Asi que me hice con un voltimetro para comprobar que efectivamente lo recibia perfectamente como se puede observar en las fotos siguientes:

Siguiendo en la insistencia, podia ser un problema (que dudaba en grandisima consideracion vista la ultima prueba), de falta de potencia de la fuente de alimentacion. Pero no queria desistir, y necesitaba -probarlo- todo. Asi que busque una fuente con 100W adicionales (la que hay montada es una Levicom 85+ Bronze de 350W que estoy seguro que le sobra potencia a patadas). Me hice con una fuente de 460W la conecte al equipo como puede observarse en la foto siguiente, y haciendo la misma prueba con el voltimetro que antes, se podia observar que llegaba la corriente adecuada:

Por esto, y en conclusion, me doy por vencido en este primer Asalto ya que no he conseguido configurar un Telefono Analogico a la centralita.

Proximamente, intentare configurar el Puerto FXO que parece ser que si funciona, para recibir como entrada una linea analogica que proviene de una centralita. De alguna forma quiero tratar de integrar esa centralita a traves de una de sus extensiones, con mi Centralita Asterisk, para ver si puedo emitir llamadas a otras extensiones de esa centralita, y ver si puedo recibir llamadas que vengan de esa centralita, en mi sistema y tratarlas, quien sabe, con una mini-operadora de pruebas.

Ademas esta prueba, me servira para comprobar si la tarjeta Digium esta en buenas condiciones, y plantear tramitar en Garantia el pequeño modulo verde FXS que estos problemas me ha dado.

Si se os ocurre cualquier idea que no haya probado aun, con el modulo FXS y que quiza se me haya escapado y pueda resolver mi problema, no dudeis en comentarlo, seria ampliamente agradecido por mi parte.