Cuando vamos a instalar un Asterisk, comprobamos que el sistema operativo tiene las últimas versiones de los paquetes estables, que tenemos una versión de Asterisk marcada como estable (nada de trunk, team o release candidate), revisamos varias veces la configuración del dialplan, comprobamos que Asterisk se registra corréctamente con el proveedor IP y probamos a hacer llamadas y recibirlas para asegurarnos que todo marcha como debería hacerlo.
Pero a menudo nos encontramos con un inconveniente a la hora de probar la conexión con una tarjeta de comunicaciones, esto se puede hacer de las siguientes maneras:
- Conectándole una línea directa con el proveedor de telefonía.
Esto sería lo ideal, aunque no siempre es posible. - Conectando un simultador de líneas.
La pega es que estos dispositivos son bastante caros y complejos para alguien no acostumbrado a estos temas. - Conectándole otro sistema con señalización contraria que simule ser el proveedor.
El resultado de la prueba dependerá de cómo tengamos configurado el sistema contrario, lo que puede darnos un resultado nada concluyente.
Cuando vamos a probar una tarjeta analógica, no es difícil encontrar una línea directa con el proveedor de telefonía que nos suministre el voltaje necesario, los tonos y los cambios de polaridad necesarios para probar la tarjeta o bien algún tipo de dispositivo que genere el voltaje necesario y nos simule una línea (un spa3000, un grandstream fxs, o cualquier otro. De la misma manera aunque un poco más complicado es con una RDSI Básica, o bien tenemos una disponible, o bien tendremos que buscar algo que nos permita simular este tipo de líneas.
Lo que es bastante más complicado es disponer de un primario, y si no tenemos la suerte de tener otra tarjeta de primarios configurada en modo proveedor (NET) y que nos suministre la señal de timing, tendremos que buscar otra manera de comprobar que la tarjeta funciona corréctamente.
Para ello, podemos utilizar lo que se llama un «conector nulo» que no es más que un cable con unos pines conectados entre sí de manera que cualquier señal que enviemos por la tarjeta (puertos TX1 y TX2) la recibiremos por los pines destinados a la recepción (RX1 y RX2). Este método no nos va a permitir comprobar si la configuración del primario es correcta (ya que para eso necesitaremos del primario con sus parámetros y su configuración establecida por el proveedor) pero sí nos va a permitir asegurarnos que la tarjeta funciona correctamente.
Tendremos que utilizar el siguiente esquema con los pines indicados unidos entre sí, cargar el módulo necesario para la tarjeta (que creará los dispositivos /dev/zapX) y, con Asterisk descargado, utilizar la herramienta ‘patlooptest’ que viene en el paquete zaptel.
La aplicación patlooptest enviará secuencias de 1’s y 0’s aleatorias a través de los pines TX y esperará a recibir la misma secuencia por los RX.
De esta manera, comprobamos que:
– La tarjeta es capaz de enviar una secuencia binaria desde una aplicación hacia el exterior.
– La tarjeta es capaz de recibir la misma secuencia desde el exterior y hasta la aplicación.
El resultado de la prueba es trivial, si lo que enviamos es igual a lo que recibimos, entonces la tarjeta es correcta. Si lo que enviamos es distinto a lo que recibimos, entonces puede ser porque la tarjeta tenga algún tipo de fallo.
Si Asterisk está cargado al hacer el test, la prueba no será válida ya que Asterisk está continuamente enviando datos a través del primario para llegar a conectarse a un primario de verdad, por lo que, además de la secuencia que envíe el patlooptest, Asterisk enviará la suya, y la aplicación no recibirá únicamente los datos que espera si no también recibirá intercalados los datos que envía Asterisk y que no están controlados.
Las tarjetas no suelen entender de señalización (qsig, euroisdn, etc…) únicamente entiende de 1’s y 0’s, por lo tanto si en el arranque del módulo de la tarjeta (que ejecuta varios tests internos) el módulo no indica que la tarjeta esté mal, y al hacer el patlooptest los datos son correctos, entonces si la conexión con el primario no funciona, seguramente se deba a un fallo en la configuración o en los valores que tenga configurado el proveedor.
Si con este conector nulo encendemos Asterisk, nos encontraremos que Asterisk mostrará un mensaje de error al detectar que el «otro lado» tiene la misma configuración que nosotros, es decir: Si hemos configurado la tarjeta como PRI_CPE, entonces en el otro lado también será PRI_CPE en lugar de PCI_NET.
Una línea de primario no es un tipo de línea que podamos tener cómodamente en casa ya que está pensado principalmente para empresas con un gran número de llamadas entrantes y/o salientes, por lo que muchos de los usuarios que no trabajan con este tipo de líneas se encuentran con un gran vacío de documentación útil que pueda ayudarles a detectar dónde están los errores. Desde Sinologic vamos a dar algunas claves importantes para detectar errores, y evitar el «choque» que puede presentarse con el operador cuando una línea de este tipo no funciona como debiera.
Hace algún tiempo, buscando información sobre señalización MFC/R2 para primarios en Angola (como ex-colonia de Portugal, mucha tecnología proviene de Portugal y esta a su vez de Brasil) me encontré con un blog de un mejicano llamado Moises Silva (
