Asterisk Advanced. Day 3

Hoy voy a hacer una prueba, escribir un articulo durante la clase a modo “Inline”. Seguramente salga un articulo demasiado extenso pero al menos, lo máximo completo.

– Teoría de Macros en el DialPlan

En primer lugar un tema que no hemos visto hasta la fecha y es crucial para configuraciones de dialplan repetitivas, las Macros.

Dos conceptos basicos

Las macros se componen del contexto del Macro [macro-<nombredelmacro>]

Solo tienen una extension, la “s”
exten => s,1,Answer()
same => n,Hangup

Por otro lado, las Macros se ejecutan desde el Plan de Marcacion, como una aplicación cualquiera con el formato Macro(<nombredelmacro>, <argumento1>, <argumento2>, etc)

Luego dentro del contexto Macro para poder utilizar esos argumentos llamados se utilizan las variables especificas de las macros ${ARG1}, ${ARG2}, etc

Ejemplo:

[extensiones]
exten => 100,1,Macro(prueba,SIP/mitelefono, 30)

[macro-prueba]
exten => s,1,Dial(${ARG1},${ARG2})

Aparte disponemos de variables especificas de las Macro. ${MACRO_CONTEXT}, ${MACRO_EXTEN} y ${MACRO_PRIORITY}. Sirven para saber dentro de la macro, que contexto, que extensión y que prioridad llamó a la Macro.

Un ejemplo, si utilizamos un Buzon de Voz, que coincide con el numero de extension pues podriamos utilizar ${MACRO_EXTEN}:

[extensiones]
exten => 100,1,Macro(prueba,SIP/mitelefono, 30)

[macro-prueba]
exten => s,1,Dial(${ARG1},${ARG2})
exten => n,VoiceMail(${MACRO_EXTEN})

A partir de aquí ya podemos dar “rienda suelta” a la imaginacion y poder simplificar nuestro trabajo de escritura de tareas repetitivas.

– Asterisk Realtime

Ya conocemos esto de artículos anteriores, como el uso del Web-MeetMe (configuraciones de salas de conferencia directamente desde la Web, a través de bases de datos en “tiempo real” (realtime).

Pero ahora una visión un poco mas práctica de como se trabaja con Realtime, ya que realmente el Web-Meetme siguiendo los pasos venia prácticamente preparado paso por paso y no podíamos entender que estaba haciendo realmente a nivel interno.

La utilidad de Realtime sobre configuraciones en ficheros de texto, es simplemente el hecho de poder introducir modificaciones constantes de una forma ultra-rapida (mediante un interfaz web por ejemplo que acceda a la base de datos).

Un ejemplo tipico: en la web vemos el listado de usuarios, con un boton para borrarlos cuando los damos de baja, y luego un mini formulario en el que ponemos el usuario y la contraseña y damos de alta una extensión inmediatamente. No habria que estar accediendo al servidor, accediendo al fichero de texto, editándolo, guardando, recargando el modulo, etc…

En configuraciones estáticas (situaciones en las que rara vez se cambia una extension por ejemplo), es poco practico por que puede salir mas caro el collar que el perro. Pero si un dia nos da por diseñar una interfaz web sencilla, y una base de datos (fichero .sql) que precargue nuestros valores default, podriamos implementar esto en tiempo record y podríamos tenerlo siempre presente en todas nuestras instalaciones (quizá algún día lo plantee esto como un articulo, muchos temas ya tengo pendientes conforme avanzamos en el mundo de Asterisk).

Un primer inconveniente que encontramos, es que Asterisk pretende centralizar todas las conexiones a bases de datos a traves de una capa de abstraccion como ODBC, es decir que los conectores directos nativos como MySQL y PostgreSQL tienden a su desaparicion. Para los no demasiado experimentados en el mundo ODBC esto podria ser un inconveniente a corto plazo.

Si recuerdan, el Web-Meetme lo hacia todo a traves de ODBC asi que este problema lo salvan (lo que no salvan que Meetme tiende a desaparcer tambien en favor de ConfBridge (nueva aplicación para conferencias sin necesidad de timing, tambien hablaremos de ella en un futuro).

Ahora sobre la configuración los ficheros involucrados

En primer lugar /etc/asterisk/extconfig.conf necesitamos añadir una linea del tipo
<nombredelaconfiguracion> => <driver>,<nombrebasededatos>,<nombretabla>

En el caso ejemplo del Web-Meetme era:
meetme => odbc,meetme, booking

El segundo fichero es el /etc/asterisk/res_config.conf

[nombrebasededatos]
enabled => yes // Esta activada la conexion
dsn => el Data Source Name del driver ODBC
pre-connect => yes // La conexión se ejecuta al arrancar Asterisk
username => usuario de la base de datos // En caso que conectemos por Puerto a la base de Datos, como en bases remotas
password => password de la base de datos // Lo mismo que lo anterior

En el ejemplo que estamos siguiendo:

[meetme]
dsn => meetme (este es el contexto que creamos antes en el sistema)
username => asterisk (supuestamente va a ser nuestro usuario para asuntos de Asterisk y servidor de base de datos)
password => asterisk (o la que le pusiéramos)
pre-connect => yes
enabled => yes

Ahora la configuracion del driver odbc en el sistema, /etc/odbc.ini

[meetme]
Description = ODBC para MySQL // Una descripcion cualquiera
Driver = MySQL // El driver ODBC que utilizamos, en este caso para MySQL por el tema ese que va a tender a desaparecer que comentábamos antes
Server = localhost // Servidor donde esta la base de datos
Database = meetme // Nombre de la base de datos con la que trabajaremos
Port = 3306 // Puerto de la base de datos
User = asterisk // En caso que conectemos por puerto en vez de por Socket
Password = asterisk // En caso que conectemos por Socket
Socket = /var/run/mysqld/mysqld.sock // Por aquí conectamos por Socket

Y finalmente /etc/odbcinst.ini

[MySQL]
Description = MySQL ODBC MyODBC Driver
Driver = /usr/lib/odbc/libmyodbc.so // librería ODBC del Driver MySQL
Setup = /usr/lib/odbc/libodbcmyS.so // librería ODBC de Configuración MySQL

Solo quedaria configurar la tabla y base de datos y ya preparado.

Algunas consideraciones adicionales: para reducir el numero de peticiones a cache, el fichero de configuracion del modulo que estamos convirtiendo en “RealTime” introducimos la siguiente variable: rtcachefriends=yes

De aquí pueden surgir multiples ideas prácticas que me gustaria probar personalmente y dedicar un articulo especifico con mis resultados, como por ejemplo, crear una funcion en func_odbc.conf para consultar algo especifico de una base de datos externa para tratarlo a traves del DialPlan, como por ejemplo consultar el telefono de un Cliente.

– CDR y CEL

Esta parte trata sobre como se gestiona CDR (Registro de Detalles de Llamada) y la nueva implementación mas detallada del registro CEL, en el que es posible ver a nivel de flujo de llamada de DialPlan, no solo a nivel de canal. La verdad es que es meramente informativa con informacion sobre los campos que se utilizan, y algunas aplicaciones de dialplan para edicion, pero realmente merece un articulo bastante amplio para poder entrar en detalle incluso algun mecanismo para extraer informacion como vimos en el articulo de CDR-Stats, una gran aplicación para poder visualizar los datos de forma bastante generica (y recuerdo que quede en montar un software para analizar llamadas pero mas en detalle para un proposito en concreto).

– El mundo de las Tarjetas Analogicas

Ya dedique varios articulos a este tema cuando empece a trabajar con la tarjeta TDM410P como el siguiente y la segunda parte del mismo.

Algunos conceptos novedosos y no vistos hasta la fecha:

Sobre la tecnologia Analogica, existen tres posibles de sistemas de señalizacion, (en el fichero chan_dahdi.conf) ground start (en desuso), loop start (tambien en desuso) y kewl start (sistema mas utilizado en la actualidad, 99% de los casos).

Otra novedad que trae la version 1.8 es la posibilidad de crear contextos en el chan_dahdi.conf y tener por ejemplo un contexto generico [channels] donde especificar ciertos argumentos especificos de la tecnologia analogica (que eran los que soliamos definir antes del channel => cuando utilizabamos un modulo FXO

Ejemplo:

[channnels]
usecallerid = yes
transfer = yes

[telefono-analogico]
callerid = “Telefono Analogico” <1001>
context= extensiones
signaling = fxo_ks
dahdichan = <el_canal_que_definimos_en_/etc/dahdi/system.conf>

[linea-analogica]
callerid=asreceived
context = llamadas_entrantes
signaling = fks_ks
dahdichan = <el_canal_que_definimos_en_/etc/dahdi/system.conf>

Pero luego, en el Dialplan tenemos que seguir definiendo en canal a la vieja usanza (DAHDI/1, DAHDI/2, etc…)

Dato importante de las lineas extrantes analogicas, es que hay que mandarlas a un contexto en el DialPlan (por ejemplo, llamadas_entrantes) y dentro de ese contexto, poner la extension “s” (start) ya que es imposible reconocer hacia donde pretende ir esa llamada por las limitaciones de la “analogia”.

Mañana parece que seguiremos con el tema de las conexiones de Tarjeteria, pero esta vez con una nueva que no hemos visto hasta la fecha, una tarjeta de Primarios.

Espero vuestros comentarios sobre como quedo esta “modalidad” de blogging inline. Para mi particularmente resulto mas comoda porque en los huecos libres podia ir escribiendo, y no tener que hacer todo el texto ya a deshoras y ademas tambien ha servido un poco con “apuntes personales” de lo visto para revisiones futuras (como realmente es el blog entero para mi personalmente).

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.