Um telefone SIP à prova de explosão pode apresentar o estado Registado enquanto as chamadas não tocam, se ligam sem som ou caem após serem atendidas. Registo, estabelecimento da chamada, transporte de media e percurso físico de áudio são verificações separadas. Identifique a primeira etapa que falha antes de alterar definições ou substituir o telefone.
Comece pelos registos remotos e por uma chamada de teste autorizada. A inspeção física numa área perigosa exige pessoal competente, autorizações do local, isolamento e as instruções do equipamento. Não abra uma caixa energizada nem ligue um portátil ou instrumento de teste comum numa área perigosa sem os controlos necessários. O diagnóstico de rede não comprova a integridade da proteção contra explosões.
O que o registo comprova e o que deixa por testar
Uma transação REGISTER bem-sucedida confirma a aceitação do pedido pelo servidor de registo; examine as associações Contact e a sua validade para compreender o resultado. A autenticação é comum, mas 200 OK, por si só, não comprova que tenha ocorrido. O estado apresentado pode refletir uma atualização anterior, em vez da acessibilidade atual.
Uma chamada ainda precisa de um INVITE que chegue ao destino correto, de uma descrição de sessão aceitável e de um percurso de áudio funcional. O Contact do terminal, o encaminhamento da PBX, um gateway ou SBC e o destino dos media podem envolver endereços e políticas diferentes. Um telefone analógico à prova de explosão ligado por um gateway FXS deve ser diagnosticado através desse gateway; o telefone não é um terminal SIP nativo.
Classifique o sintoma antes de alterar a configuração
| Sintoma observado | Primeiros elementos a recolher |
|---|---|
| Não toca ou apresenta erro imediato | INVITE de saída, destino, resposta final e rota da PBX. |
| Ligado sem áudio ou com áudio unidirecional | Endereços e portas SDP e, depois, chegada dos media em cada sentido. |
| A chamada cai após ser atendida | Entrega de ACK, quem envia BYE, temporizadores de transação e registos da plataforma. |
| Voz entrecortada ou intermitente | Lacunas na sequência RTP, jitter, carga da ligação e comportamento do áudio local. |
Registe a hora, os números de origem e destino, o sentido, o firmware, a topologia e as alterações recentes. Verifique se os destinos internos, externos, de despacho e de sonorização falham da mesma forma. Uma falha específica de uma rota difere de uma falha que afeta todas as chamadas; preserve uma captura da falha antes de reiniciar ou editar a configuração.
Passo 1: siga a sinalização até à primeira falha
Compare o número marcado com o Request-URI real e o plano de marcação da PBX. Verifique prefixos, tradução de números, permissões de saída e a rota para a extensão ou tronco pretendido. Para falhas de entrada, verifique o Contact atualmente registado e se o INVITE de entrada chega ao telefone.
Trate os códigos de resposta como indícios, não como diagnósticos completos. Um primeiro 401 ou 407 pode ser um desafio de autenticação normal; investigue um ciclo ou uma nova tentativa autenticada rejeitada. Um 403 significa recusa, 404 indica que o utilizador ou domínio de destino não foi encontrado, 408 indica tempo limite excedido e 480 indica indisponibilidade temporária. Um 488 pode rejeitar características da sessão para além de uma simples incompatibilidade de codecs. Leia os detalhes da resposta e os registos do sistema que a gerou.
Se a PBX nunca receber INVITE, compare os resultados DNS, a VLAN, o gateway, o transporte, a porta de destino e as regras de acesso. Se receber o pedido, mas não o encaminhar, examine o encaminhamento e as políticas da plataforma. Para um INVITE atendido, verifique 200 OK e ACK nos segmentos de chamada relevantes; uma indicação de ligação não comprova a conclusão de todas as trocas.
O SIP utiliza frequentemente a porta 5060, ou 5061 com TLS, mas podem ser usadas outras portas. Verifique o transporte e os serviços de escuta configurados em vez de abrir um intervalo presumido. Com TLS, uma captura de rede comum não expõe o conteúdo SIP cifrado; utilize diagnósticos autorizados do terminal ou do servidor.
Passo 2: compare SDP com o percurso real dos media
Examine o SDP negociado, incluindo c=, m=, a=rtpmap e atributos de direção como a=sendrecv. Verifique a informação de ligação ao nível da sessão e dos media, os formatos aceites e qualquer fluxo rejeitado ou inativo. A oferta/resposta pode ocorrer em diferentes mensagens SIP; não presuma que INVITE e 200 OK contêm sempre a negociação completa.
Verifique se cada endereço e porta de media anunciado é acessível através da topologia implementada. Um endereço privado é problemático quando o outro extremo não o consegue alcançar por encaminhamento, não apenas por ser privado. Compare os pacotes de ambos os lados de uma firewall ou fronteira NAT para determinar onde um dos sentidos é interrompido. Permita os fluxos de media configurados; não existe um intervalo universal de portas RTP para todos os telefones.
Um SBC pode ancorar os media quando configurado para tal. STUN, TURN e ICE têm funções diferentes e exigem suporte compatível no terminal e na plataforma; nenhum é uma opção universal para corrigir NAT. Examine a conceção antes de alterar o comportamento do SIP ALG ou da firewall e preserve uma forma de repor a configuração anterior.
Compare os tipos de payload aceites, parâmetros de codec, formação de pacotes e requisitos RTP/SRTP em cada segmento. Um gateway ou PBX só pode transcodificar quando essa função é suportada e está ativa. Uma resposta SDP pode aceitar vários formatos; é incorreto presumir que cada resposta seleciona exatamente um codec. Não deduza os codecs suportados a partir da caixa à prova de explosão ou de outro modelo.
Se os media pararem após espera, transferência ou um re-INVITE, compare os novos endereços, portas e direção SDP com a sessão original. Para desconexões a intervalos fixos, examine a mensagem de libertação e os registos antes de atribuir a causa a um temporizador de sessão ou a um tempo limite NAT. A perda RTP e o jitter descrevem o transporte; nenhum comprova que um microfone esteja a produzir voz utilizável.
Passo 3: verifique a cadeia de áudio local e os serviços necessários
Quando os media chegarem aos terminais corretos, verifique silêncio, ganho, auscultador, microfone, altifalante e saída de áudio selecionada através dos procedimentos aprovados. Pacotes bidirecionais podem transportar silêncio ou payloads que não podem ser descodificados. Compare com uma chamada e um terminal de referência funcionais sem presumir que a substituição comprova um defeito de hardware; credenciais, firmware, porta do comutador e definições de rede também podem diferir.
Teste separadamente o auscultador, o modo mãos-livres e as saídas de sonorização externa, quando existentes. Um auscultador funcional não comprova o funcionamento de um amplificador externo, circuito de cornetas ou relé de sonorização. A apresentação de localização no despacho, gravação, prioridade e integração de alarmes pertencem à plataforma ou à integração, salvo se o terminal específico implementar explicitamente essas funções.
Utilize capturas sincronizadas em pontos adequados e autorizados: diagnóstico do terminal, porta espelhada de um comutador, PBX ou SBC. Correlacione o Call-ID SIP e os carimbos de data e hora, lembrando que um SBC pode criar segmentos de chamada diferentes. Capture apenas o tráfego necessário e proteja os registos e gravações. O SRTP cifrado não pode ser ouvido a partir de uma captura comum sem material de chaves autorizado e um método de análise adequado.
Após uma alteração controlada, repita a rota que falhou e ambos os sentidos do áudio; depois verifique as funções de sonorização ou despacho afetadas e a recuperação após qualquer comutação por falha planeada. Guarde as definições finais, a referência da captura e o resultado. Para práticas de monitorização e configuração a longo prazo, consulte a manutenção remota de telefones de sonorização à prova de explosão.
Perguntas frequentes
Por que as chamadas internas funcionam e as externas falham?
As chamadas externas acrescentam encaminhamento de troncos, permissões, tradução de números e políticas a montante. Compare o percurso interno funcional com a chamada de tronco que falhou, incluindo a sinalização de retorno e os segmentos de media, em vez de presumir que o registo testa o tronco.
Todas as falhas sem áudio devem ser tratadas como problemas de codec?
Não. Primeiro determine a sessão negociada e se os media chegam a cada terminal. Encaminhamento, NAT, regras de acesso, compatibilidade SRTP e áudio local podem produzir silêncio. Uma definição de codec numa página web não comprova o que foi negociado na chamada.
Reiniciar é uma reparação?
Um reinício pode restaurar um processo ou atualizar uma associação, mas não identifica a causa. Preserve primeiro os elementos disponíveis quando possível e verifique depois uma recuperação repetível. Registe qualquer interrupção do serviço e assegure o método alternativo de comunicação do local durante a manutenção.
Referências técnicas
Base de protocolo: IETF RFC 3261, SIP e IETF RFC 3264, oferta/resposta SDP. Contexto de manutenção em áreas perigosas: orientações da HSE sobre eletricidade em atmosferas potencialmente explosivas.
