No deberíamos decir siquiera que, un primario es una comunicación entre dos sistemas (nuestro Asterisk y el operador) y, como tal, debemos tener en común los distintos parámetros que conforman la configuración de este tipo de líneas. De poco nos sirve que el operador nos provea de un primario y no nos indique la señalización, quién actúa como fuente de reloj o si disponemos de CRC4 o no. También hay que tener en cuenta que, mientras en Europa, Ásia y África se sigue un estándar bastante estricto sobre los parámetros, en América, Australia o Japón no existe esta «ventaja» y hay que conocer bastante bien todos los parámetros de la línea de primarios que nos ofrece el operador para conseguir configurarla correctamente.
Pero aún así nos encontramos con que, aun habiendo configurado «aparentemente» bien el primario, aparecen errores, caídas de llamadas, bloqueos de canales, imposibilidad de realizar llamadas, etc. Lo primero que hemos hecho es aumentar el debug del sistema buscando errores que puedan darse (en el archivo /etc/asterisk/logger.conf, habilitando el parámetro ‘debug‘ en ‘console’ o en ‘full’) de esta forma podremos ver si aparece algún mensaje de error que no debería ser, identificándola, entendiendo qué dice y buscando información sobre qué significa y cómo solucionarla.
En otras ocasiones, sobre todo cuando algo no funciona y el operador menciona la frase «hemos estado monitorizando la línea y por nuestro lado está todo correcto«, es el momento de comprobar qué está ocurriendo a nivel interno, a nivel de protocolo y ver qué ocurre, quien envía qué y demostrarnos o demostrarle al proveedor quién es el culpable de que las cosas no funcionen como deberían.
Primero, y antes de meternos en más líos, hay que entender que, si una línea ha estado funcionando bien durante varios meses, y de repente ha dejado de funcionar, sin que hayamos realizado ningún cambio, está más que claro que el culpable es el operador. Esto es porque el operador, para ofrecernos una línea, dispone de una centralita (si, como la que estamos configurando) y a diferencia de una empresa, esta centralita se modifica cada vez que hay un cliente nuevo, o le cambian el número de teléfono a alguien, o le aumentan el número de líneas disponibles, o dan de baja a alguien, o cualquier otro caso…) por lo que es más normal que, si de repente algo que ha funcionado durante un tiempo, ha dejado de funcionar, sea causado por el operador, más que porque hayamos configurado algo más hace meses y ha funcionado «a saber por qué».
Si vamos a ver quién tiene la culpa y porqué las cosas no funcionan como deberían, vamos a utilizar el protocolo Q.931 para analizar qué enviamos y qué recibimos, ver qué deberíamos recibir, qué deberíamos enviar y porqué hay algo que falla.
Al ejecutar el PRI INTENSIVE DEBUG SPAN X (en Asterisk 1.4 es PRI INTENSE DEBUG SPAN X) donde X es el número del span qué queremos monitorizar, vamos a empezar a recibir una cantidad enorme de datos, tantos que no es viable tenerlos en la consola, por lo que lo suyo es volcar todo a un archivo y analizar dicho archivo posteriormente. Para ello, vamos a utilizar el siguiente comando:
asterisk -rnvvvvvddddddd |tee /tmp/volcado.tmp
De esta manera, todo lo que veamos por la consola, lo volcaremos a un archivo (el parámetro ‘n’ es para evitar que los colores de la consola aparezcan en el archivo y nos aparezcan caracteres raros donde no deberían).
Una vez ejecutado el comando, estaremos ‘dentro’ de la consola CLI de Asterisk y entonces ejecutaremos el comando:
PRI INTENSIVE DEBUG SPAN 1
Lo dejaremos expulsando datos tanto tiempo como queramos monitorizar y una vez finalizado, salimos de Asterisk y pasaremos a analizar el archivo /tmp/volcado.tmp. Este archivo mostrará todo lo que nos ha salido en la consola, por lo que también deberíamos tener los datos del debug y del Intensive Debug.
Lo primero que debemos observar es «el sentido» del mensaje, este se indica por unas flechas ( < o bien > ) de forma que, considerando que Asterisk está a la izquierda y el «otro extremo» a la derecha, si el mensaje viene con la flecha ‘<‘, significa que es el operador quien envía el mensaje a Asterisk, y si aparece la flecha ‘>’, es de nuestro Asterisk enviándoselo al operador. Esto no significa que el mensaje llegue a su destino, pero sí que Asterisk lo envía.
Vamos a ver un ejemplo de un mensaje de Asterisk al operador:
> Message type: SETUP (5) > [04 03 80 90 a3] > Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) > Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) > User information layer 1: A-Law (35) > [18 03 a1 83 83] > Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Preferred Dchan: 0 > ChanSel: As indicated in following octets > Ext: 1 Coding: 0 Number Specified Channel Type: 3 > Ext: 1 Channel: 3 ] > [6c 0b 21 80 39 31 34 39 30 36 30 31 35] > Calling Number (len=13) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) > Presentation: Presentation permitted, user number not screened (0) '9XXXXXXXX' ] > [70 0b 80 30 39 31 34 3a 38 38 34 40 36] > Called Number (len=13) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '09XXXXXXXX' ] > [a1] > Sending Complete (len= 1)
Este es un mensaje ‘setup‘, el mensaje que inicia la llamada, en este caso, y viendo el sentido de la flecha, el mensaje lo envía Asterisk al operador, por lo que podemos deducir que es nuestro Asterisk quien le envía la llamada al operador.
< Message type: CALL PROCEEDING (2)
< [18 03 a9 83 83]
< Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive Dchan: 0
< ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 3 ]
Aquí, el operador nos envía un ‘call prodeeding‘, un mensaje que indica que ha recibido nuestra petición de iniciar la llamada y está procediendo a realizar la llamada.
A -> SETUP -> B
A <- CALL PROCEEDING <- B
A <- ALERTING <- B
A <- CONNECT <- B
A -> CONNECT ACKNOLEDGE -> B
En este momento se mantiene la conversación.
A -> DISCONNECT -> B
A <- RELEASE <- B
A -> RELEASE COMPLETE -> B
Cada parámetro, lleva una descripción y valores que nos informan del códec que utiliza el otro extremo (o nosotros), el número marcado, el número que se va a enviar, el tipo de llamada que es (por lo general, se suele configurar como ‘unknown‘ para que sea el otro extremo el que progrese la llamada como mejor le venga) y mucha más información, pero si en una conversación vemos que falta algún mensaje, podemos asegurar que hay algo que no está bien.
Para terminar, comentar que además de estos mensajes, pueden darse otros, aunque estos son los estándar, como en el caso de la señalización QSIG donde además de estos mensajes vienen otros llamados: [ROSE] y que incluye información extra.
Cuando no hay llamadas, para seguir manteniendo la conversación se suele enviar otro tipo de mensajes llamados ‘RR‘ (que vienen de Receive Ready o de listo para recibir) y suele ser algo así:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N(R): 054 P/F: 1
< 0 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 53 to (but not including) 54
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (112)
Esto significa que está a la espera de que le enviemos una llamada (fijaos en el sentido de la flecha), aunque en este caso, ambos extremos seguirán manteniendo y enviando sus correspondientes mensajes ‘RR’ al otro extremo, por lo que la comunicación sigue en funcionamiento.
El mundo de los primarios, requisitos y configuración, así como los errores típicos y cómo detectarlos, suele ser un mundo bastante ámplio y, porqué no, un poco complejo, no obstante espero que este artículo os ayude a entender un poco mejor cómo funciona uno por dentro y cómo detectar errores tanto de nuestro lado, como del lado del operador.