El carrier no siempre tiene la razón

1 Mar

(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!

Christian Cabrera

Soy un ingenieron en comunicaciones con especial interés en el área de voz sobre IP y tecnologías sobre información. He usado Asterisk de manera diaria desde hace más de 12 años.En el 2011 co-fundé Enlaza Comunicaciones, una empresa que se especializa en brindar servicios profesionales de consultoría sobre voz sobre IP basadas en Asterisk.

  • Saul Uribe

    Totalmente de acuerdo, precisamente hoy un cliente me comento tener mucho CONGESTION en el marcador automatico, y me decia que asterisk no funcionaba correctamente, tras marcar unos numeros manualmente desde una linea convencional encontre que muchos numeros no habia sido asignados, otros estaba “en reparacion”, etc. Los carriers se puede poner dificiles cuando uno les dice que ellos tiene problemas.

  • vlass

    Hola que buen foro, esto precisamente me esta pasando a mi, tengo instalado elastix 1.6, utilizo una tarjeta E1, las troncales las tenemos contratadas con el proveedor de telefonía Maxcom la cual definitivamente es un martirio con los carriers, ellos solo arrojan un tono de ocupado cuando no contactas un número por cualquier razón que “no exista”, “el número que usted marco no esta disponible o se encuentra fuera del área de servicio”, “el número que marco esta suspendido por exceso de pago, favor de no reportarlo”, etc., Esta compañia definitivamente solo se escuda en que no cuenta con esos servicios debido a los monopolios de Telmex, No pueden hacer mas, aqui lo curioso es que en determinadas llamadas las grabaciones usuales “el no existe”, “Línea ocupada” si son reproducidas por asterisk, me imagino que los teléfonos a los que se marcan pertenecen a telmex quién devuelve las grabaciones convencionales, cuando se marca a uno de maxcom o cualquier otra compañia te puede arrojar diversos resultados y uno de ellos es precisamente esta grabación reproducida por asterisk. Total que uno puede buscarle por donde sea en los archivos de configuración, porque para eso las compañías siempre te dicen que el problema es con tu servidor, pero definitivamente el problema radica en las compañías que ofrecen los servicios.

    Executing [s-CONGESTION@macro-dialout-trunk:3] NoOp(“SIP/164-b6ef6510”, “TRUNK Dial failed due to CONGESTION – failing through to other trunks”) in new stack

    Esto es lo que te muestra el asterisk CLI.

    Buen aporte y Gracias porque ahora he salido de dudas respecto a este tema!!

  • Gercahuich

    HOla, yo tengo un problema similar, recibo la e1 atravez de un Astribank, tengo 10 canales contratados, solo puedo hacer uso de 5 canales, cuando se activa una 6 llamada me deconecta una llamada activa, mi servicio esta con corte en las llamdas, sin que el watson se alarme fisicamente el led.

    aqui esta el Log, a ver si alguien me puede ayudar para buscar una solucion a mi probelma de corte de llamadas y bloqueo de canales.

    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Detected alarm on channel 8: Red Alarm
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 8.
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Detected alarm on channel 9: Red Alarm
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 9.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 1
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 1.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 2
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 2.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 3
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 3.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 4
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 4.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 5
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 5.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 6
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 6.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 7
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 7.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 8
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 8.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 9
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 9.
    [Jul 10 16:29:14] NOTICE[2804] chan_dahdi.c: Alarm cleared on channel 10
    [Jul 10 16:29:14] WARNING[2804] chan_dahdi.c: Zap alarm on chan 10.
    [Jul 10 16:29:17] DEBUG[18752] chan_dahdi.c: Winkflash, index: 0, normal: 12, callwait: -1, thirdcall: -1
    [Jul 10 16:29:20] DEBUG[18752] chan_dahdi.c: waitfordigit returned < 0…
    [Jul 10 16:29:24] DEBUG[2805] chan_dahdi.c: Message status for 1109@device changed from -1 to 0 on 36
    [Jul 10 16:29:37] DEBUG[18756] chan_dahdi.c: no MFC/R2 category specified for chan DAHDI/1-1, using default National Priority Subscriber
    [Jul 10 16:29:37] NOTICE[2804] chan_dahdi.c: Far end blocked on chan 6
    [Jul 10 16:29:37] DEBUG[18756] chan_dahdi.c: bits changed in chan 1
    [Jul 10 16:29:39] DEBUG[18757] chan_dahdi.c: Detected digit '9'
    [Jul 10 16:29:39] DEBUG[18757] chan_dahdi.c: Detected digit '0'
    [Jul 10 16:29:40] DEBUG[18757] chan_dahdi.c: Detected digit '1'
    [Jul 10 16:29:40] DEBUG[18757] chan_dahdi.c: Detected digit '5'
    [Jul 10 16:29:40] DEBUG[18757] chan_dahdi.c: Detected digit '5'
    [Jul 10 16:29:40] DEBUG[18757] chan_dahdi.c: Detected digit '5'
    [Jul 10 16:29:41] DEBUG[18757] chan_dahdi.c: Detected digit '7'
    [Jul 10 16:29:41] DEBUG[18757] chan_dahdi.c: Detected digit '5'
    [Jul 10 16:29:41] DEBUG[18757] chan_dahdi.c: Detected digit '2'
    [Jul 10 16:29:41] DEBUG[18757] chan_dahdi.c: Detected digit '8'
    [Jul 10 16:29:41] DEBUG[18757] chan_dahdi.c: Detected digit '7'
    [Jul 10 16:29:42] DEBUG[18757] chan_dahdi.c: Detected digit '8'
    [Jul 10 16:29:42] DEBUG[18757] chan_dahdi.c: Detected digit '0'
    [Jul 10 16:29:45] DEBUG[18757] chan_dahdi.c: no MFC/R2 category specified for chan DAHDI/2-1, using default National Priority Subscriber
    [Jul 10 16:29:45] NOTICE[2804] chan_dahdi.c: Far end blocked on chan 7
    [Jul 10 16:29:45] DEBUG[18757] chan_dahdi.c: bits changed in chan 2
    [Jul 10 16:29:45] DEBUG[18756] chan_dahdi.c: bits changed in chan 1
    [Jul 10 16:29:45] DEBUG[18756] chan_dahdi.c: Requested indication 20 on ch

  • Luis

    Hola, Necesito crear un reporte para comprobar si el equipo está recibiendo o no la causa de terminación de llamada. Mi pregunta es: ¿En qué LOG puedo visualizar este detalle?

    • En el /var/log/asterisk/full es donde más probabilidades tendrías de encontrarlo.