Tecnologia líder no mercado de telecomunicações

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.

 

 


Categorias: Dicas Suporte, Sem categoria

Tags: , , , ,

One thought on “Das trincheiras, resolvendo problemas com chamadas desconectadas

  1. Poxa artigo completo heim. Parabéns !!! Já vi algumas explicações no grosso modo falando sobre chamadas interrompidas, mas nada esclarecedor como esse aqui. Usar o voip é vantajoso mas essas falhas acontecem e nas muitas vezes se acha que é o provedor do serviço, mas há uma serie de fatores a serem levados em conta. Essa telefonia alternativa está disponível a todos mas é bom conhecer o que tem a oferecer, isso me ajudou https://www.voipdobrasil.com.br/blog/verdades_e_mentiras_sobre_voip

Deixe uma resposta para Daniel Perretti Cancelar resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>