Your SlideShare is downloading. ×
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Tcc Mauricio Bento Ghem 2009 - Versão Final
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tcc Mauricio Bento Ghem 2009 - Versão Final

1,100

Published on

Trabalho de Conclusão de curso de Maurício Bento Ghem (Bentow). …

Trabalho de Conclusão de curso de Maurício Bento Ghem (Bentow).

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

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,100
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP por Maurício Bento Ghem
  • 2. UNIVERSIDADE DO VALE DO RIO DOS SINOS MAURÍCIO BENTO GHEM Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP Monografia apresentada como requisito parcial para a obtenção do grau de Bacharel em Engenharia da Computação Prof. Msc. Eduardo Leivas Bastos Orientador São Leopoldo, Dezembro de 2009
  • 3. “O futuro pertence a quem souber libertar-se da idéia tradicional do trabalho como obrigação ou dever e for capaz de apostar numa mistura de atividades, onde o trabalho se confundirá com o tempo livre, com o estudo e com o jogo, enfim, com o ’ócio criativo’.” — D OMÊNICO D E M ASI
  • 4. AGRADECIMENTOS Gostaria de agradecer a meus pais que desde pequeno me incentivaram a estudar, e me apoiaram acreditando em meu potencial. Também, por me apoiar nas etapas da vida, me dar amor e proporcionar sempre as melhores condições em tudo. Pais, amo vocês. Agradeço a meu irmão por em momentos de total enlouquecimento devido ao tra- balho de conclusão entender minha situação e conversar comigo para relaxar um pouco. Agradeço a minha namorada por tentar compreender minha situação e ficar do meu lado nos muitos finais de semana que dediquei ao estudo. Agradeço aos meus amigos por entenderem a fase da vida que estou passando, por darem apoio e atenção nos momentos que mais precisei, e por estar ao meu lado mesmo eu estando um pouco ausente. Agradeço a meu orientador que me deu motivação, conhecimento, e muitas outras contribuições. Agradeço por acreditar em meu potencial e me dar forças que resultaram numa grande vontade em fazer o mestrado. Por fim, gostaria de fazer uma dedicação especial a todas as pessoas que frequentam meu blog. A troca de experiências para o crescimento pessoal e profissional é recíproca. Agora, é minha vez de agradecer a todos que me deram motivação, ajuda e compreensão nesta etapa. Valeu pessoal.
  • 5. SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 8 LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.1 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Fatores que afetam a transmissão Live Streaming . . . . . . . . . . . 22
  • 6. 2.2.1 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.2 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.4 Largura de Banda Disponível . . . . . . . . . . . . . . . . . . . . . . 28 2.3 Protocolo de Sinalização: SIP . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3.2 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.3 Redirect Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.4 Registrar Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.5 Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4 Protocolos de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4.1 Real-time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . 35 2.4.2 RTP Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . . . 36 2.5 Protocolo para Feedback : ICMP . . . . . . . . . . . . . . . . . . . . . . 39 2.6 Padrão de Arquitetura: MVC . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3 METODOLOGIA DE DESENVOLVIMENTO . . . . . . . . . . . . . . . 45 3.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.2 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
  • 7. 3.3.3 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3.4 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.1 Lógica - Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.5.2 Interface gráfica - View . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.5.3 Controlador - Controller . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.4 Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4 EXPERIMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.1 Ambiente de Experimentação . . . . . . . . . . . . . . . . . . . . . . . 71 4.1.1 Máquina Virtual 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.1.2 Máquina Virtual 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.1.3 Máquina Virtual 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2 Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.4.2 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.4.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.4.4 Buffer de compensação de jitter . . . . . . . . . . . . . . . . . . . . 84 4.5 Síntese do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
  • 8. REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
  • 9. LISTA DE ABREVIATURAS E SIGLAS ACK Acknowledge ASCII American Standard Code for Information Interchange CNAME Canonical Name DARPA Defense Advanced Research Projects Agency FEC Forward Error Correction GUI Graphical User Interface ICMP Internet Control Message Protocol IDE Integrated Development Environment IETF Internet Engineer Task Force IP Internet Protocol MGCP Media Gateway Control Protocol MVC Model View Controller NTP Network Time Protocol PABX Private Automatic Branch Exchange PSNR Peak Signal Noise Ratio PSTN Public Switched Telephone Network QoS Quality of Service RFC Request for Comments
  • 10. RR Receiver Report RTCP RTP Control Protocol RTP Real-time Transport Protocol RTT Round Trip Time SDES Source Description SIP Session Initiation Protocol SNMP Simple Network Management Protocol SO Sistema Operacional SR Sender Report SSRC Synchronization Source TCP Transmission Control Protocol TTL Time to live UAC User Agent Client UAS User Agent Server UA User Agent UDP User Datagram Protocol
  • 11. LISTA DE FIGURAS Figura 2.1: Diagrama demonstrando uma transmissão por streaming. . . . 21 Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em ação (LIMA, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figura 2.3: Funções das entidades numa rede SIP. . . . . . . . . . . . . . . 32 Figura 2.4: O pacote RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figura 2.5: O tipo de pacote sender report, do protocolo RTCP. . . . . . . . 39 Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP. . . . . . . 40 Figura 2.7: Apresentação de diversas visualizações possíveis por causa do MVC, sem alterar a integridade dos dados de negócio (BUSCHMANN et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma das partes que compõem o padrão MVC (MICROSYSTEMS, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de pré-teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figura 3.2: Diagrama da organização de pacotes por agrupamento de fun- cionalidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figura 3.3: Diagrama do modelo de classes do projeto. . . . . . . . . . . . . 60 Figura 3.4: Diagrama de classes completo do protótipo. . . . . . . . . . . . 61
  • 12. Figura 3.5: Diagrama da classe ThreadPcap. . . . . . . . . . . . . . . . . . 63 Figura 3.6: Diagrama da classe classquerierpcap. . . . . . . . . . . . . . . . 63 Figura 3.7: Diagrama da classe ThreadICMP. . . . . . . . . . . . . . . . . . 64 Figura 3.8: Diagrama da classe QuerierICMP. . . . . . . . . . . . . . . . . . 65 Figura 3.9: Diagrama de classes completo do pacote Model. . . . . . . . . 65 Figura 3.10: Diagrama da classe GuiInicial. . . . . . . . . . . . . . . . . . . . 66 Figura 3.11: Diagrama da classe GuiSmB. . . . . . . . . . . . . . . . . . . . . 67 Figura 3.12: Diagrama da classe Grafico. . . . . . . . . . . . . . . . . . . . . 67 Figura 3.13: Diagrama de classes completo do pacote View. . . . . . . . . . 68 Figura 3.14: Diagrama de classes completo do pacote Controller. . . . . . . 68 Figura 3.15: Diagrama de classes completo do pacote Extra. . . . . . . . . . 69 Figura 4.1: Topologia de redes simulada que foi utilizada no ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figura 4.2: Interface gráfica inicial do protótipo. . . . . . . . . . . . . . . . . 74 Figura 4.3: Interfaces de rede disponíveis para execução do protótipo. . . . 74 Figura 4.4: Interface gráfica que representa a tela dos gráficos. . . . . . . . 76
  • 13. LISTA DE TABELAS Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a des- crição. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Tabela 4.1: Valores medidos para cada um das cinco execuções da apli- cação para o tráfego RTP. . . . . . . . . . . . . . . . . . . . . . . 77 Tabela 4.2: Valores medidos para cada um das cinco execuções da apli- cação para o atraso de ida e volta. . . . . . . . . . . . . . . . . . 78 Tabela 4.3: Valores estimados para cada um das cinco execuções da apli- cação para tamanho do buffer de compensação de jitter. . . . . 79 Tabela 4.4: Média aritmética de todos atributos da transmissão live stream- ing ao longo de cinco iterações. . . . . . . . . . . . . . . . . . . 80
  • 14. RESUMO A utilização de aplicações em tempo real sobre redes de pacotes (ex: VoIP, videocon- ferência, live streaming) têm crescido muito nos últimos anos, principalmente em virtude da popularização da Internet e do acesso à banda larga. De modo diferente das aplicações que não são fortemente dependentes dos aspectos temporais da transmissão, as aplicações em tempo real exigem uma infra-estrutura de transporte que possa oferecer determinadas garantias de desempenho aos pacotes. Usualmente, tais garantias são expressas por um conjunto de quatro métricas: largura de banda, atraso, perda de pacotes e jitter. Exis- tem diversas soluções disponíveis no mercado para o monitoramento dessas métricas. No entanto, o cálculo dos valores usualmente depende da aplicação de certos algoritmos in- termediários que podem dificultar a tarefa. Esse trabalho teve como objetivo a criação de uma ferramenta em código-aberto e gratuita que fosse capaz de medir diretamente as quatro métricas descritas acima. Após o desenvolvimento da ferramenta, realizada com técnicas de engenharia de software, um experimento foi realizado com o intuito de verificar se os requisitos previamente propostos para a ferramenta foram atingidos. Os resultados demonstraram que houve pouca variação dos valores coletados em diferentes amostras, com exceção do jitter. Apesar de os testes terem sido realizados em ambiente controlado e com técnicas de coleta que podem influenciar as medições, a ferramenta demonstrou ser rápida e eficaz e pode servir para tornar mais clara e objetiva a medição de desempenho em redes de pacotes. Palavras-chave: Live Streaming. Métricas de desempenho de QoS. Ferramenta de mon- itoramento de redes.
  • 15. A Propose for a Real Time Monitoring Tool for Live Streaming Applications, based on the RTP Protocol. ABSTRACT The use of real-time applications over packet networks (e.g. VoIP, videoconferencing, live streaming) have grown in recent years, mainly due the popularization of Internet and broadband access. Differently from the applications that are not heavily dependent on temporal aspects of transmission, the real-time applications require a transport infrastruc- ture that can provide certain performance guarantees to packets. Usually, such guaranties are expressed by a set of four metrics: bandwidth, delay, packet loss and jitter. There are some solutions available in the market for monitoring these metrics. However, the calcu- lation of the values usually depends on certain intermediary algorithms that may hinder the task. This study had the objective to create a free and open source tool that could di- rectly measure the four metrics described above. After the development of the tool, held by software engineering techniques, an experiment was conducted with the objective of whether the previously proposed requisites for the tool have been met. The results showed that there was almost no variation in the values obtained at different samples, except for jitter. Although the tests have been conducted in a controlled environment and with data collection techniques that could influence the measurements, the tool proved to be rapid and effective and can serve to make clear and objective the performance measurement in packet networks. Keywords: Live Streaming, QoS metrics, Network Monitoring Tool.
  • 16. 15 1 INTRODUÇÃO O live streaming é todo conteúdo audiovisual capturado em tempo real e disponi- bilizado para inúmeros espectadores através da Internet (VELOS et al., 2002). Diversas aplicações multimídia podem ser caracterizadas por esse conceito, tais como conversações por VoIP (Voice over Internet Protocol), videoconferência e entretenimento, e educação à distância (EaD). De um ponto de vista mais específico, qualquer rede de transporte de da- dos baseada na técnica de comutação de pacotes (a Internet é apenas um caso particular) pode ser utilizada para suportar aplicações live streaming. Apesar de mais eficiente em termos de alocação de recursos do que a técnica de comutação de circuitos, a comutação de pacotes não reserva recursos para as aplicações. Cada pacote é visto como uma unidade de informação independente e tratado de maneira individual. Desta forma, os pacotes de uma aplicação podem sofrer atrasos variáveis quando passam em enlaces congestionados e até mesmo serem descartados em casos mais severos (KUROSE; ROSS, 2006). A literatura define quatro métricas de desempenho de rede que influenciam direta- mente no QoS (Quality of Service) oferecido às aplicações em geral: largura de banda, atraso, jitter e perda de pacotes. Em função de seus caráter instantâneo de transmissão, as aplicações live streaming necessitam de uma rede de transporte que ofereça garantias de desempenho que são expressas por valores adequados para cada uma dessas métricas (DURKIN, 2002). Apesar de haver um crescimento significativo na utilização de apli- cações em tempo real (motivado principalmente pelo barateamento do acesso à banda larga), percebe-se a inexistência de uma ferramenta gratuita e de código-aberto que mon- itore continuamente todas as quatro métricas de desempenho de rede oferecidas para uma aplicação em tempo real. Além disso, certas aplicações de monitoramento (especial- mente aquelas baseadas no protocolo SNMP) são dirigidas ao monitoramento de var-
  • 17. 16 iáveis simples e são complexas no tratamento de variáveis mais complexas e que exigem um histórico de amostras (como o jitter, por exemplo). Esse trabalho tem como objetivo o desenvolvimento de um protótipo de ferramenta de código-aberto para o monitoramento do desempenho de aplicações live streaming baseadas no protocolo RTP (Real Time Protocol). A concepção desse trabalho teve in- ício dentro do projeto Convergência Digital da UNISINOS, que tinha como objetivo a criação de aplicações interativas para a tecnologia de TV Digital. O objetivo principal do projeto era permitir a maior interatividade possível do usuário com um meio de acesso. Nesse contexto, foi percebida a necessidade da criação de um sistema Web para interação aluno-professor utilizando-se um ambiente baseado em videoconferência. Além do sis- tema, uma ferramenta de monitoramento em tempo real também mostrou-se necessária com o intuito de informar o usuário da qualidade de sua transmissão live streaming. Optou-se pela análise de aplicações em tempo real baseadas no protocolo RTP em vir- tude de sua ampla utilização no transporte de conteúdo multimídia. O protocolo RTP utiliza como protocolo de transporte o UDP (User Datagram Protocol). O UDP é ampla- mente utilizado em transmissões com tempo real por ser bastante simples e não-orientado à conexão (MEGGELEN; SMITH; MADSEN, 2005). Apesar da possibilidade de real- ização de transmissões em tempo real utilizando o protocolo TCP (Transmission Control Protocol), optou-se pela análise de aplicações em tempo real baseadas em RTP. 1.1 Trabalhos relacionados Existem diversos trabalhos teóricos que procuram analisar o impacto das métricas de desempenho nas aplicações em tempo real. No entanto, poucos descrevem o desen- volvimento de ferramentas que podem ser utilizadas para medir tais métricas. Tao, Apos- tolopoulos e Guérin (2008) propôs uma investigação na qualidade de vídeo em redes IP, por meio da métrica PSNR (Peak Signal Noise Ratio). Este trabalho analisou diversos codecs e suas relações com a taxa de transmissão e características de vídeo, entre outros parâmetros. Por outro lado, Lima (2006) propôs a criação de um sistema que permitia a monitoração das ligações VoIP. Este sistema tinha um caráter centralizado, ou seja, toda a informação era obtida nos hosts repassada para um banco de dados que realizava cálculos para obter uma pontuação média de qualidade com relação à qualidade de uma ligação.
  • 18. 17 Ao invés de decodificar os pacotes de controle da transmissão live streaming, o trabalho propôs a geração de logs por parte da aplicação utilizada na transmissão VoIP, que auxili- ado pelo protocolo SNMP (Simple Network Management Protocol) alimentava a base de dados. Um software pago que possui funcionalidades semelhantes, mas tem uma arquitetura centralizada, é o Cisco Voip Monitor Server 1 . Esta aplicação realiza toda monitoração que esta ferramenta propõe, centraliza todos os dados num servidor e requer a instalação de um agente em cada uma das máquinas que trafegará as ligações VoIP. Uma limitação desta aplicação é que ela possibilita a monitoração apenas de transmissões VoIP, e não qualquer outra que se baseie no live streaming. 1.2 Objetivo O presente trabalho tem como objetivo desenvolver um protótipo de uma ferramenta de monitoramento de desempenho em tempo real de transmissões live streaming baseada no protocolo RTP. Além do objetivo geral, este trabalho tem os objetivos específicos cita- dos a seguir: 1. Estudar as principais métricas de desempenho de QoS que impactam na transmissão live streaming (em tempo real). 2. Estudar e aplicar o padrão de arquitetura MVC no desenvolvimento do protótipo. 3. Propor técnicas de coleta das métricas de desempenho de QoS. 4. Medir os atributos de desempenho de uma transmissão em tempo real por meio do protótipo. 1.3 Estrutura do Trabalho A presente monografia está organizada em 6 capítulos. 1 Disponível em: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/ prod- ucts_tech_note09186a008010e6ba.shtml. Acesso em 7/outubro/2009.
  • 19. 18 Neste primeiro capítulo, é apresentado o contexto no qual este trabalho está inserido, o problema que busca solucionar, e os objetivos gerais e específicos. Também, são ap- resentados os trabalhos relacionados a obra, e a presente estrutura organizacional do tra- balho. No segundo capítulo, é apresentado cada um dos conceitos necessários para a pro- dução deste trabalho. Primeiro, é apresentado o que é e como funciona o streaming e sua evolução, o live streaming, e uma solução que implemente estas duas tecnologias. Em seguida, são apresentados e explicado a existência de cada fatores que afetam uma trans- missão live streaming, os fatores são: atraso, jitter, perda de pacotes e largura de banda. Na sequência, é explicado o protocolo de sinalização SIP (Session Initiation Protocol), responsável por estabelecer sessões entre os participantes de uma transmissão. Os próxi- mos itens a serem explicados são os protocolo RTP e RTCP, que atuam em conjunto per- mitindo a transmissão e controle dos dados entre integrantes de uma transmissão. Então, é apresentado o protocolo ICMP (Internet Control Message Protocol), parte integrando do Internet Protocol (IP), responsável por fornecer feedback de conectividade da rede. Na próxima seção é descrito o padrão de arquitetura que será utilizado para desenvolver o protótipo, o MVC (Model View Controller). Por fim, é feita uma síntese do que foi visto no capítulo. No terceiro capítulo, é abordada a metodologia empregada para o desenvolvimento deste trabalho. Primeiro, é descrito o ambiente de pré-testes, em termos de responsabi- lidade e especificações de hardware e software. Este ambiente é utilizado para execução das etapas da metodologia. Em seguida, é apresentado a metodologia para coleta, que engloba (1) a identificação dos dados necessário coletar na rede e sua obtenção, e (2) com base na análise dos dados da fase anterior são propostas técnicas de obtenção das métricas desempenho de QoS numa rede. Por fim, é apresentado a etapa de desenvolvi- mento do protótipo, desde o levantamento dos requisitos até a implementação das técnicas propostas na etapa anterior da metodologia. No quarto capítulo, é descrito a experimentação feita com o protótipo. Primeiro, é de- scrito o ambiente de testes utilizado, contemplando a responsabilidade e as especificações de software de cada uma dos dispositivos virtuais. Foram utilizadas máquinas virtuais, pois diferentemente do ambiente de pré-testes, este ambiente deve ser controlado. Então,
  • 20. 19 é executado o teste-piloto, sendo descrita cada uma das etapas contempladas pelo teste. Na próxima seção, são apresentados os resultados obtidos com o teste e seus significa- dos, por meio de tabelas. Na última seção, é feita uma análise e discussão dos resultados obtidos. No quinto capítulo são feitas as conclusões deste trabalho. É feito um fechamento e apresentado as dificuldades encontradas, as limitações tanto da metodologia quanto do protótipo produzido e os trabalhos futuros que podem ser desenvolvidos com base neste.
  • 21. 20 2 REVISÃO BIBLIOGRÁFICA Neste capítulo serão abordados os conceitos teóricos que subsidiam o tema desse estudo. Inicialmente o conceito de live streaming é apresentado e os problemas associados a transmissão em tempo real são descritos. Após, cada um dos protocolos que foram utilizados no trabalho são descritos: SIP, RTP, RTCP, e ICMP. Em seguida, o padrão de arquitetura MVC que será utilizado na modelagem do protótipo também é descrito detalhadamente. O último item do capítulo traz um resumo dos conceitos abordados. 2.1 Live Streaming A tecnologia de streaming consiste na quebra de um fluxo de dados em pequenos pedaços para enviá-los um a um sucessivamente, sendo que o receptor decodificará cada parte e a executará sem ter que esperar por todo o fluxo de dados (APOSTOLOPOULOS; TAN; WEE, 2002). Essa tecnologia existe desde que as transmissões por rádio e televisão analógica foram inventadas. O equipamento do espectador, desde aqueles tempos, recebia dados continuamente, sendo que simultaneamente esses dados eram apresentados, seja na tela ou nas caixas de som (TOPIC, 2002). Hoje em dia, esse conceito de streaming foi migrado para a Internet, preservando alguns princípios de antigamente, como o de oferecer conteúdo sob demanda para o usuário. Para que um conteúdo estático seja íntegro, é necessário que este seja disponibilizado em sua totalidade. O streaming, em relação ao conteúdo estático, possui uma grande vantagem: a possibilidade no acesso ao conteúdo sob demanda (TOPIC, 2002). Conforme o conteúdo é executado, as partes seguintes estão sendo recebidas e executadas, e desta forma segue, sucessivamente. A figura 2.1 apresenta um modelo de aplicação baseada no
  • 22. 21 streaming. Figura 2.1: Diagrama demonstrando uma transmissão por streaming. Para ser possível a exibição do streaming são necessários três etapas. Primeiro, é necessário ter a mídia estática, como por exemplo um arquivo de vídeo codificado em MPEG-2. Então, precisa-se passar esta mídia para um servidor de streaming, que dividirá a mídia em pequenos pedaços, para serem enviados sequencialmente para o receptor. Por último, é necessário o receptor ter um player compatível (TOPIC, 2002). Uma solução de streaming disponível na Internet é o VideoLAN Streaming Solution 1 , que engloba o servidor de streaming e o player para ser executado no receptor. Esta aplicação suporta os mais diversos protocolos de transporte para aplicações streaming, tais como: RTP/RTCP, RTSP e HTTP. Também, suporta uma vasta gama de codecs 2 , citados a seguir: Mpeg-1, Mpeg-2, Mpeg-4, WMV, DivX e H.264. Esta solução possibilita a utilização não só de arquivos estáticos, mas também de mídias capturadas em tempo real, caracterizando o live streaming, que será explicado a seguir. A evolução do streaming é a chamada live streaming, que possibilita a transmissão ao vivo de uma mídia. Com esta tecnologia é possível enviar, diretamente, para a Internet um vídeo capturado por uma câmera sem ter que armazená-lo. Esta evolução permite que as emissoras transmitam via Internet eventos, programas e rádios em tempo real, permitindo o aumento no número de espectadores que assistem ou escutam seus programas. No entanto, a áudio e videoconferência foram as aplicações que foram mais difundidas pela 1 O VideoLAN Streaming Solution está disponível no seguinte endereço web: http://www.videolan.org/vlc/streaming.html. Acesso em: 09/10/2009. 2 Um codec é um conjunto de algoritmos de codificação (e decodificação) de sinais que tem como obje- tivo a compressão de um sinal buscando a menor perda de qualidade possível. Para mais informações sobre codecs, consultar Lima (2006).
  • 23. 22 Internet, por meio de programas de fácil acesso como o Skype 3 . A videoconferência trouxe uma enorme quebra de paradigma, possibilitando que pessoas conversem frente a frente estando em qualquer lugar do mundo. Tanto o streaming quanto o live streaming podem ser implementados de muitas maneiras e com muitas ferramentas. Por ter menos overhead que o TCP, e por não ter confirmação de cada pacote recebido, o protocolo UDP se torna um atrativo. Em cima do protocolo UDP, é utilizado o RTP aliado ao RTCP (Real-time Control Protocol), que permite con- trole e geração de estatísticas da transmissão. Existem implementações que utilizam o TCP (Transmission Control Protocol) como protocolo de transporte, como a do Skype, mas o UDP é muito mais utilizado (TOPIC, 2002). 2.2 Fatores que afetam a transmissão Live Streaming As transmissões em tempo real são sensíveis a quatro parâmetros em uma rede co- mutada de pacotes: largura de banda, perda de pacotes, atraso e jitter (KUROSE; ROSS, 2006). Este parâmetros podem acarretar na degradação da qualidade da transmissão, se certos limiares forem ultrapassados. Nas seções seguintes, serão apresentados cada um dos parâmetros que podem acarretar na perda de qualidade na transmissão. 2.2.1 Atraso O atraso entre emissor e receptor é subdividido em duas classificações: atraso fim a fim e atraso de ida e volta. Estes dois tipos de atrasos serão apresentados a seguir, conforme Lima (2006). 2.2.1.1 Atraso fim a fim O atraso fim a fim é o tempo que um pacote leva para ir de um emissor para um recep- tor. Esta métrica é bastante problemática para ser estimada, pois podem existir diferenças nos relógios do emissor e do receptor. Para solucionar este problema, pode-se utilizar na rede equipamentos especializados ou serviços de sincronização de relógios que uti- 3 Skype é um programa que permite áudio e videoconferência gratuitamente. Ele está disponível em http://www.skype.com. Acesso em 09/10/2009.
  • 24. 23 lizam o protocolo NTP (Network Time Protocol). Para mais informações sobre o NTP ver Rybaczyk (2005). Este atraso é composto por um somatório dos seguintes atrasos: percurso elétrico do pacote pela rede IP, formação e reprodução dos pacotes, processamento do sistema operacional e atraso nas redes IP. Estas origens de atraso serão discutidas nas seções a seguir, conforme Carvalho (2004) e Lima (2006). 1. Percurso Elétrico: Este atraso corresponde ao tempo em que é capturado um dado do meio físico, passado por um conversor A/D (Analógico/Digital), transformado-o numa linguagem que possa ser entendida e armazenada pelo computador. Um ex- emplo com voz, seria quando a voz do locutor passa pelo transdutor eletroacústico, para depois atingir o conversor A/D. No lado do receptor, o dado digital sai do con- versor D/A (Digital/Analógico) e vai para o transdutor eletroacústico. Este atraso é constante, porém mínimo, pois os elétrons percorrem os circuitos elétricos a uma velocidade próxima à da luz. 2. Formação e Reprodução dos Pacotes: Representa o tempo utilizado para o preenchi- mento com dados de voz e/ou vídeo os pacotes live streaming para serem enviados e reproduzidos no destino como um sinal audiovisual. Estes atrasos estão na faixa de 20 ms a 30 ms, na sua formação, e de 50 ms na sua reprodução. 3. Sistema Operacional: Este atraso é variável e depende do sistema operacional utilizado. O atraso está relacionado à fatia de tempo que o kernel do sistema opera- cional aloca para o processo responsável pela transmissão live streaming, à capaci- dade de processamento do sistema, à memória do equipamento e da quantidade de processos que estão em execução em paralelo. 4. Atraso nas Redes IP: Este é o atraso que é o gargalo na transmissão. Devido a este atraso, a interatividade da conversa pode sofrer um efeito desconfortável, e, segundo a recomendação G.114 (ITU, 2003) esse tempo não deve ultrapassar 150 ms, pois a degradação de qualidade é perceptível. Este atraso é composto por uma parte fixa e outra variável. (a) Atraso Variável: O atraso variável corresponde ao tempo em que o pacote passa pelas filas de transmissão. O número de roteadores e comutadores
  • 25. 24 que estão entre a origem e o destino, e seu poder de processamento, con- tribuem diretamente para a formação do atraso variável. Uma maneira eficaz de minimizar este atraso é a implementação de QoS, permitindo que os pa- cotes live streaming tenham uma prioridade maior que os pacotes de dados convencionais. (b) Atraso Fixo: É composto por três tipo de atraso: tempo de empacotamento, tempo de serialização e atraso de propagação no meio físico. i. Tempo de empacotamento: Corresponde ao tempo necessário para se codificar ou decodificar os dados com os codecs necessários. Este tempo depende unicamente do tipo de codificação e codec utilizado. Caso o codec possua um algoritmo de alta complexidade, o tempo pode ser ex- tendido. Para maiores informações sobre codecs de áudio e vídeo consul- tar Lima (2006). ii. Tempo de serialização de bits: É o tempo necessário para se colocar os bits lógicos dos pacotes no meio físico de transmissão, sendo que este depende da velocidade do meio físico e do tamanho do pacote que está sendo transmitido. É possível obter este valor por meio da razão do tamanho do pacote já contendo o cabeçalho da camada de enlace e a taxa de transmissão do meio (ambos em kbps). iii. Atraso de propagação: Corresponde ao tempo em que os bits levarão para se propagar até o próximo nó da rede. Este tempo depende do meio físico que conecta um nó ao outro. Concluindo esta seção, o somatório dos tempos de fila, serialização e propagação compõem o tempo de rede. O primeiro é considerado um tempo estocástico, pois pacotes distintos de um mesmo fluxo de dados podem sofrer atrasos de filas diferentes, a depen- der do caminho percorrido pela rede IP. Já os tempos de serialização e propagação são considerados tempos determinísticos, pois são tempos fixos a depender da velocidade de transmissão do meio físico.
  • 26. 25 2.2.1.2 Atraso de ida e volta O atraso de ida e volta é o tempo que um pacote leva para ser enviado por um emissor, recebido pelo receptor, e devolvido para o emissor. Outro nome o qual é referido este atraso é o round trip time, ou RTT. Diferente ao outro tipo de atraso, o atraso de ida volta não depende da sincronicidade dos relógios, porém, algumas considerações devem ser feitas, como por exemplo, a precisão mínima de leitura do relógio no sistema operacional. Mas, os mesmo princípios apresentados na seção 2.2.1.1, de composição do atraso se aplicam para este também. Este atraso não corresponde ao valor do atraso fim a fim multiplicado por dois, pois a rede IP é assimétrica, portanto, o tempo que o pacote leva para chegar ao seu destino não corresponde, necessariamente, ao mesmo tempo que levaria para voltar à sua origem. Isto depende da maneira na qual os pacotes são roteados e comutados ao longo da rede. 2.2.2 Jitter O jitter se refere à variação na latência entre dois pacotes, ou seja, é a diferença entre as latências de dois pacotes, medida em dois instantes de tempos diferentes. Quando um fluxo live streaming é enviado para um dispositivo, ele é enviado à uma taxa constante com uma pequena variação na latência. No entanto, conforme os pacotes atravessam a rede, a latência dos pacotes pode variar, e chegar no destino em tempos diferentes, e pos- sivelmente, fora de ordem. O buffer de compensação de jitter é uma área de memória em que os pacotes são reordenados e entregados em streams constantes e reguladas (MEGGE- LEN; SMITH; MADSEN, 2005). Os pacotes necessitam de um tempo para se propagar da origem até o destino na rede IP. A diferença entre o tempo de chegada e o de partida é composta por uma parte fixa e outra variável (jitter). Esta parte variável se deve ao comportamento das filas de roteamento, como visto na seção 2.2.1.1. Caso os pacotes recebidos fossem executados sem nenhum tratamento para jitter, a qualidade da transmissão seria comprometida. Para isso, os receptores da transmissão implementam um buffer para compensar os efeitos do jitter. Este buffer tem como função segurar os pacotes por um tempo máximo até que os seus adjacentes possam chegar, e
  • 27. 26 a reprodução possa ser feita de modo síncrono (LIMA, 2006). A compensação de jitter pode ser observada na figura 2.2. Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em ação (LIMA, 2006). O tamanho deste buffer é o período de tempo máximo em que este pacote aguardará até ser reproduzido pelo cliente. Este valor deve ser bem especificado, pois se o tamanho for muito pequeno, os pacotes correm o risco de não chegarem a tempo e serem descarta- dos, em contrapartida, se o tamanho do buffer de compensação for muito grande o atraso fim a fim será aumentado, degradando a qualidade da transmissão. Segundo Meggelen, Smith e Madsen (2005), este valor não deve exceder 30 ms para uma transmissão com streaming. Para se determinar corretamente o valor do buffer, duas variáveis devem ser anal- isadas: a perda de pacotes e o atraso fim a fim. Também, é levado em consideração que estes valores devem respeitar os limiares de segurança, para que não se tenha uma degradação na qualidade da transmissão. Para a perda de pacotes o valor é 5% e para o atraso fim a fim é de 150 ms, conforme ITU (2003). 2.2.3 Perda de Pacotes Uma perda de pacote, sob o ponto de vida da transmissão pela rede IP, ocorre quando o mesmo não consegue chegar ao seu destinatário. A perda de pacotes é impactante no contexto de uma aplicação live streaming. Os três principais motivos pelos quais podem ocorrer perdas de pacotes são: erros na transmissão, descarte pelos roteadores de rede, ou
  • 28. 27 ainda, por causa do buffer de compensação de jitter (LIMA, 2006). Como a rede IP, por si só, não garante a entrega dos pacotes, no momento que ela se encontra sobrecarregada, ocorrem congestionamentos. Quando o roteador está com seus buffers cheios, a solução empregada por eles é o descarte dos pacotes. Se o protocolo de transporte empregado for o TCP, este cuidará para que os pacotes sejam retransmitidos. Ao passo que se for utilizado o UDP, como é um protocolo simples e não-orientado à conexão, os pacote não são recuperados. O problema de perdas de pacotes pode ser amenizado, utilizando técnicas ou mecan- ismos de reparação de pacotes perdidos, tais como: FEC (Forward Error Correction), in- terleaving, retransmissão e compensação. Cada uma destas técnicas e mecanismos serão apresentadas nos itens a seguir, conforme Balbinot et al. (2003). 1. FEC: Este mecanismo é um dos mais utilizados na atualidade, para manutenção na qualidade de sistemas VoIP. Com o FEC é adicionado uma redundância nos dados, permitindo a correção de dados perdidos ao longo da transmissão. A cada quadro ou pacote de voz, é adicionada informação relacionada às amostras de voz mais adiantadas ou mais atrasadas. Deve-se pesar bastante a necessidade de utilizar este mecanismo, pois como é adicionado uma redundância de dados na rede, pode-se causar congestionamento desnecessário. Se a perda já é decorrente de um conges- tionamento, o aumento neste fluxo pode agravar a situação. 2. Interleaving: Esta técnica reordena os quadros de mídia de múltiplos pacotes se- quencias, interpolando-os antes de efetuar o envio deste fluxo de dados. Quando o receptor receber este fluxo, este é reordenado em sua ordem original. Caso ocorra alguma perda de pacotes ao longo da transmissão, terá sido perdido poucos quadros, possibilitando uma reconstrução da mídia com perdas não significativas. Combi- nada com técnicas de compensação, pode-se obter um nível aceitável de qualidade para taxas não muito elevadas de perda. 3. Retransmissão: Esta técnica reenvia o pacote perdido. Para esta técnica ter sucesso é necessário que o pacote retransmitido chegue ao receptor a tempo para ser repro- duzido. Normalmente, esta técnica é utilizada em redes com alta disponibilidade. 4. Compensação: Este mecanismo é aplicado no lado do receptor, com o objetivo
  • 29. 28 de corrigir eventuais situações ocorridas devido à perda de pacotes. Existem três classes de compensação que podem ser utilizadas: técnicas de inserção, interpo- lação e regeneração. (a) Técnica de inserção: Prevê a substituição do pacote perdido por ruído, silên- cio ou a repetição do último pacote recebido com sucesso; (b) Interpolação: Procura recriar uma versão similar do pacote perdido através da interpolação entre pacotes adjacentes, armazenados num buffer de amostras; (c) Regeneração: Amplia o conceito da interpolação utilizando além dos pacotes adjacentes, informações à respeito do codec utilizado na codificação dos da- dos. Pacotes que chegam demasiadamente atrasados em relação ao instante de tempo que deveriam ser reproduzidos no receptor tornam-se inúteis, e consequentemente, são descar- tados. Do ponto de vista do receptor, estes pacotes foram perdidos. Portanto, para se calcular o número de pacotes perdidos num enlace, deve-se levar em conta as perdas dos pacotes na camada de rede e também na camada de aplicação. Para as transmissões live streaming, a perda de pacotes deve ser inferior a 5% (ITU, 2003). Caso este valor seja excedido, a perda da qualidade na transmissão é perceptível pelo usuário final. Numa transmissão VoIP, a qualidade da conversação será afetada. 2.2.4 Largura de Banda Disponível Numa rede de computadores, sempre é buscado que os dados fluam pelo melhor cam- inho por meio dos roteadores, partindo da origem para o destino. A quantidade de infor- mação por segundo que um meio de transmissão permite fluir é denominada largura de banda disponível. Este dado é expresso em bytes/segundo ou bits/segundo (RANJBAR, 2007). A demanda de utilização da largura de banda disponível é controlada pela aplicação. Algumas aplicações necessitam enviar dados a uma certa taxa mínima para funcionar com êxito, é o exemplo de aplicações live streaming. Esta aplicações, além de serem sensíveis à perda de pacotes, atraso e jitter, também são sensíveis à largura de banda. Se uma certa largura de banda não estiver disponível, a aplicação terá que codificar os dados a uma
  • 30. 29 taxa diferente (adequando-se a largura de banda disponível), ou terá que desistir de enviar os dados, pois se os dados chegarem depois do que o esperado eles serão descartados de qualquer maneira (KUROSE; ROSS, 2006). Também, existem aplicações nas quais não necessitam uma largura de banda mínima. As chamadas aplicações elásticas tem a capacidade de fazer o uso de qualquer largura de banda mínima ou máxima disponível. Navegação web, correio eletrônico e transferência de arquivo são exemplos de aplicações elásticas (KUROSE; ROSS, 2006). A largura de banda disponível muitas vezes acaba por ser um dos grandes proble- mas numa rede. Isto ocorre, pois a solução direta para este problema é o aumento da largura de banda disponível. Mas, para isso ser possível são necessários investimentos na infra-estrutura, muitas vezes inviabilizando num primeiro momento este upgrade. Este é apenas um dos métodos para se poder trafegar mais dados numa rede. Todos os métodos disponíveis seguem a seguir, conforme Ranjbar (2007). 1. Aumentar a capacidade do link: Como foi mencionado no parágrafo a seguir, esta é a maneira mais efetiva, porém a com mais custo direto. Para que seja aumentada a capacidade do link de dados, é necessário um investimento, o que é uma certa limitação para a resolução deste problema. 2. Marcar e classificar tráfego e implantar técnicas de filas: Com este método é possível que os dados com maior prioridade sejam encaminhados primeiro ao longo da rede. Para que este método funcione, é necessário que os dados sejam demarcados na camada de acesso da rede, para que ao longo dela sejam aplicadas as técnicas de filas de prioridade. Para mais informações sobre filas de prioridades, consultar Ranjbar (2007). 3. Utilizar técnicas de compressão: Existem técnicas que realizam a compressão de dados de alguns protocolos. Devem ser utilizadas com muito planejamento, pois os equipamentos que realizarem esta compressão estarão realizando um processa- mento a mais do que em sua operação convencional. Algumas das técnicas exis- tentes são: compressão de TCP, de camada 2 e de RTP. Neste último, o roteador desempenha um papel crucial, pois este compressão mapeia os cabeçalhos IP, UDP e RTP, compactando esta soma de cabeçalhos dos 40 bytes originais, para 2 bytes.
  • 31. 30 2.3 Protocolo de Sinalização: SIP O SIP é (Session Initiation Protocol) um protocolo de sinalização que roda na ca- mada de aplicação, que engloba a criação, modificação e finalização de uma sessão entre um e/ou mais participantes. Estas sessões incluem ligações via Internet, conferências e distribuição de conteúdo multimídia. Como o SIP é um protocolo que engloba apenas a sinalização, é necessário um protocolo que possibilite o transporte da informação fim-a- fim, neste contexto, o RTP é empregado. Idealizado por Henning Schulzrinne em 1990, no Departamento de Ciência da Com- putação da Universidade de Columbia, este protocolo teve sua primeira especificação formal submetida pelo IETF (Internet Engineering Task Force) em 1999, descrita na RFC (Request for Comments) 2543. O IETF continuou o trabalho de especificação e otimiza- ção do protocolo SIP, e em 2001 liberou outra especificação, a RFC 3261. Devido a sua simplicidade, extensibilidade e escalabilidade, ainda em 2001, diver- sas empresas começaram a adotar este protocolo em seus produtos, mesmo com outros protocolos já firmados no mercado como o H.323 e o MGCP (Media Gateway Control Protocol). Para mais informações sobre estes protocolos ver a referência Durkin (2002). Mesmo não sendo o protocolo de sinalização adotado por grande parte das empresas para conferências, este trabalho optou por utilizar o SIP, pois as soluções de código-aberto adotaram o SIP como padrão. O Asterisk é a principal aplicação de código-aberto para aplicações VoIP e conferência, conforme cita Meggelen, Smith e Madsen (2005). Um exemplo de solução que utiliza o Asterisk como base é a TrixBox 4 , que agrupa uma co- letânea de softwares que atuam em sinergia para ter como resultado um PABX que pode interligar redes IP com redes PSTN (rede telefônica pública comutada). O protocolo SIP foi criado para ser simples, deste modo a codificação das mensagens é feita toda em caracteres ASCII (ROSENBERG et al., 2002). Desta maneira, é possível ver todas as mensagens em formato de texto. Todas os tipos de mensagens trocadas pelo protocolo SIP são apresentadas nos itens a seguir, conforme Lima (2006) e Rosenberg et al. (2002). 1. INVITE: utilizada para se iniciar uma chamada. Esta mensagem, além de possuir 4 A solução IP-PABX TrixBox está disponível em http://www.trixbox.org/. Acesso em 11/10/2009.
  • 32. 31 os dados SIP, contêm dentro dela dados do protocolo SDP (Session Description Protocol), definido na RFC 2327. Por meio dos dados incluídos no SDP, é pos- sível identificar todos os dados da sessão, tais como: número de porta de origem e destino para a transmissão RTP, codec utilizado, tipo de sessão (voz ou vídeo), e informações de cada um dos componentes da sessão. 2. ACK: enviada pelo cliente para confirmar que ele recebeu uma resposta final do servidor, como por exemplo: 200 OK; 3. OPTIONS: é enviada de um cliente para o servidor para verificar suas capacidades. O servidor, por sua vez, envia de volta uma lista com os métodos que ele suporta; 4. BYE: enviada por algum dos clientes para para interromper ou encerrar uma chamada; 5. CANCEL: enviada para interromper uma mensagem enviada anteriormente en- quanto o servidor ainda não tiver enviado uma resposta final; 6. REGISTER: clientes podem registrar sua localização atual com esse pedido. Um servidor SIP que aceita esta mensagem é denominado Registrar. Com esta men- sagem é possível adicionar, remover e pesquisar associações de clientes, com suas respectivas localizações (ROSENBERG et al., 2002). Ao trocar mensagens, as respostas são identificadas por números, que identificam a classe da resposta. As respostas estão divididas em 6 categorias (para mais informações consultar Douskalis (2000)): 1. Classe 1xx: mensagens informativas; 2. Classe 2xx: sucesso; 3. Classe 3xx: redirecionamento; 4. Classe 4xx: erros do cliente; 5. Classe 5xx: erros do servidor; 6. Classe 6xx: falhas globais.
  • 33. 32 O ambiente no qual é executado o protocolo SIP é dotado de duas entidades físicas: o cliente e o servidor. O cliente é conhecido como User Agent, e o servidor possui diversas funções distintas: Proxy, Redirect, Registrar e Gateway server. Na figura 2.3 é possível observar cada uma destas funções numa rede. Estas funções são explicadas nas próximas seções, conforme Rosenberg et al. (2002) e Lima (2006). Figura 2.3: Funções das entidades numa rede SIP. 2.3.1 User Agent O UA (User Agent) é o ponto final da comunicação, o usuário final. Existem ainda duas subdivisões: o UA Client (UAC) e UA Server (UAS). O UAC é a entidade lógica que cria uma nova requisição de comunicação. Este papel é mantido apenas enquanto durar a transação. O papel não é mantido ao longo de toda a sessão, pois se uma aplicação inicia uma requisição ela é mantida como UAC desta transação. Se, durante a sessão receber uma requisição, a outra parte será o UAC desta transação. Em contrapartida, o UAS é a entidade lógica que gera uma resposta para uma requi-
  • 34. 33 sição SIP. A resposta aceita, rejeita ou redireciona a requisição. Da mesma maneira que o UAC, este papel é mantido apenas enquanto durar a transação. 2.3.2 Proxy Server Tem como função redirecionar requisições e respostas SIP. Ele age como uma enti- dade intermediária que atua como ambos cliente e servidor no âmbito de realizar requi- sições como se fosse outros clientes. Ele atua como se fosse um roteador, recebendo uma requisição de sessão de um UA, e consultando o registrar server para descobrir infor- mações do UA de destino. Se o UA de destino estiver no mesmo domínio, a requisição de sessão é enviada diretamente para o UA, caso contrário é enviado para o proxy server do domínio em questão. O proxy server interpreta, e se julgar ser necessário, reescreve a mensagem de requi- sição antes de encaminhá-la. É utilizado muitas vezes para aplicar políticas de restrição sob os UAs. 2.3.3 Redirect Server O redirect server é um UAS que ao receber mensagens do tipo INVITE gera respostas de classe 3xx, com um novo endereço SIP. Este servidor responde as requisições com um novo endereço, mas não faz o papel de continuar a chamada, como no caso do proxy server. Pode ser usado em conjunto com um registrar server, redirecionando chamadas para a localização atual do originador da chamada (RIBEIRO; RODRIGUES; MARCON- DES, 2001). 2.3.4 Registrar Server Este servidor aceita as requisições do tipo REGISTER e coloca as informações rece- bidas do usuário em algum servidor de localização. Os registrar servers são necessários para manter a informação de localização atual de um usuário. O endereço IP de um usuário pode ser alterado por alguma circunstância, como por exemplo, uma conexão de acesso à Internet que forneça ao cliente um endereço IP dinâmico. Para se manter este registro, estas mensagens são trocadas periodicamente entre o UA
  • 35. 34 e o registrar. Se um UA se mover na rede e deseja negociar novos parâmetros do registro, ele pode cancelar um registro existente e enviar um novo, conforme Douskalis (2000). 2.3.5 Gateway Server O gateway faz a interconexão entre redes SIP e redes que não utilizam este protocolo, como por exemplo, uma rede VoIP com outro protocolo de sinalização, ou uma rede de telefonia comutada (PSTN). Este dispositivo realiza funções de tradução da sinalização utilizada para o estabelec- imento e término de chamadas e a conversão do formato da mídia de uma rede para outra. As chamadas podem ser destinada a telefones tradicionais ou a dispositivos SIP, mas o gateway deve saber como encaminhá-las. A aplicação Asterisk é um exemplo de um gateway server. 2.4 Protocolos de Transporte Para se transmitir dados de uma rede para outra, seja ela qual for, é necessário que estes dados sejam encapsulados com diversos cabeçalhos, partindo da camada física até a camada de aplicação. A quarta camada do modelo TCP/IP, a camada de transporte, prevê a comunicação lógica entre processos de aplicação que rodam em hospedeiros diferentes, conforme Kurose e Ross (2006). Neste contexto, como este trabalho está lidando com aplicações live streaming, que são sensíveis principalmente ao atraso e às perdas de pa- cotes, surge a necessidade de utilizar o protocolo RTP, que tem como principal função agir como uma interface entre aplicações em tempo real e os protocolos da camada de transporte. Os dois protocolos que estão disponíveis na camada de transporte são o TCP, definido na RFC 793 e o UDP, definido na RFC 768. O protocolo TCP é o protocolo mais utilizado na Internet (LIMA, 2006). Este proto- colo foi criado com o objetivo de garantir a entrega dos pacotes, por isso cada pacote tran- sitado pelo TCP deve receber a confirmação do recebimento, na terminologia, o acknowl- edge (ACK) (mais detalhes em Agency (1981b)). Como numa transmissão em tempo real, se um pacote é perdido ou corrompido, a sua retransmissão não seria necessária (o pacote seria relevante apenas no instante de tempo que passou), o protocolo TCP causaria
  • 36. 35 um overhead de informações na rede. Além disso, o TCP não suporta a entrega de pa- cotes via multicast (entrega de um para muitos). Para maiores informações a respeito de multicast, consultar Stewart e Gough (2008). Por fim, o TCP não fornece informações, nem estatísticas da transmissão que possam ser analisadas para verificar a qualidade da transmissão. O protocolo UDP também é bastante utilizado na Internet, e foi criado com o objetivo de ser simples. Este protocolo não é orientado à conexão, logo os pacotes perdidos ou corrompidos no meio do caminho não são reenviados. Outra característica do UDP é que os pacotes (segmentos no contexto da camada de transporte) não possuem qualquer informação temporal nem número de sequência. Diferentemente do TCP, o UDP não causa nenhum atraso pré-transmissão, pois como é não orientado à conexão não utiliza a técnica de apresentação de três mensagens que possui o TCP (three way handshake). A grande maioria das aplicações live streaming utiliza os protocolos RTP/RTCP/UDP, pois o UDP gera menos overhead na comunicação (LIMA, 2006). Os protocolos RTP e RTCP serão abordados nas próximas seções. 2.4.1 Real-time Transport Protocol (RTP) O protocolo RTP permite o transporte fim-a-fim de aplicações que transmitam dados em tempo real, como áudio e vídeo, por meio de multicast ou unicast. Este protocolo não garante a qualidade do serviço (QoS) para transmissões em tempo real, por isso funciona em conjunto com o RTCP que permite monitorar a entrega, gerar estatísticas dos dados, e identificar os usuários que os recebem - numa rede multicast - proporcionando dados para o administrador analisar e realizar uma melhora no serviço. Uma maneira para se garantir a QoS é: (1) aplicar a marcação expedite forwarding no byte ToS (type of service), contido no pacote IP e (2) permitir que este tráfego flua dentro de uma fila de prioridade nos roteadores que estiverem intermediando esta transmissão. Para mais informações sobre QoS e filas de prioridades ver Ranjbar (2007). Este protocolo foi idealizado por Henning Schulzrinne e teve sua especificação inicial submetida pela IETF em 1996, como a RFC 1889. Após diversas modificações, princi- palmente na maneira que era calculado o jitter e o tempo de envio dos pacotes RTCP
  • 37. 36 (SCHULZRINNE et al., 2003), em 2003, o IETF submeteu a nova especificação RFC 3550. O RTP é específico para o tráfego de dados, deixando a cargo do RTCP estatísticas das informações. Mas, o RTP possui informações atreladas ao pacote, tais como: timestamp, número de sequência, descrição dos dados e identificação global. O pacote RTP pode ser visto na figura 2.4 5 . Como o RTP roda sob o UDP, não é possível garantir a entrega das informações sem erro. Portanto, os protocolos das camadas inferiores devem prover este serviço, os quais, encapsulam os dados RTP (DOUSKALIS, 2000). A negociação das portas associadas ao RTP é feita dinamicamente pelo protocolo de sinalização, mas, tradicionalmente, à porta RTP é atribuído um número par e, a porta RTCP recebe o próximo valor (SCHULZRINNE et al., 2003). Se a porta RTP fosse de número 8000, a RTCP seria 8001. Figura 2.4: O pacote RTP. 2.4.2 RTP Control Protocol (RTCP) O RTCP, também especificado na RFC 3550, é responsável pelo controle da transmis- são de dados em tempo real por meio do protocolo RTP. Este protocolo complementa o RTP nas suas funcionalidades, permitindo aos hosts participantes da transmissão receber relatórios de como os dados estão sendo recebidos em termos quantitativos. Desde a sua idealização na RFC 1889, este protocolo sofreu duas principais modifi- 5 Figura extraida de: http://java.sun.com/javase/technologies/desktop/media /jmf/2.1.1/guide/images/RTPRealTime2.gif. Acesso em 12/10/2009.
  • 38. 37 cações. A primeira modificação aconteceu no instante de tempo em que os pacotes RTCP são enviados. No modelo original, o tempo de envio não era otimizado, causando um overhead de pacotes RTCP quando existiam mais integrantes na transmissão. A segunda modificação aconteceu na fórmula que calcula o jitter dos pacotes. Como o jitter é um dado complexo de ser calculado, a equação foi aperfeiçoada possibilitando uma melhor exatidão no resultado. Este protocolo é baseado no envio periódico de pacotes de controle para todos os participantes da sessão, utilizando o mesmo mecanismo de comunicação dos dados. O protocolo da camada inferior (UDP) é responsável por fornecer a multiplexação dos dados e dos pacotes de controle, utilizando números de portas diferentes (LIMA, 2006). As quatro principais funções do protocolo de controle RTCP, conforme Schulzrinne et al. (2003) são: 1. Obter feedback da qualidade da transmissão de dados. Como o protocolo RTP é comumente utilizado para transmissões live streaming, que são sensíveis a muitas variáveis, esta função é vital para obter um nível mínimo de qualidade na trans- missão. Esta função de feedback é proporcionada pelos sender e receiver reports, discutidos nas próximas seções. O presente trabalho analisa estas mensagens e re- aliza cálculos para se obter um feedback visual. 2. Portar identificação persistente. Os pacotes RTCP carregam uma identificação persistente ao nível de tranporte chamada de CNAME (canonical name). Enquanto que o identificador de fonte de sincronização (SSRC) pode mudar, devido à falhas de software ou de conexão, o CNAME deverá ser o mesmo ao longo de toda uma sessão. 3. Enviar pacotes RTCP. Para que as duas funções anteriores possam funcionar, é necessário que cada um dos participantes da sessão enviem pacotes RTCP. Mas, para que o sistema possa acomodar crescimento em grandes escalas, é necessário que esta taxa seja controlada. Como cada um dos participantes envia seus pacotes RTCP, eles também recebem e podem saber o número de participantes na sessão. Este valor é utilizado para se calcular o tempo de envio de cada pacote RTCP. 4. (Opcional) Controle dos participantes da sessão. A RFC 3550 ainda cita a cober-
  • 39. 38 tura mínima de uma sessão, como o descobrimento do nome dos participantes, con- forme entram e saem. Esta função seria interessante numa audioconferência na qual não se tem controle da entrada dos participantes. Este passo é opcional, pois é necessário ter um protocolo na camada superior a esta. A especificação (SCHULZRINNE et al., 2003) define cinco tipos de pacotes RTCP: 1. SR (Sender report): responsável pelo envio e recebimento de estatísticas rela- cionadas à transmissão de cada um dos participantes são emissores ativos. Este pacote é analisado pelo presente trabalho para coletar as estatísticas, e é possível visualizá-lo na figura 2.5 6 . Neste pacote, é apresentado uma das informações cru- ciais para a análise da aplicação, o campo fraction lost. Este campo apresenta o valor de perda de pacotes relativo com base de 256, ao invés de 100. Isto ocorre, pois é dedicado um byte para o armazenamento desta informação. 2. RR (Receiver report): responsável pela recepção de estatísticas relacionadas à transmissão de cada um dos participantes que não são emissores ativos. É possível visualizar este pacote na figura 2.6 7 . 3. SDES (Source Description): pacotes compostos de zero ou mais blocos, sendo que cada bloco é preenchido pelos itens que o definem. Estes itens incluem o identifi- cador SSRC, e itens de descrição, incluindo o CNAME. 4. BYE: indica o fim da sessão. 5. APP: realiza funções específicas de alguma aplicação que o implemente. O fluxo de pacotes RTCP, não deve exceder 5% da largura de banda dedicada para as transmissões live streaming. Para isso, é aplicado um algoritmo determinístico para cal- cular o tempo de envio dos pacotes RTCP. Para maiores informações sobre como calcular o tempo de envio, consultar Schulzrinne et al. (2003). 6 Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- ments/images/rtcp_sr_header.jpg. Acesso em 13/10/2009. 7 Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- ments/images/rtcp_rr_header.jpg. Acesso em 13/10/2009.
  • 40. 39 Figura 2.5: O tipo de pacote sender report, do protocolo RTCP. 2.5 Protocolo para Feedback : ICMP O ICMP, especificado na RFC 792, é um protocolo criado para ser rodado em todos os hosts e roteadores para comunicar informações da camada de rede. Este protocolo é considerado parte integrando do protocolo IP, mas ao analisar sua arquitetura, é possível verificar que este é encapsulado pelo IP, conforme Kurose e Ross (2006). Em 1981, este protocolo foi especificado pelo DARPA (AGENCY, 1981a) como parte integrante do IP, pois permitia o fornecimento de feedback da conectividade IP. Ele ape- nas existe, pois uma rede IP não é considerada confiável. Por ser um protocolo de fun- cionamento bastante simplificado, evoluiu apenas com extensões, mas sua especificação original se manteve intacta ao longo de quase 30 anos. Este protocolo atua enviando mensagens de um emissor para um receptor, sendo que este receptor deve enviar uma resposta, se for tiver conectividade. No cabeçalho desta mensagem além dos dados do protocolo IP, estão disponíveis o tipo e o código da men- sagem. Existe uma grande combinação de tipos e códigos de mensagem para ser utilizado, portanto na tabela 2.1 é apresentado os tipos mais comuns. Para ver todos os tipos, con-
  • 41. 40 Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP. sulte a especificação do protocolo ICMP, Agency (1981a). Existem duas aplicações bastante difundidas que utilizam o ICMP como base, o Ping e o Traceroute. O Ping é uma aplicação em que é possível se verificar a conectividade da rede. Além disso, é possível mensurar o tempo em que o pacote demora para ir e voltar ao host de destino, desprezando-se perdas decorrentes de processamento do host e atraso da propa- gação elétrica. Esta aplicação funciona enviando para um receptor um pacote contendo um tipo de mensagem 8 (solicitação de eco) e código 0. O pacote trafega ao longo da rede, e ao chegar no host de destino, ele desencapsula o pacote, verifica a mensagem e envia uma outra mensagem contendo ambos tipos e códigos da mensagem com o valor 0 para o emissor original. Se fosse contado o tempo que o pacote levou para ir e voltar para o host que enviou a solicitação de eco, seria possível mensurar o atraso de ida e volta dos pacotes, ou o round-trip delay. Da mesma forma que o Ping utiliza o ICMP, o Traceroute também o utiliza para de- scobrir o caminho que um pacote percorre para se atingir um destino e o tempo decorrente. Para descobrir estes dados, um roteador de origem envia para o primeiro roteador um pa- cote ICMP com TTL (time to live) 1, para o segundo roteador um pacote ICMP com TTL 2, e assim sucessivamente até o enésimo roteador. Além disso, é executado tem- porizadores para cada um destes pacotes. Quando o enésimo pacote chega ao enésimo
  • 42. 41 Tipo de mensagem ICMP Código Descrição 0 0 resposta de eco 3 0 rede de destino inalcançável 3 1 host de dedestino inalcançável 3 2 protocolo de destino inalcançável 3 3 porta de destino inalcançável 3 6 rede de destino desconhecida 3 7 host de destino desconhecido 4 0 redução da fonte (controle de congestionamento) 8 0 solicitação de eco 9 0 anúncio do roteador 10 0 descoberta do roteador 11 0 TTL expirado 12 0 cabeçalho IP inválido Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a descrição. roteador, este roteador verifica que o TTL expirou, e seguindo as regras do protocolo IP, o roteador descarta o pacote e responde a mensagem com uma mensagem ICMP de TTL expirado, ou tipo de mensagem 11, código 0. Esta mensagem inclui o nome do roteador e seu endereço IP. Quando esta mensagem chegar ao emissor ele poderá parar o tempo- rizador, obter o tempo que levou para cada um destes pacotes ir e voltar até os enésimos roteadores, e obter o nome de cada um deles (KUROSE; ROSS, 2006). Os protocolos de rede apresentados até esta seção foram utilizados na definição das técnicas de medição das métricas de desempenho de QoS. No entanto, para conceber o protótipo são necessárias técnicas de engenharia de software. Neste contexto, surge a necessidade de se utilizar o padrão de arquitetura MVC, que será apresentado na próxima seção. 2.6 Padrão de Arquitetura: MVC O padrão Model View Controller, mais conhecido como MVC, é um padrão de ar- quitetura utilizado para se desassociar a lógica do negócio, o acesso aos dados, e a apre-
  • 43. 42 sentação e interação do usuário. Com o MVC é possível aliar um desenvolvimento ágil com um baixo acoplamento, isolando a lógica do modelo visual, e realizando a interco- municação por meio do controlador. (MICROSYSTEMS, 2008). Originalmente, este padrão surgiu para a linguagem de programação SmallTalk, que é uma linguagem de programação puramente orientada à objetos. Para mais informações sobre o SmallTalk e orientação à objetos ver LaLonde (2008). O autor pioneiro que realizou a implementação no SmallTalk foi Trygve Reenskaug. Devido a aprovação que teve este padrão, hoje em dia é um dos mais conhecidos para organização de arquitetura para sistemas interativos (BUSCHMANN et al., 1996). Atualmente, este padrão para a engenharia de software é utilizado em linguagens baseadas no paradigma orientado à objetos, pois aplicações que contém os códigos de acesso à dados, códigos da lógica do negócio e códigos de apresentação misturados, são difíceis de manter. O problema existe, pois a interdependência entre os componentes causa um forte efeito ripple, portanto uma pequena mudança no código pode afetar toda a aplicação. O alto acoplamento torna quase impossível a reutilização dos componentes, pois eles dependem uns dos outros (MICROSYSTEMS, 2008). Ao utilizar este padrão, é possível criar diferentes visualizações sem afetar a integridade dos dados, como é possível visualizar na figura 2.7. Figura 2.7: Apresentação de diversas visualizações possíveis por causa do MVC, sem alterar a integridade dos dados de negócio (BUSCHMANN et al., 1996). O papel de cada uma das partes da modelagem é apresentado nos itens a seguir, con- forme MicroSystems (2008):
  • 44. 43 1. Model: Representa os dados da corporação e as regras de negócios. Muitas vezes, serve como uma aproximação do software com o processo do mundo real. 2. View: Renderiza o conteúdo de um modelo (Model). Esta parte acessa os dados por meio de um modelo e especifica como estes dados deverão ser apresentados. Também, é responsabilidade do View manter a consistência na apresentação quando os dados forem alterados. 3. Controller: Traduz as interações do View em ações para ser efetuadas no Model. Numa interface gráfica, interações poderiam ser clicks e numa aplicação Web pode- riam ser requisições. Com base nas interações do usuário e no resultado das ações é responsabilidade do Controller apresentar a View correta. A figura 2.8 apresenta visualmente o papel das partes e seus relacionamentos. Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma das partes que compõem o padrão MVC (MICROSYSTEMS, 2008). O protótipo da aplicação utilizará como base este padrão de arquitetura para a mode- lagem do sistema.
  • 45. 44 2.7 Síntese do capítulo Neste capítulo foram abordados os conceitos necessários para o desenvolvimento do protótipo. Primeiro, foi apresentado que streaming e live streaming são conceitos de transmissão de dados. Então, foi apresentado os fatores que influenciam nas transmissões live streaming (atraso, jitter, perda de pacotes e largura de banda), e constatado que as transmissões em tempo real possuem limiares que não podem ser ultrapassados para não terem perdas perceptíveis em sua qualidade: 150 ms para atraso unidirecional, 30 ms para jitter, 5 % para perda de pacotes e largura de banda para comportar as informações da transmissão que trafegam no enlace. Na próxima seção, foi abordado o protocolo SIP, seu funcionamento, as mensagens importantes no estabelecimento da sessão relevantes para este trabalho (SIP INVITE e SIP BYE) e as funções dos dispositivos SIP numa rede. Em seguida, foi apresentado os protocolos de transporte RTP e RTCP, que realizam a transmissão e seu controle. Com relação ao protocolo RTCP, destaca-se a mensagem sender report que consta o campo fraction lost, utilizado para se obter a perda de pacotes. Na seção seguinte, foi apresentado o protocolo ICMP que foi utilizado para se descobrir o atraso de ida e volta. Por fim, foi abordado o padrão de arquitetura MVC, que permitiu isolar a lógica da visualização, permitindo um baixo acoplamento no desenvolvimento. No próximo capítulo será abordada a metodologia que foi seguida para a conclusão deste trabalho.
  • 46. 45 3 METODOLOGIA DE DESENVOLVIMENTO Neste capítulo são abordadas as etapas necessárias para o desenvolvimento do pro- tótipo. A metodologia deste trabalho foi constituída em 5 (cinco) etapas: ambiente de de- senvolvimento, requisitos, técnicas, modelagem e implementação. Foi organizada desta maneira, pois permite isolar cada um dos passos metodológicos por áreas de criação. Na primeira seção é descrito o ambiente no qual foi utilizado em todo decorrer da metodologia. Em seguida, alinhado aos objetivos e a idealização do protótipo são de- scritos os requisitos. Na próxima seção, são propostas as técnicas de obtenção das métri- cas de desempenho de QoS. Então, é feita a modelagem do protótipo com base no padrão MVC. Por fim, com base nos pacotes e classes criados na modelagem, o protótipo é im- plementado e codificado. 3.1 Ambiente de Desenvolvimento Para suportar todas as etapas da metodologia, foi necessário estabelecer um ambiente de desenvolvimento. Nesta seção é descrito as partes que compõem este ambiente: as ferramentas para desenvolvimento e os dispositivos físicos numa rede. 3.1.1 Ferramentas A utilização do padrão de arquitetura MVC na concepção do protótipo, e a utilização 1 da linguagem de programação Java permitiu o uso de ferramentas para programação 1 O Java é uma inguagem de programação orientada à objetos criada pela Sun Microsystems. Mais informações: http://java.sun.com/. Acesso em 26/11/2009.
  • 47. 46 orientada à objetos. Por meio de duas ferramentas foi possível desenvolver a parte lógica e a parte gráfica do protótipo. A lógica do protótipo foi criada com a ferramenta Eclipse 2 , enquanto que a parte gráfica foi concebida com a NetBeans 3 . A utilização da ferramenta NetBeans facilitou na criação das interfaces gráficas, pois é possível conceber a interface visualmente. Após sua criação, o código fonte gerado era copiado para a ferramenta Eclipse permitindo a integração com a lógica do protótipo. Esse desenvolvimento segmentado foi possível pela utilização do padrão MVC, isolando a parte lógica da gráfica. Além das ferramentas Eclipse e NetBeans, foram utilizadas duas bibliotecas de pro- 4 gramação para Java: JpCap e JFreeChart 5 . A JpCap é uma biblioteca que permite a captura e o envio de quadros e pacotes de rede, enquanto que a JFreeChart, é uma bib- lioteca, que permite a criação, geração e atualização de diferentes tipos de gráfico em tempo real. 3.1.2 Dispositivos Para se desenvolver o protótipo, além das ferramentas, foram utilizados dispositi- vos de rede. O propósito destes dispositivos foi simular a execução de uma aplicação live streaming. Uma aplicação VoIP foi escolhida em função de sua crescente utilização por parte de usuários domésticos e corporativos. Além disso, a existência de farta doc- umentação e aplicativos VoIP gratuitos também contribuiu para a escolha desse tipo de aplicação (transporte de voz digital). Neste ambiente foram utilizados 03 (três) hosts físicos interconectados por um switch. Foram utilizadas duas estações de trabalho, que executaram softphones, um servidor que 2 O Eclipse além de uma ferramenta é toda uma comunidade que visa a criação de plataformas de código- aberto para todo ciclo de vida do software. Ela esta disponível em http://www.eclipse.org. Acesso em 26/11/2009. 3 Criada pela Sun MicroSystems, o NetBeans é uma plataforma para desenvolvimento em Java que pos- sui bastante funcionalidade para criação de aplicações gráficas. Disponível em: http://www.netbeans.org. Acesso em 26/11/2009. 4 A biblioteca JpCap, para captura e envio de pacotes, é disponibilizada gratuitamente em: http://netresearch.ics.uci.edu/kfujii/ jpcap/doc/index.html. Acesso em 23/10/2009. 5 A biblioteca JFreeChart, para criação de gráficos, pode ser obtida gratuitamente em: http://www.jfree.org/jfreechart/. Acesso em 23/10/2009.
  • 48. 47 executou o gateway server Asterisk e um switch. A topologia de redes utilizada é apre- sentada na figura 3.1. Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de pré- teste. Na figura 3.1, é possível verificar que cada máquina recebeu um identificador numérico. Orientado por estes identificadores, nas próximas seções é apresentado as especificações de hardware e software de cada uma das máquinas. 3.1.2.1 Máquina 1 Esta máquina atuou como uma estação de trabalho comum, atendendo às ligações feitas pela máquina 3. Nela foi instalado um softphone convencional que permitisse, unicamente, receber chamadas VoIP. 1. Especificações de hardware: (a) Processador: Intel Pentium 4 HT, 3.0 Ghz; (b) Memória RAM: 512 MB; (c) Armazenamento: 160 Gb; (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: Windows XP SP2 32 bits; (b) Softphone instalado: SJPhone 1.60 6 . 6 A aplicação SJPhone possui uma versão grátis para Windows, disponível no endereço: http://www.sjlabs.com/sjp.html. Acesso em 08/10/2009.
  • 49. 48 3.1.2.2 Máquina 2 Esta máquina foi responsável por executar o gateway server para as ligações VoIP, por meio da aplicação Asterisk. Este dispositivo fez a sinalização via protocolo SIP para as outras duas estações. Foi utilizado uma solução que instala um servidor PBX-IP com- pleto, simplificando a tarefa de instalação e configuração. 1. Especificações de hardware: (a) Processador: Intel Pentium 3, 1.1 Ghz; (b) Memória RAM: 512 MB; (c) Armazenamento: 20 Gb; (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: CentOS 5.3 Final 32 bits; (b) Aplicação instalada: Solução TrixBox 2.6.18 que roda Asterisk 1.4.17. 3.1.2.3 Máquina 3 Essa máquina foi responsável por originar as ligações VoIP para a máquina 1. Além disso, ela foi utilizada para coletar os pacotes transmitidos através do uso de uma fer- ramenta específica para esse fim. A fim de tornar possível essa operação, a interface Ethernet dessa máquina teve que ser colocada em modo promíscuo 7 . 1. Especificações de hardware: (a) Processador: Intel Core 2 Duo, 1.8 Ghz; (b) Memória RAM: 2 GB; (c) Armazenamento: 100 Gb; 7 O modo promíscuo é um tipo de configuração de recepção na qual todos os pacotes que trafeguem pelo segmente de rede que a estação está conectada são capturados. Em funcionamento normal, ela receberia apenas os pacotes endereçados a ela, mas em ambiente onde são utilizados repetidores e hubs é possível utilizar o modo promíscuo para capturar dados (KUROSE; ROSS, 2006)
  • 50. 49 (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: Windows Vista Ultimate 32 bits; (b) Softphone instalado: SJPhone 1.60. (c) Ferramenta de captura e análise de dados instalada: WireShark 1.2.2 8 . 3.2 Requisitos Para conceber o protótipo, foi necessário mapear as funcionalidades que deveriam estar presentes. Tanto as funcionalidades funcionais quanto as não-funcionais deveriam ser pontuadas, não deixando nada em aberto, ou implícito. Após a seção da proposta de técnicas para medição das métricas de desempenho, é feita uma análise dos requisitos, modelando-os de forma a constituir o protótipo. Os requisitos foram mapeados por meio dos objetivos do trabalho. Foram acompan- hados de identificadores permitindo o apontamento à eles nas futuras seções do trabalho. Eles são apresentados a seguir. 1. REQ01: Permitir a escolha de uma interface de rede a ser monitorada. 2. REQ02: Detectar automaticamente o início e o fim do tráfego live streaming RTP. 3. REQ03: Suportar pelo menos o protocolo de sinalização SIP. 4. REQ04: Monitorar os fatores que afetam as transmissões live streaming: largura de banda, atraso, perda de pacotes e jitter. 5. REQ05: Monitorar cada stream em uma tela. 6. REQ06: Monitorar em tempo real o tráfego. 7. REQ07: Apresentar os dados monitorados por meio de gráficos. 8. REQ08: Persistir os dados em disco em forma de log. 8 A ferramenta WireShark é livre, e ela pode ser obtida no endereço: http://www.wireshark.org/. Acesso em 20/10/2009.
  • 51. 50 9. REQ09: A topologia da rede não deve ser alterada para que funcione a ferramenta. 3.3 Técnicas Para se desenvolver técnicas de medição para as métricas de desempenho de QoS, foi necessário: (1) realizar uma captura de pacotes no ambiente de desenvolvimento, (2) analisar os dados capturados identificando certos eventos ou atributos e (3) propor as técnicas. A simulação feita, para que fosse capturado os pacotes necessários, foi proposta da seguinte maneira. 1. Foi iniciada a ferramenta de captura de pacotes; 2. Foi feita uma tentativa de ligação VoIP partindo do dispositivo 3 para o 1; 3. O dispositivo 2 fez o intermédio desta tentativa, por meio da aplicação Asterisk. Nesta etapa o softphone do dispositivo 1 começa a tocar; 4. No momento em que o dispositivo 1 atendeu a ligação, foi enviada uma mensagem SIP para que uma sessão fosse estabelecida; 5. A transmissão live streaming RTP foi iniciada; 6. Foram capturados pacotes SIP, RTP, RTCP ao longo de 30 segundos, por meio da ferramenta WireShark; 7. Após 30 segundos, o dispositivo 3 finalizou a comunicação. Consequentemente, o dispositivo 3 enviou uma mensagem SIP que corresponde ao término da sessão; 8. O dispositivo 1 ao receber mensagem, enviou um acknowledge e a transmissão finalizou; 9. A ferramenta WireShark foi parada; 10. Os dados gerados por esta ferramenta foram analisados. Nestes 30 segundos capturados, a ferramenta capturou mais de 3.000 (três mil) pa- cotes. Seria inviável analisar um a um, portanto foi buscado analisar pacotes que possuam
  • 52. 51 algum atributo específico, ou tenham relação com algum evento de rede. Esta análise bus- cou pacotes que fossem relevantes para a criação das técnicas de medição e para a lógica do protótipo. Cada um dos eventos e atributos buscado analisar são apresentados a seguir. 1. Protocolo SIP: Por meio deste protocolo, foi possível obter dados relacionados à sessão estabelecida entre as partes da transmissão. Foram buscadas as mensagens e parâmetros que contivessem o início, término e identificação das sessões. (a) Início da transmissão: Quando um pacote com o tipo de mensagem INVITE era enviado, verificou-se o fluxo de informações que precede o início de uma transmissão live streaming. A mensagem que identifica o início da transmis- são, além de ser do tipo SIP INVITE, possui ainda dados do protocolo SDP, que identifica o início de uma sessão. Esta mensagem identifica o início da sessão, possibilitando a obtenção de dados de porta em que é iniciada a trans- missão live streaming, via protocolo RTP; e do identificador da sessão. (b) Identificação de sessões: No item anterior, foi mencionada a mensagem na qual deve ser monitorada, de modo a obter o identificador da sessão. Toda sessão possui um identificador único gerado com base num identificador randômico de criptografia (ROSENBERG et al., 2002). Este campo é o mesmo em todos os pacotes de manutenção de uma sessão SIP. O nome deste campo no pacote SIP é Call-ID. (c) Fim da transmissão: Da mesma forma que o protótipo precisa saber o início e o identificador da sessão, também é necessário descobrir quando uma trans- missão é finalizada. Desta forma, o tipo de mensagem SIP BYE foi analisado. 2. Protocolo RTCP: Este protocolo apresenta dados de controle da transmissão, porém foi analisado apenas um relatório contido nesta mensagem, o sender report. O campo analisado foi o da taxa de perdas de pacotes. (a) Taxa de perdas de pacotes: Valor que expressa a taxa na qual pacotes estão sendo perdidos na rede. Este valor é expresso em porcentagem, mas não como base 100, e sim base 256. Para obtenção, foi analisado o campo fraction loss. 3. Protocolo RTP: O protocolo RTP realiza o transporte dos dados da transmissão
  • 53. 52 live streaming. Portanto, o único dado que foi monitorado é o tamanho dos pacotes da transmissão. (a) Tamanho de cada pacote para contabilização: Como no pacote RTP trafegam dados de transmissão, a única análise feita neste protocolo foi da quantidade de banda que cada fluxo em tempo real está ocupando do enlace em termos bytes/segundo. As transmissões são isoladas umas das outras, pois são multi- plexadas em portas UDP distintas. Na seção 2.2, foram analisados os quatro fatores que influenciam as transmissões em tempo real (largura de banda disponível, perda de pacotes, atraso, e buffer de com- pensação de jitter). Como um dos objetivos deste trabalho é medir os atributos de de- sempenho de uma transmissão em tempo real, com base nas variáveis identificadas nos itens anterior, foram propostas técnicas para que sejam coletadas métricas de desempenho de QoS. No contexto deste trabalho, cada um destes fatores recebeu, respectivamente, o nome: tráfego RTP, perda de pacotes, atraso e jitter. O método utilizado para a medição de cada uma das métricas de desempenho é apre- sentado apresentado nas seções seguintes. 3.3.1 Tráfego RTP O objetivo da monitoração do tráfego RTP foi obter a largura de banda utilizada pela transmissão live streaming RTP por segundo. Para isso, foram contabilizados os pacotes RTP e RTCP. A unidade desta medida é bytes/segundo. A técnica proposta é apresentado a seguir. 1. Captura pacote da rede. 2. Verifica se o pacote é RTP ou RTCP. 3. Se sim, identifica qual transmissão está trafegando o pacote. Isto é feito identifi- cando a porta UDP. Quando é trafegado o pacote SIP INVITE, é obtida a porta na qual é trafegada a transmissão, conforme seção 2.3. 4. Obtém o tamanho do pacote.
  • 54. 53 5. Incrementa e/ou armazena o valor do tamanho do pacote. Apenas é armazenado o valor na primeira execução. Nas execuções subsequentes, é incrementado o valor da execução anterior com o valor atual. 6. Quando for o instante de tempo de obtenção da medida, aplica o seguinte algoritmo: (a) Atribui: ContagemNova = ContadorDePacotes; (b) Atribui: Resultado = (ContagemNova - ContagemAntiga) / tempoDeAtualiza- ção; (c) Atribui: ContagemAntiga = ContagemNova. 7. Conclui a operação. Por meio deste algoritmo, a largura de banda utilizada por segundo por uma transmis- são live streaming é obtida na variável Resultado. Além disso, este algoritmo é indepen- dente do tempo de obtenção dos dados para serem apresentados (tempoDeAtualização), portanto ao alterar o tempo de amostragem dos gráficos não será alterado o fluxo de exe- cução nem os valores obtidos por esta técnica. 3.3.2 Perda de Pacotes Ao monitorar a perda de pacotes, busca-se obter a taxa na qual os pacotes não con- seguem chegar ao seu destino, relativa ao número total de pacotes passados pela interface. Como esta é uma unidade relativa, ela é medida em porcentagem. Foi monitorada a perda de pacotes apenas nas transmissões live streaming RTP, e não em todo enlace. Este valor foi obtido ao monitorar os pacotes RTCP e verificar o campo fraction lost. Como este campo é composto de 1 byte, pode possuir 256 valores. Portanto, foi realizado uma con- versão para apresentar este valor como múltiplo de 100. O algoritmo que obtém a taxa de perda de pacotes é apresentado a seguir. 1. Captura pacote da rede. 2. Verifica se o pacote é RTCP. 3. Se sim, busca pelo byte 32 que contém o dado de perdas de pacotes e o atribui à variável PktLoss.
  • 55. 54 4. Aplica a equação 3.1, convertendo o dado para base 100. 100 P erdaDeP acotes = (3.1) 256 ∗ P ktLoss 5. Conclui a operação. A variável PerdaDePacotes apresenta o valor da perda de pacotes em porcentagem. 3.3.3 Atraso Para se calcular o atraso na entrega, foi necessário utilizar o protocolo ICMP. Este método envia uma requisição e contabiliza o tempo desde que ela sai do emissor até o recebimento de um retorno do receptor. O atraso obtido por meio desta técnica é o de ida e volta, ou round trip time. A unidade do atraso é milissegundos. 1. Inicia a contabilização de tempo. 2. Envia um pacote ICMP com tipo de mensagem 8 e código 0, a requisição de eco. O receptor deve responder com um pacote ICMP contendo um tipo de mensagem e código, ambos 0, indicando uma resposta de eco. 3. Para a contabilização de tempo. 4. Calcula a diferença entre o início da contabilização de tempo e o término. Esta diferença é o tempo em milissegundos que um pacote ICMP levou para ir e voltar do dispositivo emissor até o receptor. Este resultado é atribuído à variável PingResult. 5. Aplica o seguinte algoritmo: (a) Atribui: IcmpAntigo = PingResultAntigo. (b) Atribui: PingResultAntigo = PingResult. (c) Atribui: ResultadoFinal = (PingResultAntigo + ResultadoFinal) / 2 6. Conclui a operação.
  • 56. 55 Este algoritmo utiliza uma variável a mais, que não seria necessária para este algo- ritmo, porém ela é utilizada para o cálculo do jitter. A variável é IcmpAntigo. Além disso, como este algoritmo foi executado com maior frequência do que a taxa de amostragem dos dados nos gráficos, para se obter o atraso médio e não perder a exatidão na medição foi feita uma média da medição anterior com a atual, o que explica a divisão por 2 (dois) no algoritmo. 3.3.4 Jitter O valor do buffer de compensação de jitter foi obtido por amostragem. Para o cálculo desta métrica de desempenho, foram obtidas 30 amostras. A variação no atraso entre elas, o delta, foi calculado e incrementado. Após as 30 amostras terem sido obtidas, foi feito uma média destes deltas, obtendo o valor de jitter. As amostras utilizadas são as mesmas utilizadas na seção 3.3.3, para o cálculo do atraso na entrega. A unidade desta medição é em milissegundos. O algoritmo completo é apresentado a seguir. 1. Obtém amostra; 2. Incrementa o contador no número de amostras; 3. Verifica a contagem das amostras. Se for equivalente a 30, segue fluxo 3a do algo- ritmo. Caso contrário, segue fluxo 3b. (a) NúmeroDeAmostras = 30; i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |; ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta; iii. Atribui: Jitter = SomaDeDeltas / NúmeroDeAmostras; iv. Atribui: NumeroDeAmostras = 0; v. Atribui: SomaDeDeltas = 0; vi. Atribui: PingResultAntigo = 0; (b) NúmeroDeAmostras != 30; i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |;
  • 57. 56 ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta; iii. Atribui: Incrementa em 1 unidade NumeroDeAmostras; 4. Conclui a operação. A variável Delta possui a diferença entre o RTT dos pacotes ICMP. Mas é na variável Jitter, que é apresentado o resultado do tamanho do buffer de compensação de jitter. 3.4 Modelagem Esta etapa teve como objetivo produzir um modelo de classes que, somado às técnicas produzidas na seção anterior, foi possível realizar a codificação do protótipo na etapa seguinte. Neste trabalho foi modelado e desenvolvido o protótipo seguindo somente o padrão MVC, agilizando todo processo da concepção do protótipo. Como o foco deste trabalho não foi a engenharia de software, e sim a implementação das técnicas propostas medindo os atributos de desempenho de QoS numa rede, a modelagem foi simplificada. Para ver mais sobre modelagem e engenharia de software, consultar Larman (2007). Por utilizar o padrão de arquitetura MVC, a modelagem teve agilidade, facilidade e modularidade. Também por utilizar este padrão, a modelagem foi orientada à objetos, uti- lizando classes. Estas classes possuem lógicas associadas às funcionalidades do protótipo. As classes, suas associações e interconexões resultaram no protótipo. Ao analisar os requisitos, as técnicas criadas para obtenção de métricas de desem- penho, e as bibliotecas utilizadas para a linguagem de programação Java, verificou-se a necessidade de englobar os requisitos em agrupamentos de funcionalidades. Os agrupa- mentos e os requisitos atendidos por cada um deles são apresentados a seguir - foram adicionados identificadores para referenciar os agrupamentos ao longo do trabalho. 1. AF01 - Captura de Pacotes RTP/RTCP e SIP: Neste agrupamento foram incluí- dos todos os protocolos nos quais são capturados pacotes. Como os protocolos RTP e RTCP foram utilizados por duas das técnicas de medição, optou-se por isolá-los como um agrupamento de funcionalidade. Além disso, foi necessário capturar da- dos do protocolo SIP, portanto ele também está incluído neste agrupamento. Os requisitos englobados por este agrupamento são:
  • 58. 57 (a) Parte do REQ01: A biblioteca de captura de pacotes permite a captura em apenas uma interface. Desta forma, contribui para atingir este requisito. (b) REQ02: O tráfego live streaming é detectado automaticamente por meio do protocolo SIP. (c) REQ03: O protocolo SIP é suportado. (d) Parte do REQ04: Por meio dos protocolos RTP e RTCP é possível obter dois dos dados que são monitorados: tráfego RTP e perda de pacotes. (e) Parte do REQ06: Como a captura e o cálculo devem ser em tempo real para serem apresentados no gráfico, parte deste requisito é atendido com este agru- pamento. 2. AF02 - Monitoramento ICMP: O protocolo ICMP é utilizado pelas outras duas técnicas de medição das métricas de desempenho de QoS, portanto foi dedicado um agrupamento de funcionalidade para este protocolo. Os requisitos atendidos por este agrupamento são: (a) Parte do REQ01: Como o monitoramento ICMP é feito num endereço IP da interface escolhida, este agrupamento contribui para o atendimento deste requisito. (b) Parte do REQ04: Com este agrupamento, é possível medir o tamanho do buffer de compensação de jitter e o atraso no enlace. Somando as funcional- idades obtidas com o agrupamento AF02, este requisito é atendido por com- pleto. (c) Parte do REQ06: Os dados são monitorados em tempo real, tanto a captura quanto o cálculo. 3. AF03 - Gráficos: Este agrupamento agrupa a parte do protótipo responsável por exibir as informações de maneira visual. Ele engloba toda a parte de criação, manutenção e atualização dos gráficos. Também, neste agrupamento está contida a biblioteca para manipulação de gráficos. Os requisitos atendidos são apresentados a seguir. (a) REQ05: São criadas novas telas com gráficos conforme novas transmissões live streaming forem iniciadas.
  • 59. 58 (b) Parte do REQ06: Os outros agrupamentos englobavam a parte lógica do mon- itoramento em tempo real. Com este agrupamento, a parte visual é atendida, concluindo este requisito. (c) Parte do REQ07: Este agrupamento engloba a geração, manutenção e atual- ização dos gráficos, faltando apenas a parte de exibição. 4. AF04 - Interface Gráfica: Foi verificado que existe a necessidade de apenas duas telas: a de escolha de interface e a de exibição dos gráficos. Neste agrupamento estão contidas as interfaces gráficas do protótipo. Os requisitos atendidos são apre- sentados a seguir. (a) Parte do REQ01: Por meio deste agrupamento, e dos agrupamentos de AF01 e AF02, este requisito é atendido. (b) Parte do REQ07: Como este agrupamento engloba a exibição dos gráficos, em conjunto do agrupamento de gráficos, este requisito é atendido. 5. AF05 - Persistência: Além de monitorar e exibir as métricas que afetam as trans- missões live streaming, o protótipo deve realizar a persistência em disco, possibil- itando a futura análise e/ou geração de gráficos offline. Este agrupamento atende apenas a um requisito, de modo que foi criado unicamente com este objetivo. O requisito atendido é o REQ08. O REQ09 foi o único que ficou fora desta lista, pois não se trata de um requisito funcional do protótipo, e sim não-funcional. A necessidade do protótipo executar sem alterar a topologia de rede, foi um requisito que não poderia ser implementado, e sim planejado. Como este requisito foi uma premissa, foi necessário planejar a arquitetura sempre verificando se esta premissa estava sendo atendida. Cada um dos agrupamentos de funcionalidades foi analisado, buscando primeiro re- duzir o nível de abstração para o de pacotes, para então chegar nas classes de progra- mação. Como foi seguido o padrão de arquitetura MVC, foi buscado o isolamento do modelo, da visualização e do controlador. Foi possível verificar que AF01 - Captura de Pacotes RTP/RTCP e SIP, e AF02 - Monitoramento ICMP foram responsáveis por aten- der os requisitos cruciais do protótipo. Nestes agrupamentos está contido o núcleo do
  • 60. 59 protótipo, a lógica. Destes dois agrupamentos foi criado o pacote Model. Por outro lado, os agrupamentos AF03 - Gráficos e AF04 - Interface Gráfica são responsáveis pelos req- uisitos responsáveis pela parte visual e gráfica. Seguindo as diretivas do MVC, estes dois agrupamentos foram unidos no pacote View. O agrupamento final, AF05 - Persistência, não possui um tipo definido no padrão MVC, então foi criado um pacote a parte, chamado Extra. Na figura 3.2 é possível visualizar a organização de pacotes proposta. Figura 3.2: Diagrama da organização de pacotes por agrupamento de funcional- idades. Como foi buscado a redução no nível de abstração para o de classes de programação, foram utilizados os pacotes definidos no parágrafo anterior como ponto de partida para a elaboração do modelo de classes de projeto. O protótipo deve fazer a coleta de dados do ambiente, processar e atualizar os valores no gráfico. As tarefas de coleta e processa- mento foram unidas num único componente lógico, a Thread, enquanto que a tarefa de atualizar o gráfico foi de responsabilidade de outro componente, o Querier. No pacote Model, foram compreendidos dois pares Thread e Querier, um para o agrupamento AF01 - Captura de Pacotes RTP/RTCP e SIP e outro para o AF02 - Monitoramento ICMP. No pacote View, a redução no nível de abstração segmentou o agrupamento AF04 - Interface Gráfica em duas classes. A classe GuiInicial se tornou responsável pela exibição da tela inicial da aplicação, na qual é feita a escolha da interface a ser monitorada. A outra classe, GuiSmb, iniciou e terminou ao passo que as transmissões live streaming RTP iniciaram e terminaram. O agrupamento AF03 - Gráficos se transformou em apenas
  • 61. 60 uma classe, Gráfico. O pacote Extra, continha apenas um agrupamento de funcionalidades, AF05 - Per- sistência. Este agrupamento já é o de menor nível de abstração, portanto, se tornou uma classe de mesmo nome. A classe Controller realiza a intercomunicação entre todas as partes. Na figura 3.3 é possível verificar o novo diagrama com um nível menor de abstração, agora apresentando o modelo de classes do projeto. Figura 3.3: Diagrama do modelo de classes do projeto. Com base neste modelo é que foi feita a implementação de cada uma das funcionali- dades, por meio das classes. A implementação é apresentada na seção seguinte. 3.5 Implementação Nesta seção é descrito desenvolvimento do diagrama de classes de projeto e a im- plementação do protótipo, que funcionará em três etapas: (1) identificação automática de tráfego RTP para verificação dos dados, (2) processamento e (3) apresentação visual da informação resultante na tela, isso tudo em tempo real. Foi com base nestas três etapas
  • 62. 61 que foi estruturado o fluxo lógico do protótipo. Como o modelo desenvolvido na fase an- terior englobava apenas as macro-partes do protótipo, e não previa os métodos e atributos das classes, esta fase buscou, além de implementar o protótipo, desenvolver um modelo de classes de projeto completo. Para apresentar e estruturar a implementação, foi dedicada uma seção para cada um dos pacotes criados. Dentro de cada uma das seções que descrevem os pacotes, foi ap- resentado cada uma das classes, métodos principais e interações entre si, constituindo o protótipo. Os pacotes que o compõem são: Model, View, Controller e Extra. Na figura 3.4, é possível verificar o diagrama de classes completo produzido. Cada uma de suas partes é descrita nas seções a seguir. Figura 3.4: Diagrama de classes completo do protótipo. 3.5.1 Lógica - Model Este pacote engloba a parte lógica do protótipo, ou o Model do padrão MVC. O pacote Model é responsável por fazer a captura de pacotes RTP/RTCP e SIP e, também de realizar o monitoramento ICMP. A captura de pacotes e o monitoramento foram utilizados para
  • 63. 62 obter a medição dos seguintes itens: tráfego RTP, perda de pacotes, atraso na entrega dos pacotes e tamanho do buffer de compensação de jitter. Todos estes itens foram obtidos em tempo real, mas apresentados no gráfico com uma taxa de amostragem de 5 segundos, com exceção do jitter, que é apresentado no mínimo a cada 60 segundos (mais detalhes ver seção 3.3.4). Na seção 3.2, foram descritos os componentes Thread e Querier, responsáveis por, respectivamente, coletar e calcular dados, e atualizar o gráfico. Nos próximos itens, serão descritas as responsabilidades de cada uma das classes, e apresentado seu diagrama de classe respectivo. As classes responsáveis pela parte lógica são: ThreadPcap, QuerierP- cap, ThreadICMP e QuerierICMP. 1. Classe ThreadPcap: Esta classe é responsável pela captura de pacotes na rede, por meio da biblioteca JpCap. Como todo o tráfego de rede relevante ao trabalho utiliza o protocolo de transporte UDP, por meio da biblioteca utilizada foi filtrado somente este tipo de pacote. Logo, esta classe buscou capturar os pacotes contidos nos protocolos RTP, RTCP e SIP. Além da captura de pacotes, possui métodos que realizam a medição das métricas de desempenho para o tráfego RTP e a perda de pacotes. O método getPktBytes aplica a técnica que mede calcula a largura de banda utilizada pela transmissão live streaming analisada. Por outro lado, o método getPktLoss aplica a técnica que mede a perda de pacotes que incide na transmissão em tempo real RTP. A classe ThreadPcap utiliza o conceito de thread 9 , portanto executa em paralelo com o fluxo principal de execução. Diferentemente das classes responsáveis pelo monitoramento ICMP, em que são criadas n classes para n transmissões live stream- ing RTP, as classes responsáveis pela captura de pacotes possuem 1 classe para n transmissões. Isto ocorre, pois é possível criar apenas uma instância do objeto de captura de pacotes. Para armazenar os dados da captura de cada uma das transmis- sões, são utilizados vetores, como é possível ver na figura 3.5. Os dados armazena- dos nestes vetores são lidos pela classe QuerierPcap, por meio dos métodos getPk- 9 Uma thread é uma porção de código que executa em paralelo, concorrente ao fluxo principal da apli- cação. É utilizado para se dividir porções de processamento entre núcleos, num ambiente multiprocessado (DEITEL, 2004.
  • 64. 63 tBytes e getPktLoss, também apresentados na figura 3.5. Além disso, na figura 3.5, também é possível observar os atributos utilizados pela classe e os métodos, que em conjunto são responsáveis pela captura de pacotes RTP, RTCP e SIP e cálculo do tráfego RTP e perda de pacotes. Figura 3.5: Diagrama da classe ThreadPcap. 2. Classe QuerierPcap: Esta classe é responsável por consultar os dados obtidos pela classe ThreadPcap e atualizá-los no gráfico conforme o tempo de amostragem. Além disso, é respon- sável por atualizar os arquivos de log por meio da classe Persistencia. Também utiliza o conceito de thread, e diferentemente da classe ThreadPcap, são criadas n classes para n transmissões RTP. A classe QuerierPcap utiliza os métodos getPktBytes e getPktLoss da classe Thread- Pcap para obter os valores a serem atualizados no objeto gerado pela classe Grafico, do pacote View. Esta classe utiliza métodos da classe Grafico para poder atualizar os valores obtidos pelos métodos da classe ThreadPcap. Na figura 3.6, é apresentado o diagrama desta classe. Figura 3.6: Diagrama da classe classquerierpcap. 3. Classe ThreadICMP:
  • 65. 64 Esta classe é responsável pelo monitoramento de pacotes ICMP na rede, por meio do método nativo do Java System.isReachable. Ao monitorar o protocolo ICMP, esta classe tem como objetivo obter o tempo de ida e volta de um pacote na rede, e estimar o valor do buffer de compensação de jitter. Este protocolo foi utilizado pela facilidade e simplicidade, no entanto poderia ter sido utilizado o protocolo RTP. O protocolo ICMP para esta medição foi utilizado não aumentar a complexidade no desenvolvimento do protótipo. Como o par de classes da parte de captura de pacotes, esta classe utiliza o conceito de thread, mas são criadas n classes para n transmissões live streaming RTP. Os métodos principais para obtenção do RTT e do jitter são: pingerer e jitterer. Porém, a interação com a classe que atualiza o gráfico é por meio dos métodos getMillis e getJitter, que retornam os valores calculados pelos métodos citados anteriormente. Os métodos e atributos da classe podem ser vistos no diagrama, apresentado na figura 3.7. Figura 3.7: Diagrama da classe ThreadICMP. 4. Classe QuerierICMP: Esta classe é responsável por consultar os dados obtidos pela classe ThreadICMP e atualizá-los no gráfico conforme o tempo de amostragem. Além disso, é responsável por atualizar os arquivos de log por meio da classe Per- sistencia. Também utiliza o conceito de thread, e como a classe ThreadICMP, são criadas n classes para n transmissões RTP. A classe QuerierICMP utiliza os métodos getMillis e getJitter da classe Thread- ICMP para obter os valores a ser atualizado no objeto gerado pela classe Grafico,
  • 66. 65 do pacote View. Esta classe utiliza os métodos da classe Grafico para poder atualizar no gráfico os valores obtidos pelos métodos da classe ThreadICMP. Na figura 3.8, é apresentado o diagrama desta classe. Figura 3.8: Diagrama da classe QuerierICMP. O diagrama de classes completo do pacote Model é apresentado na figura 3.9. Figura 3.9: Diagrama de classes completo do pacote Model. 3.5.2 Interface gráfica - View Este pacote engloba a parte gráfica, ou o View do padrão MVC. O pacote Interface gráfica é responsável por intermediar as ações do usuário por meio de telas visuais. Tam- bém, é responsável por exibir os gráficos gerados pela parte lógica.
  • 67. 66 O protótipo compreende duas telas principais: a tela inicial e a tela dos gráficos. Na tela inicial são exibidas as interfaces de rede disponíveis para se executar o protótipo. Após a seleção, o protótipo aguarda pelo início de transmissões live streaming RTP. Quando uma transmissão é iniciada, é exibida a segunda tela, a tela dos gráficos. Esta tela é responsável por exibir graficamente cada um dos quatro parâmetros de desempenho de QoS. Não é responsabilidade deste pacote atualizar os dados, apenas permitir pontos de entrada para os dados possam ser adicionados. As classes compreendidas neste pacotes são: GuiInicial, GuiSmB e Grafico. Elas são detalhadas nos itens a seguir. 1. Classe GuiInicial: A classe GuiInicial é responsável por exibir a tela inicial. Nesta tela, é possível escolher a interface de rede e iniciar a execução do protótipo. Esta classe foi criada visualmente pela IDE (Integrated Development Environment) NetBeans, simplifi- cando a codificação. Após o criação da interface gráfica, o código fonte foi copiado para a outra ferramenta de desenvolvimento, Eclipse, e foi adicionado um método para se obter o objeto que identifica a interface de rede selecionada, o método getJ- Combo. Na figura 3.10, é apresentado o diagrama da classe. Figura 3.10: Diagrama da classe GuiInicial. 2. Classe GuiSmB: Esta classe é responsável pela exibição da tela dos gráficos. Nesta tela, são exibidos os gráficos gerados pela classe Grafico. Também criada pela IDE NetBeans de forma visual, teve a mesma dinâmica de desenvolvimento que a classe GuiInicial. Após sua criação, seu código fonte foi copiado para a ferramenta Eclipse. Nesta ferramenta, foi incluído um método na classe que permite adicionar um número identificador para cada transmissão monitorada, nomeado setStream. Na figura 3.11, é possível visualizar o diagrama da classe.
  • 68. 67 Figura 3.11: Diagrama da classe GuiSmB. 3. Classe Grafico: Esta classe é responsável pela criação e atualização dos gráficos em tempo de ex- ecução do protótipo. Isso é possível por meio da biblioteca JFreeChart permite a exibição, geração e atualização dos gráficos criados. Esta classe possui métodos para a criação de cada um dos tipos de gráficos necessários, e para a atualização de cada uma das métricas de desempenho tempo real. As duas classes que se comu- nicam com esta para atualizar os dados no gráfico são as classes do pacote Model: QuerierPcap e QuerierICMP. Na figura 3.12, é possível verificar os métodos por meio do diagrama da classe. Figura 3.12: Diagrama da classe Grafico. O diagrama de classes completo do pacote View é apresentado na figura 3.13. 3.5.3 Controlador - Controller Este pacote engloba a única classe que realiza intercomunicação entre a parte lógica e a parte gráfica. Também, é por meio do controlador que é definido o fluxo lógico de execução do protótipo. Neste pacote está compreendida a classe Controller que além de fornecer comunicação entre todas as partes do protótipo, é o ponto de execução inicial. A classe Controller possui o controle da execução do protótipo. Também, possui o controle de todas as transmissões live streaming em execução, permitindo identificar
  • 69. 68 Figura 3.13: Diagrama de classes completo do pacote View. quantas telas de gráficos devem ser executadas. Os identificadores das transmissões fi- cam persistidos no vetor vecCallId, e quantidade de transmissões em execução em num- Streams. Alem disso, a classe possui diversos vetores para controlar a quantidade de ob- jetos criados a partir das classes: GuiSmB, Grafico, QuerierPcap, ThreadICMP, Querier- ICMP. Por fim, esta classe possui métodos que agrupam a lógica necessária para quando uma transmissão é iniciada ou terminada: newStream e byeStream. A classe Controller, em seu pacote de mesmo nome, é apresentada na figura 3.14. Figura 3.14: Diagrama de classes completo do pacote Controller.
  • 70. 69 3.5.4 Extra Como um dos requisitos do protótipo era a persistência dos dados, foi criado o pa- cote Extra contendo apenas uma classe com esta funcionalidade. A classe Persistencia é responsável por persistir em arquivo um histórico dos dados apresentados na execução do protótipo. Esta classe armazena os valores de cada uma das métricas de desempenho em arquivos texto separados. São criados quatro arquivos para cada transmissão live streaming, identificados pelo número identificador da transmissão e o nome da métrica de desempenho medida. As classes QuerierPcap e QuerierICMP são responsáveis por alimentar este arquivo, conforme alimentam os gráficos. Os métodos utilizados por elas são: logRtpData, logPktloss, logDelay e logJitter. Na figura 3.15, é possível verificar o diagrama do pacote Extra, contendo a classe Persistencia. Figura 3.15: Diagrama de classes completo do pacote Extra. 3.6 Síntese do capítulo Neste capítulo foi abordada a metodologia utilizada neste trabalho, que foi organi- zada em cinco seções. Na primeira, foi abordado o ambiente de desenvolvimento que engloba: as ferramentas de desenvolvimento para a parte gráfica (NetBeans) e parte lóg- ica (Eclipse), as bibliotecas para captura de pacotes (Jpcap) e manutenção dos gráficos (JFreeChart) e os três hosts, sendo que um executou a aplicação Asterisk, outro um soft-
  • 71. 70 phone e o outro um softphone e a ferramenta de captura de pacotes (WireShark). Na segunda seção, foram pontuados os requisitos do protótipo, que vão desde a medição em tempo real dos fatores que afetam as transmissões live streaming, até a apresentação visual das informações. Na terceira seção, foi detalhado cada uma das técnicas para medição das métricas de desempenho de QoS. Para o tráfego RTP, foi utilizado a contabilização de pa- cotes; para perda de pacotes, a valor no campo fraction lost do protocolo RTCP; para o atraso, o protocolo ICMP; e para o jitter, uma técnica que fez amostragem via protocolo ICMP, para então efetuar o cálculo. Na quarta seção, foi feita a modelagem do protótipo, que aliada ao padrão MVC permitiu a criação de um diagrama de classes. Na quinta seção, com base no diagrama de classes criado na seção anterior, foi possível otimizar este diagrama e implementar o protótipo, descrevendo cada classe do trabalho. No próximo capítulo serão descritos os passos realizados na fase de experimentação da ferramenta, onde os requisitos desenvolvidos serão testados e avaliados em outro am- biente.
  • 72. 71 4 EXPERIMENTAÇÃO Nas próximas seções são apresentados os aspectos de experimentação do protótipo, os resultados obtidos, sua análise e discussão e um resumo do que foi apresentado. Primeira- mente, é apresentado a topologia de rede na qual é feito experimento com o protótipo. Na próxima seção, é descrito cada uma das etapas do experimento. Em seguida, são apre- sentados os dados obtidos pelo experimento, no ambiente proposto. Então, é discutido os resultados obtidos na seção anterior. Por fim, é feito um resumo de todos os aspectos abordados neste capítulo. 4.1 Ambiente de Experimentação O ambiente utilizado para a execução do experimento é semelhante ao descrito na seção 3.1. A diferença é que este ambiente deve ser controlado, por isso a topologia é constituida de máquinas virtuais. Foi possível simular este ambiente controlado por meio da ferramenta VMWare Workstation 61 . Para se executar as máquinas virtuais, foi necessário uma máquina hospedeira. A configuração da máquina hospedeira utilizada é: 1. Processador: Intel Centrino Core 2 Duo 1.8 Ghz 32 bits; 2. Memória RAM: 2 Gb. Para cada máquina virtual foi alocado 300MB; 3. Armazenamento: 100 Gb; 1 A ferramenta VMWare é utilizada para se virtualizar equipamentos. Pode ser obtida, na versão Server, no site do fabricante: http://www.vmware.com/. Acesso em 21/10/2009.
  • 73. 72 4. Rede: Wi-fi 54 Mbps. O ambiente de experimentação foi projetado com três dispositivos, sendo que dois foram simulados na máquina hospedeira e o terceiro foi a própria máquina hospedeira (neste trabalho, todos são chamados máquinas virtuais). Cada uma das três máquinas virtuais compartilham os mesmos recursos de hardware. Com base na figura 4.1, que apresenta a topologia de redes simulada por meio de máquinas virtuais, os dispositivos virtuais são detalhadas nas seções a seguir em termos de responsabilidade nos testes, sistema operacional (SO) e softwares instalados. Figura 4.1: Topologia de redes simulada que foi utilizada no ambiente de testes. 4.1.1 Máquina Virtual 1 Esta máquina virtual foi responsável por atuar como uma estação de trabalho, e é responsável por atender as ligações VoIP originadas pela máquina virtual 3. As especifi- cações de SO software são apresentadas abaixo: 1. Sistema Operacional: Ubuntu Desktop Linux 32 bits, versão 9.0.4; 2. Softwares: Softphone Twinkle 1.4.1 2 4.1.2 Máquina Virtual 2 Esta máquina virtual teve como responsabilidade sinalizar as ligações VoIP por meio do protocolo SIP entre as máquinas virtuais 1 e 3. As especificações de SO e software são 2 O softphone Twinkle está disponível para download no seguinte endereço: http://www.twinklephone.com/. Acesso em 21/11/2009.
  • 74. 73 apresentadas abaixo: 1. Sistema Operacional: CentOS 5.3 Final 32 bits; 2. Softwares: Solução TrixBox 2.6.18, que roda o gateway server Asterisk 1.4.17. 4.1.3 Máquina Virtual 3 Esta máquina virtual teve como responsabilidade efetuar as ligações VoIP para a máquina virtual 1. Além disso, foi nesta máquina virtual que houve a execução para a coleta de dados. As especificações de SO e software são apresentadas abaixo: 1. Sistema Operacional: Windows Vista Ultimate 32 bits; 2. Softwares: Softphone SJPhone 1.60 e o protótipo. 4.2 Experimento O experimento consistiu na execução do protótipo demonstrando cada um dos itens e telas desenvolvidas. Nesta seção, o protótipo foi executado no ambiente proposto na seção anterior, sendo descrito metodologicamente todos os detalhes da execução com base nas iterações feitas pelo usuário e/ou protótipo. Para que o experimento realizasse a medição com sucesso e para que os dados re- sultantes pudessem ser obtidos com precisão, foram definidas cinco execuções de dois minutos cada. Todos os dados obtidos ao longo destes dois minutos são abordados na seção (4.3). A execução do experimento necessitou de uma interação de um usuário com o pro- tótipo. Portanto, este é apresentado em termos de iterações do usuário e aplicação. Neste experimento, pressupõe-se que existam usuários utilizando as máquinas virtuais 1 e 3. Nos próximos itens, é apresentado e detalhado cada uma das etapas do experimento. 1. IT01: Inicia-se o protótipo. Como foi desenvolvido em Java, e esta linguagem de programação possui uma IDE de desenvolvimento, o protótipo foi iniciado pela própria ferramenta. Ao iniciar a
  • 75. 74 execução, é exibida a interface gráfica inicial, conforme pode ser visto na figura 4.2. Nesta tela, o usuário escolhe a interface de rede que são monitoradas as métricas de desempenho de QoS. Figura 4.2: Interface gráfica inicial do protótipo. 2. IT02: O usuário define a interface de rede a ser monitorada. Nesta iteração, o usuário escolhe numa lista de interfaces de rede disponíves no sistema, qual que deve ser monitorada pelo protótipo. Como o protótipo está sendo executado na máquina hospedeira, é escolhida a interface que comunica com as máquinas virtuais: VMware Virtual Ethernet Adapter (selecionada na figura 4.3). Figura 4.3: Interfaces de rede disponíveis para execução do protótipo. 3. IT03: O usuário inicia a monitoração por meio do botão Iniciar. Ao clicar no botão Iniciar, o protótipo fica em espera, aguardando por uma trans- missão live streaming RTP. Enquanto não for iniciada uma transmissão RTP, o pro- tótipo não avança para a próxima tela, a de exibição dos gráficos. 4. IT04: O usuário na máquina virtual 3 inicia uma ligação VoIP.
  • 76. 75 Nesta iteração, por meio do softphone SJPhone, o usuário na máquina virtual 3 realiza uma ligação VoIP com destino à máquina virtual 1. A aplicação Asterisk, em execução na máquina virtual 2, realiza a sinalização da chamada, e ao receber a requisição de ligação faz tocar o softphone Twinkle localizado na máquina virtual 1. 5. IT05: O usuário na máquina virtual 1, aceita a ligação. Ao verificar que seu softphone está tocando, o usuário na máquina virtual 1 atende a chamada. Neste instante, é iniciada uma transmissão live streaming RTP. 6. IT06: É apresentado uma tela com os gráficos para cada transmissão em execução. Ao detectar o estabelecimento de uma sessão SIP, e uma transmissão RTP iniciada, o protótipo apresenta a tela com os gráficos e começa a atualizá-los em tempo real a cada 5 segundos. Esta tela fica em execução até que seja terminada a sessão, e consequentemente, a transmissão. Foi definido no início desta seção que cada trans- missão deve totalizar dois minutos. Após o término desta primeira transmissão, são executadas mais quatro, totalizando cinco transmissões de dois minutos cada. Na figura 4.4, é exibida a tela que apresenta os gráficos de monitoramento de: tráfego RTP, perda de pacotes, jitter e atraso. 7. IT07: Conforme as transmissões são finalizadas, as telas de gráficos respectivas são encerradas. Após os dois minutos estipulados, o usuário na máquina virtual 3 encerra a trans- missão. Com esta ação, é finalizada a tela de gráficos. Os dados medidos ao longo dos dois minutos são armazenados nos arquivos de log, disponível na pasta do pro- tótipo. É repetida a execução do experimento desde a iteração IT04, até totalizar 5 iterações. Deste modo, é possível coletar um maior número de dados, permitindo uma maior exatidão nos resultados. 4.3 Resultados Nesta seção são apresentados os resultados obtidos após a execução do experimento. Os dados oriundos do experimento foram obtidos por meio dos arquivos de log gerados
  • 77. 76 Figura 4.4: Interface gráfica que representa a tela dos gráficos. pelo protótipo. Cada execução do experimento gerou quatro arquivos de log por transmis- são, um para cada métrica monitorada. Como foram feitas cinco execuções, no total foram obtidos vinte arquivos de log. Todos os dados obtidos foram agrupados em tabelas para poderem ser analisados e discutidos na seção posterior. Foram gerados quatro tabelas, uma para cada um dos atributos da transmissão live streaming, exceto perda de pacotes, e outra contendo as médias aritméticas das 5 execuções agrupando todas métricas moni- torados. Nas tabelas, são apresentados os dados medidos a cada 5 segundos. Na tabela 4.1, são apresentados os dados obtidos para o tráfego RTP em cada uma das cinco execuções de dois minutos. Este tráfego corresponde à largura de banda que a transmissão live streaming RTP está utilizando. A unidade na qual os valores estão expressos é bytes/segundo. Na tabela 4.2, é apresentado o valor do atraso RTT obtido ao longo das cinco exe- cuções de dois minutos. Este valor corresponde ao tempo em que um pacote ICMP leva para ir e voltar na rede, da origem até o destino. Os valores apresentados na tabela 4.2 são expressos em milissegundos.
  • 78. 77 Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5 5s 1626 0 0 0 0 10 s 10764 8410 3702 9736 9394 15 s 10806 10635 10764 10764 10678 20 s 10635 10806 10635 10678 10721 25 s 10785 10678 10678 10678 10721 30 s 10764 10678 10764 10678 10721 35 s 10721 10764 10678 10764 10678 40 s 10806 10721 10764 10721 10721 45 s 10721 10721 10721 10635 10721 50 s 10764 10764 9180 10764 10721 55 s 10699 10721 10678 10721 10764 60 s 10721 10678 10764 10764 10721 65 s 10721 10678 10635 10678 10678 70 s 10764 10678 10892 10721 10806 75 s 10806 10721 10678 10721 10635 80 s 10635 10721 10678 10678 10721 85 s 10764 10764 10764 10806 10678 90 s 10678 10635 10678 10635 10721 95 s 10721 10678 10764 10721 10721 100 s 10678 10806 10721 10721 10678 105 s 10764 10764 10678 10721 10806 110 s 10678 10678 10678 10678 10721 115 s 10721 10592 10721 10721 10678 120 s 10721 10806 10764 10764 10764 Tabela 4.1: Valores medidos para cada um das cinco execuções da aplicação para o tráfego RTP. Na tabela 4.3, é apresentado os valores medidos de jitter. O valor do jitter corre- sponde à variação do atraso na entrega dos pacotes. Os valores são expressados em milis- segundos. Os dados obtidos para a perdas de pacotes foram todos nulos, portanto não foi gerado
  • 79. 78 Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5 5s 0,00 0,00 0,00 0,00 0,00 10 s 1,55 1,55 1,53 1,50 1,51 15 s 1,78 1,89 1,90 1,88 1,90 20 s 1,94 1,95 1,95 1,94 1,95 25 s 2,00 1,99 2,00 1,98 2,00 30 s 2,01 2,01 2,01 2,00 2,02 35 s 2,01 2,00 2,01 2,00 2,02 40 s 2,01 2,00 2,02 2,00 2,01 45 s 2,01 2,01 2,02 2,01 2,01 50 s 2,02 2,01 2,00 2,01 2,01 55 s 2,01 2,00 2,02 2,01 2,01 60 s 2,01 2,00 2,01 2,00 2,01 65 s 2,02 2,00 2,01 2,00 2,02 70 s 2,01 2,01 2,02 2,00 2,01 75 s 2,02 2,00 2,01 2,00 2,02 80 s 2,02 2,01 2,01 2,00 2,01 85 s 2,02 2,00 2,00 2,00 2,02 90 s 2,02 2,00 2,00 2,00 2,01 95 s 2,01 2,00 2,00 2,00 2,01 100 s 2,02 2,03 2,00 2,00 2,02 105 s 2,01 2,01 2,00 2,00 2,01 110 s 2,02 2,01 2,00 2,00 2,02 115 s 2,02 2,01 2,00 2,00 2,01 120 s 2,02 2,01 2,00 2,00 2,01 Tabela 4.2: Valores medidos para cada um das cinco execuções da aplicação para o atraso de ida e volta. uma tabela para apresentar estes valores. Este valor corresponde à porcentagem na qual pacotes foram perdidos ou descartados ao longo da transmissão live streaming. Por fim, todos os dados foram agrupados numa mesma tabela contendo a média arit- mética de cada valor com relação às cinco execuções. Este cálculo foi feito para poder ter
  • 80. 79 Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5 5s 0,000 0,000 0,000 0,000 0,000 10 s 0,000 0,000 0,000 0,000 0,000 15 s 0,000 0,000 0,000 0,000 0,000 20 s 0,000 0,000 0,000 0,000 0,000 25 s 0,000 0,000 0,000 0,000 0,000 30 s 0,000 0,000 0,000 0,000 0,000 35 s 0,000 0,000 0,000 0,000 0,000 40 s 0,000 0,000 0,000 0,000 0,000 45 s 0,000 0,000 0,000 0,000 0,000 50 s 0,000 0,000 0,000 0,000 0,000 55 s 0,000 0,000 0,000 0,000 0,000 60 s 0,000 0,000 0,000 0,000 0,000 65 s 0,000 0,000 0,000 0,000 0,000 70 s 0,000 0,000 0,000 0,000 0,000 75 s 0,000 0,000 0,000 0,000 0,000 80 s 0,000 0,000 0,000 0,000 0,000 85 s 0,000 0,000 0,000 0,000 0,000 90 s 0,000 0,000 0,000 0,000 0,000 95 s 0,000 0,000 0,000 0,000 0,000 100 s 45,04 44,11 45,10 35,73 41,69 105 s 45,04 44,11 45,10 35,73 41,69 110 s 45,04 44,11 45,10 35,73 41,69 115 s 45,04 44,11 45,10 35,73 41,69 120 s 45,04 44,11 45,10 35,73 41,69 Tabela 4.3: Valores estimados para cada um das cinco execuções da aplicação para tamanho do buffer de compensação de jitter. uma precisão maior nos resultados obtidos pelo experimento. Estes dados são apresenta- dos na tabela 4.4.
  • 81. 80 Tráfego RTP (b/s) Atraso (ms) Jitter (ms) Perda de Pacotes (%) 5s 325 0,0 0,0 0 10 s 8401 1,5 0,0 0 15 s 10729 1,9 0,0 0 20 s 10695 1,9 0,0 0 25 s 10708 2,0 0,0 0 30 s 10721 2,0 0,0 0 35 s 10721 2,0 0,0 0 40 s 10747 2,0 0,0 0 45 s 10704 2,0 0,0 0 50 s 10439 2,0 0,0 0 55 s 10717 2,0 0,0 0 60 s 10730 2,0 0,0 0 65 s 10678 2,0 0,0 0 70 s 10772 2,0 0,0 0 75 s 10712 2,0 0,0 0 80 s 10687 2,0 0,0 0 85 s 10755 2,0 0,0 0 90 s 10669 2,0 0,0 0 95 s 10721 2,0 0,0 0 100 s 10721 2,0 42,3 0 105 s 10747 2,0 42,3 0 110 s 10687 2,0 42,3 0 115 s 10687 2,0 42,3 0 120 s 10764 2,0 42,3 0 Tabela 4.4: Média aritmética de todos atributos da transmissão live streaming ao longo de cinco iterações. 4.4 Discussão Nesta seção são discutidos e analisados os resultados obtidos pelo experimento. Por meio deste, foi possível medir as quatro métricas de desempenho de QoS: largura de banda, atraso, perda de pacotes e jitter. Com base nos valores medidos para estas métricas,
  • 82. 81 é feita uma análise individual em cada uma delas nas próximas seções. 4.4.1 Tráfego RTP O tráfego RTP consiste em medir a largura de banda utilizada por cada transmissão live streaming. A quantidade de informações que trafega na interface selecionada foi me- dida a cada cinco segundos. A unidade em que foi expressa esta medida é bytes/segundo. Conforme a tabela 4.4, apresentada na seção anterior, foi possível verificar uma me- dida constante no valor ao longo de toda a transmissão, exceto pelos instantes 5 s e 10 s. Isto ocorre, pois os softphones empregados no experimento não possuem nenhum al- goritmo de detecção de silêncio, que poderia causar uma variação para menos no uso de banda em alguns instantes de tempo. O valor do tráfego RTP difere nos instantes 5 s e 10 s devido a maneira que é calculado esta medida. Para se apresentar um valor numa base de tempo, é necessário utilizar uma referência para este cálculo, neste caso, o valor medido no instante anterior. Na seção 3.3.1, foi apresentado o algoritmo que fazia este cálculo, mas este algoritmo é derivado da fórmula apresentada em 4.1. U soDeBanda(t1) − U soDeBanda(t0) T raf egoRT P = (4.1) tempoDeAtualizaoDoGraf ico Como pode ser visto, ao utilizar a referência do instante anterior, no primeiro in- stante de tempo em que é feito a medida, 5 s, não se tem um valor de referência anterior. Portanto, a diferença entre o uso de banda será muito mais baixa do que nos instantes seguintes. O mesmo se repete para 10 s. Após a obtenção destes dois valores menores, os valores obtidos para o uso de banda são estabilizados em torno de 10700 bytes/segundo. Numa primeira análise, não é possível verificar a exatidão do valor quantitativo desta medida. No entanto, a probabilidade deste valor estar correto é alta, visto que analisando o codec de compressão de voz utilizado nos softphones, o G711, é possível verificar que ele utiliza 64 kbits por segundo, conforme Lima (2006). Ao converter este valor para bytes por segundo, temos 7812 bytes/segundo, conforme a equação 4.2. Este valor calculado corresponde apenas aos dados trafegados. Deve-se ressaltar que o valor 7812 é um cálculo teórico , não condizendo com o tamanho real dos dados que trafegam no enlace. Ainda é
  • 83. 82 necessário adicionar os cabeçalhos das camadas de enlace, rede e transporte. Portanto, é verificado a relevância nos dados medidos pela aplicação. V alorKbps Bytes/seg = (4.2) 1024 ∗ 8 4.4.2 Atraso O atraso consiste na medição do atraso em que um pacote leva da origem até seu destino (também conhecido como round trip time). Esta medida de tempo obtida por meio do experimento tem sua unidade em milissegundos. Conforme a tabela 4.4, apresentada na seção anterior, é possível verificar que o valor do atraso é mantido constante ao longo de toda transmissão, exceto pelos instantes 5 s e 10 s. Este atraso é constante e baixo, devido a utilização de um enlace lógico. A máquina virtual compartilha a rede com a máquina hospedeira, e além da largura de banda disponível ser total não existem colisões. Deste modo, como o tráfego total não ultrapassa 10 kbytes/segundo, não acontecem sobrecargas no enlace, consequentemente, o atraso fica constante e mínimo. Da mesma maneira que o tráfego RTP, nos primeiros instantes de tempo houve uma variação no atraso, se comparado com o restante da medição. Isso acontece, pois é uti- lizado o valor da medição anterior acumulada para calcular a média. O atraso é calculado a cada dois segundos, sendo a taxa de amostragem do protótipo é de cinco segundos. Desta forma, para se aumentar a precisão na medição é feito uma média. Como nos primeiros instantes em que a média é calculada os valores eram nulos, os valores inicias sofrem variações. A técnica utilizada para se obter os valores de atraso, e calcular a média é apresen- tado em 3.3.3. Desta técnica, é possível derivar uma fórmula para se calcular a média aritmética acumulada para o valor do atraso de ida e volta. A fórmula para este cálculo é apresentado na equação 4.3. M ediaAtraso(t − 1) + Atraso(t) M ediaAtraso(t) = (4.3) 2 A média para o atraso ao longo dos dois minutos de medição é 2 ms. Ao comparar
  • 84. 83 este atraso de ida volta obtido, com o atraso fim a fim recomendado pela norma G.114 (ITU, 2003) de 150 ms, é possível verificar que o valor está dentro do aceitável. O atraso de ida e volta sempre será maior que o atraso fim a fim, pois este se trata de um atraso unidirecional, conforme seção 2.2.1.1. O valor obtido pela experimentação, mesmo no pior caso de medição do atraso de ida e volta, estaria dentro de um valor aceitável, segundo a recomendação. 4.4.3 Perda de Pacotes A perda de pacotes medida pelo experimento buscou medir a taxa na qual pacotes são perdidos ou descartados no enlace, relacionados somente à transmissão live streaming em questão. Foi buscado uma medida de referência para apresentar este valor, sendo expressa em porcentagem. Seu referencial é a quantidade de pacotes que trafegaram com sucesso pelo enlace. A medição da perda de pacotes foi a única cujos dados obtidos foram constantes ao longo de toda a execução da aplicação, e em todas cinco execuções. Este dado varia bas- tante conforme a qualidade do enlace pelo qual trafegam os dados. Como foram utilizadas máquinas virtuais que compartilhavam o mesmo enlace lógico, e este nunca chegou perto da sua utilização máxima, não houve nenhuma perda ou descarte de pacotes. Portanto, esta medição ficou em 0 % em todas execuções do protótipo. É possível verificar esta medição na tabela 4.4, apresentada na seção 4.3. A medida da perda de pacotes foi obtida por meio do pacote de controle RTCP. Desta maneira foi possível medir apenas a perda de pacotes decorrente da transmissão live streaming. Esta foi a melhor maneira encontrada para se obter esta métrica, pois per- mitia medir dentro do contexto das transmissões live streaming, e não de todos os dados trafegados no enlace. Como não houve nenhuma perda de pacotes, a qualidade da transmissão não poderia ter sido afetada por esta métrica. Ainda, segundo a recomendação G114 (ITU, 2003), poderia ter ocorrido uma perda de pacotes de 5 % que a qualidade da transmissão seria mantida.
  • 85. 84 4.4.4 Buffer de compensação de jitter A medição do buffer de compensação de jitter realizada pelo protótipo no experi- mento utiliza um método que necessita primeiro fazer uma amostragem de valores, para então efetuar o cálculo. Como esta variação no atraso dos pacotes é um dado temporal, a unidade de medição é o milissegundo. A técnica utilizada para medição do jitter foi por amostragem e cálculo por meio do protocolo ICMP. Foram obtidas 30 (trinta) amostras ao longo de 60 (sessenta) segundos, sendo que a variação no atraso destas amostras eram somados. Findo minuto, foi feito a média destes valores para obter o jitter. Na seção 3.3.4 foi apresentado o algoritmo utilizado, mas a fórmula equivalente a este é apresentada em 4.4. ∆Atraso Jitter(t) = (4.4) 30 Baseado nos dados apresentados pela tabela 4.4, apresentada em 4.3, é possível ver- ificar que após 100 s iniciais o valor do jitter é apresentado. Em tese, este dado poderia ter sido exibido aos 60 s, pois são obtidas 30 amostras a cada 2 segundos. Mas, devido ao atraso na obtenção das amostras, atraso no cálculo e propagação, e atraso para exibição do gráfico, este dado apenas é apresentado no gráfico após os 100 s. Ressalta-se que este valor é uma aproximação matemática do valor real, pois este dado é complexo para se obter (MEGGELEN; SMITH; MADSEN, 2005). Foram amostrados os dados para o cálculo por meio do protocolo ICMP, ao invés do próprio protocolo RTP ou RTCP. O problema nesta abordagem é que numa rede onde exista QoS configurado, o protocolo ICMP poderia estar em outra fila de prioridade, tornando esta medida imprecisa. Também, o protocolo ICMP pode ser barrado por firewalls, inviabilizando a medição por este método. Mesmo executando num ambiente ideal, o protótipo obteve um valor acima do con- siderado seguro para uma transmissão. Foi obtida uma média de 42,3 ms, enquanto que o valor seguro seria 30 ms. Devido ao método utilizado para cálculo, este pode não ser o valor real do tamanho do buffer de compensação de jitter. Para uma futura implemen- tação, deve ser utilizado um método que calcule por meio do protocolo RTP.
  • 86. 85 4.5 Síntese do Capítulo Neste capítulo foi abordado os aspectos da experimentação deste trabalho, organizado em quatro seções. Na primeira seção, foi apresentado o ambiente da experimentação que foi todo virtualizado, pois precisava ser um ambiente controlado. Este ambiente con- sistiu de três máquinas virtuais interconectadas, sendo que duas atuaram como estações de trabalho e outra como gateway server. Na segunda seção, foi descrito o experimento com o protótipo desenvolvido. As etapas do experimento contemplaram desde o início do protótipo e estabelecimento de uma ligação VoIP, até o encerramento das chamadas. Foram feitas cinco transmissões em tempo real, cada uma com duração de dois minutos. Na terceira seção, foram apresentados os dados obtidos para cada uma das métricas de desempenho de QoS (largura de banda, atraso, perda de pacotes e jitter), por meio da medição com o experimento. Na última seção, foram discutidos os resultados obtidos na seção anterior. Todos os dados tiveram uma medição constante, sem sofrer muita vari- ação ao longo das cinco transmissões, com exceção do jitter, que além de outros motivos, variou por causa da técnica empregada na medição. No próximo capítulo serão apresentadas as conclusões deste trabalho.
  • 87. 86 5 CONCLUSÃO A transmissão de aplicações em tempo real em redes baseadas na comutação de pa- cotes (ex: Internet) ainda representa um grande desafio para administradores e profission- ais de redes. A transmissão com qualidade de conteúdo multimídia (live streaming) exige o oferecimento de determinadas garantias de desempenho das redes de pacotes. Usual- mente, tais garantias são expressas através de quatro métricas: largura de banda, latência, jitter e perda de pacotes. Apesar de serem simples de serem definidas conceitualmente, tais métricas geralmente não são oferecidas nas ferramentas utilizadas para o monitora- mento de redes de pacotes ou não podem ser obtidas durante a transmissão do fluxo, o que torna o seu cálculo complexo e demorado. Este trabalho teve como objetivo principal desenvolver um protótipo de ferramenta de monitoramento gráfica em tempo real das métricas de desempenho citadas acima. Além do desenvolvimento da ferramenta, algumas técnicas de medição das métricas foram pro- postas, implementadas e testadas por intermédio do protótipo. Os resultados obtidos demonstraram que não houve variação significativa nos valores obtidos entre as diver- sas execuções do experimento, com exceção da métrica de jitter. Dentro do contexto do experimento, a ferramenta mostrou-se robusta e capaz de servir de importante instrumento de auxílio para administradores e profissionais que desejem monitorar suas transmissões em tempo real. Apesar de o desenvolvimento e teste da ferramenta terem obtido sucesso, algumas dificuldades podem ser descritas. A primeira delas foi a obtenção do valor de jitter por intermédio do protocolo RTCP. Apesar de este valor estar contido na mensagem sender report desse protocolo, sua conversão de unidades de timestamp para milissegundos não foi possível. Em virtude disso, a obtenção desse valor foi feita utilizando-se o proto-
  • 88. 87 colo ICMP, mesmo sabendo-se que os resultados poderiam sofrer variações em função da diferença de tratamento desse protocolo nos equipamentos de rede. A segunda dificuldade encontrada foi na obtenção do atraso unidirecional. Com relação ao atraso, a literatura afirma que as transmissões em tempo real são sensíveis a um determinado valor de atraso unidirecional. A técnica utilizada no trabalho para a medição desse atributo baseou-se no atraso de ida e volta (RTT - Round Trip Time), o que torna a comparação direta com o valor da literatura não tão direta. A terceira dificuldade encontrada foi relacionada com a medição da largura de banda utilizada. Inicialmente, pensou-se em utilizar o protocolo SNMP para realizar essa medição. Como isso faria com que houvesse a necessidade da implementação de agentes nos dispositivos participantes da transmissão live streaming, a contagem de pacotes RTP e RTCP foi utilizada, tornando o protótipo independente do SNMP. Os resultados obtidos no experimento demonstraram que a ferramenta foi bem suce- dida no processo de medição. No entanto, em função dos testes terem sido realizados em um ambiente controlado, tal afirmação não pode ser generalizada. Em um ambiente real, aplicações em tempo real competem com aplicações normais pelo uso de recursos e podem influenciar o modo como as métricas de cada fluxo são medidas. Além disso, não foram medidos todos os tipos de transmissões live streaming, o que torna a validação dos resultados dependente de apenas um tipo de tráfego (VoIP). O protótipo também ficou fortemente dependente do protocolo SIP para a identificação dos fluxos de dados, sendo necessários testes com outros protocolos de sinalização (ex: H.323). Outra limitação da ferramenta é a sua dependência do protocolo ICMP para a medição atraso e jitter. Em certos ambientes, o protocolo ICMP pode ser filtrado e impedir a coleta dessas métricas. Além disso, a execução da ferramenta em situações em que políticas de QoS são im- plementadas nos dispositivos de rede, os pacotes ICMP poderiam sofrer atrasos por não serem prioritários, afetando a medição. Por último, não houve um processo de validação formal para comprovar a correção da ferramenta em termos de seus resultados. Os testes foram feitos utilizando-se um experimento cujos resultados não podem ser expandidos para outros contextos que não sejam idênticos ao apresentado. Alguns trabalhos futuros podem ser propostos com o intuito de expandir e/ou mel- horar a ferramenta desenvolvida nesse trabalho. O primeiro deles seria testar o protótipo numa topologia de redes mais complexa, simulando um ambiente real. Além disso, para
  • 89. 88 tornar mais real este ambiente deveria ser inserido tráfego de fundo, para analisar o com- portamento do protótipo com outros dados trafegando na rede. O segundo seria imple- mentar a identificação de sessão com outros protocolos além do SIP. Outros protocolos bastante utilizados, e que teriam relevância para este trabalho seriam o H.323 e o MGCP. O terceiro trabalho poderia ser o aprimoramento na maneira em que são feitos os cálcu- los de jitter e atraso. Da maneira que é feito, o protótipo fica dependente do protocolo ICMP na rede, podendo estar indisponível, ou ter uma prioridade menor na rede, se com- parado ao fluxo RTP. Tais cálculos poderiam ser feitos diretamente pelo protocolo RTP, e/ou RTCP. O desenvolvimento de uma proposta de validação formal dos objetivos tam- bém é uma atividade que poderia ser sugerida e que traria maior garantia de correção à ferramenta. As aplicações live streaming tendem a crescer em termos de uso à medida que a Inter- net se populariza e se torna cada vez mais multimídia. Obter informações de desempenho a respeito dos fluxos que sustentam tais aplicações pode fazer com que os usuários ten- ham consciência da importância que certas métricas de desempenho exercem em cada uma delas. Além disso, a extração de informações pode servir de importante apoio para o desenvolvimento de novos protocolos multimídia que sejam cada vez mais robustos e resilientes a variações de rede.
  • 90. 89 REFERÊNCIAS AGENCY, D. A. R. P. Internet Control Message Protocol. IETF - RFC 792, 1981. Disponível em: <http://www.ietf.org/rfc/rfc792.txt>. AGENCY, D. A. R. P. Transmission Control Protocol. IETF - RFC 793, 1981. Disponível em: <http://www.ietf.org/rfc/rfc793.txt>. APOSTOLOPOULOS, J.; TAN, W.; WEE, S. Video Streaming: Concepts, Algorithms, and Systems. [S.l.]: HP Laboratories Palo Alto, 2002. 11 p. BALBINOT, R. et al. Voz sobre ip - tecnologia e tendências. SBRC03, XXI Simpósio Brasileiro de Redes de Computadores., p. 321–363, 2003. BUSCHMANN, F. et al. Pattern-Oriented Software Architecture Volume 1: A System of Patterns. [S.l.]: John Wiley & Sons, 1996. CARVALHO, L. S. G. Implementação do modelo e para avaliação objetiva da qualidade da fala em redes de comunicação voip - dissertação (mestrado). Universidade Federal do Amazonas, 2004. DEITEL, H. M. Java How to Program, Sixth Edition. [S.l.]: Prentice Hall, 2004. DOUSKALIS, B. IP Telephony the Integration of Robust VoIP Service. [S.l.]: Hewlett-Packard Company, 2000. DURKIN, J. F. Voice-Enabling the Data Network: H.323, MGCP, SIP, QoS, SLAs, and Security. [S.l.]: Cisco Press, 2002. ITU, T. S. S. of. Recommendation G.114: International telephone connections and circuits General Recommendations on the transmission quality for an entire international telephone connection - One-way transmission time. [S.l.]: ITU-T, 2003.
  • 91. 90 KUROSE, J. E.; ROSS, K. W. Redes de computadores e a Internet: uma abordagem top-down. [S.l.]: Pearson Addison Wesley, 2006. (3). LALONDE, W. Discovering Smalltalk. [S.l.]: Pearson Technology Group, 2008. LARMAN, C. Utilizando UML e Padrões. [S.l.]: BookMan, 2007. LIMA, A. F. M. de. Monitoramento snmp para avaliar a qualidade das chamadas em um ambiente voip - dissertação (mestrado). Universidade Federal do Ceará, 2006. MEGGELEN, J. V.; SMITH, J.; MADSEN, L. Asterisk: The Future of Telephony. [S.l.]: O’Reilly Media, 2005. MICROSYSTEMS, S. Java blueprints: Model-view-controller. 2008. Disponível em: <http://java.sun.com/blueprints/patterns/MVC.html>. RANJBAR, A. S. CCNP ONT Official Exam Certification Guide. [S.l.]: Cisco Press, 2007. RIBEIRO, B. F. M.; RODRIGUES, P. H. d. A.; MARCONDES, C. A. C. Implementação de gateway de sinalização entre protocolos de telefonia ip sip/h.323. Simpósio Brasileiro de Redes de Computadores. Florianópolis - SC., SBRC2001, p. 574–589, 2001. Disponível em: <http://www.voip.nce.ufrj.br/pgv oip/publication/2001/sbrc2001s iph323.pdf >. ROSENBERG, J. et al. SIP: Session Initiation Protocol. IETF - RFC 3261, 2002. Disponível em: <http://www.ietf.org/rfc/rfc3261.txt>. RYBACZYK, P. Expert Network Time Protocol: An Experience in Time with NTP. [S.l.]: Apress, 2005. SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. IETF - RFC 3550, 2003. Disponível em: <http://www.ietf.org/rfc/rfc3550.txt>. STEWART, B. D.; GOUGH, C. CCNP BSCI Official Exam Certification Guide. [S.l.]: Cisco Press, 2008. (4). TAO, S.; APOSTOLOPOULOS, J.; GUéRIN, R. Real-time monitoring of video quality in ip networks. IEEE/ACM TRANSACTIONS ON NETWORKING, v. 16, 2008.
  • 92. 91 TOPIC, M. Streaming Media Demystified. [S.l.]: McGraw-Hill, 2002. VELOS, E. et al. A hierarchical characterization of a live streaming media workload. In: Internet Measurement Workshop. [S.l.]: IEEE, 2002. p. 117–130.

×