VoIPFix: Uma ferramenta para

anlise e deteco de falhas em

sistemas de telefonia IP

Paulo Csar Sicola

DISSERTAO APRESENTADA
AO
INSTITUTO DE MATEMTICA E ESTATSTICA
DA
UNIVERSIDADE DE SO PAULO
PARA
OBTENO DO TTULO
DE
MESTRE EM CINCIAS

Programa: Cincia da Computao

Orientador: Prof. Dr. Fabio Kon

So Paulo, dezembro de 2010

 VoIPFix: Uma ferramenta para
anlise e deteco de falhas em
sistemas de telefonia IP

Esta verso definitiva da dissertao

contm as correes e alteraes sugeridas pela
Comisso Julgadora durante a defesa realizada
por Paulo Csar Sicola em 10/02/2011.

Comisso julgadora:

Prof. Dr. Fabio Kon (orientador) IME-USP

Prof. Dr. Daniel Macedo Batista UNICAMP
Prof. Dr. Edson dos Santos Moreira ICMC-USP
Prof. Dr. Wagner Luiz Zucchi EP-USP
Agradecimentos

Deus, somente Tu sabes de minha jornada, das minhas limitaes, dos

desafios e obstculos que superei. Sabes tambm que sem a Tua mo poderosa
nada seria possvel. Diante de Ti, s posso louvar Teu Santo nome e agradecer por
estar sempre ao meu lado.
Rogrio e Joana, meus amados pais. Nem mil palavras seriam suficientes
para agradec-los. Vocs me criaram com dedicao, amor e carinho. Nem sei
quantos sacrifcios fizeram por minha causa, para que eu pudesse chegar at aqui,
mas tenho certeza de que foram muitos. Por vrias vezes, mesmo sem saber, vocs
me educaram como verdadeiros mestres da vida. Obrigado pelo apoio, pelo amor e
pela dedicao.
Isabel, minha amada imortal. Voc esteve do meu lado desde o primeiro
momento dessa minha jornada, me apoiando e me incentivando. Voc transformou
minha vida, minha mente e meu corao. Eu sou abenoado por ter uma mulher
incrvel ao meu lado como minha esposa. Agradeo pelo companheirismo nas
manhs, tardes, noites e feriados de estudo. Agradeo-te por tudo.
Agradeo ao professor Dr. Fabio Kon, pela dedicao e pelos sbios
conselhos que ajudaram a concretizar este trabalho e a torn-lo melhor.
Aos professores de minha banca, agradeo pelos conselhos e pela
contribuio.
Agradeo Daniela Santos, pela ajuda nas correes e melhorias do texto.
Aos meus amigos do IME; Charles Iury, Giseli Ramos, Rogrio Rondini,
Roger Ricardo, Lucas Ruiz e tantos outros, agradeo pelo companheirismo e pela
inestimvel amizade.
Finalmente, agradeo empresa em que trabalho, a Leucotron Telecom, em
especial meu Gerente, Ricardo Varejo, pelo apoio, confiana e incentivo.
Resumo

Com os avanos das tecnologias de transmisso de dados e com a

popularizao dos acessos Internet por meio de banda larga para empresas e
usurios domsticos, a telefonia IP tornou-se uma tecnologia de uso generalizado.
As prestadoras de servio de telefonia IP, tambm chamadas de operadoras
VoIP, apareceram para conquistar esse mercado crescente. Essas empresas
oferecem planos com tarifas mais reduzidas, principalmente para ligaes a longa
distncia e internacionais, uma vez que sua grande vantagem est no fato de utilizar
infraestrutura existente de rede utilizada para transporte de dados, como a Internet.
Apesar dos benefcios que a tecnologia VoIP trouxe, muitos problemas so
enfrentados pelos usurios, pois o sistema de telefonia IP depende fortemente de
recursos que no esto sob o controle das aplicaes e equipamentos responsveis
por oferecer esse servio.
O projeto VoIPFix, apresentado nesta dissertao, surgiu da necessidade de
uma ferramenta que complementasse as demais existentes no ramo de anlise de
redes de computadores e telefonia IP. Muitos dos profissionais que trabalham nesse
mercado possuem um conhecimento limitado das tecnologias e protocolos dos
equipamentos de VoIP, pois algo muito especfico desse tipo de tecnologia.
O VoIPFix foi construdo com o propsito nico de ser uma ferramenta
eficiente e exclusiva para VoIP, possuindo funcionalidades necessrias para dar
suporte ao profissional de administrao de rede a observar e diagnosticar
problemas de telefonia IP.
O trabalho aqui apresentado inclui a investigao de ferramentas
relacionadas, descreve os princpios utilizados na arquitetura de construo do
VoIPFix, seus detalhes de implementao e apresenta testes de correo e
desempenho dos algoritmos de anlise.
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 O Mercado de Telefonia IP .......................................................................................... 2
1.2 Motivaes para o Trabalho ........................................................................................ 3
1.3 Objetivos do Trabalho .................................................................................................. 4
2 Protocolos de Telefonia IP ............................................................................................... 5
2.1 SIP................................................................................................................................ 5
2.1.1 Estrutura de mensagens SIP ............................................................................... 6
2.2 SDP ............................................................................................................................ 11
2.3 RTP ............................................................................................................................ 14
2.4 Exemplos de Fluxos de Mensagens SIP................................................................... 15
2.4.1 Pedido de registro .............................................................................................. 16
2.4.2 Estabelecimento de sesso ............................................................................... 17
2.4.3 Finalizao de sesso ........................................................................................ 18
2.4.4 Cancelamento de sesso ................................................................................... 19
3 Trabalhos Relacionados ................................................................................................ 20
3.1 Wireshark ................................................................................................................... 20
3.1.1 Anlise dos campos de mensagens .................................................................. 20
3.1.2 Visualizao das transaes de chamada......................................................... 21
3.1.3 Grfico de transaes de chamada ................................................................... 21
3.1.4 Reprodutor de udio de chamadas .................................................................... 21
3.1.5 Anlise de pacotes RTP ..................................................................................... 22
3.2 Cace Pilot ................................................................................................................... 22
3.3 SIP Automatic Debugger ........................................................................................... 23
4 VoIPFix ............................................................................................................................. 24
4.1 Arquitetura.................................................................................................................. 25
4.1.2 Interpretador ....................................................................................................... 27
4.1.3 Detector de transaes ...................................................................................... 28
4.1.4 Analisador ........................................................................................................... 29
4.1.5 GUI ...................................................................................................................... 29
4.1.6 Gerenciador ........................................................................................................ 30
4.2 Funcionalidades ......................................................................................................... 30
4.2.1 Captura de pacotes ............................................................................................ 31
4.2.2 Anlise de pacotes de forma eficiente em plataformas multicore ..................... 32
 4.2.3 Anlise durante o processo de captura ............................................................. 33
4.2.4 Anlise de mltiplos arquivos gravados sequencialmente ................................ 33
4.2.5 Exibio de lista de transaes .......................................................................... 34
4.2.6 Exibio de detalhes das mensagens de sinalizao e voz ............................. 36
4.2.7 Exibio de grfico detalhado de transaes .................................................... 38
4.2.8 Exibio de grfico com nmero de transaes ................................................ 41
4.2.9 Exibio de grfico com estatsticas de fechamento de chamadas .................. 42
4.2.10 Exibio de grfico de nmero de chamadas por usurio ou mquina ............ 44
4.2.11 Exibio de grfico com estatsticas de pedidos de registros ........................... 48
4.2.12 Exibio de grfico de nmero de registros por usurio ou mquina ............... 49
4.2.13 Filtro de transaes ............................................................................................ 52
4.2.14 Medio de jitter, perda de pacotes e erros de sequncia ................................ 53
4.2.15 Deteco de mudez total ou parcial em chamadas ........................................... 54
4.2.16 Deteco de transaes com erros de sinalizao ........................................... 57
4.2.17 Informativo com causas de problemas com transaes ................................... 59
4.2.18 Reproduo do udio das chamadas com codificador G.711 ........................... 60
4.3 Tecnologias e ferramentas utilizadas ........................................................................ 61
4.3.1 Linguagem de programao .............................................................................. 61
4.3.2 Capturador de pacotes de rede ......................................................................... 61
4.3.3 Interpretador de mensagens SIP ....................................................................... 62
4.3.4 Ferramentas e equipamentos de testes ............................................................ 62
4.4 Detalhes de implementao ...................................................................................... 64
4.4.1 Captura de pacotes ............................................................................................ 64
4.4.2 Anlise de mltiplos arquivos gravados sequencialmente ................................ 65
4.4.3 Identificao de pacotes de interesse ................................................................ 66
4.4.4 Interpretao dos pacotes de sinalizao.......................................................... 67
4.4.5 Anlise de transaes de forma eficiente em plataformas multicore ................ 67
4.4.6 Anlise durante o processo de captura ............................................................. 72
4.4.7 Exibio de lista de transaes .......................................................................... 73
4.4.8 Exibio de grfico detalhado de transaes .................................................... 73
4.4.9 Exibio de grficos com estatsticas ................................................................ 74
4.4.10 Filtro de transaes .......................................................................................... 74
4.4.11 Medio de jitter, perda de pacotes e erros de sequncia .............................. 75
4.4.12 Deteco de mudez total ou parcial em chamadas ......................................... 76
4.4.13 Deteco de transaes com erros de sinalizao.............................................. 76
4.4.14 Informativo com causas de problemas com transaes ................................. 79
 4.4.15 Reproduo do udio das chamadas com codificador G.711......................... 79
4.5 Testes de correo .................................................................................................... 79
4.5.1 Medio de jitter mximo .................................................................................. 79
4.5.2 Medio de percentual de perda de pacotes .................................................... 80
4.6 Testes de desempenho com abertura de arquivos grandes .................................... 81
4.7 Comparao com outras ferramentas ....................................................................... 85
4.7.1 Anlise de forma eficiente em plataformas multicore ........................................ 87
4.7.2 Exibio de transaes de registro .................................................................... 87
4.7.3 Deteco de mudez total ou parcial em chamadas ........................................... 87
4.7.4 Deteco de erros de sinalizao ...................................................................... 87
4.7.5 Medio de jitter, perda de pacotes e erros de sequncia ................................ 88
5 Concluso ........................................................................................................................ 89
5.1 Trabalhos futuros ....................................................................................................... 89
6 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

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:

Deteco de eventos anormais no sistema de telefonia principal da empresa;

anlise de problemas em campo;
verificao de funcionamento de equipamentos de testes em laboratrio;
 2

medio de jitter e perda de pacotes em ensaios de grande escala.

O VoIPFix est disponibilizado como um projeto de software livre atravs do

Centro de Competncia de Software Livre do IME-USP, no stio
http://ccsl.ime.usp.br/voipfix, sob a licena GNU General Public License v.3.

1.1 O Mercado de Telefonia IP

Com os avanos das tecnologias de transmisso de dados e com a

popularizao dos acessos Internet atravs de banda larga para empresas e
usurios domsticos, a telefonia IP tornou-se um fato real. As empresas utilizam de
todos os recursos possveis para que a comunicao tenha, com
clientes/fornecedores e colaboradores, um custo menor do que aquele do sistema
de telefonia fixa convencional.
As prestadoras de servio de telefonia IP, tambm chamadas de operadoras
VoIP, apareceram para conquistar esse mercado crescente. Essas empresas
oferecem planos com tarifas mais reduzidas, principalmente para ligaes de longa
distncia e internacionais, uma vez que a grande vantagem est no fato dela utilizar
infraestrutura existente de rede utilizada para transporte de dados, como a Internet.
Alm de permitir um custo mais barato para ligaes, o usurio de VoIP ainda
tem a mobilidade como vantagem, j que possvel se comunicar no importa o
local onde se esteja, desde que haja um acesso Internet com velocidade razovel.
Atravs da telefonia IP possvel realizar ligaes de qualquer parte do mundo e
para qualquer outra parte do mundo, com tarifas bem reduzidas.
Apesar das grandes vantagens, essa tecnologia ainda apresenta alguns
problemas aos usurios, principalmente no que diz respeito qualidade da
chamada. Porm, os benefcios so muito grandes e fazem com que o mercado
cresa a cada dia. Apenas as vantagens de reduo de custos e mobilidade j so
grandes motivos para que essa tecnologia seja bastante utilizada.
Segundo informaes do stio Teleco [TELE], computando apenas os servios
das duas maiores operadoras de telefonia IP do Brasil, que so a Embratel e a GVT,
o crescimento de assinantes nos ltimos anos foi muito grande, como pode ser visto
na Tabela 1:

Milhares 2008 2009 2010

Embratel 1802 2557 2765
GVT 100 147 176

Tabela 1 Milhares de assinantes de VoIP das maiores operadoras brasileiras.

Fonte: www.teleco.com.br
 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 Motivaes para o Trabalho

Apesar dos benefcios que a tecnologia VoIP trouxe, muitos problemas so

enfrentados pelos usurios, pois o sistema de telefonia IP depende fortemente de
recursos que no esto sob o controle das aplicaes e equipamentos responsveis
por oferecer esse servio [KP09]. Alguns dos problemas so:
Degradao da qualidade de voz;
ausncia de udio em um ou ambos os sentidos;
queda de ligaes;
indisponibilidade do servio de telefonia.
Alguns desses problemas so causados principalmente pelas condies da
rede por onde os pacotes de sinalizao e voz esto trafegando, pois, normalmente,
eles esto compartilhando o meio de transmisso com outros pacotes da rede. Tais
problemas da telefonia IP podem ser causados por:

Largura de banda de rede insuficiente para transmisso de voz;

regras de priorizao de pacotes inadequadas em equipamentos de
roteamento;
regras de redirecionamento de pacotes incoerentes em equipamentos de
roteamento para funcionamento de servios de VoIP;
instabilidade de elementos de rede ou meios de transmisso.

As causas dos problemas de um sistema de telefonia IP so relativamente

bem conhecidas, mas so muito difceis de serem diagnosticadas, envolvendo
anlise de grande quantidade de dados.

Este trabalho apresenta o desenvolvimento do VoIPFix [VOIP], uma

ferramenta especfica de anlise de casos que utilizem VoIP, do ponto de vista de
pacotes de sinalizao e voz. Alguns dos objetivos so:

Capturar e analisar de forma eficiente, pacotes de sinalizao e voz;

exibir relatrios das ligaes, informando dados como perda de pacotes, jitter,
qualidade de voz da ligao;
 4

informar problemas relativos sinalizao nas chamadas e nos pedidos de

registro;
permitir a operao e o diagnstico de problemas por usurios que tenham
conhecimento bsico de VoIP.

1.3 Objetivos do Trabalho

Este trabalho tem os seguintes objetivos:

Investigar criticamente outras ferramentas conceituadas de monitoramento e

anlise de VoIP, citando suas limitaes;
propor novas funes para torn-las mais adequadas aos usurios com
pouco conhecimento na tecnologia e protocolos;
desenvolver uma nova ferramenta capaz de resolver parte das limitaes
trazendo maior facilidade de avaliao em questes de VoIP;
apresentar um estudo dos problemas mais comuns de sinalizao e trfego
de voz;
propor novas tcnicas de diagnstico, anlise de protocolos de sinalizao e
implement-las na nova ferramenta proposta, o VoIPFix.
A organizao desta dissertao a seguinte: o Captulo 2 apresenta os
conceitos bsicos dos protocolos de telefonia IP, como o SIP e o RTP, necessrios
para o entendimento do trabalho e fundamentais para o funcionamento do VoIPFix.
Traz tambm alguns exemplos de fluxos de mensagens de sinalizao. O Captulo 3
descreve o estado da arte e os principais trabalhos relacionados. O Captulo 4
detalha o sistema proposto com os objetivos principais, detalhes de implementao
da ferramenta e testes de correo e desempenho. Por ltimo, o Captulo 5 traz a
concluso sobre a pesquisa e aponta para possveis caminhos para trabalhos
futuros.
 5

2 Protocolos de Telefonia IP
A tecnologia de VoIP utiliza-se de dois tipos bsicos de protocolos para o seu
funcionamento:

Protocolo de sinalizao: responsvel pelo estabelecimento, controle e

encerramento das chamadas;
protocolo de transporte de voz: responsvel por trafegar a voz digitalizada e
codificada atravs da rede de comutao de pacotes.
Durante a evoluo da telefonia IP, muitos protocolos de sinalizao foram
desenvolvidos e utilizados, porm, atualmente, o protocolo mais utilizado o SIP.
Por tal motivo, este trabalho trata somente dos casos onde esse protocolo
utilizado. No haver nenhuma perda de funcionalidade, j que quase a totalidade
das aplicaes utiliza esse protocolo.
Em relao ao protocolo para transporte de voz, o mais utilizado, desde as
primeiras aplicaes de telefonia IP, o RTP, que, independentemente do tipo do
protocolo de sinalizao, pode ser utilizado para transportar os pacotes de voz
digitalizados e codificados atravs da rede de comutao de pacotes.
A seguir, sero descrito com mais detalhes esses dois protocolos e alguns
outros pontos chaves para o bom entendimento dos propsitos deste trabalho. Os
conceitos mostrados tm a profundidade necessria para que se possa entender os
objetivos do trabalho e os pontos chaves das tarefas, bem como eles sero
apresentados.

2.1 SIP
O SIP (Session Initiation Protocol) baseado nos modelos de requisies e
respostas do HTTP [FIE99], onde o sistema final que gera requisies chamado de
user agent client (UAC) e o outro, que responde a essas requisies, chamado de
user agent server (UAS).

As mensagens SIP trocadas entre os agentes podem ser transportadas por

UDP [POS80a] ou TCP [POS80b], porm a maioria das aplicaes utiliza somente o
UDP.
Dois conceitos so importantes para entendimento da mecnica das
mquinas de estado que regem as requisies e respostas do SIP, so eles: a
sesso e a transao.
A sesso uma coleo de fluxos de mdia, como udio, vdeo ou texto, com
o propsito de se iniciar uma comunicao entre dois ou mais participantes. Para o
estabelecimento dessa sesso, alguns parmetros devem ser negociados durante a
sinalizao, por exemplo, endereos IP, portas e codificadores de udio/vdeo. Tais
parmetros so fornecidos em mensagens SIP que contm outro protocolo chamado
SDP (Session Description Protocol) [HAN98].

Uma transao do SIP consiste numa requisio do cliente que invoca um

mtodo particular (funo) no servidor e esse responde com a mensagem adequada
 6

para dar continuidade ao atendimento dessa requisio. Na especificao original do

SIP, seis mtodos esto definidos:

REGISTER: para registrar informaes de contato e localizao do usurio;

INVITE: para iniciar uma sesso;
ACK: para confirmar o incio de uma sesso;
CANCEL: para cancelar uma sesso que est iniciando;
BYE: para terminar uma sesso estabelecida;
OPTIONS: para requisitar as capacidades de um agente.

Outros mtodos, como INFO [DON00], MESSAGE [CAM02], PRACK

[RS02a], UPDATE [ROS02b], REFER [SPA03] e NOTIFY [ROA03] foram
definidos para estender as possibilidades do SIP e implementar outros tipos de
servios de telefonia.

As requisies so recebidas ou geradas por servidores que esto presentes

num sistema de telefonia IP. Conceitualmente, os trs tipos de servidores numa
arquitetura SIP, so:

Servidores de encaminhamento: ajudam a encaminhar as requisies para os

destinos corretos dos usurios;
servidores de registro: permitem que os usurios possam informar o endereo
na rede para que os outros servidores possam consultar e encontrar onde
est um determinado usurio;
servidores de redirecionamento: ajudam a encontrar caminhos alternativos
onde os usurios possam ser encontrados.

Conceitualmente, os servidores no sistema de telefonia IP so considerados

como aplicaes fisicamente separadas, porm nada impede que os trs tipos
estejam instalados e em execuo em um mesmo computador servidor.

2.1.1 Estrutura de mensagens SIP

O SIP um protocolo baseado em texto, que utiliza o conjunto de caracteres

do UTF-8 [YER98]. As mensagens que so trocadas entre os agentes de uma
sesso seguem o mesmo padro das requisies HTTP, onde h uma parte que o
cabealho, com campos especficos dependendo do tipo da mensagem, e um corpo,
onde h informaes sobre a mdia da sesso que ser estabelecida.

No repertrio do SIP, as mensagens so divididas em requisio e resposta.

As mensagens de requisio solicitam mtodos especficos em um agente, como,
por exemplo, solicitar o incio de uma sesso de voz, cancelar uma sesso de voz
no processo de estabelecimento e encerrar uma sesso de voz depois de
estabelecida. Alm disso, tais mensagens podem solicitar o registro em um servidor
e algumas outras funes j definidas.
 7

A seguir, um detalhamento das duas mensagens de requisio de maior

relevncia.

2.1.1.1 Mensagem de requisio de registro

A mensagem de REGISTER, enviada por um UAC, solicita ao servidor de

registro que o adicione em sua lista de usurios presentes na rede, para que outros
servidores ou usurios possam encontr-lo. Tal mensagem contm apenas o
cabealho e seus campos, j que no ser estabelecida nenhuma sesso de mdia
entre o usurio e o servidor. Outras mensagens sero trocadas entre o UAC e o
servidor para completar a transao at que o registro seja efetivamente concludo.
Essas outras mensagens sero mostradas na Seo 2.4 que trata dos fluxos de
mensagens SIP.

A Figura 1 traz um exemplo de mensagem de requisio REGISTER.

REGISTER sip:192.168.1.35 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.33:5060;branch=z9hG4bK65F64549E146534
From: PCS200 <sip:200@192.168.1.35>;tag=1619075203
To: PCS200 <sip:200@192.168.1.35>
Contact: "PCS200" <sip:200@192.168.1.33:5060>
Call-ID: 016CD3BA63B0260AF38A7424274DB77D@192.168.1.35
CSeq: 425 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0

Figura 1 Exemplo de mensagem de pedido de registro.

A primeira linha, chamada de linha de requisio, informa basicamente o

mtodo (REGISTER) invocado pelo agente que gerou a mensagem e o endereo do
servidor no qual ele deseja invocar o mtodo.

As demais linhas so os campos do cabealho da mensagem REGISTER, e

trazem informaes relevantes identificao e localidade do usurio requisitante,
bem como a forma de realizar o registro no servidor.

Dependendo do tipo da mensagem SIP, h campos que so obrigatrios. No

caso de mensagens de registro como a transcrita acima, segundo a RFC3261, os
campos obrigatrios so:

Call-ID: contm um identificador nico da transao. Esse nmero gerado

pelo solicitante e deve ser diferente a cada pedido de uma nova transao;
 8

CSeq: formado por um nmero de sequncia que deve ser incrementado a

cada pedido. Tambm informa o mtodo no qual o nmero de sequncia se
refere;
From: traz informaes de localizao do requisitante;
Max-Forwards: em caso de utilizao de proxies entre o requisitante e o
servidor, este nmero decrementado a cada passagem por um proxy,
evitando assim laos infinitos;
To: onde o servidor coleta a informao de qual o usurio que est
solicitando o registro. Normalmente o campo From contm os mesmos
valores presentes no campo To;
Via: traz informaes por quais estaes a mensagem passou. No caso de
haver somente um campo Via, a informao refere-se ao endereo IP e a
porta onde o usurio est.

Dependendo da forma de registro que est sendo feita, outros campos so

obrigatrios, por exemplo, quando o servidor solicita uma autenticao para realizar
o registro. Nesse caso, o campo Authorization necessrio e ir trazer
informaes da autenticao solicitada pelo servidor e a senha criptografada que
dar acesso ao pedido de registro.

Outros campos so opcionais e trazem informaes adicionais sobre o

usurio requisitante:

Contact: contm informaes de rota para acesso ao usurio requisitante,

como o endereo IP e a porta;
Expires: informa o tempo em segundos que o solicitante do registro deseja
que o servidor considere vlido. Durante esse tempo o servidor de registro ir
manter as informaes do pedido em sua tabela, devendo o solicitante gerar
um novo pedido antes que o tempo acabe, renovando a tabela do servidor;
User-Agent: contm o nome do agente que gerou a mensagem. Geralmente,
a identificao do aplicativo que est sendo utilizado e a verso do mesmo;
Content-Length: informa o tamanho em bytes do corpo da mensagem. No
caso de uma mensagem de registro, como no h nenhum dado no corpo da
mensagem, o valor informado zero.

2.1.1.2 Mensagem de requisio de incio de sesso

A mensagem de INVITE utilizada quando um UAC deseja iniciar uma

sesso de voz, vdeo ou texto com outro agente. Ela pode ser enviada diretamente
ao destino com o qual se deseja estabelecer a sesso, ou pode passar por um
servidor proxy, que a encaminhar ao destino final. Assim como na transao de
pedido de registro, a mensagem de INVITE somente a primeira que d incio ao
processo. Outras mensagens so trocadas entre o UAC e o destino para dar
continuidade at a finalizao da transao de incio de sesso. Tais mensagens
sero mostradas na Seo 2.4 que cita exemplos de fluxos de mensagens SIP.
 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.

INVITE sip:201@192.168.1.35 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.33:5060;branch=z9hG4bK712315B3AC61DA1
From: PCS200 <sip:200@192.168.1.35>;tag=27392778
To: <sip:201@192.168.1.35>
Contact: <sip:200@192.168.1.33:5060>
Call-ID: 7774DCEB-FB21-7874-CDE4-811205A05075@192.168.1.33
CSeq: 30067 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite release 1105d
Content-Length: 308

v=0
o=200 4223007348 4223007351 IN IP4 192.168.1.33
s=X-Lite
c=IN IP4 192.168.1.33
t=0 0
m=audio 8000 RTP/AVP 0 8 3 98 97 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:3 gsm/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:97 speex/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

Figura 2 Exemplo de mensagem de abertura de sesso.

 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 User-
Agent. 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.

2.1.1.3 Mensagens de resposta

Uma mensagem SIP de resposta aquela gerada por um UAS ou por um

servidor para responder a uma requisio de um UAC. Ela pode conter campos
adicionais com informaes necessrias ao UAC ou somente reconhecer o
recebimento da requisio, evitando retransmisses pelo UAC. Muitas das
mensagens de resposta tambm levam o UAC a movimentar sua mquina de estado
de controle da transao.

As mensagens de resposta so divididas em seis classes e tm sua utilizao

de acordo com a requisio em andamento e o estado da mesma. Os tipos de
classes so mostrados na Tabela 2.
 11

Classe Descrio Ao

1xx Informativa Indica o status da chamada antes da concluso. Se for

primeira resposta, informativa ou provisional.

2xx Sucesso A requisio foi bem sucedida. Se for um INVITE, um

ACK deve ser enviado, seno interrompe a
retransmisso da requisio.

3xx Redirecionamento O servidor retornou outros possveis locais. O cliente

pode repetir a requisio em outro servidor.

4xx Erro pelo cliente A requisio falhou por um erro do cliente. O cliente
deve repetir a requisio, reformulando-a com os
parmetros da mensagem de resposta.

5xx Falha do servidor A requisio falhou por um erro do servidor. O cliente

deve repetir em outro servidor.

6xx Falha global A requisio falhou. A requisio no deve ser enviada

novamente a nenhum servidor.

Tabela 2 Tipos de mensagens de resposta.

2.2 SDP

Aps o fim do cabealho do exemplo da mensagem de requisio de incio de

sesso da Figura 2, aparecem, no corpo da mensagem de INVITE, as informaes
relativas sesso que o UAC deseja estabelecer [RS02b]. Esse outro protocolo
chamado de SDP, tendo na primeira linha a informao v=0, que o primeiro campo
obrigatrio do SDP.

O SDP, definido pela RFC2327 [HAN98], composto por uma srie de linhas,
denominadas de campos, cujos nomes so abreviados por uma nica letra e esto
numa ordem estabelecida para facilitar o trabalho do interpretador.

A Tabela 3 lista os possveis campos do SDP, quais so obrigatrios, os que

so opcionais e faz uma breve descrio sobre cada um.
 12

Campo Nome Obrigatrio

v= Verso do protocolo Sim

o= Criador e identificador da sesso 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= Informaes do consumo de banda No

t= Tempo de incio e finalizao da sesso Sim

r= Nmero de repeties No

z= Correes de fuso horrio No

k= Chave de criptografia No

a= Linha de atributos da sesso No

m= Informaes da mdia No

a= Atributos de uma mdia No

Tabela 3 Campos do SDP.

No exemplo da mensagem de INVITE, os campos que so obrigatrios do

SDP so especialmente tratados pelo UAS que recebe a requisio. a partir
desses campos que so extradas as informaes de quais codificadores podero
ser utilizados, alm dos endereos IP e porta destinos para o fluxo de mdia. Abaixo,
os campos que merecem uma ateno especial:
 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

O RTP foi desenvolvido para permitir o transporte de pacotes em tempo real

contendo voz, vdeo ou outra informao sobre IP. Esse protocolo foi definido pelo
IETF e est descrito na RFC3550.

O RTP no fornece nenhuma qualidade de servio por si s atravs da rede,

pois os pacotes so tratados da mesma forma que todos os outros na rede [PER03].
Porm ele permite a deteco de problemas introduzidos pela rede IP, como:
Perda de pacotes;
variaes de atraso no transporte (jitter);
pacotes chegando fora da sequncia em que foram enviados.

Os dados dos pacotes RTP no esto em formato de texto, mas sim binrio,
como os cabealhos do UDP e do IP. O RTP foi projetado para ser bastante
genrico e alguns campos do cabealho no so utilizados por determinadas
aplicaes. A verso atual do protocolo a de nmero 2 e o formato do cabealho,
composto por 12 octetos, mostrado a seguir:

bit offset 0-1 2 3 4-7 8 9-15 16-31

0 V P X CC M PT Sequence Number
32 Timestamp
64 SSRC identifier
96 CSRC identifiers
96 + 32*CC Profile-specific extension Extension header length
header ID
128 + 32*CC 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 Exemplos de Fluxos de Mensagens SIP

Abaixo, alguns exemplos de fluxo de mensagens SIP [JOH03]. Neles, ser

mostrado somente um diagrama da troca de mensagens entre o UAS e o UAC.

Como em qualquer outro protocolo, muitas temporizaes esto envolvidas

numa troca de mensagens entre dois agentes SIP, principalmente quando o
protocolo de transporte o UDP. Nos diagramas abaixo, no so mostrados os
 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.

2.4.1 Pedido de registro

Nesta transao o cliente solicita ao servidor o registro de seu usurio,

informando o IP e a porta onde pode ser localizado. Essas informaes sero
armazenadas pelo servidor em uma tabela de registro e sero utilizadas por ele
quando for necessrio contatar esse cliente novamente. No caso especfico do
exemplo da Figura 4, o servidor solicita uma autenticao ao usurio antes de
confirmar o registro.

UAC UAS Mensagem

Register M1
100 Trying
M2
401 Unauthorized
M3
Register
M4
100 Trying
M5
200 OK
M6

Figura 4 Fluxo de mensagens para pedido de registro.

M1: mensagem que d incio requisio de registro no servidor.

M2: enviada pelo UAS para indicar que recebeu a solicitao de registro do
UAC, e que para este movimentar sua mquina de estado e interromper a
retransmisso do pedido de registro.
 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.

2.4.2 Estabelecimento de sesso

Neste exemplo de estabelecimento da sesso so mostradas todas as

mensagens trocadas entre um cliente e um servidor, at a ltima mensagem de
atendimento (M7) e o incio do fluxo RTP, simbolizado somente por duas setas (M9
e M10).

Especificamente nesse caso, o UAS est solicitando autenticao do UAC

para que o estabelecimento da sesso continue. Isso uma configurao feita no
UAS. A Figura 5 mostra esse exemplo.

UAC UAS Mensagem

Invite com SDP
M1
407 Proxy Auth. Req.
M2
ACK
M3
Invite com SDP M4
100 Trying M5
180 Ringing M6
200 OK com SDP M7
ACK M8
RTP M9
RTP M10

Figura 5 Fluxo de mensagens para estabelecimento de sesso.

M1: o UAC solicita ao UAS o incio de uma negociao de uma sesso de

mdia. Essa mensagem contm em seu corpo o SDP, que utilizado para
detalhar informaes sobre os codificadores, endereo IP e porta que sero
utilizados durante o fluxo de mdia.
M2: aqui o UAS solicita que o UAC se autentique, de uma forma semelhante
como foi feito na mensagem M3, no exemplo de pedido de registro.
M3: o cliente confirma e entende a mensagem anterior.
 18

M4: um novo pedido gerado com os dados de autenticao solicitados pelo

servidor.
M5: uma mensagem provisional enviada pelo UAS para indicar que recebeu e
est processando a solicitao.
M6: indica que o alvo da sesso est sendo sinalizado do pedido de abertura
de sesso.
M7: indica que o alvo atendeu ao pedido de abertura de sesso. Como parte
do segundo passo da negociao de informaes de SDP, o UAS envia
nessa mensagem qual ou quais os codificadores que poder trabalhar
durante o fluxo de mdia, alm do endereo IP e porta para envio dos pacotes
RTP pelo outro lado.
M8: o UAC concorda com a deciso do UAS com relao finalizao da
negociao dos codificadores.
M9: apenas ilustrativo, indica que o fluxo de RTP est presente no sentindo
do UAS para o UAC.
M10: apenas ilustrativo, indica que o fluxo de RTP est presente no sentido
do UAC para o UAS.

O fluxo RTP entre o UAC e o UAS somente representa a presena da mdia

estabelecida na sesso, porm ela tambm pode acontecer envolvendo outros
elementos chamados media gateways, que no so agentes usurios, mas sim,
conversores de mdia.

2.4.3 Finalizao de sesso

A finalizao da sesso composta, no exemplo da Figura 6, somente pelas

mensagens M11 e M12. A terminao da sesso pode ser iniciada pelo o UAS ou
pelo UAC. As outras mensagens acima da mensagem M11 so mostradas apenas
para contextualizar.

UAC UAS Mensagem

Invite com SDP
M1
407 Proxy Auth. Req.
M2
ACK
M3
Invite com SDP M4
100 Trying M5
180 Ringing M6
200 OK com SDP M7
ACK M8
RTP M9
RTP M10
BYE M11
OK M12

Figura 6 Finalizao de sesso.

 19

M1 a M10: conforme descrito no exemplo de estabelecimento de sesso.

M11: o UAC solicita o encerramento da sesso e do fluxo RTP com o UAS.
Essa mensagem poderia ter sido gerada pelo UAS, se ele tivesse encerrado a
chamada primeiro.
M12: o UAS confirma o encerramento da sesso e do fluxo RTP.

2.4.4 Cancelamento de sesso

O cancelamento da sesso, neste exemplo, d-se a partir da mensagem M4.

O processo de cancelamento da sesso pode ser iniciado pelo UAC ou pelo UAS,
embora, nesse ltimo caso, dependa de funes do aplicativo ou aparelho SIP para
cancelar uma chamada recebida sem que antes haja o atendimento da mesma.

No exemplo da Figura 7, pode-se notar que o UAS no solicitou autenticao

para o UAC para prosseguir a sesso.

UAC UAS Mensagem

Invite com SDP M1
100 Trying M2
180 Ringing M3
Cancel M4
487 Request Terminated M5
200 OK M6
ACK M7

Figura 7 Cancelamento de sesso.

M1 a M3: conforme descrito no exemplo de estabelecimento de sesso.

M4: o UAC solicita o cancelamento do processo de abertura da sesso.
M5: o UAS informa que a requisio foi terminada.
M6: o UAS informa que a requisio de abertura de sesso foi cancelada.
M7: o UAC confirma o recebimento da mensagem anterior.
 20

3 Trabalhos Relacionados
Os trabalhos aqui citados so ferramentas com caractersticas semelhantes
ao VoIPFix, sendo o ltimo deles, o SIP Automatic Debugger, um trabalho
acadmico.

Existem atualmente muitos aplicativos com o propsito de capturar e analisar

pacotes de uma rede de computadores. Alguns deles so gratuitos, com o cdigo
fonte aberto e outros so comerciais. O objetivo deste captulo citar algumas
caractersticas da parte de anlise SIP e RTP de alguns desses aplicativos e fazer
uma comparao com o propsito do desenvolvimento do VoIPFix.

3.1 Wireshark

O projeto do Wireshark [WIREa], comeou em 1998, com o nome de Ethereal.

Esse aplicativo talvez seja o analisador de protocolos de rede mais conhecido e
utilizado ao redor do mundo, com vrias caractersticas, incluindo uma gama
razovel de ferramentas para anlise de voz sobre IP, alm de ter cdigo fonte
aberto com licena GPL. Algumas de suas principais caractersticas so:

Analisa vrios tipos de protocolos de rede;

permite analisar os pacotes durante a captura;
pode ser executado em diversas plataformas como Windows, GNU/Linux,
Mac OS X, Solaris entre outros;
possui uma boa quantidade de ferramentas para anlise de dados de voz
sobre IP;
l e escreve os dados capturados em diversos formatos de arquivos que
podem ser utilizados em outros programas similares;
grava mltiplos arquivos de acordo com o tamanho ou tempo decorrido da
captura;
possui filtros de captura e exibio de pacotes de acordo com endereos IP,
portas ou tipos de protocolos.

A seguir, algumas caractersticas importantes desse aplicativo sero

detalhadas, no que se refere ao tratamento e anlise de pacotes relacionados a
VoIP. As caractersticas citadas levam em conta somente os protocolos SIP e RTP.

3.1.1 Anlise dos campos de mensagens

Todas as mensagens podem ser analisadas de uma forma mais profunda,

permitindo visualizar cada campo e seus parmetros de forma clara. Essa
caracterstica permite que o usurio copie para a rea de trabalho partes especficas
das mensagens, alm de poder criar filtros para exibir mensagens que pertenam
mesma transao.
 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:

Usurio origem e destino da chamada;

endereo de origem da chamada;
nmero de pacotes que a transao possui;
qual o estado em que a transao ficou aps a ltima mensagem capturada.

3.1.3 Grfico de transaes de chamada

Recurso que permite a visualizao de todas as mensagens de uma

transao de chamada de forma grfica, semelhante ao que foi mostrado na Figura
6.

Ainda, ao clicar em cada seta que corresponde a uma mensagem SIP ou RTP
da chamada, o Wireshark ir procurar a mensagem na lista de pacotes capturados e
exibir seus campos.

possvel exibir mais de uma transao ao mesmo tempo atravs desse

grfico, fazendo selees mltiplas na lista de exibio. Com esse recurso, o usurio
pode analisar transaes de chamada diferentes, mas que tm uma relao comum,
por exemplo, uma chamada entre dois elementos IP num sistema de telefonia.

3.1.4 Reprodutor de udio de chamadas

Caso a chamada tenha se estabelecido com o codificador G.711 [ITU72], o

Wireshark consegue reproduzir o udio da conversao ocorrida durante a ligao.
Outros codificadores no so suportados pelo aplicativo.

O udio reproduzido de acordo com os dados que foram capturados,

podendo levar em considerao o parmetro de jitter buffer, que pode ser
configurado no aplicativo para que ele descarte pacotes com valores de jitter
superiores ao determinado pelo usurio. Essa facilidade faz com que o udio
reproduzido seja mais prximo ao que o usurio ouviu realmente, j que o aplicativo
ir descartar pacotes da mesma forma que o equipamento receptor faria.

Ainda dentro da parte de reproduo do udio, possvel visualizar um

grfico com a forma de onda do udio contido nos pacotes. Alm disso, o usurio
pode perceber onde houve momentos de silncio, bem como pontos de perda de
pacotes, que so ressaltados pelo Wireshark atravs de trechos vermelhos na forma
de onda.
 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.1.5 Anlise de pacotes RTP

Com a anlise de pacotes possvel examinar os seguintes parmetros:

Nmero de pacotes transmitidos e/ou recebidos;

porcentagem de perda de pacotes;
tempo mximo entre pacotes consecutivos;
jitter;
erros de sequncia.

Apesar de o Wireshark possuir poucas funcionalidades para anlise de

pacotes de VoIP, ele tem um importante papel no mundo de anlise de redes de
computadores e de telefonia IP.

O objetivo deste trabalho desenvolver uma ferramenta que implemente

todas as caractersticas listadas acima, no que se refere ao tratamento de pacotes
SIP e RTP, porm com outras caractersticas essenciais para um profissional que
trabalhe com VoIP. Essas outras caractersticas sero listadas no Captulo 4.

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:

Lista com as ligaes bem-sucedidas e motivos de insucesso;

consumo de banda de rede atravs de grficos;
lista com as chamadas e parmetros como perda de pacotes, jitter, qualidade
de cada chamada;
grficos que mostram o trfego de pacotes de VoIP para cada mquina;
grficos com nmero de ligaes por mquina ou usurio;
relatrios detalhados em diversos formatos de arquivos.
 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 SIP Automatic Debugger

O SIP Automatic Debugger [BAO09] uma ferramenta desenvolvida em C

para ambiente Windows e composta por trs mdulos que operam em sequncia,
como descrito nos itens abaixo:

Sniffer: desenvolvido utilizando a biblioteca WinpCap, responsvel por

capturar os pacotes da rede e selecionar os pacotes SIP dentre os
capturados.
Analisador: classifica as mensagens SIP baseando-se nas transaes e
dilogos que ocorrem durante o processo de captura.
Controlador: responsvel por verificar o fluxo de mensagens por comparao
com um conjunto de regras previamente carregado no aplicativo.
O princpio desse aplicativo analisar cenrios, comparando comportamentos
conhecidos de equipamentos. Nesse caso, os cenrios de testes devem ser
carregados previamente, podendo ento verificar se algo est fora do
comportamento esperando, como ausncia de campos nas mensagens SIP ou
temporizaes incorretas.
Alm disso, ele foi desenvolvido para testar e avaliar a interoperabilidade
entre equipamentos, determinando fontes de incompatibilidades, identificando falhas
e preparando um roteiro para resoluo de problemas.
 24

4 VoIPFix

O projeto do VoIPFix surgiu da necessidade de uma ferramenta que

complementasse as demais existentes no ramo de anlise de rede de computadores
e telefonia IP. Profissionais que trabalham nesse mercado podem possuir
conhecimento limitado das tecnologias e protocolos dos equipamentos de VoIP, pois
algo muito especfico desse tipo de tecnologia.
Aplicativos como o Wireshark e o Cace Pilot foram desenvolvidos com
objetivos mais amplos, cobrindo uma gama maior de protocolos e aplicaes de
redes de computadores. As ferramentas de VoIP nesses programas fazem parte de
um conjunto de funcionalidades maior, no sendo o objeto alvo de sua utilizao.
O Wireshark poderia ter sido utilizado como base no desenvolvimento desse
trabalho, sendo alterado para a criao de novas funcionalidades. Essa deciso no
foi tomada, pois ele foi construdo para trabalhar com apenas um thread, mesmo em
sistemas multicore. Alm disso, para que ele se tornasse uma ferramenta eficiente,
como o VoIPFix, mudanas mais drsticas teriam que ser feitas como, por
exemplo, a substituio do interpretador de mensagens SIP. Fatores como esses
fizeram optar por no utiliz-lo.
O VoIPFix foi construdo com propsito nico de ser uma ferramenta de
gerenciamento exclusiva para VoIP, possuindo somente as funcionalidades
necessrias para dar suporte ao usurio a observar e diagnosticar problemas de
telefonia IP.
As ferramentas do VoIPFix foram elaboradas para guiar o usurio a realizar a
anlise partindo de uma viso macro das ocorrncias, passando por funcionalidades
que trazem informaes, relatrios e estatsticas, at chegar aos pacotes que
compem uma determinada transao. Essa abordagem permite que os usurios de
pouca experincia utilizem a ferramenta at o nvel adequado do seu conhecimento,
no deixando os usurios avanados sem as ferramentas de anlise mais
profundas.
Ele possui as seguintes caractersticas principais:

Captura e anlise eficiente de mensagens de sinalizao SIP e pacotes RTP

de udio;
exibio de relatrios com diagnsticos de ocorrncias das transaes de
registro e chamadas que foram capturadas;
identificao dos problemas mais comuns que ocorrem num sistema de
telefonia IP relativos sinalizao e ao fluxo de mdia.

Os usurios dessa ferramenta podem ser:

profissionais do ramo de telefonia, que possuem bons conhecimentos dessa

atividade, mas no possuem total domnio de redes de computadores;
analistas de redes de computadores, que possuem a formao necessria
para tal atividade, mas no tm experincia em telefonia convencional e IP;
 25

profissionais que trabalham em empresas prestadoras de telefonia IP, para

monitorao e acompanhamento dos servios oferecidos;
instaladores de equipamentos de VoIP, pois a ferramenta possui uma
interface simplificada para esse tipo de profissional.

O local de sua instalao depende das necessidades do usurio, mas na

maioria dos casos ideal que ele seja colocado junto ao PBX IP ou aos terminais
SIP de interesse. Isso pode ser feito configurando os elementos de rede, como
switches a espelharem as portas desses equipamentos para o VoIPFix.

A essncia do VoIPFix permitir que usurios que no tenham conhecimento

detalhado em protocolos de sinalizao e mdia possam analisar, identificar e
apontar possveis problemas em uma rede com servio de VoIP. Porm, ainda
oferecer facilidades para exame profundo das mensagens SIP e RTP, assim como
feito com o Wireshark, j que nem todos os problemas podero ser identificados
automaticamente pelo VoIPFix, ficando, ainda, a cargo do usurio analista,
interpretar os dados de um problema mais complexo.

4.1 Arquitetura

Nesta seo ser descrita a arquitetura do VoIPFix, estudando os principais

mdulos da implementao do aplicativo. Os detalhes de implementao de cada
mdulo e de cada funcionalidade sero descritos na Seo 4.4.
O VoIPFix foi construdo com o conceito de programao orientada a objetos,
utilizando a linguagem C++. Ele composto por 25 classes contendo 9542 linhas de
cdigo espalhadas por 49 arquivos.
A Figura 8 mostra os mdulos principais da arquitetura de construo do
VoIPFix.
 26

Figura 8 Arquitetura do VoIPFix.

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

aviso ao mdulo de hierarquia superior sobre a chegada de um novo pacote

em uma interface de rede ou de um arquivo aberto, dependo do que foi
instrudo para ser feito.

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:

Anlise do cabealho Ethernet da camada de enlace e verificao se o

protocolo utilizado na camada de rede do pacote o IP. Isso deve ser feito,
pois todos os pacotes de voz sobre IP utilizam esse protocolo como camada
de rede;
verificao do cabealho IP, se o protocolo de transporte utilizado o UDP,
pois, como dito, o VoIPFix somente analisa pacotes sobre esse protocolo de
transporte;
coleta das informaes de endereo IP e porta de origem e destino desse
pacote, pois a informao ser essencial aos mdulos de anlise de
transaes;
 28

verificao se os dados transportados pelo pacote no payload UDP pertence

a um pacote SIP. Isso feito analisando a primeira linha do texto, em busca
de palavras chaves e combinaes caractersticas de um pacote SIP. O
passo economiza processamento, pois elimina pacotes previamente
marcados como no SIP do passo de interpretao propriamente dito;
envio de um pacote SIP ao processo de interpretao, o que transforma o
texto da mensagem em uma estrutura padro, podendo ser analisada de
forma mais eficiente pelos mdulos de anlise. Esse processo de
interpretao realizado pela biblioteca oSIP. Caso o pacote no seja SIP,
ainda h a possibilidade dele ser RTP, que no um protocolo que carrega
mensagens em formato texto. Nesse caso, no possvel ter certeza
absoluta se um pacote ou no RTP, mas alguns testes so feitos a fim de
verificar a sua integridade e marc-lo. Os demais pacotes, que no foram
marcados como SIP nem RTP, so descartados para no ocuparem espao
em memria.

Quando o VoIPFix est sendo utilizado para abrir arquivos salvos em um

disco, esse mdulo executa o procedimento descrito acima em mltiplas tarefas
concorrentes, visando a economia de tempo de processamento e o total
aproveitamento dos recursos da mquina hospedeira.

4.1.3 Detector de transaes

Mdulo responsvel por identificar os pacotes SIP e RTP de uma mesma

transao, para que possa ser feita anlise de estados de fechamento, clculos e
estatsticas pelo mdulo analisador. Essa tarefa executada quando o VoIPFix
recebe pacotes de uma interface de rede e quando recebe pacotes de um arquivo
sendo aberto do disco.

A tarefa de agrupar os pacotes SIP e RTP de uma mesma transao revelou

as vantagens do VoIPFix em relao ao Wireshark, no que diz respeito eficincia
de anlise, facilidade ao usurio do aplicativo, alm de facilidade estrutural para o
crescimento de novas funcionalidades ao VoIPFix.

As funcionalidades de exibio de grfico das transaes e exibio de

pacotes utilizam as informaes geradas por esse mdulo, uma vez que elas
necessitam justamente que os pacotes de uma mesma transao estejam
agrupados de forma organizada.

Da mesma forma como feito no mdulo interpretador, o VoIPFix realiza o

trabalho nesse mdulo com vrios threads concorrentes, ao abrir arquivos salvos em
disco, com o objetivo de economizar tempo de processamento.
 29

4.1.4 Analisador

O mdulo analisador realiza as tarefas de maior interesse ao usurio, como

por exemplo:

Identificao de problemas de sinalizao;

identificao de problemas de fluxo de mdia;
clculos de perda de pacotes, jitter e erros de sequncia em fluxos de mdia;
gerao de grficos de estatsticas, como fechamento de chamadas.

O analisador no utiliza vrios threads concorrentes para realizar o trabalho

descrito acima, j que isso deve ser feito de forma sequencial para cada transao a
ser analisada. O ganho de tempo com utilizao de tarefas concorrentes no seria
significativo nesse caso, alm de trazer uma grande dificuldade na sua
implementao.

4.1.5 GUI

A interface grfica de usurio (GUI) foi desenvolvida de modo a atingir os

seguintes objetivos principais:

Proporcionar a usurios com menos experincia em protocolos de VoIP,

facilidades que no so encontradas em outras aplicaes do mesmo tipo;
ter um caminho de utilizao de modo que as telas com informaes mais
ricas em contedo, e tambm mais complexas, sejam acionadas sob
instruo do usurio, caso esse necessite;
tornar a utilizao mais eficiente e rpida, sem exibir grande quantidade de
informao nos primeiros momentos da abertura de arquivos em disco. As
telas que trazem grande quantidade de pacotes s so exibidas se o usurio
assim necessitar;
ter poucos controles, mas com funcionalidades especficas e eficientes, sem
necessitar de muitos ajustes ou configuraes por parte dos usurios;
exibir relatrios e estatsticas de forma clara e concisa, trazendo apenas
informaes bsicas que o usurio deseja. Informaes mais avanadas s
aparecem sob instruo do usurio.

Apesar de os objetivos acima citados terem sido atingidos na primeira verso

do VoIPFix, muitas facilidades devero ser adicionadas ao aplicativo, de modo a
torn-lo ainda mais amigvel e eficiente, tanto para usurios leigos como para
usurios avanados. A seo de trabalhos futuros trata de ideias de
aperfeioamento para a aplicao.

A Figura 9 mostra a interface grfica do VoIPFix com as janelas principais

abertas.
 30

Figura 9 Interface grfica do VoIPFix.

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:

Tratar os comandos enviados pelo usurio atravs da interface grfica at os

mdulos responsveis por execut-los;
armazenar as configuraes do sistema realizadas pelo usurio;
direcionar o fluxo de pacotes do capturador at o analisador, quando
necessrio;
direcionar as transaes de interesse do mdulo de transaes at o mdulo
analisador;
gerenciar a forma de utilizao da aplicao (captura de pacotes atravs de
uma interface de rede ou abertura de arquivos salvos em disco).

Esse mdulo funciona como um maestro da aplicao inteira, cuidando ainda

da abertura de janelas de forma automtica na interface grfica de usurio e
tambm no gerenciamento dos objetos utilizados por elas.

4.2 Funcionalidades

O VoIPFix foi construdo com o objetivo de ser uma ferramenta de anlise de

telefonia IP, com recursos especficos para esse tipo de aplicao de redes de
computadores. A premissa inicial era se tornar totalmente capaz de ser utilizado
como ferramenta nica de avaliao e investigao de protocolos de sinalizao e
transporte de mdia, sem a necessidade de outras aplicaes. Por esses motivos,
 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.

4.2.1 Captura de pacotes

a) Necessidade:

Para que o VoIPFix no dependa de outros aplicativos para realizar a captura

de pacotes, que, dentre outros motivos, necessitaria de instalao, configurao e
operao de dois programas diferentes, essa funcionalidade foi implementada na
ferramenta. Alm disso, muitas funes so executadas durante o processo de
captura, oferecendo informaes de anlise em tempo de captura.

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:
Endereo IP de origem ou destino;
protocolo de transporte;
endereo MAC de origem ou destino.

Ele realiza a captura dos pacotes em modo promscuo, ou seja, so

capturados todos os pacotes que passam pela interface de rede escolhida, mesmo
que o pacote no tenha como destino essa interface de rede.

Na barra de menus da aplicao, o item Captura permite iniciar ou parar um

processo de captura. A opo Iniciar mostra a tela da Figura 10.

Figura 10 Tela para iniciar captura de pacotes.

 32

Os componentes dessa tela so:

Interface: lista as interfaces de rede disponveis no sistema, para que o

usurio selecione qual deseja capturar os pacotes.
Filtro: permite especificar o filtro de pacotes, atravs da sintaxe utilizada pela
biblioteca de captura, a ser utilizado durante o processo de captura.

4.2.2 Anlise de pacotes de forma eficiente em plataformas multicore

a) Necessidade:

A anlise de arquivos de captura muito extensos, da ordem de algumas

dezenas de megabytes, normalmente lenta, devido ao grande nmero de pacotes
capturados. Isso acontece quando a coleta dos dados foi feita em uma rede de
grande fluxo ou foi realizada durante um intervalo de tempo muito longo.

O VoIPFix foi concebido para ser uma ferramenta eficiente de anlise. Como
atualmente a maioria dos computadores possuem processadores multicore, a
ferramenta foi construda para aproveitar ao mximo o poder de processamento
desses sistemas.

Nos testes de desempenho, mostrados na Seo 4.5 Testes de , fica

claro o ganho de eficincia do VoIPFix em relao a outras ferramentas, na abertura
e anlise de arquivos grandes.

b) Funcionamento:

Em plataformas com processador multicore, o VoIPFix tem o desempenho de

processamento dos pacotes aumentado, utilizando-se dessa caracterstica para
realizar a anlise em mais de uma tarefa paralelamente.

Certas funcionalidades, como interpretar os pacotes de VOIP para montagem

das informaes das transaes, podem ser executadas em mais de uma thread ao
mesmo tempo dentro do programa. Isso traz um ganho de desempenho
considervel para o VoIPFix.

O VoIPFix est preparado para plataformas multicore e, por isso, ter um

desempenho maior do que o Wireshark, que, mesmo em plataformas com mais de
um ncleo, acaba utilizando somente um para realizar o processamento dos pacotes
[WIRb].

Quando o usurio abre um arquivo capturado, que contm um tamanho acima

de algumas unidades de MBytes, ele pode perceber o trabalho do VoIPFix, sendo
realizado em mais de uma thread, como mostra a Figura 11.
 33

Figura 11 Analisando pacotes em mais de um thread.

O nmero de threads mostrado nessa tela apenas com intuito informativo,

indicando quantas tarefas concorrentes esto sendo executadas para tratar o
arquivo que est sendo aberto. Esse nmero representa a quantidade de ncleos do
processador disponveis do sistema.

4.2.3 Anlise durante o processo de captura

a) Necessidade:

Em certos casos, o usurio necessita capturar os dados e, ao mesmo tempo,

salv-los em arquivos, mas tambm deseja realizar a anlise de algumas situaes
ou problemas que esteja interessado em detectar durante esse processo. Para isso
o aplicativo realiza a interpretao dos pacotes durante a captura.

b) Funcionamento:

O VoIPFix permite que os pacotes sejam analisados durante o processo de

captura, e, assim, realizar muitas tarefas paralelamente captura. Essa
caracterstica importante para situaes em que necessrio identificar uma
situao desejada pelo usurio em tempo real, sem a necessidade de salvar em um
arquivo para uma anlise posterior.

Todas as ferramentas do VoIPFix podem ser executadas durante o processo

de captura, com base nos pacotes capturados at o momento da utilizao de cada
funcionalidade. Porm, at o momento da escrita deste trabalho, somente a tela que
lista as transaes atualizada durante a captura. Ser proposto um mecanismo
que atualiza as demais telas durante esse processo, sem que haja a necessidade de
fechar e reabrir as telas correspondentes, como acontece com no Wireshark.

4.2.4 Anlise de mltiplos arquivos gravados sequencialmente

a) Necessidade:

Para que no sejam gerados arquivos muito extensos, muitos aplicativos de

captura so configurados para salvar os dados em vrios arquivos gravados
sequencialmente. Isso traz o benefcio de no tornar o processo de anlise muito
 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.

4.2.5 Exibio de lista de transaes

a) Necessidade:

Para usurios com menor conhecimento sobre os protocolos, difcil realizar

anlises e localizar as transaes olhando para vrios pacotes em uma lista.
necessrio que a ferramenta agrupe essas mensagens de acordo com as
transaes s quais elas pertenam.

b) Funcionamento:

No VoIPFix, quando o usurio abre um arquivo ou inicia uma captura, a

primeira tela que aparece a lista de transaes. Dessa forma ele comea a realizar
a anlise partindo das transaes SIP que possui, e no a partir de uma lista de
pacotes, que muitas das vezes confunde at mesmo usurios experientes.

A Figura 12 mostra o resultado da abertura de um arquivo qualquer, que

contm vrias transaes.
 35

Figura 12 Tela com a lista de transaes.

As informaes apresentadas nessa tela so:

Nmero: indica o nmero da transao na lista;

Incio: hora de incio. Esse o tempo em que a mquina capturou o primeiro
pacote da transao;
Tipo: tipo da transao. As duas principais so REGISTER e INVITE, que
respectivamente, indicam transao de registro e chamada;
IP Origem: o endereo IP de origem do primeiro pacote. Normalmente o
endereo do UAC que solicitou a requisio ao UAS;
Usurio Origem: usurio que originou a requisio ao UAS. No caso de um
pedido de registro, esse o usurio que ir se autenticar, enviando
informaes de localizao;
IP Destino: endereo IP destino do primeiro pacote. Geralmente o endereo
do UAS que recebe a requisio enviada pelo UAC;
Usurio Destino: o usurio alvo da requisio. Quando um pedido de
registro, o campo tem o mesmo valor do usurio de origem. Em se tratando
de uma requisio de INVITE, o usurio alvo da chamada;
Estado: mostra o estado da requisio. Quando a tela representa as
informaes de um arquivo aberto, o campo mostra o estado da transao at
o fim do arquivo, pois ela pode no ter sido capturada totalmente. Ainda,
quando ela est sendo utilizada para captura de pacotes atravs de uma
interface de rede, o campo atualizado a cada mudana de estado da
transao.
 36

Outras funes so acionadas a partir dessa tela, so elas:

Exibio do grfico de transaes;

lista de pacotes das transaes;
relatrio com informaes de perda de pacotes, jitter, erros de sequncia,
erros de sinalizao e fluxo;
tela para reproduo do udio da chamada.

4.2.6 Exibio de detalhes das mensagens de sinalizao e voz

a) Necessidade:

Para usurios com grandes conhecimentos de protocolos de VoIP, a

utilizao de aplicativos que no exibem detalhes das mensagens e seus campos
desagradvel. Alm disso, previsto que nem todos os problemas sero
diagnosticados pelo VoIPFix num primeiro instante; dessa forma, qualquer usurio
necessita de acesso fcil aos detalhes das mensagens de sinalizao e voz.

b) Funcionamento:

O VoIPFix, como o Wireshark, exibe todos os campos das mensagens de

sinalizao e voz de forma detalhada, pois, como previsto, nem todos os
problemas e situaes sero cobertos por este trabalho, cabendo ao usurio utilizar-
se da facilidade para tentar identificar os problemas baseando-se no contedo dos
pacotes de sinalizao ou voz.

A facilidade mais adequada para usurios, que tenham um conhecimento

mais profundo dos protocolos de VoIP. Porm, interessante tambm para que
usurios com pouco conhecimento possam aprender mais sobre a tecnologia e
diagnosticar problemas mais complexos sem a ajuda do VoIPFix, nos casos que no
sero cobertos.

A Figura 13 mostra essa tela, que chamada selecionando-se as transaes

de interesse na tela da lista de transaes, clicando-se com o boto direito e
escolhendo a opo Pacotes. Quando mais de uma transao selecionada, todos
os pacotes sero exibidos na ordem em que eles foram capturados. Isso faz que os
pacotes das transaes fiquem misturados, o que normal, j que pode existir mais
de uma chamada ou registro acontecendo ao mesmo tempo.
 37

Figura 13 Tela com detalhes dos pacotes.

Essa tela apresenta dois conjuntos de informao. O primeiro, que fica na

parte superior, a lista com todos os pacotes das transaes selecionadas para
exibio. Nessa parte, tem-se as seguintes informaes:

Num: mostra o nmero do pacote como referncia em toda a lista;

Hora: hora em que o pacote foi capturado pela interface de rede do sistema;
Origem: endereo IP e porta de origem do pacote;
Destino: endereo IP e porta de destino do pacote;
Protocolo: o tipo do protocolo presente no pacote, que pode ser SIP, SIP/SDP
(para mensagens SIP que contm no corpo o protocolo SDP) ou RTP;
Informao: campo que traz uma srie de informaes, dependendo do tipo
do protocolo do pacote. Para mensagens SIP de requisio, a informao
nesse campo a linha de requisio. Para mensagens SIP de resposta, esse
campo traz o cdigo de resposta e a frase correspondente presente na
mensagem. Quando for pacotes RTP, esse campo mostra um resumo do
pacote, contendo o tipo do codificador de voz do pacote, SSRC, nmero de
sequncia e o timestamp do pacote.

A segunda parte dessa tela desmembra cada pacote selecionado na lista

superior da tela, seja do protocolo SIP ou do RTP.
No exemplo mostrado na figura acima, um pacote SIP foi selecionado. Nesse
caso, todos os campos do cabealho e do corpo, caso exista, so detalhados com
seus valores.
 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.

Figura 14 Grfico com transao de chamada.

 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

Figura 15 Grfico com transao de registro.

Essa tela muito semelhante tela de transao de chamada, e obviamente

no possui setas com fluxo RTP. As informaes nela contidas e seu
comportamento so semelhantes ao descrito anteriormente.

A Figura 16 mostra duas transaes ao mesmo tempo, a primeira, de registro

e, a segunda, de chamada.
 41

Figura 16 Grfico com transao de registro e chamada.

Quando duas transaes so exibidas na tela, as mensagens de cada uma

so apresentadas em cores diferentes, para que, assim, o usurio possa diferenciar
pacotes de transaes diferentes.

4.2.8 Exibio de grfico com nmero de transaes

a) Necessidade:

Em certos casos, interessante observar a quantidade de um determinado

tipo de transao em relao a outras, por exemplo, o nmero de requisies de
registro em relao ao nmero de chamadas. Isso pode auxiliar o analista do
sistema a detectar excessos de pedidos de registro ou outro tipo de requisio.

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

Figura 17 Grfico com nmero de transaes.

O grfico, em forma de barras horizontais, mostra a porcentagem em relao

ao total e, tambm, a quantidade absoluta no contexto de anlise.

No exemplo acima, pode-se observar uma grande quantidade de requisies

OPTIONS em relao a outras requisies.

Para acessar todos os tipos de grficos de estatsticas de requisies, o

usurio deve acessar a opo Estatsticas no menu Ferramentas.

4.2.9 Exibio de grfico com estatsticas de fechamento de chamadas

a) Necessidade:

Um dos indicativos de que um sistema de telefonia est se comportando bem

a porcentagem de chamadas com sucesso em relao s no completadas
corretamente. Essa informao deve ser exibida de forma clara e objetiva em um
grfico.

b) Funcionamento:

Essa funcionalidade til para exibir algumas estatsticas das causas de

fechamento de chamadas, contabilizando, por exemplo, quantas chamadas foram
completadas com sucesso, quantas foram canceladas, rejeitadas ou negadas.

A Figura 18 mostra um exemplo da funcionalidade:

 43

Figura 18 Grfico com estatsticas de fechamento de chamadas.

Com o grfico acima, o usurio pode observar como est a eficincia de

chamadas do sistema de telefonia IP e ainda ser alertado sobre um possvel
problema, caso o nmero de chamadas ocupadas ou negadas esteja alto.

Cada estado apresentado no grfico de fechamento de chamadas tem o

seguinte significado:

Terminada: chamadas onde o desligamento aconteceu de forma correta, com

o envio do BYE por uma das partes da transao;
Completada: chamadas onde aconteceu somente o atendimento com a
mensagem de resposta 200 OK. Provavelmente, o restante da transao no
foi capturado at o momento da anlise;
Ocupada: chamada no completada, pois o usurio estava ocupado. Nessa
situao, o UAS responde com a mensagem 486 Busy Here;
Cancelada: requisies de chamadas canceladas com a mensagem CANCEL
enviada por uma das partes, antes que acontecesse o atendimento pelo
chamado;
Negada: requisio que no chegou a ser completada, e que foi negada por
algum motivo, por exemplo, usurio ausente ou no encontrado;
No Autorizada: o servidor solicitou autenticao para o requisitante da
chamada, mas essa no foi autorizada. O UAS respondeu com a mensagem
401 Unauthorized ou 407 Proxy Authentication Required;
Mdia no suportada: situao onde o UAC envia uma requisio de chamada
com um codificador de voz ou vdeo no suportado pelo UAS e este envia a
mensagem de resposta 415 Unsupported Media Type. Em alguns casos
o UAS pode responder com essa mensagem quando no consegue entender
o SDP da mensagem de requisio ou de atendimento da chamada;
 44

Outras: qualquer outro estado da transao que no sejam nenhum dos

descritos acima.

4.2.10 Exibio de grfico de nmero de chamadas por usurio ou mquina

a) Necessidade:

Em certos casos interessante contabilizar a utilizao do sistema de

telefonia IP, considerando o nmero de chamadas de um determinado usurio ou
mquina na rede. Isso importante tambm para descobrir usurios que estejam
fazendo tentativas sucessivas de pedidos de chamadas e que no esto tendo
sucesso. Esse fato pode ser prejudicial ao sistema de telefonia IP e deve ser
cessado o quanto antes, para no congestionar os servidores.

b) Funcionamento:

O VoIPFix exibe vrios grficos discriminando a quantidade de transaes de

chamada de cada usurio ou mquina do sistema de telefonia IP.

A Figura 19 mostra o grfico de chamadas originadas pelos usurios, onde a

informao da primeira coluna o nmero do usurio, a segunda a porcentagem
de ligaes realizadas em relao ao total e a terceira o nmero absoluto de
chamadas.
 45

Figura 19 Grfico com o nmero de chamadas do usurio.

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

Figura 20 Grfico com nmero de chamadas para o usurio.

O VoIPFix exibe, ainda, grficos de chamadas relacionados s mquinas

presentes no sistema de telefonia IP, o que poder ser observado nos prximos
grficos.
A Figura 21 mostra o grfico com o nmero de chamadas que partiram dos
endereos IP das mquinas presentes no sistema:
 47

Figura 21 Grfico com nmero de chamadas do endereo.

Alm de trazer informaes sobre a utilizao do sistema de telefonia, em

termos de chamadas, o grfico acima tambm pode alertar sobre possveis ataques
vindos de um endereo IP especfico dentro ou fora da rede local dos equipamentos.
A Figura 22 mostra o grfico com o nmero de chamadas para os endereos
IP dos equipamentos no sistema:
 48

Figura 22 Grfico com nmero de chamadas para o endereo.

Da mesma forma, o analisador pode observar se um determinado

equipamento est com excesso de servio em relao ao nmero de chamadas que
esto sendo direcionadas a ele.

4.2.11 Exibio de grfico com estatsticas de pedidos de registros

a) Necessidade:

Avaliar somente as transaes de chamada nem sempre o suficiente para

diagnosticar problemas em um sistema de telefonia IP. Em algumas situaes,
analisar o comportamento dessas transaes necessrio para solucionar casos
relacionados ao servidor de registro.

b) Funcionamento:

O VoIPFix possui um grfico com a estatstica de pedidos de registro total do

sistema, apresentando a contabilidade das requisies que tiveram sucesso e as
que no foram completadas corretamente.

A Figura 23 mostra um exemplo da funcionalidade:

 49

Figura 23 Grfico com estatsticas de pedidos de registro.

Cada estado apresentado no grfico de pedidos de registro tem o seguinte

significado:

Completada: requisio de registro que foi bem-sucedida. Servidor de registro

respondeu com a mensagem 200 OK;
Negada: requisio que foi negada pelo servidor de registro, por exemplo,
quando ele no est aceitando pedidos de registros;
No Autorizada: o servidor solicitou autenticao para o requisitante do
registro, mas esse no foi autorizado. O UAS respondeu com a mensagem
401 Unauthorized;
No Encontrado: o servidor negou a requisio de registro com a mensagem
404 Not Found, indicando que o nome de usurio utilizado na requisio de
registro no existe;
Intervalo Muito Curto: o UAC fez uma requisio de registro ao UAS, com
intervalo de tempo muito curto e recebeu a mensagem 423 Interval Too
Brief como resposta, indicando que ele deve reformular um novo pedido
com o tempo mnimo informado nessa mensagem.

4.2.12 Exibio de grfico de nmero de registros por usurio ou mquina

a) Necessidade:

Avaliar a quantidade de pedidos de registro que um determinado usurio ou

mquina est enviando importante para verificar se no est havendo um nmero
de mensagens muito grande durante um intervalo de tempo, j que isso nem sempre
necessrio. Da mesma forma, importante verificar se um servidor de registro est
recebendo uma grande quantidade de requisies ou at mesmo um ataque de
vindo de um endereo IP desconhecido.
 50

b) Funcionamento:

O VoIPFix, na mesma janela de grficos com estatsticas, exibe as seguintes

informaes relativas requisies de registro:

Nmero de registros do usurio;

Nmero de registros do endereo IP;
Nmero de registros para o endereo IP.

No faz sentido existir um grfico mostrando o nmero de pedidos de registro

para um determinado usurio, como no grfico de nmeros de chamadas, pois no
h essa situao nas requisies de registro.

A Figura 24 mostra um exemplo do nmero de registros dos usurios.

Figura 24 Grfico com nmero de registros do usurio.

Nesse exemplo, o analisador poderia tomar atitudes para verificar o motivo

pelo qual o usurio de nmero 526 est realizando mais pedidos do que os demais.
Provavelmente ele est configurado com intervalo de tempo menor que os demais.
Se houvesse muitos desses casos em um sistema de telefonia IP, o servidor de
registros poderia ficar sobrecarregado.
A Figura 25 mostra um exemplo de grfico com o nmero de registros com
destino aos endereos IP:
 51

Figura 25 Grfico com nmero de registros do endereo.

Atravs do grfico acima, o analisador pode verificar os endereos IP com

maior nmero de pedidos de registro, podendo at indicar um ataque de requisies,
caso o endereo IP em questo seja desconhecido.

A Figura 26 mostra um exemplo do nmero de registros para os endereos

IP.

Figura 26 Grfico com nmero de registros para o endereo.

 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.

4.2.13 Filtro de transaes

a) Necessidade:

Em muitos dos casos, quando se tem uma grande quantidade de transaes

e deseja-se analisar somente alguns tipos especficos ou aquelas com determinados
usurios ou endereos, conveniente fazer uma filtragem para tornar o processo de
anlise mais limpo e rpido.

b) Funcionamento:

Atravs da lista de transaes, como descrito na Seo 4.2.6, essa

ferramenta permite ao usurio filtrar as requisies com base nos seguintes
parmetros:

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

Figura 27 Tela de filtro de transaes.

As opes selecionadas pelo usurio nessa tela sero aplicadas tela com a
lista de transaes, exibindo somente aquelas que corresponderem s opes
selecionadas.

4.2.14 Medio de jitter, perda de pacotes e erros de sequncia

a) Necessidade:

Uma das maiores preocupaes dos administradores dos sistemas de

telefonia IP identificar os possveis problemas causados por deficincias da
infraestrutura de rede, como perda de pacotes e latncia, fazendo um estudo dos
impactos na qualidade das ligaes de VoIP.

b) Funcionamento:

O VoIPFix traz informaes de jitter, perda de pacotes e erros de sequncia

nos fluxos RTP das chamadas, assim como feita em outras ferramentas do
gnero.

A partir da lista de transaes exibida no VoIPFix, o usurio pode selecionar

as transaes de chamada que deseja analisar, clicar com o boto direito e
selecionar a opo Relatrio, onde poder verificar os parmetros de jitter, perda
de pacotes e erros de sequncia das chamadas selecionadas.
 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.

Figura 28 Relatrio de jitter, perda de pacotes e erro de sequncia.

Na tela de relatrio so exibidas as seguintes informaes sobre as

transaes selecionadas pelo usurio:

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.

4.2.15 Deteco de mudez total ou parcial em chamadas

a) Necessidade:

Detectar se uma chamada ficou totalmente sem udio ou teve perodos de

mudez ao longo do tempo no uma tarefa fcil de ser feita. Diferentemente da
 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:

Com a cor vermelha, para problemas de alta gravidade;

com a cor amarela, para problemas de mdia gravidade;
com a cor azul, para situaes simplesmente informativas, no
necessariamente um problema.

Quando o usurio posiciona o cursor em cima desse campo, o VoIPFix

mostra uma mensagem dizendo o tipo e a gravidade do problema, e, ao clic-lo, um
relatrio mais detalhado exibido na parte inferior da tela de relatrio.

A Figura 29 mostra um exemplo onde houve momentos de ausncia do fluxo

de udio do receptor da chamada.
 56

Figura 29 Deteco de momentos de ausncia de fluxo de udio.

Na Figura 30 exibido um exemplo mostrando um problema mais grave em

relao ao fluxo RTP, onde no foi detectado o fluxo RTP do receptor da chamada.
Problemas assim podem acontecer quando um dos elementos est atrs de um NAT
[EGE94] e no conseguiu abrir o fluxo de udio para o IP correto do destinatrio, ou
ainda quando aconteceu algum problema na mquina de gerao dos pacotes RTP.

O VoIPFix detecta situaes desse tipo, mas no esclarece a causa do

problema, uma vez que no h evidncias concretas na captura que possibilitem
uma anlise conclusiva de forma automtica. Fica a cargo do usurio analisador
mais experiente investigar as possveis causas.

Figura 30 Deteco de ausncia de fluxo RTP num sentido.

Na Seo 4.4.13, que trata sobre os detalhes de implementao da

funcionalidade, ser descrito, a partir de grficos, como o VoIPFix conseguiu
detectar o problema acima.
 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:

Com a cor vermelha, para problemas de alta gravidade;

com a cor amarela, para problemas de mdia gravidade;
com a cor azul, para situaes apenas informativas, no necessariamente um
problema.

Ainda, quando o usurio clica sobre a transao destacada, um relatrio mais

detalhado aparece na parte inferior da tela.
 58

Figura 31 Relatrio com problema de sinalizao.

A Figura 31 mostra um exemplo da utilizao da ferramenta de relatrio,

mostrando um problema em que o receptor no aceitou a mensagem BYE de
desligamento enviada pelo originador. Esse tipo de ocorrncia faz que o receptor
mantenha o fluxo RTP ainda ativo com o originador e o sistema de bilhetagem
continue contabilizando o tempo da ligao, at que o usurio que esteja operando o
terminal desligue efetivamente a chamada.
Ainda no exemplo acima, o VoIPFix detectou a ausncia do fluxo RTP da
chamada, mesmo ela tendo sido estabelecida normalmente. Nesse caso, pode ter
ocorrido negociao do fluxo RTP atravs de outros endereos IP que no foram
capturados, no acontecendo um problema realmente. Porm, o usurio informado
sobre a ocorrncia.
A Figura 32 mostra outro exemplo de deteco de problema de sinalizao
realizado automaticamente pelo VoIPFix, porm com mais detalhes sobre o que
realmente aconteceu de errado na mensagem de BYE enviada pelo originador.

No caso da Figura 32, o originador enviou a mensagem de desligamento da

chamada com o campo CSeq com valor inferior ao da requisio inicial, por isso o
VoIPFix acusou o fato e informou os valores do campo em cada mensagem.
Com funcionalidades como essa, o VoIPFix traz grandes vantagens em
relao a outras ferramentas de VoIP, pois no necessrio que um usurio
analisador com experincia em SIP, tenha de verificar mensagem por mensagem,
campo por campo, a fim de descobrir um problema especfico. Da mesma forma, um
usurio com pouco conhecimento pode ter respostas mais claras sobre problemas
de sinalizao.
 59

Figura 32 Deteco de problema de fechamento de chamada.

Na Seo 4.4.13, que trata sobre os detalhes de implementao da

funcionalidade, ser descrito, atravs de mais grficos, como o VoIPFix conseguiu
detectar o problema acima.

4.2.17 Informativo com causas de problemas com transaes

a) Necessidade:

Alm dos problemas de sinalizao, provocados por erros nos equipamentos,

ainda podem acontecer casos onde toda a sinalizao est correta, porm a
requisio no pode ser aceita ou no consegue ser completada. Nesses casos, os
equipamentos de telefonia IP costumam sinalizar para o usurio a ocorrncia, porm
nem sempre de forma clara e precisa.

b) Funcionamento:

O VoIPFix trata de casos, evidenciando as transaes que no puderam ser

completadas, por situaes como:

Senha de autenticao incorreta;

usurio de origem ou destino inexistente;
usurio de destino ocupado ou temporariamente indisponvel;
configurao de codificadores de voz incorreta;
erros no agente que recebe a requisio;
indisponibilidade do agente destino;
chamada cancelada.

As informaes com as causas de problemas com as transaes so exibidas

na tela com a lista de transaes, como mostra a Figura 33.
 60

Figura 33 Informativo com problemas de transaes.

4.2.18 Reproduo do udio das chamadas com codificador G.711

a) Necessidade:

Em algumas situaes, quando nenhum erro aparente evidenciado pela

ferramenta no que diz respeito qualidade de voz, ausncia de udio, atrasos ou
picotes, necessrio ouvir o udio da ligao para inferir o problema.

b) Funcionamento:

O VoIPFix permite que o usurio possa ouvir o udio das chamadas que
forem completadas utilizando o codificador de voz G.711 [ITU72], considerando que
os pacotes do fluxo de voz foram capturados corretamente e esto presentes no
arquivo de captura.

A maior parte dos codificadores de voz no so gratuitos e necessitam de

licena para serem utilizados. Por esse motivo, somente as chamadas com o G.711
tm a possibilidade de reproduo do seu udio. Outros codificadores, como o
G.729 [ITU07] e iLBC [AND04], que so os mais utilizados, no sero incorporados
nessa funcionalidade para reproduo do udio da chamada. Isso no significa que
as demais funes do VoIPFix no podero funcionar caso a chamada utilize um
desses codificadores. Sero propostas para trabalhos futuros, implementaes para
suportar os codificadores que so de cdigo fonte aberto.

A Figura 34 mostra a tela utilizada para reproduo do udio de chamadas

que utilizaram o codificador G.711.
 61

Figura 34 Reprodutor de udio de chamadas.

Para acessar a tela acima, o usurio deve clicar com o boto direito sobre
uma chamada, na tela com a lista de transaes, e escolher a opo Reproduzir
udio.

4.3 Tecnologias e ferramentas utilizadas

Nesta seo so apresentadas as tecnologias utilizadas para a construo do

VoIPFix, bem como outras ferramentas de apoio e testes.

4.3.1 Linguagem de programao

A linguagem utilizada no desenvolvimento o C++, com auxlio do Qt,

desenvolvido pela empresa Nokia [QT]. Qt um arcabouo para desenvolvimento de
aplicativos com interface grfica de usurio em C++, que pode ser compilado para
vrios sistemas operacionais, como Windows, GNU/Linux, Mac OS X e outros
[BLA08]. A licena utilizada a LGPL.

Como ambiente integrado de desenvolvimento, foi utilizada a ferramenta Qt

Creator, da prpria Nokia, disponvel gratuitamente no site do Qt. Com essa
ferramenta foi possvel editar, compilar e executar os programas criados em Qt, alm
de criar interfaces grficas de usurio. O Qt Creator est disponvel para Windows,
GNU/Linux e Mac OS X.

4.3.2 Capturador de pacotes de rede

Muitas ferramentas de captura e anlise de pacotes de rede trabalham com

arquivos no formato pcap [PCAP], que armazena todas as informaes dos pacotes
capturados em um arquivo nico.

O VoIPFix utilizou como padro esse formato de arquivo, para salvar os

pacotes e tambm abrir arquivos previamente capturados por outras ferramentas.
Para isso, utilizou a biblioteca WinpCap [WINP], na verso para Windows. Para a
verso GNU/Linux, a biblioteca utilizada foi a libpcap [TCPD], muito semelhante ao
WinpCap, mas especfica para rodar nesse sistema operacional.
 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.

4.3.4 Ferramentas e equipamentos de testes

Durante a etapa de desenvolvimento e testes, foram utilizados algumas

ferramentas e equipamentos que auxiliaram na gerao de mensagens e fluxo de
voz, captura de pacotes e interconexo de elementos SIP. A seguir uma breve
descrio dessas ferramentas:

a) X-Lite:

O X-Lite [XLT] um aplicativo para Windows e GNU/Linux, disponvel

gratuitamente, que faz a funo de um telefone SIP em um PC. Com esse aplicativo
possvel se registrar em um servidor, gerar e receber chamadas utilizando os
mecanismos de multimdia do PC, atravs de alguns codificadores de voz de padro
aberto. O aplicativo foi escolhido para ser um gerador de requisies e chamadas.

A Figura 35 mostra a tela inicial do aplicativo X-Lite.

 63

Figura 35 Tela do aplicativo X-Lite.

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

A seguir, so apresentados o detalhamento sobre a implementao de cada
funo do VoIPFix e como cada mdulo foi construdo para alcanar os objetivos
propostos para o trabalho.

4.4.1 Captura de pacotes

Utilizando a biblioteca WinpCap [WINP] no Windows e libpcap [TCPD] no

GNU/Linux, o VoIPFix realiza a captura dos pacotes de rede em modo promscuo a
partir de uma interface de rede escolhida pelo usurio.
As duas bibliotecas, tanto para Windows quanto para GNU/Linux, so muito
parecidas em se tratando de princpio de funcionamento, tendo apenas algumas
variaes nos nomes das funes e em seus parmetros.
O processo utilizado pelo VoIPFix para iniciar uma captura, realizado dentro
do mdulo Capturador, o seguinte:

O VoIPFix lista as interfaces de rede disponveis na plataforma, como

mostrado na Figura 10;
o usurio escolhe a interface de rede para realizao da captura de pacotes;
 65

o usurio escolhe filtros de captura, por exemplo, somente pacotes UDP ou

de uma determinada mquina;
o processo de captura iniciado pelo usurio;
o VoIPFix compila e aplica o filtro escolhido pelo usurio durante a captura
na interface de rede selecionada;
cada pacote que chega adicionado em uma lista pela biblioteca, e tratado
dentro de uma thread da aplicao;
eventualmente, cada pacote poder ser salvo em um arquivo temporrio ou
escolhido pelo usurio.
O WinpCap e a libpcap possuem duas formas de entregar os pacotes
recebidos atravs de uma interface de rede aplicao que o utiliza:

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.
Por questes de facilidade de implementao, o mdulo Capturador
implementa a segunda forma descrita acima, abrindo o dispositivo de rede para a
captura e iniciando uma thread com alta prioridade para coletar os pacotes, para que
possam ser enviados s camadas superiores da aplicao.
O mesmo processo utilizado para abertura de arquivos em disco, para
tornar as camadas superiores da aplicao independentes do modo de coleta de
pacotes. A nica diferena que o mdulo Capturador avisa a camada superior
quando o final do arquivo atingido.

4.4.2 Anlise de mltiplos arquivos gravados sequencialmente

A funcionalidade descrita na Seo 4.2.4 implementada inteiramente no

mdulo Capturador da aplicao, que realiza os seguintes passos:

Recebe uma lista de arquivos, escolhidos pelo usurio, a serem abertos;

realiza a abertura de um arquivo por vez, passando para o prximo quando
encontra o fim de cada um;
a cada pacote encontrado no arquivo, avisa a camada superior sobre o
mesmo;
quando encontra o fim do ltimo arquivo, avisa a camada superior sobre o
fato.
O procedimento descrito acima garante que todos os demais mdulos do
VoIPFix trabalhem como se estivesse abrindo um nico arquivo do disco. Porm, o
usurio tem uma grande vantagem de abrir mo de procedimentos de mescla de
arquivos, ou ainda, ter de analisar transaes com mensagens dispersas em mais
de um arquivo capturado.
 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.

4.4.3 Identificao de pacotes de interesse

Os pacotes de interesse para o VoIPFix so, essencialmente, aqueles que

trafegam e que utilizam o protocolo de transporte UDP. Porm, a anlise no se
restringe somente ao tipo do protocolo, uma vez que muitas outras aplicaes
utilizam o UDP para troca de mensagens, como, por exemplo, o servio de DNS.
Sendo assim, outros critrios so utilizados para a deteco dos pacotes relevantes
de uma aplicao VoIP. Os critrios adotados so descritos abaixo.

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:

Tipo de codificador de voz [SCH96];

SSRC de cada fluxo.
Esses outros fatores so necessrios para garantir que somente os pacotes
de um fluxo especfico, que tenha se iniciado aps o estabelecimento da sesso,
sejam considerados nas anlises relativas a pacotes RTP.

4.4.4 Interpretao dos pacotes de sinalizao

O processo de interpretao de pacotes caracteriza-se por transformar o

payload UDP de um pacote reconhecido SIP, que est em formato texto, em
estruturas com formato fixo e conhecido, independentemente do tipo da mensagem.
Essa estrutura, que gerada depois do processo de interpretao da
mensagem, constituda de acordo com os tipos de campos que podem existir em
qualquer mensagem SIP. Dessa forma, a manipulao torna-se mais fcil do que
manter a mensagem em formato original de texto, pois qualquer consulta a um
campo de cabealho especfico feita diretamente dentro da estrutura, no campo
correspondente ao da mensagem SIP.
Esse processo de interpretao feito utilizando a biblioteca oSIP [OSIP], que
recebe o texto da mensagem SIP e devolve uma estrutura preenchida com os
campos da mensagem e seus valores.

4.4.5 Anlise de transaes de forma eficiente em plataformas multicore

O mecanismo de anlise dos pacotes, provenientes de um arquivo aberto do

disco ou de uma interface de rede, a parte mais importante de todo o VoIPFix,
pois, desse processo, que se obtm toda a informao a ser apresentada ao
usurio analisador.
A forma como esse ncleo de anlise foi elaborado permite que o
processamento seja indiferente em relao origem dos pacotes. Porm, quando
estes so frutos de um arquivo de disco, utiliza-se de uma tcnica que permite
aproveitar totalmente os recursos de uma mquina com disponibilidade de
processamento paralelo, como o caso de plataformas multicore.

A tecnologia e os algoritmos utilizados para paralelizao da anlise dos

pacotes ser o ponto principal desta subseo, pois um dos diferenciais que torna
o VoIPFix uma ferramenta muito eficiente se comparada com outras. Os testes de
 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) Tecnologia de processamento paralelo:

Para cumprir um dos objetivos do VoIPFix, que realizar a anlise dos
pacotes de VoIP de forma gil, foi necessrio utilizar mecanismos de computao
paralela em plataformas multicore.

A tarefa mais importante e que consome maior processamento, a

interpretao dos pacotes de sinalizao e voz. Ela foi implementada utilizando os
prprios mecanismos disponveis do Qt, chamado de QtConcurrent [SUM10], que
uma API que torna possvel escrever programas multi-threaded sem utilizar funes
de baixo nvel e dependentes do sistema operacional.

b) Algoritmo de interpretao de pacotes de forma paralela:

O QtConcurrent pode trabalhar de diversas maneiras para realizar
processamento paralelo. A seguir, a descrio da forma adotada pelo VoIPFix para
processar os pacotes:

Tem-se a lista de pacotes montada em ordem de captura;

passa-se essa lista como argumento para a chamada da funo que executa
o processamento multi-thread;
a biblioteca QtConcurrent se encarrega de iniciar tantas threads quanto forem
possveis para tratar essa lista;
a biblioteca ainda cuida de fazer que cada thread em execuo pegue
sequencialmente um item da lista, que um pacote, passando como
argumento para a funo de interpretao de pacotes.

A
Figura 36 ilustra o algoritmo descrito acima, com um exemplo de
processamento paralelo de pacotes, considerando um ambiente com quatro threads:
 69

Tarefa 1 Cabealhos
Pacote 1 SIP
Campos
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 Time stamp
Pacote 9 Tarefa 1 RTP Payload type
Pacote 10 Tarefa 3 RTP SSRC
.......
Pacote n
Figura 36 Interpretao de pacotes em mltiplas tarefas.

Dessa forma os pacotes da lista so tratados pelo interpretador em mltiplas

tarefas paralelas, sem necessidade de sincronizao, pois, nesse ponto do processo
de anlise, todos os pacotes so dissociados de transaes.

c) Formao das transaes:

O VoIPFix tambm utiliza a tcnica de processamento paralelo para analisar
os pacotes depois da interpretao, agrupando-os em estruturas para formar as
transaes.
A Figura 37 ilustra um exemplo de anlise de pacotes, aps o processo de
interpretao, considerando um ambiente com quatro threads. Essa situao
necessita de sincronizao para a escrita de informaes na estrutura de cada
transao, pois mais de uma tarefa pode analisar um pacote de uma mesma
transao.
 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

A estrutura, que comporta os pacotes de cada transao, possui os seguintes

campos:

call_id: armazena o texto de identificao nica, utilizado para encontrar

todos pacotes que pertencem mesma transao;
tipoTrans: varivel inteira que guarda o tipo de transao armazenada na
estrutura;
statusCode: corresponde ao cdigo de estado da transao durante o
processo de anlise da requisio e das respostas. Quando todas as
mensagens tiverem sido tratadas, o campo corresponde ao estado de
finalizao da transao;
posPacotes: lista de ndices que aponta para cada pacote da transao. Ela
pode conter pacotes fora da ordem que foram capturados, pois o processo de
anlise em mltiplas tarefas insere e analisa informaes de forma
assncrona, para garantir o mximo de aproveitamento de tempo no
processamento;
numPacoteReq: aponta para a lista de ndices, indicando o pacote que
contm a mensagem de requisio que deu incio transao, pois eles
podem estar fora da ordem em que foram capturados;
ipMediaSrc: endereo IP, que o originador de uma chamada ofereceu para
receber o fluxo RTP;
 71

ipMediaDst: endereo IP, que o receptor de uma chamada ofereceu para

receber o fluxo RTP;
portMediaSrc: porta UDP, que o originador de uma chamada ofereceu para
receber o fluxo RTP;
portMediaDst: porta UDP, que o receptor de uma chamada ofereceu para
receber o fluxo RTP;
mediaSrcOK: flag que indica que pelo menos um pacote do fluxo do
originador foi detectado;
mediaDstOK: flag que indica que pelo menos um pacote do fluxo do receptor
foi detectado;
ssrcSrc: inteiro que armazena o nmero do SSRC do fluxo RTP do
originador;
ssrcDst: inteiro que armazena o nmero do SSRC do fluxo RTP do receptor;
lock: objeto que cuida dos mecanismos de sincronizao e proteo de
escrita e leitura dentro da estrutura de cada transao, durante o
processamento paralelo dos pacotes.

A seguir, apresentado o algoritmo implementado na funo de anlise das

mensagens, para formao das transaes, que executado em processos
paralelos em mquinas com mltiplos ncleos:

//Inicializa varivel de controle de tipo de transao

tipoReq = TRANS_TYPE_NONE;
Se mensagem SIP ento
call_id = call id da mensagem SIP;
//bloqueia acesso de outras threads
mutex.lock();
Se no existe transao com call_id ento
cria nova transao com call_id;
adiciona pacote SIP na lista de transaes;
mutex.unlock();
Se mensagem SIP de requisio ento
tipoReq = tipo de requisio da mensagem SIP;
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
Seno
// mensagem de resposta
estadoTransao = estadoMensagemDeResposta;
Fim Se
Seno
//j existe transao com call_id
mutex.unlock();
adiciona pacote SIP na lista de transao;
Se mensagem SIP de requisio ento
tipoReq = tipo de requisio da mensagem SIP;
 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

O algoritmo sempre considera que sua execuo ser feita em um ambiente

com processamento paralelo, por isso, em alguns pontos, h o controle de
sincronismo, para evitar que mais de uma tarefa escreva dentro da mesma estrutura
de uma transao ao mesmo tempo.
Ele ainda possui mecanismos para considerar a anlise de mensagens em
ordem contrria sua chegada, pois as tarefas paralelas coletam os itens da lista
medida que concluem a anlise do pacote anterior, fazendo com que saiam de
sequncia, como mostrado na Figura 37.

4.4.6 Anlise durante o processo de captura

Como foi descrito na Seo 4.4.1, o processo de captura utiliza uma thread
para coletar os pacotes que chegam at a interface de rede escolhida, sendo
 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.

4.4.7 Exibio de lista de transaes

A partir da estrutura que agrupa os pacotes de cada transao, formada

durante o processo de anlise, pode-se exibir uma lista como a da Figura 12.
As informaes para montagem dessa tela so retiradas da primeira
mensagem, que na maioria dos casos a de requisio. Somente o campo de
estado coletado da prpria estrutura que armazena a transao, pois no depende
da anlise das demais mensagens.

4.4.8 Exibio de grfico detalhado de transaes

Como explicado na Seo 4.2.7, o usurio pode selecionar vrias transaes

para exibir o grfico detalhado de cada uma. Assim, o VoIPFix deve montar uma
lista ordenada pelo tempo, contendo todas as mensagens SIP e os pacotes RTP de
acordo com a seleo do usurio.
O algoritmo para realizao desse trabalho detalhado abaixo:

Ordena-se a lista de transaes selecionadas pelo usurio de acordo com o

tempo de incio de cada uma, pois a seleo pode ter sido feita de forma
aleatria. Foi utilizado o insertion sort [COR03] para a ordenao crescente,
pois natural que a lista tenha sido gerada pelo usurio j na ordem correta
que elas aparecem, e o algoritmo tem um desempenho melhor nessa
situao;
cria-se uma lista principal de pacotes, contendo aqueles necessrios a todas
as transaes selecionadas;
 74

ordena-se os pacotes de forma crescente, de acordo com o tempo de cada

um, utilizando o algoritmo quick sort [COR03]. Esse passo necessrio, pois
as transaes podem acontecer num mesmo perodo de tempo, e as
mensagens no grfico devem aparecer sequencialmente crescentes,
independentemente de qual transao ela pertena;
monta-se a lista de informaes para o grfico, contendo, de cada pacote, o
tempo de chegada, endereo IP de origem, porta de origem, endereo IP de
destino, porta de destino e o comentrio que exibido acima de cada seta do
grfico. Esse ltimo retirado da linha de requisio ou cdigo de estado,
quando uma mensagem SIP, ou do tipo do codificador, quando um pacote
RTP. O fluxo unidirecional RTP representado somente por uma seta, uma
vez que seria visualmente desconfortvel exibir todos os pacotes;
monta-se uma lista contendo todos os endereos IP de origem e de destino
que aparecem em todos os pacotes, para que o mecanismo que desenha o
grfico possa criar as colunas que representam cada endereo. Alm disso,
ele deve tambm definir a orientao da seta que representa o pacote.

4.4.9 Exibio de grficos com estatsticas

A janela que mostra as estatsticas exibe grficos com:

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.
Todas as informaes so retiradas da estrutura gerada durante o processo
de anlise de pacotes. A contabilidade feita de acordo com o tipo a ser gerado e
exibida em forma de grfico de barras.
O processo simples e no utiliza nenhum algoritmo complexo.

4.4.10 Filtro de transaes

A tela de configurao de filtros, como mostrada na Figura 27, coleta as

informaes escolhidas pelo usurio e as compara com cada transao da estrutura
gerada durante o processo de anlise. Depois da comparao, somente as que
atenderem s opes escolhidas que sero exibidas na tela de listagem de
transaes.
A comparao feita da seguinte forma, de acordo com cada opo da tela
de filtros:

Tipo de transao: compara a opo escolhida pelo usurio com o mtodo de

requisio existente na primeira mensagem SIP da estrutura de transao;
horrio de incio: filtra as transaes a partir da hora de chegada do primeiro
pacote da transao;
 75

endereo IP de origem: filtra as transaes a partir do endereo IP de origem

do primeiro pacote da transao;
endereo IP de destino: filtra as transaes a partir do endereo IP de destino
do primeiro pacote da transao;
usurio de origem: filtra as transaes a partir do usurio de origem, presente
no campo From da mensagem de requisio;
usurio de destino: filtra as transaes a partir do usurio de origem, presente
no campo To da mensagem de requisio;
estado de finalizao da transao: exibe somente as mensagens que
possurem os estados de transao selecionados pelo usurio.

4.4.11 Medio de jitter, perda de pacotes e erros de sequncia

Os algoritmos utilizados para medio de jitter, perda de pacotes e

contabilizao de erros de sequncia foram implementados segundo os exemplos
em linguagem C, propostos no Apndice A da RFC3550 [SCH03]. Uma descrio
mais detalhada pode ser encontrada nesse documento.
O VoIPFix alimenta os algoritmos com cada fluxo de udio retirado da
estrutura que armazena os pacotes RTP de cada transao, tendo como sada os
valores de:

Jitter mdio e mximo do fluxo;

quantidade de ocorrncias de erros de sequncia;
nmero de pacotes esperados;
nmero de pacotes recebidos.
O percentual de perda de pacotes calculado a partir do nmero de pacotes
esperados e recebidos.
Basicamente, o algoritmo possui as seguintes caractersticas principais:

Considera um fluxo vlido a partir de um nmero de pacotes detectados;

permite um nmero mnimo de pacotes fora de sequncia, sem considerar
como uma situao de erro;
possui mecanismos de deteco de reciclagem do nmero de sequncia, sem
contabilizar situao de erro.
Foram realizados testes de medio de jitter e perdas de pacotes,
comparando os resultados do VoIPFix com os do Wireshark, a fim de comprovar a
correo da implementao dos algoritmos. Os resultados so apresentados nas
Sees 4.5.1 e 4.5.2.
 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:

Erro na negociao dos endereos IP ou porta UDP durante o

estabelecimento da chamada;
falha na ativao dos canais de RTP no equipamento de converso de mdia;
problemas de transposio de NAT.
O VoIPFix detecta qualquer um desses erros, mas no informa a causa real
do problema, pois no h informao suficiente nos traos de captura que
esclaream os fatos com preciso.
O algoritmo, para deteco de mudez total em um dos lados da chamada,
utiliza as informaes de sesso coletadas no processo de anlise e formao das
estruturas de transaes. Durante a varredura dos pacotes RTP pertencentes
transao em anlise, se nenhum for detectado, um flag marcado, indicando a
ocorrncia do fato no fluxo correspondente.
Para a deteco de mudez parcial ou ausncia momentnea de udio em um
dos fluxos da chamada, o VoIPFix utiliza a mesma funo para medio de perda de
pacotes e erros de sequncia. Porm, quando o nmero de sequncia do RTP salta
para um valor superior a 100 pacotes, um flag marcado indicando a ocorrncia do
acidente do fluxo de udio. Esse nmero foi escolhido simplesmente para servir de
base de testes para o algoritmo, pois corresponde a dois segundos de ausncia em
um fluxo em que cada pacote possui 20ms de amostra. Em aplicaes futuras, o
usurio poder configurar o tempo mximo permitido para que a aplicao sinalize a
ocorrncia do fato.

4.4.13 Deteco de transaes com erros de sinalizao

Na primeira verso do VoIPFix, foram implementados dois testes que

verificam e apontam erros de sinalizao na finalizao de transaes de chamada.
Apesar de terem sido implementados apenas dois testes, o mecanismo adotado
permite que, em trabalhos futuros, outros testes possam ser criados.
 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.

Figura 38 Grfico de problema de fechamento de chamada. Caso 1.

A mensagem 481 Call Leg/Transaction Does Not Exist, enviada

pelo receptor da chamada em resposta requisio de BYE, foi detectada pelo
VoIPFix, caracterizando um problema no desligamento da chamada, uma vez que a
resposta correta deveria ser 200 OK. Nesse caso, o VoIPFix no foi capaz de
identificar claramente o motivo do no reconhecimento da requisio de BYE pelo
receptor da chamada.
O algoritmo, para tratar essa situao, procura pelas mensagens de
finalizao corretas de uma chamada, e, caso no as encontre, sinaliza a existncia
de um erro grave de sinalizao.
O segundo caso apresentado na Seo 4.2.16, mostra uma situao
semelhante, como mostra a Figura 39.
 78

Figura 39 Grfico de problema de fechamento de chamada. Caso 2.

O comportamento do receptor da chamada, ao receber a mensagem de BYE,

diferente em relao ao primeiro caso, porm, o VoIPFix conseguiu detectar o erro
na finalizao da chamada, pela ausncia de mensagem de resposta 200 OK.

Nesse caso, o algoritmo do VoIPFix conseguiu identificar o motivo da recusa

da mensagem de BYE, como pode ser observado na Figura 32, no qual a ferramenta
cita os valores errados do campo CSeq nessa mensagem.

A especificao de testes da ETSI possui itens especficos para verificao de

conformidade, no que diz respeito finalizao de chamadas. O segundo caso
apresentado, infringiu a regra descrita no teste SIP_CC_OE_CR_V_004 do
documento [MTS07], que diz que uma sesso estabelecida, deve ser finalizada por
uma mensagem de BYE com o valor do campo CSeq incrementado de uma unidade.
 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.4.15 Reproduo do udio das chamadas com codificador G.711

O processo para reproduo do udio de chamadas que foram completadas

com o codificador G.711 possui os seguintes passos:

A partir da transao selecionada pelo usurio para a reproduo, o VoIPFix

verifica o tipo de codificador utilizado na chamada, restringindo somente as
que estiverem codificadas com codificador G.711 lei A ou G.711 lei ;
agrupa todos os pacotes RTP do fluxo do originador e receptor em duas listas
separadas;
retira o payload RTP que contm a amostra do udio codificado de cada
pacote;
faz a converso utilizando uma tabela para retirar a amostra de udio;
gera um arquivo no formato Au [AUF]. A gerao desse arquivo
interessante para o processo de reproduo, que pode ser controlado de
acordo com o usurio. Alm disso, interessante para trabalhos futuros de
exportao do udio de chamadas;
exibe a janela da Figura 34, que permite que o usurio controle a reproduo
da chamada.

4.5 Testes de correo

Foram realizados testes no VoIPFix para avaliar e comparar a preciso das
funcionalidades de medio de jitter, perda de pacotes e erros de sequncia da
aplicao.
A fim de avaliar a correo dos dados apresentados, foi feita a comparao
com uma ferramenta muito utilizada, que o padro no mundo de open source. Os
experimentos mostram que os resultados so to bons quanto o Wireshark.

4.5.1 Medio de jitter mximo

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.

Tempo (ms) VoIPFix 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
Tabela 4 Teste de correo: jitter mximo.

Nota-se claramente que, nesses dois casos, os valores encontrados pelas

duas ferramentas foram muito prximos, comprovando que a implementao da
funcionalidade de medio de jitter do VoIPFix foi bem-sucedida.

4.5.2 Medio de percentual de perda de pacotes

Foram selecionados arquivos de captura diferentes dos utilizados nos testes

de medio de jitter, para anlise do percentual de perda de pacotes apontados pelo
VoIPFix e Wireshark, a fim de realizar comparaes. Os resultados so
apresentados na Tabela 5.

VoIPFix Wiresahrk

Fluxo Originador Receptor Originador Receptor

Caso 1 0% 24,05% 0% 24,01%
Caso 2 4,88% 0,30% 4,88% 0%
Tabela 5 Teste de correo: perda de pacotes.

Assim como nos testes de medio de jitter, os valores encontrados pelo

VoIPFix foram muito prximos aos do Wireshark, comprovando tambm que a
implementao do algoritmo de medio de perda de pacotes foi bem-sucedida. A
diferena de valores encontrados no fluxo do receptor, deve-se tcnica adotada no
VoIPFix, segundo a prpria recomendao da RFC3550, de somente considerar um
fluxo aps um nmero mnimo de pacotes. Como o Wireshark considera um fluxo
vlido a partir do primeiro pacote, diferenas como essas podem acontecer.
 81

4.6 Testes de desempenho com abertura de arquivos grandes

Os testes de abertura de arquivos grandes foram realizados com o objetivo

de avaliar o tempo gasto pelo VoIPFix para realizar tal trabalho, comparado com o
Wireshark em condies semelhantes.

a) Informaes sobre as mquinas utilizadas nos testes

A seguir, uma descrio sobre cada mquina utilizada nos testes:

Mquina Sistema Operacional Processador RAM

1 Debian GNU/Linux AMD Phenom II X4 945 (4 4 GB

kernel 2.6.26-2-amd64, ncleos), com clock de 3 GHz e
com KDE 3.5.10 64 bits cache de 512 KB

2 Debian GNU/Linux Intel Core 2 Duo E4600 (2 2 GB

kernel 2.6.26-2-686, ncleos), com clock de 2.40 GHz e
com KDE 3.5.10 32 bits cache de 2048 KB

3 Windows Vista Business Intel Core 2 Duo E4600 (2 2 GB

Edition Service Pack 2 ncleos), com clock de 2.40 GHz e
32 bits cache de 2048 KB

4 Debian GNU/Linux Intel Core 2 Duo T6600 (2 3 GB

kernel 2.6.26-2-amd64, ncleos), com clock de 2.20 GHz e
com Gnome 2.22.3 64 cache de 2048 KB
bits

5 Windows 7 Home Basic Intel Core 2 Duo T6600 (2 3 GB

64 bits ncleos), com clock de 2.20 GHz e
cache de 2048 KB

Tabela 6 Informaes sobre mquinas utilizadas nos testes.

b) Informaes sobre os arquivos:

Os arquivos utilizados nos testes foram capturados pelo Wireshark em uma

rede onde havia alto trfego de pacotes SIP, RTP e outros. O aplicativo foi
 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:

nmero de transaes SIP: 5869;

nmero de transaes de registro: 338;
nmero de transaes de chamada: 62;
nmero de pacotes SIP: 23496;
nmero de pacotes RTP: 220092;
nmero total de pacotes: 388619.

Arquivo de 100 MBytes:

nmero de transaes SIP: 7715;

nmero de transaes de registro: 377;
nmero de transaes de chamada: 115;
nmero de pacotes SIP: 30879;
nmero de pacotes RTP: 574781;
nmero total de pacotes: 817997.

Arquivo de 150 MBytes:

nmero de transaes SIP: 8781;

nmero de transaes de registro: 407
nmero de transaes de chamada: 154;
nmero de pacotes SIP: 35411;
nmero de pacotes RTP: 838603;
nmero total de pacotes: 1163435.

Arquivo de 200 MBytes:

nmero de transaes SIP: 11020;

nmero de transaes de registro: 454;
nmero de transaes de chamada: 209;
nmero de pacotes SIP: 44518;
nmero de pacotes RTP: 1224064;
nmero total de pacotes: 1629625.
 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) Mquina 1 Mquina 2 Mquina 3 Mquina 4 Mquina 5

VoIPFix 8,74 11,90 11,01 8,23 11,62
Wireshark 53 60 47 95 71
Tabela 7 Tempo de abertura de arquivo com 50 MB.
 84

b) Arquivo de 100 MBytes:

Tempo (s) Mquina 1 Mquina 2 Mquina 3 Mquina 4 Mquina 5

VoIPFix 23,97 31,00 25,25 21,16 28,11
Wireshark 126 160 157 250 175
Tabela 8 Tempo de abertura de arquivo com 100 MB.

c) Arquivo de 150 MBytes:

Tempo (s) Mquina 1 Mquina 2 Mquina 3 Mquina 4 Mquina 5

VoIPFix 46,92 60,21 43,47 39,70 49,43
Wireshark 173 230 197 355 240
Tabela 9 Tempo de abertura de arquivo com 150 MB.

d) Arquivo de 200 MBytes:

Tempo (s) Mquina 1 Mquina 2 Mquina 3 Mquina 4 Mquina 5

VoIPFix 64,47 90,26 62,34 58,09 72,46
Wireshark 295 390 340 600 460
Tabela 10 Tempo de abertura de arquivo com 200 MB.

Pelos resultados mostrados acima, evidente que o VoIPFix atingiu com

sucesso um dos maiores objetivos propostos, que foi a abertura e a anlise de uma
grande quantidade de pacotes de forma eficiente, pois ele gastou um tempo bem
menor que o Wireshark, principalmente nos arquivos maiores.

A seguir, alguns motivos pelo qual o VoIPFix possui uma eficincia superior,
se comparada ao Wireshark, em relao ao desempenho de abertura de arquivos:

Permite processamento paralelo dos pacotes, em mquinas com mltiplos

ncleos;
foi desenvolvido utilizando uma biblioteca para interface grfica mais
avanada, alm de tcnicas sofisticadas e de alto desempenho;
utiliza uma biblioteca de interpretao de mensagens SIP muito eficiente, que
transforma os textos do protocolo em estruturas de fcil indexao e busca;
foi construdo utilizando algoritmos de ordenao criteriosamente escolhidos
para satisfazer as necessidades de cada caso;
somente realiza processamento de pacotes e mensagens que interessam
para a anlise de VoIP;
utiliza classes de armazenamento de informaes em forma de listas,
largamente usado em toda a aplicao, providos pela linguagem de
programao Qt, desenvolvidos com foco em desempenho e baixo consumo
de memria.
 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 / 50 MB 100 MB 150 MB 200 MB

Tempo (s)
VoIPFix 29,50 97,30 205,05 322,11
Wireshark 274 790 1210 2180
Tabela 11 Teste de desempenho em mquina de um ncleo.

4.7 Comparao com outras ferramentas

A Tabela 12 mostra um comparativo realizado entre o VoIPFix, o Wireshark e

o Cace Pilot, a respeito das principais funcionalidades de anlise de pacotes de
VoIP das trs aplicaes:
 86

Funcionalidade VoIPFix Wireshark Cace Pilot

Captura de pacotes

Anlise de forma gil em plataformas

multicore
Exibio de detalhes das mensagens
Operao em sistema GNU/Linux
Exibio de lista de transaes de registro
Exibio de lista de transaes de chamada
Grfico detalhado das transaes de registro
Grfico detalhado das transaes de
chamadas
Deteco de mudez total ou parcial em
chamadas
Deteco de erros de sinalizao
Localizao de transaes com base no
usurio ou endereo da mquina
Anlise durante o processo de captura
Anlise de arquivos gravados em sequncia
Grfico com estatsticas de chamadas
Reproduo das chamadas com codificador
G711
Medio de jitter, perda de pacotes e erros de
sequncia
Informativo de problemas de transaes
Exibio de grfico com estatsticas de
nmero de transaes de chamada por
usurio ou mquina
Exibio de grfico com estatsticas de
nmero de transaes de registro por usurio
ou mquina
Tabela 12 Comparativo de funcionalidades com Wireshark e Cace Pilot.

importante ressaltar alguns diferenciais do VoIPFix em relao ao

Wireshark e o Cace Pilot. A seguir, um detalhamento dessas vantagens.
 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.

4.7.2 Exibio de transaes de registro

Exibir as transaes de registro em listas e em forma de grficos de

extrema utilidade durante o processo de anlise de um sistema de telefonia IP. Essa
funcionalidade no foi implementada no Wireshark nem no Cace Pilot, porm, no
VoIPFix, teve o tratamento de importncia igual s transaes de chamada.

Vrias situaes exigem investigao das transaes de registro. O VoIPFix

fornece boas ferramentas para facilitar a operao e o trabalho do usurio
analisador nesses casos.

4.7.3 Deteco de mudez total ou parcial em chamadas

Com essa funcionalidade, o usurio do VoIPFix poder ser alertado de

situaes de mudez em transaes de chamada. A facilidade de diagnsticos em
situaes assim traz grandes benefcios para o usurio analisador, que no mais
necessita investigar o fluxo de mdia pacote a pacote at encontrar algum tipo de
problema que explique o caso.

O Wireshark e o Cace Pilot possuem funcionalidades que expressam perda

de pacotes, mas no alertam sobre a ausncia de um fluxo total ou parcial, como
feito no VoIPFix.

4.7.4 Deteco de erros de sinalizao

Uma das grandes funcionalidade do VoIPFix, para usurios que no possuem

conhecimento profundo nos protocolos envolvidos, a deteco de erros de
sinalizao.

Poucos casos foram implementados na atual verso da ferramenta, porm a

base de interpretao est pronta para ser expandida e cobrir todos os casos
previstos no documento de testes da ETSI [MTS07].
 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:

Tendo um arquivo aberto ou pacotes capturados atravs de uma interface de

rede, selecionar a opo que exibe as transaes de chamadas;
exibir o grfico da transao desejada;
clicar sobre o pacote RTP do fluxo desejado para ser analisado;
acessar o menu de anlise de fluxo RTP, que um processo separado da
anlise das transaes. Essa atitude leva muito tempo para ser executada,
quando feita em arquivos muito grandes.

No VoIPFix, a anlise desses parmetros est diretamente associada

transao de chamada. O usurio analisador deve apenas selecionar a transao
desejada e, a partir da, comandar a abertura do relatrio que contm as
informaes buscadas.
 89

5 Concluso

O VoIPFix foi construdo para atender as necessidades de uma ferramenta de

anlise para o mundo de telefonia IP, de modo eficiente e de fcil operao por
usurios com um mnimo de conhecimento da rea.
Seus objetivos foram alcanados, apesar das limitaes em algumas
ferramentas, principalmente em situaes de captura em tempo real de pacotes.
Porm, a base desenvolvida permitir evolues e melhorias, permitindo
acompanhar a evoluo dos sistemas computacionais em relao a processamento
de alto desempenho.
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:

Deteco de eventos anormais no sistema de telefonia principal da empresa;

anlise de problemas em campo;
verificao de funcionamento de equipamentos de testes em laboratrio;
medio de jitter e perda de pacotes em ensaios de grande escala.
Seu desempenho, estabilidade e facilidade de operao ajudaro muitos
profissionais que dependem de boas ferramentas gratuitas para auxiliar no trabalho
de anlise de pacotes de rede no mundo de telefonia IP.
O VoIPFix est disponibilizado como um projeto de software livre atravs do
Centro de Competncia de Software Livre do IME-USP, no stio
http://ccsl.ime.usp.br/voipfix, sob a licena GNU General Public License v.3.

5.1 Trabalhos futuros

A base desenvolvida neste trabalho permitir evolues, melhorias e criaes
de novas funcionalidades para o VoIPFix. Algumas delas so descritas a seguir.

a) Medio de qualidade de voz:

Implementao de medio de qualidade de voz, segundo o Modelo E,
detalhado no trabalho [CAR04], a partir do jitter e perda de pacotes, valores j
calculados pelo VoIPFix em uma chamada.
As alteraes na estrutura do VoIPFix sero pontuais, devendo influenciar
especificamente nas funes de anlise de fluxo RTP.

b) Reproduo de udio de chamadas com iLBC:

Reproduzir udio de chamadas apenas com o codificador G.711 no

satisfatrio para muitas situaes, porm o VoIPFix foi preparado para incorporao
 90

de outros codificadores de voz, como o iLBC, que no necessita de pagamento de

royalties para ser utilizado.

c) Outras anlises durante a captura:

A anlise do VoIPFix durante o processo de captura restringe-se exibio

somente da lista de transaes. A proposta melhorar os mecanismos, permitindo a
realizao de todas as tarefas, sem que o usurio tenha de interromper a captura ou
mesmo fechar algumas janelas e reabri-las novamente, como feito com o
Wireshark.

d) Exportao de logs de eventos:

Um dos projetos futuros, fazer que o VoIPFix torne-se uma ferramenta de
gerncia proativa de sistemas de telefonia IP, exportando os logs de eventos para
um computador remoto, durante o processo de captura, por meio de SysLog ou
outro protocolo. Dessa forma, o administrador de redes poder ser informado de
eventos como:

erros de sinalizao em transaes de chamada ou registro

presena de equipamentos com comportamento incorreto na rede;
queda de qualidade de voz ou aumento de fatores como jitter e perda de
pacotes;
ataques de scanners SIP;
dificuldade de registro ou estabelecimento de chamada por algum usurio.

e) Deteco de dgitos no payload RTP:

O VoIPFix detecta o transporte de dgitos DTMF somente atravs de
mensagens do tipo SIP INFO. Em verses futuras, ser implementada a deteco
dos dgitos que estiverem presentes no payload RTP do fluxo de udio [SCH00].

f) Grfico de jitter e taxa de perda de pacotes ao longo da chamada:

Os valores de jitter e perda de pacotes, medidos pelo VoIPFix no final de uma
chamada, so importantes para uma primeira avaliao da qualidade da chamada e
do meio de transmisso.
Como trabalho futuro, sero feitos grficos para exibio da evoluo desses
parmetros durante a chamada, permitindo ao usurio a inspeo dos momentos
crticos no exato ponto onde ocorreram.

O VoIPFix continuar a ser desenvolvido pelo autor, agregando novas

funcionalidades, tornando-o cada vez mais eficiente. Ser feito um esforo para
 91

atrair a comunidade de usurios e desenvolvedores interessada nesse tipo de

ferramenta, para aprimor-lo e contribuir para a criao de melhorias.
 92

6 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 Peer-

to-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/aparelho-

telefonico/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]. KARAPANTAZIS, S., PAVLIDOU, F. VoIP: A comprehensive survey on a

promising technology. In The International Journal of Computer and
Telecommunications Networking, volume 53, issue 12, agosto de 2009.

[MTS07]. Methods for Testing and Specification (MTS); Conformance Test

Specification for SIP (IETF RFC3261); Part 2: Test Suite Structure and
Test Purposes (TSS&TP). 2007. (ETSI TS 102 027-2 V4.1.1).

[OSIP]. OSIP. http://www.gnu.org/software/osip. ltimo acesso em 01/05/2010.

[PCAP]. PCAP Next Generation Dump File Format.

http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html. ltimo
acesso em 02/10/2010.

[PER03]. PERKINS, C. RTP Audio and Video for the Internet. Addison-Wesley
Professional. 2003. 432 p.

[POS80a]. POSTEL, J. User Datagram Protocol. 1980. IETF RFC768.

[POS80b]. POSTEL, J. Transmission Control Protocol. 1980. IETF RFC761.

 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.