Tecnologia líder no mercado de telecomunicações

Posts para » sippulse

Das trincheiras, resolvendo problemas com chamadas desconectadas

Imagem dos artigos das trincheiras

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:

  1. Timeout do áudio (RTP).  Um dos lados ou os dois pararam de enviar o áudio
  2. Erros de roteamento, encaminhamento errado do ACK
  3. Tratamento incompleto dos RE-INVITES
  4. Bugs nos endpoints ou gateways
  5. 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:

  1. BYE vindo do destino (terminação)
  2. BYE vinda da origem (cliente)
  3. 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.

  1. 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.
  2. 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:

  1. Endereço errado no Session Descrition Protocol
  2. Bloqueio no firewall entre os endereços descritos no SDP
  3. Application Layer Gateway no meio do caminho
  4. 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.