Monitoramento de circuitos de voz: troncos SIP, 0800 e URA
Um tronco SIP registrado e um PABX sem alarmes não provam que uma chamada completa com áudio. Este guia compara as formas de monitorar um circuito de voz, mostra como confirmar uma queda sem alarme falso e diz que evidência guardar para cobrar a operadora.
Resumo
- Ping e SIP OPTIONS mostram que um equipamento responde; só uma chamada de teste real mostra que a chamada de um cliente completa, com áudio nos dois sentidos.
- A captura passiva no PABX só vê as chamadas que chegam até ele: quando a falha está antes, na operadora ou na rota do 0800, ela não registra nada.
- No ritmo padrão do Monitor, cada circuito recebe uma chamada de teste a cada 15 minutos; depois de uma falha, três novas tentativas a cada 2 minutos, e quatro falhas seguidas abrem um incidente.
- Duas chamadas boas seguidas confirmam a volta do circuito; uma falha isolada nunca vira incidente.
- Quando a falha é do próprio monitoramento, o teste fica sem visibilidade: não conta contra o circuito e não entra no SLA.
- A evidência de cada falha é o código SIP, a causa Q.850, o Call-ID e o horário exato de cada chamada de teste.
O que é monitoramento de circuitos de voz?
Monitoramento de circuitos de voz é a verificação contínua de que cada tronco SIP, número 0800, DDR de filial e URA completa chamadas com áudio nos dois sentidos e com a mensagem certa. Um circuito de voz, aqui, é qualquer número ou rota por onde um cliente chega até a sua empresa por telefone.
A definição importa porque muda o que se mede. A maior parte das ferramentas de um ambiente de telefonia olha para os equipamentos: se o SBC está ligado, se o tronco está registrado, se o processador do PABX está folgado. Essas perguntas são necessárias, mas respondem a outra coisa. Um equipamento pode estar perfeito enquanto a chamada de um cliente não chega até ele.
Este guia trata da pergunta que o cliente faz: se eu ligar agora, alguém atende? Os guias sobre 0800 e URA, ligação muda, qualidade de voz e SLA aprofundam cada parte.
Por que o painel fica verde enquanto o cliente ouve silêncio?
O painel fica verde porque mede o equipamento, e não a chamada. O PABX está ligado, o tronco SIP aparece registrado e o link responde, enquanto a falha está na rota da operadora, na tradução do 0800 ou no caminho do áudio. Nenhum desses pontos manda alarme para o painel da sua equipe.
Três situações comuns mostram o problema:
- A chamada nunca chega. A operadora deixou de rotear o seu 0800 ou um DDR até o seu tronco. O PABX não recebe nada, então não tem o que reclamar.
- A chamada chega, mas o áudio não. A sinalização SIP passa e a chamada é atendida, mas o RTP, que leva a voz, para em um NAT, num firewall ou num SIP ALG. O resultado é a ligação muda ou o áudio de um lado só, e o PABX registra uma chamada completada.
- A mensagem errada atende. A URA foi trocada, a gravação de feriado ficou ligada ou a operadora toca a mensagem de número inexistente. Para a sinalização, tudo funcionou.
Há um agravante: de madrugada e no fim de semana, poucas chamadas é o normal. O cliente que liga às 2h e ouve silêncio desiste, e a falha só aparece quando o atendimento abre e as filas estão estranhamente vazias.
Ping, SIP OPTIONS, captura passiva ou chamada de teste: o que cada um vê?
Cada método de monitoramento de um tronco SIP responde a uma pergunta diferente. O ping diz se um endereço responde; o SIP OPTIONS e o registro, se a pilha SIP responde; a captura passiva, como foram as chamadas que chegaram. Só a chamada de teste real diz se a chamada de um cliente completa agora, com áudio.
| Método | O que vê | O que não vê | Para que serve |
|---|---|---|---|
| Ping | Que o endereço do SBC ou do PABX responde na rede | O serviço SIP, a rota da operadora, o áudio, a mensagem; muitos SBCs nem respondem a ping | Saber se o equipamento sumiu da rede |
| SIP OPTIONS e registro (keep-alive) | Que a pilha SIP do outro lado responde e que o registro do tronco está válido | Se um INVITE para o seu número é roteado até você, se o áudio passa, quem atende | Manter o tronco e o NAT ativos e notar a perda do registro |
| Monitoramento passivo (captura de pacotes, estatísticas RTCP no PABX) | Códigos SIP, perda e jitter das chamadas reais que chegaram ao PABX | As chamadas que nunca chegaram; nada, quando não há tráfego | Diagnosticar qualidade e investigar uma chamada específica |
| Chamada de teste real | Se a chamada completa, o código SIP e a causa Q.850, quem atendeu, o áudio nos dois sentidos e a qualidade medida | Origens e números que ela não disca; o que acontece entre dois testes | Saber se o cliente consegue falar com você, a qualquer hora |
Os métodos se completam: a chamada de teste diz se está funcionando; os outros ajudam a descobrir por que não está.
Ping
O ping é o teste mais barato e o mais limitado. Ele confirma que um endereço IP responde, o que ajuda a saber se um SBC ou um link sumiu. Mas um equipamento que responde ao ping pode estar com o serviço SIP parado, e muitos SBCs descartam o ping de propósito, por segurança.
SIP OPTIONS e registro
O método OPTIONS, definido no RFC 3261, pergunta a um elemento SIP o que ele suporta. Na prática, SBCs e operadoras enviam OPTIONS em intervalos para saber se o outro lado está vivo e, junto com outras técnicas descritas no RFC 6314, para manter abertos os mapeamentos de NAT. O REGISTER, também do RFC 3261, é como o tronco diz à operadora para onde entregar as chamadas. Veja registro SIP.
Um tronco registrado e respondendo a OPTIONS prova que a sinalização entre os dois equipamentos funciona. Não prova três coisas: que a operadora roteia um número específico até esse tronco (a tradução de um 0800 acontece em outro lugar da rede dela); que o áudio passa, já que o RTP viaja em outras portas e pode ser barrado enquanto o OPTIONS passa; e que quem atende é a URA certa.
Monitoramento passivo no PABX
A captura de pacotes no PABX ou no SBC registra a sinalização e o áudio das chamadas reais. Os relatórios RTCP do RFC 3550 trazem a perda de pacotes e o jitter de cada sentido, e muitos equipamentos calculam a partir deles uma nota MOS estimada pelo modelo E da ITU-T G.107, que a ITU-T P.800.1 chama de MOS-CQE. É a ferramenta certa para investigar por que uma chamada específica soou mal.
O limite é estrutural: o monitoramento passivo só vê o que chega. Se a operadora parou de entregar as chamadas do 0800, não há pacote para capturar, e de madrugada, sem tráfego, não há dado nenhum. Uma queda no volume de chamadas não serve de sinal às 3h de domingo, quando zero chamadas é o esperado.
Chamada de teste real
A chamada de teste disca o número de fora, como um cliente faz, e julga o resultado. Ela atravessa a operadora, a tradução do 0800, o tronco, o SBC, o PABX e a URA, e por isso vê o que o cliente veria. É o único método que funciona igual às 3h e às 15h, porque não depende de alguém ligar.
Ela também tem limites. Testa a partir da sua origem e só os números que disca; uma falha que afeta apenas chamadas vindas de celular, por exemplo, pode não aparecer (veja por que o 0800 não completa do celular). Não vê o que acontece entre um teste e o próximo. E ocupa um canal por alguns segundos, como uma chamada de cliente.
O que uma chamada de teste precisa verificar?
Uma chamada de teste precisa verificar quatro coisas, em ordem: se a chamada completou, se atendeu quem deveria atender, se o áudio passou nos dois sentidos e se a voz chegou com qualidade. Um teste que confere só a primeira deixa passar o 0800 mudo, a URA trocada e a mensagem da operadora.
A chamada completou?
A resposta da rota a um INVITE diz o que aconteceu. As respostas 1xx indicam andamento, 200 OK indica atendimento, e as respostas 4xx, 5xx e 6xx indicam falha. As que um teste mais encontra:
| Resposta SIP | O que costuma significar | Para o monitoramento |
|---|---|---|
| 180 Ringing | O destino está tocando | Andamento, ainda não é atendimento |
| 183 Session Progress | Andamento com áudio antes do atendimento, o early media (RFC 3960) | Pode ser o toque ou uma mensagem da operadora; não é atendimento |
| 403 Forbidden | A rota recusou a chamada | Falha |
| 404 Not Found | O número não existe para essa rota | Falha |
| 408 Request Timeout | Nenhuma resposta final a tempo | Falha |
| 480 Temporarily Unavailable | O destino está indisponível no momento | Falha |
| 486 Busy Here | Ocupado | Falha para uma URA, que deveria atender toda chamada |
| 487 Request Terminated | A chamada foi cancelada antes do atendimento | Quando o teste desistiu de esperar, é falha de atendimento |
| 488 Not Acceptable Here | A oferta de mídia, como os codecs, não foi aceita (RFC 3264) | Falha |
| 503 Service Unavailable | O serviço do outro lado não está disponível | Falha |
| 603 Decline | O destino recusou a chamada | Falha |
Junto com o código SIP, muitas rotas enviam a causa Q.850 da rede de telefonia no cabeçalho Reason, como descreve o RFC 6432. A lista de códigos SIP, a lista de causas Q.850 e a consulta de código SIP explicam cada uma.
Atendeu quem deveria atender?
“Atendeu” não basta. Um 0800 pode completar e tocar a gravação da operadora dizendo que o número não existe; uma URA pode ser trocada sem aviso. Por isso cada circuito precisa de uma definição do que deve atender, e o teste precisa conferir.
No Monitor, essa escolha é feita na implantação e decide o que conta como funcionando:
- Uma saudação ou mensagem gravada, a URA: passa quando a chamada é atendida e a saudação esperada é ouvida. A 2N5 grava a saudação de referência de cada número, e cada chamada compara o que ouviu com ela. A mensagem de erro de uma operadora não passa.
- Um tom de teste ou serviço de eco: passa quando a chamada é atendida e os tons enviados voltam.
- Outro: pode tocar até o fim ou ser atendido com áudio, conforme o combinado. Se uma pessoa atender, ela ouve uma mensagem avisando que é um teste automático.
Para uma URA, ocupado, sem atendimento ou tocar até o fim é falha: ela atende toda chamada sozinha.
O áudio passou nos dois sentidos?
Uma chamada pode ser atendida e ficar muda, ou levar a voz para um lado só. A sinalização SIP e o áudio seguem caminhos diferentes: o SIP combina os endereços e as portas, e o RTP leva a voz. Um NAT que reescreve só um dos dois, um SIP ALG que altera a mensagem ou um firewall que barra as portas de mídia produzem a ligação muda, enquanto o PABX registra uma chamada completada. Num circuito com tom de teste ou eco, o teste confere que os tons enviados voltam. O guia ligação muda e áudio de um lado só detalha as causas.
A voz chegou com qualidade?
Uma chamada pode completar e soar picotada. O Monitor mede a qualidade de escuta a partir do áudio que a chamada recebeu, comparado com a gravação de referência, com o modelo ViSQOL no modo de fala, e dá uma nota de 1 a 5: o MOS-LQO, na terminologia da ITU-T P.800.1. É diferente do MOS-CQE que um PABX estima com números da rede pelo modelo E da G.107: um mede o que chegou, o outro calcula o que deveria ter chegado.
Por padrão, o circuito está saudável com MOS-LQO a partir de 3,8, e uma nota abaixo de 3,0 marca a chamada como degradada. Uma chamada degradada passa pelas mesmas novas tentativas de qualquer falha. Veja qualidade de voz medida e o guia MOS-LQO e ViSQOL.
Como confirmar uma queda sem alarme falso?
Uma queda de circuito de voz se confirma repetindo a chamada antes de avisar alguém. Uma falha isolada pode ser uma rota que oscilou uma vez; quatro falhas seguidas, com poucos minutos entre elas, são uma queda. A mesma lógica vale para a volta: uma chamada boa não basta, duas seguidas confirmam.
No ritmo padrão do Monitor, cada circuito recebe uma chamada de teste a cada 15 minutos. Quando uma falha, a chamada é repetida três vezes, a cada 2 minutos; quatro falhas seguidas abrem um incidente, e duas chamadas boas seguidas confirmam a volta. Em forma de linha do tempo, com T sendo o horário do teste que falhou primeiro:
| Momento | Chamada | Resultado | O que acontece |
|---|---|---|---|
| T − 15 min | Teste agendado | Completa, a URA atende | Circuito saudável |
| T | Teste agendado | SIP 503 | Primeira falha; nova tentativa em 2 minutos; ninguém é avisado |
| T + 2 min | Nova tentativa | SIP 503 | Segunda falha seguida; nova tentativa em 2 minutos |
| T + 4 min | Nova tentativa | SIP 503 | Terceira falha seguida; nova tentativa em 2 minutos |
| T + 6 min | Nova tentativa | SIP 503 | Quarta falha seguida: incidente aberto, com as evidências; a camada 1 é avisada por e-mail e SMS |
| Depois | Chamadas seguintes | Falham | O incidente segue aberto; se ninguém confirmar a tempo, o alerta sobe para a camada seguinte |
| Na volta | Chamada | Completa, a URA atende | Primeira chamada boa; o incidente ainda não fecha |
| Logo depois | Chamada seguinte | Completa, a URA atende | Segunda boa seguida: volta confirmada, incidente fechado, contatos avisados |
Se a chamada de T + 2 min completar, a sequência para ali: houve uma falha isolada, ninguém foi acordado e nada entra no SLA. É esse filtro que permite confiar num alerta às 2h.
Quanto tempo leva para uma queda virar alerta?
Depende de quando a queda começa em relação ao teste. No pior caso, ela começa logo depois de um teste bom: leva até 15 minutos para o próximo teste ver a falha e mais 6 minutos para as três novas tentativas confirmarem, ou seja, 15 + 6 = 21 minutos até o incidente. No melhor caso, começa logo antes de um teste e vira incidente em cerca de 6 minutos.
Testar com mais frequência reduz esse tempo, mas cada teste ocupa um canal por alguns segundos. A conta da frequência padrão: 24 horas × 4 testes por hora = 96 chamadas de teste por dia, por circuito, sem contar as novas tentativas.
Por que quatro falhas e duas boas?
Quatro falhas seguidas, em 6 minutos, separam uma oscilação de uma queda sem atrasar demais o alerta. Duas chamadas boas seguidas evitam o vai e volta de um circuito instável, que de outro modo fecharia e reabriria o incidente a cada teste. Esses são os valores padrão do Monitor.
Quando o próprio monitoramento fica cego?
O monitoramento fica cego quando o teste não pode ser feito por um problema do lado de quem testa: o servidor de chamadas sem resposta, a conta de origem fora do ar, a rede do próprio monitoramento caída. Nesse caso o teste não diz nada sobre o circuito de voz, e não pode contar como queda dele.
Contar a cegueira como queda causa três estragos. A equipe é acordada às 2h por um problema que não é dela. O SLA do circuito sai pior do que foi. E a contestação com a operadora enfraquece, porque basta a operadora mostrar que o lado dela estava normal naquela hora para pôr em dúvida as outras quedas registradas. A cegueira também não pode contar como tempo no ar: se ninguém conseguiu testar, ninguém sabe como o circuito estava.
No Monitor, quando a falha está do lado da 2N5, por exemplo o servidor de chamadas da 2N5 sem resposta, o teste fica sem visibilidade:
- não conta contra o circuito e não abre incidente para o cliente;
- não entra no SLA: o período sai da conta e aparece separado no relatório;
- não acorda a equipe do cliente; a 2N5 é avisada se durar mais de 30 minutos;
- um sinal periódico avisa a 2N5 também se o monitoramento parar de rodar.
Quem monta o próprio monitoramento precisa da mesma separação. Uma forma prática é ter um destino de controle, um número que sempre deveria completar, testado da mesma origem. Se o circuito e o controle falham juntos, o problema provavelmente está na origem do teste, e não no circuito.
Que evidência guardar de cada falha?
Para cada chamada de teste que falhou, guarde o código SIP da resposta, a causa Q.850 quando ela vier, o Call-ID, o horário exato com fuso, o número chamado e a origem. Com isso a operadora consegue achar a chamada nos próprios registros, e o “nenhum defeito encontrado” fica difícil de sustentar.
| Evidência | De onde vem | Por que importa |
|---|---|---|
| Código SIP | A linha de status da resposta (RFC 3261), por exemplo 503 | Diz em que ponto e como a chamada foi recusada |
| Causa Q.850 | O cabeçalho Reason, quando a rota envia (RFC 6432), por exemplo Reason: Q.850;cause=34 |
Traz a causa da rede de telefonia por trás do SIP |
| Call-ID | O cabeçalho Call-ID da chamada (RFC 3261) | Identifica a chamada nos registros da operadora |
| Horário | O relógio de quem testou, com segundos e fuso | Cruza com os registros da operadora e marca o início e o fim da queda |
| Número chamado e origem | O próprio teste | Uma falha pode valer só para uma origem ou um número |
| Última chamada saudável | O histórico de testes | Delimita quando a queda começou |
| O que foi ouvido | A gravação da chamada, quando a URA ou a gravação atendeu | Prova a mensagem errada ou a mensagem da operadora |
Guarde o código SIP e a causa Q.850 juntos, chamada por chamada: a mesma resposta 503 pode vir com causas diferentes, e cada uma aponta para um lugar.
No Monitor, cada incidente traz um bloco pronto para colar no chamado da operadora: o circuito, a operadora, o primeiro sintoma, o código SIP e a causa Q.850 de cada chamada, e a última chamada saudável. Exemplo, com dados de demonstração: SIP 503 Service Unavailable, Q.850 causa 34 (nenhum circuito ou canal disponível), confirmado após 4 chamadas com falha. O áudio só é guardado quando quem atende é a gravação ou a URA informada, criptografado e excluído após 90 dias; a voz de uma pessoa nunca é guardada.
O que monitorar: troncos SIP, 0800, DDRs de filial ou URA?
Monitore primeiro o que o cliente disca, depois cada caminho por onde essas chamadas passam. Em geral, isso significa os números de atendimento, como 0800 e 4004, a URA que os atende, um DDR por tronco SIP e por operadora, e um DDR em cada filial. Cada um vira um circuito de voz com agenda própria.
| O que | O que discar | O que deve atender | O que o teste mostra |
|---|---|---|---|
| Número de atendimento (0800, 0300, 4004) | O próprio número, como o cliente disca | A saudação da URA | A rota da operadora, a portabilidade, a plataforma da URA |
| URA telefônica | O número que cai nela | A saudação gravada como referência | A mensagem trocada, a plataforma fora do ar, a qualidade |
| Tronco SIP | Um DDR que entra por esse tronco | Um tom de teste, um eco ou uma saudação | Recusa da operadora, canais lotados, áudio de um lado só |
| DDR de filial | Um número da filial | Tom, eco, saudação, ou um ramal que pode tocar | O tronco, o link e o PABX daquela filial |
| Fila de atendimento | O número da fila | A saudação, ou pode tocar | Se a fila recebe chamadas |
Um tronco, um DDR
Se você tem dois troncos SIP de operadoras diferentes por redundância, teste cada um com um DDR que entra só por ele. Testar apenas o número principal esconde a queda do primeiro tronco enquanto o segundo segura as chamadas, e você só descobre quando os dois caem juntos. A redundância só vale se cada caminho for testado.
Números de atendimento e URA
O número de atendimento é o que mais pesa, porque é o que o cliente conhece. Teste o próprio 0800, e não só o DDR para onde ele é traduzido: a tradução fica na operadora, e é ali que muitas falhas acontecem. O guia Seu 0800 parou e ninguém avisou trata desse caso em detalhe, e a página monitoramento de 0800 e URA mostra como o Monitor julga cada número. Para as filiais, um DDR por filial, com um ramal ou um tom de teste atrás, cobre o tronco, o link e o PABX de cada uma; veja monitoramento de troncos SIP.
Com que frequência testar um circuito de voz?
A frequência do teste define a resolução do SLA de um circuito de voz. Com uma chamada a cada 15 minutos e novas tentativas a cada 2 minutos depois de uma falha, o início e o fim de cada queda ficam marcados com poucos minutos de margem. Testar de hora em hora pode deixar passar quedas inteiras de 40 minutos.
A conta parte da meta. Uma meta de 99,9% num mês de 30 dias permite 43.200 minutos × 0,001 = 43,2 minutos fora do ar. Se o teste acontece a cada 60 minutos, uma queda de 40 minutos pode começar e terminar entre dois testes e nunca entrar no relatório: o SLA sai melhor do que foi. Para a meta valer alguma coisa, o intervalo entre testes precisa ser bem menor do que o tempo que ela permite. A calculadora de SLA faz a conta para qualquer meta e período.
Duas outras decisões pesam tanto quanto o intervalo:
- Os horários sem ninguém olhando. Um 0800 de atendimento 24 horas precisa de teste de madrugada e no fim de semana, porque é quando ninguém da equipe vai perceber sozinho. No Monitor, cada número tem a sua agenda, em intervalos ou em horários fixos, inclusive à noite e nos fins de semana.
- O limite de chamadas. Cada teste ocupa um canal por alguns segundos. Com muitos circuitos atrás do mesmo tronco, o teste precisa caber num limite de chamadas para nunca disputar canal com os clientes.
E o link de internet por onde a voz passa?
O link de internet é o circuito de dados por onde a voz quase sempre passa, e uma queda nele derruba todos os circuitos de voz do local de uma vez. Medir o link ao lado das chamadas de teste responde à primeira pergunta de toda queda de voz: foi a linha ou foi a conexão?
No Monitor, um agente que a 2N5 instala no local mede latência, perda de pacotes, jitter, tempo de DNS e velocidade. Cada circuito de voz pode ser ligado ao link do seu local; com a opção de esperar pelo link, a equipe recebe um alerta sobre o link, e não um por circuito de voz que passa por ele. Veja circuitos de dados.
Quem deve ser avisado quando um circuito de voz cai?
Quando um circuito de voz cai de verdade, quem precisa saber é quem consegue agir naquela hora, e não uma caixa de e-mail que ninguém abre de madrugada. Uma escada com camadas, que sobe até alguém assumir, garante que o alerta de um incidente confirmado não fique sem resposta.
No Monitor, o incidente avisa a camada 1 por e-mail e SMS. Se ninguém confirmar no tempo definido, o alerta sobe para a camada seguinte; uma única confirmação, um toque no link do SMS, para a subida e registra quem assumiu. Se nenhuma camada confirmar, os administradores da empresa são avisados. Os contatos do cliente recebem o aviso do problema e o da solução, fora da escada. Janelas de manutenção silenciam os circuitos escolhidos durante o horário marcado. Veja alertas e escalonamento.
O tempo até a primeira confirmação entra nos relatórios de SLA ao lado da disponibilidade. Medir a chamada, confirmar a queda, separar a cegueira, guardar a evidência e avisar a pessoa certa: é isso que transforma um monitoramento em resposta.
Perguntas frequentes
Ping ou SIP OPTIONS bastam para monitorar um tronco SIP?
Não. O ping diz que o endereço do SBC ou do PABX responde na rede, e o SIP OPTIONS diz que a pilha SIP do outro lado responde. Nenhum dos dois faz uma chamada: não mostram se a operadora roteia o seu número até você, se o áudio passa nos dois sentidos ou se a URA certa atende. Para isso é preciso uma chamada de teste real.
De quanto em quanto tempo testar um circuito de voz?
Num intervalo bem menor do que o tempo fora do ar que a meta permite. Uma meta de 99,9% num mês de 30 dias tolera 43 minutos; testar de hora em hora pode deixar passar uma queda inteira. No ritmo padrão do Monitor, a chamada de teste acontece a cada 15 minutos, com novas tentativas a cada 2 minutos depois de uma falha.
Por que não alertar já na primeira chamada que falha?
Porque uma falha isolada pode ser uma rota que oscilou uma vez, e um alerta falso às 2h ensina a equipe a ignorar os próximos. Repetir a chamada separa a oscilação da queda: no Monitor, quatro falhas seguidas, por padrão (a primeira e três novas tentativas), abrem um incidente, e só um incidente confirmado avisa alguém por e-mail e SMS.
O que é um teste sem visibilidade?
É um teste que não pôde ser feito por um problema do lado de quem testa, por exemplo o servidor de chamadas do monitoramento sem resposta. Ele não diz nada sobre o circuito. No Monitor, esse período não conta contra o circuito, não entra no SLA e não acorda a equipe do cliente; quem é avisada é a 2N5.
O que mandar para a operadora quando um tronco SIP cai?
O número chamado, a origem, o horário de cada chamada com segundos e fuso, o código SIP da resposta, a causa Q.850 quando ela veio e o Call-ID. Com esses dados a operadora encontra cada chamada nos próprios registros. Inclua também a última chamada que funcionou, para marcar quando a queda começou.