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

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

“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’.”

— DOMÊNICO DE MASI

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.

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

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

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

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

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

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

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

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

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

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.

ABSTRACT

A Propose for a Real Time Monitoring Tool for Live Streaming Applications, based

on the RTP Protocol.

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.

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-

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.

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.

1Disponível em: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/ prod-

ucts_tech_note09186a008010e6ba.shtml. Acesso em 7/outubro/2009.

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,

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.

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

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 Solution1, 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

1O VideoLAN Streaming Solution está disponível no seguinte endereço web:

http://www.videolan.org/vlc/streaming.html. Acesso em: 09/10/2009.2Um 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).

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-

3Skype é um programa que permite áudio e videoconferência gratuitamente. Ele está disponível em

http://www.skype.com. Acesso em 09/10/2009.

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

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.

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

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

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

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

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.

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

4A solução IP-PABX TrixBox está disponível em http://www.trixbox.org/. Acesso em 11/10/2009.

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.

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-

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

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

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

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-5Figura extraida de: http://java.sun.com/javase/technologies/desktop/media

/jmf/2.1.1/guide/images/RTPRealTime2.gif. Acesso em 12/10/2009.

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-

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).

6Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-

ments/images/rtcp_sr_header.jpg. Acesso em 13/10/2009.7Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-

ments/images/rtcp_rr_header.jpg. Acesso em 13/10/2009.

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-

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

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-

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):

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.

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.

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

da linguagem de programação Java 1 permitiu o uso de ferramentas para programação

1O Java é uma inguagem de programação orientada à objetos criada pela Sun Microsystems. Mais

informações: http://java.sun.com/. Acesso em 26/11/2009.

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 Eclipse2, 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-

gramação para Java: JpCap 4 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

2O 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.3Criada 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.4A 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.5A biblioteca JFreeChart, para criação de gráficos, pode ser obtida gratuitamente em:

http://www.jfree.org/jfreechart/. Acesso em 23/10/2009.

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.6A 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.

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;7O 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)

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.8A ferramenta WireShark é livre, e ela pode ser obtida no endereço: http://www.wireshark.org/. Acesso

em 20/10/2009.

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

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

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.

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.

54

4. Aplica a equação 3.1, convertendo o dado para base 100.

PerdaDePacotes =100

256 ∗ PktLoss(3.1)

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.

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 |;

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:

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.

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

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

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

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

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-

9Uma 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.

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:

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,

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.

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.

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

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.

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-

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.

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;

1A 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.

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ão2O softphone Twinkle está disponível para download no seguinte endereço:

http://www.twinklephone.com/. Acesso em 21/11/2009.

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

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.

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

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.

77

Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5

5 s 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

78

Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5

5 s 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

79

Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5

5 s 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.

80

Tráfego RTP (b/s) Atraso (ms) Jitter (ms) Perda de Pacotes (%)

5 s 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,

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.

TrafegoRTP =UsoDeBanda(t1) − UsoDeBanda(t0)

tempoDeAtualizaoDoGrafico(4.1)

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 é

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.

Bytes/seg =V alorKbps

1024 ∗ 8(4.2)

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.

MediaAtraso(t) =MediaAtraso(t− 1) + Atraso(t)

2(4.3)

A média para o atraso ao longo dos dois minutos de medição é 2 ms. Ao comparar

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.

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.

Jitter(t) =

∑∆Atraso

30(4.4)

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.

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.

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-

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

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.

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.

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/pgvoip/publication/2001/sbrc2001siph323.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.

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.