Tecnologia líder no mercado de telecomunicações

Posts para » Sem categoria

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.

 

 


Consulta de operadora em Python PHP e Java via novo WebService ATI

consulta de operadora via web service ATI

Para facilitar a gestão de créditos aos clientes ATI, Sistema que realiza a consulta de operadora, disponibilizamos um novo modo de realizar as consultas via Web Service, informando juntamente com o RN1 da operadora, o saldo atual de créditos da conta que está realizando a consulta e o seu vencimento. Neste post também veremos exemplos de como realizar a consulta em Python, PHP e Java.

Para realizar a consulta retornando as informações adicionais, foi criado um novo Web Service a parte, que opera inclusive em outra porta, 9091.
Leia mais…


Limite de chamadas, max calls, por gateway com FreeSWITCH

FreeSwitch

Ao se trabalhar em ambientes com grandes volumes de chamadas, como call centers e operadoras VoIP por exemplo, a quantidade de chamadas simultâneas enviadas para determinados gateways acaba atingindo valores verdadeiramente altos durante a produção.

Esta situação pode vir a ser um problema quando se utilizam gateways que possuem recursos limitados, como baixo poder de processamento ou memória, fazendo com que estes equipamentos venham a travar ao receber este grande volume de requisições.

Para evitar este tipo de problema, é necessário acrescentar algum mecanismo de controle de entrega de chamadas para os gateways, fazendo com que o volume de chamadas não ultrapasse o limite do gateway. Leia mais…


Webinar – SCM Call Routing – 30 de Abril

webinar
Serviços de VoIP estão cada vez mais comuns em nosso dia a dia. Este mercado abre inúmeras oportunidades para provedores de serviços sobre a internet, que não só oferecem serviços de melhor qualidade como também a um custo mais competitivo.
Mas o uso da internet como meio de comunicação de voz, traz também os custos e riscos inerentes ao mundo da web. Uma vez que você conecta seu serviço a internet em um lado (para acesso a seus clientes) e a operadoras do outro, a falta de controle sobre sua segurança pode trazer prejuízos significativos. Uma vez que um hacker entrou em sua rede, seja por um terminal de um cliente seu sem segurança, ou seja mesmo vindo de um PABX IP não seguro, ele poderá ter acesso a diversos recursos de interconexão que sua rede ofereça. Há na internet diversos mecanismos maliciosos que buscam pro fraquezas em redes VoIP para explora-las e fraudá-las,
Neste próximo dia 30 de Abril, A SIPPulse irá conduzir um webinar sobre nossas soluções SCM e como podemos apoiar sua empresa a reduzir a exposição a fraudes.

Faça sua inscrição gratuita aqui  !