Na manutenção de um telefone SIP à prova de explosão, uma resposta 200 OK a uma transação REGISTER confirma apenas que o terminal estabeleceu com sucesso uma associação de endereço autenticada com o servidor de registro. Isso não garante que um INVITE possa ser roteado corretamente, que o SDP consiga negociar um codec compatível ou que a mídia RTP possa trafegar nos dois sentidos entre o telefone à prova de explosão e a extremidade remota. Em outras palavras, o estado “Registrado” descreve apenas uma parte da alcançabilidade do plano de controle SIP, e não a capacidade completa de chamada ponta a ponta.
Por isso, um telefone à prova de explosão pode aparecer corretamente registrado e ainda não tocar, conectar sem áudio, apresentar voz em apenas um sentido ou desconectar imediatamente após o atendimento. Em muitos casos, o servidor de registro não é a verdadeira origem da falha. O problema está no caminho de sinalização, no caminho de mídia ou na cadeia de áudio local posterior ao registro. Diagnosticar em três camadas — sinalização, mídia e áudio do terminal — transforma uma reclamação vaga de “registrado, mas não consegue chamar” em uma sequência de etapas testáveis de forma independente e evita reinicializações repetidas do dispositivo na direção errada.
Por que “Registrado” não significa que o telefone certamente consegue fazer chamadas?
Primeiro, é preciso entender o que o registro realmente faz. Uma solicitação REGISTER enviada pelo terminal normalmente contém vários campos importantes: Request-URI, que identifica o domínio de registro; To, que representa a conta registrada, ou Address-of-Record (AOR); Contact, que identifica o endereço atual pelo qual o terminal pode ser alcançado, normalmente um endereço IP e uma porta; e Expires, que define por quanto tempo o registro permanece válido.
O registro não é uma operação única. A plataforma mantém no serviço de localização uma relação indicando que determinado AOR pode ser alcançado naquele momento por um Contact específico. Essa associação tem um tempo de expiração, muitas vezes configurado em torno de uma hora. O terminal precisa renovar o registro antes que ele expire. Caso contrário, a plataforma pode acabar considerando o ramal desconectado.
A autenticação normalmente exige duas trocas. Primeiro, o terminal envia REGISTER sem credenciais e o servidor responde com 401 Unauthorized, acompanhado de parâmetros de desafio como realm e nonce. O terminal calcula o resumo de autenticação usando as credenciais da conta e envia outro REGISTER com um cabeçalho Authorization. Só então normalmente recebe 200 OK. Portanto, em termos de sinalização, “registro bem-sucedido” significa que o terminal e o servidor acabaram de concluir uma transação REGISTER autenticada.
Uma chamada telefônica real exige muito mais. Quando o usuário disca, o terminal precisa gerar um INVITE. O PBX, servidor SIP ou plataforma de despacho deve rotear o número chamado de acordo com as regras de numeração e permissões. Em seguida, os dois lados usam SDP para negociar um codec, um endereço de mídia e uma porta RTP antes que a voz possa efetivamente fluir.
Sinalização e mídia também seguem caminhos separados. A sinalização SIP normalmente usa UDP/TCP 5060 ou TLS 5061, enquanto o RTP utiliza uma faixa separada de portas UDP dinâmicas. Se um firewall liberar 5060, mas bloquear a faixa RTP, o registro pode funcionar perfeitamente enquanto a chamada fica sem áudio.
REGISTER é concluído com sucesso
→ A conta SIP aparece conectada
→ O INVITE ainda pode ser rejeitado
→ Mesmo que 200 OK seja retornado
→ O RTP ainda pode ser bloqueado por firewall, NAT ou endereço de mídia incorreto
→ Mesmo que o RTP chegue ao terminal
→ O microfone ou alto-falante local ainda pode estar com defeito
O ponto principal é simples: o estado de registro é apenas uma fotografia indicando que uma transação foi bem-sucedida em determinado momento; não comprova a disponibilidade de voz ponta a ponta. Ele nem sequer comprova que a rede esteja alcançável neste exato momento, pois o registro é renovado periodicamente e o estado Registrado exibido pode apenas refletir a última renovação bem-sucedida.
Primeiro determine se a falha está no estabelecimento da chamada ou na mídia de voz
Quando alguém informa que um telefone está “registrado, mas não consegue fazer chamadas”, o primeiro passo não deve ser alterar codecs ou configurações de rede. Primeiro determine exatamente o que “não consegue chamar” significa. Algumas perguntas normalmente definem a direção do diagnóstico antes de qualquer ferramenta ser usada.
Uma chamada SIP completa pode ser dividida em duas etapas principais. A primeira é o estabelecimento da chamada, que começa com INVITE e continua até o lado chamado responder com 200 OK e o chamador enviar ACK. A segunda é a mídia de voz, quando a negociação SDP já foi concluída e o RTP bidirecional deve efetivamente fluir. A divisão mais simples é verificar se a interface do usuário mostra a chamada como conectada.
Se a discagem gerar erro imediato, não houver toque ou o usuário remoto nunca receber a chamada, o problema provavelmente está na sinalização SIP ou no roteamento da chamada. Se os dois lados mostram a chamada como conectada e o cronômetro está em andamento, mas não há áudio ou há áudio em apenas uma direção, o diagnóstico deve migrar para o caminho de mídia SDP e RTP.
| Sintoma | Etapa provável | Primeiras verificações |
|---|---|---|
| Erro imediato ao discar / sem toque / extremidade remota não recebe nada | Estabelecimento da chamada | Roteamento de números, permissões, códigos de resposta SIP, alcançabilidade da sinalização |
| Chamada aparece conectada, mas não há áudio | Mídia de voz | Endereço de mídia SDP, portas RTP, firewall, NAT, codec |
| A chamada conecta, mas o áudio é unidirecional | Mídia de voz | Comparar SDP, RTP, mapeamento NAT e fluxos de mídia capturados por direção |
| A chamada desconecta após alguns segundos | Estabelecimento + mídia | ACK, Session Timer, expiração de NAT, política de liberação da plataforma |
| Áudio entrecortado ou intermitente | Qualidade do transporte de mídia | Perda de pacotes, jitter, latência, largura de banda e alterações nas portas RTP |
Dois outros padrões também ajudam. Se o telefone consegue fazer chamadas, mas não receber, a causa costuma estar relacionada ao roteamento de números de entrada, endereço Contact, NAT ou roteamento da plataforma. Se consegue receber, mas não fazer chamadas, a verificação deve se concentrar no plano de discagem, permissões de saída, formato do número ou configuração do tronco SIP.
Se ramais SIP comuns conseguem ligar entre si, mas chamadas para a console de despacho, sistema de avisos ou PSTN falham, o domínio da falha fica muito menor e provavelmente está ligado a uma rota ou interface específica.
Portanto, um relatório de campo útil deve responder a quatro perguntas:
A falha ocorre em chamadas de saída ou de entrada?
A chamada chega a tocar?
A interface mostra a chamada como conectada?
Não há áudio, há áudio em um só sentido ou a chamada cai após alguns segundos?
Essas quatro respostas são muito mais úteis do que simplesmente dizer “o telefone não funciona”.
Quando o estabelecimento da chamada falha, verificar primeiro o número, as permissões ou a resposta SIP?
Se o problema ocorre durante o estabelecimento, siga o caminho da sinalização SIP antes de suspeitar do hardware do telefone à prova de explosão. Uma ordem prática é: número → permissões → código de resposta → alcançabilidade da sinalização.
Comece pelo número e pelo plano de discagem. O Request-URI enviado pelo terminal corresponde ao que a plataforma espera? O ramal precisa de prefixo? A discagem entre sistemas exige código de área, código de acesso ou tradução de números? Muitos casos de “registrado, mas não consegue chamar” são causados por incompatibilidade entre o formato enviado pelo telefone e as regras de roteamento configuradas no PBX.
Por exemplo, o telefone pode enviar 8001, enquanto o PBX espera 8#8001 ou um número completo no formato E.164. Uma captura de pacotes mostrando o Request-URI do INVITE confirma isso imediatamente.
Em seguida, verifique as permissões da conta. Alguns ramais só podem fazer chamadas internas e não têm permissão para PSTN. Outros conseguem chamar ramais SIP comuns, mas não podem acessar linhas de emergência, grupos de despacho ou zonas de avisos. Esse tipo de configuração de classe de serviço é especialmente fácil de ignorar em projetos industriais, porque o registro não testa essas permissões de negócio. REGISTER responde “esta conta está online?”, enquanto a tentativa de chamada responde “esta conta está autorizada a chamar este destino?”.
Os códigos de resposta SIP podem então reduzir ainda mais o escopo da falha:
| Classe | Respostas comuns | Direção típica |
|---|---|---|
| 1xx Informativa | 100 Trying, 180 Ringing, 183 Session Progress | O estabelecimento está avançando; o problema pode estar mais adiante ou relacionado à mídia |
| 2xx Sucesso | 200 OK | Estabelecimento concluído; passar para o diagnóstico de mídia |
| 4xx Falha do cliente | 401/407 autenticação, 403 permissão, 404 não encontrado, 408 timeout, 480 indisponível, 486 ocupado, 488 incompatibilidade de codec | Frequentemente relacionado à configuração do terminal, roteamento ou política de serviço |
| 5xx Falha do servidor | 500, 503 Service Unavailable | Lado do PBX, SBC ou plataforma de despacho |
| 6xx Falha global | 603 Decline | O destino rejeita explicitamente a chamada |
Algumas respostas aparecem com frequência no diagnóstico. 401/407 normalmente apontam para o tratamento do desafio de autenticação, como credenciais, algoritmo ou associação da conta. 403 deve direcionar a investigação para regras de permissão, política da conta ou o motivo pelo qual a plataforma rejeitou a solicitação. 404 pode significar que o número não existe ou nenhuma rota corresponde. 408 e 480 apontam para timeout ou indisponibilidade do usuário. 488 é frequentemente associado a capacidades de mídia incompatíveis ou negociação de codec.
Se a configuração SIP parecer correta, mas o INVITE nunca chegar ao sistema de destino, volte ao caminho de rede. Verifique VLAN, gateway, firewall, regras ACL e o endereço de destino realmente usado pelo telefone. O teste mais rápido é capturar o tráfego no lado do servidor. Se o INVITE chegar, mas não for encaminhado, investigue o roteamento do PBX ou da plataforma de despacho. Se nunca chegar, concentre-se no terminal ou no caminho entre o terminal e o servidor.
Se a chamada está conectada, mas não há áudio ou há áudio em apenas um sentido, o que verificar?
“Os dois lados mostram conectado, mas não há som” é uma das falhas SIP mais comuns. Nesse ponto, a sinalização normalmente já foi concluída com sucesso. O problema tende a estar na negociação SDP ou no transporte RTP. O diagnóstico deve passar do plano de sinalização para o plano de mídia.
Comece pelas informações de mídia transportadas no SDP. Algumas linhas são especialmente importantes: c= identifica o endereço de conexão, m= define a mídia e a porta, a=rtpmap mapeia tipos de carga útil para codecs e a=sendrecv/sendonly/recvonly define a direção da mídia.
O endereço de áudio anunciado pelo terminal no INVITE ou 200 OK precisa ser alcançável pela extremidade remota. Se o terminal inserir no SDP um endereço privado não roteável como 192.168.x.x enquanto a extremidade remota está em outra rede, a chamada SIP pode ser estabelecida normalmente mesmo que o fluxo RTP nunca chegue ao destino. É a clássica falha “conectado, mas sem áudio”.
Ambientes NAT são especialmente propensos a esse problema, e o tratamento depende da arquitetura de rede. A sinalização SIP pode atravessar o NAT normalmente enquanto o caminho de mídia falha completamente. Comportamentos NAT comuns incluem NAT cone completo, NAT cone restrito, NAT cone restrito por porta e NAT simétrico, com dificuldade crescente de atravessamento.
Redes industriais costumam resolver isso usando um SBC como relé de mídia, ancorando o RTP em um ponto conhecido. Outros ambientes podem usar STUN para descobrir mapeamentos de endereço público, enquanto implantações mais complexas podem usar TURN ou ICE. O mecanismo correto depende da topologia real. Um REGISTER bem-sucedido não comprova que o RTP consegue atravessar o NAT.
Firewalls são outra causa comum. Alguns projetos liberam apenas 5060 ou 5061 porque são as portas SIP óbvias, enquanto a voz usa uma faixa RTP totalmente separada. Muitos dispositivos alocam dinamicamente portas RTP em intervalos como 10000–20000. Se SIP estiver liberado, mas RTP for bloqueado por uma ACL, o resultado será exatamente o relato “a chamada conecta, mas não há áudio”.
Áudio unidirecional deve ser investigado por direção. Se a sala de controle consegue ouvir o telefone de campo, mas o usuário de campo não ouve a sala de controle, pelo menos uma direção RTP ou um caminho de áudio local já está funcionando. Em vez de revisar toda a rede novamente, compare os dois endereços SDP, portas RTP, mapeamentos NAT e fluxos de mídia capturados. Diferenças direcionais frequentemente apontam diretamente para o mapeamento NAT, regra de firewall ou endereço SDP incorreto de um dos lados.
Depois de verificar a rede, confira o codec e a cadeia de áudio local
A presença de pacotes RTP não garante voz inteligível. O próximo passo é confirmar se os dois lados realmente negociaram um codec compatível.
A negociação de codec segue o modelo de oferta/resposta do SDP. O terminal chamador lista no SDP do INVITE os codecs suportados, normalmente em ordem de preferência. O terminal chamado escolhe um codec que também suporta e o retorna no 200 OK. Se as duas listas de capacidades não tiverem nenhum codec em comum, a negociação de mídia falha.
Codecs comuns em telefones industriais à prova de explosão incluem G.711 (PCMU/PCMA, 64 kbps e amplamente compatível com ambientes PSTN), G.729 para links de menor largura de banda, G.722 para voz em banda larga e Opus em alguns dispositivos mais recentes. Se o telefone tiver apenas um grupo de codecs habilitado enquanto o PBX, sistema de gravação ou plataforma de despacho suportar outro, o resultado pode ser 488 Not Acceptable Here ou, em algumas implementações, uma chamada conectada com mídia anormal.
O método correto é comparar os tipos de carga útil (Payload Types) e as listas de codecs nas duas mensagens SDP, em vez de apenas verificar uma página de gerenciamento que indica que um codec está habilitado.
Depois de confirmar a negociação do codec e o transporte RTP, passe para o caminho físico de áudio do terminal. Telefones à prova de explosão costumam operar por longos períodos em ambientes ruidosos, úmidos, empoeirados ou corrosivos. Microfone, monofone, alto-falante, módulo amplificador, conector ou cabo de campo podem falhar mesmo que a pilha SIP esteja funcionando perfeitamente.
Um método prático é comparar as estatísticas RTP com o que realmente se ouve no local. Se a captura mostrar RTP bidirecional contínuo, com quantidade e temporização de pacotes normais, mas um lado ainda estiver sem áudio, verifique mute, nível de áudio e microfone ou alto-falante físico. Se o RTP estiver sendo transmitido, mas o conteúdo de áudio estiver praticamente silencioso, investigue também a captação do microfone ou o caminho de aquisição de áudio.
Quando há análise quantitativa de mídia, três indicadores são especialmente úteis: perda de pacotes, jitter e latência unidirecional. A degradação de voz aumenta com a perda de pacotes, jitter excessivo pode exigir um buffer maior e alta latência unidirecional dificulta uma conversa natural. Se a perda estiver concentrada em um salto específico da rede, pode haver congestionamento de enlace ou transporte por rádio.
Para estações de avisos à prova de explosão com saída amplificada, diferencie também o caminho do alto-falante interno do telefone de qualquer saída para corneta externa ou amplificador. Eles não necessariamente usam exatamente o mesmo caminho de áudio. Uma chamada normal pelo monofone ou viva-voz não comprova que o áudio externo de avisos esteja funcionando, e o inverso também é verdadeiro. Comissionamento e diagnóstico devem verificar cada caminho de áudio necessário separadamente, em vez de tratar toda reclamação de “sem áudio de avisos” como falha SIP.
Como uma captura de pacotes pode reduzir rapidamente o domínio da falha?
Para uma falha SIP complexa, alterar parâmetros repetidamente costuma ser menos eficaz do que capturar uma chamada completa com falha e acompanhá-la em ordem cronológica de REGISTER até BYE. O Wireshark é suficiente na maioria dos casos. Pontos de captura úteis incluem o lado do telefone, uma porta espelhada do comutador e o lado do SBC ou PBX.
O local da captura determina o que pode ser provado. Uma captura no terminal mostra exatamente o que o telefone enviou e recebeu, ajudando a determinar se a falha se origina localmente. Uma captura no SBC ou PBX mostra se a plataforma recebeu e encaminhou a sinalização corretamente. Em implantações que atravessam VLANs, sites ou um SBC, capturas em vários pontos são preferíveis, porque um único ponto só comprova que uma mensagem passou por aquele local; não comprova o comportamento do próximo segmento da rede.
Com a captura disponível, siga a chamada nesta ordem:
1. REGISTER foi bem-sucedido?
→ 2. INVITE foi realmente enviado?
→ 3. O PBX recebeu e roteou corretamente?
→ 4. A extremidade remota retornou 18x / 200 OK?
→ 5. O SDP negociou um codec comum?
→ 6. Há RTP bidirecional de fato?
→ 7. Os endereços IP e portas de destino RTP estão corretos?
→ 8. O microfone e o alto-falante de campo realmente estão transmitindo áudio?
O Wireshark oferece ferramentas úteis. Mensagens SIP podem ser filtradas com expressões como sip ou sip.CSeq. Em Telephony → VoIP Calls, uma chamada pode ser revisada junto com sua sequência de sinalização e os fluxos RTP relacionados. A análise RTP também ajuda a identificar perda de pacotes, jitter e outros indicadores de qualidade de mídia.
A ordem de diagnóstico deve continuar sendo primeiro sinalização, depois mídia. Se a sinalização falhar, o problema está no estabelecimento da chamada. Se a sinalização for concluída, mas a mídia estiver ausente, a investigação deve se concentrar no caminho de mídia.
Em um caso de “saída funciona, entrada falha”, verifique se o INVITE de entrada realmente chega ao telefone à prova de explosão. Se a chamada cair de forma consistente após alguns segundos ou dezenas de segundos, verifique ACK, Session Timer, mapeamento NAT e se a plataforma encerra a sessão porque uma mensagem esperada não foi recebida.
Outro caso menos evidente é a renegociação de mídia durante a chamada. Um re-INVITE pode alterar o endereço ou a porta RTP. Se um mapeamento NAT falhar durante essa renegociação, o sintoma pode ser “a chamada funcionou por alguns segundos e depois o áudio desapareceu”.
O objetivo não é memorizar todos os códigos de resposta SIP. Continue fazendo uma pergunta: qual foi a última camada que esta chamada atravessou com sucesso e onde apareceu o primeiro comportamento anormal? Depois de localizar o primeiro ponto de falha, grande parte do diagnóstico já está concluída.
Perguntas frequentes
Se um telefone SIP aparece registrado, isso pelo menos prova que a rede está funcionando?
Não. Registrado apenas mostra que o terminal conseguiu concluir uma transação de registro SIP com o Registrar em determinado momento. Isso não prova que roteamento de chamadas, alcançabilidade do destino, mídia RTP, NAT, regras de firewall ou hardware de áudio do terminal estejam funcionando. Também não garante que a rede permanecerá livre de perda de pacotes ou alta latência durante uma chamada real. Como o registro é periódico, o estado Registrado exibido pode apenas refletir a última renovação bem-sucedida.
Os dois lados aparecem conectados, mas não há áudio. O que verificar primeiro?
Primeiro inspecione os endereços IP de mídia, portas RTP e negociação de codec no SDP. Depois confirme que firewall, dispositivo NAT ou SBC permitem RTP bidirecional. Se o RTP bidirecional estiver definitivamente chegando aos dois terminais, passe para microfone, alto-falante, estado de silenciamento e configurações de saída de áudio local. A ordem prática é caminho de mídia primeiro, hardware local depois.
Por que o mesmo telefone à prova de explosão consegue fazer chamadas internas, mas falha em chamadas PSTN?
Chamadas entre ramais internos e chamadas PSTN normalmente usam caminhos de roteamento diferentes. Chamadas externas também envolvem permissões de saída, tradução de números, configuração do tronco SIP, roteamento da operadora e regras de identificação do chamador. Uma chamada ramal a ramal bem-sucedida só comprova que parte do caminho SIP e de mídia funciona. Chamadas PSTN ainda precisam passar pelo tronco e pela rede da operadora, introduzindo requisitos adicionais de roteamento e política.
O registro está normal, mas o áudio fica entrecortado ou a chamada cai no meio. O que pode causar isso?
O problema geralmente está na qualidade do transporte de mídia: perda de pacotes, jitter excessivo, largura de banda insuficiente ou mapeamento NAT expirado podem interromper o RTP durante a chamada. Verifique primeiro perda e jitter RTP, depois capacidade do enlace e cobertura de rádio quando aplicável. Se as chamadas sempre caírem após um intervalo previsível, investigue também a renegociação de mídia por re-INVITE e o comportamento do Session Timer.
Por que substituir o telefone resolve o problema enquanto a unidade original continua falhando?
Isso geralmente aponta para configuração, firmware ou hardware local do telefone original, e não para a rede. Possíveis causas incluem problema de firmware, parâmetros SIP incorretos como expiração do registro, tratamento NAT ou faixa de portas RTP, ou falha no DSP ou módulo de áudio. Compare os dois dispositivos configuração por configuração, especialmente listas de codecs, portas SIP e ajustes NAT, em vez de atribuir imediatamente a diferença a uma rede instável.
Reiniciar um telefone SIP à prova de explosão pode ser considerado um método adequado de diagnóstico?
Uma reinicialização pode restaurar temporariamente o registro, renovar um mapeamento NAT ou liberar um processo travado, mas não deve substituir o isolamento da falha. Se a causa estiver na configuração do plano de discagem, permissões SIP, regras de firewall, negociação de codec ou roteamento de mídia, reiniciar pode apenas mascarar o problema por pouco tempo ou não produzir efeito algum. Uma abordagem melhor é registrar os sintomas, preservar capturas de sinalização e registros e então determinar se a primeira falha está no terminal, na rede ou na plataforma de comunicações.
A Becke Telcom pode auxiliar no diagnóstico com base na arquitetura real do terminal, IP PBX, tronco SIP, comutação de rede, SBC e sistema de despacho. A Becke Telcom também fornece telefones à prova de explosão, telefones de avisos à prova de explosão, gateways SIP, sistema de avisos IP e equipamentos de despacho unificado para ambientes industriais petroquímicos, de energia, mineração, túneis e outros.
