Tempo de leitura: 6 minutos
Este é um artigo gerado das trincheiras do suporte técnico.
Um dos casos mais comuns e irritantes com VoIP são chamadas desconectadas. Você está no meio de uma conversação e a chamada é desligada abruptamente. Se você estiver fazendo uma venda, irrita, se estiver fazendo uma cobrança é desastroso, o cliente pode facilmente desligar.
Entenda porque as chamadas são desconectadas em VoIP e como solucionar o problema.
Principais razões para uma chamada desconectada:
- Timeout do áudio (RTP). Um dos lados ou os dois pararam de enviar o áudio
- Erros de roteamento, encaminhamento errado do ACK
- Tratamento incompleto dos RE-INVITES
- Bugs nos endpoints ou gateways
- Fim do crédito
Processo para identificar o problema
Eu costumo dizer que na resolução de problemas, 90% do tempo é gasto no levantamento de dados e apenas 10% na análise. Se você estiver com um problema de chamadas desconectadas a primeira coisa a fazer é reproduzir o problema e fazer uma coleta de logs e traces SIP. Você pode usar a ferramenta de SIP trace do SipPulse ou simplesmente o ngrep.
Análise diferencial
Quando reproduzir o problema, tente entender se a chamada está ficando muda ou está sendo desligada. Isso é chave para o entendimento do problema.
Desligamento da chamada
Quando ocorre o desligamento, a chamada é encerrada, não apenas ficando muda. O primeiro passo em uma chamada desligada é identificar quem gerou o desligamento. Isso pode ser feito analisando a origem do pedido de BYE. O SipPulse possui um relatório de motivos de desligamento e pode rapidamente identificar a origem e causa do desligamento.
O BYE pode ter sido enviado de três possíveis fontes:
- BYE vindo do destino (terminação)
- BYE vinda da origem (cliente)
- BYE vindo do servidor
BYE vindo do cliente.
Se o BYE está vindo do cliente, deve se explicar ao cliente que ele mesmo está desligando a chamada e pedí-lo para examinar na sua platafoma o que está ocorrendo. Muitas vezes pequenos problemas de interoperabilidade podem ocasionar as quedas.
BYE vinda da terminação
Da mesma forma se o BYE está vindo da terminação, cabe a ele explicar porque seu sistema ou gateway está originando um BYE. Eventualmente podem ser encontrados problemas de interoperabilidade.
BYE vindo do SipPulse.
Se o BYE está vindo do SipPulse é preciso analisar as seguintes causas.
- Falta de ACK. Alguns clientes não roteiam corretamente o ACK, não são capazes de entender os cabeçalhos ROUTE e RECORD_ROUTE. Algumas vezes a terminação envia um RECORD_ROUTE incorreto (Asterisk sem externip por exemplo). Se o SipPulse enviar um BYE após 5s, significa que ele não recebeu o ACK e desligou para evitar maiores danos. Se o ACK não veio o BYE não vai vir e a chamada ficará presa. Verifique no trace se o pedido de ACK possui o campo Route:, se não tiver, eis o problema.
- Falta de áudio em uma das pontas. Se o SipPulse estiver tratando mídia (Media KeepAlive), e um dos lados parar de enviar áudio a chamada será desconectada em 90 segundos para não ficar presa. As vezes se o CODEC é g729B com supressão de silencio, isto pode acontecer. É possível no SipPulse configurar o RTPPROXY para mandar a notificação de desconexão apenas se os dois lados pararem de enviar áudio.
Chamada Muda
A resolução da chamada muda é ainda mais desafiadora. A grande maioria dos casos de chamada muda ocorre por falha em um dos firewalls no caminho. É importante lembrar que o RTP no caso do SipPulse é independente e pode estar sendo enviado diretamente ao gateway da sua interconexão.
Os principais motivos de chamada muda são:
- Endereço errado no Session Descrition Protocol
- Bloqueio no firewall entre os endereços descritos no SDP
- Application Layer Gateway no meio do caminho
- Re-INVITE com endereços SDP errados ou falta do cookie nat=yes, mkp=yes
Endereço errado no SDP (Session Description Protocol)
Um dos casos mais comuns, é uma falha no sistema onde no endereço SDP após a passagem no Proxy ainda é mostrado um endereço interno (iniciando com 192.168, 172.16 ou 10). Não há conectividade e a chamada fica muda. Este caso é muito comum com NAT (tradução de endereço de rede).
SDP presente no INVITE
c=IN IP4 10.8.1.31.
t=0 0.
m=audio 17844 RTP/AVP 0 8 18 101.
SDP presente no 200 OK
c=IN IP4 10.8.1.28.
t=0 0.
m=audio 21550 RTP/AVP 0 101.
Se você observar, no exemplo acima os endereços informados para troca de áudio foram 10.8.1.31 na porta UDP 17844 e 10.8.1.28 na porta UDP 21550, o codec negociado é o 0 (g711 ulaw). Como existe conectividade entre esses endereços o áudio está normal. Desconfie se você começar a ver endereços que estão atrás de NAT e que não foram convertidos para os endereços externos do roteador. Se não houver conectividade bidirecional entre os endereços a chamada vai ficar muda. É isto que queremos observar na captura.
Bloqueio no firewall
Se você verificar o SDP e os endereços estiverem corretos, é provável que um firewall no meio do caminho esteja barrando os pacotes de RTP entre os pontos. É comum o cliente autorizar o IP do provedor, mas esquecer de autorizar o IP de todos os gateways com quem se comunica diretamente.
ALG no meio do caminho
Para aqueles que tem um firewall SonicWALL, Microtik entre outros é bom desativar todo e qualquer tratamento específico de VoIP. Na maioria das vezes causa mais problema que resolve. O SipPulse é capaz de resolver sozinho os problemas com NAT se houver ALG nos firewalls, por favor desative. Um teste fácil é configurar uma porta diferente de 5060 no proxy e no cliente. Se a chamada passar, significa que um ALG estava causando problema.
ReINVITE com endereços SDP errados
O estabelecimento da chamada pode ter ocorrido corretamente, mas após 90s por alguma razão a chamada ficou muda. Um Re-INVITE pode ter sido gerado com endereços SDP errados. Os RE-INVITES são marcados com cookies (nat-yes, mkp=yes). Se estes cookies são suprimidos no gateway ou no cliente, no RE-INVITE o sistema não saberá que tem de ativar o RTPPROXY novamente. É fácil de ver, basta examinar o SDP das mensagens de RE-INVITE e ver se o pedido após passar no proxy contêm o endereço do RTPPROXY no SDP. Uma dica para reproduzir o problema é pressionar a tecla Hold e Resume. O Hold gera um Re-INVITE. Se ficou mudo após o hold, tem problema no Re-INVITE.
Resumo
Chamadas mudas não são difíceis de serem diagnosticadas, mas é preciso reproduzir o problema e coletar dados antes de chegar a uma conclusão. Abaixo um resumo do que verificar:
Relatório de chamadas desconectadas
SIP Trace
– ACK sem Route
– Endereços no SDP que não tem conectividade entre sí
– Firewalls e roteadores com ALG (Mudar porta de 5060 p/ outra no cliente e servidor)
Teste de Hold/Resume para RE-INVITES
Eu espero que este artigo lhe ajude a encontra chamadas desconectadas e mudas mais rapidamente.
