Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP

1. Proposta de uma Ferramenta de
Monitoramento de Desempenho
em Tempo Real para aplicações
Live Streaming baseadas no
protocolo RTP
por
Maurício Bento Ghem

2. UNIVERSIDADE DO VALE DO RIO DOS SINOS
MAURÍCIO BENTO GHEM
Proposta de uma Ferramenta de
Monitoramento de Desempenho em Tempo
Real para aplicações Live Streaming
baseadas no protocolo RTP
Monografia apresentada como requisito
parcial para a obtenção do grau de
Bacharel em Engenharia da Computação
Prof. Msc.
Eduardo Leivas Bastos
Orientador
São Leopoldo, Dezembro de 2009

3. “O futuro pertence a quem souber libertar-se da idéia tradicional do trabalho
como obrigação ou dever e for capaz de apostar numa mistura de atividades,
onde o trabalho se confundirá com o tempo livre, com o estudo e com o jogo,
enfim, com o ’ócio criativo’.”
— D OMÊNICO D E M ASI

4. AGRADECIMENTOS
Gostaria de agradecer a meus pais que desde pequeno me incentivaram a estudar, e
me apoiaram acreditando em meu potencial. Também, por me apoiar nas etapas da vida,
me dar amor e proporcionar sempre as melhores condições em tudo. Pais, amo vocês.
Agradeço a meu irmão por em momentos de total enlouquecimento devido ao tra-
balho de conclusão entender minha situação e conversar comigo para relaxar um pouco.
Agradeço a minha namorada por tentar compreender minha situação e ficar do meu
lado nos muitos finais de semana que dediquei ao estudo.
Agradeço aos meus amigos por entenderem a fase da vida que estou passando, por
darem apoio e atenção nos momentos que mais precisei, e por estar ao meu lado mesmo
eu estando um pouco ausente.
Agradeço a meu orientador que me deu motivação, conhecimento, e muitas outras
contribuições. Agradeço por acreditar em meu potencial e me dar forças que resultaram
numa grande vontade em fazer o mestrado.
Por fim, gostaria de fazer uma dedicação especial a todas as pessoas que frequentam
meu blog. A troca de experiências para o crescimento pessoal e profissional é recíproca.
Agora, é minha vez de agradecer a todos que me deram motivação, ajuda e compreensão
nesta etapa. Valeu pessoal.

5. SUMÁRIO
LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 8
LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Fatores que afetam a transmissão Live Streaming . . . . . . . . . . . 22

6. 2.2.1 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4 Largura de Banda Disponível . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Protocolo de Sinalização: SIP . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 Redirect Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.4 Registrar Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.5 Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Protocolos de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Real-time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . 35
2.4.2 RTP Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Protocolo para Feedback : ICMP . . . . . . . . . . . . . . . . . . . . . . 39
2.6 Padrão de Arquitetura: MVC . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3 METODOLOGIA DE DESENVOLVIMENTO . . . . . . . . . . . . . . . 45
3.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7. 3.3.3 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.4 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.1 Lógica - Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.2 Interface gráfica - View . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.3 Controlador - Controller . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.4 Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4 EXPERIMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1 Ambiente de Experimentação . . . . . . . . . . . . . . . . . . . . . . . 71
4.1.1 Máquina Virtual 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.2 Máquina Virtual 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.3 Máquina Virtual 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.4.2 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.4 Buffer de compensação de jitter . . . . . . . . . . . . . . . . . . . . 84
4.5 Síntese do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8. REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9. LISTA DE ABREVIATURAS E SIGLAS
ACK Acknowledge
ASCII American Standard Code for Information Interchange
CNAME Canonical Name
DARPA Defense Advanced Research Projects Agency
FEC Forward Error Correction
GUI Graphical User Interface
ICMP Internet Control Message Protocol
IDE Integrated Development Environment
IETF Internet Engineer Task Force
IP Internet Protocol
MGCP Media Gateway Control Protocol
MVC Model View Controller
NTP Network Time Protocol
PABX Private Automatic Branch Exchange
PSNR Peak Signal Noise Ratio
PSTN Public Switched Telephone Network
QoS Quality of Service
RFC Request for Comments

10. RR Receiver Report
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
RTT Round Trip Time
SDES Source Description
SIP Session Initiation Protocol
SNMP Simple Network Management Protocol
SO Sistema Operacional
SR Sender Report
SSRC Synchronization Source
TCP Transmission Control Protocol
TTL Time to live
UAC User Agent Client
UAS User Agent Server
UA User Agent
UDP User Datagram Protocol

11. LISTA DE FIGURAS
Figura 2.1: Diagrama demonstrando uma transmissão por streaming. . . . 21
Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em
ação (LIMA, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 2.3: Funções das entidades numa rede SIP. . . . . . . . . . . . . . . 32
Figura 2.4: O pacote RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 2.5: O tipo de pacote sender report, do protocolo RTCP. . . . . . . . 39
Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP. . . . . . . 40
Figura 2.7: Apresentação de diversas visualizações possíveis por causa
do MVC, sem alterar a integridade dos dados de negócio (BUSCHMANN
et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma
das partes que compõem o padrão MVC (MICROSYSTEMS,
2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de
pré-teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 3.2: Diagrama da organização de pacotes por agrupamento de fun-
cionalidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 3.3: Diagrama do modelo de classes do projeto. . . . . . . . . . . . . 60
Figura 3.4: Diagrama de classes completo do protótipo. . . . . . . . . . . . 61

12. Figura 3.5: Diagrama da classe ThreadPcap. . . . . . . . . . . . . . . . . . 63
Figura 3.6: Diagrama da classe classquerierpcap. . . . . . . . . . . . . . . . 63
Figura 3.7: Diagrama da classe ThreadICMP. . . . . . . . . . . . . . . . . . 64
Figura 3.8: Diagrama da classe QuerierICMP. . . . . . . . . . . . . . . . . . 65
Figura 3.9: Diagrama de classes completo do pacote Model. . . . . . . . . 65
Figura 3.10: Diagrama da classe GuiInicial. . . . . . . . . . . . . . . . . . . . 66
Figura 3.11: Diagrama da classe GuiSmB. . . . . . . . . . . . . . . . . . . . . 67
Figura 3.12: Diagrama da classe Grafico. . . . . . . . . . . . . . . . . . . . . 67
Figura 3.13: Diagrama de classes completo do pacote View. . . . . . . . . . 68
Figura 3.14: Diagrama de classes completo do pacote Controller. . . . . . . 68
Figura 3.15: Diagrama de classes completo do pacote Extra. . . . . . . . . . 69
Figura 4.1: Topologia de redes simulada que foi utilizada no ambiente de
testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 4.2: Interface gráfica inicial do protótipo. . . . . . . . . . . . . . . . . 74
Figura 4.3: Interfaces de rede disponíveis para execução do protótipo. . . . 74
Figura 4.4: Interface gráfica que representa a tela dos gráficos. . . . . . . . 76

13. LISTA DE TABELAS
Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a des-
crição. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 4.1: Valores medidos para cada um das cinco execuções da apli-
cação para o tráfego RTP. . . . . . . . . . . . . . . . . . . . . . . 77
Tabela 4.2: Valores medidos para cada um das cinco execuções da apli-
cação para o atraso de ida e volta. . . . . . . . . . . . . . . . . . 78
Tabela 4.3: Valores estimados para cada um das cinco execuções da apli-
cação para tamanho do buffer de compensação de jitter. . . . . 79
Tabela 4.4: Média aritmética de todos atributos da transmissão live stream-
ing ao longo de cinco iterações. . . . . . . . . . . . . . . . . . . 80

14. RESUMO
A utilização de aplicações em tempo real sobre redes de pacotes (ex: VoIP, videocon-
ferência, live streaming) têm crescido muito nos últimos anos, principalmente em virtude
da popularização da Internet e do acesso à banda larga. De modo diferente das aplicações
que não são fortemente dependentes dos aspectos temporais da transmissão, as aplicações
em tempo real exigem uma infra-estrutura de transporte que possa oferecer determinadas
garantias de desempenho aos pacotes. Usualmente, tais garantias são expressas por um
conjunto de quatro métricas: largura de banda, atraso, perda de pacotes e jitter. Exis-
tem diversas soluções disponíveis no mercado para o monitoramento dessas métricas. No
entanto, o cálculo dos valores usualmente depende da aplicação de certos algoritmos in-
termediários que podem dificultar a tarefa. Esse trabalho teve como objetivo a criação
de uma ferramenta em código-aberto e gratuita que fosse capaz de medir diretamente
as quatro métricas descritas acima. Após o desenvolvimento da ferramenta, realizada
com técnicas de engenharia de software, um experimento foi realizado com o intuito de
verificar se os requisitos previamente propostos para a ferramenta foram atingidos. Os
resultados demonstraram que houve pouca variação dos valores coletados em diferentes
amostras, com exceção do jitter. Apesar de os testes terem sido realizados em ambiente
controlado e com técnicas de coleta que podem influenciar as medições, a ferramenta
demonstrou ser rápida e eficaz e pode servir para tornar mais clara e objetiva a medição
de desempenho em redes de pacotes.
Palavras-chave: Live Streaming. Métricas de desempenho de QoS. Ferramenta de mon-
itoramento de redes.

15. A Propose for a Real Time Monitoring Tool for Live Streaming Applications, based
on the RTP Protocol.
ABSTRACT
The use of real-time applications over packet networks (e.g. VoIP, videoconferencing,
live streaming) have grown in recent years, mainly due the popularization of Internet and
broadband access. Differently from the applications that are not heavily dependent on
temporal aspects of transmission, the real-time applications require a transport infrastruc-
ture that can provide certain performance guarantees to packets. Usually, such guaranties
are expressed by a set of four metrics: bandwidth, delay, packet loss and jitter. There are
some solutions available in the market for monitoring these metrics. However, the calcu-
lation of the values usually depends on certain intermediary algorithms that may hinder
the task. This study had the objective to create a free and open source tool that could di-
rectly measure the four metrics described above. After the development of the tool, held
by software engineering techniques, an experiment was conducted with the objective of
whether the previously proposed requisites for the tool have been met. The results showed
that there was almost no variation in the values obtained at different samples, except for
jitter. Although the tests have been conducted in a controlled environment and with data
collection techniques that could influence the measurements, the tool proved to be rapid
and effective and can serve to make clear and objective the performance measurement in
packet networks.
Keywords: Live Streaming, QoS metrics, Network Monitoring Tool.

16. 15
1 INTRODUÇÃO
O live streaming é todo conteúdo audiovisual capturado em tempo real e disponi-
bilizado para inúmeros espectadores através da Internet (VELOS et al., 2002). Diversas
aplicações multimídia podem ser caracterizadas por esse conceito, tais como conversações
por VoIP (Voice over Internet Protocol), videoconferência e entretenimento, e educação à
distância (EaD). De um ponto de vista mais específico, qualquer rede de transporte de da-
dos baseada na técnica de comutação de pacotes (a Internet é apenas um caso particular)
pode ser utilizada para suportar aplicações live streaming. Apesar de mais eficiente em
termos de alocação de recursos do que a técnica de comutação de circuitos, a comutação
de pacotes não reserva recursos para as aplicações. Cada pacote é visto como uma unidade
de informação independente e tratado de maneira individual. Desta forma, os pacotes de
uma aplicação podem sofrer atrasos variáveis quando passam em enlaces congestionados
e até mesmo serem descartados em casos mais severos (KUROSE; ROSS, 2006).
A literatura define quatro métricas de desempenho de rede que influenciam direta-
mente no QoS (Quality of Service) oferecido às aplicações em geral: largura de banda,
atraso, jitter e perda de pacotes. Em função de seus caráter instantâneo de transmissão,
as aplicações live streaming necessitam de uma rede de transporte que ofereça garantias
de desempenho que são expressas por valores adequados para cada uma dessas métricas
(DURKIN, 2002). Apesar de haver um crescimento significativo na utilização de apli-
cações em tempo real (motivado principalmente pelo barateamento do acesso à banda
larga), percebe-se a inexistência de uma ferramenta gratuita e de código-aberto que mon-
itore continuamente todas as quatro métricas de desempenho de rede oferecidas para uma
aplicação em tempo real. Além disso, certas aplicações de monitoramento (especial-
mente aquelas baseadas no protocolo SNMP) são dirigidas ao monitoramento de var-

17. 16
iáveis simples e são complexas no tratamento de variáveis mais complexas e que exigem
um histórico de amostras (como o jitter, por exemplo).
Esse trabalho tem como objetivo o desenvolvimento de um protótipo de ferramenta
de código-aberto para o monitoramento do desempenho de aplicações live streaming
baseadas no protocolo RTP (Real Time Protocol). A concepção desse trabalho teve in-
ício dentro do projeto Convergência Digital da UNISINOS, que tinha como objetivo a
criação de aplicações interativas para a tecnologia de TV Digital. O objetivo principal do
projeto era permitir a maior interatividade possível do usuário com um meio de acesso.
Nesse contexto, foi percebida a necessidade da criação de um sistema Web para interação
aluno-professor utilizando-se um ambiente baseado em videoconferência. Além do sis-
tema, uma ferramenta de monitoramento em tempo real também mostrou-se necessária
com o intuito de informar o usuário da qualidade de sua transmissão live streaming.
Optou-se pela análise de aplicações em tempo real baseadas no protocolo RTP em vir-
tude de sua ampla utilização no transporte de conteúdo multimídia. O protocolo RTP
utiliza como protocolo de transporte o UDP (User Datagram Protocol). O UDP é ampla-
mente utilizado em transmissões com tempo real por ser bastante simples e não-orientado
à conexão (MEGGELEN; SMITH; MADSEN, 2005). Apesar da possibilidade de real-
ização de transmissões em tempo real utilizando o protocolo TCP (Transmission Control
Protocol), optou-se pela análise de aplicações em tempo real baseadas em RTP.
1.1 Trabalhos relacionados
Existem diversos trabalhos teóricos que procuram analisar o impacto das métricas
de desempenho nas aplicações em tempo real. No entanto, poucos descrevem o desen-
volvimento de ferramentas que podem ser utilizadas para medir tais métricas. Tao, Apos-
tolopoulos e Guérin (2008) propôs uma investigação na qualidade de vídeo em redes IP,
por meio da métrica PSNR (Peak Signal Noise Ratio). Este trabalho analisou diversos
codecs e suas relações com a taxa de transmissão e características de vídeo, entre outros
parâmetros. Por outro lado, Lima (2006) propôs a criação de um sistema que permitia a
monitoração das ligações VoIP. Este sistema tinha um caráter centralizado, ou seja, toda a
informação era obtida nos hosts repassada para um banco de dados que realizava cálculos
para obter uma pontuação média de qualidade com relação à qualidade de uma ligação.

18. 17
Ao invés de decodificar os pacotes de controle da transmissão live streaming, o trabalho
propôs a geração de logs por parte da aplicação utilizada na transmissão VoIP, que auxili-
ado pelo protocolo SNMP (Simple Network Management Protocol) alimentava a base de
dados.
Um software pago que possui funcionalidades semelhantes, mas tem uma arquitetura
centralizada, é o Cisco Voip Monitor Server 1 . Esta aplicação realiza toda monitoração
que esta ferramenta propõe, centraliza todos os dados num servidor e requer a instalação
de um agente em cada uma das máquinas que trafegará as ligações VoIP. Uma limitação
desta aplicação é que ela possibilita a monitoração apenas de transmissões VoIP, e não
qualquer outra que se baseie no live streaming.
1.2 Objetivo
O presente trabalho tem como objetivo desenvolver um protótipo de uma ferramenta
de monitoramento de desempenho em tempo real de transmissões live streaming baseada
no protocolo RTP. Além do objetivo geral, este trabalho tem os objetivos específicos cita-
dos a seguir:
1. Estudar as principais métricas de desempenho de QoS que impactam na transmissão
live streaming (em tempo real).
2. Estudar e aplicar o padrão de arquitetura MVC no desenvolvimento do protótipo.
3. Propor técnicas de coleta das métricas de desempenho de QoS.
4. Medir os atributos de desempenho de uma transmissão em tempo real por meio do
protótipo.
1.3 Estrutura do Trabalho
A presente monografia está organizada em 6 capítulos.
1
Disponível em: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/ prod-
ucts_tech_note09186a008010e6ba.shtml. Acesso em 7/outubro/2009.

19. 18
Neste primeiro capítulo, é apresentado o contexto no qual este trabalho está inserido,
o problema que busca solucionar, e os objetivos gerais e específicos. Também, são ap-
resentados os trabalhos relacionados a obra, e a presente estrutura organizacional do tra-
balho.
No segundo capítulo, é apresentado cada um dos conceitos necessários para a pro-
dução deste trabalho. Primeiro, é apresentado o que é e como funciona o streaming e sua
evolução, o live streaming, e uma solução que implemente estas duas tecnologias. Em
seguida, são apresentados e explicado a existência de cada fatores que afetam uma trans-
missão live streaming, os fatores são: atraso, jitter, perda de pacotes e largura de banda.
Na sequência, é explicado o protocolo de sinalização SIP (Session Initiation Protocol),
responsável por estabelecer sessões entre os participantes de uma transmissão. Os próxi-
mos itens a serem explicados são os protocolo RTP e RTCP, que atuam em conjunto per-
mitindo a transmissão e controle dos dados entre integrantes de uma transmissão. Então,
é apresentado o protocolo ICMP (Internet Control Message Protocol), parte integrando
do Internet Protocol (IP), responsável por fornecer feedback de conectividade da rede.
Na próxima seção é descrito o padrão de arquitetura que será utilizado para desenvolver o
protótipo, o MVC (Model View Controller). Por fim, é feita uma síntese do que foi visto
no capítulo.
No terceiro capítulo, é abordada a metodologia empregada para o desenvolvimento
deste trabalho. Primeiro, é descrito o ambiente de pré-testes, em termos de responsabi-
lidade e especificações de hardware e software. Este ambiente é utilizado para execução
das etapas da metodologia. Em seguida, é apresentado a metodologia para coleta, que
engloba (1) a identificação dos dados necessário coletar na rede e sua obtenção, e (2)
com base na análise dos dados da fase anterior são propostas técnicas de obtenção das
métricas desempenho de QoS numa rede. Por fim, é apresentado a etapa de desenvolvi-
mento do protótipo, desde o levantamento dos requisitos até a implementação das técnicas
propostas na etapa anterior da metodologia.
No quarto capítulo, é descrito a experimentação feita com o protótipo. Primeiro, é de-
scrito o ambiente de testes utilizado, contemplando a responsabilidade e as especificações
de software de cada uma dos dispositivos virtuais. Foram utilizadas máquinas virtuais,
pois diferentemente do ambiente de pré-testes, este ambiente deve ser controlado. Então,

20. 19
é executado o teste-piloto, sendo descrita cada uma das etapas contempladas pelo teste.
Na próxima seção, são apresentados os resultados obtidos com o teste e seus significa-
dos, por meio de tabelas. Na última seção, é feita uma análise e discussão dos resultados
obtidos.
No quinto capítulo são feitas as conclusões deste trabalho. É feito um fechamento
e apresentado as dificuldades encontradas, as limitações tanto da metodologia quanto do
protótipo produzido e os trabalhos futuros que podem ser desenvolvidos com base neste.

21. 20
2 REVISÃO BIBLIOGRÁFICA
Neste capítulo serão abordados os conceitos teóricos que subsidiam o tema desse
estudo. Inicialmente o conceito de live streaming é apresentado e os problemas associados
a transmissão em tempo real são descritos. Após, cada um dos protocolos que foram
utilizados no trabalho são descritos: SIP, RTP, RTCP, e ICMP. Em seguida, o padrão
de arquitetura MVC que será utilizado na modelagem do protótipo também é descrito
detalhadamente. O último item do capítulo traz um resumo dos conceitos abordados.
2.1 Live Streaming
A tecnologia de streaming consiste na quebra de um fluxo de dados em pequenos
pedaços para enviá-los um a um sucessivamente, sendo que o receptor decodificará cada
parte e a executará sem ter que esperar por todo o fluxo de dados (APOSTOLOPOULOS;
TAN; WEE, 2002). Essa tecnologia existe desde que as transmissões por rádio e televisão
analógica foram inventadas. O equipamento do espectador, desde aqueles tempos, recebia
dados continuamente, sendo que simultaneamente esses dados eram apresentados, seja
na tela ou nas caixas de som (TOPIC, 2002). Hoje em dia, esse conceito de streaming
foi migrado para a Internet, preservando alguns princípios de antigamente, como o de
oferecer conteúdo sob demanda para o usuário.
Para que um conteúdo estático seja íntegro, é necessário que este seja disponibilizado
em sua totalidade. O streaming, em relação ao conteúdo estático, possui uma grande
vantagem: a possibilidade no acesso ao conteúdo sob demanda (TOPIC, 2002). Conforme
o conteúdo é executado, as partes seguintes estão sendo recebidas e executadas, e desta
forma segue, sucessivamente. A figura 2.1 apresenta um modelo de aplicação baseada no

22. 21
streaming.
Figura 2.1: Diagrama demonstrando uma transmissão por streaming.
Para ser possível a exibição do streaming são necessários três etapas. Primeiro, é
necessário ter a mídia estática, como por exemplo um arquivo de vídeo codificado em
MPEG-2. Então, precisa-se passar esta mídia para um servidor de streaming, que dividirá
a mídia em pequenos pedaços, para serem enviados sequencialmente para o receptor. Por
último, é necessário o receptor ter um player compatível (TOPIC, 2002).
Uma solução de streaming disponível na Internet é o VideoLAN Streaming Solution
1
, que engloba o servidor de streaming e o player para ser executado no receptor. Esta
aplicação suporta os mais diversos protocolos de transporte para aplicações streaming, tais
como: RTP/RTCP, RTSP e HTTP. Também, suporta uma vasta gama de codecs 2 , citados
a seguir: Mpeg-1, Mpeg-2, Mpeg-4, WMV, DivX e H.264. Esta solução possibilita a
utilização não só de arquivos estáticos, mas também de mídias capturadas em tempo real,
caracterizando o live streaming, que será explicado a seguir.
A evolução do streaming é a chamada live streaming, que possibilita a transmissão ao
vivo de uma mídia. Com esta tecnologia é possível enviar, diretamente, para a Internet um
vídeo capturado por uma câmera sem ter que armazená-lo. Esta evolução permite que as
emissoras transmitam via Internet eventos, programas e rádios em tempo real, permitindo
o aumento no número de espectadores que assistem ou escutam seus programas. No
entanto, a áudio e videoconferência foram as aplicações que foram mais difundidas pela
1
O VideoLAN Streaming Solution está disponível no seguinte endereço web:
http://www.videolan.org/vlc/streaming.html. Acesso em: 09/10/2009.
2
Um codec é um conjunto de algoritmos de codificação (e decodificação) de sinais que tem como obje-
tivo a compressão de um sinal buscando a menor perda de qualidade possível. Para mais informações sobre
codecs, consultar Lima (2006).

23. 22
Internet, por meio de programas de fácil acesso como o Skype 3 . A videoconferência
trouxe uma enorme quebra de paradigma, possibilitando que pessoas conversem frente a
frente estando em qualquer lugar do mundo.
Tanto o streaming quanto o live streaming podem ser implementados de muitas maneiras
e com muitas ferramentas. Por ter menos overhead que o TCP, e por não ter confirmação
de cada pacote recebido, o protocolo UDP se torna um atrativo. Em cima do protocolo
UDP, é utilizado o RTP aliado ao RTCP (Real-time Control Protocol), que permite con-
trole e geração de estatísticas da transmissão. Existem implementações que utilizam o
TCP (Transmission Control Protocol) como protocolo de transporte, como a do Skype,
mas o UDP é muito mais utilizado (TOPIC, 2002).
2.2 Fatores que afetam a transmissão Live Streaming
As transmissões em tempo real são sensíveis a quatro parâmetros em uma rede co-
mutada de pacotes: largura de banda, perda de pacotes, atraso e jitter (KUROSE; ROSS,
2006). Este parâmetros podem acarretar na degradação da qualidade da transmissão, se
certos limiares forem ultrapassados. Nas seções seguintes, serão apresentados cada um
dos parâmetros que podem acarretar na perda de qualidade na transmissão.
2.2.1 Atraso
O atraso entre emissor e receptor é subdividido em duas classificações: atraso fim
a fim e atraso de ida e volta. Estes dois tipos de atrasos serão apresentados a seguir,
conforme Lima (2006).
2.2.1.1 Atraso fim a fim
O atraso fim a fim é o tempo que um pacote leva para ir de um emissor para um recep-
tor. Esta métrica é bastante problemática para ser estimada, pois podem existir diferenças
nos relógios do emissor e do receptor. Para solucionar este problema, pode-se utilizar
na rede equipamentos especializados ou serviços de sincronização de relógios que uti-
3
Skype é um programa que permite áudio e videoconferência gratuitamente. Ele está disponível em
http://www.skype.com. Acesso em 09/10/2009.

24. 23
lizam o protocolo NTP (Network Time Protocol). Para mais informações sobre o NTP ver
Rybaczyk (2005).
Este atraso é composto por um somatório dos seguintes atrasos: percurso elétrico
do pacote pela rede IP, formação e reprodução dos pacotes, processamento do sistema
operacional e atraso nas redes IP. Estas origens de atraso serão discutidas nas seções a
seguir, conforme Carvalho (2004) e Lima (2006).
1. Percurso Elétrico: Este atraso corresponde ao tempo em que é capturado um dado
do meio físico, passado por um conversor A/D (Analógico/Digital), transformado-o
numa linguagem que possa ser entendida e armazenada pelo computador. Um ex-
emplo com voz, seria quando a voz do locutor passa pelo transdutor eletroacústico,
para depois atingir o conversor A/D. No lado do receptor, o dado digital sai do con-
versor D/A (Digital/Analógico) e vai para o transdutor eletroacústico. Este atraso
é constante, porém mínimo, pois os elétrons percorrem os circuitos elétricos a uma
velocidade próxima à da luz.
2. Formação e Reprodução dos Pacotes: Representa o tempo utilizado para o preenchi-
mento com dados de voz e/ou vídeo os pacotes live streaming para serem enviados
e reproduzidos no destino como um sinal audiovisual. Estes atrasos estão na faixa
de 20 ms a 30 ms, na sua formação, e de 50 ms na sua reprodução.
3. Sistema Operacional: Este atraso é variável e depende do sistema operacional
utilizado. O atraso está relacionado à fatia de tempo que o kernel do sistema opera-
cional aloca para o processo responsável pela transmissão live streaming, à capaci-
dade de processamento do sistema, à memória do equipamento e da quantidade de
processos que estão em execução em paralelo.
4. Atraso nas Redes IP: Este é o atraso que é o gargalo na transmissão. Devido a
este atraso, a interatividade da conversa pode sofrer um efeito desconfortável, e,
segundo a recomendação G.114 (ITU, 2003) esse tempo não deve ultrapassar 150
ms, pois a degradação de qualidade é perceptível. Este atraso é composto por uma
parte fixa e outra variável.
(a) Atraso Variável: O atraso variável corresponde ao tempo em que o pacote
passa pelas filas de transmissão. O número de roteadores e comutadores

25. 24
que estão entre a origem e o destino, e seu poder de processamento, con-
tribuem diretamente para a formação do atraso variável. Uma maneira eficaz
de minimizar este atraso é a implementação de QoS, permitindo que os pa-
cotes live streaming tenham uma prioridade maior que os pacotes de dados
convencionais.
(b) Atraso Fixo: É composto por três tipo de atraso: tempo de empacotamento,
tempo de serialização e atraso de propagação no meio físico.
i. Tempo de empacotamento: Corresponde ao tempo necessário para se
codificar ou decodificar os dados com os codecs necessários. Este tempo
depende unicamente do tipo de codificação e codec utilizado. Caso o
codec possua um algoritmo de alta complexidade, o tempo pode ser ex-
tendido. Para maiores informações sobre codecs de áudio e vídeo consul-
tar Lima (2006).
ii. Tempo de serialização de bits: É o tempo necessário para se colocar
os bits lógicos dos pacotes no meio físico de transmissão, sendo que
este depende da velocidade do meio físico e do tamanho do pacote que
está sendo transmitido. É possível obter este valor por meio da razão do
tamanho do pacote já contendo o cabeçalho da camada de enlace e a taxa
de transmissão do meio (ambos em kbps).
iii. Atraso de propagação: Corresponde ao tempo em que os bits levarão
para se propagar até o próximo nó da rede. Este tempo depende do meio
físico que conecta um nó ao outro.
Concluindo esta seção, o somatório dos tempos de fila, serialização e propagação
compõem o tempo de rede. O primeiro é considerado um tempo estocástico, pois pacotes
distintos de um mesmo fluxo de dados podem sofrer atrasos de filas diferentes, a depen-
der do caminho percorrido pela rede IP. Já os tempos de serialização e propagação são
considerados tempos determinísticos, pois são tempos fixos a depender da velocidade de
transmissão do meio físico.

26. 25
2.2.1.2 Atraso de ida e volta
O atraso de ida e volta é o tempo que um pacote leva para ser enviado por um emissor,
recebido pelo receptor, e devolvido para o emissor. Outro nome o qual é referido este
atraso é o round trip time, ou RTT. Diferente ao outro tipo de atraso, o atraso de ida volta
não depende da sincronicidade dos relógios, porém, algumas considerações devem ser
feitas, como por exemplo, a precisão mínima de leitura do relógio no sistema operacional.
Mas, os mesmo princípios apresentados na seção 2.2.1.1, de composição do atraso se
aplicam para este também.
Este atraso não corresponde ao valor do atraso fim a fim multiplicado por dois, pois a
rede IP é assimétrica, portanto, o tempo que o pacote leva para chegar ao seu destino não
corresponde, necessariamente, ao mesmo tempo que levaria para voltar à sua origem. Isto
depende da maneira na qual os pacotes são roteados e comutados ao longo da rede.
2.2.2 Jitter
O jitter se refere à variação na latência entre dois pacotes, ou seja, é a diferença entre
as latências de dois pacotes, medida em dois instantes de tempos diferentes. Quando um
fluxo live streaming é enviado para um dispositivo, ele é enviado à uma taxa constante
com uma pequena variação na latência. No entanto, conforme os pacotes atravessam a
rede, a latência dos pacotes pode variar, e chegar no destino em tempos diferentes, e pos-
sivelmente, fora de ordem. O buffer de compensação de jitter é uma área de memória em
que os pacotes são reordenados e entregados em streams constantes e reguladas (MEGGE-
LEN; SMITH; MADSEN, 2005).
Os pacotes necessitam de um tempo para se propagar da origem até o destino na
rede IP. A diferença entre o tempo de chegada e o de partida é composta por uma parte
fixa e outra variável (jitter). Esta parte variável se deve ao comportamento das filas de
roteamento, como visto na seção 2.2.1.1.
Caso os pacotes recebidos fossem executados sem nenhum tratamento para jitter, a
qualidade da transmissão seria comprometida. Para isso, os receptores da transmissão
implementam um buffer para compensar os efeitos do jitter. Este buffer tem como função
segurar os pacotes por um tempo máximo até que os seus adjacentes possam chegar, e

27. 26
a reprodução possa ser feita de modo síncrono (LIMA, 2006). A compensação de jitter
pode ser observada na figura 2.2.
Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em ação
(LIMA, 2006).
O tamanho deste buffer é o período de tempo máximo em que este pacote aguardará
até ser reproduzido pelo cliente. Este valor deve ser bem especificado, pois se o tamanho
for muito pequeno, os pacotes correm o risco de não chegarem a tempo e serem descarta-
dos, em contrapartida, se o tamanho do buffer de compensação for muito grande o atraso
fim a fim será aumentado, degradando a qualidade da transmissão. Segundo Meggelen,
Smith e Madsen (2005), este valor não deve exceder 30 ms para uma transmissão com
streaming.
Para se determinar corretamente o valor do buffer, duas variáveis devem ser anal-
isadas: a perda de pacotes e o atraso fim a fim. Também, é levado em consideração
que estes valores devem respeitar os limiares de segurança, para que não se tenha uma
degradação na qualidade da transmissão. Para a perda de pacotes o valor é 5% e para o
atraso fim a fim é de 150 ms, conforme ITU (2003).
2.2.3 Perda de Pacotes
Uma perda de pacote, sob o ponto de vida da transmissão pela rede IP, ocorre quando
o mesmo não consegue chegar ao seu destinatário. A perda de pacotes é impactante no
contexto de uma aplicação live streaming. Os três principais motivos pelos quais podem
ocorrer perdas de pacotes são: erros na transmissão, descarte pelos roteadores de rede, ou

28. 27
ainda, por causa do buffer de compensação de jitter (LIMA, 2006).
Como a rede IP, por si só, não garante a entrega dos pacotes, no momento que ela se
encontra sobrecarregada, ocorrem congestionamentos. Quando o roteador está com seus
buffers cheios, a solução empregada por eles é o descarte dos pacotes. Se o protocolo de
transporte empregado for o TCP, este cuidará para que os pacotes sejam retransmitidos.
Ao passo que se for utilizado o UDP, como é um protocolo simples e não-orientado à
conexão, os pacote não são recuperados.
O problema de perdas de pacotes pode ser amenizado, utilizando técnicas ou mecan-
ismos de reparação de pacotes perdidos, tais como: FEC (Forward Error Correction), in-
terleaving, retransmissão e compensação. Cada uma destas técnicas e mecanismos serão
apresentadas nos itens a seguir, conforme Balbinot et al. (2003).
1. FEC: Este mecanismo é um dos mais utilizados na atualidade, para manutenção na
qualidade de sistemas VoIP. Com o FEC é adicionado uma redundância nos dados,
permitindo a correção de dados perdidos ao longo da transmissão. A cada quadro
ou pacote de voz, é adicionada informação relacionada às amostras de voz mais
adiantadas ou mais atrasadas. Deve-se pesar bastante a necessidade de utilizar este
mecanismo, pois como é adicionado uma redundância de dados na rede, pode-se
causar congestionamento desnecessário. Se a perda já é decorrente de um conges-
tionamento, o aumento neste fluxo pode agravar a situação.
2. Interleaving: Esta técnica reordena os quadros de mídia de múltiplos pacotes se-
quencias, interpolando-os antes de efetuar o envio deste fluxo de dados. Quando o
receptor receber este fluxo, este é reordenado em sua ordem original. Caso ocorra
alguma perda de pacotes ao longo da transmissão, terá sido perdido poucos quadros,
possibilitando uma reconstrução da mídia com perdas não significativas. Combi-
nada com técnicas de compensação, pode-se obter um nível aceitável de qualidade
para taxas não muito elevadas de perda.
3. Retransmissão: Esta técnica reenvia o pacote perdido. Para esta técnica ter sucesso
é necessário que o pacote retransmitido chegue ao receptor a tempo para ser repro-
duzido. Normalmente, esta técnica é utilizada em redes com alta disponibilidade.
4. Compensação: Este mecanismo é aplicado no lado do receptor, com o objetivo

29. 28
de corrigir eventuais situações ocorridas devido à perda de pacotes. Existem três
classes de compensação que podem ser utilizadas: técnicas de inserção, interpo-
lação e regeneração.
(a) Técnica de inserção: Prevê a substituição do pacote perdido por ruído, silên-
cio ou a repetição do último pacote recebido com sucesso;
(b) Interpolação: Procura recriar uma versão similar do pacote perdido através
da interpolação entre pacotes adjacentes, armazenados num buffer de amostras;
(c) Regeneração: Amplia o conceito da interpolação utilizando além dos pacotes
adjacentes, informações à respeito do codec utilizado na codificação dos da-
dos.
Pacotes que chegam demasiadamente atrasados em relação ao instante de tempo que
deveriam ser reproduzidos no receptor tornam-se inúteis, e consequentemente, são descar-
tados. Do ponto de vista do receptor, estes pacotes foram perdidos. Portanto, para se
calcular o número de pacotes perdidos num enlace, deve-se levar em conta as perdas dos
pacotes na camada de rede e também na camada de aplicação.
Para as transmissões live streaming, a perda de pacotes deve ser inferior a 5% (ITU,
2003). Caso este valor seja excedido, a perda da qualidade na transmissão é perceptível
pelo usuário final. Numa transmissão VoIP, a qualidade da conversação será afetada.
2.2.4 Largura de Banda Disponível
Numa rede de computadores, sempre é buscado que os dados fluam pelo melhor cam-
inho por meio dos roteadores, partindo da origem para o destino. A quantidade de infor-
mação por segundo que um meio de transmissão permite fluir é denominada largura de
banda disponível. Este dado é expresso em bytes/segundo ou bits/segundo (RANJBAR,
2007).
A demanda de utilização da largura de banda disponível é controlada pela aplicação.
Algumas aplicações necessitam enviar dados a uma certa taxa mínima para funcionar com
êxito, é o exemplo de aplicações live streaming. Esta aplicações, além de serem sensíveis
à perda de pacotes, atraso e jitter, também são sensíveis à largura de banda. Se uma certa
largura de banda não estiver disponível, a aplicação terá que codificar os dados a uma

30. 29
taxa diferente (adequando-se a largura de banda disponível), ou terá que desistir de enviar
os dados, pois se os dados chegarem depois do que o esperado eles serão descartados de
qualquer maneira (KUROSE; ROSS, 2006).
Também, existem aplicações nas quais não necessitam uma largura de banda mínima.
As chamadas aplicações elásticas tem a capacidade de fazer o uso de qualquer largura de
banda mínima ou máxima disponível. Navegação web, correio eletrônico e transferência
de arquivo são exemplos de aplicações elásticas (KUROSE; ROSS, 2006).
A largura de banda disponível muitas vezes acaba por ser um dos grandes proble-
mas numa rede. Isto ocorre, pois a solução direta para este problema é o aumento da
largura de banda disponível. Mas, para isso ser possível são necessários investimentos na
infra-estrutura, muitas vezes inviabilizando num primeiro momento este upgrade. Este é
apenas um dos métodos para se poder trafegar mais dados numa rede. Todos os métodos
disponíveis seguem a seguir, conforme Ranjbar (2007).
1. Aumentar a capacidade do link: Como foi mencionado no parágrafo a seguir, esta
é a maneira mais efetiva, porém a com mais custo direto. Para que seja aumentada
a capacidade do link de dados, é necessário um investimento, o que é uma certa
limitação para a resolução deste problema.
2. Marcar e classificar tráfego e implantar técnicas de filas: Com este método
é possível que os dados com maior prioridade sejam encaminhados primeiro ao
longo da rede. Para que este método funcione, é necessário que os dados sejam
demarcados na camada de acesso da rede, para que ao longo dela sejam aplicadas
as técnicas de filas de prioridade. Para mais informações sobre filas de prioridades,
consultar Ranjbar (2007).
3. Utilizar técnicas de compressão: Existem técnicas que realizam a compressão de
dados de alguns protocolos. Devem ser utilizadas com muito planejamento, pois
os equipamentos que realizarem esta compressão estarão realizando um processa-
mento a mais do que em sua operação convencional. Algumas das técnicas exis-
tentes são: compressão de TCP, de camada 2 e de RTP. Neste último, o roteador
desempenha um papel crucial, pois este compressão mapeia os cabeçalhos IP, UDP
e RTP, compactando esta soma de cabeçalhos dos 40 bytes originais, para 2 bytes.

31. 30
2.3 Protocolo de Sinalização: SIP
O SIP é (Session Initiation Protocol) um protocolo de sinalização que roda na ca-
mada de aplicação, que engloba a criação, modificação e finalização de uma sessão entre
um e/ou mais participantes. Estas sessões incluem ligações via Internet, conferências e
distribuição de conteúdo multimídia. Como o SIP é um protocolo que engloba apenas a
sinalização, é necessário um protocolo que possibilite o transporte da informação fim-a-
fim, neste contexto, o RTP é empregado.
Idealizado por Henning Schulzrinne em 1990, no Departamento de Ciência da Com-
putação da Universidade de Columbia, este protocolo teve sua primeira especificação
formal submetida pelo IETF (Internet Engineering Task Force) em 1999, descrita na RFC
(Request for Comments) 2543. O IETF continuou o trabalho de especificação e otimiza-
ção do protocolo SIP, e em 2001 liberou outra especificação, a RFC 3261.
Devido a sua simplicidade, extensibilidade e escalabilidade, ainda em 2001, diver-
sas empresas começaram a adotar este protocolo em seus produtos, mesmo com outros
protocolos já firmados no mercado como o H.323 e o MGCP (Media Gateway Control
Protocol). Para mais informações sobre estes protocolos ver a referência Durkin (2002).
Mesmo não sendo o protocolo de sinalização adotado por grande parte das empresas para
conferências, este trabalho optou por utilizar o SIP, pois as soluções de código-aberto
adotaram o SIP como padrão. O Asterisk é a principal aplicação de código-aberto para
aplicações VoIP e conferência, conforme cita Meggelen, Smith e Madsen (2005). Um
exemplo de solução que utiliza o Asterisk como base é a TrixBox 4 , que agrupa uma co-
letânea de softwares que atuam em sinergia para ter como resultado um PABX que pode
interligar redes IP com redes PSTN (rede telefônica pública comutada).
O protocolo SIP foi criado para ser simples, deste modo a codificação das mensagens
é feita toda em caracteres ASCII (ROSENBERG et al., 2002). Desta maneira, é possível
ver todas as mensagens em formato de texto. Todas os tipos de mensagens trocadas pelo
protocolo SIP são apresentadas nos itens a seguir, conforme Lima (2006) e Rosenberg et
al. (2002).
1. INVITE: utilizada para se iniciar uma chamada. Esta mensagem, além de possuir
4
A solução IP-PABX TrixBox está disponível em http://www.trixbox.org/. Acesso em 11/10/2009.

32. 31
os dados SIP, contêm dentro dela dados do protocolo SDP (Session Description
Protocol), definido na RFC 2327. Por meio dos dados incluídos no SDP, é pos-
sível identificar todos os dados da sessão, tais como: número de porta de origem
e destino para a transmissão RTP, codec utilizado, tipo de sessão (voz ou vídeo), e
informações de cada um dos componentes da sessão.
2. ACK: enviada pelo cliente para confirmar que ele recebeu uma resposta final do
servidor, como por exemplo: 200 OK;
3. OPTIONS: é enviada de um cliente para o servidor para verificar suas capacidades.
O servidor, por sua vez, envia de volta uma lista com os métodos que ele suporta;
4. BYE: enviada por algum dos clientes para para interromper ou encerrar uma chamada;
5. CANCEL: enviada para interromper uma mensagem enviada anteriormente en-
quanto o servidor ainda não tiver enviado uma resposta final;
6. REGISTER: clientes podem registrar sua localização atual com esse pedido. Um
servidor SIP que aceita esta mensagem é denominado Registrar. Com esta men-
sagem é possível adicionar, remover e pesquisar associações de clientes, com suas
respectivas localizações (ROSENBERG et al., 2002).
Ao trocar mensagens, as respostas são identificadas por números, que identificam a
classe da resposta. As respostas estão divididas em 6 categorias (para mais informações
consultar Douskalis (2000)):
1. Classe 1xx: mensagens informativas;
2. Classe 2xx: sucesso;
3. Classe 3xx: redirecionamento;
4. Classe 4xx: erros do cliente;
5. Classe 5xx: erros do servidor;
6. Classe 6xx: falhas globais.

33. 32
O ambiente no qual é executado o protocolo SIP é dotado de duas entidades físicas: o
cliente e o servidor. O cliente é conhecido como User Agent, e o servidor possui diversas
funções distintas: Proxy, Redirect, Registrar e Gateway server. Na figura 2.3 é possível
observar cada uma destas funções numa rede. Estas funções são explicadas nas próximas
seções, conforme Rosenberg et al. (2002) e Lima (2006).
Figura 2.3: Funções das entidades numa rede SIP.
2.3.1 User Agent
O UA (User Agent) é o ponto final da comunicação, o usuário final. Existem ainda
duas subdivisões: o UA Client (UAC) e UA Server (UAS).
O UAC é a entidade lógica que cria uma nova requisição de comunicação. Este papel
é mantido apenas enquanto durar a transação. O papel não é mantido ao longo de toda
a sessão, pois se uma aplicação inicia uma requisição ela é mantida como UAC desta
transação. Se, durante a sessão receber uma requisição, a outra parte será o UAC desta
transação.
Em contrapartida, o UAS é a entidade lógica que gera uma resposta para uma requi-

34. 33
sição SIP. A resposta aceita, rejeita ou redireciona a requisição. Da mesma maneira que o
UAC, este papel é mantido apenas enquanto durar a transação.
2.3.2 Proxy Server
Tem como função redirecionar requisições e respostas SIP. Ele age como uma enti-
dade intermediária que atua como ambos cliente e servidor no âmbito de realizar requi-
sições como se fosse outros clientes. Ele atua como se fosse um roteador, recebendo uma
requisição de sessão de um UA, e consultando o registrar server para descobrir infor-
mações do UA de destino. Se o UA de destino estiver no mesmo domínio, a requisição de
sessão é enviada diretamente para o UA, caso contrário é enviado para o proxy server do
domínio em questão.
O proxy server interpreta, e se julgar ser necessário, reescreve a mensagem de requi-
sição antes de encaminhá-la. É utilizado muitas vezes para aplicar políticas de restrição
sob os UAs.
2.3.3 Redirect Server
O redirect server é um UAS que ao receber mensagens do tipo INVITE gera respostas
de classe 3xx, com um novo endereço SIP. Este servidor responde as requisições com um
novo endereço, mas não faz o papel de continuar a chamada, como no caso do proxy
server. Pode ser usado em conjunto com um registrar server, redirecionando chamadas
para a localização atual do originador da chamada (RIBEIRO; RODRIGUES; MARCON-
DES, 2001).
2.3.4 Registrar Server
Este servidor aceita as requisições do tipo REGISTER e coloca as informações rece-
bidas do usuário em algum servidor de localização. Os registrar servers são necessários
para manter a informação de localização atual de um usuário. O endereço IP de um
usuário pode ser alterado por alguma circunstância, como por exemplo, uma conexão de
acesso à Internet que forneça ao cliente um endereço IP dinâmico.
Para se manter este registro, estas mensagens são trocadas periodicamente entre o UA

35. 34
e o registrar. Se um UA se mover na rede e deseja negociar novos parâmetros do registro,
ele pode cancelar um registro existente e enviar um novo, conforme Douskalis (2000).
2.3.5 Gateway Server
O gateway faz a interconexão entre redes SIP e redes que não utilizam este protocolo,
como por exemplo, uma rede VoIP com outro protocolo de sinalização, ou uma rede de
telefonia comutada (PSTN).
Este dispositivo realiza funções de tradução da sinalização utilizada para o estabelec-
imento e término de chamadas e a conversão do formato da mídia de uma rede para outra.
As chamadas podem ser destinada a telefones tradicionais ou a dispositivos SIP, mas o
gateway deve saber como encaminhá-las.
A aplicação Asterisk é um exemplo de um gateway server.
2.4 Protocolos de Transporte
Para se transmitir dados de uma rede para outra, seja ela qual for, é necessário que
estes dados sejam encapsulados com diversos cabeçalhos, partindo da camada física até a
camada de aplicação. A quarta camada do modelo TCP/IP, a camada de transporte, prevê
a comunicação lógica entre processos de aplicação que rodam em hospedeiros diferentes,
conforme Kurose e Ross (2006). Neste contexto, como este trabalho está lidando com
aplicações live streaming, que são sensíveis principalmente ao atraso e às perdas de pa-
cotes, surge a necessidade de utilizar o protocolo RTP, que tem como principal função
agir como uma interface entre aplicações em tempo real e os protocolos da camada de
transporte. Os dois protocolos que estão disponíveis na camada de transporte são o TCP,
definido na RFC 793 e o UDP, definido na RFC 768.
O protocolo TCP é o protocolo mais utilizado na Internet (LIMA, 2006). Este proto-
colo foi criado com o objetivo de garantir a entrega dos pacotes, por isso cada pacote tran-
sitado pelo TCP deve receber a confirmação do recebimento, na terminologia, o acknowl-
edge (ACK) (mais detalhes em Agency (1981b)). Como numa transmissão em tempo
real, se um pacote é perdido ou corrompido, a sua retransmissão não seria necessária (o
pacote seria relevante apenas no instante de tempo que passou), o protocolo TCP causaria

36. 35
um overhead de informações na rede. Além disso, o TCP não suporta a entrega de pa-
cotes via multicast (entrega de um para muitos). Para maiores informações a respeito de
multicast, consultar Stewart e Gough (2008). Por fim, o TCP não fornece informações,
nem estatísticas da transmissão que possam ser analisadas para verificar a qualidade da
transmissão.
O protocolo UDP também é bastante utilizado na Internet, e foi criado com o objetivo
de ser simples. Este protocolo não é orientado à conexão, logo os pacotes perdidos ou
corrompidos no meio do caminho não são reenviados. Outra característica do UDP é
que os pacotes (segmentos no contexto da camada de transporte) não possuem qualquer
informação temporal nem número de sequência. Diferentemente do TCP, o UDP não
causa nenhum atraso pré-transmissão, pois como é não orientado à conexão não utiliza a
técnica de apresentação de três mensagens que possui o TCP (three way handshake).
A grande maioria das aplicações live streaming utiliza os protocolos RTP/RTCP/UDP,
pois o UDP gera menos overhead na comunicação (LIMA, 2006).
Os protocolos RTP e RTCP serão abordados nas próximas seções.
2.4.1 Real-time Transport Protocol (RTP)
O protocolo RTP permite o transporte fim-a-fim de aplicações que transmitam dados
em tempo real, como áudio e vídeo, por meio de multicast ou unicast. Este protocolo não
garante a qualidade do serviço (QoS) para transmissões em tempo real, por isso funciona
em conjunto com o RTCP que permite monitorar a entrega, gerar estatísticas dos dados,
e identificar os usuários que os recebem - numa rede multicast - proporcionando dados
para o administrador analisar e realizar uma melhora no serviço. Uma maneira para se
garantir a QoS é: (1) aplicar a marcação expedite forwarding no byte ToS (type of service),
contido no pacote IP e (2) permitir que este tráfego flua dentro de uma fila de prioridade
nos roteadores que estiverem intermediando esta transmissão. Para mais informações
sobre QoS e filas de prioridades ver Ranjbar (2007).
Este protocolo foi idealizado por Henning Schulzrinne e teve sua especificação inicial
submetida pela IETF em 1996, como a RFC 1889. Após diversas modificações, princi-
palmente na maneira que era calculado o jitter e o tempo de envio dos pacotes RTCP

37. 36
(SCHULZRINNE et al., 2003), em 2003, o IETF submeteu a nova especificação RFC
3550.
O RTP é específico para o tráfego de dados, deixando a cargo do RTCP estatísticas das
informações. Mas, o RTP possui informações atreladas ao pacote, tais como: timestamp,
número de sequência, descrição dos dados e identificação global. O pacote RTP pode ser
visto na figura 2.4 5 . Como o RTP roda sob o UDP, não é possível garantir a entrega das
informações sem erro. Portanto, os protocolos das camadas inferiores devem prover este
serviço, os quais, encapsulam os dados RTP (DOUSKALIS, 2000).
A negociação das portas associadas ao RTP é feita dinamicamente pelo protocolo de
sinalização, mas, tradicionalmente, à porta RTP é atribuído um número par e, a porta
RTCP recebe o próximo valor (SCHULZRINNE et al., 2003). Se a porta RTP fosse de
número 8000, a RTCP seria 8001.
Figura 2.4: O pacote RTP.
2.4.2 RTP Control Protocol (RTCP)
O RTCP, também especificado na RFC 3550, é responsável pelo controle da transmis-
são de dados em tempo real por meio do protocolo RTP. Este protocolo complementa o
RTP nas suas funcionalidades, permitindo aos hosts participantes da transmissão receber
relatórios de como os dados estão sendo recebidos em termos quantitativos.
Desde a sua idealização na RFC 1889, este protocolo sofreu duas principais modifi-
5
Figura extraida de: http://java.sun.com/javase/technologies/desktop/media
/jmf/2.1.1/guide/images/RTPRealTime2.gif. Acesso em 12/10/2009.

38. 37
cações. A primeira modificação aconteceu no instante de tempo em que os pacotes RTCP
são enviados. No modelo original, o tempo de envio não era otimizado, causando um
overhead de pacotes RTCP quando existiam mais integrantes na transmissão. A segunda
modificação aconteceu na fórmula que calcula o jitter dos pacotes. Como o jitter é um
dado complexo de ser calculado, a equação foi aperfeiçoada possibilitando uma melhor
exatidão no resultado.
Este protocolo é baseado no envio periódico de pacotes de controle para todos os
participantes da sessão, utilizando o mesmo mecanismo de comunicação dos dados. O
protocolo da camada inferior (UDP) é responsável por fornecer a multiplexação dos dados
e dos pacotes de controle, utilizando números de portas diferentes (LIMA, 2006).
As quatro principais funções do protocolo de controle RTCP, conforme Schulzrinne
et al. (2003) são:
1. Obter feedback da qualidade da transmissão de dados. Como o protocolo RTP
é comumente utilizado para transmissões live streaming, que são sensíveis a muitas
variáveis, esta função é vital para obter um nível mínimo de qualidade na trans-
missão. Esta função de feedback é proporcionada pelos sender e receiver reports,
discutidos nas próximas seções. O presente trabalho analisa estas mensagens e re-
aliza cálculos para se obter um feedback visual.
2. Portar identificação persistente. Os pacotes RTCP carregam uma identificação
persistente ao nível de tranporte chamada de CNAME (canonical name). Enquanto
que o identificador de fonte de sincronização (SSRC) pode mudar, devido à falhas
de software ou de conexão, o CNAME deverá ser o mesmo ao longo de toda uma
sessão.
3. Enviar pacotes RTCP. Para que as duas funções anteriores possam funcionar, é
necessário que cada um dos participantes da sessão enviem pacotes RTCP. Mas,
para que o sistema possa acomodar crescimento em grandes escalas, é necessário
que esta taxa seja controlada. Como cada um dos participantes envia seus pacotes
RTCP, eles também recebem e podem saber o número de participantes na sessão.
Este valor é utilizado para se calcular o tempo de envio de cada pacote RTCP.
4. (Opcional) Controle dos participantes da sessão. A RFC 3550 ainda cita a cober-

39. 38
tura mínima de uma sessão, como o descobrimento do nome dos participantes, con-
forme entram e saem. Esta função seria interessante numa audioconferência na
qual não se tem controle da entrada dos participantes. Este passo é opcional, pois é
necessário ter um protocolo na camada superior a esta.
A especificação (SCHULZRINNE et al., 2003) define cinco tipos de pacotes RTCP:
1. SR (Sender report): responsável pelo envio e recebimento de estatísticas rela-
cionadas à transmissão de cada um dos participantes são emissores ativos. Este
pacote é analisado pelo presente trabalho para coletar as estatísticas, e é possível
visualizá-lo na figura 2.5 6 . Neste pacote, é apresentado uma das informações cru-
ciais para a análise da aplicação, o campo fraction lost. Este campo apresenta o
valor de perda de pacotes relativo com base de 256, ao invés de 100. Isto ocorre,
pois é dedicado um byte para o armazenamento desta informação.
2. RR (Receiver report): responsável pela recepção de estatísticas relacionadas à
transmissão de cada um dos participantes que não são emissores ativos. É possível
visualizar este pacote na figura 2.6 7 .
3. SDES (Source Description): pacotes compostos de zero ou mais blocos, sendo que
cada bloco é preenchido pelos itens que o definem. Estes itens incluem o identifi-
cador SSRC, e itens de descrição, incluindo o CNAME.
4. BYE: indica o fim da sessão.
5. APP: realiza funções específicas de alguma aplicação que o implemente.
O fluxo de pacotes RTCP, não deve exceder 5% da largura de banda dedicada para as
transmissões live streaming. Para isso, é aplicado um algoritmo determinístico para cal-
cular o tempo de envio dos pacotes RTCP. Para maiores informações sobre como calcular
o tempo de envio, consultar Schulzrinne et al. (2003).
6
Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-
ments/images/rtcp_sr_header.jpg. Acesso em 13/10/2009.
7
Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-
ments/images/rtcp_rr_header.jpg. Acesso em 13/10/2009.

40. 39
Figura 2.5: O tipo de pacote sender report, do protocolo RTCP.
2.5 Protocolo para Feedback : ICMP
O ICMP, especificado na RFC 792, é um protocolo criado para ser rodado em todos
os hosts e roteadores para comunicar informações da camada de rede. Este protocolo é
considerado parte integrando do protocolo IP, mas ao analisar sua arquitetura, é possível
verificar que este é encapsulado pelo IP, conforme Kurose e Ross (2006).
Em 1981, este protocolo foi especificado pelo DARPA (AGENCY, 1981a) como parte
integrante do IP, pois permitia o fornecimento de feedback da conectividade IP. Ele ape-
nas existe, pois uma rede IP não é considerada confiável. Por ser um protocolo de fun-
cionamento bastante simplificado, evoluiu apenas com extensões, mas sua especificação
original se manteve intacta ao longo de quase 30 anos.
Este protocolo atua enviando mensagens de um emissor para um receptor, sendo que
este receptor deve enviar uma resposta, se for tiver conectividade. No cabeçalho desta
mensagem além dos dados do protocolo IP, estão disponíveis o tipo e o código da men-
sagem. Existe uma grande combinação de tipos e códigos de mensagem para ser utilizado,
portanto na tabela 2.1 é apresentado os tipos mais comuns. Para ver todos os tipos, con-

41. 40
Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP.
sulte a especificação do protocolo ICMP, Agency (1981a).
Existem duas aplicações bastante difundidas que utilizam o ICMP como base, o Ping
e o Traceroute.
O Ping é uma aplicação em que é possível se verificar a conectividade da rede. Além
disso, é possível mensurar o tempo em que o pacote demora para ir e voltar ao host de
destino, desprezando-se perdas decorrentes de processamento do host e atraso da propa-
gação elétrica. Esta aplicação funciona enviando para um receptor um pacote contendo
um tipo de mensagem 8 (solicitação de eco) e código 0. O pacote trafega ao longo da
rede, e ao chegar no host de destino, ele desencapsula o pacote, verifica a mensagem e
envia uma outra mensagem contendo ambos tipos e códigos da mensagem com o valor 0
para o emissor original. Se fosse contado o tempo que o pacote levou para ir e voltar para
o host que enviou a solicitação de eco, seria possível mensurar o atraso de ida e volta dos
pacotes, ou o round-trip delay.
Da mesma forma que o Ping utiliza o ICMP, o Traceroute também o utiliza para de-
scobrir o caminho que um pacote percorre para se atingir um destino e o tempo decorrente.
Para descobrir estes dados, um roteador de origem envia para o primeiro roteador um pa-
cote ICMP com TTL (time to live) 1, para o segundo roteador um pacote ICMP com
TTL 2, e assim sucessivamente até o enésimo roteador. Além disso, é executado tem-
porizadores para cada um destes pacotes. Quando o enésimo pacote chega ao enésimo

42. 41
Tipo de mensagem ICMP Código Descrição
0 0 resposta de eco
3 0 rede de destino inalcançável
3 1 host de dedestino inalcançável
3 2 protocolo de destino inalcançável
3 3 porta de destino inalcançável
3 6 rede de destino desconhecida
3 7 host de destino desconhecido
4 0 redução da fonte (controle de congestionamento)
8 0 solicitação de eco
9 0 anúncio do roteador
10 0 descoberta do roteador
11 0 TTL expirado
12 0 cabeçalho IP inválido
Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a descrição.
roteador, este roteador verifica que o TTL expirou, e seguindo as regras do protocolo IP,
o roteador descarta o pacote e responde a mensagem com uma mensagem ICMP de TTL
expirado, ou tipo de mensagem 11, código 0. Esta mensagem inclui o nome do roteador
e seu endereço IP. Quando esta mensagem chegar ao emissor ele poderá parar o tempo-
rizador, obter o tempo que levou para cada um destes pacotes ir e voltar até os enésimos
roteadores, e obter o nome de cada um deles (KUROSE; ROSS, 2006).
Os protocolos de rede apresentados até esta seção foram utilizados na definição das
técnicas de medição das métricas de desempenho de QoS. No entanto, para conceber o
protótipo são necessárias técnicas de engenharia de software. Neste contexto, surge a
necessidade de se utilizar o padrão de arquitetura MVC, que será apresentado na próxima
seção.
2.6 Padrão de Arquitetura: MVC
O padrão Model View Controller, mais conhecido como MVC, é um padrão de ar-
quitetura utilizado para se desassociar a lógica do negócio, o acesso aos dados, e a apre-

43. 42
sentação e interação do usuário. Com o MVC é possível aliar um desenvolvimento ágil
com um baixo acoplamento, isolando a lógica do modelo visual, e realizando a interco-
municação por meio do controlador. (MICROSYSTEMS, 2008).
Originalmente, este padrão surgiu para a linguagem de programação SmallTalk, que
é uma linguagem de programação puramente orientada à objetos. Para mais informações
sobre o SmallTalk e orientação à objetos ver LaLonde (2008). O autor pioneiro que
realizou a implementação no SmallTalk foi Trygve Reenskaug. Devido a aprovação que
teve este padrão, hoje em dia é um dos mais conhecidos para organização de arquitetura
para sistemas interativos (BUSCHMANN et al., 1996).
Atualmente, este padrão para a engenharia de software é utilizado em linguagens
baseadas no paradigma orientado à objetos, pois aplicações que contém os códigos de
acesso à dados, códigos da lógica do negócio e códigos de apresentação misturados, são
difíceis de manter. O problema existe, pois a interdependência entre os componentes
causa um forte efeito ripple, portanto uma pequena mudança no código pode afetar toda
a aplicação. O alto acoplamento torna quase impossível a reutilização dos componentes,
pois eles dependem uns dos outros (MICROSYSTEMS, 2008). Ao utilizar este padrão, é
possível criar diferentes visualizações sem afetar a integridade dos dados, como é possível
visualizar na figura 2.7.
Figura 2.7: Apresentação de diversas visualizações possíveis por causa do MVC,
sem alterar a integridade dos dados de negócio (BUSCHMANN et al., 1996).
O papel de cada uma das partes da modelagem é apresentado nos itens a seguir, con-
forme MicroSystems (2008):

44. 43
1. Model: Representa os dados da corporação e as regras de negócios. Muitas vezes,
serve como uma aproximação do software com o processo do mundo real.
2. View: Renderiza o conteúdo de um modelo (Model). Esta parte acessa os dados
por meio de um modelo e especifica como estes dados deverão ser apresentados.
Também, é responsabilidade do View manter a consistência na apresentação quando
os dados forem alterados.
3. Controller: Traduz as interações do View em ações para ser efetuadas no Model.
Numa interface gráfica, interações poderiam ser clicks e numa aplicação Web pode-
riam ser requisições. Com base nas interações do usuário e no resultado das ações
é responsabilidade do Controller apresentar a View correta.
A figura 2.8 apresenta visualmente o papel das partes e seus relacionamentos.
Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma das
partes que compõem o padrão MVC (MICROSYSTEMS, 2008).
O protótipo da aplicação utilizará como base este padrão de arquitetura para a mode-
lagem do sistema.

45. 44
2.7 Síntese do capítulo
Neste capítulo foram abordados os conceitos necessários para o desenvolvimento do
protótipo. Primeiro, foi apresentado que streaming e live streaming são conceitos de
transmissão de dados. Então, foi apresentado os fatores que influenciam nas transmissões
live streaming (atraso, jitter, perda de pacotes e largura de banda), e constatado que as
transmissões em tempo real possuem limiares que não podem ser ultrapassados para não
terem perdas perceptíveis em sua qualidade: 150 ms para atraso unidirecional, 30 ms para
jitter, 5 % para perda de pacotes e largura de banda para comportar as informações da
transmissão que trafegam no enlace. Na próxima seção, foi abordado o protocolo SIP,
seu funcionamento, as mensagens importantes no estabelecimento da sessão relevantes
para este trabalho (SIP INVITE e SIP BYE) e as funções dos dispositivos SIP numa rede.
Em seguida, foi apresentado os protocolos de transporte RTP e RTCP, que realizam a
transmissão e seu controle. Com relação ao protocolo RTCP, destaca-se a mensagem
sender report que consta o campo fraction lost, utilizado para se obter a perda de pacotes.
Na seção seguinte, foi apresentado o protocolo ICMP que foi utilizado para se descobrir
o atraso de ida e volta. Por fim, foi abordado o padrão de arquitetura MVC, que permitiu
isolar a lógica da visualização, permitindo um baixo acoplamento no desenvolvimento.
No próximo capítulo será abordada a metodologia que foi seguida para a conclusão
deste trabalho.

46. 45
3 METODOLOGIA DE DESENVOLVIMENTO
Neste capítulo são abordadas as etapas necessárias para o desenvolvimento do pro-
tótipo. A metodologia deste trabalho foi constituída em 5 (cinco) etapas: ambiente de de-
senvolvimento, requisitos, técnicas, modelagem e implementação. Foi organizada desta
maneira, pois permite isolar cada um dos passos metodológicos por áreas de criação.
Na primeira seção é descrito o ambiente no qual foi utilizado em todo decorrer da
metodologia. Em seguida, alinhado aos objetivos e a idealização do protótipo são de-
scritos os requisitos. Na próxima seção, são propostas as técnicas de obtenção das métri-
cas de desempenho de QoS. Então, é feita a modelagem do protótipo com base no padrão
MVC. Por fim, com base nos pacotes e classes criados na modelagem, o protótipo é im-
plementado e codificado.
3.1 Ambiente de Desenvolvimento
Para suportar todas as etapas da metodologia, foi necessário estabelecer um ambiente
de desenvolvimento. Nesta seção é descrito as partes que compõem este ambiente: as
ferramentas para desenvolvimento e os dispositivos físicos numa rede.
3.1.1 Ferramentas
A utilização do padrão de arquitetura MVC na concepção do protótipo, e a utilização
1
da linguagem de programação Java permitiu o uso de ferramentas para programação
1
O Java é uma inguagem de programação orientada à objetos criada pela Sun Microsystems. Mais
informações: http://java.sun.com/. Acesso em 26/11/2009.

47. 46
orientada à objetos. Por meio de duas ferramentas foi possível desenvolver a parte lógica
e a parte gráfica do protótipo. A lógica do protótipo foi criada com a ferramenta Eclipse
2
, enquanto que a parte gráfica foi concebida com a NetBeans 3 .
A utilização da ferramenta NetBeans facilitou na criação das interfaces gráficas, pois
é possível conceber a interface visualmente. Após sua criação, o código fonte gerado
era copiado para a ferramenta Eclipse permitindo a integração com a lógica do protótipo.
Esse desenvolvimento segmentado foi possível pela utilização do padrão MVC, isolando
a parte lógica da gráfica.
Além das ferramentas Eclipse e NetBeans, foram utilizadas duas bibliotecas de pro-
4
gramação para Java: JpCap e JFreeChart 5 . A JpCap é uma biblioteca que permite a
captura e o envio de quadros e pacotes de rede, enquanto que a JFreeChart, é uma bib-
lioteca, que permite a criação, geração e atualização de diferentes tipos de gráfico em
tempo real.
3.1.2 Dispositivos
Para se desenvolver o protótipo, além das ferramentas, foram utilizados dispositi-
vos de rede. O propósito destes dispositivos foi simular a execução de uma aplicação
live streaming. Uma aplicação VoIP foi escolhida em função de sua crescente utilização
por parte de usuários domésticos e corporativos. Além disso, a existência de farta doc-
umentação e aplicativos VoIP gratuitos também contribuiu para a escolha desse tipo de
aplicação (transporte de voz digital).
Neste ambiente foram utilizados 03 (três) hosts físicos interconectados por um switch.
Foram utilizadas duas estações de trabalho, que executaram softphones, um servidor que
2
O Eclipse além de uma ferramenta é toda uma comunidade que visa a criação de plataformas de código-
aberto para todo ciclo de vida do software. Ela esta disponível em http://www.eclipse.org. Acesso em
26/11/2009.
3
Criada pela Sun MicroSystems, o NetBeans é uma plataforma para desenvolvimento em Java que pos-
sui bastante funcionalidade para criação de aplicações gráficas. Disponível em: http://www.netbeans.org.
Acesso em 26/11/2009.
4
A biblioteca JpCap, para captura e envio de pacotes, é disponibilizada gratuitamente em:
http://netresearch.ics.uci.edu/kfujii/ jpcap/doc/index.html. Acesso em 23/10/2009.
5
A biblioteca JFreeChart, para criação de gráficos, pode ser obtida gratuitamente em:
http://www.jfree.org/jfreechart/. Acesso em 23/10/2009.

48. 47
executou o gateway server Asterisk e um switch. A topologia de redes utilizada é apre-
sentada na figura 3.1.
Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de pré-
teste.
Na figura 3.1, é possível verificar que cada máquina recebeu um identificador numérico.
Orientado por estes identificadores, nas próximas seções é apresentado as especificações
de hardware e software de cada uma das máquinas.
3.1.2.1 Máquina 1
Esta máquina atuou como uma estação de trabalho comum, atendendo às ligações
feitas pela máquina 3. Nela foi instalado um softphone convencional que permitisse,
unicamente, receber chamadas VoIP.
1. Especificações de hardware:
(a) Processador: Intel Pentium 4 HT, 3.0 Ghz;
(b) Memória RAM: 512 MB;
(c) Armazenamento: 160 Gb;
(d) Rede: Ethernet 100 Mbps.
2. Especificações de software:
(a) Sistema Operacional: Windows XP SP2 32 bits;
(b) Softphone instalado: SJPhone 1.60 6 .
6
A aplicação SJPhone possui uma versão grátis para Windows, disponível no endereço:
http://www.sjlabs.com/sjp.html. Acesso em 08/10/2009.

49. 48
3.1.2.2 Máquina 2
Esta máquina foi responsável por executar o gateway server para as ligações VoIP,
por meio da aplicação Asterisk. Este dispositivo fez a sinalização via protocolo SIP para
as outras duas estações. Foi utilizado uma solução que instala um servidor PBX-IP com-
pleto, simplificando a tarefa de instalação e configuração.
1. Especificações de hardware:
(a) Processador: Intel Pentium 3, 1.1 Ghz;
(b) Memória RAM: 512 MB;
(c) Armazenamento: 20 Gb;
(d) Rede: Ethernet 100 Mbps.
2. Especificações de software:
(a) Sistema Operacional: CentOS 5.3 Final 32 bits;
(b) Aplicação instalada: Solução TrixBox 2.6.18 que roda Asterisk 1.4.17.
3.1.2.3 Máquina 3
Essa máquina foi responsável por originar as ligações VoIP para a máquina 1. Além
disso, ela foi utilizada para coletar os pacotes transmitidos através do uso de uma fer-
ramenta específica para esse fim. A fim de tornar possível essa operação, a interface
Ethernet dessa máquina teve que ser colocada em modo promíscuo 7 .
1. Especificações de hardware:
(a) Processador: Intel Core 2 Duo, 1.8 Ghz;
(b) Memória RAM: 2 GB;
(c) Armazenamento: 100 Gb;
7
O modo promíscuo é um tipo de configuração de recepção na qual todos os pacotes que trafeguem pelo
segmente de rede que a estação está conectada são capturados. Em funcionamento normal, ela receberia
apenas os pacotes endereçados a ela, mas em ambiente onde são utilizados repetidores e hubs é possível
utilizar o modo promíscuo para capturar dados (KUROSE; ROSS, 2006)

50. 49
(d) Rede: Ethernet 100 Mbps.
2. Especificações de software:
(a) Sistema Operacional: Windows Vista Ultimate 32 bits;
(b) Softphone instalado: SJPhone 1.60.
(c) Ferramenta de captura e análise de dados instalada: WireShark 1.2.2 8 .
3.2 Requisitos
Para conceber o protótipo, foi necessário mapear as funcionalidades que deveriam
estar presentes. Tanto as funcionalidades funcionais quanto as não-funcionais deveriam
ser pontuadas, não deixando nada em aberto, ou implícito. Após a seção da proposta de
técnicas para medição das métricas de desempenho, é feita uma análise dos requisitos,
modelando-os de forma a constituir o protótipo.
Os requisitos foram mapeados por meio dos objetivos do trabalho. Foram acompan-
hados de identificadores permitindo o apontamento à eles nas futuras seções do trabalho.
Eles são apresentados a seguir.
1. REQ01: Permitir a escolha de uma interface de rede a ser monitorada.
2. REQ02: Detectar automaticamente o início e o fim do tráfego live streaming RTP.
3. REQ03: Suportar pelo menos o protocolo de sinalização SIP.
4. REQ04: Monitorar os fatores que afetam as transmissões live streaming: largura
de banda, atraso, perda de pacotes e jitter.
5. REQ05: Monitorar cada stream em uma tela.
6. REQ06: Monitorar em tempo real o tráfego.
7. REQ07: Apresentar os dados monitorados por meio de gráficos.
8. REQ08: Persistir os dados em disco em forma de log.
8
A ferramenta WireShark é livre, e ela pode ser obtida no endereço: http://www.wireshark.org/. Acesso
em 20/10/2009.

51. 50
9. REQ09: A topologia da rede não deve ser alterada para que funcione a ferramenta.
3.3 Técnicas
Para se desenvolver técnicas de medição para as métricas de desempenho de QoS,
foi necessário: (1) realizar uma captura de pacotes no ambiente de desenvolvimento, (2)
analisar os dados capturados identificando certos eventos ou atributos e (3) propor as
técnicas. A simulação feita, para que fosse capturado os pacotes necessários, foi proposta
da seguinte maneira.
1. Foi iniciada a ferramenta de captura de pacotes;
2. Foi feita uma tentativa de ligação VoIP partindo do dispositivo 3 para o 1;
3. O dispositivo 2 fez o intermédio desta tentativa, por meio da aplicação Asterisk.
Nesta etapa o softphone do dispositivo 1 começa a tocar;
4. No momento em que o dispositivo 1 atendeu a ligação, foi enviada uma mensagem
SIP para que uma sessão fosse estabelecida;
5. A transmissão live streaming RTP foi iniciada;
6. Foram capturados pacotes SIP, RTP, RTCP ao longo de 30 segundos, por meio da
ferramenta WireShark;
7. Após 30 segundos, o dispositivo 3 finalizou a comunicação. Consequentemente, o
dispositivo 3 enviou uma mensagem SIP que corresponde ao término da sessão;
8. O dispositivo 1 ao receber mensagem, enviou um acknowledge e a transmissão
finalizou;
9. A ferramenta WireShark foi parada;
10. Os dados gerados por esta ferramenta foram analisados.
Nestes 30 segundos capturados, a ferramenta capturou mais de 3.000 (três mil) pa-
cotes. Seria inviável analisar um a um, portanto foi buscado analisar pacotes que possuam

52. 51
algum atributo específico, ou tenham relação com algum evento de rede. Esta análise bus-
cou pacotes que fossem relevantes para a criação das técnicas de medição e para a lógica
do protótipo. Cada um dos eventos e atributos buscado analisar são apresentados a seguir.
1. Protocolo SIP: Por meio deste protocolo, foi possível obter dados relacionados à
sessão estabelecida entre as partes da transmissão. Foram buscadas as mensagens e
parâmetros que contivessem o início, término e identificação das sessões.
(a) Início da transmissão: Quando um pacote com o tipo de mensagem INVITE
era enviado, verificou-se o fluxo de informações que precede o início de uma
transmissão live streaming. A mensagem que identifica o início da transmis-
são, além de ser do tipo SIP INVITE, possui ainda dados do protocolo SDP,
que identifica o início de uma sessão. Esta mensagem identifica o início da
sessão, possibilitando a obtenção de dados de porta em que é iniciada a trans-
missão live streaming, via protocolo RTP; e do identificador da sessão.
(b) Identificação de sessões: No item anterior, foi mencionada a mensagem na
qual deve ser monitorada, de modo a obter o identificador da sessão. Toda
sessão possui um identificador único gerado com base num identificador randômico
de criptografia (ROSENBERG et al., 2002). Este campo é o mesmo em todos
os pacotes de manutenção de uma sessão SIP. O nome deste campo no pacote
SIP é Call-ID.
(c) Fim da transmissão: Da mesma forma que o protótipo precisa saber o início
e o identificador da sessão, também é necessário descobrir quando uma trans-
missão é finalizada. Desta forma, o tipo de mensagem SIP BYE foi analisado.
2. Protocolo RTCP: Este protocolo apresenta dados de controle da transmissão, porém
foi analisado apenas um relatório contido nesta mensagem, o sender report. O
campo analisado foi o da taxa de perdas de pacotes.
(a) Taxa de perdas de pacotes: Valor que expressa a taxa na qual pacotes estão
sendo perdidos na rede. Este valor é expresso em porcentagem, mas não como
base 100, e sim base 256. Para obtenção, foi analisado o campo fraction loss.
3. Protocolo RTP: O protocolo RTP realiza o transporte dos dados da transmissão

53. 52
live streaming. Portanto, o único dado que foi monitorado é o tamanho dos pacotes
da transmissão.
(a) Tamanho de cada pacote para contabilização: Como no pacote RTP trafegam
dados de transmissão, a única análise feita neste protocolo foi da quantidade
de banda que cada fluxo em tempo real está ocupando do enlace em termos
bytes/segundo. As transmissões são isoladas umas das outras, pois são multi-
plexadas em portas UDP distintas.
Na seção 2.2, foram analisados os quatro fatores que influenciam as transmissões
em tempo real (largura de banda disponível, perda de pacotes, atraso, e buffer de com-
pensação de jitter). Como um dos objetivos deste trabalho é medir os atributos de de-
sempenho de uma transmissão em tempo real, com base nas variáveis identificadas nos
itens anterior, foram propostas técnicas para que sejam coletadas métricas de desempenho
de QoS. No contexto deste trabalho, cada um destes fatores recebeu, respectivamente, o
nome: tráfego RTP, perda de pacotes, atraso e jitter.
O método utilizado para a medição de cada uma das métricas de desempenho é apre-
sentado apresentado nas seções seguintes.
3.3.1 Tráfego RTP
O objetivo da monitoração do tráfego RTP foi obter a largura de banda utilizada pela
transmissão live streaming RTP por segundo. Para isso, foram contabilizados os pacotes
RTP e RTCP. A unidade desta medida é bytes/segundo. A técnica proposta é apresentado
a seguir.
1. Captura pacote da rede.
2. Verifica se o pacote é RTP ou RTCP.
3. Se sim, identifica qual transmissão está trafegando o pacote. Isto é feito identifi-
cando a porta UDP. Quando é trafegado o pacote SIP INVITE, é obtida a porta na
qual é trafegada a transmissão, conforme seção 2.3.
4. Obtém o tamanho do pacote.

54. 53
5. Incrementa e/ou armazena o valor do tamanho do pacote. Apenas é armazenado o
valor na primeira execução. Nas execuções subsequentes, é incrementado o valor
da execução anterior com o valor atual.
6. Quando for o instante de tempo de obtenção da medida, aplica o seguinte algoritmo:
(a) Atribui: ContagemNova = ContadorDePacotes;
(b) Atribui: Resultado = (ContagemNova - ContagemAntiga) / tempoDeAtualiza-
ção;
(c) Atribui: ContagemAntiga = ContagemNova.
7. Conclui a operação.
Por meio deste algoritmo, a largura de banda utilizada por segundo por uma transmis-
são live streaming é obtida na variável Resultado. Além disso, este algoritmo é indepen-
dente do tempo de obtenção dos dados para serem apresentados (tempoDeAtualização),
portanto ao alterar o tempo de amostragem dos gráficos não será alterado o fluxo de exe-
cução nem os valores obtidos por esta técnica.
3.3.2 Perda de Pacotes
Ao monitorar a perda de pacotes, busca-se obter a taxa na qual os pacotes não con-
seguem chegar ao seu destino, relativa ao número total de pacotes passados pela interface.
Como esta é uma unidade relativa, ela é medida em porcentagem. Foi monitorada a perda
de pacotes apenas nas transmissões live streaming RTP, e não em todo enlace. Este valor
foi obtido ao monitorar os pacotes RTCP e verificar o campo fraction lost. Como este
campo é composto de 1 byte, pode possuir 256 valores. Portanto, foi realizado uma con-
versão para apresentar este valor como múltiplo de 100. O algoritmo que obtém a taxa de
perda de pacotes é apresentado a seguir.
1. Captura pacote da rede.
2. Verifica se o pacote é RTCP.
3. Se sim, busca pelo byte 32 que contém o dado de perdas de pacotes e o atribui à
variável PktLoss.

55. 54
4. Aplica a equação 3.1, convertendo o dado para base 100.
100
P erdaDeP acotes = (3.1)
256 ∗ P ktLoss
5. Conclui a operação.
A variável PerdaDePacotes apresenta o valor da perda de pacotes em porcentagem.
3.3.3 Atraso
Para se calcular o atraso na entrega, foi necessário utilizar o protocolo ICMP. Este
método envia uma requisição e contabiliza o tempo desde que ela sai do emissor até o
recebimento de um retorno do receptor. O atraso obtido por meio desta técnica é o de ida
e volta, ou round trip time. A unidade do atraso é milissegundos.
1. Inicia a contabilização de tempo.
2. Envia um pacote ICMP com tipo de mensagem 8 e código 0, a requisição de eco.
O receptor deve responder com um pacote ICMP contendo um tipo de mensagem e
código, ambos 0, indicando uma resposta de eco.
3. Para a contabilização de tempo.
4. Calcula a diferença entre o início da contabilização de tempo e o término. Esta
diferença é o tempo em milissegundos que um pacote ICMP levou para ir e voltar do
dispositivo emissor até o receptor. Este resultado é atribuído à variável PingResult.
5. Aplica o seguinte algoritmo:
(a) Atribui: IcmpAntigo = PingResultAntigo.
(b) Atribui: PingResultAntigo = PingResult.
(c) Atribui: ResultadoFinal = (PingResultAntigo + ResultadoFinal) / 2
6. Conclui a operação.

56. 55
Este algoritmo utiliza uma variável a mais, que não seria necessária para este algo-
ritmo, porém ela é utilizada para o cálculo do jitter. A variável é IcmpAntigo. Além disso,
como este algoritmo foi executado com maior frequência do que a taxa de amostragem
dos dados nos gráficos, para se obter o atraso médio e não perder a exatidão na medição
foi feita uma média da medição anterior com a atual, o que explica a divisão por 2 (dois)
no algoritmo.
3.3.4 Jitter
O valor do buffer de compensação de jitter foi obtido por amostragem. Para o cálculo
desta métrica de desempenho, foram obtidas 30 amostras. A variação no atraso entre elas,
o delta, foi calculado e incrementado. Após as 30 amostras terem sido obtidas, foi feito
uma média destes deltas, obtendo o valor de jitter. As amostras utilizadas são as mesmas
utilizadas na seção 3.3.3, para o cálculo do atraso na entrega. A unidade desta medição é
em milissegundos.
O algoritmo completo é apresentado a seguir.
1. Obtém amostra;
2. Incrementa o contador no número de amostras;
3. Verifica a contagem das amostras. Se for equivalente a 30, segue fluxo 3a do algo-
ritmo. Caso contrário, segue fluxo 3b.
(a) NúmeroDeAmostras = 30;
i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |;
ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta;
iii. Atribui: Jitter = SomaDeDeltas / NúmeroDeAmostras;
iv. Atribui: NumeroDeAmostras = 0;
v. Atribui: SomaDeDeltas = 0;
vi. Atribui: PingResultAntigo = 0;
(b) NúmeroDeAmostras != 30;
i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |;

57. 56
ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta;
iii. Atribui: Incrementa em 1 unidade NumeroDeAmostras;
4. Conclui a operação.
A variável Delta possui a diferença entre o RTT dos pacotes ICMP. Mas é na variável
Jitter, que é apresentado o resultado do tamanho do buffer de compensação de jitter.
3.4 Modelagem
Esta etapa teve como objetivo produzir um modelo de classes que, somado às técnicas
produzidas na seção anterior, foi possível realizar a codificação do protótipo na etapa
seguinte. Neste trabalho foi modelado e desenvolvido o protótipo seguindo somente o
padrão MVC, agilizando todo processo da concepção do protótipo. Como o foco deste
trabalho não foi a engenharia de software, e sim a implementação das técnicas propostas
medindo os atributos de desempenho de QoS numa rede, a modelagem foi simplificada.
Para ver mais sobre modelagem e engenharia de software, consultar Larman (2007).
Por utilizar o padrão de arquitetura MVC, a modelagem teve agilidade, facilidade e
modularidade. Também por utilizar este padrão, a modelagem foi orientada à objetos, uti-
lizando classes. Estas classes possuem lógicas associadas às funcionalidades do protótipo.
As classes, suas associações e interconexões resultaram no protótipo.
Ao analisar os requisitos, as técnicas criadas para obtenção de métricas de desem-
penho, e as bibliotecas utilizadas para a linguagem de programação Java, verificou-se a
necessidade de englobar os requisitos em agrupamentos de funcionalidades. Os agrupa-
mentos e os requisitos atendidos por cada um deles são apresentados a seguir - foram
adicionados identificadores para referenciar os agrupamentos ao longo do trabalho.
1. AF01 - Captura de Pacotes RTP/RTCP e SIP: Neste agrupamento foram incluí-
dos todos os protocolos nos quais são capturados pacotes. Como os protocolos RTP
e RTCP foram utilizados por duas das técnicas de medição, optou-se por isolá-los
como um agrupamento de funcionalidade. Além disso, foi necessário capturar da-
dos do protocolo SIP, portanto ele também está incluído neste agrupamento. Os
requisitos englobados por este agrupamento são: