SmartBand: Sistema de auditoria para transmissoes LiveStreaming

Maurıcio Bento Ghem1

1Engenharia da Computacao - Universidade do Vale do Rio dos Sinos (UNISINOS)Caixa postal 275 – 93.022-000 – Sao Leopoldo – RS – Brazil

Mauricio@Bentow.org

Abstract. The Live Streaming brought new functionalities to the interaction andcommunication among the users on the Internet, an example of applicationwould be the videoconference. Due to a lack of specialized tools to monitorand 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 thetransmissions of information based on a Live Streaming system. In the currentstage of the research, data was collected to be analyzed by the next stage, whichwill define which items will be audited. The following stages will be responsiblefor the implementation and validation of the SmartBand system.

Resumo. O Live Streaming trouxe novas funcionalidades para a interacao ecomunicacao entre usuarios na Internet, um exemplo de aplicacao seria a video-conferencia. Devido a carencia de ferramentas especializadas no acompan-hamento e auditoria de transmissoes Live Streaming, o presente trabalho temcomo objetivo desenvolver uma aplicacao de redes que possibilite a auditoriana transmissao de informacoes baseadas num sistema Live Streaming. Nestaetapa da pesquisa foram coletados dados que serao analisados pela proximaetapa, que definira quais os itens a serem auditados. As etapas seguintes seraoresponsaveis pela implementacao e validacao do sistema SmartBand.

1. Introducao

O Live Streaming [Velos et al. 2002] e todo conteudo audiovisual capturado em temporeal e disponibilizado para inumeros espectadores via Internet. Esse conceito e aplicadoem diversas aplicacoes, tais como a de videoconferencia, entretenimento e educacao adistancia (EaD), que vem crescendo ao longo dos anos por proporcionar muitos benefıciosse comparada ao ensino presencial [Fischer 2000]. Hoje, o meio mais comum parase utilizar essa modalidade e um ambiente de ensino que contempla apostilas, forunse conversacoes. Muitos desses ambientes carecem do contato ao vivo com o instru-tor/professor [Firmo 2003].

O projeto Convergencia Digital1, no qual este trabalho de conclusao de curso estainserido, trata de permitir a maior interatividade possıvel do usuario com um meio deacesso. Nesse contexto e na atual etapa na qual o projeto se encontra, percebeu-se anecessidade de se criar um sistema Web para interacao aluno-professor utilizando-se um

1O projeto Convergencia Digital tem como objetivo a criacao de aplicacoes interativas para a TV Digital.E coordenado pelo prof. Joao Bittencourt, e o projeto e executado e patrocinado pela UNISINOS.

ambiente baseado na videoconferencia. E importante destacar que a EaD e um exemplo deaplicacao de transmissao de audiovisual em tempo real (Live Streaming) [Coventry 1998].

Em sua concepcao, o SmartBand tinha como objetivo ser um protocolo de geren-ciamento de transmissao das informacoes que funcionaria proativamente selecionando amelhor stream baseado na largura de banda que o usuario possui. Este trabalho era di-vidido em tres etapas, sendo elas, respectivamente: estudo, definicao e implementacao.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-missao Live Streaming em funcionamento. Para que esse protocolo pudesse funcionar,seria necessario criar uma aplicacao especıfica que tivesse as interfaces necessarias parapermitir seu acoplamento. Como este projeto se tornaria inviavel, o escopo do SmartBandfoi alterado para o atual.

Apos a revisao de escopo, este trabalho tem como objetivo criar a aplicacao Smart-Band (SmB), que fara auditoria na transmissao de informacoes por meio da Internetvisando a melhor qualidade de servico para o usuario na recepcao de audio e vıdeo emtempo real. O SmB possibilitara a visualizacao em tempo real de estatısticas relacionadasa utilizacao da banda, ao atraso na transmissao e outros dados relevantes que possam ser,posteriormente, analisados e utilizados para proporcionar aos usuarios um servico melhor,tanto na transmissao quanto na conectividade com a rede.

Este relatorio apresenta o desenvolvimento parcial do sistema descrito acima e estaestruturado da seguinte forma: a secao 2 apresenta todos os conceitos e bibliotecas queprecisam ser dominados para a criacao da aplicacao; a secao 3 apresenta a metodologia doprojeto, apresentando cada um dos objetivos especıficos; a secao 4 apresenta os resultadosobtidos ate o momento, e na ultima secao, e apresentada uma breve conclusao e a projecaodas proximas etapas.

2. Revisao Bibliografica

Nesta secao, serao abordados os principais temas que compoem a revisao bibliografica dotrabalho ate o presente momento. Tambem, serao apresentados topicos que serao apro-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 pedacospara envia-los um a um sucessivamente, sendo que o receptor decodificara cada parte ea executara sem ter que esperar por todo o fluxo de dados [Apostolopoulos et al. 2002].Essa tecnologia existe desde que as transmissoes por radio e televisao analogica foraminventadas. O equipamento do espectador, desde aqueles tempos, recebia dados contin-uamente, sendo que simultaneamente esses dados eram apresentados, seja na tela ou nascaixas de som [Topic 2002]. Hoje em dia, esse conceito de streaming foi migrado para aInternet, preservando alguns princıpios de antigamente, como o de oferecer conteudo sobdemanda para o usuario.

Em relacao ao conteudo estatico, que e necessario ter em sua totalidade para serıntegro, o streaming tem uma grande vantagem, pois e possıvel acessar um conteudo sobdemanda. Conforme o conteudo e executado as partes seguintes estao sendo recebidas,

executadas, e assim sucessivamente. Hoje em dia, grandes websites utilizam esta tec-nologia como um servico. O Youtube2, por exemplo, recebe uma mıdia estatica e a tornadisponıvel como um fluxo de dados para ser acessada sob demanda.

A evolucao desta tecnologia e a chamada Live Streaming que possibilita a trans-missao ao vivo de uma mıdia. Com esta tecnologia e possıvel enviar, diretamente, para aInternet um vıdeo capturado por uma camera sem ter que armazena-lo. Esta evolucao per-mite que as emissoras transmitam via Internet eventos, programas e radios em tempo real,permitindo o aumento no numero de espectadores que assistem ou escutam seus progra-mas. Porem, a transmissao em tempo real nao foi a maior aplicacao para esta tecnologia,e sim a videoconferencia que foi amplamente difundida por meio de programas comoSkype3. A videoconferencia trouxe uma enorme quebra de paradigma, possibilitando quepessoas conversem frente a frente estando em qualquer lugar do mundo.

Tanto o streaming quanto o live streaming podem ser implementados de muitasmaneiras. Uma das mais eficientes, e nao proprietaria e utilizando um codec para com-primir a mıdia e transmiti-la para os usuarios via protocolo RTP (Real-time TransportProtocol) [Schulzrinne et al. 2003] que roda em cima do protocolo de transporte UDP4,que nao e orientado a conexao. Aliado ao RTP, o protocolo RTCP (Real-time Control Pro-tocol) permite controle e geracao de estatısticas da transmissao. Existem implementacoesque utilizam o TCP5 como protocolo de transporte, multiplexando na mesma conexao oprotocolo 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)18896 [Schulzrinne et al. 1996], mas ao longo do tempo foi aprimorado e em 2003 foicriada 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 meiode multicast ou unicast. Este protocolo nao garante a qualidade do servico (QoS) paratransmissoes em tempo real, por isso funciona em conjunto com o RTCP que permitemonitorar a entrega, gerar estatısticas dos dados, e identificar os usuarios que os recebem- numa rede multicast - proporcionando dados para o administrador analisar e realizaruma melhora no servico.

Existem diversas aplicacoes que entregam conteudo multimıdia em tempo realque rodam sob o protocolo RTP, tais como: Cisco IPTV, Asterisk Video Call, QuicktimeStreaming Server e Shoutcast Webradio. Em contrapartida, outras grandes empresas op-taram por desenvolver um protocolo de transporte proprietario, algumas aplicacoes sao: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

2Mais informacoes em: http://www.youtube.com/t/about.3Disponıvel em http://www.skype.com.4User Datagram Protocol. Mais informacoes em: http://www.faqs.org/rfcs/rfc768.html.5Transmission Control Protocol. Mais informacoes em: http://www.faqs.org/rfcs/rfc793.html.6Disponıvel em: http://www.ietf.org/rfc/rfc1889.txt.7Disponıvel em: http://www.faqs.org/rfcs/rfc3550.html.

algoritmos utilizados para calcular jitter [Meggelen et al. 2005] e atraso, e do calculo dostempos para envio e recebimento das mensagens. O RTCP e bidirecional, ou seja, pacotessao enviados da origem de conteudo para o destino e vice-versa. O pacote RTCP tem umformato padrao, este e resumido na figura 18, porem recebe diferentes conteudos depen-dendo do papel do host na rede. Se ele e a origem dos dados, e incluıdo no pacote umsender report, como pode ser visto na figura 2 9. Caso o papel do host seja de destinatario,este enviara um receiver report com diferentes tipos de dados, como apresentado na figura310. Os dados contidos neste pacote serao de extremo valor para os calculos e estatısticasgerados pelo sistema SmartBand.

Figure 1. O pacote RTCP.

Figure 2. O sender report inserido dentro do pacote RTCP.

2.3. O Protocolo SIPO protocolo SIP11 foi especificado na RFC 326112, e e considerado um protocolo desinalizacao, que roda na camada de aplicacao, que engloba a criacao, modificacao efinalizacao de uma sessao entre um e/ou mais participantes. Estas sessoes incluemligacoes via Internet, conferencias e distribuicao de multimıdia. Como o SIP e um pro-tocolo que engloba apenas a sinalizacao, e necessario um protocolo que possibilite otransporte da informacao fim-a-fim, neste contexto, o RTP e empregado.

8A figura esta disponıvel em: http://java.sun.com/javase/technologies/desktop/media/jmf/2.1.1/guide/images/RTPRealTime2.gif

9A figura esta disponıvel em: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-ments/images/rtcp sr header.jpg

10A figura esta disponıvel em: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu-ments/images/rtcp rr header.jpg

11Acronimo de Session Initiation Protocol. RFC disponıvel em: http://www.ietf.org/rfc/rfc3261.txt.12Disponıvel em: http://www.ietf.org/rfc/rfc3261.txt.

Figure 3. O receiver report inserido dentro do pacote RTCP.

A topologia convencional para uso do protocolo SIP e apresentada na figura 4, naqual 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 nomodelo do HTTP de mensagens, sendo enviada uma requisicao chamando determinadometodo ou funcao do servidor. Para a aplicacao SmartBand, sera relevante o pacote deresposta que invoca o metodo ’INVITE’, no qual requisita o inıcio de uma sessao comoutro dispositivo. Este pacote tem um formato unico, e por meio dele que sera descobertoo numero da porta RTP.

Este pacote de resposta a chamada SIP INVITE e composto dos dados SIP in-cluindo outro protocolo descrito na RFC 232714, chamado de SDP (Session DescriptionProtocol). Por meio dos dados incluıdos no SDP, e possıvel identificar todos os dados dasessao, tais como: numero de porta de origem e destino para a transmissao RTP, codecutilizado, tipo de sessao (voz ou vıdeo), e informacoes de cada um dos componentes dasessao. Utilizando os dados do SDP sera possıvel monitorar os dados gerados via RTCP.

2.4. A biblioteca JPCAP

A JPCAP15 e uma biblioteca disponıvel para Java que permite a captura e o envio dequadros e pacotes de rede. Os tipos de dados que podem ser gerados e capturados nativa-mente pela biblioteca sao: Ethernet, IPv4, IPv6, ARP/RARP, TCP, UDP e ICMP. Ela foiconcebida num projeto do professor Tatsuya Suda, que atua na Universidade da CaliforniaIrvine.

13Disponıvel em: http://www.faqs.org/rfcs/rfc2822.html.14Mais informacoes em: http://www.ietf.org/rfc/rfc2327.txt.15Mais informacoes em: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html.

Dentre as outras bibliotecas disponıveis que desempenhassem essa funcao, foiescolhido essa devido a facilidade de uso, suporte aos protocolos necessarios e por teruma comunidade que da suporte e apoio a duvidas. Porem, tanto esta quanto as outrasbibliotecas nao dao suporte nativo ao protocolo RTP/RTCP, sendo necessario manipulareste 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. Elee 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 SenseMultiple Access with Collision Detection) da camada de enlace. Alem disso, suporta odesenvolvimento de extensoes e novos protocolos que sao incorporados a esta ferramentapara serem validados cientificamente16.

Devido as limitacoes que o protocolo RTP nativo do NS-2 possui - como naoincorporar o protocolo de controle (RTCP) - a Universidade de Patras criou uma extensaodo protocolo RTP contida no NS-2, chamado de RTPUP [Bouras et al. 2008], incluindogrande parte dos conceitos definidos na RFC 3550, incluindo o RTCP. Desta maneira, epossıvel utilizar o NS-2 em conjunto com esta implementacao do RTP para gerar dadosfictıcios e verificar o comportamento do SmartBand.

3. MetodologiaNesta secao, sera apresentada a metodologia modificada desde que o escopo do projetofoi alterado. Esta metodologia e tal que permite atingir o objetivo geral proposto naintroducao.

O presente trabalho foi dividido em quatro grandes etapas, cada uma delas con-templando os objetivos especıficos, que sao: medicao e obtencao de informacoes de umarede ao longo de uma transmissao Live Streaming, definicao de equacoes ou algoritmospara obtencao de dados estatısticos, criacao de um prototipo da ferramenta proposta e suavalidacao. A primeira etapa e responsavel pela coleta de dados oriundos do protocolode controle, o RTCP, que roda em paralelo com o RTP. Na segunda etapa, com base nosconceitos estudados e no resultado da etapa anterior, serao definidos o tipo e a estruturaque a informacao tera para ser apresentada na aplicacao. Na terceira etapa, ocorrera odesenvolvimento da aplicacao, que fara o monitoramento para gerar estatısticas e dadosrelevantes para auditoria da transmissao. A quarta e ultima etapa contemplara a validacaodo sistema como um todo.

Cada uma dessas etapas sera descrita a seguir.

3.1. Coleta de Dados

Para se desenvolver a aplicacao final, sera necessario interagir com os pacotes gera-dos pelo protocolo RTCP, que atua em conjunto com o RTP. Devido a quantidade deinformacao contida no pacote RTCP, sera feita uma coleta de dados proveniente de

16O NS-2 e disponibilizado no site: http://www.isi.edu/nsnam/ns/.

multiplos tipos de aplicacoes para verificar os dados e elaborar uma maneira de dar sen-tido a informacao no sistema SmartBand. Como esses protocolos sao definidos por meiode RFCs e as aplicacoes que os implementam seguem essa proposta de padrao, o processode obtencao de dados sera facilitado.

A maneira proposta para se coletar os dados, parte da utilizacao de um sniffer derede que ira capturar pacotes de tres diferentes tipos de aplicacoes, permitindo a hetero-geneidade de dados. A aplicacao utilizada para se capturar os pacotes e o Wireshark17, eos tipos de aplicacoes a serem monitoradas sao: videoconferencia, transmissao de dadosvia simulador de redes e fluxo de dados aleatorio via gerador de pacotes TCP/IP. A seguir,serao especificados os programas e metodos utilizados para atingir o objetivo da coleta dedados.

O metodo utilizado para se adquirir dados da aplicacao de videoconferencia sera ode captura de dados por meio do sniffer Wireshark, que interceptara pacotes entre dois oumais hosts que participam da conversa. O programa que suporta videoconferencia e o As-terisk18, um sistema de telefonia IP e PSTN completo que permite alta customizacao, queesta inserido numa solucao IP-PBX open-source completa chamada Trixbox19. Essa suıtesera instalada em um servidor, e dois ou mais clientes estarao executando soft-phones,um telefone baseado em IP. Um cliente fara uma ligacao para o outro, e sera iniciada avideoconferencia, enquanto que o sniffer captura as mensagens trocadas entre os hosts.

O simulador de redes empregado no segundo tipo de aplicacao a monitorar e oNS-2, acompanhado da extensao RTPUP, que implementa, conforme a RFC 3550, o pro-tocolo RTP [Bouras et al. 2008]. O metodo para se capturar trafego desse simulador seraum pouco diferente em relacao ao anterior devido a maneira como esse simulador foiconcebido. Sera necessario programar as transmissoes entre hosts com base nos exemp-los que a extensao proporciona. Devido a falta de dinamismo na captura dos dados, essemetodo tera a menor prioridade na coleta e uso dos dados.

O ultimo metodo para coleta de dados utilizara um gerador de pacotes a serdefinido. Esse metodo e semelhante ao anterior, porem os pacotes trafegam numa redeTCP/IP de fato, diferentemente do ambiente simulado. Com esse metodo sera possıvelverificar o comportamento do protocolo RTCP em diversos tipos de transmissao.

3.2. Estruturacao da informacao

Nesta etapa sera feito um estudo de que dados serao relevantes apresentar na aplicacaoSmartBand. Para serem apresentados, os dados deverao ser tratados para terem relevanciapara a pessoa que esta acompanhando a ferramenta e fazendo auditoria. Baseado nosdados coletados na etapa anterior e no estudo da RFC 3550 serao criadas equacoes detratamento 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:

• Numero de pacotes RTP trafegados;• Perda de pacotes decorrente de instabilidade na conexao;

17Mais informacoes em: http://www.wireshark.org/18Disponıvel em: http://www.asterisk.org/.19Encontra-se disponıvel em: http://www.trixbox.com/.

• Latencia do link;• Jitter, a variancia na latencia entre os pacotes recebidos;• Uso instantaneo de banda, decorrente da transmissao live streaming.

Alguns itens podem ser derivados do pacote RTCP, em contrapartida outros de-verao ter um metodo de calculo diferenciado, utilizando artifıcios de programacao ouprotocolo 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, sera utilizada a linguagem deprogramacao Java com uma API que permite a interpretacao de pacotes RTP/RTCP. Destemodo, sera possıvel obter dados de uma aplicacao que esta rodando sem interferir em suaexecucao. Se fosse mantido o escopo anterior, a intervencao seria necessaria tornando oprojeto inviavel para um ambiente de producao. Nos paragrafos a seguir sera detalhadoo funcionamento esperado da aplicacao, a maneira que ela sera concebida e metodo deexecucao para se obter os dados e gerar as estatısticas propostas.

O funcionamento do sistema SmartBand sera dado em tres fases: (1) identificacaoautomatica de trafego RTP para verificacao dos dados, (2) processamento e (3)apresentacao visual da informacao resultante na tela, isso tudo em tempo real. Para aprimeira fase, a aplicacao fara uma varredura constante de portas ate encontrar um padraoRTP que possa ser monitorado. A segunda, responsavel pelo processamento, sera estrutu-rada conforme a etapa anterior, descrita na secao 3.2. Por fim, a terceira fase apresentaraos dados tratados pela fase anterior de maneira visual atraves de graficos.

A aplicacao SmartBand sera desenvolvida na linguagem de programacao Javaacoplada a API Java.net.RTP desenvolvida pela Universidade de Columbia que permitiraa interpretacao e manipulacao dos dados contidos nos pacotes de controle (RTCP) gera-dos pelo protocolo RTP. Para estruturar a programacao sera utilizado o padrao de designModel-View-Controller (MVC) que permite aliar um desenvolvimento agil com um baixoacoplamento, isolando a logica e a interface com o usuario, realizando a intercomunicacaoatraves do controlador20. O ciclo de desenvolvimento tera tres iteracoes, sendo queprimeiro sera feita a logica, em seguida o design, para entao serem interligados pelocontrolador e o SmartBand ser testado. O controlador sera desenvolvido em paralelo comos outros itens.

3.4. Validacao

O SmartBand somente tera exito total se puder ser comprovado que os dados geradospor ele estao corretos. Esta etapa preve a validacao do funcionamento e integridade dainformacao gerada pela aplicacao. Para atingir estes objetivos serao utilizadas duas fer-ramentas - ja discutidas anteriormente - que farao a simulacao (NS-2) e teste em umambiente real (Asterisk).

Num primeiro momento sera executado o simulador de redes com umaconfiguracao semelhante a que e incluıda nos exemplos da extensao RTPUP para poder

20Mais informacoes em: http://java.sun.com/blueprints/patterns/MVC-detailed.html.

gerar trafego, armazena-lo e passar offline pelo SmartBand para verificar seu funciona-mento. Quando o sistema passar neste teste sera feita a validacao atraves de um sistemareal em funcionamento.

Apos o funcionamento com os dados gerados pelo simulador o SmartBand seracolocado numa rede real rodando a suıte Trixbox, que contem o programa Asterisk, parapoder verificar seu funcionamento num ambiente de producao. Este sistema estara config-urado num servidor, e dois ou mais hosts estarao configurados com softphones para estab-elecerem uma comunicacao live streaming. A aplicacao SmartBand entrara em funciona-mento e um dos hosts realizara uma chamada para outro host, que o atendera, iniciandouma videoconferencia. Ao longo desta sessao, o sistema monitorara a comunicacao e ospacotes RTCP para gerar as estatısticas previstas na etapa anterior. Se o SmartBand passarneste teste, estara validado.

4. Resultados ParciaisAtualmente, a metodologia foi finalizada e esta solida o suficiente para se analisar e perce-ber que o resultado final e tangıvel. Alem disso, foi instalado o set-up inicial para iniciara execucao da metodologia, no qual consiste em duas maquinas virtuais, ambas com am-biente Linux, que foram instalar com o software VMWare. Uma das maquinas virtuaissera utilizada para executar o simulador de redes NS-2 e outra para a suıte Trixbox, eambas estao funcionais. Em relacao ao desenvolvimento, foi instalada a suıte contendo aaplicacao Eclipse, para codificacao em Java, e a esta foi incorporada a biblioteca JPCAPpara testes de captura e leitura dos dados nos pacotes.

Nos itens a seguir serao descritos os principais aspectos observados em relacao acada uma das etapas da metodologia.

4.1. Coleta de DadosFoi aplicado o metodo descrito na metodologia para a coleta de dados, mas apenas uti-lizando a aplicacao de videoconferencia via VoIP. A aplicacao Asterisk foi executada, etambem dois softphones em duas maquinas virtuais diferentes. Neste ambiente, foi efetu-ada uma ligacao, enquanto esse canal de comunicacao era monitorado. Esta ligacao tinhauma duracao media de 30 segundos, tempo necessario para se capturar dados e poderdescobrir um padrao de trafego RTP/RTCP.

Por meio da utilizacao do sniffer de rede, foi possıvel identificar o padrao detrafego e o conteudo dos pacotes RTCP. A ferramenta Wireshark apresenta cada um doscampos que compoem o pacote na sua totalidade, facilitando a identificacao de cada umdos bytes que armazenam os dados relevantes para a aplicacao. Estes dados foram pontu-ados para serem analisados pela proxima etapa da metodologia.

O modelo proposto para o SmartBand tem uma limitacao de que devera sempreestar vinculado ao protocolo de sinalizacao da transmissao Live Streaming, neste caso,o protocolo SIP e utilizado. Como este protocolo e amplamente difundido e disponıvelna maioria dos equipamentos que transmitem VoIP, a limitacao sera tecnica, e nao defuncionamento real. Devido a limitacao da biblioteca de captura de dados, nao e possıveltornar a aplicacao independente do protocolo de sinalizacao, pois como esta e nenhumaoutra biblioteca possui captura de dados RTP/RTCP nativo, e necessario analisar cadaum dos pacotes UDP. Quando e detectado o pacote SIP que responde a requisicao da

chamada, a porta que ira ocorrer a transmissao de dados e identificada via inspecao dopacote, e tendo esse dado, baseado na RFC, descobre-se que a porta que ira rodar o RTCPe 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-crito por um dos integrantes da empresa Telchemy, referencia na monitoracao e gestaode servicos de VoIP e IPTV. Este documento falava de como as estatısticas nao eram rel-evantes para poder medir os dados de perda de pacotes e jitter. Como este documentoera baseado na antiga RFC do protocolo RTP, estes dados serao analisados posterior-mente, para ver se e relevante utilizar os dados RTCP ou encontrar uma alternativa para amedicao.

Sem considerar a documentacao discutida no paragrafo anterior, os dados quepodem e serao extraıdos dos pacotes RTCP sao:

• Perda de pacotes acumulada;• Porcentagem de pacotes perdidos por unidade de tempo;• Jitter;

Como sao poucos os dados que poderao ser extraıdos do pacote RTCP, para con-seguir todos os dados para as estatısticas devera ser feito um estudo se a ferramenta de-pendera de outros servicos como SNMP ou se todas rotinas serao implementadas do zerona aplicacao.

4.3. A aplicacao SmartBand

Nesta etapa, foram feitos testes com a biblioteca JPCAP e estipulado a biblioteca graficaa ser utilizada, a jFreeChart21.

Com relacao a biblioteca JPCAP, primeiro, foi feito o teste para a captura de todosos pacotes UDP, tentando identificar o pacote SIP que responde o inıcio da chamada eantecede a troca de trafego RTP e RTCP. Entao, foi pego o numero da porta RTP, contidono pacote SIP, que seria iniciado a transmissao e somado uma unidade para descobrir aporta que trafega RTCP (RFC). De posse da conexao RTCP, foi possıvel fazer chamadasbyte a byte para fazer testes se os dados capturados pelo sniffer coincidiam com os dadoscapturados via biblioteca de captura. Este teste destina-se a verificar com a aplicacaoprocedera para auxiliar na auditoria da transmissao Live streaming.

Foi estipulado o uso da biblioteca jFreeChart devido a otimas experiencias anteriorpara criacao, geracao e atualizacao de graficos. Com esta biblioteca e possıvel gerar osmais variados tipos de graficos, e em tempo real - uma necessidade do projeto.

4.4. Validacao

Como a aplicacao nao foi finalizada, esta etapa nao entrou em pleno funcionamento. Aunica validacao existente, ate entao e se os dados capturados estao corretos.

21Mais informacoes em: http://www.jfree.org/jfreechart/.

5. ConclusaoNesta producao foram abordados os amplos aspectos teoricos e metodologicos sobre acriacao do sistema de auditoria para transmissoes live streaming, o SmartBand. Para isso,foram descritas cada uma das etapas necessarias de estudo e desenvolvimento envolvidasneste processo.

O projeto SmartBand teve seu escopo alterado apos uma analise de viabilidadeque deixou claro que nao seria possıvel atingir o resultado do projeto da maneira queera proposta. Com o escopo alterado, as revisoes bibliograficas e metodologias tiveramque ser reformuladas por completo, no entanto esta reformulacao trouxe mais clareza eobjetividade ao projeto.

Neste documento foi apresentado todo o desenvolvimento necessario para aconcretizacao de um sistema para auditoria em transmissoes Live Streaming, nomeadoSmartBand. Apesar de ainda estar em desenvolvimento, ja e possıvel obter alguns dadosderivados da transmissao. Mas, falta ainda obter mais dados, e trata-los para dar contextoe prover as estatısticas previstas pela aplicacao, para entao concluir o desenvolvimento dainterface da aplicacao e iniciar a validacao.

O proximo trabalho a ser realizado e finalizar a etapa de obtencao de dados einiciar a etapa de estruturacao da informacao. Ao longo deste desenvolvimento, seracriada a interface da aplicacao, para entao interligar com cada uma de suas partes. Aposa conclusao das etapas anteriores, sera iniciada a etapa de validacao do SmartBand.

ReferencesApostolopoulos, 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 ofRTP/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 ComputerBased 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, comtransmissao ao vivo e interatividade. PPGC da UFRGS.

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 TransportProtocol for Real-Time Applications. RFC 1889 - obsolete.

Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. (2003). RTP: A TransportProtocol 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.