Your SlideShare is downloading. ×

Ra 2009 Bentow. SmartBand

606

Published on

This is the report of what has been developed for my project.

This is the report of what has been developed for my project.

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

  • Be the first to like this

No Downloads
Views
Total Views
606
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
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. SmartBand: Sistema de auditoria para transmiss˜ es Live o Streaming Maur´cio Bento Ghem1 ı 1 ¸˜ Engenharia da Computacao - Universidade do Vale do Rio dos Sinos (UNISINOS) Caixa postal 275 – 93.022-000 – S˜ o Leopoldo – RS – Brazil a Mauricio@Bentow.org Abstract. The Live Streaming brought new functionalities to the interaction and communication among the users on the Internet, an example of application would be the videoconference. Due to a lack of specialized tools to monitor and do the auditing in Live Streaming transmissions, this work has the objec- tive to develop a network application that makes it possible the auditory in the transmissions of information based on a Live Streaming system. In the current stage of the research, data was collected to be analyzed by the next stage, which will define which items will be audited. The following stages will be responsible for the implementation and validation of the SmartBand system. Resumo. O Live Streaming trouxe novas funcionalidades para a interacao e ¸˜ comunicacao entre usu´ rios na Internet, um exemplo de aplicacao seria a video- ¸˜ a ¸˜ conferˆ ncia. Devido a carˆ ncia de ferramentas especializadas no acompan- e ` e hamento e auditoria de transmiss˜ es Live Streaming, o presente trabalho tem o como objetivo desenvolver uma aplicacao de redes que possibilite a auditoria ¸˜ na transmiss˜ o de informacoes baseadas num sistema Live Streaming. Nesta a ¸˜ etapa da pesquisa foram coletados dados que ser˜ o analisados pela pr´ xima a o etapa, que definir´ quais os itens a serem auditados. As etapas seguintes ser˜ o a a respons´ veis pela implementacao e validacao do sistema SmartBand. a ¸˜ ¸˜ ¸˜ 1. Introducao ´ O Live Streaming [Velos et al. 2002] e todo conte´ do audiovisual capturado em tempo u ´ real e disponibilizado para in´ meros espectadores via Internet. Esse conceito e aplicado u ¸˜ ¸˜ ` em diversas aplicacoes, tais como a de videoconferˆ ncia, entretenimento e educacao a e distˆ ncia (EaD), que vem crescendo ao longo dos anos por proporcionar muitos benef´cios a ı se comparada ao ensino presencial [Fischer 2000]. Hoje, o meio mais comum para ´ se utilizar essa modalidade e um ambiente de ensino que contempla apostilas, f´ runso ¸˜ e conversacoes. Muitos desses ambientes carecem do contato ao vivo com o instru- tor/professor [Firmo 2003]. O projeto Convergˆ ncia Digital1 , no qual este trabalho de conclus˜ o de curso est´ e a a inserido, trata de permitir a maior interatividade poss´vel do usu´ rio com um meio de ı a acesso. Nesse contexto e na atual etapa na qual o projeto se encontra, percebeu-se a ¸˜ necessidade de se criar um sistema Web para interacao aluno-professor utilizando-se um 1 ¸˜ ¸˜ O projeto Convergˆ ncia Digital tem como objetivo a criacao de aplicacoes interativas para a TV Digital. e ´ ´ E coordenado pelo prof. Jo˜ o Bittencourt, e o projeto e executado e patrocinado pela UNISINOS. a
  • 2. ´ ´ ambiente baseado na videoconferˆ ncia. E importante destacar que a EaD e um exemplo de e ¸˜ aplicacao de transmiss˜ o de audiovisual em tempo real (Live Streaming) [Coventry 1998]. a ¸˜ Em sua concepcao, o SmartBand tinha como objetivo ser um protocolo de geren- ¸˜ ciamento de transmiss˜ o das informacoes que funcionaria proativamente selecionando a a melhor stream baseado na largura de banda que o usu´ rio possui. Este trabalho era di- a ¸˜ vidido em trˆ s etapas, sendo elas, respectivamente: estudo, definicao e implementacao. e ¸˜ Ao longo da primeira etapa, foi descoberto um grande problema de viabilidade que se- ¸˜ ` ria uma grande limitacao no acoplamento deste protocolo a uma plataforma de trans- miss˜ o Live Streaming em funcionamento. Para que esse protocolo pudesse funcionar, a a ¸˜ seria necess´ rio criar uma aplicacao espec´fica que tivesse as interfaces necess´ rias para ı a permitir seu acoplamento. Como este projeto se tornaria invi´ vel, o escopo do SmartBand a foi alterado para o atual. o a ¸˜ Ap´ s a revis˜ o de escopo, este trabalho tem como objetivo criar a aplicacao Smart- a a ¸˜ Band (SmB), que far´ auditoria na transmiss˜ o de informacoes por meio da Internet ` ¸˜ ´ visando a melhor qualidade de servico para o usu´ rio na recepcao de audio e v´deo em ¸ a ı a ¸˜ tempo real. O SmB possibilitar´ a visualizacao em tempo real de estat´sticas relacionadas ı ` ¸˜ a utilizacao da banda, ao atraso na transmiss˜ o e outros dados relevantes que possam ser, a posteriormente, analisados e utilizados para proporcionar aos usu´ rios um servico melhor, a ¸ tanto na transmiss˜ o quanto na conectividade com a rede. a Este relat´ rio apresenta o desenvolvimento parcial do sistema descrito acima e est´ o a estruturado da seguinte forma: a seca ¸ ˜ o 2 apresenta todos os conceitos e bibliotecas que ¸˜ ¸˜ ¸˜ precisam ser dominados para a criacao da aplicacao; a secao 3 apresenta a metodologia do ¸˜ projeto, apresentando cada um dos objetivos espec´ficos; a secao 4 apresenta os resultados ı ´ ¸˜ ´ obtidos at´ o momento, e na ultima secao, e apresentada uma breve conclus˜ o e a projecao e a ¸˜ das pr´ ximas etapas. o 2. Revis˜ o Bibliogr´ fica a a ¸˜ Nesta secao, ser˜ o abordados os principais temas que comp˜ em a revis˜ o bibliogr´ fica do a o a a trabalho at´ o presente momento. Tamb´ m, ser˜ o apresentados t´ picos que ser˜ o apro- e e a o a fundados posteriormente para a total completude do trabalho. 2.1. Live Streaming A tecnologia de streaming consiste na quebra de um fluxo de dados em pequenos pedacos ¸ para envi´ -los um a um sucessivamente, sendo que o receptor decodificar´ cada parte e a a a executar´ sem ter que esperar por todo o fluxo de dados [Apostolopoulos et al. 2002]. a Essa tecnologia existe desde que as transmiss˜ es por r´ dio e televis˜ o anal´ gica foram o a a o inventadas. O equipamento do espectador, desde aqueles tempos, recebia dados contin- uamente, 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 ı u demanda para o usu´ rio. a ¸˜ u a ´ Em relacao ao conte´ do est´ tico, que e necess´ rio ter em sua totalidade para ser a ´ntegro, o streaming tem uma grande vantagem, pois e poss´vel acessar um conte´ do sob ı ´ ı u u ´ demanda. Conforme o conte´ do e executado as partes seguintes est˜ o sendo recebidas, a
  • 3. executadas, e assim sucessivamente. Hoje em dia, grandes websites utilizam esta tec- nologia como um servico. O Youtube2 , por exemplo, recebe uma m´dia est´ tica e a torna ¸ ı a dispon´vel como um fluxo de dados para ser acessada sob demanda. ı ¸˜ ´ A evolucao desta tecnologia e a chamada Live Streaming que possibilita a trans- a ı ´ miss˜ o ao vivo de uma m´dia. Com esta tecnologia e poss´vel enviar, diretamente, para a ı ı a a ¸˜ Internet um v´deo capturado por uma cˆ mera sem ter que armazen´ -lo. Esta evolucao per- mite que as emissoras transmitam via Internet eventos, programas e r´ dios em tempo real, a permitindo o aumento no n´ mero de espectadores que assistem ou escutam seus progra- u e a a ¸˜ mas. Por´ m, a transmiss˜ o em tempo real n˜ o foi a maior aplicacao para esta tecnologia, e sim a videoconferˆ ncia que foi amplamente difundida por meio de programas como e 3 Skype . A videoconferˆ ncia trouxe uma enorme quebra de paradigma, possibilitando que e pessoas conversem frente a frente estando em qualquer lugar do mundo. Tanto o streaming quanto o live streaming podem ser implementados de muitas a ´ maneiras. Uma das mais eficientes, e n˜ o propriet´ ria e utilizando um codec para com- a primir a m´dia e transmiti-la para os usu´ rios via protocolo RTP (Real-time Transport ı a Protocol) [Schulzrinne et al. 2003] que roda em cima do protocolo de transporte UDP4 , a ´ que n˜ o e orientado a conex˜ o. Aliado ao RTP, o protocolo RTCP (Real-time Control Pro- a ¸˜ ¸˜ tocol) permite controle e geracao de estat´sticas da transmiss˜ o. Existem implementacoes ı a 5 que utilizam o TCP como protocolo de transporte, multiplexando na mesma conex˜ o o a protocolo de controle, como a do Skype. 2.2. Protocolo RTP/RTCP ¸˜ O protocolo RTP teve sua especificacao inicial em 1996 pela RFC (Request for comments) 6 1889 [Schulzrinne et al. 1996], mas ao longo do tempo foi aprimorado e em 2003 foi criada a RFC 35507 [Schulzrinne et al. 2003]. Este protocolo permite o transporte fim- ¸˜ ´ a-fim de aplicacoes que transmitam dados em tempo real, como audio e v´deo, por meio ı de multicast ou unicast. Este protocolo n˜ o garante a qualidade do servico (QoS) para a ¸ transmiss˜ es em tempo real, por isso funciona em conjunto com o RTCP que permite o monitorar a entrega, gerar estat´sticas dos dados, e identificar os usu´ rios que os recebem ı a - numa rede multicast - proporcionando dados para o administrador analisar e realizar uma melhora no servico. ¸ ¸˜ Existem diversas aplicacoes que entregam conte´ do multim´dia em tempo real u ı que rodam sob o protocolo RTP, tais como: Cisco IPTV, Asterisk Video Call, Quicktime Streaming Server e Shoutcast Webradio. Em contrapartida, outras grandes empresas op- a ¸˜ taram por desenvolver um protocolo de transporte propriet´ rio, algumas aplicacoes s˜ o: a Skype e Microsoft Windows Media. ´ Por ser aberto e por ter uma RFC que padronize o protocolo RTP, e poss´vel in- ı ¸˜ ¸˜ corporar uma aplicacao que faca a interpretacao dos dados gerados pelo protocolo RTCP, ¸ ¸˜ o de controle. Este protocolo foi a principal evolucao desde a primeira RFC, devido aos 2 ¸˜ Mais informacoes em: http://www.youtube.com/t/about. 3 Dispon´vel em http://www.skype.com. ı 4 ¸˜ User Datagram Protocol. Mais informacoes em: http://www.faqs.org/rfcs/rfc768.html. 5 ¸˜ Transmission Control Protocol. Mais informacoes em: http://www.faqs.org/rfcs/rfc793.html. 6 Dispon´vel em: http://www.ietf.org/rfc/rfc1889.txt. ı 7 Dispon´vel em: http://www.faqs.org/rfcs/rfc3550.html. ı
  • 4. algoritmos utilizados para calcular jitter [Meggelen et al. 2005] e atraso, e do c´ lculo dos a ´ tempos para envio e recebimento das mensagens. O RTCP e bidirecional, ou seja, pacotes s˜ o enviados da origem de conte´ do para o destino e vice-versa. O pacote RTCP tem um a u formato padr˜ o, este e resumido na figura 18 , por´ m recebe diferentes conte´ dos depen- a ´ e u ´ ´ dendo do papel do host na rede. Se ele e a origem dos dados, e inclu´do no pacote um ı sender report, como pode ser visto na figura 2 9 . Caso o papel do host seja de destinat´ rio, a este enviar´ um receiver report com diferentes tipos de dados, como apresentado na figura a 310 . Os dados contidos neste pacote ser˜ o de extremo valor para os c´ lculos e estat´sticas a a ı gerados pelo sistema SmartBand. Figure 1. O pacote RTCP. Figure 2. O sender report inserido dentro do pacote RTCP. 2.3. O Protocolo SIP O protocolo SIP11 foi especificado na RFC 326112 , e e considerado um protocolo de ´ ¸˜ ¸˜ ¸˜ sinalizacao, que roda na camada de aplicacao, que engloba a criacao, modificacao e ¸˜ ¸˜ finalizacao de uma sess˜ o entre um e/ou mais participantes. Estas sess˜ es incluem a o ¸˜ ¸˜ ´ ligacoes via Internet, conferˆ ncias e distribuicao de multim´dia. Como o SIP e um pro- e ı ¸˜ ´ tocolo que engloba apenas a sinalizacao, e necess´ rio um protocolo que possibilite o a ¸˜ ´ transporte da informacao fim-a-fim, neste contexto, o RTP e empregado. 8 A figura est´ a dispon´vel ı em: http://java.sun.com/javase/technologies/desktop/media /jmf/2.1.1/guide/images/RTPRealTime2.gif 9 A figura est´ dispon´vel em: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- a ı ments/images/rtcp sr header.jpg 10 A figura est´ dispon´vel em: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- a ı ments/images/rtcp rr header.jpg 11 Acrˆ nimo de Session Initiation Protocol. RFC dispon´vel em: http://www.ietf.org/rfc/rfc3261.txt. o ı 12 Dispon´vel em: http://www.ietf.org/rfc/rfc3261.txt. ı
  • 5. Figure 3. O receiver report inserido dentro do pacote RTCP. ´ A topologia convencional para uso do protocolo SIP e apresentada na figura 4, na ¸˜ ´ qual apresenta o fluxo de informacoes, e como cada um dos protocolos e utilizado. Figure 4. Topologia convencional do uso do protocolo SIP auxiliado pelo RTP. O SIP utiliza formato de mensagens definidos na RFC 282213 , e possui, basica- ¸˜ ´ mente, dois tipos de mensagens, requisicoes e respostas. Este protocolo e baseado no ¸˜ modelo do HTTP de mensagens, sendo enviada uma requisicao chamando determinado ¸˜ ¸˜ m´ todo ou funcao do servidor. Para a aplicacao SmartBand, ser´ relevante o pacote de e a resposta que invoca o m´ todo ’INVITE’, no qual requisita o in´cio de uma sess˜ o com e ı a ´ outro dispositivo. Este pacote tem um formato unico, e por meio dele que ser´ descoberto a o n´ mero da porta RTP. u ` ´ Este pacote de resposta a chamada SIP INVITE e composto dos dados SIP in- 14 cluindo outro protocolo descrito na RFC 2327 , chamado de SDP (Session Description ı ´ Protocol). Por meio dos dados inclu´dos no SDP, e poss´vel identificar todos os dados da ı sess˜ o, tais como: n´ mero de porta de origem e destino para a transmiss˜ o RTP, codec a u a a ı ¸˜ utilizado, tipo de sess˜ o (voz ou v´deo), e informacoes de cada um dos componentes da sess˜ o. Utilizando os dados do SDP ser´ poss´vel monitorar os dados gerados via RTCP. a a ı 2.4. A biblioteca JPCAP A JPCAP15 e uma biblioteca dispon´vel para Java que permite a captura e o envio de ´ ı quadros e pacotes de rede. Os tipos de dados que podem ser gerados e capturados nativa- mente pela biblioteca s˜ o: Ethernet, IPv4, IPv6, ARP/RARP, TCP, UDP e ICMP. Ela foi a concebida num projeto do professor Tatsuya Suda, que atua na Universidade da Calif´ rnia o Irvine. 13 Dispon´vel em: http://www.faqs.org/rfcs/rfc2822.html. ı 14 ¸˜ Mais informacoes em: http://www.ietf.org/rfc/rfc2327.txt. 15 ¸˜ Mais informacoes em: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html.
  • 6. ¸˜ Dentre as outras bibliotecas dispon´veis que desempenhassem essa funcao, foi ı escolhido essa devido a facilidade de uso, suporte aos protocolos necess´ rios e por ter a uma comunidade que d´ suporte e apoio a d´ vidas. Por´ m, tanto esta quanto as outras a u e bibliotecas n˜ o d˜ o suporte nativo ao protocolo RTP/RTCP, sendo necess´ rio manipular a a a este pacote como UDP, possibilitando o acesso aos dados do pacote apenas byte a byte. 2.5. NS-2 e RTPUP ´ O NS-2 e uma ferramenta baseada no simulador de redes REAL, criado em 1989. Ele ´ ` e um simulador de redes orientado a eventos discretos, direcionado a pesquisa cient´fica. ı ´ Com este simulador e poss´vel simular protocolos de diversas camadas do modelo OSI, ı ¸˜ tais como: HTTP e Telnet (camada de aplicacao); TCP, UDP e RTP (camada de trans- porte); protocolos de roteamento e QoS (camada de rede); e CSMA/CD (Carrier Sense Multiple Access with Collision Detection) da camada de enlace. Al´ m disso, suporta o e desenvolvimento de extens˜ es e novos protocolos que s˜ o incorporados a esta ferramenta o a para serem validados cientificamente16 . ` ¸˜ Devido as limitacoes que o protocolo RTP nativo do NS-2 possui - como n˜ o a incorporar o protocolo de controle (RTCP) - a Universidade de Patras criou uma extens˜ o a do protocolo RTP contida no NS-2, chamado de RTPUP [Bouras et al. 2008], incluindo grande parte dos conceitos definidos na RFC 3550, incluindo o RTCP. Desta maneira, e ´ ¸˜ poss´vel utilizar o NS-2 em conjunto com esta implementacao do RTP para gerar dados ı fict´cios e verificar o comportamento do SmartBand. ı 3. Metodologia ¸˜ Nesta secao, ser´ apresentada a metodologia modificada desde que o escopo do projeto a ´ foi alterado. Esta metodologia e tal que permite atingir o objetivo geral proposto na introduca ¸ ˜ o. O presente trabalho foi dividido em quatro grandes etapas, cada uma delas con- ¸˜ ¸˜ ¸˜ templando os objetivos espec´ficos, que s˜ o: medicao e obtencao de informacoes de uma ı a ¸˜ ¸˜ rede ao longo de uma transmiss˜ o Live Streaming, definicao de equacoes ou algoritmos a ¸˜ ¸˜ para obtencao de dados estat´sticos, criacao de um prot´ tipo da ferramenta proposta e sua ı o ¸˜ ´ validacao. A primeira etapa e respons´ vel pela coleta de dados oriundos do protocolo a de controle, o RTCP, que roda em paralelo com o RTP. Na segunda etapa, com base nos conceitos estudados e no resultado da etapa anterior, ser˜ o definidos o tipo e a estrutura a ¸˜ ¸˜ que a informacao ter´ para ser apresentada na aplicacao. Na terceira etapa, ocorrer´ o a a ¸˜ desenvolvimento da aplicacao, que far´ o monitoramento para gerar estat´sticas e dados a ı ´ ¸˜ relevantes para auditoria da transmiss˜ o. A quarta e ultima etapa contemplar´ a validacao a a do sistema como um todo. Cada uma dessas etapas ser´ descrita a seguir. a 3.1. Coleta de Dados ¸˜ Para se desenvolver a aplicacao final, ser´ necess´ rio interagir com os pacotes gera- a a ` dos pelo protocolo RTCP, que atua em conjunto com o RTP. Devido a quantidade de ¸˜ informacao contida no pacote RTCP, ser´ feita uma coleta de dados proveniente de a 16 ´ O NS-2 e disponibilizado no site: http://www.isi.edu/nsnam/ns/.
  • 7. ¸˜ m´ ltiplos tipos de aplicacoes para verificar os dados e elaborar uma maneira de dar sen- u ` ¸˜ tido a informacao no sistema SmartBand. Como esses protocolos s˜ o definidos por meio a ¸˜ de RFCs e as aplicacoes que os implementam seguem essa proposta de padr˜ o, o processo a ¸˜ de obtencao de dados ser´ facilitado. a ¸˜ A maneira proposta para se coletar os dados, parte da utilizacao de um sniffer de a e ¸˜ rede que ir´ capturar pacotes de trˆ s diferentes tipos de aplicacoes, permitindo a hetero- geneidade de dados. A aplicacao utilizada para se capturar os pacotes e o Wireshark17 , e ¸˜ ´ ¸˜ os tipos de aplicacoes a serem monitoradas s˜ o: videoconferˆ ncia, transmiss˜ o de dados a e a via simulador de redes e fluxo de dados aleat´ rio via gerador de pacotes TCP/IP. A seguir, o ser˜ o especificados os programas e m´ todos utilizados para atingir o objetivo da coleta de a e dados. e ¸˜ O m´ todo utilizado para se adquirir dados da aplicacao de videoconferˆ ncia ser´ o e a de captura de dados por meio do sniffer Wireshark, que interceptar´ pacotes entre dois ou a ´ mais hosts que participam da conversa. O programa que suporta videoconferˆ ncia e o As- e terisk18 , um sistema de telefonia IP e PSTN completo que permite alta customizacao, que ¸˜ est´ inserido numa solucao IP-PBX open-source completa chamada Trixbox19 . Essa su´te a ¸˜ ı ser´ instalada em um servidor, e dois ou mais clientes estar˜ o executando soft-phones, a a a ¸˜ um telefone baseado em IP. Um cliente far´ uma ligacao para o outro, e ser´ iniciada a a videoconferˆ ncia, enquanto que o sniffer captura as mensagens trocadas entre os hosts. e ¸˜ O simulador de redes empregado no segundo tipo de aplicacao a monitorar e o ´ NS-2, acompanhado da extens˜ o RTPUP, que implementa, conforme a RFC 3550, o pro- a tocolo RTP [Bouras et al. 2008]. O m´ todo para se capturar tr´ fego desse simulador ser´ e a a ¸˜ ` um pouco diferente em relacao ao anterior devido a maneira como esse simulador foi concebido. Ser´ necess´ rio programar as transmiss˜ es entre hosts com base nos exemp- a a o ` los que a extens˜ o proporciona. Devido a falta de dinamismo na captura dos dados, esse a m´ todo ter´ a menor prioridade na coleta e uso dos dados. e a ´ O ultimo m´ todo para coleta de dados utilizar´ um gerador de pacotes a ser e a e ´ definido. Esse m´ todo e semelhante ao anterior, por´ m os pacotes trafegam numa rede e TCP/IP de fato, diferentemente do ambiente simulado. Com esse m´ todo ser´ poss´vel e a ı verificar o comportamento do protocolo RTCP em diversos tipos de transmiss˜ o. a ¸˜ ¸˜ 3.2. Estruturacao da informacao a a ¸˜ Nesta etapa ser´ feito um estudo de que dados ser˜ o relevantes apresentar na aplicacao SmartBand. Para serem apresentados, os dados dever˜ o ser tratados para terem relevˆ ncia a a para a pessoa que est´ acompanhando a ferramenta e fazendo auditoria. Baseado nos a ¸˜ dados coletados na etapa anterior e no estudo da RFC 3550 ser˜ o criadas equacoes de a tratamento ou algoritmos para cada um dos campos contido no pacote RTCP. Atualmente, percebe-se a necessidade de monitorar os seguintes itens, todos con- tidos impl´cita ou explicitamente no pacote RTCP: ı • N´ mero de pacotes RTP trafegados; u • Perda de pacotes decorrente de instabilidade na conex˜ o; a 17 ¸˜ Mais informacoes em: http://www.wireshark.org/ 18 Dispon´vel em: http://www.asterisk.org/. ı 19 Encontra-se dispon´vel em: http://www.trixbox.com/. ı
  • 8. • Latˆ ncia do link; e • Jitter, a variˆ ncia na latˆ ncia entre os pacotes recebidos; a e • Uso instantˆ neo de banda, decorrente da transmiss˜ o live streaming. a a Alguns itens podem ser derivados do pacote RTCP, em contrapartida outros de- e a ı ¸˜ ver˜ o ter um m´ todo de c´ lculo diferenciado, utilizando artif´cios de programacao ou a protocolo SNMP. ¸˜ 3.3. A aplicacao SmartBand ´ ¸˜ Nesta etapa e descrito o produto deste trabalho, a aplicacao SmartBand. Para atin- ¸˜ gir os objetivos especificados na introducao, como base, ser´ utilizada a linguagem de a ¸˜ ¸˜ programacao Java com uma API que permite a interpretacao de pacotes RTP/RTCP. Deste a ı ¸˜ modo, ser´ poss´vel obter dados de uma aplicacao que est´ rodando sem interferir em sua a ¸˜ ¸˜ execucao. Se fosse mantido o escopo anterior, a intervencao seria necess´ ria tornando o a a ¸˜ projeto invi´ vel para um ambiente de producao. Nos par´ grafos a seguir ser´ detalhado a a ¸˜ o funcionamento esperado da aplicacao, a maneira que ela ser´ concebida e m´ todo de a e ¸˜ execucao para se obter os dados e gerar as estat´sticas propostas. ı O funcionamento do sistema SmartBand ser´ dado em trˆ s fases: (1) identificacao a e ¸˜ a a ¸˜ autom´ tica de tr´ fego RTP para verificacao dos dados, (2) processamento e (3) ¸˜ ¸˜ apresentacao visual da informacao resultante na tela, isso tudo em tempo real. Para a ¸˜ primeira fase, a aplicacao far´ uma varredura constante de portas at´ encontrar um padr˜ o a e a RTP que possa ser monitorado. A segunda, respons´ vel pelo processamento, ser´ estrutu- a a ¸˜ rada conforme a etapa anterior, descrita na secao 3.2. Por fim, a terceira fase apresentar´a os dados tratados pela fase anterior de maneira visual atrav´ s de gr´ ficos. e a ¸˜ A aplicacao SmartBand ser´ desenvolvida na linguagem de programacao Java a ¸˜ ` acoplada a API Java.net.RTP desenvolvida pela Universidade de Columbia que permitir´ a ¸˜ ¸˜ a interpretacao e manipulacao dos dados contidos nos pacotes de controle (RTCP) gera- ¸˜ dos pelo protocolo RTP. Para estruturar a programacao ser´ utilizado o padr˜ o de design a a ´ Model-View-Controller (MVC) que permite aliar um desenvolvimento agil com um baixo o a ¸˜ acoplamento, isolando a l´ gica e a interface com o usu´ rio, realizando a intercomunicacao 20 e a e ¸˜ atrav´ s do controlador . O ciclo de desenvolvimento ter´ trˆ s iteracoes, sendo que primeiro ser´ feita a l´ gica, em seguida o design, para ent˜ o serem interligados pelo a o a controlador e o SmartBand ser testado. O controlador ser´ desenvolvido em paralelo com a os outros itens. ¸˜ 3.4. Validacao a ˆ O SmartBand somente ter´ exito total se puder ser comprovado que os dados gerados a e ¸˜ por ele est˜ o corretos. Esta etapa prevˆ a validacao do funcionamento e integridade da ¸˜ ¸˜ informacao gerada pela aplicacao. Para atingir estes objetivos ser˜ o utilizadas duas fer- a a a ¸˜ ramentas - j´ discutidas anteriormente - que far˜ o a simulacao (NS-2) e teste em um ambiente real (Asterisk). Num primeiro momento ser´ executado o simulador de redes com uma a ¸˜ ´ configuracao semelhante a que e inclu´da nos exemplos da extens˜ o RTPUP para poder ı a 20 ¸˜ Mais informacoes em: http://java.sun.com/blueprints/patterns/MVC-detailed.html.
  • 9. gerar tr´ fego, armazen´ -lo e passar offline pelo SmartBand para verificar seu funciona- a a a ¸˜ mento. Quando o sistema passar neste teste ser´ feita a validacao atrav´ s de um sistema e real em funcionamento. Ap´ s o funcionamento com os dados gerados pelo simulador o SmartBand ser´ o a colocado numa rede real rodando a su´te Trixbox, que cont´ m o programa Asterisk, para ı e ¸˜ poder verificar seu funcionamento num ambiente de producao. Este sistema estar´ config- a urado num servidor, e dois ou mais hosts estar˜ o configurados com softphones para estab- a ¸˜ ¸˜ elecerem uma comunicacao live streaming. A aplicacao SmartBand entrar´ em funciona- a mento e um dos hosts realizar´ uma chamada para outro host, que o atender´ , iniciando a a e a a ¸˜ uma videoconferˆ ncia. Ao longo desta sess˜ o, o sistema monitorar´ a comunicacao e os pacotes RTCP para gerar as estat´sticas previstas na etapa anterior. Se o SmartBand passar ı neste teste, estar´ validado. a 4. Resultados Parciais Atualmente, a metodologia foi finalizada e est´ s´ lida o suficiente para se analisar e perce- a o ´ ber que o resultado final e tang´vel. Al´ m disso, foi instalado o set-up inicial para iniciar ı e ¸˜ a execucao da metodologia, no qual consiste em duas m´ quinas virtuais, ambas com am- a biente Linux, que foram instalar com o software VMWare. Uma das m´ quinas virtuais a ser´ utilizada para executar o simulador de redes NS-2 e outra para a su´te Trixbox, e a ı a ¸˜ ambas est˜ o funcionais. Em relacao ao desenvolvimento, foi instalada a su´te contendo a ı ¸˜ ¸˜ aplicacao Eclipse, para codificacao em Java, e a esta foi incorporada a biblioteca JPCAP para testes de captura e leitura dos dados nos pacotes. ¸˜ Nos itens a seguir ser˜ o descritos os principais aspectos observados em relacao a a cada uma das etapas da metodologia. 4.1. Coleta de Dados Foi aplicado o m´ todo descrito na metodologia para a coleta de dados, mas apenas uti- e ¸˜ ¸˜ lizando a aplicacao de videoconferˆ ncia via VoIP. A aplicacao Asterisk foi executada, e e tamb´ m dois softphones em duas m´ quinas virtuais diferentes. Neste ambiente, foi efetu- e a ¸˜ ¸˜ ¸˜ ada uma ligacao, enquanto esse canal de comunicacao era monitorado. Esta ligacao tinha ¸˜ uma duracao m´ dia de 30 segundos, tempo necess´ rio para se capturar dados e poder e a descobrir um padr˜ o de tr´ fego RTP/RTCP. a a ¸˜ Por meio da utilizacao do sniffer de rede, foi poss´vel identificar o padr˜ o de ı a tr´ fego e o conte´ do dos pacotes RTCP. A ferramenta Wireshark apresenta cada um dos a u ¸˜ campos que comp˜ em o pacote na sua totalidade, facilitando a identificacao de cada um o ¸˜ dos bytes que armazenam os dados relevantes para a aplicacao. Estes dados foram pontu- ados para serem analisados pela pr´ xima etapa da metodologia. o ¸˜ O modelo proposto para o SmartBand tem uma limitacao de que dever´ sempre a ¸˜ estar vinculado ao protocolo de sinalizacao da transmiss˜ o Live Streaming, neste caso, a ´ ´ o protocolo SIP e utilizado. Como este protocolo e amplamente difundido e dispon´vel ı ¸˜ na maioria dos equipamentos que transmitem VoIP, a limitacao ser´ t´ cnica, e n˜ o de a e a ` ¸˜ a ´ funcionamento real. Devido a limitacao da biblioteca de captura de dados, n˜ o e poss´vel ı ¸˜ ¸˜ tornar a aplicacao independente do protocolo de sinalizacao, pois como esta e nenhuma ´ outra biblioteca possui captura de dados RTP/RTCP nativo, e necess´ rio analisar cada a ´ um dos pacotes UDP. Quando e detectado o pacote SIP que responde a requisicao da ¸˜
  • 10. ´ ¸˜ chamada, a porta que ir´ ocorrer a transmiss˜ o de dados e identificada via inspecao do a a pacote, e tendo esse dado, baseado na RFC, descobre-se que a porta que ir´ rodar o RTCP a ´ e a porta do RTP + 1. ¸˜ ¸˜ 4.2. Estruturacao da Informacao Ao longo da etapa de coleta de dados, foram feitas pesquisas a respeito dos dados com- plementares, que poderiam ser utilizados para agregar no processo de auditoria propor- cionado pelo SmartBand. Nesta pesquisa foi encontrado um documento de 2002, es- e ¸˜ crito por um dos integrantes da empresa Telchemy, referˆ ncia na monitoracao e gest˜ oa de servicos de VoIP e IPTV. Este documento falava de como as estat´sticas n˜ o eram rel- ¸ ı a evantes para poder medir os dados de perda de pacotes e jitter. Como este documento era baseado na antiga RFC do protocolo RTP, estes dados ser˜ o analisados posterior- a ´ mente, para ver se e relevante utilizar os dados RTCP ou encontrar uma alternativa para a ¸˜ medicao. ¸˜ Sem considerar a documentacao discutida no par´ grafo anterior, os dados que a podem e ser˜ o extra´dos dos pacotes RTCP s˜ o: a ı a • Perda de pacotes acumulada; • Porcentagem de pacotes perdidos por unidade de tempo; • Jitter; Como s˜ o poucos os dados que poder˜ o ser extra´dos do pacote RTCP, para con- a a ı seguir todos os dados para as estat´sticas dever´ ser feito um estudo se a ferramenta de- ı a pender´ de outros servicos como SNMP ou se todas rotinas ser˜ o implementadas do zero a ¸ a ¸˜ na aplicacao. ¸˜ 4.3. A aplicacao SmartBand Nesta etapa, foram feitos testes com a biblioteca JPCAP e estipulado a biblioteca gr´ fica a 21 a ser utilizada, a jFreeChart . ¸˜ ` Com relacao a biblioteca JPCAP, primeiro, foi feito o teste para a captura de todos os pacotes UDP, tentando identificar o pacote SIP que responde o in´cio da chamada e ı antecede a troca de tr´ fego RTP e RTCP. Ent˜ o, foi pego o n´ mero da porta RTP, contido a a u no pacote SIP, que seria iniciado a transmiss˜ o e somado uma unidade para descobrir a a porta que trafega RTCP (RFC). De posse da conex˜ o RTCP, foi poss´vel fazer chamadas a ı byte a byte para fazer testes se os dados capturados pelo sniffer coincidiam com os dados capturados via biblioteca de captura. Este teste destina-se a verificar com a aplicacao ¸˜ proceder´ para auxiliar na auditoria da transmiss˜ o Live streaming. a a ´ Foi estipulado o uso da biblioteca jFreeChart devido a otimas experiˆ ncias anterior e ¸˜ ¸˜ ¸˜ a ´ para criacao, geracao e atualizacao de gr´ ficos. Com esta biblioteca e poss´vel gerar os ı mais variados tipos de gr´ ficos, e em tempo real - uma necessidade do projeto. a ¸˜ 4.4. Validacao ¸˜ a Como a aplicacao n˜ o foi finalizada, esta etapa n˜ o entrou em pleno funcionamento. A a ´ ¸˜ e a ´ unica validacao existente, at´ ent˜ o e se os dados capturados est˜ o corretos. a 21 ¸˜ Mais informacoes em: http://www.jfree.org/jfreechart/.
  • 11. 5. Conclus˜ o a ¸˜ Nesta producao foram abordados os amplos aspectos te´ ricos e metodol´ gicos sobre a o o ¸˜ criacao do sistema de auditoria para transmiss˜ es live streaming, o SmartBand. Para isso, o foram descritas cada uma das etapas necess´ rias de estudo e desenvolvimento envolvidas a neste processo. O projeto SmartBand teve seu escopo alterado ap´ s uma an´ lise de viabilidade o a que deixou claro que n˜ o seria poss´vel atingir o resultado do projeto da maneira que a ı era proposta. Com o escopo alterado, as revis˜ es bibliogr´ ficas e metodologias tiveram o a ¸˜ que ser reformuladas por completo, no entanto esta reformulacao trouxe mais clareza e objetividade ao projeto. Neste documento foi apresentado todo o desenvolvimento necess´ rio para aa ¸˜ concretizacao de um sistema para auditoria em transmiss˜ es Live Streaming, nomeado o a´ SmartBand. Apesar de ainda estar em desenvolvimento, j´ e poss´vel obter alguns dados ı derivados da transmiss˜ o. Mas, falta ainda obter mais dados, e trat´ -los para dar contexto a a ı ¸˜ e prover as estat´sticas previstas pela aplicacao, para ent˜ o concluir o desenvolvimento da a ¸˜ ¸˜ interface da aplicacao e iniciar a validacao. ´ ¸˜ O pr´ ximo trabalho a ser realizado e finalizar a etapa de obtencao de dados e o ¸˜ ¸˜ iniciar a etapa de estruturacao da informacao. Ao longo deste desenvolvimento, ser´ a ¸˜ criada a interface da aplicacao, para ent˜ o interligar com cada uma de suas partes. Ap´ s a o a a ¸˜ a conclus˜ o das etapas anteriores, ser´ iniciada a etapa de validacao do SmartBand. References Apostolopoulos, J., Tan, W., and Wee, S. (2002). Video Streaming: Concepts, Algorithms, and Systems. HP Laboratories Palo Alto. Bouras, C., Gkamas, A., and Kioumourtzis, G. (2008). Extending the Functionality of RTP/RTCP Implementation in Network Simulator (NS-2) to support TCP friendly con- gestion control. University of Patras. Coventry, L. (1998). Video conferencing in higher education. Institute for Computer Based Learning, Warriot University. Firmo, R. M. (2003). Educacao & Tecnologia, volume 8 of 2. Packt Publishing. ¸˜ Fischer, G. S. (2000). Um ambiente virtual para multim´dia de ensino na Web, com ı transmiss˜ o ao vivo e interatividade. PPGC da UFRGS. a Meggelen, J., Smith, J., and Madsen, L. (2005). Asterisk: The future of telephony. O’Reilly Books. Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. (1996). RTP: A Transport Protocol for Real-Time Applications. RFC 1889 - obsolete. Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. (2003). RTP: A Transport Protocol for Real-Time Applications. RFC 3550. Topic, M. (2002). Streaming Media Demystified. McGraw-Hill. Velos, E., Almeida, V., Meira, W., Bestravos, A., and Jin, S. (2002). A hierarchical char- acterization of a live streaming media workload. In Internet Measurement Workshop, pages 117–130. IEEE.

×