O documento apresenta uma proposta de ferramenta de monitoramento de desempenho em tempo real para aplicações de streaming ao vivo utilizando o protocolo RTP. A monografia explora os fatores que afetam a transmissão, metodologia de desenvolvimento e os resultados experimentais alcançados. Este trabalho visa contribuir para a melhoria da qualidade dos serviços de streaming ao vivo.

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:

58. 57
(a) Parte do REQ01: A biblioteca de captura de pacotes permite a captura em
apenas uma interface. Desta forma, contribui para atingir este requisito.
(b) REQ02: O tráfego live streaming é detectado automaticamente por meio do
protocolo SIP.
(c) REQ03: O protocolo SIP é suportado.
(d) Parte do REQ04: Por meio dos protocolos RTP e RTCP é possível obter dois
dos dados que são monitorados: tráfego RTP e perda de pacotes.
(e) Parte do REQ06: Como a captura e o cálculo devem ser em tempo real para
serem apresentados no gráfico, parte deste requisito é atendido com este agru-
pamento.
2. AF02 - Monitoramento ICMP: O protocolo ICMP é utilizado pelas outras duas
técnicas de medição das métricas de desempenho de QoS, portanto foi dedicado
um agrupamento de funcionalidade para este protocolo. Os requisitos atendidos
por este agrupamento são:
(a) Parte do REQ01: Como o monitoramento ICMP é feito num endereço IP
da interface escolhida, este agrupamento contribui para o atendimento deste
requisito.
(b) Parte do REQ04: Com este agrupamento, é possível medir o tamanho do
buffer de compensação de jitter e o atraso no enlace. Somando as funcional-
idades obtidas com o agrupamento AF02, este requisito é atendido por com-
pleto.
(c) Parte do REQ06: Os dados são monitorados em tempo real, tanto a captura
quanto o cálculo.
3. AF03 - Gráficos: Este agrupamento agrupa a parte do protótipo responsável por
exibir as informações de maneira visual. Ele engloba toda a parte de criação,
manutenção e atualização dos gráficos. Também, neste agrupamento está contida a
biblioteca para manipulação de gráficos. Os requisitos atendidos são apresentados
a seguir.
(a) REQ05: São criadas novas telas com gráficos conforme novas transmissões
live streaming forem iniciadas.

59. 58
(b) Parte do REQ06: Os outros agrupamentos englobavam a parte lógica do mon-
itoramento em tempo real. Com este agrupamento, a parte visual é atendida,
concluindo este requisito.
(c) Parte do REQ07: Este agrupamento engloba a geração, manutenção e atual-
ização dos gráficos, faltando apenas a parte de exibição.
4. AF04 - Interface Gráfica: Foi verificado que existe a necessidade de apenas duas
telas: a de escolha de interface e a de exibição dos gráficos. Neste agrupamento
estão contidas as interfaces gráficas do protótipo. Os requisitos atendidos são apre-
sentados a seguir.
(a) Parte do REQ01: Por meio deste agrupamento, e dos agrupamentos de AF01
e AF02, este requisito é atendido.
(b) Parte do REQ07: Como este agrupamento engloba a exibição dos gráficos, em
conjunto do agrupamento de gráficos, este requisito é atendido.
5. AF05 - Persistência: Além de monitorar e exibir as métricas que afetam as trans-
missões live streaming, o protótipo deve realizar a persistência em disco, possibil-
itando a futura análise e/ou geração de gráficos offline. Este agrupamento atende
apenas a um requisito, de modo que foi criado unicamente com este objetivo. O
requisito atendido é o REQ08.
O REQ09 foi o único que ficou fora desta lista, pois não se trata de um requisito
funcional do protótipo, e sim não-funcional. A necessidade do protótipo executar sem
alterar a topologia de rede, foi um requisito que não poderia ser implementado, e sim
planejado. Como este requisito foi uma premissa, foi necessário planejar a arquitetura
sempre verificando se esta premissa estava sendo atendida.
Cada um dos agrupamentos de funcionalidades foi analisado, buscando primeiro re-
duzir o nível de abstração para o de pacotes, para então chegar nas classes de progra-
mação. Como foi seguido o padrão de arquitetura MVC, foi buscado o isolamento do
modelo, da visualização e do controlador. Foi possível verificar que AF01 - Captura de
Pacotes RTP/RTCP e SIP, e AF02 - Monitoramento ICMP foram responsáveis por aten-
der os requisitos cruciais do protótipo. Nestes agrupamentos está contido o núcleo do

60. 59
protótipo, a lógica. Destes dois agrupamentos foi criado o pacote Model. Por outro lado,
os agrupamentos AF03 - Gráficos e AF04 - Interface Gráfica são responsáveis pelos req-
uisitos responsáveis pela parte visual e gráfica. Seguindo as diretivas do MVC, estes dois
agrupamentos foram unidos no pacote View. O agrupamento final, AF05 - Persistência,
não possui um tipo definido no padrão MVC, então foi criado um pacote a parte, chamado
Extra. Na figura 3.2 é possível visualizar a organização de pacotes proposta.
Figura 3.2: Diagrama da organização de pacotes por agrupamento de funcional-
idades.
Como foi buscado a redução no nível de abstração para o de classes de programação,
foram utilizados os pacotes definidos no parágrafo anterior como ponto de partida para
a elaboração do modelo de classes de projeto. O protótipo deve fazer a coleta de dados
do ambiente, processar e atualizar os valores no gráfico. As tarefas de coleta e processa-
mento foram unidas num único componente lógico, a Thread, enquanto que a tarefa de
atualizar o gráfico foi de responsabilidade de outro componente, o Querier. No pacote
Model, foram compreendidos dois pares Thread e Querier, um para o agrupamento AF01
- Captura de Pacotes RTP/RTCP e SIP e outro para o AF02 - Monitoramento ICMP.
No pacote View, a redução no nível de abstração segmentou o agrupamento AF04 -
Interface Gráfica em duas classes. A classe GuiInicial se tornou responsável pela exibição
da tela inicial da aplicação, na qual é feita a escolha da interface a ser monitorada. A
outra classe, GuiSmb, iniciou e terminou ao passo que as transmissões live streaming
RTP iniciaram e terminaram. O agrupamento AF03 - Gráficos se transformou em apenas

61. 60
uma classe, Gráfico.
O pacote Extra, continha apenas um agrupamento de funcionalidades, AF05 - Per-
sistência. Este agrupamento já é o de menor nível de abstração, portanto, se tornou uma
classe de mesmo nome.
A classe Controller realiza a intercomunicação entre todas as partes. Na figura 3.3 é
possível verificar o novo diagrama com um nível menor de abstração, agora apresentando
o modelo de classes do projeto.
Figura 3.3: Diagrama do modelo de classes do projeto.
Com base neste modelo é que foi feita a implementação de cada uma das funcionali-
dades, por meio das classes. A implementação é apresentada na seção seguinte.
3.5 Implementação
Nesta seção é descrito desenvolvimento do diagrama de classes de projeto e a im-
plementação do protótipo, que funcionará em três etapas: (1) identificação automática de
tráfego RTP para verificação dos dados, (2) processamento e (3) apresentação visual da
informação resultante na tela, isso tudo em tempo real. Foi com base nestas três etapas

62. 61
que foi estruturado o fluxo lógico do protótipo. Como o modelo desenvolvido na fase an-
terior englobava apenas as macro-partes do protótipo, e não previa os métodos e atributos
das classes, esta fase buscou, além de implementar o protótipo, desenvolver um modelo
de classes de projeto completo.
Para apresentar e estruturar a implementação, foi dedicada uma seção para cada um
dos pacotes criados. Dentro de cada uma das seções que descrevem os pacotes, foi ap-
resentado cada uma das classes, métodos principais e interações entre si, constituindo o
protótipo. Os pacotes que o compõem são: Model, View, Controller e Extra.
Na figura 3.4, é possível verificar o diagrama de classes completo produzido. Cada
uma de suas partes é descrita nas seções a seguir.
Figura 3.4: Diagrama de classes completo do protótipo.
3.5.1 Lógica - Model
Este pacote engloba a parte lógica do protótipo, ou o Model do padrão MVC. O pacote
Model é responsável por fazer a captura de pacotes RTP/RTCP e SIP e, também de realizar
o monitoramento ICMP. A captura de pacotes e o monitoramento foram utilizados para

63. 62
obter a medição dos seguintes itens: tráfego RTP, perda de pacotes, atraso na entrega dos
pacotes e tamanho do buffer de compensação de jitter. Todos estes itens foram obtidos
em tempo real, mas apresentados no gráfico com uma taxa de amostragem de 5 segundos,
com exceção do jitter, que é apresentado no mínimo a cada 60 segundos (mais detalhes
ver seção 3.3.4).
Na seção 3.2, foram descritos os componentes Thread e Querier, responsáveis por,
respectivamente, coletar e calcular dados, e atualizar o gráfico. Nos próximos itens, serão
descritas as responsabilidades de cada uma das classes, e apresentado seu diagrama de
classe respectivo. As classes responsáveis pela parte lógica são: ThreadPcap, QuerierP-
cap, ThreadICMP e QuerierICMP.
1. Classe ThreadPcap:
Esta classe é responsável pela captura de pacotes na rede, por meio da biblioteca
JpCap. Como todo o tráfego de rede relevante ao trabalho utiliza o protocolo de
transporte UDP, por meio da biblioteca utilizada foi filtrado somente este tipo de
pacote. Logo, esta classe buscou capturar os pacotes contidos nos protocolos RTP,
RTCP e SIP. Além da captura de pacotes, possui métodos que realizam a medição
das métricas de desempenho para o tráfego RTP e a perda de pacotes. O método
getPktBytes aplica a técnica que mede calcula a largura de banda utilizada pela
transmissão live streaming analisada. Por outro lado, o método getPktLoss aplica a
técnica que mede a perda de pacotes que incide na transmissão em tempo real RTP.
A classe ThreadPcap utiliza o conceito de thread 9 , portanto executa em paralelo
com o fluxo principal de execução. Diferentemente das classes responsáveis pelo
monitoramento ICMP, em que são criadas n classes para n transmissões live stream-
ing RTP, as classes responsáveis pela captura de pacotes possuem 1 classe para n
transmissões. Isto ocorre, pois é possível criar apenas uma instância do objeto de
captura de pacotes. Para armazenar os dados da captura de cada uma das transmis-
sões, são utilizados vetores, como é possível ver na figura 3.5. Os dados armazena-
dos nestes vetores são lidos pela classe QuerierPcap, por meio dos métodos getPk-
9
Uma thread é uma porção de código que executa em paralelo, concorrente ao fluxo principal da apli-
cação. É utilizado para se dividir porções de processamento entre núcleos, num ambiente multiprocessado
(DEITEL, 2004.

64. 63
tBytes e getPktLoss, também apresentados na figura 3.5. Além disso, na figura 3.5,
também é possível observar os atributos utilizados pela classe e os métodos, que
em conjunto são responsáveis pela captura de pacotes RTP, RTCP e SIP e cálculo
do tráfego RTP e perda de pacotes.
Figura 3.5: Diagrama da classe ThreadPcap.
2. Classe QuerierPcap:
Esta classe é responsável por consultar os dados obtidos pela classe ThreadPcap e
atualizá-los no gráfico conforme o tempo de amostragem. Além disso, é respon-
sável por atualizar os arquivos de log por meio da classe Persistencia. Também
utiliza o conceito de thread, e diferentemente da classe ThreadPcap, são criadas n
classes para n transmissões RTP.
A classe QuerierPcap utiliza os métodos getPktBytes e getPktLoss da classe Thread-
Pcap para obter os valores a serem atualizados no objeto gerado pela classe Grafico,
do pacote View. Esta classe utiliza métodos da classe Grafico para poder atualizar
os valores obtidos pelos métodos da classe ThreadPcap.
Na figura 3.6, é apresentado o diagrama desta classe.
Figura 3.6: Diagrama da classe classquerierpcap.
3. Classe ThreadICMP:

65. 64
Esta classe é responsável pelo monitoramento de pacotes ICMP na rede, por meio
do método nativo do Java System.isReachable. Ao monitorar o protocolo ICMP,
esta classe tem como objetivo obter o tempo de ida e volta de um pacote na rede, e
estimar o valor do buffer de compensação de jitter. Este protocolo foi utilizado pela
facilidade e simplicidade, no entanto poderia ter sido utilizado o protocolo RTP. O
protocolo ICMP para esta medição foi utilizado não aumentar a complexidade no
desenvolvimento do protótipo.
Como o par de classes da parte de captura de pacotes, esta classe utiliza o conceito
de thread, mas são criadas n classes para n transmissões live streaming RTP. Os
métodos principais para obtenção do RTT e do jitter são: pingerer e jitterer. Porém,
a interação com a classe que atualiza o gráfico é por meio dos métodos getMillis e
getJitter, que retornam os valores calculados pelos métodos citados anteriormente.
Os métodos e atributos da classe podem ser vistos no diagrama, apresentado na
figura 3.7.
Figura 3.7: Diagrama da classe ThreadICMP.
4. Classe QuerierICMP: Esta classe é responsável por consultar os dados obtidos pela
classe ThreadICMP e atualizá-los no gráfico conforme o tempo de amostragem.
Além disso, é responsável por atualizar os arquivos de log por meio da classe Per-
sistencia. Também utiliza o conceito de thread, e como a classe ThreadICMP, são
criadas n classes para n transmissões RTP.
A classe QuerierICMP utiliza os métodos getMillis e getJitter da classe Thread-
ICMP para obter os valores a ser atualizado no objeto gerado pela classe Grafico,

66. 65
do pacote View. Esta classe utiliza os métodos da classe Grafico para poder atualizar
no gráfico os valores obtidos pelos métodos da classe ThreadICMP.
Na figura 3.8, é apresentado o diagrama desta classe.
Figura 3.8: Diagrama da classe QuerierICMP.
O diagrama de classes completo do pacote Model é apresentado na figura 3.9.
Figura 3.9: Diagrama de classes completo do pacote Model.
3.5.2 Interface gráfica - View
Este pacote engloba a parte gráfica, ou o View do padrão MVC. O pacote Interface
gráfica é responsável por intermediar as ações do usuário por meio de telas visuais. Tam-
bém, é responsável por exibir os gráficos gerados pela parte lógica.

67. 66
O protótipo compreende duas telas principais: a tela inicial e a tela dos gráficos. Na
tela inicial são exibidas as interfaces de rede disponíveis para se executar o protótipo.
Após a seleção, o protótipo aguarda pelo início de transmissões live streaming RTP.
Quando uma transmissão é iniciada, é exibida a segunda tela, a tela dos gráficos. Esta
tela é responsável por exibir graficamente cada um dos quatro parâmetros de desempenho
de QoS. Não é responsabilidade deste pacote atualizar os dados, apenas permitir pontos
de entrada para os dados possam ser adicionados.
As classes compreendidas neste pacotes são: GuiInicial, GuiSmB e Grafico. Elas são
detalhadas nos itens a seguir.
1. Classe GuiInicial:
A classe GuiInicial é responsável por exibir a tela inicial. Nesta tela, é possível
escolher a interface de rede e iniciar a execução do protótipo. Esta classe foi criada
visualmente pela IDE (Integrated Development Environment) NetBeans, simplifi-
cando a codificação. Após o criação da interface gráfica, o código fonte foi copiado
para a outra ferramenta de desenvolvimento, Eclipse, e foi adicionado um método
para se obter o objeto que identifica a interface de rede selecionada, o método getJ-
Combo.
Na figura 3.10, é apresentado o diagrama da classe.
Figura 3.10: Diagrama da classe GuiInicial.
2. Classe GuiSmB:
Esta classe é responsável pela exibição da tela dos gráficos. Nesta tela, são exibidos
os gráficos gerados pela classe Grafico. Também criada pela IDE NetBeans de
forma visual, teve a mesma dinâmica de desenvolvimento que a classe GuiInicial.
Após sua criação, seu código fonte foi copiado para a ferramenta Eclipse. Nesta
ferramenta, foi incluído um método na classe que permite adicionar um número
identificador para cada transmissão monitorada, nomeado setStream.
Na figura 3.11, é possível visualizar o diagrama da classe.

68. 67
Figura 3.11: Diagrama da classe GuiSmB.
3. Classe Grafico:
Esta classe é responsável pela criação e atualização dos gráficos em tempo de ex-
ecução do protótipo. Isso é possível por meio da biblioteca JFreeChart permite a
exibição, geração e atualização dos gráficos criados. Esta classe possui métodos
para a criação de cada um dos tipos de gráficos necessários, e para a atualização de
cada uma das métricas de desempenho tempo real. As duas classes que se comu-
nicam com esta para atualizar os dados no gráfico são as classes do pacote Model:
QuerierPcap e QuerierICMP.
Na figura 3.12, é possível verificar os métodos por meio do diagrama da classe.
Figura 3.12: Diagrama da classe Grafico.
O diagrama de classes completo do pacote View é apresentado na figura 3.13.
3.5.3 Controlador - Controller
Este pacote engloba a única classe que realiza intercomunicação entre a parte lógica
e a parte gráfica. Também, é por meio do controlador que é definido o fluxo lógico de
execução do protótipo. Neste pacote está compreendida a classe Controller que além de
fornecer comunicação entre todas as partes do protótipo, é o ponto de execução inicial.
A classe Controller possui o controle da execução do protótipo. Também, possui
o controle de todas as transmissões live streaming em execução, permitindo identificar

69. 68
Figura 3.13: Diagrama de classes completo do pacote View.
quantas telas de gráficos devem ser executadas. Os identificadores das transmissões fi-
cam persistidos no vetor vecCallId, e quantidade de transmissões em execução em num-
Streams. Alem disso, a classe possui diversos vetores para controlar a quantidade de ob-
jetos criados a partir das classes: GuiSmB, Grafico, QuerierPcap, ThreadICMP, Querier-
ICMP. Por fim, esta classe possui métodos que agrupam a lógica necessária para quando
uma transmissão é iniciada ou terminada: newStream e byeStream.
A classe Controller, em seu pacote de mesmo nome, é apresentada na figura 3.14.
Figura 3.14: Diagrama de classes completo do pacote Controller.

70. 69
3.5.4 Extra
Como um dos requisitos do protótipo era a persistência dos dados, foi criado o pa-
cote Extra contendo apenas uma classe com esta funcionalidade. A classe Persistencia
é responsável por persistir em arquivo um histórico dos dados apresentados na execução
do protótipo. Esta classe armazena os valores de cada uma das métricas de desempenho
em arquivos texto separados. São criados quatro arquivos para cada transmissão live
streaming, identificados pelo número identificador da transmissão e o nome da métrica
de desempenho medida. As classes QuerierPcap e QuerierICMP são responsáveis por
alimentar este arquivo, conforme alimentam os gráficos. Os métodos utilizados por elas
são: logRtpData, logPktloss, logDelay e logJitter.
Na figura 3.15, é possível verificar o diagrama do pacote Extra, contendo a classe
Persistencia.
Figura 3.15: Diagrama de classes completo do pacote Extra.
3.6 Síntese do capítulo
Neste capítulo foi abordada a metodologia utilizada neste trabalho, que foi organi-
zada em cinco seções. Na primeira, foi abordado o ambiente de desenvolvimento que
engloba: as ferramentas de desenvolvimento para a parte gráfica (NetBeans) e parte lóg-
ica (Eclipse), as bibliotecas para captura de pacotes (Jpcap) e manutenção dos gráficos
(JFreeChart) e os três hosts, sendo que um executou a aplicação Asterisk, outro um soft-

71. 70
phone e o outro um softphone e a ferramenta de captura de pacotes (WireShark). Na
segunda seção, foram pontuados os requisitos do protótipo, que vão desde a medição em
tempo real dos fatores que afetam as transmissões live streaming, até a apresentação visual
das informações. Na terceira seção, foi detalhado cada uma das técnicas para medição das
métricas de desempenho de QoS. Para o tráfego RTP, foi utilizado a contabilização de pa-
cotes; para perda de pacotes, a valor no campo fraction lost do protocolo RTCP; para o
atraso, o protocolo ICMP; e para o jitter, uma técnica que fez amostragem via protocolo
ICMP, para então efetuar o cálculo. Na quarta seção, foi feita a modelagem do protótipo,
que aliada ao padrão MVC permitiu a criação de um diagrama de classes. Na quinta
seção, com base no diagrama de classes criado na seção anterior, foi possível otimizar
este diagrama e implementar o protótipo, descrevendo cada classe do trabalho.
No próximo capítulo serão descritos os passos realizados na fase de experimentação
da ferramenta, onde os requisitos desenvolvidos serão testados e avaliados em outro am-
biente.

72. 71
4 EXPERIMENTAÇÃO
Nas próximas seções são apresentados os aspectos de experimentação do protótipo, os
resultados obtidos, sua análise e discussão e um resumo do que foi apresentado. Primeira-
mente, é apresentado a topologia de rede na qual é feito experimento com o protótipo. Na
próxima seção, é descrito cada uma das etapas do experimento. Em seguida, são apre-
sentados os dados obtidos pelo experimento, no ambiente proposto. Então, é discutido
os resultados obtidos na seção anterior. Por fim, é feito um resumo de todos os aspectos
abordados neste capítulo.
4.1 Ambiente de Experimentação
O ambiente utilizado para a execução do experimento é semelhante ao descrito na
seção 3.1. A diferença é que este ambiente deve ser controlado, por isso a topologia é
constituida de máquinas virtuais. Foi possível simular este ambiente controlado por meio
da ferramenta VMWare Workstation 61 .
Para se executar as máquinas virtuais, foi necessário uma máquina hospedeira. A
configuração da máquina hospedeira utilizada é:
1. Processador: Intel Centrino Core 2 Duo 1.8 Ghz 32 bits;
2. Memória RAM: 2 Gb. Para cada máquina virtual foi alocado 300MB;
3. Armazenamento: 100 Gb;
1
A ferramenta VMWare é utilizada para se virtualizar equipamentos. Pode ser obtida, na versão Server,
no site do fabricante: http://www.vmware.com/. Acesso em 21/10/2009.

73. 72
4. Rede: Wi-fi 54 Mbps.
O ambiente de experimentação foi projetado com três dispositivos, sendo que dois
foram simulados na máquina hospedeira e o terceiro foi a própria máquina hospedeira
(neste trabalho, todos são chamados máquinas virtuais). Cada uma das três máquinas
virtuais compartilham os mesmos recursos de hardware. Com base na figura 4.1, que
apresenta a topologia de redes simulada por meio de máquinas virtuais, os dispositivos
virtuais são detalhadas nas seções a seguir em termos de responsabilidade nos testes,
sistema operacional (SO) e softwares instalados.
Figura 4.1: Topologia de redes simulada que foi utilizada no ambiente de testes.
4.1.1 Máquina Virtual 1
Esta máquina virtual foi responsável por atuar como uma estação de trabalho, e é
responsável por atender as ligações VoIP originadas pela máquina virtual 3. As especifi-
cações de SO software são apresentadas abaixo:
1. Sistema Operacional: Ubuntu Desktop Linux 32 bits, versão 9.0.4;
2. Softwares: Softphone Twinkle 1.4.1 2
4.1.2 Máquina Virtual 2
Esta máquina virtual teve como responsabilidade sinalizar as ligações VoIP por meio
do protocolo SIP entre as máquinas virtuais 1 e 3. As especificações de SO e software são
2
O softphone Twinkle está disponível para download no seguinte endereço:
http://www.twinklephone.com/. Acesso em 21/11/2009.

74. 73
apresentadas abaixo:
1. Sistema Operacional: CentOS 5.3 Final 32 bits;
2. Softwares: Solução TrixBox 2.6.18, que roda o gateway server Asterisk 1.4.17.
4.1.3 Máquina Virtual 3
Esta máquina virtual teve como responsabilidade efetuar as ligações VoIP para a
máquina virtual 1. Além disso, foi nesta máquina virtual que houve a execução para a
coleta de dados. As especificações de SO e software são apresentadas abaixo:
1. Sistema Operacional: Windows Vista Ultimate 32 bits;
2. Softwares: Softphone SJPhone 1.60 e o protótipo.
4.2 Experimento
O experimento consistiu na execução do protótipo demonstrando cada um dos itens e
telas desenvolvidas. Nesta seção, o protótipo foi executado no ambiente proposto na seção
anterior, sendo descrito metodologicamente todos os detalhes da execução com base nas
iterações feitas pelo usuário e/ou protótipo.
Para que o experimento realizasse a medição com sucesso e para que os dados re-
sultantes pudessem ser obtidos com precisão, foram definidas cinco execuções de dois
minutos cada. Todos os dados obtidos ao longo destes dois minutos são abordados na
seção (4.3).
A execução do experimento necessitou de uma interação de um usuário com o pro-
tótipo. Portanto, este é apresentado em termos de iterações do usuário e aplicação. Neste
experimento, pressupõe-se que existam usuários utilizando as máquinas virtuais 1 e 3.
Nos próximos itens, é apresentado e detalhado cada uma das etapas do experimento.
1. IT01: Inicia-se o protótipo.
Como foi desenvolvido em Java, e esta linguagem de programação possui uma IDE
de desenvolvimento, o protótipo foi iniciado pela própria ferramenta. Ao iniciar a

75. 74
execução, é exibida a interface gráfica inicial, conforme pode ser visto na figura 4.2.
Nesta tela, o usuário escolhe a interface de rede que são monitoradas as métricas de
desempenho de QoS.
Figura 4.2: Interface gráfica inicial do protótipo.
2. IT02: O usuário define a interface de rede a ser monitorada.
Nesta iteração, o usuário escolhe numa lista de interfaces de rede disponíves no
sistema, qual que deve ser monitorada pelo protótipo. Como o protótipo está sendo
executado na máquina hospedeira, é escolhida a interface que comunica com as
máquinas virtuais: VMware Virtual Ethernet Adapter (selecionada na figura 4.3).
Figura 4.3: Interfaces de rede disponíveis para execução do protótipo.
3. IT03: O usuário inicia a monitoração por meio do botão Iniciar.
Ao clicar no botão Iniciar, o protótipo fica em espera, aguardando por uma trans-
missão live streaming RTP. Enquanto não for iniciada uma transmissão RTP, o pro-
tótipo não avança para a próxima tela, a de exibição dos gráficos.
4. IT04: O usuário na máquina virtual 3 inicia uma ligação VoIP.

76. 75
Nesta iteração, por meio do softphone SJPhone, o usuário na máquina virtual 3
realiza uma ligação VoIP com destino à máquina virtual 1. A aplicação Asterisk,
em execução na máquina virtual 2, realiza a sinalização da chamada, e ao receber a
requisição de ligação faz tocar o softphone Twinkle localizado na máquina virtual
1.
5. IT05: O usuário na máquina virtual 1, aceita a ligação.
Ao verificar que seu softphone está tocando, o usuário na máquina virtual 1 atende
a chamada. Neste instante, é iniciada uma transmissão live streaming RTP.
6. IT06: É apresentado uma tela com os gráficos para cada transmissão em execução.
Ao detectar o estabelecimento de uma sessão SIP, e uma transmissão RTP iniciada,
o protótipo apresenta a tela com os gráficos e começa a atualizá-los em tempo real
a cada 5 segundos. Esta tela fica em execução até que seja terminada a sessão, e
consequentemente, a transmissão. Foi definido no início desta seção que cada trans-
missão deve totalizar dois minutos. Após o término desta primeira transmissão, são
executadas mais quatro, totalizando cinco transmissões de dois minutos cada.
Na figura 4.4, é exibida a tela que apresenta os gráficos de monitoramento de:
tráfego RTP, perda de pacotes, jitter e atraso.
7. IT07: Conforme as transmissões são finalizadas, as telas de gráficos respectivas são
encerradas.
Após os dois minutos estipulados, o usuário na máquina virtual 3 encerra a trans-
missão. Com esta ação, é finalizada a tela de gráficos. Os dados medidos ao longo
dos dois minutos são armazenados nos arquivos de log, disponível na pasta do pro-
tótipo. É repetida a execução do experimento desde a iteração IT04, até totalizar 5
iterações. Deste modo, é possível coletar um maior número de dados, permitindo
uma maior exatidão nos resultados.
4.3 Resultados
Nesta seção são apresentados os resultados obtidos após a execução do experimento.
Os dados oriundos do experimento foram obtidos por meio dos arquivos de log gerados

77. 76
Figura 4.4: Interface gráfica que representa a tela dos gráficos.
pelo protótipo. Cada execução do experimento gerou quatro arquivos de log por transmis-
são, um para cada métrica monitorada. Como foram feitas cinco execuções, no total foram
obtidos vinte arquivos de log. Todos os dados obtidos foram agrupados em tabelas para
poderem ser analisados e discutidos na seção posterior. Foram gerados quatro tabelas,
uma para cada um dos atributos da transmissão live streaming, exceto perda de pacotes,
e outra contendo as médias aritméticas das 5 execuções agrupando todas métricas moni-
torados. Nas tabelas, são apresentados os dados medidos a cada 5 segundos.
Na tabela 4.1, são apresentados os dados obtidos para o tráfego RTP em cada uma
das cinco execuções de dois minutos. Este tráfego corresponde à largura de banda que
a transmissão live streaming RTP está utilizando. A unidade na qual os valores estão
expressos é bytes/segundo.
Na tabela 4.2, é apresentado o valor do atraso RTT obtido ao longo das cinco exe-
cuções de dois minutos. Este valor corresponde ao tempo em que um pacote ICMP leva
para ir e voltar na rede, da origem até o destino. Os valores apresentados na tabela 4.2 são
expressos em milissegundos.

78. 77
Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5
5s 1626 0 0 0 0
10 s 10764 8410 3702 9736 9394
15 s 10806 10635 10764 10764 10678
20 s 10635 10806 10635 10678 10721
25 s 10785 10678 10678 10678 10721
30 s 10764 10678 10764 10678 10721
35 s 10721 10764 10678 10764 10678
40 s 10806 10721 10764 10721 10721
45 s 10721 10721 10721 10635 10721
50 s 10764 10764 9180 10764 10721
55 s 10699 10721 10678 10721 10764
60 s 10721 10678 10764 10764 10721
65 s 10721 10678 10635 10678 10678
70 s 10764 10678 10892 10721 10806
75 s 10806 10721 10678 10721 10635
80 s 10635 10721 10678 10678 10721
85 s 10764 10764 10764 10806 10678
90 s 10678 10635 10678 10635 10721
95 s 10721 10678 10764 10721 10721
100 s 10678 10806 10721 10721 10678
105 s 10764 10764 10678 10721 10806
110 s 10678 10678 10678 10678 10721
115 s 10721 10592 10721 10721 10678
120 s 10721 10806 10764 10764 10764
Tabela 4.1: Valores medidos para cada um das cinco execuções da aplicação
para o tráfego RTP.
Na tabela 4.3, é apresentado os valores medidos de jitter. O valor do jitter corre-
sponde à variação do atraso na entrega dos pacotes. Os valores são expressados em milis-
segundos.
Os dados obtidos para a perdas de pacotes foram todos nulos, portanto não foi gerado

79. 78
Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5
5s 0,00 0,00 0,00 0,00 0,00
10 s 1,55 1,55 1,53 1,50 1,51
15 s 1,78 1,89 1,90 1,88 1,90
20 s 1,94 1,95 1,95 1,94 1,95
25 s 2,00 1,99 2,00 1,98 2,00
30 s 2,01 2,01 2,01 2,00 2,02
35 s 2,01 2,00 2,01 2,00 2,02
40 s 2,01 2,00 2,02 2,00 2,01
45 s 2,01 2,01 2,02 2,01 2,01
50 s 2,02 2,01 2,00 2,01 2,01
55 s 2,01 2,00 2,02 2,01 2,01
60 s 2,01 2,00 2,01 2,00 2,01
65 s 2,02 2,00 2,01 2,00 2,02
70 s 2,01 2,01 2,02 2,00 2,01
75 s 2,02 2,00 2,01 2,00 2,02
80 s 2,02 2,01 2,01 2,00 2,01
85 s 2,02 2,00 2,00 2,00 2,02
90 s 2,02 2,00 2,00 2,00 2,01
95 s 2,01 2,00 2,00 2,00 2,01
100 s 2,02 2,03 2,00 2,00 2,02
105 s 2,01 2,01 2,00 2,00 2,01
110 s 2,02 2,01 2,00 2,00 2,02
115 s 2,02 2,01 2,00 2,00 2,01
120 s 2,02 2,01 2,00 2,00 2,01
Tabela 4.2: Valores medidos para cada um das cinco execuções da aplicação
para o atraso de ida e volta.
uma tabela para apresentar estes valores. Este valor corresponde à porcentagem na qual
pacotes foram perdidos ou descartados ao longo da transmissão live streaming.
Por fim, todos os dados foram agrupados numa mesma tabela contendo a média arit-
mética de cada valor com relação às cinco execuções. Este cálculo foi feito para poder ter

80. 79
Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5
5s 0,000 0,000 0,000 0,000 0,000
10 s 0,000 0,000 0,000 0,000 0,000
15 s 0,000 0,000 0,000 0,000 0,000
20 s 0,000 0,000 0,000 0,000 0,000
25 s 0,000 0,000 0,000 0,000 0,000
30 s 0,000 0,000 0,000 0,000 0,000
35 s 0,000 0,000 0,000 0,000 0,000
40 s 0,000 0,000 0,000 0,000 0,000
45 s 0,000 0,000 0,000 0,000 0,000
50 s 0,000 0,000 0,000 0,000 0,000
55 s 0,000 0,000 0,000 0,000 0,000
60 s 0,000 0,000 0,000 0,000 0,000
65 s 0,000 0,000 0,000 0,000 0,000
70 s 0,000 0,000 0,000 0,000 0,000
75 s 0,000 0,000 0,000 0,000 0,000
80 s 0,000 0,000 0,000 0,000 0,000
85 s 0,000 0,000 0,000 0,000 0,000
90 s 0,000 0,000 0,000 0,000 0,000
95 s 0,000 0,000 0,000 0,000 0,000
100 s 45,04 44,11 45,10 35,73 41,69
105 s 45,04 44,11 45,10 35,73 41,69
110 s 45,04 44,11 45,10 35,73 41,69
115 s 45,04 44,11 45,10 35,73 41,69
120 s 45,04 44,11 45,10 35,73 41,69
Tabela 4.3: Valores estimados para cada um das cinco execuções da aplicação
para tamanho do buffer de compensação de jitter.
uma precisão maior nos resultados obtidos pelo experimento. Estes dados são apresenta-
dos na tabela 4.4.

81. 80
Tráfego RTP (b/s) Atraso (ms) Jitter (ms) Perda de Pacotes (%)
5s 325 0,0 0,0 0
10 s 8401 1,5 0,0 0
15 s 10729 1,9 0,0 0
20 s 10695 1,9 0,0 0
25 s 10708 2,0 0,0 0
30 s 10721 2,0 0,0 0
35 s 10721 2,0 0,0 0
40 s 10747 2,0 0,0 0
45 s 10704 2,0 0,0 0
50 s 10439 2,0 0,0 0
55 s 10717 2,0 0,0 0
60 s 10730 2,0 0,0 0
65 s 10678 2,0 0,0 0
70 s 10772 2,0 0,0 0
75 s 10712 2,0 0,0 0
80 s 10687 2,0 0,0 0
85 s 10755 2,0 0,0 0
90 s 10669 2,0 0,0 0
95 s 10721 2,0 0,0 0
100 s 10721 2,0 42,3 0
105 s 10747 2,0 42,3 0
110 s 10687 2,0 42,3 0
115 s 10687 2,0 42,3 0
120 s 10764 2,0 42,3 0
Tabela 4.4: Média aritmética de todos atributos da transmissão live streaming ao
longo de cinco iterações.
4.4 Discussão
Nesta seção são discutidos e analisados os resultados obtidos pelo experimento. Por
meio deste, foi possível medir as quatro métricas de desempenho de QoS: largura de
banda, atraso, perda de pacotes e jitter. Com base nos valores medidos para estas métricas,

82. 81
é feita uma análise individual em cada uma delas nas próximas seções.
4.4.1 Tráfego RTP
O tráfego RTP consiste em medir a largura de banda utilizada por cada transmissão
live streaming. A quantidade de informações que trafega na interface selecionada foi me-
dida a cada cinco segundos. A unidade em que foi expressa esta medida é bytes/segundo.
Conforme a tabela 4.4, apresentada na seção anterior, foi possível verificar uma me-
dida constante no valor ao longo de toda a transmissão, exceto pelos instantes 5 s e 10
s. Isto ocorre, pois os softphones empregados no experimento não possuem nenhum al-
goritmo de detecção de silêncio, que poderia causar uma variação para menos no uso de
banda em alguns instantes de tempo.
O valor do tráfego RTP difere nos instantes 5 s e 10 s devido a maneira que é calculado
esta medida. Para se apresentar um valor numa base de tempo, é necessário utilizar uma
referência para este cálculo, neste caso, o valor medido no instante anterior. Na seção
3.3.1, foi apresentado o algoritmo que fazia este cálculo, mas este algoritmo é derivado
da fórmula apresentada em 4.1.
U soDeBanda(t1) − U soDeBanda(t0)
T raf egoRT P = (4.1)
tempoDeAtualizaoDoGraf ico
Como pode ser visto, ao utilizar a referência do instante anterior, no primeiro in-
stante de tempo em que é feito a medida, 5 s, não se tem um valor de referência anterior.
Portanto, a diferença entre o uso de banda será muito mais baixa do que nos instantes
seguintes. O mesmo se repete para 10 s. Após a obtenção destes dois valores menores, os
valores obtidos para o uso de banda são estabilizados em torno de 10700 bytes/segundo.
Numa primeira análise, não é possível verificar a exatidão do valor quantitativo desta
medida. No entanto, a probabilidade deste valor estar correto é alta, visto que analisando
o codec de compressão de voz utilizado nos softphones, o G711, é possível verificar que
ele utiliza 64 kbits por segundo, conforme Lima (2006). Ao converter este valor para bytes
por segundo, temos 7812 bytes/segundo, conforme a equação 4.2. Este valor calculado
corresponde apenas aos dados trafegados. Deve-se ressaltar que o valor 7812 é um cálculo
teórico , não condizendo com o tamanho real dos dados que trafegam no enlace. Ainda é

83. 82
necessário adicionar os cabeçalhos das camadas de enlace, rede e transporte. Portanto, é
verificado a relevância nos dados medidos pela aplicação.
V alorKbps
Bytes/seg = (4.2)
1024 ∗ 8
4.4.2 Atraso
O atraso consiste na medição do atraso em que um pacote leva da origem até seu
destino (também conhecido como round trip time). Esta medida de tempo obtida por
meio do experimento tem sua unidade em milissegundos.
Conforme a tabela 4.4, apresentada na seção anterior, é possível verificar que o valor
do atraso é mantido constante ao longo de toda transmissão, exceto pelos instantes 5 s
e 10 s. Este atraso é constante e baixo, devido a utilização de um enlace lógico. A
máquina virtual compartilha a rede com a máquina hospedeira, e além da largura de banda
disponível ser total não existem colisões. Deste modo, como o tráfego total não ultrapassa
10 kbytes/segundo, não acontecem sobrecargas no enlace, consequentemente, o atraso fica
constante e mínimo.
Da mesma maneira que o tráfego RTP, nos primeiros instantes de tempo houve uma
variação no atraso, se comparado com o restante da medição. Isso acontece, pois é uti-
lizado o valor da medição anterior acumulada para calcular a média. O atraso é calculado
a cada dois segundos, sendo a taxa de amostragem do protótipo é de cinco segundos.
Desta forma, para se aumentar a precisão na medição é feito uma média. Como nos
primeiros instantes em que a média é calculada os valores eram nulos, os valores inicias
sofrem variações.
A técnica utilizada para se obter os valores de atraso, e calcular a média é apresen-
tado em 3.3.3. Desta técnica, é possível derivar uma fórmula para se calcular a média
aritmética acumulada para o valor do atraso de ida e volta. A fórmula para este cálculo é
apresentado na equação 4.3.
M ediaAtraso(t − 1) + Atraso(t)
M ediaAtraso(t) = (4.3)
2
A média para o atraso ao longo dos dois minutos de medição é 2 ms. Ao comparar

84. 83
este atraso de ida volta obtido, com o atraso fim a fim recomendado pela norma G.114
(ITU, 2003) de 150 ms, é possível verificar que o valor está dentro do aceitável. O atraso
de ida e volta sempre será maior que o atraso fim a fim, pois este se trata de um atraso
unidirecional, conforme seção 2.2.1.1. O valor obtido pela experimentação, mesmo no
pior caso de medição do atraso de ida e volta, estaria dentro de um valor aceitável, segundo
a recomendação.
4.4.3 Perda de Pacotes
A perda de pacotes medida pelo experimento buscou medir a taxa na qual pacotes são
perdidos ou descartados no enlace, relacionados somente à transmissão live streaming em
questão. Foi buscado uma medida de referência para apresentar este valor, sendo expressa
em porcentagem. Seu referencial é a quantidade de pacotes que trafegaram com sucesso
pelo enlace.
A medição da perda de pacotes foi a única cujos dados obtidos foram constantes ao
longo de toda a execução da aplicação, e em todas cinco execuções. Este dado varia bas-
tante conforme a qualidade do enlace pelo qual trafegam os dados. Como foram utilizadas
máquinas virtuais que compartilhavam o mesmo enlace lógico, e este nunca chegou perto
da sua utilização máxima, não houve nenhuma perda ou descarte de pacotes. Portanto,
esta medição ficou em 0 % em todas execuções do protótipo. É possível verificar esta
medição na tabela 4.4, apresentada na seção 4.3.
A medida da perda de pacotes foi obtida por meio do pacote de controle RTCP.
Desta maneira foi possível medir apenas a perda de pacotes decorrente da transmissão
live streaming. Esta foi a melhor maneira encontrada para se obter esta métrica, pois per-
mitia medir dentro do contexto das transmissões live streaming, e não de todos os dados
trafegados no enlace.
Como não houve nenhuma perda de pacotes, a qualidade da transmissão não poderia
ter sido afetada por esta métrica. Ainda, segundo a recomendação G114 (ITU, 2003),
poderia ter ocorrido uma perda de pacotes de 5 % que a qualidade da transmissão seria
mantida.

85. 84
4.4.4 Buffer de compensação de jitter
A medição do buffer de compensação de jitter realizada pelo protótipo no experi-
mento utiliza um método que necessita primeiro fazer uma amostragem de valores, para
então efetuar o cálculo. Como esta variação no atraso dos pacotes é um dado temporal, a
unidade de medição é o milissegundo.
A técnica utilizada para medição do jitter foi por amostragem e cálculo por meio do
protocolo ICMP. Foram obtidas 30 (trinta) amostras ao longo de 60 (sessenta) segundos,
sendo que a variação no atraso destas amostras eram somados. Findo minuto, foi feito
a média destes valores para obter o jitter. Na seção 3.3.4 foi apresentado o algoritmo
utilizado, mas a fórmula equivalente a este é apresentada em 4.4.
∆Atraso
Jitter(t) = (4.4)
30
Baseado nos dados apresentados pela tabela 4.4, apresentada em 4.3, é possível ver-
ificar que após 100 s iniciais o valor do jitter é apresentado. Em tese, este dado poderia
ter sido exibido aos 60 s, pois são obtidas 30 amostras a cada 2 segundos. Mas, devido ao
atraso na obtenção das amostras, atraso no cálculo e propagação, e atraso para exibição
do gráfico, este dado apenas é apresentado no gráfico após os 100 s.
Ressalta-se que este valor é uma aproximação matemática do valor real, pois este dado
é complexo para se obter (MEGGELEN; SMITH; MADSEN, 2005). Foram amostrados
os dados para o cálculo por meio do protocolo ICMP, ao invés do próprio protocolo RTP
ou RTCP. O problema nesta abordagem é que numa rede onde exista QoS configurado, o
protocolo ICMP poderia estar em outra fila de prioridade, tornando esta medida imprecisa.
Também, o protocolo ICMP pode ser barrado por firewalls, inviabilizando a medição por
este método.
Mesmo executando num ambiente ideal, o protótipo obteve um valor acima do con-
siderado seguro para uma transmissão. Foi obtida uma média de 42,3 ms, enquanto que
o valor seguro seria 30 ms. Devido ao método utilizado para cálculo, este pode não ser
o valor real do tamanho do buffer de compensação de jitter. Para uma futura implemen-
tação, deve ser utilizado um método que calcule por meio do protocolo RTP.

86. 85
4.5 Síntese do Capítulo
Neste capítulo foi abordado os aspectos da experimentação deste trabalho, organizado
em quatro seções. Na primeira seção, foi apresentado o ambiente da experimentação que
foi todo virtualizado, pois precisava ser um ambiente controlado. Este ambiente con-
sistiu de três máquinas virtuais interconectadas, sendo que duas atuaram como estações
de trabalho e outra como gateway server. Na segunda seção, foi descrito o experimento
com o protótipo desenvolvido. As etapas do experimento contemplaram desde o início
do protótipo e estabelecimento de uma ligação VoIP, até o encerramento das chamadas.
Foram feitas cinco transmissões em tempo real, cada uma com duração de dois minutos.
Na terceira seção, foram apresentados os dados obtidos para cada uma das métricas de
desempenho de QoS (largura de banda, atraso, perda de pacotes e jitter), por meio da
medição com o experimento. Na última seção, foram discutidos os resultados obtidos na
seção anterior. Todos os dados tiveram uma medição constante, sem sofrer muita vari-
ação ao longo das cinco transmissões, com exceção do jitter, que além de outros motivos,
variou por causa da técnica empregada na medição.
No próximo capítulo serão apresentadas as conclusões deste trabalho.

87. 86
5 CONCLUSÃO
A transmissão de aplicações em tempo real em redes baseadas na comutação de pa-
cotes (ex: Internet) ainda representa um grande desafio para administradores e profission-
ais de redes. A transmissão com qualidade de conteúdo multimídia (live streaming) exige
o oferecimento de determinadas garantias de desempenho das redes de pacotes. Usual-
mente, tais garantias são expressas através de quatro métricas: largura de banda, latência,
jitter e perda de pacotes. Apesar de serem simples de serem definidas conceitualmente,
tais métricas geralmente não são oferecidas nas ferramentas utilizadas para o monitora-
mento de redes de pacotes ou não podem ser obtidas durante a transmissão do fluxo, o
que torna o seu cálculo complexo e demorado.
Este trabalho teve como objetivo principal desenvolver um protótipo de ferramenta de
monitoramento gráfica em tempo real das métricas de desempenho citadas acima. Além
do desenvolvimento da ferramenta, algumas técnicas de medição das métricas foram pro-
postas, implementadas e testadas por intermédio do protótipo. Os resultados obtidos
demonstraram que não houve variação significativa nos valores obtidos entre as diver-
sas execuções do experimento, com exceção da métrica de jitter. Dentro do contexto do
experimento, a ferramenta mostrou-se robusta e capaz de servir de importante instrumento
de auxílio para administradores e profissionais que desejem monitorar suas transmissões
em tempo real.
Apesar de o desenvolvimento e teste da ferramenta terem obtido sucesso, algumas
dificuldades podem ser descritas. A primeira delas foi a obtenção do valor de jitter por
intermédio do protocolo RTCP. Apesar de este valor estar contido na mensagem sender
report desse protocolo, sua conversão de unidades de timestamp para milissegundos não
foi possível. Em virtude disso, a obtenção desse valor foi feita utilizando-se o proto-

88. 87
colo ICMP, mesmo sabendo-se que os resultados poderiam sofrer variações em função da
diferença de tratamento desse protocolo nos equipamentos de rede. A segunda dificuldade
encontrada foi na obtenção do atraso unidirecional. Com relação ao atraso, a literatura
afirma que as transmissões em tempo real são sensíveis a um determinado valor de atraso
unidirecional. A técnica utilizada no trabalho para a medição desse atributo baseou-se no
atraso de ida e volta (RTT - Round Trip Time), o que torna a comparação direta com o
valor da literatura não tão direta. A terceira dificuldade encontrada foi relacionada com
a medição da largura de banda utilizada. Inicialmente, pensou-se em utilizar o protocolo
SNMP para realizar essa medição. Como isso faria com que houvesse a necessidade da
implementação de agentes nos dispositivos participantes da transmissão live streaming,
a contagem de pacotes RTP e RTCP foi utilizada, tornando o protótipo independente do
SNMP.
Os resultados obtidos no experimento demonstraram que a ferramenta foi bem suce-
dida no processo de medição. No entanto, em função dos testes terem sido realizados
em um ambiente controlado, tal afirmação não pode ser generalizada. Em um ambiente
real, aplicações em tempo real competem com aplicações normais pelo uso de recursos
e podem influenciar o modo como as métricas de cada fluxo são medidas. Além disso,
não foram medidos todos os tipos de transmissões live streaming, o que torna a validação
dos resultados dependente de apenas um tipo de tráfego (VoIP). O protótipo também ficou
fortemente dependente do protocolo SIP para a identificação dos fluxos de dados, sendo
necessários testes com outros protocolos de sinalização (ex: H.323). Outra limitação da
ferramenta é a sua dependência do protocolo ICMP para a medição atraso e jitter. Em
certos ambientes, o protocolo ICMP pode ser filtrado e impedir a coleta dessas métricas.
Além disso, a execução da ferramenta em situações em que políticas de QoS são im-
plementadas nos dispositivos de rede, os pacotes ICMP poderiam sofrer atrasos por não
serem prioritários, afetando a medição. Por último, não houve um processo de validação
formal para comprovar a correção da ferramenta em termos de seus resultados. Os testes
foram feitos utilizando-se um experimento cujos resultados não podem ser expandidos
para outros contextos que não sejam idênticos ao apresentado.
Alguns trabalhos futuros podem ser propostos com o intuito de expandir e/ou mel-
horar a ferramenta desenvolvida nesse trabalho. O primeiro deles seria testar o protótipo
numa topologia de redes mais complexa, simulando um ambiente real. Além disso, para

89. 88
tornar mais real este ambiente deveria ser inserido tráfego de fundo, para analisar o com-
portamento do protótipo com outros dados trafegando na rede. O segundo seria imple-
mentar a identificação de sessão com outros protocolos além do SIP. Outros protocolos
bastante utilizados, e que teriam relevância para este trabalho seriam o H.323 e o MGCP.
O terceiro trabalho poderia ser o aprimoramento na maneira em que são feitos os cálcu-
los de jitter e atraso. Da maneira que é feito, o protótipo fica dependente do protocolo
ICMP na rede, podendo estar indisponível, ou ter uma prioridade menor na rede, se com-
parado ao fluxo RTP. Tais cálculos poderiam ser feitos diretamente pelo protocolo RTP,
e/ou RTCP. O desenvolvimento de uma proposta de validação formal dos objetivos tam-
bém é uma atividade que poderia ser sugerida e que traria maior garantia de correção à
ferramenta.
As aplicações live streaming tendem a crescer em termos de uso à medida que a Inter-
net se populariza e se torna cada vez mais multimídia. Obter informações de desempenho
a respeito dos fluxos que sustentam tais aplicações pode fazer com que os usuários ten-
ham consciência da importância que certas métricas de desempenho exercem em cada
uma delas. Além disso, a extração de informações pode servir de importante apoio para
o desenvolvimento de novos protocolos multimídia que sejam cada vez mais robustos e
resilientes a variações de rede.

90. 89
REFERÊNCIAS
AGENCY, D. A. R. P. Internet Control Message Protocol. IETF - RFC 792, 1981.
Disponível em: <http://www.ietf.org/rfc/rfc792.txt>.
AGENCY, D. A. R. P. Transmission Control Protocol. IETF - RFC 793, 1981. Disponível
em: <http://www.ietf.org/rfc/rfc793.txt>.
APOSTOLOPOULOS, J.; TAN, W.; WEE, S. Video Streaming: Concepts, Algorithms,
and Systems. [S.l.]: HP Laboratories Palo Alto, 2002. 11 p.
BALBINOT, R. et al. Voz sobre ip - tecnologia e tendências. SBRC03, XXI Simpósio
Brasileiro de Redes de Computadores., p. 321–363, 2003.
BUSCHMANN, F. et al. Pattern-Oriented Software Architecture Volume 1: A System of
Patterns. [S.l.]: John Wiley & Sons, 1996.
CARVALHO, L. S. G. Implementação do modelo e para avaliação objetiva da qualidade
da fala em redes de comunicação voip - dissertação (mestrado). Universidade Federal do
Amazonas, 2004.
DEITEL, H. M. Java How to Program, Sixth Edition. [S.l.]: Prentice Hall, 2004.
DOUSKALIS, B. IP Telephony the Integration of Robust VoIP Service. [S.l.]:
Hewlett-Packard Company, 2000.
DURKIN, J. F. Voice-Enabling the Data Network: H.323, MGCP, SIP, QoS, SLAs, and
Security. [S.l.]: Cisco Press, 2002.
ITU, T. S. S. of. Recommendation G.114: International telephone connections
and circuits General Recommendations on the transmission quality for an entire
international telephone connection - One-way transmission time. [S.l.]: ITU-T, 2003.

91. 90
KUROSE, J. E.; ROSS, K. W. Redes de computadores e a Internet: uma abordagem
top-down. [S.l.]: Pearson Addison Wesley, 2006. (3).
LALONDE, W. Discovering Smalltalk. [S.l.]: Pearson Technology Group, 2008.
LARMAN, C. Utilizando UML e Padrões. [S.l.]: BookMan, 2007.
LIMA, A. F. M. de. Monitoramento snmp para avaliar a qualidade das chamadas em um
ambiente voip - dissertação (mestrado). Universidade Federal do Ceará, 2006.
MEGGELEN, J. V.; SMITH, J.; MADSEN, L. Asterisk: The Future of Telephony. [S.l.]:
O’Reilly Media, 2005.
MICROSYSTEMS, S. Java blueprints: Model-view-controller. 2008. Disponível em:
<http://java.sun.com/blueprints/patterns/MVC.html>.
RANJBAR, A. S. CCNP ONT Official Exam Certification Guide. [S.l.]: Cisco Press,
2007.
RIBEIRO, B. F. M.; RODRIGUES, P. H. d. A.; MARCONDES, C.
A. C. Implementação de gateway de sinalização entre protocolos de
telefonia ip sip/h.323. Simpósio Brasileiro de Redes de Computadores.
Florianópolis - SC., SBRC2001, p. 574–589, 2001. Disponível em:
<http://www.voip.nce.ufrj.br/pgv oip/publication/2001/sbrc2001s iph323.pdf >.
ROSENBERG, J. et al. SIP: Session Initiation Protocol. IETF - RFC 3261, 2002.
Disponível em: <http://www.ietf.org/rfc/rfc3261.txt>.
RYBACZYK, P. Expert Network Time Protocol: An Experience in Time with NTP. [S.l.]:
Apress, 2005.
SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. IETF
- RFC 3550, 2003. Disponível em: <http://www.ietf.org/rfc/rfc3550.txt>.
STEWART, B. D.; GOUGH, C. CCNP BSCI Official Exam Certification Guide. [S.l.]:
Cisco Press, 2008. (4).
TAO, S.; APOSTOLOPOULOS, J.; GUéRIN, R. Real-time monitoring of video quality
in ip networks. IEEE/ACM TRANSACTIONS ON NETWORKING, v. 16, 2008.

92. 91
TOPIC, M. Streaming Media Demystified. [S.l.]: McGraw-Hill, 2002.
VELOS, E. et al. A hierarchical characterization of a live streaming media workload. In:
Internet Measurement Workshop. [S.l.]: IEEE, 2002. p. 117–130.