PSTN Usage não encontra a rota correta no Direct Routing: diagnóstico imediato
PSTN Usage Direct Routing falha quando a Voice Routing Policy não associa o número discado a um uso de PSTN válido, forçando o Teams a rejeitar a chamada ou escolher uma rota incorreta. Engenheiros de voz e administradores do Teams percebem esse sintoma quando a sinalização retorna códigos como 404, 480 ou 500, ou quando rotas incorretas são selecionadas sem causa evidente. Para gestores e equipes responsáveis por avaliar SIP e políticas de roteamento, o desafio é implementar SIP e políticas de roteamento com segurança e previsibilidade, evitando mudanças que corrijam um tronco e quebrem outro. O diagnóstico deve seguir critérios práticos: aderência ao problema real, complexidade de implantação, risco operacional, tempo até valor e integração com o processo atual.
O primeiro passo é validar a cadeia completa de roteamento, não apenas o tronco SIP. A causa mais comum é a ausência do PSTN Usage correto na Voice Routing Policy aplicada ao usuário. A rota existe, mas nunca é consultada. Em seguida, revise a ordem das rotas: o Teams avalia a sequência definida e usa a primeira correspondência, então uma rota genérica antes de uma específica captura chamadas indevidas. A normalização do número também altera a decisão; se o dial plan converte para E.164 antes da consulta, padrões locais falham. Erros como 404 indicam destino não reconhecido, 480 indisponibilidade temporária e 500 falha interna no SBC ou provedor.
Como próximos passos, confirme o vínculo do uso de PSTN à política, valide o padrão da rota e consulte os logs do SBC para identificar o tronco tentado. Esse fluxo reduz riscos e evita alterações desnecessárias na infraestrutura. Para referência técnica oficial, consulte a documentação de roteamento de voz do Direct Routing.
Para aprofundar o diagnóstico e entender como o roteamento por habilidades pode impactar a experiência do usuário final, consulte nosso guia sobre Roteamento por habilidades: como conectar cada cliente ao atendente certo. Além disso, se o problema persistir com áudio ou latência, avalie se a VPN prejudica a telefonia do Teams? Como testar — esse fator pode mascarar falhas de rota.
O que é PSTN Usage no Direct Routing e por que ele define a rota?
| Cenário | Causa provável | Teste | Ação recomendada |
|---|---|---|---|
| Chamada cai no voicemail errado | Padrão de número na rota captura o destino antes da regra específica. | Verifique a ordem das rotas no PSTN Usage e teste com o número completo no Teams. | Reordene as rotas no uso de voz, colocando padrões mais específicos antes dos genéricos. |
| Chamada retorna 404 | Número discado não corresponde a nenhum padrão de rota associado ao uso. | Use o Get-CsOnlinePstnUsage para listar usos e compare com a política aplicada. | Adicione o padrão de número ausente à rota e associe ao PSTN Usage correto. |
| Chamada não sai do Teams | Voice Routing Policy sem o uso de voz necessário ou SBC offline. | Teste com Get-CsOnlineVoiceRoute e verifique o status do SBC no portal. | Associe o uso de voz à política e confirme a conectividade do SBC com o tenant. |
| Chamada vai para o SBC errado | Dois SBCs com padrões sobrepostos e a rota de menor prioridade vence. | Analise o tronco e o FQDN no roteamento; use o Get-CsOnlinePstnUsage para rastrear a rota ativa. | Defina prioridade explícita nas rotas ou separe os padrões de número por SBC. |
PSTN Usage Direct Routing é um contêiner lógico que agrupa rotas de voz e as associa a uma Voice Routing Policy. Ele define quais SBCs e trunks podem ser usados para cada padrão de número discado, e a ordem das rotas dentro dele determina a prioridade de tentativa de chamada.
Para engenheiros de voz, entender o papel do PSTN Usage no roteamento é essencial: ele não executa roteamento sozinho, mas organiza rotas que apontam para SBCs específicos. A Voice Routing Policy decide qual PSTN Usage aplicar a um usuário ou número, e a sequência interna das rotas define qual SBC será tentado primeiro. Se a primeira rota falhar, o sistema tenta a próxima, permitindo failover previsível entre trunks e operadoras.
Essa separação entre PSTN Usage e Voice Routing Policy permite reutilizar o mesmo uso em múltiplas políticas. Um engenheiro pode criar o uso "Nacional-Primario" e aplicá-lo a políticas de diferentes departamentos. Alterações na rota afetam todas as políticas vinculadas, sem edição individual.
Em um cenário com dois SBCs, o PSTN Usage "Saida-Nacional" pode conter duas rotas: a primeira aponta para o SBC-A em São Paulo, a segunda para o SBC-B em Recife como contingência. Usuários vinculados à política tentarão o SBC-A primeiro; se ele não responder, a chamada segue para o SBC-B. Mesmo com um único SBC, o PSTN Usage continua obrigatório, pois toda Voice Routing Policy precisa referenciar pelo menos um uso.
Para validar a configuração, use Get-CsOnlinePstnUsage e Get-CsOnlineVoiceRoutingPolicy no PowerShell do Teams. A documentação oficial da Microsoft sobre Direct Routing e voice routing detalha os parâmetros aceitos em cada rota.
Antes de revisar a política de voz, entenda como a automação de chamadas interage com o Direct Routing. Veja nosso artigo sobre Como Funciona um Discador Automático? e o Discador Automático para Call Center: Guia Completo — ambos dependem de rotas PSTN corretas para funcionar. Em cenários de saúde, a falha de rota pode forçar o paciente a repetir informações; veja Como evitar que o paciente repita as mesmas informações em cada canal.
Se o problema envolver qualidade de áudio ou sintetização de voz, confira nosso diagnóstico sobre Deepgram com voz picotando: o problema está no TTS ou na telefonia?. Para fluxos de confirmação por mensagem, entenda a Preço de mensagem de utilidade no WhatsApp: quando existe cobrança — isso pode influenciar a escolha entre canais. E, ao finalizar processos que dependem de assinatura, veja Como Enviar um Documento para Assinatura Eletrônica.
Por que o PSTN Usage não encontra a rota correta? 5 causas frequentes
Falhas de PSTN Usage Direct Routing geralmente decorrem de inconsistências entre a ordem de avaliação, a normalização do número e a atribuição da política de voz. Para engenheiros de voz, o objetivo prático é identificar por que a rota correta não é selecionada antes de alterar qualquer configuração no SBC. A lista abaixo reúne as causas mais comuns, com sintoma observável e teste imediato.
- Ordem incorreta das rotas no PSTN Usage. O Teams avalia as rotas na sequência definida. Sintoma: chamadas caem em um tronco genérico mesmo existindo rota específica. Teste: reordene as rotas e compare o tronco selecionado no log do SBC.
- Normalização do número chamado alterando o padrão de correspondência. A discagem com DDD local ou código de país pode gerar formatos diferentes. Exemplo: +5511 4000-1234 normalizado como 1140001234 não corresponde a um padrão que espera E.164. Teste: valide o número normalizado antes da seleção de rota.
- Voice Routing Policy não atribuída ao usuário. Sem política associada, o Teams não encontra o PSTN Usage. Sintoma: usuário recebe erro de discagem não autorizada. Teste: confirme a política no perfil do usuário no Teams Admin Center.
- SBC não habilitado para o tronco ou configuração de gateway incorreta. O tronco pode existir, mas o SBC não estar ativo para aquela rota. Sintoma: chamada falha com timeout ou rejeição SIP. Teste: verifique o status do gateway e o FQDN configurado.
- Conflito entre rotas com padrões sobrepostos. Padrões como "11" e "1" competem pela mesma chamada. Sintoma: comportamento inconsistente conforme o número discado. Teste: revise a especificidade dos padrões e remova sobreposições.
Validar normalização, ordem e atribuição antes de alterar o SBC reduz o tempo de diagnóstico.
Como diagnosticar e corrigir o roteamento de chamadas no Direct Routing?
Engenheiros de voz precisam de um método estruturado para diagnosticar e corrigir falhas em PSTN Usage Direct Routing. A cadeia de roteamento envolve política do usuário, ordem das rotas, normalização numérica e logs do SBC. Uma falha em qualquer ponto interrompe a chamada antes de alcançar o gateway correto.
- Confirme a Voice Routing Policy atribuída ao usuário. No PowerShell do Teams, execute Get-CsOnlineUser -Identity [email protected] | Select-Object VoiceRoutingPolicy. Verifique se a política contém ao menos um PSTN Usage associado e se o usuário possui número habilitado para chamadas externas.
- Revise a ordem das rotas dentro do PSTN Usage. Use Get-CsOnlinePstnUsage para listar as rotas vinculadas. O Teams avalia as rotas na sequência configurada; uma rota genérica antes de uma específica pode capturar o número discado e enviá-lo ao SBC errado.
- Teste a normalização do número chamado. Execute Test-CsOnlinePstnRoute -DialedNumber +5511999999999 -User [email protected]. O retorno indica qual rota e qual SBC seriam usados, expondo lacunas de padrão numérico ou tradução incorreta.
- Analise logs do SBC e do Teams. No SBC, procure respostas SIP 404, 500 ou 503 com o Reason header. No Teams, use o relatório de diagnóstico de chamadas para identificar se a falha ocorre na política, na rota ou no gateway.
- Ajuste a configuração e repita o teste. Corrija a ordem das rotas, adicione o padrão numérico ausente ou reatribua a política. Execute novamente o Test-CsOnlinePstnRoute e uma chamada real de validação antes de liberar para produção.
Engenheiros de voz que validam política, ordem de rota e normalização antes de abrir chamado no suporte reduzem o tempo de indisponibilidade do roteamento. A documentação oficial da Microsoft sobre configuração de Direct Routing orienta essa sequência como prática recomendada.
Tabela: cenários de falha, causa provável e ação recomendada
Quando uma chamada falha no Direct Routing, o engenheiro precisa de um guia objetivo para isolar o problema. A tabela abaixo condensa os quatro cenários mais comuns com teste e correção direta.
O erro mais caro ao implementar o uso de voz é tratar a ordem das rotas como irrelevante. A Microsoft avalia as rotas na sequência em que aparecem no PSTN Usage, e a primeira correspondência vence.
Antes de alterar qualquer rota, documente o cenário atual e teste em um usuário piloto. Isso evita que uma correção local derrube chamadas de toda a fila.
Quando escalar para um especialista em Direct Routing?
Engenheiros de voz devem escalar o problema quando o diagnóstico local não elimina a falha de roteamento após validar Voice Routing Policy, PSTN Usage e rotas associadas. Saber quando não conseguir resolver sozinho é tão importante quanto dominar a configuração do tenant: a persistência do erro indica dependência de camadas externas ao Microsoft Teams e, nesse ponto, o custo de tentativa e erro supera o valor de continuar isolado.
Acione um especialista quando a correção exigir mudança em SBC, tronco SIP ou configuração da operadora, pois esses elementos ficam fora do controle direto do administrador do Teams. Alterações no Session Border Controller afetam segurança, codecs e failover. Da mesma forma, ajustes na operadora envolvem contratos, numeração e rotas de emergência que não aparecem no portal do Teams.
Se a causa envolver integração com PABX legado, o diagnóstico interno raramente fecha o ciclo. PABX adiciona planos de discagem, transformações numéricas e sinalização proprietária que mascaram o comportamento esperado no Direct Routing. Planejamento de capacidade e alta disponibilidade também exige visão de tráfego, redundância de SBC e acordos de contingência com a operadora. A documentação oficial da Microsoft lista os controladores de borda certificados para Direct Routing, mas a arquitetura de resiliência depende do desenho de cada operação.
Escalar não significa ausência de método. Significa reconhecer o limite entre configuração de tenant e infraestrutura de voz gerenciada por terceiros. Antes de acionar o especialista, reúna logs de chamada, print da política aplicada e resultado do teste de rota. Esse pacote reduz o tempo de diagnóstico e evita retrabalho entre equipes.
Conclusão: como garantir que o PSTN Usage escolha a rota certa sempre
Garantir roteamento estável exige revisão periódica das políticas de voz, não apenas correção pontual de falhas. A cada alteração de tronco ou número novo, valide a ordem das rotas e a associação de usos PSTN na política.
Equipes que documentam cada mudança de rota e testam chamadas de prova reduzem drasticamente falhas recorrentes de PSTN Usage Direct Routing. A normalização de números deve ser idêntica entre o SBC, o Teams e o provedor de telefonia — divergências de formato são a causa mais comum de rota não encontrada.
Monitore os logs do SBC para identificar padrões de falha antes que afetem usuários finais. Alertas de resposta SIP 404 ou 404 de rota inexistente indicam problema de configuração, não de infraestrutura.
Para operações que buscam otimização contínua, uma parceria com especialistas reduz o tempo de diagnóstico e evita retrabalho. Considere avaliar sua arquitetura atual com quem já implementou discadores automáticos e integrações complexas de telefonia.
Revise trimestralmente as políticas de roteamento e compare com o plano de numeração real da operação. Essa prática preventiva elimina a maioria dos incidentes antes que cheguem ao helpdesk.
Fale com um consultor da TW Solutions e avalie a arquitetura ideal para sua operação.
Perguntas frequentes
Quando o PSTN Usage no Direct Routing não encontra a rota correta, o problema está na ordem das rotas ou na política de voz?
Ambos podem causar a falha. A ordem incorreta das rotas no PSTN Usage faz o Teams selecionar um tronco genérico antes do específico. Já a Voice Routing Policy sem o uso associado impede a seleção de qualquer rota. Valide os dois pontos no diagnóstico.
Quais requisitos de contratação de SBC e tronco SIP são necessários para o PSTN Usage encontrar a rota correta no Direct Routing?
O artigo não detalha requisitos de contratação. Ele foca em configuração pós-contratação: o SBC precisa estar habilitado no tenant e as rotas associadas ao PSTN Usage. Sem isso, a chamada falha com 404 ou 480, independentemente do contrato com a operadora.
Qual o custo de corrigir falhas de PSTN Usage que não encontra a rota correta no Direct Routing?
O artigo não menciona valores. A correção envolve reordenar rotas ou ajustar a Voice Routing Policy no PowerShell, sem custo adicional de licenciamento. O investimento principal é o tempo do engenheiro para diagnosticar e testar as mudanças antes de aplicá-las.
Que suporte a Microsoft oferece quando o PSTN Usage não encontra a rota correta no Direct Routing?
O artigo sugere escalar para um especialista quando a falha persiste após validar política, uso e rotas. Isso indica dependência de camadas externas, como SBC ou operadora, que estão fora do controle direto do administrador do Teams.
O PSTN Usage no Direct Routing pode escolher uma rota incorreta mesmo com a Voice Routing Policy correta?
Sim. Se a ordem das rotas dentro do PSTN Usage colocar um padrão genérico antes do específico, o Teams seleciona o tronco errado. O artigo indica reordenar as rotas, colocando padrões mais específicos antes dos genéricos, e testar a chamada.
A falha do PSTN Usage em encontrar a rota correta no Direct Routing pode ser resolvida sem acionar a operadora?
Depende da causa. Se for ordem de rotas ou política de voz, sim, via PowerShell. Se a correção exigir mudança em SBC, tronco SIP ou configuração da operadora, o artigo recomenda escalar para um especialista, pois esses elementos estão fora do controle do administrador do Teams.
