(por cuestiones de confidencialidad no puedo revelar nombres, pero esta historia aplica en general)
Desde el pasado noviembre recibí una llamada de uno de mis clientes indicándome que su equipo Elastix muy frecuentemente le daba el ya conocido mensaje «todos los circuitos se encuentran ocupados«. Su enlace con la PSTN era a través de un enlace digital E1 ISDN. Pensé que algo estaría mal con la configuración del equipo, así que decidí acceder a la consola para ver que era lo que lo ocasionaba.
Intentó varias llamadas a un mismo número: todas fallaron. Mi creencia fue pensar que Elastix estaba mal interpretando el código Q.931 que el carrier entregaba de vuelta tras el resultado de la llamada. Para quienes no saben, el Q.931 es el protocolo estándar de la ITU para la señalización de control de conexión en ISDN (en otras palabras, es el responsable de indicar el estado de una llamada generada a través de un E1 ISDN). Por default, Elastix interpreta prácticamente todo con la misma respuesta de «todos los circuitos se encuentran ocupados», por lo que a pesar de que la razón de terminado de la llamada sea una congestión del carrier o bien que el número marcado no existe, siempre obtenemos la misma respuesta.
Implementé la solución de uno de mis post anteriores esperando que eso resolviera el problema y el cliente se enterara de cual era la verdadera razón para la desconexión. Poco tiempo paso cuando mi cliente me indicó que no hubo cambio, sino que todo continuó exactamente igual que al principio (mismo mensaje para todos los casos). Esto me extrañó dado que esta solución ha sido exitosa en muchos casos e inclusive, otras empresas lo han sugerido a sus clientes para resolver problemas con el servicio recibido por otros carriers, por lo que tuve que indagar más para encontrar la causa del problema.
Tras analizar los logs, encontré cientos de registros como este:
[Feb 9 08:34:03] VERBOSE[10458] pbx.c: -- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/31163-00002883", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 31 - failing through to other trunks") in new stack
[Feb 9 08:36:42] VERBOSE[10472] pbx.c: -- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/31142-0000288d", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 31 - failing through to other trunks") in new stack
[Feb 9 08:42:10] VERBOSE[10499] pbx.c: -- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/31161-00002897", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 31 - failing through to other trunks") in new stack
[Feb 9 08:44:45] VERBOSE[10512] pbx.c: -- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/31131-0000289c", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 31 - failing through to other trunks") in new stack
[Feb 9 08:49:55] VERBOSE[10523] pbx.c: -- Executing [continue@macro-dialout-trunk:3] NoOp("SIP/31112-0000289f", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 31 - failing through to other trunks") in new stack
Aquí se aprecia que el código de terminación de la llamada fue el 31. Si buscamos en Google encontraremos que el código 31 dice «Normal, unspecified», significando que la llamada terminó por causas normales que no fueron especificadas. Esto es normal de vez en cuando, pero tener tantos intentos fallidos en el mismo intervalo de tiempo me hizo investigar más.
Encontré los números que se marcaban y tomé mi línea analógica convencional y marqué a ellos. Los resultados fueron diferentes para los diferentes números:
- «El número que marcó está fuera de servicio»
- «El número que marcó está suspendido»
- «El número que marcó no existe»
- «El número celular que usted marcó no está disponible o se encuentra fuera del área de servicio»
Entonces no era problema que todos los canales estuvieran ocupados, sino que el carrier NO estaba regresándonos la causa correcta de terminación de la llamada para cada caso específico. Esto es sumamente importante, ya que en base al código de error obtenido sabes como debes retroalimentar a los usuarios para que reintenten pasados unos minutos o bien, que dejen de intentar llamar a un número imposible de localizar.
A pesar que trates de explicarle esto a los clientes, muchos no entienden que las líneas digitales se basan en códigos de error y no en grabaciones que escuchan en su línea al momento de marcar. Decir que todos los circuitos están ocupados normalmente es asociado con problemas de capacidad (piensan que hacen demasiadas llamadas simultáneas) o con un problema del conmutador, y acaban echándote la culpa a ti como proveedor del mismo.
Como el problema escalaba de lo que éramos capaces de ofrecer (ya que el enlace es provisto por el carrier, no por nosotros) no nos quedó de otra que levantar la incidencia. Esto fue desde noviembre 2011. Múltiples pruebas se tuvieron que hacer para demostrar a los ingenieros de soporte del carrier que el problema no venía del conmutador, sino de su enlace (o bien, de la interconexión de ellos con el destino al que se estaba marcando).
Tras 3 meses de idas y vueltas, reportes enviados y pruebas fallidas, antier me reportaron que por fin pudieron cumplirse pruebas exitosas del proyecto. El problema radicó en la interconexión entre carriers, no en la conexión de Asterisk.
Los ingenieros de soporte nos hicieron notar que gracias a la insistencia de nuestra parte el problema pudo detectarse e inclusive, se corrigió para todos los usuarios del mismo tipo de servicio. Inclusive la retroalimentación fue que muchos proveedores de conmutadores de telefonía convencional disfrazan los códigos de error recibidos para otorgarle al usuario respuestas aceptables en los problemas de los enlaces digitales. Sin embargo, Asterisk es de los pocos conmutadores con acceso total a la información (sin restricciones), por lo que pudimos meternos a hacer un debug intensivo del medio y pudimos refutar al carrier que el problema no venía de nuestro lado.
Sin acceso a la información que Asterisk entrega, nunca hubiéramos tenido las pruebas para acusar a quien tuvo la verdadera culpa del problema y hoy, seguiríamos igual que al principio.
Creo que la moraleja de esta historia es: nunca asuman que el proveedor grande siempre tiene la razón. Consigan pruebas, experimenten y evalúen sus resultados. Es muy probable que ustedes sean quienes puedan salir victoriosos de la contienda, solo infórmense bien de lo que ustedes saben que deberían estar recibiendo.
¡Suerte!
