Descobrir o que aconteceu com esta chamada
Você tem um número e talvez um horário. Precisa saber onde a chamada caiu e de quem foi a culpa. Essa é, de longe, a pergunta mais comum que fazem ao Butler.
Primeiro alguém reclamou. Quase sempre começa assim, seja um usuário final, um revendedor ou um colega em outro canal, e o que chega até você é um único identificador: um número discado, às vezes um horário, às vezes nada além de “agora há pouco”.
Responder hoje significa abrir uma ferramenta de trace, saber qual Controlador de Borda de Sessão (SBC) analisar, encontrar a chamada, ler um diagrama SIP e saber o que um 480 significa naquele contexto. O Butler reduz tudo isso a uma frase digitada na janela de chat que você já tem aberta.
Escolha uma pergunta e leia a conversa completa
Todas estas conversas vêm de uma mesma tarde, sem edição, com os identificadores mascarados. Leia a segunda para ver o que o Butler faz quando não tem os dados que você pediu.
- A chamada foi atendida às 10:16:10 UTC
- Duração de 87 segundos, com áudio conectado nos dois sentidos
- Desconexão normal por quem ligou, e os dois trechos indicam release_source ConnectedLeg, então o lado da operadora estava ativo e conectado quando a chamada terminou
Uma operadora negava ter recebido uma chamada e citava um Call-ID para provar. O Butler encontrou a chamada e depois notou o detalhe que encerra a discussão: o Call-ID citado pertence ao salto entre dois dos nossos próprios SBCs, então a operadora não poderia tê-lo visto. Ele devolveu o Call-ID que ela deveria procurar e confirmou que a chamada foi atendida e durou 87 segundos. Isso seriam vinte minutos em uma captura de pacotes, e o resultado é uma frase que você pode mandar direto para a operadora.
- O release_source de cada trecho de saída é LocalLeg, com sip_final_response 503
- O original_cause é 503_SERVICE_UNAVAIL(503)
- O seu SBC enviou o INVITE e a operadora devolveu 503 Service Unavailable
A primeira mensagem é a que vale a pena ler. Quando perguntaram sobre “uma chamada que falhou com um 503 hoje de manhã”, o Butler não escolheu uma chamada qualquer torcendo para acertar. Pediu um número, um horário aproximado e um SBC, e depois a encontrou com um filtro no servidor pelo código de resposta, em vez de percorrer linhas. A resposta cita as evidências usadas antes de chegar à conclusão, e é isso que permite encaminhar a última linha como está.
- O 180 Ringing foi enviado pela central de terminação, não pelo aparelho do usuário final
- O toque que aparece no diagrama é apenas sinalização: a outra ponta indicava que estava tentando alertar o destino
- O 486 voltou 20 ms depois, então o aparelho quase certamente não teve tempo de tocar fisicamente
As duas partes estavam certas, e é por isso que a discussão não chegava a lugar nenhum. A rede tentou entregar a chamada e o telefone não tocou: vinte milissegundos explicam tudo. Repare que o Butler não escolheu um lado para defender. Ele leu o que a sinalização realmente dizia, e ela se mostrou mais precisa do que qualquer uma das partes.
Um número que não diz nada, dividido em dois que dizem alguma coisa. De quase três segundos para conectar, 295 milissegundos foram atraso pós-discagem, ou seja, o roteamento e o processamento do próprio destino, e os outros 2,9 segundos foram a pessoa chamada sem atender. O primeiro é uma questão de plataforma e o segundo não, e confundir os dois é como se perde uma tarde investigando o sistema errado.
A objeção de sempre a colocar um assistente na frente de um suporte é que ele vai afogar a equipe em detalhes. Este é o contraexemplo. Por trás dessa resposta, o Butler percorreu uma cadeia de três saltos e seis trechos e depois descartou quase tudo: nada de códigos de resposta, nada de nomes de NAP, nada de topologia. Três frases simples que a pessoa que abriu o chamado consegue de fato ler.
O engenheiro disse que as chamadas falharam. As evidências diziam que não, e o Butler disse isso, com o diagrama como prova. Repare também que ninguém precisou repetir nada: na terceira mensagem a pergunta é só “na chamada 1”, e o Butler ainda tem as duas chamadas em mente. Uma resposta confiável é aquela que está disposta a discordar de você.
Os pedidos e aonde cada um leva
Copie um e troque os números pelos seus. As perguntas seguintes importam mais do que a primeira.
Alguém reclamou e você só tem o número. Sem horário, sem direção, sem SBC.
A chamada, a causa da desconexão e qual trecho a provocou.
Você está prestes a abrir um chamado com uma operadora upstream e precisa que ele seja incontestável.
O NAP de entrada, o NAP de saída, a origem da liberação e a causa da desconexão, que transformam “a chamada falhou” em “ela saiu por este tronco e aquela operadora recusou”.
O código de status não é a resposta. Você quer o texto exato do cabeçalho de motivo.
A frase de motivo, mais qualquer cabeçalho Reason ou Warning que a acompanhe, que é a parte que um painel não consegue mostrar.
Uma reclamação de áudio, e a oferta SDP lista cinco codecs que não dizem nada.
O codec negociado em cada trecho, lido nos registros dos trechos e não na oferta.
Como ler o que volta
O que aconteceu com esta chamada?
Um número e, talvez, um horário. O Butler encontra a chamada e diz de que lado ela foi encerrada.
Contagens, agrupamentos, limites e KPIs sobre um conjunto de chamadas.
Tabelas de roteamento, regex e perfis SDP em linguagem simples.
Pergunte em francês, espanhol ou português e receba a resposta com base na documentação em inglês.
Mudanças, relatórios, arquivos e e-mails, cada um esperando o seu sim.
Cole a reclamação nas palavras do cliente e deixe o Butler encontrar a chamada.
Pergunte ao Butler sobre a sua própria chamada com falha
Implantado em 48 horas, com contrato mensal, no aplicativo de chat que sua equipe já tem aberto.
Ao enviar este formulário, suas informações serão processadas de acordo com nossa Política de Privacidade.