Averiguar qué pasó con esta llamada
Tiene un número y quizás una hora. Necesita saber dónde murió la llamada y de quién fue la culpa. Es, por lejos, lo que más le preguntan a Butler.
Primero alguien se quejó. Casi siempre empieza así, ya sea un usuario final, un revendedor o un colega en otro canal, y lo que le llega es un único identificador: un número marcado, a veces una hora, en ocasiones nada más que “hace un momento”.
Responder hoy implica abrir una herramienta de trazas, saber qué controlador de borde de sesión (SBC) revisar, encontrar la llamada, leer un diagrama SIP y saber qué significa un 480 en ese contexto. Butler reduce todo eso a una frase escrita en la ventana de chat que ya tiene abierta.
Elija una pregunta y lea el intercambio completo
Todos estos intercambios salen de una misma tarde, sin editar, con los identificadores ocultos. Lea el segundo para ver qué hace Butler cuando no tiene los datos que le pidió.
- La llamada fue contestada a las 10:16:10 UTC
- Duración de 87 segundos, con audio conectado en ambos sentidos
- Liberación normal por parte de quien llamó, y ambos tramos indican release_source ConnectedLeg, así que el lado del operador estaba activo y conectado cuando terminó
Un operador negaba haber recibido una llamada y citaba un Call-ID para probarlo. Butler encontró la llamada y luego notó el detalle que zanja la discusión: el Call-ID citado pertenece al salto entre dos de nuestros propios SBC, así que el operador no podía haberlo visto. Devolvió el que deberían buscar y confirmó que la llamada fue contestada y duró 87 segundos. Eso son veinte minutos en una captura de paquetes, y el resultado es una frase que puede enviar directamente al operador.
- El release_source de cada tramo de salida es LocalLeg, con sip_final_response 503
- El original_cause es 503_SERVICE_UNAVAIL(503)
- Su SBC envió el INVITE y el operador devolvió 503 Service Unavailable
El primer mensaje es el que vale la pena leer. Cuando le preguntaron por “una llamada que falló con un 503 esta mañana”, Butler no eligió una llamada al azar con la esperanza de acertar. Pidió un número, una hora aproximada y un SBC, y luego la encontró con un filtro del lado del servidor sobre el código de respuesta, en lugar de recorrer filas. La respuesta nombra la evidencia que usó antes de sacar la conclusión, y eso es lo que permite reenviar la última línea tal cual.
- El 180 Ringing lo envió el conmutador de terminación, no el dispositivo del usuario final
- El timbre que aparece en el diagrama es solo señalización: el extremo remoto indicaba que estaba intentando alertar al destino
- El 486 llegó 20 ms después, así que es casi seguro que el teléfono no tuvo tiempo de sonar físicamente
Las dos partes tenían razón, y por eso la discusión no iba a ninguna parte. La red sí intentó entregar la llamada y el teléfono no sonó: veinte milisegundos son toda la explicación. Observe que Butler no eligió un bando para defenderlo. Leyó lo que realmente decía la señalización, que resultó ser más precisa que cualquiera de las dos partes.
Una cifra que no dice nada, dividida en dos que sí dicen algo. De casi tres segundos de conexión, 295 milisegundos fueron retardo posmarcación, es decir, el enrutamiento y el procesamiento propio del destino, y los otros 2.9 segundos fueron el destinatario sin atender. Lo primero es un tema de plataforma y lo segundo no, y confundirlos es la forma de pasar una tarde resolviendo problemas en el sistema equivocado.
La objeción habitual a poner un asistente frente a una mesa de soporte es que va a enterrar al equipo en detalles. Este es el contraejemplo. Detrás de esa respuesta, Butler recorrió una cadena de tres saltos y seis tramos, y luego descartó casi todo: sin códigos de respuesta, sin nombres de NAP, sin topología. Tres frases simples que la persona que abrió el ticket realmente puede leer.
El ingeniero dijo que las llamadas fallaron. La evidencia decía que no, y Butler lo dijo, con el diagrama como prueba. Observe también que nadie repitió nada: para el tercer mensaje la pregunta es solo “en la llamada 1”, y Butler todavía tiene ambas llamadas presentes. Una respuesta digna de confianza es una que está dispuesta a llevarle la contraria.
Las consultas y a dónde lleva cada una
Copie una y reemplace los números por los suyos. Las preguntas de seguimiento importan más que la primera.
Alguien se quejó y lo único que tiene es el número. Sin hora, sin dirección, sin SBC.
La llamada, la causa de desconexión y qué tramo la generó.
Está por abrir un ticket con un operador aguas arriba y necesita que sea indiscutible.
El NAP de entrada, el NAP de salida, el origen de la liberación y la causa de desconexión, que convierten “la llamada falló” en “salió por esta troncal y ese operador la rechazó”.
El código de estado no es la respuesta. Quiere el texto exacto del encabezado de motivo.
La frase de motivo, más cualquier encabezado Reason o Warning que la acompañe, que es la parte que un panel no le puede mostrar.
Una queja de audio, y la oferta SDP lista cinco códecs que no le dicen nada.
El códec negociado en cada tramo, leído de los registros de los tramos y no de la oferta.
Cómo leer lo que recibe
¿Qué pasó con esta llamada?
Un número y, quizás, una hora. Butler encuentra la llamada e indica de qué lado se terminó.
Conteos, agrupaciones, umbrales y KPI sobre un conjunto de llamadas.
Tablas de enrutamiento, expresiones regulares y perfiles SDP en lenguaje sencillo.
Pregunte en francés, español o portugués y obtenga la respuesta a partir de la documentación en inglés.
Cambios, informes, archivos y correos, cada uno a la espera de su confirmación.
Pegue la queja con las palabras del cliente y deje que Butler encuentre la llamada.
Pregúntele a Butler por su propia llamada fallida
Implementado en 48 horas, mes a mes, en la aplicación de chat que su equipo ya tiene abierta.
Al enviar este formulario, su información será procesada de acuerdo con nuestra Política de privacidad.