Академический Документы
Профессиональный Документы
Культура Документы
DISSERTAO APRESENTADA
AO
INSTITUTO DE MATEMTICA E ESTATSTICA
DA
UNIVERSIDADE DE SO PAULO
PARA
OBTENO DO TTULO
DE
MESTRE EM CINCIAS
Comisso julgadora:
Agradecimentos
Resumo
Abstract
With recent advances in technologies for data transmission and with the
popularization of Internet access via broadband for businesses and home users, IP
telephony has become a fact.
Internet phone service providers also called VoIP providers appeared to
capture this growing market. These companies offer plans with lower rates,
especially for long distance and international calls, since their great advantage is the
fact the use existing communication networks, such as the Internet.
Despite the benefits that VoIP technology has brought, many problems are still
faced by users, because the IP telephony system depends heavily on resources that
are not under the control of applications and equipments responsible for providing
this service.
The VoIPFix project, presented in this dissertation, arose from the need for a
tool that complements the others in the analysis of computer networks and IP
telephony. Professionals working in this market sometimes have limited knowledge of
the technologies and protocols of VoIP equipments, because they are something
very specific.
VoIPFix was built with the single purpose of being an efficient and unique tool
for VoIP, with features required to support the network administrator to observe and
diagnose problems in IP telephony.
The work presented here includes an investigation of related tools, the
principles used in the construction of the VoIPFix architecture, its implementation
details and tests of correctness and performance of its analysis algorithms.
Sumrio
Lista de Figuras ...................................................................................................................... vii
Lista de Tabelas ..................................................................................................................... viii
1
Introduo .......................................................................................................................... 1
1.1
1.2
1.3
SIP................................................................................................................................ 5
2.1.1
2.2
SDP ............................................................................................................................ 11
2.3
RTP ............................................................................................................................ 14
2.4
2.4.1
2.4.2
2.4.3
2.4.4
Wireshark ................................................................................................................... 20
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
3.3
VoIPFix ............................................................................................................................. 24
4.1
Arquitetura.................................................................................................................. 25
4.1.2
Interpretador ....................................................................................................... 27
4.1.3
4.1.4
Analisador ........................................................................................................... 29
4.1.5
GUI ...................................................................................................................... 29
4.1.6
Gerenciador ........................................................................................................ 30
4.2
Funcionalidades ......................................................................................................... 30
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
4.2.10
4.2.11
4.2.12
4.2.13
4.2.14
4.2.15
4.2.16
4.2.17
4.2.18
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.4.8
4.4.9
4.4.10
4.4.11
4.4.12
4.4.15
4.5
4.5.1
4.5.2
4.6
4.7
4.7.1
4.7.2
4.7.3
4.7.4
4.7.5
Concluso ........................................................................................................................ 89
5.1
Bibliografia ....................................................................................................................... 92
Lista de Figuras
Figura 1 Exemplo de mensagem de pedido de registro. ......................................... 7
Figura 2 Exemplo de mensagem de abertura de sesso......................................... 9
Figura 3 Cabealho RTP. ...................................................................................... 14
Figura 4 Fluxo de mensagens para pedido de registro. ......................................... 16
Figura 5 Fluxo de mensagens para estabelecimento de sesso. .......................... 17
Figura 6 Finalizao de sesso. ............................................................................ 18
Figura 7 Cancelamento de sesso. ....................................................................... 19
Figura 8 Arquitetura do VoIPFix. ........................................................................... 26
Figura 9 Interface grfica do VoIPFix. ................................................................... 30
Figura 10 Tela para iniciar captura de pacotes. ..................................................... 31
Figura 11 Analisando pacotes em mais de um thread. .......................................... 33
Figura 12 Tela com a lista de transaes. ............................................................. 35
Figura 13 Tela com detalhes dos pacotes. ............................................................ 37
Figura 14 Grfico com transao de chamada. ..................................................... 38
Figura 15 Grfico com transao de registro. ........................................................ 40
Figura 16 Grfico com transao de registro e chamada. ..................................... 41
Figura 17 Grfico com nmero de transaes. ...................................................... 42
Figura 18 Grfico com estatsticas de fechamento de chamadas. ......................... 43
Figura 19 Grfico com o nmero de chamadas do usurio. .................................. 45
Figura 20 Grfico com nmero de chamadas para o usurio. ............................... 46
Figura 21 Grfico com nmero de chamadas do endereo. .................................. 47
Figura 22 Grfico com nmero de chamadas para o endereo. ............................ 48
Figura 23 Grfico com estatsticas de pedidos de registro. ................................... 49
Figura 24 Grfico com nmero de registros do usurio. ........................................ 50
Figura 25 Grfico com nmero de registros do endereo. ..................................... 51
Figura 26 Grfico com nmero de registros para o endereo. ............................... 51
Figura 27 Tela de filtro de transaes. .................................................................. 53
Figura 28 Relatrio de jitter, perda de pacotes e erro de sequncia. ..................... 54
Figura 29 Deteco de momentos de ausncia de fluxo de udio......................... 56
Figura 30 Deteco de ausncia de fluxo RTP num sentido. ................................ 56
Figura 31 Relatrio com problema de sinalizao. ................................................ 58
Figura 32 Deteco de problema de fechamento de chamada. ............................ 59
Figura 33 Informativo com problemas de transaes. ........................................... 60
Figura 34 Reprodutor de udio de chamadas. ...................................................... 61
Figura 35 Tela do aplicativo X-Lite. ....................................................................... 63
Figura 36 Interpretao de pacotes em mltiplas tarefas. ..................................... 69
Figura 37 Anlise em mltiplas tarefas para formao de transaes ................... 70
Figura 38 Grfico de problema de fechamento de chamada. Caso 1. ................... 77
Figura 39 Grfico de problema de fechamento de chamada. Caso 2. ................... 78
Lista de Tabelas
Tabela 1 Milhares de assinantes de VoIP das maiores operadoras brasileiras. ...... 2
Tabela 2 Tipos de mensagens de resposta. .......................................................... 11
Tabela 3 Campos do SDP. .................................................................................... 12
Tabela 4 Teste de correo: jitter mximo. ........................................................... 80
Tabela 5 Teste de correo: perda de pacotes. .................................................... 80
Tabela 6 Informaes sobre mquinas utilizadas nos testes. ................................ 81
Tabela 7 Tempo de abertura de arquivo com 50 MB. ............................................ 83
Tabela 8 Tempo de abertura de arquivo com 100 MB. .......................................... 84
Tabela 9 Tempo de abertura de arquivo com 150 MB. .......................................... 84
Tabela 10 Tempo de abertura de arquivo com 200 MB. ........................................ 84
Tabela 11 Teste de desempenho em mquina de um ncleo. .............................. 85
Tabela 12 Comparativo de funcionalidades com Wireshark e Cace Pilot. ............. 86
1 Introduo
As primeiras aplicaes de telefonia IP apareceram de forma mais concreta
no final da dcada de 1990, quando comearam a se desenvolver aplicativos para
computadores, capazes de transportar a voz codificada e transmitida em pacotes
[JOH04]. Com esses programas para telefonia IP, era possvel que duas pessoas se
comunicassem atravs da Internet, embora com uma qualidade de voz ainda muito
precria.
Alguns protocolos de sinalizao, como o H.323 [ITU09] e o MEGACO
[CUE00], foram desenvolvidos para a comunicao entre os sistemas de telefonia IP
para que pudessem trocar informaes e estabelecer uma chamada entre dois
computadores. Surgia ento a tecnologia chamada de VoIP (Voice over the Internet
Protocol).
No incio, o grande problema para as aplicaes e equipamentos de VoIP era
com relao compresso e transmisso da voz digitalizada. Os pacotes que
carregavam essa voz compartilhavam os mesmos meios de transmisso ocupados
pelo trfego de dados na Internet, de uma forma completamente diferente da
telefonia analgica, que conta com um circuito dedicado entre os interlocutores.
Porm, apesar desses e de outros problemas, era evidente que a tecnologia de VoIP
traria muitos benefcios para o mundo da telefonia, principalmente no que diz
respeito reduo do custo das chamadas.
Em 1997, o IETF (Internet Engineering Task Force) [IETF] comeou a
desenvolver outro protocolo de sinalizao, que poderia ser utilizado para telefonia
IP e tambm para outros tipos de aplicaes. Esse protocolo, que recebeu o nome
de SIP (Session Initiation Protocol), atualmente o mais utilizado pelos aplicativos e
equipamentos de telefonia IP. A segunda e atual verso revisada foi publicada em
junho de 2002 como sendo a RFC3261 [ROS02a].
Os protocolos como o SIP so utilizados para iniciar, controlar e encerrar
sesses, fazendo apenas o trabalho de sinalizao entre os envolvidos, no lidando
com questes de voz quando se trata de chamadas. Para tal, existem os protocolos
de transporte em tempo real que so utilizados para carregar a voz digitalizada
atravs da rede de comunicao de dados. A tcnica de transmitir voz codificada por
uma rede de pacotes teve incio com experimentos por volta de 1970 [PER03].
Porm o protocolo para transporte de voz mais utilizado, desde o incio da telefonia
IP at hoje, o RTP (Real-Time Transport Protocol) [SCH03] desenvolvido tambm
pelo IETF no perodo entre 1992 e 1996, baseado em outros protocolos com o
mesmo objetivo.
O VoIPFix j utilizado como ferramenta, pelo prprio autor desta
dissertao, que trabalha na empresa Leucotron Telecom, desenvolvendo
equipamentos de comunicao privada (centrais PBX) e solues de telefonia IP,
substituindo o Wireshark em todas as situaes como:
1.1
O Mercado de Telefonia IP
Milhares
2008
2009
2010
Embratel
1802
2557
2765
GVT
100
147
176
3
Esses dados levam em considerao somente os assinantes pagantes do
servio de telefonia IP das operadoras citadas. Ainda h um nmero grande de
usurios em outras operadoras e outros servios privados que so utilizados para
realizar interligao entre centrais de uma mesma empresa, escritrios e
residncias. Porm, evidente o crescimento nos ltimos anos de usurios
pagantes.
Alm dessas operadoras, ainda h o servio de telefonia IP oferecido pelo
Skype, que, alm de outras funcionalidades, permite que usurios utilizem a Internet
para realizar ligaes para telefones fixos, mveis e para outros usurios, com
preos competitivos. Esse trabalho no cita maiores detalhes sobre essa aplicao,
pois o Skype utiliza um protocolo de sinalizao proprietrio [BS06].
1.2
1.3
Objetivos do Trabalho
Este trabalho tem os seguintes objetivos:
2 Protocolos de Telefonia IP
A tecnologia de VoIP utiliza-se de dois tipos bsicos de protocolos para o seu
funcionamento:
2.1
SIP
6
para dar continuidade ao atendimento dessa requisio. Na especificao original do
SIP, seis mtodos esto definidos:
7
A seguir, um detalhamento das duas mensagens de requisio de maior
relevncia.
9
O exemplo a seguir de uma mensagem originada pelo usurio de nome 200
que deseja estabelecer uma sesso de voz com o usurio de nome 201.
A Figura 2 contm um exemplo de mensagem para abertura de sesso.
No caso de um sistema de telefonia, os nomes, que esto nos campos From
e To, so os nmeros dos telefones dos usurios. No exemplo abaixo, eles
aparecem entre sip: e o @ e so os nmeros 200 e 201. Esses nmeros fazem
parte do plano de numerao e podem ser discados por qualquer outro telefone num
sistema hbrido (composto por telefones IP e telefones analgicos convencionais).
Regularmente, so apenas dgitos discveis de um teclado de telefone
convencional, mas podem ser compostos por caracteres alfanumricos.
A informao que aparece logo aps o nome do campo From chamada de
display name, e no exemplo utilizado na Figura 2 abaixo o PCS200, que
representa simplesmente uma identificao a ser exibida no destino. Normalmente,
o UAS que recebe a requisio utiliza essa informao para exibi-la em um visor.
10
O cabealho da mensagem de INVITE, que vai da primeira linha at
Content-Length, tem alguns campos parecidos com o da mensagem de
REGISTER, por exemplo, Via, Contact, Call-ID, Max-Forwards e UserAgent. O contedo desses campos so parecidos com o da mensagem de registro,
mas alguns deles tm utilidades diferentes, pois o UAS que recebe a mensagem
utiliza as informaes para encaminhar a ligao a um destino, ou mesmo atender e
dar continuidade ao processo de abertura da sesso.
A primeira linha, que a chamada linha de requisio, contm o mtodo
(INVITE) que invocado no UAS, alm do nmero do destino da requisio (201) e
o endereo IP onde ele est registrado (192.168.1.35).
Diferente da mensagem de registro, o campo To contm a informao de qual
usurio a requisio tem como alvo e tambm o endereo IP do servidor de
encaminhamento.
Os campos Content-Type e Content-Length contm, respectivamente, o
tipo e o tamanho da informao que est no corpo da mensagem.
Nesse tipo de mensagem, os campos obrigatrios so: Call-ID, Contact,
Cseq, From, Max-Forwards, To e Via.
11
Classe Descrio
Ao
1xx
Informativa
2xx
Sucesso
3xx
4xx
5xx
Falha do servidor
6xx
Falha global
2.2
SDP
12
Campo Nome
Obrigatrio
v=
Verso do protocolo
Sim
o=
Sim
s=
Nome da sesso
Sim
i=
Informao da sesso
No
u=
URI
No
e=
Endereo de e-mail
No
p=
Nmero do telefone
No
c=
Informao da conexo
Sim
b=
No
t=
Sim
r=
Nmero de repeties
No
z=
No
k=
Chave de criptografia
No
a=
No
m=
Informaes da mdia
No
a=
No
13
a) Criador da sesso: o campo o contm informaes sobre o originador. utilizado
unicamente como um identificador da sesso. O campo formado pelos seguintes
parmetros:
o= username session-id version network-type address-type address
O username contm o usurio do originador. O parmetro session-id pode ser
um nmero aleatrio ou a hora atual retornada pelo Network Time Protocol (NTP),
para garantir um nmero nico. O version um campo numrico que
incrementado a cada mudana na sesso e tambm recomendado que seja
utilizado o valor retornado pelo NTP. O network-type tem sempre o valor IN para
Internet. O address-type pode ser IP4, para endereos IPv4; ou IP6, para IPv6. O
address contm o endereo IP do criador da sesso.
b) Informao da conexo: o campo c contm dados sobre a conexo de mdia e
tem o seguinte formato:
c=network-type address-type connection-address
Os parmetros network-type e address-type tm o mesmo significado que no
campo criador da sesso, mas as informaes aqui so relativas conexo de
mdia. O campo connection-address contm o endereo IP para onde os pacotes do
fluxo de mdia devem ser enviados. importante ressaltar que o endereo IP desse
campo pode no ter o mesmo valor do endereo IP que est no campo o, por
exemplo, quando o criador da sesso, que quem gera a sinalizao, est
localizado num IP diferente do gateway que ir receber os pacotes do fluxo de mdia.
c) Informaes da mdia: o campo m contm informaes sobre o tipo de mdia da
sesso e tem o seguinte formato:
m=media port transport format-list
O parmetro media pode ser audio, video, application, data, telephone-event
ou control e indica qual o tipo de mdia que ser usada na sesso descrita. O
parmetro port contm o nmero da porta no qual os pacotes do fluxo de mdia
devem ser enviados. O transport contm o protocolo de transporte e pode ser
RTP/AVP (real-time transport protocol/audio video profiles) ou UDP. O ltimo
parmetro, format-list, contm os tipos de codificadores utilizados para transporte do
fluxo de mdia. Mais de um codificador pode ser definido, sugerindo quais os tipos de
codificadores que o originador da sesso aceita.
d) Atributos da mdia: o campo a contm atributos da sesso de mdia. Esse campo
pode ser usado para descrever mais detalhes sobre os codificadores informados no
campo m.
14
2.3
RTP
bit offset
0
32
64
96
96 + 32*CC
128 + 32*CC
0-1
V
2
P
3
X
4-7
CC
8
M
9-15
16-31
PT
Sequence Number
Timestamp
SSRC identifier
CSRC identifiers
Profile-specific extension
Extension header length
header ID
Extension header
Figura 3 Cabealho RTP.
a) Verso (V): dois bits que indicam a verso do protocolo. A verso atual dois.
b) Enchimento (P): se est com valor um, significa que h octetos de enchimento
adicionados no fim do pacote para torn-lo com um comprimento fixo. Esse campo
normalmente utilizado quando se usa fluxo com criptografia.
c) Extenso (X): se est com valor um, h extenses adicionais no cabealho.
Extenses so definidas por certos tipos de dados.
d) Contador CSRC (CC): campo com quatro bits que contm o nmero de
identificadores da fonte de contribuio presente no cabealho. utilizado somente
por um misturador que coleta vrios fluxos RTP e gera somente um, como acontece
quando h uma conferncia.
e) Marcador (M): bit utilizado para indicar o incio da transmisso de um novo quadro
no vdeo ou a retomada de uma fala, quando se utiliza supresso de silncio.
15
f) Tipo dos dados (PT): campo com sete bits, indica o codificador que utilizado
para transportar os dados aps o cabealho. O valor dele coincide com o codificador
que foi negociado no SDP.
g) Nmero de sequncia (Sequence Number): campo com 16 bits, incrementado a
cada pacote RTP que enviado. utilizado pelo receptor para detectar a falta de
um pacote ou a chegada em ordem incorreta.
h) Marcador de tempo (TimeStamp): campo de 32 bits que indica um tempo relativo
quando o dado foi amostrado. Permite que o receptor retire os atrasos dos pacotes e
reproduza o fluxo no tempo correto, considerando que haja uma fila de
armazenagem suficiente para os pacotes atrasados.
i) Identificador da fonte de sincronizao (SSRCI): campo de 32 bits que identifica o
gerador de um fluxo RTP. No incio da transmisso dos pacotes RTP, cada gerador
escolhe aleatoriamente um nmero para ser transmitido. Caso acontea
coincidncia na escolha do valor do identificador da fonte de sincronizao, um novo
nmero escolhido, at que haja somente identificadores nicos.
j) Identificador da fonte de contribuio (CSRC): pode haver de zero a 15 instncias
desse campo de 32 bits no cabealho. A quantidade informada no campo contador
de CSRC. S existe quando os pacotes so transmitidos por um misturador.
k) Dados: campo onde a informao de voz ou vdeo transportada, de acordo com
o codificador que foi escolhido durante a negociao da sesso. Seu tamanho de
acordo com o codificador que utilizado.
O RTP permite que haja deteco de pacotes perdidos analisando intervalos
no nmero de sequncia, assim como pacotes recebidos fora de ordem, mas deixa o
decodificador lidar com esses problemas durante a reproduo do fluxo de vdeo ou
voz. Por exemplo, um decodificador de vdeo pode compensar a falta de alguns
quadros de imagem, repetindo o ltimo quadro de vdeo exibido, enquanto um
decodificador de udio pode inserir o rudo de fundo captado na ligao.
Variaes no atraso dos pacotes podem ser detectadas analisando-se cada
marcador de tempo presente. No caso de um codificador com taxa de transmisso
contnua, como o caso do PCM, o incremento do valor do marcador de tempo
linear. A marcao de tempo de amostragem de cada pacote serve para que o
decodificador a reproduza os dados dos pacotes em intervalos corretos.
2.4
16
tempos envolvidos entre uma mensagem e outra. Normalmente, um aplicativo de
anlise do protocolo SIP apenas informa qual foi o tempo entre uma mensagem e
outra, no ressaltando os problemas que porventura podem acontecer quando uma
mensagem chega num tempo fora da faixa prevista na RFC.
A RFC3261 sugere que para construo de um agente SIP, uma mquina de
estado deve controlar toda a transao de acordo com as mensagens que so
recebidas ou enviadas e tambm os tempos envolvidos entre essas mensagens. A
cada mensagem enviada por um agente, sua mquina de estado muda para outro
passo e, dependendo da mensagem enviada, um temporizador iniciado. Caso
esse temporizador chegue ao fim, a mquina de estado do agente vai para outro
passo e poder enviar uma mensagem solicitando o cancelamento da transao. Se
um agente recebe a mensagem de resposta mensagem enviada, a mquina vai
para outro estado, podendo paralisar o temporizador iniciado. Toda essa anlise
depende do tipo da transao e do estado em que ela se encontra.
A anlise das temporizaes para verificar se a sinalizao trocada entre dois
agentes est ou no dentro das recomendaes muito complexa, pois envolve
muitos parmetros e estados das transaes entre esses dois agentes, por isso no
ser objeto de estudo deste trabalho.
UAC
UAS
Register
100 Trying
401 Unauthorized
Register
100 Trying
200 OK
Mensagem
M1
M2
M3
M4
M5
M6
17
M3: neste exemplo, o servidor necessita que o usurio se autentique para que
o pedido de registro seja aceito. Essa mensagem contm uma chave para
que o UAC repita o pedido de registro com o seu usurio e senha
criptografados segundo essa chave.
M4: um novo pedido de registro gerado com a autenticao solicitada pelo
servidor. Nessa mensagem o UAC tambm pode informar qual o tempo de
validade do pedido de registro.
M5: idem a M2.
M6: o servidor aceita o pedido de registro, finalizando a transao.
UAC
UAS
Mensagem
M1
M2
M3
M4
100 Trying
M5
180 Ringing
M6
M7
ACK
M8
RTP
M9
RTP
M10
18
UAS
Mensagem
M1
M2
M3
M4
100 Trying
M5
180 Ringing
M6
M7
ACK
M8
RTP
M9
RTP
M10
BYE
M11
OK
M12
19
UAS
Invite com SDP
Mensagem
M1
100 Trying
M2
180 Ringing
M3
Cancel
M4
M5
200 OK
M6
ACK
M7
20
Trabalhos Relacionados
Wireshark
21
3.1.2 Visualizao das transaes de chamada
Com o recurso da visualizao das chamadas, possvel verificar de forma
resumida todas as transaes de chamada que ocorreram, dando uma viso mais
ampla das ligaes que aconteceram durante o perodo de captura.
Nessa tela, possvel ter as seguintes informaes:
22
Para chamadas com outros codificadores, pode-se utilizar a facilidade do
Wireshark de extrao do payload dos pacotes RTP para serem salvos em arquivo.
Essa informao pode ser convertida, atravs de outros aplicativos, para arquivos de
udio com formatos reconhecidos por tocadores padres.
3.2
Cace Pilot
O Cace Pilot [CACE] um aplicativo comercial com foco maior para anlise
de desempenho de redes, com alguns recursos interessantes para o mundo de
VoIP. Ele foi feito pelo mesma empresa desenvolvedora do Wireshark.
Esse aplicativo tem objetivos bem diferentes do Wireshark, j que est mais
voltado a apresentar resultados relativos ao consumo de rede, qualidade nas
chamadas, nmero de sucessos e insucessos das transaes, alm de relatrios
indicando mquinas com maior utilizao e trfego de VoIP.
A seguir, uma lista resumida das caractersticas principais referentes anlise
de pacotes de VoIP:
23
Como um aplicativo com grandes recursos para anlise de trfego de vrios
outros protocolos, ele possui facilidades interessantes para isolar pontos ou
chamadas especficas. Essa anlise isolada permite verificar uma possvel causa de
problemas, como ligaes com baixa qualidade, fazendo uma checagem para
verificar como est o trfego de pacotes de outros protocolos no momento exato em
que ocorreu o problema.
Apesar de muito poderoso, o Cace Pilot no um aplicativo no qual
possvel trabalhar de forma isolada, pois quando se torna necessrio analisar os
campos dos pacotes ou inteirar-se da sequncia de mensagens, necessrio lanar
mo do Wireshark.
Uma grande vantagem do Cace Pilot permitir a o exame mais rpido de
arquivos de captura muito grandes, da ordem de centenas de megabytes. Isso
possvel j que esse aplicativo possui mecanismos de anlise mais eficientes em
computadores multicore.
Pode-se dizer que as demais caractersticas do Cace Pilot so supridas pelo
Wireshark. Caso o usurio ainda necessite de ferramentas de observao mais
profunda em mensagens, campos, temporizaes entre mensagens e visualizador
de transaes SIP, esse deve ainda utilizar o Wireshark. O Cace Pilot mais voltado
para anlise do servio e sua qualidade do que profundidade de problemas em nvel
de protocolo.
3.3
24
VoIPFix
25
4.1
Arquitetura
26
4.1.1 Capturador
Este mdulo responsvel pela coleta de pacotes, seja ela feita atravs de
uma interface de rede ou por arquivos salvos em disco, e tambm pelo salvamento
de pacotes em arquivos. Essas duas tarefas so implementadas atravs de
bibliotecas especficas para esse tipo de aplicao: WinpCap, para ambiente
Windows, e libpcap, para ambiente GNU/Linux.
As tarefas executadas por esse mdulo so:
Listagem das interfaces de rede do sistema, para que possam ser exibidas
pela interface grfica, permitindo que o usurio escolha a mais adequada;
recebimento de instruo de abertura de uma interface de rede e captura dos
pacotes atravs dela;
captura de pacotes atravs de uma interface de rede, que pode ser feita em
modo promscuo, ou seja, captura todos os pacotes que passarem
fisicamente pela interface de rede selecionada, mesmo que no tenham como
destino essa interface;
aplicao dos filtros escolhidos pelo usurio para capturar somente pacotes
de interesse (endereo IP, porta, etc.);
recebimento de instruo para abertura de arquivos salvos em disco;
salvamento de listas de pacotes em disco, mediante instruo da interface
grfica de usurio;
27
Essas tarefas compem a base da aplicao, no que diz respeito coleta das
informaes necessrias para o funcionamento do VoIPFix.
O mdulo Capturador contm particularidades em relao ao sistema
operacional que est sendo utilizado, j que est em contato com bibliotecas
diferentes para cada ambiente. Porm, a forma de utilizao das bibliotecas de
captura bem semelhante, no tendo nenhum impacto no desempenho ou perda de
funcionalidade de um sistema para o outro.
A interface de interao desse mdulo com os de hierarquia superior fazem
com que ele seja visto de forma independente do tipo de sistema operacional
utilizado.
O Capturador possui apenas uma thread de execuo, pois no possvel
abrir um arquivo utilizando tarefas concorrentes, visando a economia de tempo,
como feito em outros mdulos do VoIPFix.
Quando os dados esto sendo capturados atravs de uma interface de rede,
os pacotes so armazenados em memria e no em arquivos temporrios em disco.
4.1.2 Interpretador
Como o prprio nome diz, neste mdulo os pacotes provenientes de uma
interface de rede ou de um arquivo aberto do disco so selecionados e
interpretados, visando extrair somente as informaes de interesse para os demais
mdulos da hierarquia superior da aplicao.
A forma de trabalho do Interpretador depende do comportamento do resto do
sistema, que pode estar sendo utilizado para capturar pacotes de uma interface de
rede ou comandado a abrir um ou mais arquivos do disco. Porm,
independentemente do modo de trabalho, ele ir executar os seguintes
procedimentos quando um pacote recebido:
28
29
4.1.4 Analisador
O mdulo analisador realiza as tarefas de maior interesse ao usurio, como
por exemplo:
4.1.5 GUI
A interface grfica de usurio (GUI) foi desenvolvida de modo a atingir os
seguintes objetivos principais:
30
4.1.6 Gerenciador
O gerenciador, como o prprio nome diz, cuida do controle de todo o
funcionamento da aplicao. Algumas de suas funes so:
4.2
Funcionalidades
31
algumas de suas funcionalidades formam a base para que ele seja autocontido e
oferea recursos necessrios para o funcionamento de caractersticas inovadoras e
eficientes em relao a outras ferramentas desse tipo.
A seguir, o detalhamento de cada uma das funcionalidades do VoIPFix,
partindo das caractersticas de base, at as mais sofisticadas e inovadoras. A
descrio traz o motivo de sua existncia dentro da aplicao e o que ela realmente
faz.
b) Funcionamento:
O VoIPFix realiza a captura de todos os pacotes de uma determinada
interface de rede, permitindo o salvamento em arquivos, que podero ser abertos
para uma anlise posterior pelo usurio. A captura ainda pode ser parametrizada
para filtrar os pacotes, segundo informaes como:
protocolo de transporte;
32
Os componentes dessa tela so:
33
34
lento, uma vez que o tamanho do arquivo pode ser controlado de tal forma a
somente ter dimenses apropriadas para a mquina de anlise. Porm, isso traz
algumas dificuldades para o usurio, como, por exemplo, a existncia de transaes
que comeam em um arquivo e s so finalizadas no arquivo gravado na sequncia.
Atualmente, as ferramentas de captura possuem uma funcionalidade que permite
mesclar dois ou mais arquivos, porm, isso torna a anlise ainda mais lenta, j que
essa funo gera um arquivo ainda maior.
b) Funcionamento:
Com o VoIPFix, o usurio pode escolher a opo de abrir arquivos gravados
sequencialmente, atravs do menu Arquivo Abrir Sequencial. O comando, faz a
ferramenta abrir todos os arquivos selecionados de uma s vez, dando a sensao
ao usurio de que ele est abrindo somente um arquivo contendo todas as
informaes. No feito nenhum processo de mescla, nem a gerao de um
arquivo temporrio contendo os demais.
Obviamente, o tempo de processamento do conjunto de arquivos
proporcional ao tamanho dos dados, porm, no acontecem os problemas gerados
pelo processo de salvamento de arquivo de forma sequencial. Alm disso, o usurio
pode realizar a anlise, sem ter o problema de encontrar parte de uma transao em
outro arquivo e ter de repetir o processo inteiro novamente.
Todas as ferramentas do VoIPFix funcionam normalmente para esse tipo de
situao.
35
36
Outras funes so acionadas a partir dessa tela, so elas:
37
38
4.2.7 Exibio de grfico detalhado de transaes
a) Necessidade:
O agrupamento das mensagens SIP e RTP em uma lista de transaes
facilita muito o trabalho do usurio, porm necessrio uma forma grfica de exibir
essas requisies, para facilitar a localizao e o entendimento do usurio.
b) Funcionamento:
Aps o usurio exibir a lista de transaes desejadas, ele pode selecionar
uma ou mais transaes para que elas possam ser exibidas em grficos, da forma
como mostrado nas figuras da Seo 2.4.
Com essa ferramenta, o usurio pode fazer uma anlise em um nvel mais
elevado, podendo ainda clicar em uma mensagem especfica e exibir seus campos e
seus respectivos valores na tela com a lista de pacotes da transao.
Muitos dos problemas no apontados pelo VoIPFix podero ser descobertos
por um usurio com bons conhecimentos de protocolos de VoIP, atravs desse
grfico.
A Figura 14 um exemplo dessa facilidade.
39
Essa tela contm informaes completas sobre a troca de mensagens e fluxo
de mdia entre os participantes da chamada. Com ela, o usurio pode identificar
exatamente as mquinas participantes da transao, seus endereos IP, portas e
tipo de codificador utilizado no fluxo de voz, que representado apenas com uma
seta no sentido em que ela acontece, j que so muitos pacotes.
No caso apresentado acima, o cliente que gera a requisio da chamada o
que possui o endereo IP 192.168.6.131 e o servidor que aceita o pedido o que
possui o endereo IP 192.168.0.78, que somente tratas as mensagens de
sinalizao. O dispositivo de rede com o endereo IP 192.168.0.79 um media
gateway responsvel por tratar os pacotes de voz do servidor.
Ainda possvel observar de maneira mais amigvel a troca de mensagens
entre os participantes da transao, identificando a sequncia de ocorrncia dessas
mensagens, os tempos entre cada uma delas, as mensagens de requisio e os
cdigos das mensagens de resposta.
Com esse grfico e a tela de lista de pacotes abertas, clicando em qualquer
mensagem SIP do grfico, ser marcado e exibido o pacote correspondente na tela
de lista, permitindo ao usurio localizar rapidamente a informao de interesse.
Quando clica-se na seta que corresponde ao fluxo RTP, ser exibido o primeiro
pacote desse fluxo detectado pela ferramenta. Essas duas telas associadas
permitem que o usurio faa uma anlise muito profunda sobre a transao
desejada.
A Figura 15, mostra uma transao de registro.
40
41
b) Funcionamento:
O VoIPFix contabiliza o nmero de transaes de INVITE, REGISTER,
OPTIONS e NOTIFY, que so as mais comuns de acontecerem num sistema de
telefonia IP, e exibe um grfico como o da Figura 17.
42
43
44
45
Com esse tipo de grfico, o analista pode observar a utilizao do sistema por
usurio, identificando quantas ligaes cada um deles originou no intervalo de tempo
de anlise.
A Figura 20 mostra o grfico com as estatsticas de chamadas com destino
aos usurios, onde a informao da primeira coluna o nmero do usurio receptor,
a segunda a porcentagem de ligaes recebidas em relao ao total e a terceira
o nmero absoluto de chamadas.
46
47
48
49
50
b) Funcionamento:
O VoIPFix, na mesma janela de grficos com estatsticas, exibe as seguintes
informaes relativas requisies de registro:
51
52
No grfico com o nmero de registros para os endereos IP, possvel
observar se os servidores esto com uma carga excessiva de pedidos durante o
intervalo de tempo de captura realizado.
Determinar a quantidade mxima de requisies suportada por um servidor
de registro no uma tarefa complexa, pois existem vrios aplicativos gratuitos que
realizam esse tipo de ensaio. Dependendo da estrutura de hardware e do software
de um servidor, esse nmero pode chegar a centenas ou at milhares de
requisies por segundo, mesmo em um equipamento de pequeno porte.
A preocupao com os grficos listados nessa seo no se deve apenas aos
servidores de registro, mas tambm ao consumo desnecessrio de rede, pois no
h necessidade de pedidos em curtos intervalos de tempo de um mesmo usurio, a
no ser que ele esteja em um dispositivo mvel que troca de rede vrias vezes num
intervalo de tempo pequeno.
Tipo de transao;
horrio de incio;
endereo IP de origem;
endereo IP de destino;
usurio de origem;
usurio de destino;
estado de finalizao da transao.
A Figura 27 mostra a tela utilizada para configurao do filtro:
53
54
A Figura 28 mostra um trecho do relatrio, onde exibido o jitter, a perda de
pacotes e os erros de sequncia de trs chamadas.
Nmero da transao;
horrio de incio;
horrio de finalizao;
tipo da transao;
codificador de udio, em transaes de chamada;
endereo IP de origem;
usurio origem que solicitou a requisio;
endereo IP de destino;
usurio destino;
estado de finalizao da transao;
durao em transaes de chamada;
jitter mdio, em segundos, do fluxo de udio do originador, em transaes de
chamada;
jitter mximo, em segundos, do fluxo de udio do originador, em transaes
de chamada;
perda de pacotes do fluxo de udio do originador, em transaes de
chamada;
erros de sequncia do fluxo de udio do originador, em transaes de
chamada;
jitter mdio, em segundos, do fluxo de udio do receptor, em transaes de
chamada;
jitter mximo, em segundos, do fluxo de udio do receptor, em transaes de
chamada;
perda de pacotes do fluxo de udio do receptor, em transaes de chamada;
erros de sequncia do fluxo de udio do receptor, em transaes de
chamada.
55
anlise das mensagens de sinalizao, que no passam de algumas unidades, a
quantidade dos pacotes de voz muito grande, o que dificulta uma anlise criteriosa
para descobrir pontos de picotes ou ausncia significativa de udio.
b) Funcionamento:
O VoIPFix capaz de identificar a mudez total ou parcial atravs da deteco
da ausncia de pacotes RTP em um ou em ambos os sentidos. Os motivos que
levam a esse acontecimento podem ser vrios, mas qualquer um deles pode ser
detectado, uma vez que a interrupo do fluxo de pacotes, quando acontece de
forma intencional, sinalizada atravs de um bit dentro do cabealho RTP. Um dos
motivos para o acontecimento desse fato quando um dos sistemas possui
mecanismos de deteco automtica de voz para interrupo do fluxo em momentos
de silncio.
A deteco de falta de udio por ausncia de pacotes RTP s poder ser
considerada vlida se alguns dos pacotes do fluxo, em pelo menos um sentido,
puderem ser capturados no incio da chamada. Nos casos onde houve somente a
captura dos pacotes de sinalizao, sem nenhum pacote do fluxo RTP dessa
transao, no ser possvel diagnosticar problemas como esse.
Na mesma tela que exibe o relatrio com informaes de jitter, o usurio pode
ter um diagnstico do fluxo de udio da chamada.
O VoIPFix sinaliza na coluna Codificador, colorindo o campo da transao
para problemas de fluxo RTP, da seguinte forma:
informativas,
no
56
57
4.2.16 Deteco de transaes com erros de sinalizao
a) Necessidade:
Erros de sinalizao so os casos mais difceis de serem detectados por uma
ferramenta puramente de anlise de pacotes, pois o protocolo SIP complexo e
extenso.
b) Funcionamento:
A proposta do trabalho foi fazer com que sejam cobertos alguns casos mais
comuns, mas que exijam um conhecimento mnimo de SIP pelo usurio operador do
VoIPFix.
Como dito anteriormente, embora os equipamentos de telefonia IP sigam os
padres propostos pelas recomendaes padronizadas, ainda h margem para
interpretaes diferentes, o que causa incompatibilidade entre equipamentos de
fabricantes diferentes. Ainda, nem todos os casos e estados so testados de forma
exaustiva, a ponto de cobrir qualquer tipo de situao do protocolo de sinalizao.
Os casos que foram cobertos pelo VoIPFix so fundamentados na
especificao da ETSI [MTS07], criada para testes de conformidade do
comportamento de equipamentos de telefonia IP baseados em SIP.
O VoIPFix alerta o usurio analisador sobre a deteco de problemas ou
erros de sinalizao, colorindo o campo Tipo da transao da seguinte forma:
58
59
b) Funcionamento:
O VoIPFix trata de casos, evidenciando as transaes que no puderam ser
completadas, por situaes como:
60
61
4.3
62
4.3.3 Interpretador de mensagens SIP
Para cumprir os objetivos propostos, o VoIPFix teve de ser capaz de
interpretar todas as mensagens SIP que estavam nos pacotes de rede capturados.
Para isso foi utilizado um interpretador que recebe o texto de uma mensagem, faz a
anlise e identifica todos os campos e valores do cabealho e corpo de uma
mensagem SIP.
A biblioteca utilizada para servir de interpretador a oSIP [OSIP], que
compatvel com o padro proposto pela RFC3261.
Com a oSIP, foi possvel transformar as mensagens SIP em estruturas que
traduzem cada campo e seus valores. Sendo assim, depois de ter sido interpretada,
possvel identificar os mtodos de cada uma, as mensagens de cada transao, os
parmetros de negociao de sesso e todos os outros parmetros que podem
aparecer no SIP.
63
b) Telefone IP Chatty:
O Chatty [CHAT] um telefone IP que faz a mesma funo que o X-Lite,
porm no necessita de um computador para realizar seu trabalho. Ele pode ser
conectado diretamente rede de computadores atravs de sua interface Ethernet.
Possui um teclado numrico e um visor de cristal lquido para exibir informaes ao
usurio das chamadas de VoIP e permitir configuraes bsicas.
Esse aparelho telefnico VoIP foi escolhido tambm para servir de gerador de
requisies e chamadas VoIP, pois ele homologado pela Anatel (Agncia Nacional
de Telecomunicaes) segundo o documento de requisitos tcnicos [ANA10]
aplicveis para ensaios desse tipo de aparelho. Esse documento, em relao aos
testes da mquina SIP dos aparelhos IP, baseia-se numa especificao [MTS07]
desenvolvida pelo rgo ETSI (European Telecommunications Standards Institute),
que rene e especifica todos os comportamentos esperados de um equipamento
VoIP que trabalha com o protocolo SIP. A ETSI se baseou na RFC3261 para
elaborar todos esses testes. A Anatel no especifica todos os testes recomendados
pela ETSI, mas apenas alguns aplicveis a adaptadores para telefnicos analgicos
e telefones IP, como o Chatty.
64
c) Trixbox:
O Trixbox [TRIX] um PBX IP baseado no famoso Asterisk [AST], que um
software livre que transforma um PC numa plataforma de comunicao multimdia.
Ambos so projetos com cdigo fonte aberto.
Essa plataforma um excelente PBX IP, com vrios recursos adicionais,
como correio de voz, unidade de resposta audvel e outros. Porm, at o momento
da escrita desta dissertao, ele no est totalmente aderente s normas da ETSI
no que diz respeito ao comportamento de um equipamento VoIP baseado em SIP.
H trabalhos paralelos que esto empenhados em fazer com que o Asterisk se torne
um equipamento que segue todas as normas para telefonia IP baseada em SIP.
Como ele ainda no totalmente aderente s normas da ETSI, ele foi
utilizado em testes onde o VoIPFix pode detectar falhas na sinalizao.
d) Ision IP:
O Ision [ISI] um PBX hbrido (possui elementos IP, analgicos e digitais) de
grande porte fabricado pela Leucotron Telecom. O equipamento est homologado
pela Anatel, inclusive no que diz respeito s normas de testes de SIP.
4.4
Detalhes de implementao
65
Receber o ponteiro de uma funo para que seja chamada cada vez que um
pacote recebido ou;
armazenar os pacotes em uma lista temporria e deixar a cargo da aplicao
coletar os pacotes na medida do possvel, at que a lista fique vazia e seja
preenchida novamente com a chegada de novos pacotes.
66
Obviamente, o processo consome recursos da mquina que realiza o
trabalho, na proporo do tamanho de cada arquivo, uma vez que todos os arquivos
selecionados pelo usurio so abertos e carregados para a memria.
a) SIP:
A tcnica adotada para a caracterizao de um pacote SIP consiste na
identificao do nome do protocolo e de sua verso, presentes na primeira linha do
payload UDP. O VoIPFix analisa somente pacotes da verso 2.0, que a
atualmente utilizada.
Para mensagens de resposta, a primeira linha, chamada de linha de status,
tem o seguinte formato:
SIP-Version SP Status-Code SP Reason-Phrase CRLF
Sendo assim, basta identificar que o primeiro campo dessa linha seja
SIP/2.0, para caracterizar que uma mensagem SIP de resposta.
Para as mensagens de requisio, a primeira linha, chamada de linha de
requisio, possui o seguinte formato:
Method SP Request-URI SP SIP-Version CRLF
Dessa forma, a identificao ligeiramente mais trabalhosa, consistindo no
mesmo princpio de procurar pelo nome e verso do protocolo somente na primeira
linha para caracterizar como uma mensagem SIP de requisio.
Tendo o pacote sido marcado como do protocolo SIP, ele encaminhado
para a parte que realiza a interpretao completa do pacote. Essa tcnica garante
uma agilidade na identificao e interpretao dos pacotes de uma rede, no
passando toda e qualquer mensagem UDP pelo interpretador.
b) RTP:
O mecanismo utilizado para identificao de pacotes RTP [AGR08], baseia-se
na prvia deteco das sesses atravs das mensagens de sinalizao utilizadas
para negociao e estabelecimento. Aps a identificao dessas sesses, o VoIPFix
67
passa a identificar os pacotes UDP que se encaixem em pelo menos uma das
condies de endereo IP ou porta de origem ou destino.
O VoIPFix vai alm e considera outros fatores que tornam a identificao dos
pacotes RTP mais segura. Tais fatores so analisados em conjunto com o endereo
IP e porta de destino e origem, mas s so considerados aps algumas unidades de
pacotes terem aparecido no incio do fluxo. Isso necessrio para se certificar que
realmente um fluxo de voz comeou. Tais fatores adicionais so:
68
tempo de abertura e processamento de arquivos grandes, descritos na Seo 4.5
Testes de , evidenciam o ganho de desempenho obtido por meio das tcnicas
inovadoras utilizadas para desempenhar essa tarefa.
A seguir, os pontos principais do mecanismo utilizado so descritos:
A
Figura 36 ilustra o algoritmo descrito acima, com um exemplo de
processamento paralelo de pacotes, considerando um ambiente com quatro threads:
69
Cabealhos
Pacote 1
Tarefa 1
SIP
Pacote 2
Tarefa 2
RTP
Pacote 3
Tarefa 3
RTP
Pacote 4
Tarefa 4
SIP
Pacote 5
Tarefa 2
???
Pacote 6
Tarefa 1
???
Pacote 7
Tarefa 4
Pacote 8
Tarefa 3
???
SIP
Pacote 9
Tarefa 1
RTP
Time stamp
Payload type
Pacote 10
Tarefa 3
RTP
SSRC
Campos
.......
Pacote n
Figura 36 Interpretao de pacotes em mltiplas tarefas.
70
SIP
Tarefa 4
Transao 1
RTP
Tarefa 3
Transao 2
RTP
Tarefa 1
Transao 2
SIP
Tarefa 4
Transao 3
???
Tarefa 2
???
Tarefa 2
???
Tarefa 3
SIP
Tarefa 1
Transao 1
RTP
Tarefa 4
Transao 3
RTP
Tarefa 2
Transao 2
...
SIP
Figura 37 Anlise em mltiplas tarefas para formao de transaes
71
72
tipoTrans = tipo da transao existente;
Se tipoTrans INVITE,REGISTER,OPTIONS,NOTIFIY ento
//transao j possui tipo
Se tipoReq CANCEL ento
estadoTransao = CANCEL;
Seno Se tipoReq BYE ento
estadoTransao = BYE;
Fim Se
Seno
//transao ainda no possui tipo
Se tipoReq INVITE,REGISTER,OPTIONS,NOTIFIY
ento
tipoTransao = tipoReq;
Seno Se tipoReq CANCEL ento
estadoTransao = CANCEL;
Seno Se tipoReq BYE ento
estadoTransao = BYE;
Fim Se
Fim Se
Seno Se mensagem de resposta
statusCode = cdigo da mensagem de resposta;
Se statusCode != CANCEL e statusCode != BYE
statusTransao = statusCode;
Fim Se
Fim Se
Se mensagem SIP possui SDP ento
Se possui mdia de udio ento
Adiciona informaes de mdia na transao;
Fim Se
Fim Se
Fim Se
Seno
Se pacote RTP ento
Adiciona pacote RTP na lista da transao;
Fim Se
Fim Se
73
enviados diretamente para os mecanismos de interpretao e anlise, sem a
necessidade de formao de filas.
A anlise durante a captura de pacotes utiliza os mesmos mecanismos
descritos na Seo 4.4.3. A diferena bsica que os pacotes chegam e so
analisados medida que so capturados, no sendo necessrio utilizar
processamento paralelo, pois no h formao de filas como acontece quando um
arquivo aberto.
As funes que organizam os pacotes em conjuntos de transaes, durante a
captura, por meio de uma interface, so as mesmas utilizadas no processamento
paralelo, pois foram projetadas para contemplar a situao. Pode-se dizer que o
processo uma particularizao desse algoritmo, quando executado em um
processador com um nico ncleo, mas com a vantagem de cobrir situaes em que
os pacotes chegam fora de ordem.
Algumas melhorias sero feitas para que todas as funcionalidades de anlise
funcionem em conjunto com a captura de pacotes por intermdio de uma interface
de rede. Atualmente, no possvel, por exemplo, acompanhar a chegada dos
pacotes por grficos de transaes. A Seo 5.1 descreve com mais detalhes os
trabalhos futuros nesse sentido.
74
Nmero de transaes;
estatsticas de fechamento de chamadas;
nmero de chamadas por usurio ou mquina;
estatsticas de pedidos de registros;
nmero de registros por usurio ou mquina.
75
76
4.4.12 Deteco de mudez total ou parcial em chamadas
O VoIPFix detecta mudez total ou parcial em chamadas completadas com
qualquer tipo de codificador de voz, pois analisa somente o fluxo de pacotes, sem
realizar nenhum tipo de decodificao para extrao do udio.
Da mesma forma como feita com a medio de jitter, perda de pacotes e
erros de sequncia, a ferramenta s realiza o processo de deteco de acidentes de
fluxo quando o usurio seleciona uma transao na lista e solicita a abertura da
janela de relatrios. Essa atitude foi adotada para evitar que o VoIPFix execute
trabalhos demorados sem necessidade, pois dependendo da quantidade de
transaes selecionadas e do tempo de cada chamada, o processo pode levar muito
tempo para ser realizado.
A mudez total, em um ou em ambos os sentidos do fluxo de udio, pode ser
causada por vrios motivos. Abaixo alguns exemplos:
77
O primeiro caso apresentado na Seo 4.2.16, detectou problema no
fechamento da chamada, pois a requisio de BYE no foi entendida pelo receptor
da chamada, como pode ser observado com mais detalhes na Figura 38.
78
79
4.4.14 Informativo com causas de problemas com transaes
O campo estado da lista de transaes no exibe somente a situao de
finalizao da transao, mas, tambm, qualquer tipo de erro que acontece durante
o fechamento de uma chamada ou pedido de registro.
A obteno dessa informao feita durante o processo de anlise dos
pacotes e da montagem da estrutura que agrupa os pacotes da transao, como j
foi explicado na Seo 4.4.3.
4.5
Testes de correo
4.5.1
Esse parmetro indica o maior valor de jitter atingido durante todo o fluxo RTP
da chamada. Valores superiores a algumas unidades em relao ao tempo de cada
amostra, contida em um pacote, pode fazer com que ele seja descartado, causando
picotes no udio reproduzido.
80
Foram selecionados arquivos de captura de casos que continham chamadas
com valores de jitter diferentes de zero, para serem analisados pelo VoIPFix e pelo
Wireshark. Os resultados dos testes so apresentados na Tabela 4.
VoIPFix
Tempo (ms)
Wireshark
Fluxo
Originador
Receptor
Originador
Receptor
Caso 1
0,21
25,99
0,21
26,00
Caso 2
0,14
11,10
0,14
11,11
4.5.2
VoIPFix
Wiresahrk
Fluxo
Originador
Receptor
Originador
Receptor
Caso 1
0%
24,05%
0%
24,01%
Caso 2
4,88%
0,30%
4,88%
0%
81
4.6
Sistema Operacional
Debian
kernel
GNU/Linux AMD
Debian
kernel
II
X4
945
(4
4 GB
cache de 512 KB
GNU/Linux Intel
Core
Duo
E4600
(2
2 GB
Phenom
RAM
Processador
cache de 2048 KB
Core
Duo
E4600
(2
2 GB
Debian
kernel
cache de 2048 KB
GNU/Linux Intel
Core
Duo
T6600
(2
3 GB
Core
Duo
T6600
(2
3 GB
82
configurado para ger-los com tamanho de no mximo 50 MBytes e criar um novo
depois de atingir esse limite. A captura foi realizada at a gerao de quatro
arquivos, que foram mesclados, formando outros de 100, 150 e 200 MBytes.
A seguir, so apresentadas informaes relevantes sobre os arquivos
utilizados nos teste:
Arquivo de 50 MBytes:
83
4.6.1 Testes
O procedimento utilizado para avaliar o tempo de abertura de cada arquivo,
no Wireshark e no VoIPFix, levou em considerao uma das operaes que mais
utilizada por um usurio comum de uma ferramenta como essa e, tambm, uma das
que mais consome processamento, que a abertura da lista de transaes,
realizada por ambas as aplicaes.
No VoIPFix, a operao executada assim que for ordenada a abertura de
um arquivo, exibindo todas as transaes existentes. No Wireshark, aps a escolha
do arquivo desejado, necessrio aguardar at que ele exiba todos os pacotes em
uma lista, para, depois, acessar o menu que contm a operao que exibe somente
as chamadas, pois no h uma funcionalidade que exibe todas as transaes, como
no VoIPFix.
importante ressaltar que a comparao de desempenho dos dois
aplicativos, em relao a essa funcionalidade, considera somente a percepo de
tempo do usurio para obter a lista de transaes, uma vez que o VoIPFix realiza
um trabalho maior, analisando e exibindo todas as requisies, no somente as de
chamadas, como faz o Wireshark.
A medio de tempo, nos testes com o VoIPFix, foi feita com a prpria
ferramenta, que informa os segundos gastos desde o comando de abertura do
arquivo at a exibio de toda a lista de transaes. No Wireshark, foi realizada a
medio com a ajuda de cronmetro manual, por isso os tempos no so to
precisos quanto no VoIPFix.
Foram utilizadas cinco mquinas com arquitetura e sistemas operacionais
diferentes durante os testes de abertura de arquivos grandes. O intuito foi de
comparar o desempenho de ambas as aplicaes, pois utilizam tecnologias bem
diferentes, alm de salientar o ganho de desempenho do VoIPFix em arquitetura
com vrios ncleos.
A seguir, o resultado dos testes de abertura de cada arquivo, em cada
mquina, utilizando o VoIPFix e o Wireshark:
a) Arquivo de 50 MBytes:
Tempo (s)
VoIPFix
Wireshark
Mquina 1 Mquina 2
Mquina 3
Mquina 4
Mquina 5
8,74
11,90
11,01
8,23
11,62
53
60
47
95
71
84
b) Arquivo de 100 MBytes:
Tempo (s)
VoIPFix
Wireshark
Mquina 1 Mquina 2
Mquina 3
Mquina 4
Mquina 5
23,97
31,00
25,25
21,16
28,11
126
160
157
250
175
Mquina 1 Mquina 2
Mquina 3
Mquina 4
Mquina 5
46,92
60,21
43,47
39,70
49,43
173
230
197
355
240
Mquina 1 Mquina 2
Mquina 3
Mquina 4
Mquina 5
64,47
90,26
62,34
58,09
72,46
295
390
340
600
460
85
Para comprovar a eficincia do VoIPFix em relao ao Wireshark, foram
realizados os mesmos testes de abertura de arquivos grandes, porm em uma
mquina com apenas um ncleo. Dessa forma, o VoIPFix utilizou apenas uma
thread para processar os arquivos e seus pacotes, como o Wireshark. A seguir a
descrio da mquina utilizada nos testes:
Sistema operacional: Kubuntu 8.04 com kernel 2.6.24-16 com KDE verso
3.5.9;
processador: AMD Athlon XP 2400+, com clock de 2 GHz - single core;
memria RAM: 512 MB.
Os resultados so apresentados na Tabela 11.
Tamanho do arquivo /
Tempo (s)
50 MB
100 MB
150 MB
200 MB
VoIPFix
29,50
97,30
205,05
322,11
274
790
1210
2180
Wireshark
4.7
86
Funcionalidade
VoIPFix
Captura de pacotes
Anlise de
multicore
forma
gil
em
plataformas
Grfico detalhado
chamadas
de
das
transaes
87
4.7.1 Anlise de forma eficiente em plataformas multicore
O ganho de desempenho do VoIPFix, em relao ao Wireshark, para
realizao de tarefas que demandam grande poder de processamento, ficou
evidente nos testes apresentados na Seo 4.6. No somente para abertura de
arquivos grandes, mas, tambm, para gerao de relatrios e medies de jitter, que
necessita de anlise de todos os pacotes do fluxo de mdia.
A arquitetura implementada no VoIPFix permitir novas implementaes e
evolues, que podero aproveitar a base j desenvolvida para processamento
paralelo, tornando-o eficiente em outras funcionalidades.
88
4.7.5 Medio de jitter, perda de pacotes e erros de sequncia
A forma como o Wireshark disponibiliza essas funcionalidades torna-o pouco
eficiente, pois a anlise dissociada da transao da chamada, fazendo que o
usurio analisador tenha de realizar os seguintes passos:
89
Concluso
5.1
Trabalhos futuros
90
de outros codificadores de voz, como o iLBC, que no necessita de pagamento de
royalties para ser utilizado.
91
atrair a comunidade de usurios e desenvolvedores interessada nesse tipo de
ferramenta, para aprimor-lo e contribuir para a criao de melhorias.
92
Bibliografia
[AGR08]. AGRAWAL, A. et al. SIP/RTP Session Analysis and Tracking for VoIP
Logging. In 16th IEEE International Conference, pginas 1-5. 2008.
[AND04]. ANDERSEN, S. et al. Internet Low Bit Rate Codec (iLBC). 2004. IETF
RFC3951.
[ANA10]. Requisitos Tcnicos e Procedimentos de Ensaios Aplicveis
Certificao de Produtos para Telecomunicao de Categoria 1. Agncia
Nacional de Telecomunicaes. Brasil. 2010.
[AST]. ASTERISK: The Open Source Telephony Project. http://www.asterisk.org.
ltimo acesso em 14/11/2010.
[AUF]. Au File Format.
http://www.opengroup.org/public/pubs/external/auformat.html. ltimo
acesso em 03/10/2010.
[BAO09]. BAO, D. et al. Session Initiation Protocol Automatic Debugger. In IEEE
Transactions on Instrumentation and Measurement, volume 58, nmero
6. June 2009.
[BLA08]. BLANCHETTE, J.; SUMMERFIELD, M. C++ GUI Programming with Qt 4.
2nd. ed. Prentice Hall. 2008. 752 p.
[BS06]. BASET, Salman A., SCHULZRINNE, H. An Analysis of the Skype Peerto-Peer Internet Telephony Protocol. In 25th IEEE International
Conference on Computer Communications, pginas 1-11. 2006.
[CACE]. CACE Pilot. http://www.cacetech.com. ltimo acesso em 07/11/2010.
[CAM02]. CAMPBELL, B., et al. The SIP Extension for Instant Messaging. 2002.
IETF RFC3428.
[CAR04]. CARVALHO, L. S. G. D. Implementao do Modelo E para Avaliao
Objetiva da Qualidade de Fala em Redes de Comunicao VoIP. 2004.
169 p. Dissertao (Mestrado em Cincia da Computao) Instituto de
Cincias Exatas, Universidade Federal do Amazonas, Manaus, Setembro
de 2004.
[CHAT]. TELEFONE IP Chatty. http://www.leucotron.com.br/aparelhotelefonico/chattyip. ltimo acesso em 15/11/2010.
[COR03]. CORMEN, Thomas H., et al. Introduction to Algorithms. 2nd. ed.
McGraw-Hill. 2003. 1056 p.
[CUE00]. CUERVO, F., et al. Megaco Protocol Version 1.0. 2000. IETF RFC3015.
[DON00]. DONOVAN, S. The SIP INFO Method. 2000. IETF RFC2976.
93
[EGE94]. Egevang, K. et al. The IP Network Address Translator (NAT). 1994. IETF
RFC1631.
[FIE99]. FIELDING, R. et al. Hypertext Transfer Protocol HTTP/1.1. 1999. IETF
RFC2616.
[HAN98]. HANDLEY, M.; JACOBSON, V. SDP: Session Description Protocol. 1998.
IETF RFC2327.
[IETF]. IETF. http://www.ietf.org. ltimo acesso em 10/11/2010.
[ISI]. ISION IP: PBX IP. http://www.leucotron.com.br/pabx/ision-ip/conheca.
ltimo acesso em 15/11/2010.
[ITU07]. Recommendation ITU-T G.729. Coding of speech at 8 kbit/s using
conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
2007.
[ITU09]. Recommendation ITU-T H.323, version 7.0. Infrastructure of audiovisual
services Systems and terminal equipment for audiovisual services.
2009.
[ITU72]. Recommendation ITU-T G.711. Pulse Code Modulation (PCM) of Voice
Frequencies. 1972.
[JOH03]. JOHNSTON, A. et al. SIP Basic Call Flow Examples. 2003. IETF
RFC3665.
[JOH04]. JOHNSTON, ALAN B. Undestanding the Session Initiation Protocol. 2nd.
ed. Artech House Telecommunications. 2004. 283 p.
[KP09].
94
[QT]. QT - Cross-platform application and UI framework. http://qt.nokia.com.
ltimo acesso em 13/11/2010.
[ROA03]. ROACH, A. SIP Specific Event Notification. 2003. IETF RFC3265.
[ROS02a]. ROSENBERG, J. et al. SIP: Session Initiation Protocol. 2002. IETF
RFC3261.
[ROS02b]. ROSENBERG, J. The SIP UPDATE Method. 2002. IETF RFC3311.
[RS02a]. ROSENBERG, J. and SCHULZRINNE, H. Reliability of Provisional
Responses in SIP. 2002. IETF RFC3262.
[RS02b]. ROSENBERG, J. and SCHULZRINNE, H. An Offer/Answer Model with the
SDP. 2002. IETF RFC3264.
[SCH00]. SCHULZRINNE, H. et al. RTP Payload for DTMF Digits, Telephony Tones
and Telephony Signals. 2003. IETF RFC2833.
[SCH03]. SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time
Applications. 2003. IETF RFC3550.
[SCH96]. SCHULZRINNE, H. et al. RTP Profile for Audio and Video Conferences
with Minimal Control. 1996. IETF RFC1890.
[SPA03]. SPARKS, R. The SIP Refer Method. 2003. IETF RFC3515.
[SUM10]. SUMMERFIELD, M. Advanced Qt Programming. Prentice Hall. 2010. 536
p.
[TCPD]. TCPDUMP/LIBPCAP . http://www.tcpdump.org. ltimo acesso em
02/10/2010.
[TELE]. ESTATSTICAS de VoIP. Teleco,
http://www.teleco.com.br/voip_estatis.asp. ltimo acesso em 14/11/2010
[TRIX]. TRIXBOX: The Open Platform for Business Telephony.
http://www.trixbox.org. ltimo acesso em 02/05/2010.
[VOIP] VoIPFix. http://ccsl.ime.usp.br/voipfix. ltimo acesso em 03/01/2011.
[XLT]. X-LITE. http://www.counterpath.com/x-lite.html. ltimo acesso em
01/05/2010.
[YER98]. YERGEAU, F. UTF-8, A transformation format of ISO 10646. 1998. IETF
RFC2279.
[WINP]. WINPCAP. http://www.winpcap.org. ltimo acesso em 02/10/2010.
[WIRa]. WIRESHARK . www.wireshark.org. ltimo acesso em 01/11/2010.
95
[WIRb]. WIRESHARK Performance. http://wiki.wireshark.org/Performance. ltimo
acesso em 14/11/2010.