Sumário

1Exemplos de problemas encontrados em ligações VoIP.....................................................................1

1.1Chamada VoIP sem áudio – sem tráfego RTP/RTCP..................................................................1
1.1.1Espelhamento de portas em switch gerenciável..................................................................2
1.2Chamada VoIP sem áudio – STUN desativado...........................................................................3
1.2.1Servidores STUN ...............................................................................................................6
1.2.2Redirecionamento de portas................................................................................................8
1.3Chamada VoIP rejeitada..............................................................................................................9
1.4Chamada VoIP completa ..........................................................................................................10

1 Exemplos de problemas encontrados em ligações VoIP

1.1 Chamada VoIP sem áudio – sem tráfego RTP/RTCP

Em uma interligação entre PABXs Ision, a reclamação era de que as ligações estavam
ficando sem áudio nos dois lados da conversação.
Analisando o traço podemos perceber que a sinalização SIP ocorre normalmente, ou
seja, a central de IP 192.169.1.180 envia o INVITE (com destino ao usuário 8866) a
central de IP 192.169.1.4, o qual é rejeitado (solicitado à senha) e faz com que seja
enviado o RE-INVITE. Após isso as mensagens 200 OK, 100 Trying e 180 Ringing são
enviadas corretamente do destinatário ao originador da ligação, conforme FIGURA 1.
 Figura 1 - Fluxo de mensagens SIP

Conforme apresentado na figura anterior podemos perceber que não há troca de

pacotes RTP/RTCP entre origem e destino, por conta disso, não é possível identificar o
problema. Isso provavelmente aconteceu devido à falta da configuração do espelhamento
de portas no switch onde as centrais e suas respectivas placas estavam conectadas.

1.1.1 Espelhamento de portas em switch gerenciável

O espelhamento de portas é muito utilizado para analisar tráfegos de rede, onde é

necessário avaliar todos os pacotes que passam por diferentes portas em um switch.
Essa opção é encontrada apenas em switches gerenciáveis e cada fabricante tem uma
forma diferente para configuração.
Como exemplo, segue a configuração do espelhamento de portas em um switch D-
Link DES-3028P, nesse switch há a possibilidade de espelharmos o tráfego de entrada
(Ingress), tráfego de saída (Egress), ou ambos os tráfegos (Both) de uma porta para outra
(Target Port). Dessa forma, a porta alvo receberá todo tráfego das portas espelhadas, no
exemplo da FIGURA 2, a porta 28 receberá os pacotes das portas 5, 12, 17, 21, 23.
 Figura 2 – Espelhamento de portas switch D-Link DES-3028P

1.2 Chamada VoIP sem áudio – STUN desativado

Em uma interligação entre centrais Active IP que se encontram em redes e localidades

diferentes, ou seja, utilizam a internet para se comunicar, a reclamação era de que em um
lado da conversação estava ficando sem áudio.
Foram feitas capturas de tráfego de rede utilizando o software Wireshark para análise
do problema. Para facilitar o estudo do traço no Wireshark foi utilizado o filtro “sip||rtp”,
com isso são apresentados apenas às mensagens SIP, SDP e os pacotes RTP, conforme
FIGURA 3.
 Figura 3 – Filtro sip||rtp no Wireshark

Acessando o fluxo de mensagens da chamada VoIP podemos verificar o que esta

ocorrendo na conversação, conforme FIGURA 4.

Figura 4 – Fluxo de mensagens SIP e RTP

Nesse sistema uma central está localizada em uma rede privada de endereço IP
192.168.100.0/24 e a outra está em uma rede privada de endereço IP 10.0.1.0/24. Essas
redes estão conectadas através da internet, ou seja, o registro VoIP nesse caso acontece
utilizando o endereço IP público da rede de cada central (endereço IP do gateway).
O INVITE está sendo gerado do IP 192.168.100.80 com destino ao usuário 313 do
IP 189.33.22.21 (endereço público da rede de destino). Após o estabelecimento da
sessão SIP, há uma troca de pacotes RTP/RTCP entre os IPs internos 192.168.100.81 e
10.0.1.250, conforme figura anterior, com isso, poderíamos concluir que a conversação
está acontecendo de forma correta, no entanto, se observarmos melhor os pacotes no
estabelecimento da sessão podemos encontrar o problema.
Selecionando a mensagem SDP – 200 OK, que se trata da resposta à solicitação
do INVITE, enviada do IP 189.33.22.21 ao IP 192.168.100.80, conforme FIGURA 5, serão
habilitadas na tela principal do software as informações dessa mensagem, conforme
FIGURA 6.

Figura 5 – Seleção da mensagem SDP – 200 OK

 Figura 6 – Informações da mensagem SDP

No cabeçalho SDP, no campo “Connection Information”, é apresentado o endereço

IP 10.0.1.250, esse campo indica qual é o endereço IP em que deverão ser enviados os
pacotes de áudio, ou seja, essa mensagem informa ao IP 192.168.100.80 que envie os
pacotes RTP ao IP 10.0.1.250. Como se trata de uma interligação entre duas redes
privadas através da internet, uma não tem acesso aos endereços internos da outra, dessa
forma, a central de endereço IP 192.168.100.80 não “enxerga” a rede 10.0.1.0 e por isso
os pacotes RTP não chegam ao destino (mesmo que no fluxo do wireshark os pacotes
parecem ser trocados entre origem e destino).
Esse tipo de “problema” sempre acontecerá quando temos uma interligação entre
redes privadas através da internet, para solucionar tal comportamento nessas
conversações é utilizado o servidor STUN nos equipamentos responsáveis por
estabelecer a chamada, nesse caso, o STUN deve estar ativo nos dois PABXs Active IP.

1.2.1 Servidores STUN

A função do servidor STUN é traduzir o endereço IP local para o endereço IP

público de uma rede, dessa forma, no cabeçalho SDP será informado o endereço IP
público, que possibilitará com que os pacotes RTP cheguem ao destino, já que o
endereço IP público se trata de um endereço roteável na internet.
O servidor STUN é um serviço oferecido na internet e se trata de servidores
capazes de fazer essa tradução de endereços, utilizam a comunicação UDP e porta
padrão 3478.
Alguns dos principais servidores STUN existentes são:
• stun.sipgate.net;
• stun.internetcalls.com;
• stun.ideasip.com;
• stun.xten.com;
• stun.callwithus.com;
• stun.rnktel.com.

No caso da interligação que está sendo analisada, em uma das duas centrais o
STUN estava devidamente ativado e por isso a ligação, para essa extremidade, estava
com o áudio normalmente. Analisando o cabeçalho SDP da mensagem INVITE – SDP
enviada do IP 192.168.100.80, podemos perceber a atuação do servidor STUN na
mensagem, conforme FIGURA 7.

Figura 7 – Informações da mensagem SDP (2)

Nessa mensagem, o campo “Connection Information” é apresentado o endereço IP

189.12.120.223, que é o IP público da rede onde se encontra a central, com esse
endereço IP, a outra extremidade da conversação consegue enviar os pacotes de áudio
de forma correta.
1.2.2 Redirecionamento de portas

Ainda em relação às interligações entre diferentes redes privadas, além do STUN,

é utilizado outro recurso para que os pacotes SIP e RTP saiam da origem e cheguem até
o destino através da internet. Esse recurso é o redirecionamento de portas nos gateways
e firewalls de saída das redes onde estão as centrais Leucotron.
Com o STUN, toda a comunicação acontecerá através dos endereços IPs públicos
e de alguma forma, esses pacotes devem chegar até as centrais que estão na rede local,
para isso, é utilizado uma facilidade existente em roteadores e firewalls chamada de
redirecionamento de portas, isso permite configurar um redirecionamento em que todo o
tráfego que chegue a determinada porta no gateway ou firewall seja redirecionado a um
endereço IP na rede local, conforme FIGURA 8.

Figura 8 – Redirecionamento de portas em roteador

Nas interligações VoIP que utilizam os equipamentos Leucotron as portas

redirecionadas são:
• Porta SIP – porta padrão 5060;
 • Portas RTP/RTCP – portas 6000 até 7000 (dependem do equipamento).

1.3 Chamada VoIP rejeitada

Em outro caso envolvendo problemas em ligações VoIP com equipamentos

Leucotron acontecia das ligações não serem completadas. Nesse caso, com o wireshark
capturando os traços e utilizando o filtro “sip||rtp” nos pacotes capturados, foi fácil
perceber onde estava o problema.
Podemos observar na FIGURA 9, que o INVITE enviado do IP 189.33.22.21 ao
usuário 311 no IP 192.168.100.80 é rejeitado com a mensagem 415 – Unsupported Media
Type e com isso a ligação é cancelada.

Figura 9 – Chamada VoIP rejeitada

Analisando melhor as mensagens SIP podemos notar que o problema está na lista
de codecs disponíveis nas duas extremidades da conversação, pois os tipos de codecs de
uma central não são iguais aos da outra.
Na FIGURA 10 é apresentada a lista de codecs disponíveis no cabeçalho SDP da
central de IP 189.33.22.21, conforme abaixo.

Figura 10 – Lista de codecs

Os codecs habilitados nessa central são: 18 / 4 / 8 / 0. Caso a outra central

possuísse qualquer um desses a chamada seria completada, no entanto, como a outra
central não está com nenhum destes codecs habilitados e a chamada é rejeitada.

1.4 Chamada VoIP completa

Para finalizar as análises em chamadas VoIP será apresentado uma conversação

onde não foi encontrado nenhum problema e alguns pontos importantes serão
destacados.
Considerando todas as condições descritas anteriormente bem sucedidas (STUN,
redirecionamentos, espelhamentos), foi capturado uma conversação VoIP, conforme
FIGURA 11.
 Figura 11 – Fluxo de chamada VoIP completa

A primeira informação importante a ser observada na figura acima é que o INVITE

partiu da central de IP 192.168.100.140 com destino ao usuário 9501 no IP
200.248.217.26, acessando essa mensagem SIP podemos encontrar mais informações
importantes, conforme FIGURA 12.

Figura 12 – Mensagem SIP/SDP

 O campo “Connection Information” indica que a outra extremidade da conversação
deverá enviar os pacotes de áudio ao endereço IP 189.13.171.139 (IP público da rede),
conforme primeiro destaque na figura anterior.
O campo “Media Description” informa que a porta RTP que receberá os pacotes de
áudio é a porta 20000 e os codecs disponíveis nesta central são: 18 / 8 / 0.
Analisando a mensagem SDP – 200 OK enviada da central de IP 200.248.217.26
para o IP 192.168.100.140, conforme FIGURA 13.

Figura 13 – Mensagem SIP/SDP (2)

O campo “Connection Information” indica que os pacotes RTP devem ser enviados
ao endereço IP 200.248.217.26.
No campo “Media Description” informa que a porta RTP que receberá os pacotes
de áudio será a 8330 e essa central possui apenas o codec 18 habilitado.
Acessando a mensagem RTP/RTCP temos mais algumas informações importantes,
conforme FIGURA 14.
 Figura 14 – Mensagem RTP/RTCP

Nessa mensagem podemos observar que os pacotes RTP estão sendo trocados
através das portas UDP 20000 e 8330, e que o codec escolhidos foi o G.729.

No player oferecido pelo wireshark podemos ouvir o áudio da conversação e ainda

obter algumas informações interessantes sobre a sessão VoIP. Na FIGURA 15 é
apresentado o áudio das duas extremidades da chamada, bastando o computador possuir
sistema de áudio para ouvir a ligação. Um ponto interessante é a função de “jitter buffer”
presente no player, conforme destaque na FIGURA 15, isso permite alterar o buffer da
conversação para que se tenha uma qualidade melhor no áudio.
No exemplo a seguir, o “jitter buffer” utilizado é de 30 ms, com esse valor, a
mensagem superior não apresenta nenhuma perda em relação ao jitter, conforme
destaque na figura, o que faz o áudio ficar sem perdas. Já na mensagem inferior, o “jitter
buffer” de 30 ms não é suficiente para deixar a mensagem sem perdas e podemos
observar que a perda em relação ao jitter foi de 8,9%.
Figura 15 – Player com conversação VoIP