Administração de Videoconferência

Administrao de
Videoconferncia
Graciela M. L. Martins Leonardo Daronco Valter Roesler
Administrao de
Videoconferncia
Administrao de
Videoconferncia
Rio de Janeiro Escola Superior de Redes 2013
Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP Rua Lauro Mller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho
Escola Superior de Redes

Coordenao
Luiz Coelho
Edio
Pedro Sangirardi
Coordenao Acadmica de Mdias de Suporte Colaborao Digital
Renato Duarte
Equipe ESR (em ordem alfabtica)
Celia Maciel, Cristiane Oliveira, Derlina Miranda, Edson Kowask, Elimria Barbosa, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato e Sergio de Souza
Capa, projeto visual e diagramao
Tecnodesign
Verso
3.0.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuio
Rua Lauro Mller, 116 sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP) M381a Martins, Graciela M. L. Administrao de Videoconferncia / Graciela M. L. Martins, Valter Roesler; Colaborao de Daniel Weber e Leonardo Daronco. 3. ed. Rio de Janeiro: RNP/ESR, 2011. 290 p. : il. ; 28 cm. Bibliografia: p. 273-274. ISBN 978-85-63630-14-8
1. Videoconferncia. 2. Transmisso de udio e vdeo. 3. Padres de vdeo. I. Roesler, Valter. II. Weber, Daniel. III. Daronco, Leonardo. IV. Ttulo. CDD 006.7
Sumrio
1. Conceitos fundamentais e solues
Histrico da videoconferncia1 Videoconferncia hoje3 Definio de videoconferncia4 Objetivos da videoconferncia 4 Elementos de uma video/webconferncia5 Tipos de videoconferncia7 Sistemas dedicados7 Sistemas de mesa8 Sistemas de webconferncia9 Cenrios: Ensino a Distncia (EAD)10 Cenrios: reunies de trabalho11 Cenrios: telepresena12 Cenrios: Telemedicina12 Dispositivos adicionais13 Cmera de documentos13 Quadro interativo14 Sistemas com alta definio15 Relao de aspecto16 Estruturao de um servio17 Roteiro de Atividades 121 Atividade 1 Sistema de conferncia em desktop21 Atividade 2 Funcionalidades do sistema21 Atividade 3 Medindo o atraso da transmisso22 iii
2. Padres de videoconferncia
Introduo a padres e protocolos23 Padronizao23 Princpios de codificao de udio24 Padres de udio27 Princpios de codificao de vdeo28 Redundncia espacial29 Redundncia temporal30 Redundncia psicovisual30 Redundncia de codificao (entrpica)31 Padres de vdeo31 H.26433 MPEG33 Padres de dados35 Padres de comunicao 36 Padro H.32036 Padro H.32337 Multipoint Control Unit (MCU)39 Gateway40 Gatekeeper41 Elementos de borda43 Protocolos da arquitetura H.32343 Protocolos RTP e RTCP44 Protocolo H.225 RAS46 Protocolo H.225 sinalizao de chamada49 Protocolo H.24550 Procedimentos de uma conexo H.32354 Padres para servios 57 Roteiro de Atividades 259 Atividade 1 Anlise de troca de mensagens direta entre dois clientes 59 Atividade 2 Anlise de troca de mensagens entre dois clientes com gatekeeper60
3. Plano de numerao e gatekeeper

Padro ITU E.16461 iv
Plano de numerao62 Plano de discagem63 Gatekeeper GnuGK64 Instalao do GnuGK65 Inicializao do GnuGK65 GnuGK no Windows66 Configurao do GnuGK (Windows, Linux e outros)66 Monitoramento do GnuGK68 Zoneamento70 Hierarquia de gatekeepers72 Mensagens LRQ73 Reescrita de nmeros E.16475 Autenticao77 Contabilizao81 Modos de operao83 Modo direto83 Modo roteamento84 Modo proxy84 Roteiro de Atividades 389 Atividade 1 Configurando o cliente e efetuando chamadas89 Atividade 2 Configurando GnuGK para conexo de clientes autorizados89 Atividade 3 Habilitando modo proxy90 Atividade 4 Configurando o DGK na rede90
4. Introduo ao SIP
Session Initiation Protocol (SIP)93 Arquitetura do SIP94 Mensagens e respostas SIP97 Registro SIP100 Diagrama de uma chamada SIP101 Comparao SIP e H.323102 OpenSIPS103 Instalao OpenSIPS 104 Inicializao OpenSIPS 104 v
Arquitetura modular OpenSIPS 106 Configurao OpenSIPS 107 Lgica de roteamento108 Modos de operao OpenSIPS 109 Integrao com banco de dados OpenSIPS 111 Localizao de usurios OpenSIPS 113 Plano de discagem OpenSIPS 113 Autenticao de clientes OpenSIPS 115 Contabilizao OpenSIPS 117 Gerao de logs OpenSIPS 118 Roteiro de Atividades 4121 Atividade 1 Ligao SIP atravs do X-Lite121 Atividade 2 Configurao e utilizao de um servidor SIP: OpenSIPS121 Atividade 3 Incluir validao de usurios no OpenSIPS122
5. Redes de computadores e videoconferncia

Infraestrutura bsica de redes125 Formas de trfego de redes para videoconferncia126 Ponto-a-ponto126 Multiponto127 Trfego unicast129 Trfego broadcast129 Trfego multicast130 Multiponto: unicast x multicast130 Multicast132 Portas e protocolos dos padres H.323 e SIP134 Uso de firewalls em videoconferncia135 Videoconferncia via NAT136 Tipos de NAT137 Problemas gerados pelas NATs em videoconferncias139 Solues140 Suporte a NAT nos softwares de videoconferncia142 Conceitos de transmisso multimdia143 Latncia143 Jitter144 Skew145
vi
Atraso na transmisso149 Uso de QoS em videoconferncia155 QoS no H.323155 QoS na rede156 Arquiteturas de rede para suporte a QoS158 Roteiro de Atividades 5161 Atividade 1 Gerar fluxos UDP e TCP com iperf 161 Atividade 2 Identificar e analisar pacotes RTP e RTCP162 Atividade 3 Calcular atrasos na comunicao163
6. Videoconferncia multiponto
Videoconferncia multiponto165 Modelo centralizado166 Modelo descentralizado166 Multicast167 Modelo hbrido167 MCU168 Solues de MCUs 171 Solues de MCUs em hardware173 Demonstrao de MCU RNP174 Solues de MCUs em software175 Alternativa ao MCU: vdeo escalvel176 Estudo de caso de vdeo escalvel: empresa Vidyo178 Roteiro de Atividades 6181 Atividade 1 Demonstrao das funcionalidades do Polycom V500181 Atividade 2 Compartilhamento de documentos com People+Content181
7. Projeto de ambientes de videoconferncia

Salas de videoconferncia183 Ambiente fsico184 Iluminao184 Visibilidade185 Acstica186 Climatizao186
vii
Ambiente de udio187 Tipos de microfones e suas caractersticas187 Microfonia191 Caixas acsticas191 Ambiente de vdeo192 Projeto de sala193 Natureza da sala e pblico alvo194 Mobilirio e equipamentos194 Infraestrutura e layout196 Preparao de uma videoconferncia197 Etiqueta e boas prticas199 Estudo de caso 1: Auditrio201 Estudo de caso 2: Sala de reunio203 Estudo de caso 3: Uso geral204 Estudo de caso 4: Projeto da sala da ESR-RS205 Acstica207 Planos de cmera/operao208 Sonorizao209 Roteiro de Atividades 7211 Atividade 1 Anlise de cenrios e elaborao do projeto das salas211
8. Transmisso via streaming

Streaming de vdeo213 Streaming x Download progressivo 214 Solues para transmisso e gravao215 Solues baseadas em software216 Requisitos principais para streaming e gravao218 Servidores de streaming em software219 Roteiro de Atividades 8223 Atividade 1 Utilizao do Windows Media Server223 Atividade 2 Transmisso de contedo com a sute Flash Media223
9. Videoconferncia web
Conferncia Web (webconferncia)225
viii
Modelos de servio de webconferncia227 Solues de conferncia web228 Adobe Connect229 Ingressar em uma sesso230 Interface do cliente230 Papis (permisses) dos usurios231 Compartilhamento de udio e vdeo232 Compartilhamento de documentos, tela e quadro branco232 Bate-papo (chat)234 Outros pods234 Layouts235 rea do apresentador236 Dispositivos mveis236 Funcionalidades administrativas236 Cisco WebEx237 FuzeMeeting239 Google Hangout241 BigBlueButton (BBB)241 Mconf244 OpenMeetings247 Outras solues249 Spreed249 Elluminate Live!250 WebHuddle251 Roteiro de Atividades 9253 Atividade 1 Administrao e utilizao do Adobe Connect253 Atividade 2 Utilizao do Mconf253 Atividade 3 Utilizao do Google Hangout253
10. V ideoconferncia em desktop

IVA255 EVO262 VSee264 Citrix GoToMeeting267 Outras solues269
ix
Roteiro de Atividades 10271 Atividade 1 Utilizao do EVO271 Atividade 2 Utilizao do VSee271
Bibliografia 273

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e Governana de TI. A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil (UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no apenas como expositor de conceitos e informaes, mas principalmente como orientador do aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional. A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise, sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias. Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor busca incentivar a participao dos alunos continuamente.
xi
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar. As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo para as atividades prticas, conforme descrio a seguir: Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que o aluno se coloque em posio de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos). Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e oferecer explicaes complementares. Terceira etapa: discusso das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la, devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas, estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem solues alternativas s sugeridas por ele e pelos colegas e, caso existam, a coment-las.
Sobre o curso
O livro de apoio ao curso composto de 10 captulos sobre os diversos aspectos necessrios a uma compreenso mais aprofundada dos sistemas de videoconferncia. A apresentao dos conceitos tericos consolidada com atividades prticas que reforam o aprendizado. O livro aborda questes como fundamentos de videoconferncia, padres internacionais de videoconferncia (H.323 e SIP), gerncia de sistemas de videoconferncia, ambientes de videoconferncia, streaming e uso de aplicativos de videoconferncia. O foco do livro est sobre os diferentes tipos de conferncia com vdeo, implantao e administrao de solues de videoconferncia, e nas melhores prticas para a elaborao de projetos de ambientes adequados para a realizao dos diferentes tipos de videoconferncia.
A quem se destina
O pblico-alvo deste curso amplo, incluindo administradores de sistemas de videoconferncia, gerentes de projeto relacionados a vdeo, profissionais interessados em transmisso de eventos via streaming, ou qualquer pessoa que necessite de um maior embasamento para solucionar problemas em ambientes de videoconferncia. desejvel que os participantes tenham conhecimento prvio em redes de computadores e no uso de sistemas Linux.
xii
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro: Itlico Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada de comandos.
Contedo de slide
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo
Indica um documento como referncia complementar.
Smbolo
Indica um vdeo como referncia complementar.
Smbolo
Indica um arquivo de adio como referncia complementar.
Smbolo
Indica um aviso ou precauo a ser considerada.
Smbolo
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao entendimento do tema em questo.
Smbolo
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citao: MARTINS, Graciela; DARONCO, Leonardo; ROESLER, Valter. Administrao de Videoconferncia. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao: Escola Superior de Redes RNP Endereo: Av. Lauro Mller 116 sala 1103 Botafogo Rio de Janeiro RJ 22290-906 E-mail: info@esr.rnp.br xiii
Sobre os autores
Graciela M. L. Martins tem 14 anos de experincia na rea de TI. Graduada em Cincia da Computao pela UNESP. Especializou-se em Aplicaes de Comunicao e Colaborao na Internet durante o mestrado realizado na USP e, posteriormente, em Gesto Estratgica da Inovao Tecnolgica pela UNICAMP. Atua na RNP na gesto de programas e projetos visando o provimento de solues de TIC para as reas de Educao e Cultura. Foi uma das responsveis pela estruturao inicial do servio de webconferncia provido pela RNP. Leonardo Daronco formado em Cincia da Computao pela Universidade Federal de Santa Maria (2007) e tem mestrado em Cincia da Computao pela Universidade Federal do Rio Grande do Sul (2009). Tem experincia em assuntos relacionados multimdia, codificao de vdeo, redes de computadores e programao. Trabalha atualmente no grupo de pesquisa PRAV (Projetos em udio e Vdeo) da Universidade Federal do Rio Grande do Sul (UFRGS), com pesquisa e desenvolvimento de sistemas multimdia para webconferncia, ensino a distncia e desenvolvimento em dispositivos mveis e sistemas web. Valter Roesler formado em Engenharia Eltrica pela Universidade Federal do Rio Grande do Sul (1988), com mestrado (1993) e doutorado (2003) em Cincia da Computao pela UFRGS. Atualmente Professor Adjunto na Universidade Federal do Rio Grande do Sul. Tem experincia na rea de cincia da computao, com nfase em redes de computadores, atuando principalmente nos temas: Telemedicina, Tele-educao, Multimdia, Redes de Computadores, Codificao de Vdeo e TV Digital. Coordenador do laboratrio do PRAV (Projetos em udio e Vdeo). Lder do grupo de pesquisa do Ncleo de TV Digital da UFRGS e Ncleo de Telessade, no diretrio dos grupos de pesquisa CNPq. Renato Duarte formado em Cincia da Computao pela UniCarioca e trabalha h treze anos na rea. Atualmente responsvel pela rea acadmica de Mdias de Suporte Colaborao Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (ESR-RNP). responsvel pela infraestrutura de TI de apoio coordenao da ESR, e pelo preparo e validao dos laboratrios para execuo das atividades prticas dos cursos da ESR.
xiv
1
Conceitos fundamentais e solues
objetivos
Familiarizar o aluno com os princpios e conceitos fundamentais associados videoconferncia, bem como gerar um nivelamento entre os diferentes conceitos existentes.
conceitos
Cenrios e aplicaes de videoconferncia, tipos de sistemas de videoconferncia, conferncia sncrona e assncrona, taxa de quadros por segundo, resoluo, banda, atraso, relao de aspecto.
Histrico da videoconferncia
Este telefone apresenta muitas deficincias para ser considerado seriamente como um meio de comunicao. O dispositivo inerentemente sem valor para ns. Esta frase foi traduzida de um memorando interno da companhia Western Union do ano de 1876*, e mostra a capacidade de mudana e evoluo da tecnologia. Hoje sabemos como eles estavam enganados. Este mesmo problema j esteve tambm relacionado aos sistemas de videoconferncia em seu incio, mas com o avano da tecnologia ficou claro que os sistemas de videoconferncia so de grande utilidade.
*
Fonte: http://www.princeton.edu
Figura 1.1 Picture phone AT&T 1964.
Os sistemas de videoconferncia foram criados em meados da dcada de 1960. Para se ter uma ideia, desde 1970 as centrais telefnicas j suportavam teleconferncias baseadas em udio, mas conferncias por vdeo ainda no eram uma realidade. Foi a partir da dcada de 1980, porm, que os rumos da pesquisa e desenvolvimento caracterizaram esses sistemas do modo como so atualmente conhecidos.
Captulo 1 - Conceitos fundamentais e solues
O primeiro sistema de videoconferncia data de 1964, ano em que a empresa americana AT&T apresenta o picture phone em uma feira em Nova York, e o mundo conhece o primeiro telefone com imagem da histria das telecomunicaes. O aparelho foi introduzido no mercado em 1970 e comercializado por cerca de U$ 160 dlares mensais. Um ano depois, a Ericsson lanou o primeiro vdeo-telefone transatlntico.
Figura 1.2 Servio da Bell System.
A dcada de 1980 marcada por avanos na pesquisa em transmisso de dados. Aproveitando a iniciativa da Arpanet, foram realizados vrios experimentos com transmisso de voz em pacotes digitais, impulsionando o desenvolvimento de protocolos especiais para tratamento destes pacotes, como o Network Voice Protocol (1973) e, mais tarde o Packet Video Protocol (1981). Em 1982 lanada a recomendao H.120 para codificao de vdeo, abrindo caminho para o surgimento da recomendao H.320, voltada para videoconferncia. A dcada de 1990 continuou marcada por seguidas recomendaes e pelo surgimento de padres para regulamentar o desenvolvimento de sistemas de videoconferncia. Tambm nessa dcada so conhecidos os primeiros sistemas de videoconferncia comercializados no mercado pelas empresas Compression Lab, PictureTel e Mitsubishi. Vrios acontecimentos marcaram a evoluo dos sistemas de videoconferncia, como:
11 1990: surge a recomendao para conferncia ISDN. 11 1991: primeira videoconferncia com udio e vdeo utilizando o codec H.261. 11 1992: lanado o sistema de videoconferncia CU-SeeMe, inicialmente apenas para
Macintosh e sem udio.
11 1993: suporte a multiponto. 11 1994: suporte a udio e verso para Windows. 11 1996: lanada a primeira verso da recomendao H.323 e do NetMeeting pela Microsoft.
Administrao de Videoconferncia
11 1998: lanadas a segunda verso da recomendao H.323 e a primeira verso do padro

MPEG-4 para compresso de vdeo.
11 1999: lanadas a terceira verso da recomendao H.323 e a segunda verso do padro

MPEG-4 para compresso de vdeo; o IETF divulga o SIP.
11 2000: Samsung lana o primeiro MPEG-4 streaming 3G. 11 2001: realizada a primeira telecirurgia transatlntica. 11 2003: lanado o padro H.264; disseminao de redes de banda larga; maior acessibilidade a vdeo; uso de videoconferncia na educao.
A partir da dcada de 1990, vrios aplicativos comearam a ganhar espao no mercado mundial, sobretudo para envio e recebimento de informaes de udio e vdeo sobre redes TCP/IP. Cada vez mais, aplicativos para o envio de udio e vdeo exploravam e aprimoravam as tcnicas para compresso de dados, permitindo a comunicao de usurios em rede com baixo custo e padro de qualidade aceitvel. A popularizao dos sistemas de videoconferncia foi impulsionada pela recomendao H.323 feita pela ITU-T em 1996, que permitiu o desenvolvimento padronizado de diversas solues de software para videoconferncia. Atualmente, as solues para sistemas de videoconferncia so comumente utilizadas no nosso dia a dia, seja na comunicao entre pessoas na internet ou integradas ao cotidiano das grandes corporaes. A utilizao desses sistemas extrapolou a rea de negcios, estando hoje presente em atividades de ensino a distncia, de telemedicina e de pesquisa cientfica, alm de muitas outras aplicaes. No Brasil, o mercado para sistemas de videoconferncia acompanha a tendncia de crescimento mundial. Cada vez mais empresas e usurios domsticos tm lanado mo desse recurso para realizar atividades do dia a dia, como conversar com amigos distantes ou tomar decises de negcios em reunies no presenciais. Portanto, possvel dizer que estamos caminhando para o mundo das solues multimdia sobre redes IP, que no constituem apenas uma tendncia da atualidade, mas sim uma necessidade para incluso em um mercado a cada ano mais competitivo, gil e rpido, demandando mais recursos para facilitar o relacionamento entre as empresas. Nesse sentido, nos prximos anos, a videoconferncia ser uma das ferramentas mais importantes no cenrio dos negcios e da comunicao interpessoal.
Saiba mais
Leia o artigo de Lori Wilkerson sobre a histria da videocon ferncia: The History of Video Conferencing - Moving Ahead at the Speed of Video.
w H.323
H.320
Videoconferncia hoje
Na sua 7 verso, o padro mais consolidado para videoconferncia.
Ainda bastante utilizado nas corporaes, embora tenda a ser substitudo por sistemas baseados em IP. SIP Consolidado para telefonia sobre IP. Webconferncia O surgimento de clientes web tem possibilitado a realizao de conferncias via web.
Essa forma alternativa de videoconferncia tem se destacado pela facilidade de uso. Atualmente, existem padres j consolidados para a realizao de videoconferncias, que sero vistos ao longo do curso. O H.323 o padro mais consolidado e encontra-se em sua 7 verso. O H.320, para uso em redes ISDN (Integrated Services Digital Network) outro padro bastante consolidado, mas tende a ser substitudo pelos sistemas baseados em IP, como o H.323. Outro padro que vem crescendo o SIP. Inicialmente utilizado apenas para telefonia sobre IP (nicho dominado pelo SIP), vem sendo cada vez mais utilizado para videoconferncias. Outro tipo de videoconferncia que vem crescendo conhecido como webconferncia, se destacando pela facilidade de uso. As webconferncias sero abordadas adiante.
Definio de videoconferncia
Antes de definir o termo videoconferncia, importante comentar sua diferena em relao ao termo webconferncia. Vdeo + Conferncia Conferncia onde h interao entre duas ou mais pessoas atravs de vdeo e normalmente tambm de udio. Web + Conferncia A palavra indica uma comunicao via web (internet), no necessariamente envolvendo vdeo (apesar de normalmente ser utilizado). Videoconferncias so normalmente realizadas de trs formas: atravs de softwares instalados em computadores pessoais, via hardwares dedicados e ainda pela utilizao do navegador web no computador pessoal. Com a padronizao dos sistemas web atuais, normalmente no necessrio instalar qualquer software adicional, bastando instalar um
plug-in no navegador para que o usurio obtenha todas as funcionalidades da conferncia. importante observar que a palavra conferncia sugere a participao de trs ou mais pessoas. Entretanto, uma videoconferncia pode ser realizada entre duas ou mais pessoas.
Objetivos da videoconferncia
Comunicao em tempo real entre duas ou mais pessoas geograficamente dispersas, normalmente em locais diferentes, atravs de udio e vdeo.
A videoconferncia um recurso facilitador da comunicao entre pessoas. Por intermdio de uma videoconferncia, duas ou mais pessoas participam de uma discusso e, embora se encontrem em lugares diferentes, podem ver e ouvir umas s outras como se estivessem reunidas no mesmo local. A grande vantagem dos sistemas de videoconferncia consiste em viabilizar a comunicao em tempo real entre grupos de pessoas, com o uso simultneo de udio e vdeo, independentemente de sua localizao geogrfica. Assim, torna-se possvel trabalhar cooperativamente por meio do compartilhamento de informaes e de outros materiais de trabalho como documentos, imagens ou planilhas sem qualquer nus proveniente da distncia geogrfica. Outras possibilidades da videoconferncia:
11 Compartilhamento e apresentao de slides. 11 Compartilhamento de aplicaes. 11 Bate-papo por chat. 11 Quadro branco (colaborativo).
11 Troca de arquivos.
Alm da troca de udio e vdeo entre os participantes, os sistemas atuais tm disponibilizado diversas outras ferramentas que melhoram a comunicao e criam novas possibilidades para as videoconferncias. Entre essas ferramentas esto bate-papo por chat, compartilhamento de apresentaes, quadro branco colaborativo, troca de arquivos e compartilhamento de aplicaes. Esta ltima ferramenta normalmente est presente nos sistemas de videoconferncia de desktop e mostra claramente a integrao que um sistema de videoconferncia pode ter com o sistema base sobre o qual executado (no caso a integrao com o sistema operacional). Com a evoluo da tecnologia e a reduo dos custos
nos ltimos anos, a videoconferncia passou a ser usada como ferramenta de colaborao, aprendizagem e entretenimento. As videoconferncias evoluram muito nos ltimos anos e ferramentas como as citadas j so comuns em muitos sistemas. Apesar disso, os sistemas continuam sendo chamados de videoconferncia. Pode-se fazer uma analogia desta situao com a evoluo do telefone celular, que deixou de ser apenas um dispositivo para efetuar e receber ligaes telefnicas para se tornar um computador porttil, que pode inclusive realizar videoconferncias. Apesar dessa evoluo, eles continuam sendo chamados de telefones celulares, mesmo que ligaes telefnicas no sejam, em alguns casos, a ferramenta mais utilizada do dispositivo.
Elementos de uma video/webconferncia

11 Vdeo e udio 11 Codificao e decodificao 11 Transmisso e recepo 11 Equipamentos de udio e vdeo
Vdeo e udio
A primeira etapa para uma videoconferncia consiste na captura e digitalizao dos sinais de udio e vdeo que sero transmitidos. Para tal, existem diversos dispositivos diferentes. O vdeo pode ser capturado por cmeras variando desde webcams de baixo custo (que normalmente apresentam baixa qualidade) at cmeras profissionais que garantem alta qualidade (HD). Atualmente j existem cmeras pessoais capazes de capturar vdeo em alta resoluo. O udio normalmente capturado por dispositivos de headset (fone de ouvido com microfone) quando se deseja maior privacidade, ou por microfones, que podem ser de diversos modelos, conforme seu propsito.
Transmisso Codicao Vdeo Decodicao
udio
Figura 1.3 Elementos bsicos de videoconferncia.
udio e vdeo
Codificao e decodificao
Aps a captura e digitalizao, os dados so codificados (o que inclui sua compresso) para que possam ser transmitidos pela rede. O elemento essencial para este processo o codec (COdificador/DECodificador), que atua nas funes de codificao e decodificao. A etapa de compresso algortmica fundamental para otimizar a transmisso das informaes. O sinal original reduzido para um tamanho n vezes menor atravs da codificao, o que
possibilita a transmisso dos dados e tambm a adaptao da transmisso conforme a rede disponvel. No lado do receptor, o codec realiza a decodificao, que consiste em transformar os dados novamente para seu formato original, o que permite sua reproduo. Os codecs utilizados normalmente so os baseados em normas internacionais da ITU-T, e muitas vezes MPEG para vdeo. possvel afirmar que todos os sistemas de videoconferncia utilizam o mesmo conjunto de codecs, ou uma variao deste conjunto. Ou seja, os codecs mais comuns para udio e vdeo normalmente so suportados por diversos sistemas de videoconferncia. O que difere de um sistema para outro so os mecanismos de compresso, ou seja, a parametrizao da compresso algortmica adotada pelo fabricante.
Transmisso e recepo
Aps a codificao, os dados esto prontos para serem transmitidos. A transmisso depender das caractersticas da rede, onde um parmetro extremamente importante a banda disponvel, que utilizada para configurao da codificao de udio e vdeo. A qualidade da rede muitas vezes monitorada e utilizada para modificar a parametrizao da codificao de udio e vdeo. Se a rede est congestionada, por exemplo, o monitor de rede pode fazer com que a codificao do vdeo seja reduzida de 1 Mbit/s para 350 Kbit/s ou menos, reduzindo a qualidade do vdeo, mas ainda assim permitindo que a videoconferncia continue funcional. Essa questo da adaptao automtica s condies da rede ainda mobiliza a pesquisa, apesar de estar bastante consolidada. A organizao dos pacotes na rede feita com base em protocolos de rede, que muitas outras vezes so baseados em padres abertos como o Real-time Transport Protocol (RTP), mas que outras vezes so protocolos proprietrios dos desenvolvedores do software ou hardware que est sendo utilizado. Um protocolo indispensvel para que se saiba como os dados esto trafegando na rede e para possibilitar a recepo e organizao dos dados que esto sendo recebidos.
Equipamentos de udio e vdeo

A utilizao de sistemas de videoconferncia em diferentes reas de atuao impulsiona o uso de equipamentos de udio e vdeo cada vez mais sofisticados. Dependendo do sistema utilizado, possvel conectar diversos equipamentos videoconferncia. Por exemplo: no caso de uso em auditrios, podemos acrescentar caixas de som, amplificadores e outros microfones, ligados a uma mesa de udio profissional que, por sua vez, ser conectada entrada de udio do sistema. Hoje em dia, o mercado j disponibiliza microfones especializados em capturar udio em grandes ambientes. Um exemplo disso o microfone de 360 graus, com cobertura para at 10 pessoas simultaneamente, que possibilita a utilizao de um microfone sem fio. No caso do vdeo, podem ser acrescentadas cmeras de vdeo auxiliares conectadas a
uma mesa de vdeo. Esse caso indicado quando, por exemplo, se deseja ter uma cmera focando o instrutor e outra focando a plateia. Alm disso, j existem cmeras digitais de alta definio com controle remoto, e televisores com excelente resoluo, que oferecem alta qualidade de vdeo e so utilizados em sistemas de salas. Esses equipamentos tambm so encontrados na verso desktop, em que temos um sistema com cmera fixa, microfone, fone de ouvido e alto-falante, permitindo videoconferncias via IP ou internet.
Tipos de videoconferncia
H basicamente trs tipos de sistemas de videoconferncia:
11 Sistemas dedicados (hardware) 11 Sistemas de mesa (computador pessoal) 11 Sistemas de webconferncia (navegador web)
Normalmente, imaginamos que os servios de um sistema de videoconferncia limitam-se transmisso de vdeo e udio entre os participantes de uma sala. Embora a funcionalidade bsica da videoconferncia seja a de encurtar distncias, eliminando a necessidade da presena fsica dos participantes em uma reunio, podemos destacar duas classes de servios essencialmente necessrias para suportar a interao entre os participantes de uma sala de videoconferncia: comunicao e colaborao. A comunicao a facilidade fundamental, enquanto a colaborao utilizada quando os participantes, alm de se comunicarem, ainda trabalham em conjunto compartilhando documentos, planilhas e imagens. A comunicao existe em todos os tipos de videoconferncias existentes, enquanto a colaborao o item que apresenta maiores diferenas conforme o tipo de videoconferncia utilizado. H basicamente trs tipos de sistemas de videoconferncia: sistemas dedicados de hardware, sistemas de mesa em computadores pessoais, e sistemas de webconferncia que utilizam o navegador web.
Sistemas dedicados (hardware)

Geralmente presentes em grandes organizaes, que fazem uso de dispositivos dedicados e de software integrado neste dispositivo. Os sistemas dedicados do tipo appliance apre sentam solues mais robustas, confiveis e normalmente mais prticas do que as solues baseadas em PCs.
Sistemas de mesa (desktop)

Ao contrrio dos sistemas dedicados, no exigem equipamentos especiais e caros. Sistemas desktop normalmente so vantajosos em relao ao custo (so executados em mquinas de propsito geral, alm de poderem usar softwares freeware), mas a qualidade da videoconferncia depender do hardware com que o sistema est sendo executado. Esses sistemas normalmente apresentam mais funcionalidades adicionais, como quadro interativo, compartilhamento de aplicaes, compartilhamento de slides, entre outros.
Sistemas de webconferncia
So normalmente compostos por um servidor, responsvel por coordenar as diversas sesses/salas de participantes, e os clientes, que utilizam o navegador web. Esses sistemas tambm apresentam funcionalidades adicionais, como quadro interativo, compartilhamento de aplicaes, slides, e assim por diante.
Sistemas dedicados
Todos os componentes (hardware e software) requeridos esto em um nico equipamento, que conectado a uma televiso ou monitor e rede de dados. O controle do equipamento normalmente feito distncia, por controle remoto, incluindo o controle da cmera (movimentao, zoom etc.). Existem modelos para diferentes propsitos: grupos grandes, grupos pequenos e ambientes individuais.
Os sistemas dedicados foram desenvolvidos principalmente para utilizao de grupos de usurios, em salas de videoconferncia: so sistemas dedicados, geralmente com alta capacidade de processamento e prticos para instalao. O equipamento (algumas vezes chamado de codec) composto por um hardware dedicado, construdo especificamente para videoconferncias, os softwares necessrios para configurar e utilizar o hardware e diversas entradas e sadas para perifricos. Normalmente os equipamentos j possuem uma cmera acoplada e so acessados a distncia por controle remoto. Alm disso, esses sistemas podem ser integrados a diversos perifricos, tais como: televisor, computador, videocassete, cmera de documentos e cmera auxiliar. Apesar da diferena existente entre as diversas marcas, verses e tipos de equipamentos, uma caracterstica comum dos sistemas dedicados topo de linha a maior qualidade. Como possuem um hardware dedicado de alto desempenho, estes equipamentos conseguem utilizar resolues altas (vdeo em HD) e altas taxas de transmisso, o que garante qualidade de udio e vdeo. Outra caracterstica importante dos sistemas dedicados a praticidade. Eles j contm todos os componentes e aplicaes necessrias para realizar uma videoconferncia, sendo que normalmente s necessrio conectar o equipamento a um monitor, rede de dados, realizar algumas configuraes e ele j pode ser utilizado. So equipamentos que dificilmente requerem manuteno e teoricamente so imunes a vrus. O reflexo das vantagens citadas para os dispositivos dedicados visto no custo dos equipamentos, que costuma ser alto e representa a maior desvantagem que eles apresentam. Alm disso, este tipo de equipamento geralmente s permite atualizaes para recursos especficos quando estiverem disponveis.
Figura 1.4 Sistemas dedicados para videoconferncia.
Polycom V500
Tandberg 990 MXP
Polycom VSX 7000s
Os sistemas dedicados so utilizados por aplicaes que primam pela alta qualidade na transmisso de udio e vdeo, tais como: ensino a distncia, palestras, reunies, telemedicina. Apesar de serem utilizados principalmente em ambientes coletivos, eles tambm podem ser utilizados individualmente. Hoje em dia, vrias empresas disputam o mercado dos sistemas de videoconferncia de grande porte, entre elas Polycom, Cisco, Tandberg e Sony.
Sistemas de mesa
Recursos agregados ao computador pessoal para torn-lo adequado para uma videoconferncia:
11 Computador com suporte multimdia 11 Microfone e caixas de som 11 Cmera de vdeo 11 Software (EVO, VSee, Ekiga etc.)
O grande diferencial dos sistemas de mesa est no aproveitamento do computador, que j um equipamento amplamente difundido e utilizado. Estes sistemas normalmente so voltados para uso individual. Para utilizar um sistema deste tipo necessria a instalao de software, microfone, cmera, e possivelmente outros componentes, que so facilmente acoplados a um computador pessoal, conforme pode ser visto na figura.
Figura 1.5 Estrutura de videoconferncia de mesa.
A qualidade de som e imagem depende da qualidade da rede de transmisso e da capacidade de processamento da mquina. Atualmente, a maioria das solues pode operar em taxas que variam de 64 Kbit/s a 2 Mbit/s. Um dos pioneiros nesse ramo foi o sistema da White Pine / First Virtual Communication, o CU-SeeMe, que disponibiliza recursos para os usurios se comunicarem uns com os outros atravs de conexes ponto-a-ponto ou multiponto. O sistema adota o padro H.323, adequado para operaes em redes corporativas IP e na internet. O software EVO, da Caltech, outro exemplo de sistema de mesa que tem evoludo muito nos ltimos tempos. Ele conta com suporte H.323, SIP, chat, vrios vdeos simultneos e diversos outros recursos. Outros softwares conhecidos so o Windows Messenger, Microsoft Office Live Meeting, MSN Messenger e Windows Live Messenger. No Windows Vista chama-se Windows Meeting Space. Ao longo deste curso, o aluno poder utilizar para seu estudo o software Polycom Telepresence m100 ou ento o sistema de software livre Ekiga. Ambos suportam SIP e H.323.
Figura 1.6 Exemplos de sistema de videoconferncia de mesa.
EVO
Vsee
Ekiga
Sistemas de webconferncia
Utilizam o navegador web para efetuar a conferncia:
11 Computador com suporte multimdia. 11 Microfone e caixas de som (ou headset).
11 Cmera de vdeo (webcam, handycam etc.). 11 Navegador web no cliente. 11 Necessitam de mquina servidora para gerncia.
A grande vantagem dos sistemas de webconferncia est na facilidade de efetuar uma videoconferncia, visto que no necessrio para o usurio participante instalar qualquer tipo de software na sua mquina, pois tais sistemas funcionam via navegador web. Nesse tipo de sistema, um administrador da conferncia normalmente cria uma sala virtual e convida os participantes. Essa sala virtual gerenciada por um servidor localizado em algum ponto, porm isso transparente para os usurios. Assim, os sistemas de webconferncia no s aproveitam o computador do usurio, mas tambm aproveitam seu navegador web, bem como a porta destinada ao navegador, que normalmente liberada no firewall, no demandando qualquer liberao de porta aos administradores de rede, o que muitas vezes pode ser traumtico numa empresa com polticas rgidas de segurana.
Figura 1.7 Exemplos de sistemas de webconferncia.
Adobe Connect
Cenrios: Ensino a Distncia (EAD)

Videoconferncias para ensino a distncia podem ser realizadas em ambientes de diferentes tipos e escalas, ou seja, para turmas pequenas ou grandes, seja em salas de aula tradicionais ou em auditrios. necessria uma preparao bsica para viabilizar aulas a distncia, com uso de TVs ou teles para exibio dos vdeos e de um sistema de videoconferncia dedicado para realizar a videoconferncia em si. Sero dados dois exemplos abaixo: 1) um modelo mais simples, utilizando uma sala de aula tradicional e sem muitos recursos, permitindo basicamente a visualizao do site remoto e dos slides do site remoto; e 2) um modelo mais completo, onde a videoconferncia acontece em um auditrio, permitindo a visualizao adicional dos diversos pontos remotos participantes do evento.
Figura 1.8 Exemplos de cenrios de ensino a distncia. Fonte: http://www. unameseca.com.
10
1. No caso do uso de salas de aula tradicionais, um cenrio tpico posicionar o equipa-
mento de videoconferncia na parte frontal da sala junto a duas televises: em uma tela os alunos visualizam o professor e na outra as informaes compartilhadas (apresentaes, documentos, etc.). Se houver possibilidade de interao dos alunos com o professor remoto, existe um microfone junto ao equipamento de videoconferncia, at onde o aluno se dirige para fazer sua pergunta. O microfone j est posicionado em um local de modo que o aluno aparea na cmera.
2. No caso de auditrios ou salas com melhor infraestrutura para videoconferncia,
costuma-se utilizar, em vez de duas TVs, um ou mais teles. No telo possvel visualizar o instrutor e tambm os slides compartilhados, alm dos outros participantes remotos. Em um modelo mais complexo tambm possvel distribuir diversos microfones na sala, para facilitar a interao dos alunos com o professor. No momento que o aluno comea a fazer sua pergunta, a cmera apontada para ele, de forma manual ou automtica.
Figura 1.9 Estrutura do sistema IVA.
Um cenrio de aula a distncia pode ser caracterizado por alunos distribudos em vrios pontos ou por um workshop reunindo especialistas para a discusso de um tema especfico.
Adiante neste curso ser detalhado o sistema Interativo de Vdeo e udio (IVA), desenvolvido para as necessidades da Escola Superior de Redes da RNP pelo grupo do PRAV da UFRGS, no mbito do grupo de trabalho de IEAD Infraestrutura para Ensino a Distncia de 2007-2008.
Cenrios: reunies de trabalho

Em comparao ao cenrio de EAD, reunies de trabalho normalmente so compostas por um nmero menor de participantes e tero muito mais interao entre os pontos remotos, ou seja, uma discusso, no uma palestra. As reunies so realizadas em salas usualmente com uma mesa ao centro e o equipamento de videoconferncia em uma de suas pontas. Algumas vezes so utilizadas telas grandes para aumentar a sensao de que as pessoas esto no mesmo local (ver o cenrio de telepresena a seguir). Por ser uma discusso, os participantes devem ter acesso fcil aos microfones, e para isso costumam ser utilizados microfones multidirecionais.
11
Figura 1.10 Federal Emergency Management Agency (FEMA). Fonte: http://www.photoli brary.fema.gov
Cenrios: telepresena
Telepresena o nome dado aos sistemas de videoconferncia que procuram reduzir ao mximo a sensao de distncia entre os pontos remotos, procurando criar a iluso de que todos estejam em um mesmo ambiente. O cenrio semelhante ao das reunies de trabalho, mas so utilizadas televises ainda maiores e cuidadosamente posicionadas, para que as pessoas sejam exibidas com seu tamanho real e paream estar posicionadas no mesmo ambiente (sentadas na mesma mesa, por exemplo).
Figura 1.11 Exemplo de sala de telepresena (Cisco).
Cenrios: Telemedicina
Operando desde 2006, a Rede Universitria de Telemedicina, um programa do Ministrio da
Cincia, Tecnologia e Inovao (MCTI) e executado pela Rede Nacional de Ensino e Pesquisa (RNP), formalizou a criao e implantao de ncleos de telemedicina/ telessade, garantindo a conectividade de 55 hospitais universitrios e de ensino rede Ip da RNP. Em 2011, 8 novos ncleos de telemedicina RUTE foram inaugurados, faltando ncleos apenas em trs estados (PI, RO, RR), que sero inaugurados em 2012. Alm disso, pode-se destacar como iniciativas bem-sucedidas: 15 salas de videoconferncia homologadas; mais de 600 vdeo e webconferncias realizadas em 47 especialidades da sade, com participao de 313 instituies; assinatura com a RNP de 28 novos termos de cooperao tcnica com hospitais de ensino. A partir de 2012, 75 hospitais em todo o pas sero integrados ao projeto.
12
Para a telemedicina, o fator mais importante de uma videoconferncia costuma ser a qualidade das imagens. Para muitas aplicaes na telemedicina necessria alta qualidade na resoluo de imagens para permitir, por exemplo, um diagnstico correto de doenas. Outro exemplo o projeto POA_S@UDE de telemedicina implementado no Hospital Materno Infantil Presidente Vargas (HMIPV), prximo ao centro de Porto Alegre/RS, onde um sistema utilizado para realizao de tele-ultrassonografias em pacientes de regies mais remotas, onde difcil o acesso a mdicos especializados.
Figura 1.12 Mdico remoto efetua laudo distncia. Fonte: http://www.inf. ufrgs.br/prav/pro jetos_poasaude.php
Dispositivos adicionais
Alm da troca de udio e vdeo entre os participantes, outro objetivo de uma videoconferncia promover suporte colaborao e cooperao, oferecendo ferramentas que permitam a interao e o trabalho em grupo. Para tanto, j existem servios de suporte colaborao que vm sendo agregados aos servios de videoconferncia, visando criar condies para o trabalho cooperativo entre equipes remotamente situadas. Uma alternativa para servios de colaborao a utilizao de padres internacionais, e um deles, utilizado para transferncia de dados, o protocolo ITU T.120. Esse protocolo designa uma famlia de padres abertos que definem prticas para a transmisso de dados. Vrias empresas adotam o T.120 nas suas respectivas solues, tais como: Apple, AT&T, British Telecom, Cisco Systems, Intel, MCI, Microsoft e PictureTel. Os servios de suporte colaborao so implementados por ferramentas geralmente encontradas nos terminais de videoconferncia. Como exemplos dessas ferramentas, podemos citar a cmera de documentos, o quadro interativo e o chat. A seguir, detalhamos algumas dessas ferramentas de colaborao visual.
Cmera de documentos
Cmera de alta resoluo que captura e transmite imagens de documentos e outros objetos fsicos. Valoriza e d maior impacto s apresentaes audiovisuais.
A cmera de documentos utilizada para digitalizar documentos, objetos, formas tridimensionais, documentos impressos e material grfico de qualquer natureza. Consiste numa cmera esttica usada para enviar imagens (transformadas em vdeos) de documentos, materiais impressos, transparncias, slides e raios-X, alm de objetos tridimensionais.
13
Figura 1.13 Cmera de documentos.
Quadro interativo
Tudo o que escrito ou desenhado no quadro digitalizado, facilitando visualizao remota. O clique do mouse pode ser feito com o dedo ou caneta diretamente no quadro branco. Sua aplicao ocorre principalmente em EAD, pois substitui o quadro-negro tradicional em salas de aula. O quadro interativo (ou eletrnico) oferece uma espcie de espao virtual compartilhado pelos participantes, em que todas as aes realizadas so capturadas em tempo real e disponibilizadas (como vdeos) na videoconferncia. Em outras palavras, esse recurso permite capturar tudo o que escrito ou desenhado em um quadro branco comum, em cores e em tempo real, e transmitir esses dados diretamente para o microcomputador ou sistema de videoconferncia.
StarBoard Hitachi Entrada RGB, sada USB
Figura 1.14 Exemplos de quadro interativo.
A seguir veremos outras abordagens para quadros interativos.
Tablet
Notebook ultraporttil ( 1 kg) com recursos para escrever ou inserir dados diretamente na tela por meio de uma caneta metlica. Permite a exibio de vdeos, incluso de anotaes e envio e gravao das imagens. uma alternativa ao quadro eletrnico, j que a imagem do tablet pode ser projetada em uma tela.
14
iPad
Figura 1.15 Tablet.
Um tablet um computador porttil (normalmente mais porttil e leve que um notebook) que permite a insero de dados atravs do contato na tela do computador (multitouch). O contato normalmente feito atravs de uma caneta ou dedo, que permite que o usurio desenhe, escreva e insira dados diversos na mquina como se estivesse escrevendo em uma folha de papel. Os dispositivos normalmente permitem escrever sobre aplicaes e gravar estas anotaes. Isso torna os tablets muito teis em ambientes escolares, onde as anotaes dos alunos podem ser inseridas sobre as apresentaes do professor, por exemplo. Dependendo do sistema e das aplicaes utilizadas, tambm possvel converter texto escrito mo para texto no computador (inclusive equaes).
Sistemas com alta definio

importante ressaltar a diferena da relao de aspecto entre Standard Definition (SD) e High Definition (HD). SD no um nome dado a apenas uma resoluo especfica, ou seja, h mais de um formato de vdeo que pode ser chamado de SD o mesmo vale para HD. O SD caracterizado pelas resolues 720x480 e 720x576, que so utilizadas no sistema de televiso tradicional. J o HD caracterizado por resolues 720p (1280x720) e 1080p ou 1080i (1920x1080), assim como resolues maiores do que estas. As letras p e i na nomenclatura indicam sistemas progressivos ou entrelaados, respectivamente. Devido a esta diferena entre as resolues HD (e por questes de marketing), as resolues 1920x1080 passaram a ser chamadas de Full HD, diferenciando-a das resolues inferiores.
SD
Razo de aspecto 4:3
HD
Razo de aspecto 16:9
Figura 1.16 Exemplos de Standard Definition e High Definition.
Widescreen (20% mais largo)
15
Formato SD HD Resoluo mnima Full p: Vdeo progressivo i: Vdeo entrelaado
Resolues 720x480, 720x576 1280x720p 1920x1080i, 1920x1080p e maiores

Figura 1.17 Resolues SD e HD.
Figura 1.18 Equipamentos com suporte a HD. Fonte: http://www. polycom.com.
Cmera Tandberg Precision HD
Polycom HDX Series
O mercado de equipamentos de videoconferncia bastante competitivo, o que tem provocado um avano tecnolgico significativo nos ltimos anos. Empresas como Polycom, Tandberg e Sony j disponibilizam equipamentos com alta definio, udio e vdeo de excelente qualidade, o que torna a videoconferncia mais realista e possibilita sua aplicao em outras reas, como na telemedicina.
Relao de aspecto
a proporo entre a largura e altura e dos pixels que compem uma imagem digital.
11 Vdeo: arquivo widescreen-explanation.swf. 11 Adaptao da relao de aspecto ( pillarboxes e letterboxes). 11 Adaptao da relao de aspecto de 16:9 para 4:3. 11 Adaptao da relao de aspecto de 4:3 para 16:9.
Relao de aspecto (aspect ratio) a proporo entre a largura e altura e dos pixels que
compem uma imagem digital. O exemplo mais tradicional a relao 4:3, utilizada na televiso analgica tradicional. Outra relao de aspecto comum atualmente a 16:9, utilizada em televises HD. Apesar de alguns dispositivos, como DVDs, exibirem contedos de 4:3 em 16:9 e vice-versa, muitas vezes necessrio adaptar esta relao de aspecto para o formato do dispositivo onde elas sero exibidas. Nestes casos so utilizadas as letterboxes, ou seja, as barras pretas na parte superior e inferior dos vdeos (ou nas laterais). Elas so utilizadas
para que os vdeos possam ser exibidos em sua relao de aspecto original em dispositivos que utilizam outra resoluo de aspecto sem distorcer as imagens.
Monitor 16:9 Video 4:3
Monitor 4:3 Video 16:9
Figura 1.19 Exemplo de ajuste 4:3 e 16:9.
16
Para adaptao da relao de aspecto, alm da possibilidade de pillarboxes ou letterboxes, tambm possvel utilizar outras tcnicas, que normalmente so o redimensionamento do vdeo e a remoo de alguma rea dele.
Figura 1.20 Tcnica de redimensionamento de vdeo.
Redimensionamento
Remoo de reas
Para adaptar um vdeo em 16:9 para monitores 4:3, uma alternativa redimensionar o vdeo, ou seja, encolher o vdeo horizontalmente at que sua relao de aspecto seja 4:3, o que acaba deformando as imagens. Uma alternativa remover reas laterais do vdeo, transformando-o em 4:3 sem necessidade de redimensionamento. Esta alternativa costuma ser chamada de pan and scan, e causa perdas de contedo do vdeo, j que algumas de suas partes sero completamente removidas. Porm, ela mantm as imagens com seu aspecto original. Para adaptar um vdeo em 4:3 para monitores 16:9, alm do uso de pillarboxes, possvel utilizar dois outros mtodos: redimensionamento com e sem remoo de reas. Redimensionar um vdeo 4:3 para 16:9 gera uma expanso horizontal do vdeo, o que acaba deformando as imagens. Outra alternativa remover barras na parte superior e inferior do vdeo (tornando-o 16:9) e depois redimension-lo para a resoluo desejada. Esta ltima alternativa no deforma a imagem, mas gera perda de contedo do vdeo.
Figura 1.21 Tcnica de redimen sionamento sem e com remoo de reas.
Redimensionamento
Remoo de reas
Estruturao de um servio
Identificar as necessidades dos usurios:
11 Tipo de comunicao: ponto-a-ponto ou multiponto. 11 Qualidade: padro SD ou HD. 11 Tipos de dados que sero compartilhados: documentos eletrnicos ou impressos,
vdeos etc.
17
Um servio de comunicao caracterizado por um canal de comunicao em que interlocutores enviam e recebem mensagens. O suporte comunicao interpessoal a essncia de uma videoconferncia. De acordo com a dinmica estabelecida entre os interlocutores de um canal comunicativo, podemos distinguir o servio de comunicao entre:
1. Comunicao 1:1 (um-para-um) 2. Comunicao 1:n (um-para-muitos) 3. Comunicao n:n (muitos-para-muitos)
As mensagens so transmitidas entre mquinas em uma rede de computadores atravs de chamadas, que podem ser (de acordo com as formas de comunicao citadas):
1. Ponto-a-ponto: uma mquina-origem envia mensagens para uma mquina-destino. 2. Multiponto unidirecional: uma mquina-origem envia mensagens para n
mquinas-destino.
3. Multiponto bidirecional: n mquinas enviam mensagens s demais.
Internet
Figura 1.22 Comunicao ponto-a-ponto (1:1).
No caso de uma comunicao ponto-a-ponto um-para-um, cada participante visualiza a imagem do participante remoto maximizada na tela. Alm desta imagem, a maioria dos sistemas atuais permite que o participante veja a sua prpria imagem em uma regio reduzida da tela ( preview local para verificar se o enquadramento est bom). Geralmente, o participante pode escolher se deseja visualizar essas duas opes simultaneamente ou apenas a imagem remota.
Internet
Viso Local
Imagem local e remota
Figura 1.23 Comunicao ponto-a-ponto (1:n).
Em uma comunicao ponto-a-ponto um-para-muitos, h um participante de um lado interagindo com um grupo que est em uma sala remota. Em relao parte tcnica da videoconferncia, esta comunicao praticamente igual s comunicaes ponto-a-ponto um-para-um. Tanto o grupo quanto a pessoa que est sozinha pode escolher se deseja visualizar a imagem local e remota simultaneamente ou apenas a remota. Ou ainda compartilhar um documento em vez da imagem local (isso tambm vale para os outros casos de comunicao).
18
Este modelo de comunicao comum em encontros que envolvem vrios participantes localizados em uma sala de apresentao, alm de mais um participante remoto conectado a um terminal de videoconferncia. Um exemplo prtico desse tipo de situao a apresentao de palestras a distncia, em que um ponto de origem (o instrutor) interage por meio de videoconferncia com um grupo de participantes remotos (alunos). Nesse caso, as mensagens seguem em uma chamada ponto-a-ponto da mquina-origem para a mquina-destino, embora a comunicao seja do tipo um-para-muitos. Neste modelo necessrio ter cuidados com o posicionamento do microfone e da cmera, especialmente na sala com vrios participantes. A cmera deve ter uma viso de todos os participantes da sala e o microfone deve estar acessvel a todos.
Internet
Viso Local
Viso Local
Figura 1.24 Comunicao ponto-a-ponto (n:n).
Em uma comunicao ponto-a-ponto muitos para muitos, h dois grupos, um em cada local, interagindo a partir de uma sala de videoconferncia. Assim como no modelo anterior, tambm deve-se ter o cuidado adicional com o posicionamento da cmera e do microfone, neste caso no apenas em uma, mas em duas salas. Mais complexo que o modelo de comunicao ponto-a-ponto o modelo multiponto, ou seja, uma situao onde temos mais de dois locais conectados em uma conferncia. H vrios casos em que esse modelo utilizado. Exemplos: numa reunio de negcios, na qual estejam conectadas a matriz da empresa e duas (ou mais) filiais; uma aula remota, com o professor presente numa sala, e duas (ou mais) salas remotas apenas com alunos e monitores.
Internet
Viso Local
Figura 1.25 Comunicao multiponto.
A chamada multiponto necessita de um controle especial para gerenciar os n fluxos gerados, e essa responsabilidade pode ser efetuada de diferentes maneiras, como atravs de uma entidade chamada Multipoint Control Unit (MCU), ou atravs de um sistema central por software, ou mesmo sem entidade central, onde cada participante envia o sinal a todos. Esses mecanismos sero detalhados posteriormente.
19
Entenda as necessidades dos usurios e conhea a estrutura que ser usada nas videoconferncias, alm da verba disponvel. Verifique ainda a sala que ser usada para a instalao do sistema:
11 Sala: individual, de reunio ou de aula, ou ainda um auditrio ou sala especfica

(consultrio, centro cirrgico etc).
11 Qual o tipo de microfone adequado? 11 Qual o tipo de cmera de vdeo adequada? 11 Qual a banda de rede disponvel?
O tpico da estrutura da sala de videoconferncia ser abordado em outra sesso deste curso. No momento basta dizer que a estruturao da sala um ponto extremamente importante para a definio de um ambiente de videoconferncia.
Para pensar
importante ter uma estimativa da verba disponvel para o projeto, pois muitas vezes ela que determina a qualidade dos equipamentos e a quantidade de recursos adicionais que sero agregados ao sistema. Sistemas dedicados costumam ser mais prticos, mas apresentam custos elevados. Para reduzir os custos possvel buscar solues em software, especialmente as solues free, como o GNU Gatekeeper.
Por exemplo, se o caso for de comunicao multiponto e no houver verba para aquisio de um controlador de chamadas multiponto (MCU), isso pode ser um ponto crtico no projeto. Algumas alternativas:
11 Usar uma MCU de terceiros; 11 Adquirir equipamentos de videoconferncia j com suporte multiponto; 11 Pensar na possibilidade de usar uma soluo baseada na web (webconferncia), onde
geralmente o suporte multiponto est implcito;
11 Utilizar MCU em software.

Assim, entendendo as necessidades dos usurios, conhecendo a estrutura que ser usada nas videoconferncias e a verba disponvel, possvel especificar o equipamento e os recursos que sero necessrios.
20
Roteiro de Atividades 1
Atividade 1 Sistema de conferncia em desktop
O aluno dever realizar uma conferncia ponto-a-ponto (1:1) por udio e vdeo com o colega ao lado. Para isso, dever instalar e configurar o software disponibilizado para esta atividade, conforme as orientaes do instrutor. Dicas para a configurao do software de videoconferncia:
11 Geral: a aplicao pode solicitar nome de usurio; 11 Vdeo: verificar se a fonte de vdeo a correta; 11 udio: verificar se a entrada e sada de udio esto configuradas; 11 Rede:verificar se o adaptador de rede selecionado o correto; 11 Protocolos: localizar os protocolos de comunicao disponveis (SIP e H.323).
1. Realizada a verificao do aplicativo, os alunos se organizaro em duplas para realizar
uma chamada (1:1) com o software. Para isso, disque para o endereo IP do destino.
2. Ajuste o udio e o vdeo da chamada. 3. Refaa a chamada invertendo o originador dela.
Atividade 2 Funcionalidades do sistema

Nesta atividade vamos explorar as funcionalidades do software, monitorando o volume de trfego da rede durante a realizao de uma conferncia. Para isso deve-se utilizar um software de anlise de banda em tempo real, conforme orientao do instrutor. Os procedimentos descritos a seguir podem exigir o reincio das chamadas para que as configuraes tenham efeito.
11 Nas configuraes do software de videoconferncia, altere a velocidade (taxa de conexo

ou banda) para o mnimo possvel (desde que esse mnimo permita transmisso de udio e vdeo). Verifique visualmente a qualidade. Refaa a chamada para o mximo de banda que o software oferece. Verifique a qualidade. Houve mudana visvel de qualidade? Por qu?
11 Verifique a banda utilizada pela aplicao durante a chamada. Habilite e desabilite a

transmisso de vdeo para observar as diferenas. Verifique tambm se a banda de rede fixa ou se h variaes. Compartilhe algum tipo de dado (quadro branco, apresentaatividade do usurio. Responda as questes a seguir:
1. Por que as novas chamadas s podem ser feitas por IP? Por que no funciona chamar
Captulo 1 - Roteiro de Atividades
es ou desktop). Verifique as variaes imediatas da rede conforme acontece alguma
pelo nome inserido nas configuraes do software do colega?
21
2. Dado que dois pontos utilizam o sistema de videoconferncia, suponha que o ponto A
selecionou a velocidade 128 kbit/s e o ponto B selecionou 2 Mbit/s. Ao iniciarem uma chamada, qual ser a velocidade utilizada?
3. Acesse a tela de configurao do sistema de videoconferncia, especificamente a de con-
figurao H.323 e SIP. Que protocolo de sinalizao est sendo usado na comunicao entre os sistemas? Justifique.
Atividade 3 Medindo o atraso da transmisso

Nesta atividade o aluno dever medir o atraso que ocorre em uma sesso de videoconferncia, desde a captura da imagem pela cmera at a exibio no computador remoto e retorno para o computador original (atraso de ida e volta). Esta atividade deve ser realizada em duplas. Para realizar esta tarefa, deve-se instalar um software de cronmetro no computador. Passo 1: dispare o cronmetro na mquina A. Passo 2: a mquina A filma com a webcam o seu cronmetro, transmitindo essa imagem para a mquina B. Passo 3: a mquina B filma o sinal recebido de A, enviando-o de volta. Passo 4: agora a mquina A possui a imagem original do cronmetro rodando numa janela e a imagem do cronmetro que foi e voltou atravs do software de videoconferncia. Com isso d para saber o atraso de ida e volta. Capture a tela (printscreen) a partir da mquina A para ver o atraso. Responda s questes:
1. Cite pelo menos trs causas de atrasos observados em videoconferncias.
2. Qual o valor do atraso observado numa conexo abaixo de 256Kbit/s?
3. Modifique a banda para ~2Mbit/s e mea novamente o atraso. Qual o valor do atraso?
Ele variou ou ficou igual? Justifique.
22
2
Padres de videoconferncia
objetivos
Proporcionar uma viso ampla dos padres de videoconferncia existentes atualmente com foco no padro H.323.
conceitos
Princpios de codificao de udio e vdeo, padro de comunicao H.323, protocolo de sinalizao H.323.
Introduo a padres e protocolos

Imagine uma reunio com a participao de vrias pessoas: para que haja uma comunicao efetiva entre todas elas, necessrio que os participantes se faam entender, dominando um mesmo idioma e vocabulrio. Sem o estabelecimento de uma linguagem comum, no haver entendimento entre os participantes da conversa. Imaginemos agora a mesma situao s que com computadores distribudos em uma rede em vez de pessoas. Nesse caso, alm da infraestrutura de redes, necessria uma linguagem padronizada para que haja uma comunicao efetiva entre os computadores. Para garantir que os computadores falem a mesma lngua, existem diversos padres e protocolos que regem essa comunicao. Esses padres e protocolos so objeto de estudo de diversas organizaes, que trabalham no seu desenvolvimento e manuteno. Dentre estas organizaes, as mais notveis em relao a padres de videoconferncia so: ITU-T, IETF e MPEG.
Padronizao
Organizaes que estabelecem normas e protocolos para videoconferncia: 11 Telecomunication Standardization Sector do International Telecommunications Union (ITU-T). 11 Internet Engineering Task Force (IETF). 11 Moving Picture Experts Group (MPEG). A International Telecommunication Union (ITU) uma dessas organizaes que atua no desenvolvimento de padres reconhecidos internacionalmente, no intuito de viabilizar a interao entre computadores e outros equipamentos de telecomunicaes. Esse rgo
internacional, responsvel por estabelecer recomendaes para telecomunicaes, divide-se em grupos de estudo onde cada grupo incumbido de investigar um conjunto de questes, cujos resultados definem as recomendaes estabelecidas pela ITU-T.
Captulo 2 - Padres de videoconferncia
23
Um desses grupos, responsvel pela famlia ITU H.3xx, encarregado por estabelecer recomendaes para colaborao de dados e videoconferncia, ou seja, pela formalizao de padres para comunicao multimdia sobre redes IP. A Internet Engineering Task Force (IETF) uma comunidade internacional aberta, constituda de administradores, operadores e pesquisadores concentrados em padronizar a evoluo da arquitetura da internet e a operao da rede. A IETF est aberta a qualquer indivduo interessado. O trabalho tcnico da IETF tambm realizado em grupos de estudo, organizados por tpicos de interesse em diversas reas, como distribuio, transporte, segurana etc. Outra preocupao de padronizao diz respeito s estratgias de compresso e transmisso de dados multimdia. Hoje em dia, existem cada vez mais aplicaes que envolvem udio, vdeo e dados disposio de um pblico distribudo e crescente. A exploso da internet na dcada de 1990 levou milhares de usurios a utilizarem esses servios com intuito profissional, comercial ou domstico. Assim, a internet agrega um volume de dados multimdia cada vez maior, o que eleva a demanda de banda e a necessidade de estratgias eficientes para transmisso desses dados. Nesse sentido, uma organizao aborda mecanismos para codificao e transmisso de udio e vdeo. O grupo Moving Picture Experts Group (MPEG) uma organizao que regulamenta padres para transmisso e compresso de udio e vdeo. Os esforos desse grupo contam, atualmente, com trs padres que incluem compresso de vdeo: MPEG-1, MPEG-2 e MPEG-4. O MPEG ainda possui outros padres associados: o MPEG-7 responsvel pela descrio de contedo multimdia (metadados) e o MPEG-21, responsvel pela definio de um framework multimdia. Esse padro ser detalhado adiante. Os padres ITU-T de videoconferncia exigem dos fabricantes a implementao de um conjunto mnimo de padres de compresso de udio e vdeo. H padres opcionais que tambm podem ser utilizados nos sistemas de videoconferncia. Alm disso, cada fabricante pode adicionar padres proprietrios s suas solues. Conjunto mnimo + padres opcionais + padres proprietrios Os padres de videoconferncia especificam um conjunto mnimo de padres ITU-T de compresso de udio e vdeo que deve ser implementado para que um sistema seja homologado conforme este padro. E alm deste conjunto mnimo, existem os padres opcionais, que normalmente so mais complexos, como o H.264 para vdeo. Muitos sistemas ainda incluem mtodos proprietrios de codificao de vdeo e udio. Por serem mtodos proprietrios, onde muitas vezes apenas o prprio fabricante sabe como o mtodo funciona, outros sistemas dificilmente tero suporte a esses mtodos, o que impossibilita a interoperao entre os sistemas. Apesar disso, mtodos proprietrios podem ser utilizados como um diferencial quando um fabricante desenvolve um mtodo novo ou otimiza um mtodo de codificao, por exemplo. Nesse caso, normalmente o cliente dever possuir
equipamentos do mesmo fabricante em todas as pontas, a fim de poder utilizar o padro.
Princpios de codificao de udio

Como converter udio analgico em digital? 11 PCM (Pulse Code Modulation): 11 sinal discretizado (gera um erro de amostragem). Como minimizar o erro de quantizao (duas formas)?
24
Qual taxa de amostragem deve ser utilizada supondo que: 11 Frequncia da voz humana: 20 Hz 6.000 Hz (porm banda de 4kHz oferece perfeita inteligibilidade). 11 Frequncia do ouvido humano: 20 Hz 20.000 Hz. 22 Qual o nmero de nveis e amostras no PCM comercial? 22 Companso do sinal. 22 A voz humana pode variar 10 mil vezes, pois o ser humano pode falar baixinho ou gritando e o outro lado deve ouvir perfeitamente. Como lidar com isso?
O primeiro passo para a codificao de udio consiste na captura dos sinais sonoros (ondas sonoras) e na transformao deles em sinais digitais. Como esta converso de sinais analgicos para sinais digitais feita? Uma tcnica bastante utilizada em telefonia a tcnica PCM, que analisa o sinal analgico em instantes uniformes de tempo, obtm a magnitude do sinal nestes instantes e representa esta magnitude de forma numrica (de forma binria). A imagem abaixo mostra um exemplo de um sinal de udio analgico que ser convertido para digital:
Figura 2.1 Onda analgica a ser convertida.
No grfico da figura 2.1, o eixo y mostra a magnitude do sinal e o eixo x o tempo. A linha azul representa a onda sonora, enquanto as linhas verticais ao longo do grfico marcam os momentos em que sero obtidas amostras da onda sonora, ou seja, os momentos onde a magnitude da onda ser representada por um nmero binrio. O prximo grfico mostra o resultado da aplicao do PCM sobre a primeira parte da onda:
111 110 101 100
010 001 000 0 0 0 0 1 1 1 0 0 0 1 1 0 1 1 1 0 1 1 1 0 1 1 1
Figura 2.2 Aplicao do Pulse Code Modulation.
O eixo y mostra uma escala com um nmero para cada linha horizontal. Este nmero est representado em binrio (com 3 bits para facilitar o entendimento) e corresponde ao smbolo que ser utilizado pelo PCM para representar cada uma das oito linhas horizontais. A cada instante de tempo (linhas verticais) o PCM verifica a magnitude da onda e encontra a linha horizontal que mais se aproxima deste valor. Ele usa ento o smbolo associado a esta
011
25
linha para representar a magnitude da onda nesse instante. Esse processo vai se repetindo para a onda em instantes de tempo uniformes, gerando os smbolos que a representam. Esses smbolos esto exibidos no grfico ao longo do eixo x (000, 011, 100 etc.). A linha cinza mostra o formato com que a onda passa a ser representada aps ser convertida para o formato digital pelo PCM. Cada valor obtido pelo PCM ao longo do tempo chamado de uma amostra do sinal, e por isso este processo chamado de amostragem da onda sonora. A definio do nmero de amostras obtidas um parmetro muito importante do processo, que influencia diretamente na qualidade do sinal digital. Quanto maior o nmero de amostras, maior ser a proximidade do sinal digital com o sinal analgico, mas tambm maior ser a quantidade de dados necessrios para representar este sinal. O teorema de Nyquist indica que a taxa de amostragem do sinal deve ser de pelo menos o dobro da frequncia do sinal. Este teorema muito usado como base para definio da taxa de amostragem utilizada. A definio da taxa de amostragem normalmente baseada na frequncia da voz humana e na sensitividade do ouvido humano. A voz humana pode variar entre 20 Hz e 6000 Hz aproximadamente; entretanto, limitando em 4 kHz a conversa fica totalmente inteligvel, pois frequncias altas so mais raras. Portanto, muitos sistemas que trabalham com voz humana tomam como base a frequncia de 4 kHz. Segundo o teorema de Nyquist, a taxa de amostragem deve ser pelo menos duas vezes a frequncia desejada. Assim, a taxa de amostragem utilizada em codecs comerciais de 8 kHz, ou 8.000 amostras por segundo. J o ouvido humano capaz de perceber sons entre 20 Hz e 20 kHz, aproximadamente, ou seja, sons com frequncias acima de 20 kHz no podem ser ouvidos. Este conhecimento costuma ser utilizado na digitalizao de sons mais complexos que a voz, onde se deseja a capacidade de representao de todo o espectro de frequncias que pode ser ouvido pelo homem. Em CDs de udio, por exemplo, utilizada a taxa de amostragem de 44.1 kHz, pouco mais que o dobro da frequncia mxima ouvida pelo homem. Outro parmetro que influencia diretamente na qualidade do sinal digital o nmero de bits utilizado em cada amostra. No exemplo anterior foram utilizados 3 bits por motivos didticos. Com um nmero maior de bits possvel representar mais fielmente o sinal analgico (mais linhas horizontais no grfico), reduzindo a diferena entre os sinais, o que chamado de erro de quantizao. Em CDs de udio, so utilizados 16 bits para cada amostra. Em telefonia se trabalha com 8 bits por amostra. Outra tcnica aplicada durante a digitalizao de sinais sonoros a companso do sinal, representada na figura a seguir. Este processo necessrio, pois a amplitude dos sinais sonoros pode variar muito. A voz humana pode variar 10 mil vezes, pois o ser humano pode falar muito baixo ou gritando, e em ambos os casos deve ser totalmente entendido no destino. Isso cria um problema para a digitalizao, pois seriam necessrios muitos bits para representar cada
amostra (o ideal seriam 13 bits por amostra; comercialmente so usados 8). No processo de companso, os sinais mais fracos so elevados e os mais fortes so reduzidos, e assim todos podem ser representados por um nmero fixo de bits, pois o sinal analgico da voz homogeneizado. Dessa forma, se a pessoa fala baixo, sua voz amplificada antes da digitalizao. Se fala alto, no amplificada. Assim, todos os sinais podem ser representados com os 8 bits, economizando na taxa de transmisso via rede. As duas formas mais utilizadas de companso so chamadas de lei A (mais usada na Europa) e lei (mais usada nos Estados Unidos e Japo).
26
Vs
Companso segundo lei A ou (analgico)

Figura 2.3 Curva de companso da voz (entrada/sada).
Usar 13 bits e comprimir segundo lei A ou (digital)
Ve
Padres de udio
A figura abaixo mostra um resumo da faixa de frequncia, taxas de transmisso e latncia utilizada nos principais padres de codificao de udio. Padro G.711 G.722 G.722.2 G.723.1 G.728 G.729
Figura 2.4 Resumo das faixas de frequncia.
Faixa de frequncia 300 Hz - 3.4 kHz 50 Hz - 7 kHz 50 Hz - 7 kHz 8 kHz 300 Hz - 3.4 kHz 8 kHz
Taxa de transmisso 64 kbit/s 48,56 ou 64 kbit/s 6,6 - 23,85 kbit/s 5,3 ou 6,3 kbit/s 16 kbit/s 8 kbit/s
Latncia <1 <2 100 <2 25 - 35
Qualidade Excelente Boa Razovel Boa Boa
Abaixo temos uma breve descrio de cada um dos padres: 11 G.711 mandatrio para todos os sistemas H.3xx. Possui udio com qualidade de telefonia padro. Indicado para uso em conferncias com taxa disponvel de pelo menos 128 kbit/s. 11 G.722 produz udio de boa qualidade, e aumenta a resposta em frequncia em relao ao G.711 (vai at 7 kHz). 11 G.722.1 possui taxas mais baixas de compresso (24 e 32 kbit/s), mas mantendo o udio na mesma qualidade do G.722 ou at melhor. Licenciado pela Polycom como Siren14. 11 G.722.2 a 12 kbit/s prov excelente qualidade de voz em ambiente calmo. Taxas mais altas so teis em condies de barulho de fundo e msica. Licenciado pela VoiceAge 11 Adaptive Multi-Rate - WideBand (AMR-WB) recomendado no anexo C do G.722.1, tornando possvel o uso de uma resposta em frequncia de 14 kHz em vez de 7 kHz. Da os nomes dados pela Polycom: Siren7 e Siren14. 11 G.723.1 requer baixa largura de banda (5,3 e 6,3 kbit/s) e usado para VoIP. Devido ao tempo de latncia e qualidade de udio, muitas vezes substitudo pelo G.711. 11 G.726 transmisso de voz nas taxas 16, 24, 32 e 40 kbit/s. Geralmente transmitido a 32 kbit/s, o que acarreta na economia de 50% na capacidade de uso da rede em comparao ao G.711, porm piora em termos de atraso.
Corporation como AMR-WB.
27
11 G.728 utiliza taxa de 16 kbit/s com baixo atraso (menor que 2 ms) e boa qualidade de voz. 11 G.729 costuma ser utilizado para VoIP e opera com taxa de 8 kbit/s (apresenta extenses que utilizam as taxas de 6,4 e 11,8 kbit/s). 11 G.729a anexo do G.729 que prov uma variao do original com menos computao, embora a qualidade da voz fique pior. s vezes usado quando h necessidade de envio simultneo de voz e dados. 11 G.729b outro anexo do G.729 que contm um mtodo de compresso de silncio, que possibilita a deteco de atividade (voz) no sinal. 11 G.729.1 desenvolvido para prover melhor qualidade e mais flexibilidade do que o G.729, sendo interopervel com este. Opera nas taxas de 8 a 32 kbit/s.
Princpios de codificao de vdeo

11 O vdeo uma sequncia de imagens estticas. Principais taxas usadas atualmente (quadros por segundo): 11 30 NTSC e PAL-M. 11 25 PAL e SECAM. 11 24 cinema. 11 50 e 60 alguns sistemas HDTV de alta capacidade. 11 Assim como a codificao de udio, a codificao de vdeo o processo de digitalizao dos sinais analgicos de vdeo aps serem capturados por algum dispositivo (como uma cmera de vdeo). 11 Um vdeo um conjunto de imagens estticas, dispostas em sequncia e exibidas rapidamente uma aps a outra. Em 1832, Plateau descobriu que so necessrias pelo menos 10 imagens por segundo para que um vdeo passe a ideia de movimento para uma pessoa, devido a um fenmeno no crebro conhecido como persistncia retiniana, que mantm a imagem na retina por alguns milisegundos aps a imagem ter sido modificada.
Figura 2.5 Teoria de Plateau.
Atualmente so usadas taxas de 24 quadros (imagens) por segundo no cinema e 25 ou 30 quadros por segundo em sistemas de televiso. Sistemas mais modernos de alta capacidade j utilizam taxas de 50 e 60 quadros por segundo.
Por que comprimir?

Calcule: 11 Taxa em bit/s de vdeo SD no comprimido (Standard Definition 720x480, RGB, 30 qps) 11 Taxa em bit/s de vdeo HD no comprimido (High Definition 1920x1080p, RGB, 30 qps)
28
Trs componentes fundamentais: R, G e B compem qualquer cor por emisso luminosa.
Figura 2.6 A Practical Guide to Video and Audio Compression. Fonte: Cliff Wooton, Focal Press, 2007.
Vermelho Amarelo
Verde
0 255 0
Cyan
0 255 255
Azul
0 0 255
Violeta
255 0 255
Figura 2.7 Componentes RGB.
R G B
255 0 0
255 255 0
Assim como o udio, o vdeo analgico capturado e convertido para o formato digital. O processo diferente do utilizado para udio. No vdeo, cada imagem capturada por diversos sensores, que capturam a intensidade de cada ponto da imagem e convertem esta intensidade para um valor representado digitalmente, formando uma matriz de valores que representa a imagem capturada. Cada valor destes representa um pixel da imagem. Para cada imagem, o processo normalmente feito para as trs cores bsicas, o vermelho, o verde e o azul, formando os trs planos (ou matrizes) que compem a imagem (RGB). Alm do RGB, a imagem pode tambm ser representada de outras formas, como o YUV, muito utilizado na codificao de vdeo. 11 Para compresso dos vdeos gerados aps a captura, os codificadores utilizam tcnicas para reduzir redundncias de diversos tipos presentes no vdeo: 11 Redundncia espacial. 11 Redundncia temporal. 11 Redundncia psicovisual. 11 Redundncia de codificao (entrpica).
Redundncia espacial
A redundncia espacial ocorre em pixels de uma mesma imagem, isto , pixels vizinhos no espao tendem a ser muito parecidos (ou iguais). normal que imagens possuam regies homogneas, onde as cores so praticamente iguais. Estas regies so facilmente compactadas, porque de modo simplificado o codificador pode informar a cor de um bloco de pixels apenas uma vez e indicar que toda uma regio semelhante.
29
Figura 2.8 reas com redundncia espacial.
Redundncia temporal
Quadros vizinhos temporalmente possuem diversos pixels similares, seja na mesma posio (crculo azul) ou em posies prximas (crculo vermelho).
A redundncia temporal percebida entre quadros vizinhos. Assim como um quadro pode ter regies muito homogneas, dois quadros vizinhos podem ser muito parecidos. Nestes casos, o codificador pode simplesmente informar que determinada regio de um quadro exatamente igual mesma regio no quadro anterior (rea maior marcada na imagem), ou ento que esta regio igual uma regio localizada em outro local no quadro anterior (rea menor marcada na imagem). Essa indicao do deslocamento do bloco na imagem de referncia conhecida como vetor de movimento.
Quadro 1 Quadro 2
Figura 2.9 reas com redundncia nos quadros.
Redundncia psicovisual
O sistema visual humano mais sensvel s informaes de brilho do que de cor, pois no olho humano existem 240 milhes de bastonetes (brilho) e 13 milhes de cones (cores). Por isso podem ser utilizados mais dados (bits) para representar brilho do que cores.
Isso requer uma transformao do sistema RGB (Red Green Blue) para YCbCr (luminncia Y imagem em preto e branco e crominncias Cb e Cr cores associadas). Relaes dos componentes de cores: reduo de 4:4:4 para 4:2:2 (33% de compresso) ou 4:2:0 (50% de compresso). A redundncia psicovisual leva em considerao o conhecimento sobre o sistema visual humano. Sabe-se que o olho humano possui muito mais componentes que percebem o brilho das imagens do que componentes que percebem as cores, portanto muito mais interessante representar mais variaes de brilho do que de cores. Na prtica, isso corresponde a utilizar um nmero maior de bits para representao do brilho.
30
A redundncia psicovisual aplicada por sistemas de cores como o YCbCr, que utiliza um plano para o brilho (Y) e dois para cores (Cb e Cr), que pode ser utilizado de diversas maneiras na amostragem do sinal, aps a captao da luz na cmera pelo CCD ou CMOS: 11 4:4:4 amostragem total, sem compresso, utilizada mais em cinema, por causa das tcnicas de chroma key. Mantm todas as cores na mxima resoluo. 11 4:2:2 o dobro de bits para brilho (4) do que para cada componente de cor (2 para cada). Esse tipo de amostragem j permite uma compresso de 33% do tamanho do vdeo digital, com o mnimo de perda em cor, sendo utilizada em todos os sistemas de TV digital. 11 4:2:0 o qudruplo de bits para brilho (4) do que para os componentes de cor (2 para ambos), amostragem que comprime o sinal em 50% com perda mnima de cores, sendo usada nos sistemas de cmeras do tipo handycam, e tambm para videoconferncias.
Redundncia de codificao (entrpica)

A redundncia de codificao no vista na anlise das imagens como as outras redundncias, mas na anlise da sequncia de bits gerada aps a codificao das imagens. Nesta sequncia de bits, muitos padres se repetem, como, por exemplo, sequncias grandes de ZEs. Existem diversas tcnicas para reduzir esta redundncia (tcnicas de codificao entrpica). Entre as tcnicas utilizadas esto a codificao de Huffman, que representa os dados de entrada com smbolos, utilizando smbolos menores para os dados de entrada mais frequentes e smbolos maiores para os menos frequentes. H tambm a codificao aritmtica, que representa os dados por nmeros de ponto flutuante. Ao contrrio de outras tcnicas utilizadas na compresso, a codificao entrpica no introduz perda, ou seja, a imagem codificada pode ser restaurada para seu estado original (exatamente como era) depois de decodificada. A compresso de vdeo um artifcio importante para os sistemas de videoconferncia, pois reduz sensivelmente o fluxo de dados transmitidos na rede, embora, por outro lado, aumente a necessidade de processamento nos terminais da videoconferncia, pois necessrio fazer a codificao/decodificao do vdeo para exibi-lo nos clientes, o que pode retardar um pouco a dinmica do processo e provocar uma latncia maior.
Padres de vdeo
ITU-T Standards Joint ITU-T MPEG Standards MPEG Standards
1984
H.261
H.263 H.262 MPEG-2 MPEG-1
H.263+
H.263++
H.264/AVC MPEG-4 parte 10 MPEG-4
H.265
Figura 2.10 Evoluo dos padres de vdeo.
1988 1990
1993
1995
1997
2000
2003
2013
O grfico mostra a evoluo na padronizao da codificao de vdeo. A norma H.261, finalizada no incio dos anos 90, foi a primeira iniciativa da organizao ITU de gerar um padro para aplicaes de teleconferncia. Alguns anos depois, o grupo MPEG lanou o padro MPEG-1 visando principalmente aplicaes de armazenamento de vdeo. Posteriormente as duas organizaes lanaram em conjunto a especificao H.262/MPEG-2 (H.262 pela enti-
31
dade ITU e MPEG-2 pela organizao MPEG), que veio a se tornar o padro mais difundido para aplicaes de vdeo digital, como DVD e TV digital. O H.263 veio como uma evoluo do H.261, e teve algumas evolues, como o H.263+ e H.263++. No final dos anos 90, o grupo MPEG lanou a especificao MPEG-4. Em paralelo, a organizao ITU vinha trabalhando em um projeto de codificao ainda mais eficiente. As duas organizaes ento uniram esforos para lanar, em 2002, outra padronizao conjunta, a H.264/AVC, que a mesma norma MPEG-4 (parte 10). Alguns padres do MPEG foram desenvolvidos em conjunto com o ITU-T e publicados pelas duas entidades com nomes diferentes, apesar dos padres serem exatamente os mesmos. Este o caso do MPEG-2 (parte 2), que o mesmo padro H.262 da ITU-T e especifica um modelo para codificao de vdeo. Outro caso de cooperao das entidades no padro MPEG-4 (parte 10) ( Advanced Video Coding AVC), que corresponde ao padro H.264 da ITU-T. Na verdade, a partir do MPEG-2 houve um esforo conjunto entre o MPEG e o ITU, conhecido como Joint Video Team ( JVT), e ambos trabalham em conjunto para definir os padres da forma mais eficiente e tambm compatvel, evitando incompatibilidades. notvel a alta capacidade de compresso de dados e flexibilidade do padro H.264/AVC. Sua flexibilidade deve-se ao fato de poder ser aplicado a uma extensa variedade de aplicaes, sendo eficiente, por exemplo, para taxas de bits e resolues de vdeo altas e baixas. O preo a ser pago por todas as vantagens do H.264 o poder de processamento exigido para codificao de vdeo superior ao dos outros algoritmos. O H.265 ou MPEG-H (parte 2) tambm conhecido como High Efficiency Video Coding (HEVC). Sucessor do H.264 AVC, HEVC dobra a taxa de compresso quando comparado ao H.264, permitindo resolues de 320x240 at 7680x4320. O formato padro de vdeo para os servios de videoconferncia especificados na recomendao H.323 baseado no formato Common Intermediate Format (CIF), que consiste na resoluo 352x288. Esse padro nasceu na especificao H.261. O CIF nasceu da necessidade de estabelecimento de um formato padro para videoconferncia que suportasse os dois principais formatos padronizados de TV em todo o mundo: Phase Alternating Line (PAL) A TV PAL utiliza 625 linhas para formao do quadro, a uma taxa de 24 quadros por segundo. Possui frequncia de varredura vertical de 50 Hz e resoluo de 720 x 576 pixels. National Television Standard Committee (NTSC) e PAL-M A TV NTSC ou PAL-M utiliza 525 linhas por quadro, 30 quadros por segundo, frequncia de 60 Hz e resoluo de 720 x 480 pixels. A figura seguinte mostra uma comparao entre as resolues utilizadas nos padres H.261 e H.263:
Formato CIF Sub-QCIF QCIF CIF 4CIF 16CIF
Resoluo (em pixels) 128 x 96 176 x 144 352 x 288 702 x 576 1.408 x 1.152
H.261 N R O N N
H.263 O R O O O
Figura 2.11 Comparao entre os padres H.261 e H.263.
R: Requerido; O: Opcional; N: No especificado
32
Como podemos observar na figura, o formato CIF apresenta variaes que definem outros formatos de resoluo. Formatos com menor resoluo requerem menor largura de banda para transmisso, como o caso do Sub-QCIF. Formatos com maior resoluo, como o caso do 4CIF, requerem maior largura de banda para a transmisso. Para o padro H.323, o padro para codificao de vdeo requerido o H.261 com resoluo QCIF. Assim, h a garantia de que todos os sistemas compatveis com H.323 suportam pelo menos essa especificao.
H.264
Padro de codificao de vdeo bastante utilizado atualmente, que usa novas tcnicas no disponveis no MPEG2, MPEG4 e H.263. Oferece o dobro da qualidade de vdeo do H.262 em qualquer taxa de transmisso. Tornou-se um padro mandatrio para sistemas de alta definio com os discos Blue Ray, e tambm para produtos de broadcast, cabo, videoconferncia e outros eletrnicos diversos. Tambm adotado na TV digital brasileira.
O H.264 um padro bastante utilizado atualmente em codificao de vdeo, sendo cada vez mais usado em sistemas de videoconferncia. Ele foi especificado pela ITU-T em conjunto com o grupo MPEG, sendo nomeado H.264 pela ITU-T e MPEG-4 (parte 10) ou MPEG-4 AVC, de Advanced Video Coding, pelo MPEG. Ao contrrio do MPEG-4, o H.264 tem um escopo mais reduzido e seu foco a otimizao da codificao de vdeo. Ele inclui diversas novas funcionalidades no processo de codificao em relao aos seus predecessores, buscando um balano entre eficincia da codificao, complexidade e custo. O grau de compresso do padro e a incluso de outros componentes que envolvem estritamente vdeo e a flexibilidade permitida fazem com que seja uma grande promessa para o futuro das aplicaes de videoconferncia. Ele j o padro adotado nos sistemas mais modernos, principalmente os que requerem alta qualidade, como nos casos dos discos Blue Ray. O H.264 foi adotado como o padro de codificao a ser usado pelo sistema brasileiro de TV digital.
MPEG
O MPEG foi um grupo estabelecido em 1988, com a meta de elaborar padres genricos para vdeo digital e compresso de udio, definindo normas para multiplexar fluxo de udio e vdeo. Padres: 11 MPEG-1, MPEG-2, MPEG-4 e MPEG-H: possuem partes especficas de compresso de udio e vdeo. 11 MPEG-7: descrio de contedo de mdia (metadados). 11 MPEG-21: definio de um framework multimdia.
Os padres MPEG normalmente so divididos em diversas partes, cada uma especificando determinadas etapas ou processos da codificao (codificao de imagens, de udio, processo de testes, entre outros). No MPEG-1, por exemplo, a parte 3 especifica codificao de udio, sendo o formato de codificao que ficou conhecido pelo nome MP3. A parte que especifica codificao de vdeo normalmente a parte 2 dos padres, o que acontece no MPEG-1, MPEG-2 e MPEG-4.
33
O MPEG-1 o padro mais antigo da famlia MPEG, projetado inicialmente para ser capaz de comprimir cerca de 30 minutos de udio e vdeo para um nico CD. O MPEG-1 uma estratgia eficiente de compresso e descompresso, mas qualitativamente deixa a desejar. Normalmente, as taxas utilizadas esto em torno de 1 a 1,5 Mbit/s. Desde que a compresso H.263 vem sendo utilizada na maioria dos sistemas baseados em H.323 j que fornece a mesma qualidade de imagem com uma taxa semelhante , o MPEG-1 no tem sido mais adotado em sistemas de videoconferncia. Assim como o MPEG-1, o padro MPEG-2 implementa um esquema para compresso de vdeo. Porm, o propsito inicial dos desenvolvedores do MPEG-2 era atender a aplicaes de broadcast, o que trouxe novas especificidades ao esquema adotado, que representa uma evoluo ao MPEG-1, sendo muito mais complexo e eficiente. Atualmente, o MPEG-2 cobre muitas variaes de resoluo e formato, visando tambm atender as especificaes da TV de alta definio. O mercado disponibiliza um grande nmero de produtos que utilizam este formato, como DVD players, receptores de TV via satlite e receptores de TV a cabo. O MPEG-2 ainda utilizado em videoconferncias quando se deseja um mtodo mais rpido e menos complexo de compresso ou manter a compatibilidade com sistemas antigos. O MPEG-4 o mais novo dos padres da famlia MPEG, introduzido em 1999. O maior diferencial do MPEG-4 incluir novos mtodos de codificao de vdeo que o tornam mais eficiente que o MPEG-2. Alm disso, o MPEG-4 tambm um padro bastante mais extenso que o MPEG-2, sendo definido como um padro para representao de objetos audiovisuais. O mecanismo de compresso semelhante ao MPEG-2, mas este padro procura tratar de diversos tipos de dados, como objetos (regies de um vdeo), redes de pontos 2D e 3D, animaes e texturas. Assim como no MPEG-2, o MPEG-4 tambm oferece uma variedade de perfis que podem ser utilizados, permitindo desde taxas muito baixas (para utilizao em dispositivos mveis, por exemplo) at taxas bem maiores, que permitem transmisso de vdeo de alta qualidade. Comparando perfis equivalentes, o MPEG-4 requer maior processamento do que os padres MPEG-2 e MPEG-1 para codificao e decodificao. Do mesmo modo como os demais esquemas de compresso MPEG, ele foi desenvolvido para aplicaes de broadcast e streaming, onde a latncia no se apresenta como uma questo to crucial quanto em aplicaes de videoconferncia. O MPEG-4 apresenta duas partes relacionadas codificao de vdeo: 11 MPEG-4 parte 2 : mtodo tambm chamado de MPEG-4 Visual, representa a evoluo da codificao do MPEG-2. Normalmente quando se fala apenas em MPEG-4, esta parte do padro que est sendo referenciada. 11 MPEG-4 parte 10: foi definida em conjunto com o ITU-T e chamada de Advanced Video Coding (AVC) pelo MPEG e H.264 pelo ITU-T. No deve ser confundido com o MPEG-4 parte
2, pois representa um formato de compresso diferente. O MPEG-4 parte 2 vem substituindo o MPEG-2 j h alguns anos, sendo utilizado em diversos vdeos na internet codificados atravs de codecs que implementam o padro, como os j populares DivX e Quicktime 6. J o MPEG-4 parte 10 corresponde ao H.264, que j possui diversas aplicaes (como Blue-ray, TV digital brasileira, entre outras) e tende a se tornar o padro mais utilizado, inclusive em videoconferncias.
34
Uma breve descrio desses padres disponibilizada em Videoconferencing Cookbook no site da ViDe.
w Padres de dados
H dois padres importantes homologados pela ITU-T: 11 T.120: srie de protocolos para compartilhamento de dados com suporte a multiponto. Possibilita: 22 Compartilhamento de rea de trabalho ou de aplicao. 22 Uso de quadro branco (bate-papo e transferncia de arquivos). 11 H.239: possibilita a criao e o controle de canais de vdeo adicionais. 22 Canal de vdeo adicional para envio de apresentaes, compartilhamento de tela do computador, entre outros. T.120 uma famlia de padres estabelecidos pela ITU e suportados pelo padro H.323 (de uso no obrigatrio). A norma T.120 regulamenta uma srie de protocolos para o compartilhamento de dados em sistemas de videoconferncia. O T.120 suporta comunicao
ponto-a-ponto e tambm comunicao multiponto, podendo ser utilizado atravs de um n centralizador (servidor) ou no. Quando utilizado em conjunto com um sistema de videoconferncia, pode assumir duas estratgias: in-band (a troca de dados entre os terminais compartilham o mesmo canal utilizado para troca de vdeo e udio) ou out-of-band (as cone xes de dados so feitas independentemente das conexes de multimdia). Dentre as principais aplicaes do T.120, destacamos: compartilhamento de rea de trabalho e aplicaes, quadro branco (whiteboard ), bate-papo e transferncia de arquivos. Exemplo de equipamento que facilita a captura de dados para uso do H.239:
Figura 2.12 Polycom Visual Concert.
O H.239 faz parte da famlia de protocolos H.32x (que inclui o H.323) e utilizado para possibilitar a criao e o controle de canais multimdia adicionais na videoconferncia. O H.239 voltado para sistemas baseados nos padres H.245 e H.320. Enquanto o H.245 permite a criao de mltiplos canais para vdeo, o H.320 permite apenas um canal. Com isso, em relao ao H.320, o H.239 traz a vantagem de permitir um canal adicional de vdeo, onde identificao dos canais (indicar que um canal de vdeo corresponde apresentao do professor, por exemplo) e mtodos para controlar estes canais em conferncias multiponto, como permitir que apenas um participante esteja transmitindo um vdeo adicional contendo a imagem de seu desktop, por exemplo.
pode ser transmitida, por exemplo, uma apresentao. Alm disso, tambm permite a
35
Padres de comunicao
A figura a seguir contm um resumo das principais recomendaes ITU, com o tipo de redes para as quais elas so voltadas e os padres de udio e vdeo utilizados em cada uma. Padres de comunicao H.310 H.320 H.323 H.324
Padres de vdeo MPEG-2 H.261, H.263 H.261, H.263 H.263
Padres de udio MPEG-2 G.711, G.722 e G.728 G.711, G.722, G.723, G.728 e G.729 G.723.1
Redes Redes ATM Redes ISDN e dedicadas Redes de pacotes (IP) Rede telefnica
Figura 2.13 Principais padres ITU-T.
A famlia H.3xx um conjunto de recomendaes regulamentadas pela ITU-T que compe o principal conjunto de recomendaes relacionadas videoconferncia. Essas recomendaes costumam ser chamadas de guarda-chuva, pois fazem referncia a diversas outras recomendaes, entre elas recomendaes para codificao de udio e vdeo, multiplexao, sinalizao e controle. Estas recomendaes referenciadas indicam as tcnicas e protocolos que podem ser utilizadas nas diversas reas da videoconferncia. A recomendao H.323, por exemplo, faz referncia aos protocolos H.261, H.263 e H.264 para codificao de vdeo. O ncleo de recomendaes da famlia H.3xx composto por: 11 H.310 prov suporte para videoconferncia sobre ATM e possui um nicho muito especfico. 11 H.320 padro para transmisso de vdeo, udio e dados em tempo real em redes ISDN (Integrated Services Digital Network ). disponibilizado de duas formas: PRI fornece 30 canais de 64 kbit/s e dois canais de sinalizao, totalizando 2 Mbit/s; BRI fornece dois canais de 64 kbit/s e um canal de sinalizao de 16 kbit/s, totalizando 144 kbit/s. 11 H.323 recomendao voltada para videoconferncias em redes comutadas por pacotes sem garantia de qualidade de servio (LANs, internet etc.). 11 H.324 prov suporte para videoconferncia de baixa largura de banda sobre PSTN (Public Switched Telephone Network ). Esse protocolo foi utilizado na sia pelo mercado de telefonia celular. Alm dos padres ITU, h um padro IETF que deve ser destacado: 11 SIP protocolo dominante na rea de VoIP e cujo uso em videoconferncias vem crescendo cada vez mais. Neste curso ser dada nfase aos protocolos H.323, durante esta sesso, e SIP em sesses
posteriores.
Padro H.320
O padro H.320 voltado para videoconferncias em redes ISDN.
36
Estrutura de normas do H.320
Codecs de vdeo
H.261
H.263
H.264
Codecs de udio
G.711
G.722
G.728
Controle
H.221
H.242
H.230
Dados
T.120
H.239
Figura 2.14 Estrutura de normas do H.320.
Controle
H.243
Recomendaes utilizadas pelo H.320: 11 Codificao de vdeo: H.261 e opcionalmente H.262, H.263 e H.264. 11 Codificao de udio: G.711 e opcionalmente G.722, G.728, G.723.1 e G.729. 11 Controle: H.221, H.242, H.243 e H.230. 11 Dados: T.120 e H.239. A base do H.320 est nos seus padres de controle. Abaixo h uma breve descrio de cada um deles: 11 H.221: define a estrutura de organizao dos dados ( framing ) para canais de 64 a 1920 kbit/s em conferncias. 11 H.242: define um sistema para estabelecer comunicao entre terminais audiovisuais (ponto-a-ponto) usando canais digitais de at 2 Mbit/s. 11 H.230: define o controle de sincronizao de quadros e indicao de sinais para sistemas audiovisuais. 11 H.243: define procedimentos para estabelecer comunicao entre 3 ou mais terminais audiovisuais usando canais digitais de at 2 Mbit/s. Comunicao com o MCU.
Padro H.323
Padro mais difundido para transmisso de voz, vdeo e dados em tempo real, para uso em redes comutadas por pacotes. Foi o primeiro padro para VoIP, mas perdeu espao para o SIP. Principais componentes de uma rede H.323: 11 Terminais.
11 Gatekeeper. 11 Gateway. 11 Elementos de borda. Terminais H.323 so equipamentos que conectam-se rede H.323, viabilizando a participao dos usurios em videoconferncias. O H.323 um padro ITU que descreve protocolos, servios e equipamentos necessrios para comunicao multimdia incluindo udio, vdeo e dados em redes sem garantia de qualidade de servio. O H.323 vem sendo desenvolvido desde 1996 com o objetivo de prover comunicao multimdia sobre redes baseadas em IP como a prpria internet, IPX, LANs e
11 Unidade de Controle Multiponto (MCU).
37
WANs. Desde sua criao, o H.323 j sofreu muitas revises, que incorporam novas caractersticas para adequ-lo s novas tendncias. O H.323 tambm pode ser visto como uma derivao de outro padro da famlia H.32x, o H.320, mas otimizado para uso na internet. Atualmente, o H.323 tambm conta com especificaes para a incluso de suporte voz e telefonia sobre IP. O funcionamento do padro H.323 fundamentado numa espcie de contrato entre os componentes que interagem dentro de um ambiente H.323, permitindo que esses componentes troquem informaes entre si. O H.323 tambm especifica os padres utilizados para esta comunicao, que formam a linguagem utilizada pelos componentes para que eles possam se entender. A arquitetura H.323 composta dos seguintes componentes: 11 Terminais: so computadores ou equipamentos dedicados utilizados como pontos finais (endpoints) da rede de comunicao. Esses equipamentos so responsveis por fornecer suporte em tempo real s comunicaes bidirecionais. Tipicamente, so representados por computadores pessoais com suporte multimdia e cmeras integradas ou equipamentos dedicados que j contm cmera e captao de som ligados a um televisor ou projetor. Em alguns momentos o termo endpoint utilizado na norma H.323 para referenciar qualquer elemento capaz de receber ou iniciar chamadas, seja um terminal, gateway ou MCU. 11 Gatekeepers: conhecidos como os crebros da rede, responsveis pela gerncia de outros componentes do H.323 e pelas funes de traduo de endereos e identificao dos elementos de videoconferncia, autorizao e gerenciamento. 11 Gateways: promovem o entendimento comum, ou seja, trabalham como tradutores responsveis pela conexo em redes no integradas (fora da zona H.323), possibilitando a interoperabilidade com endpoints de redes baseadas em circuitos (por exemplo, RDSI). 11 MCU: Multipoint Control Units so responsveis pela conferncia multiponto, viabilizando que mais de dois participantes se comuniquem simultaneamente atravs da rede, analogamente ao que acontece em uma teleconferncia via telefone.
Figura 2.15 Exemplo de cenrio (terminais, MCU, gatekeeper, gateway).
Telefone IP phone Rede IP Telefone IP phone

Gatekeeper
Roteador
Terminal H.323 Roteador
Gateway
MCU
ISDN Gateway Terminal H.323
PSTN / WIRELESS
Telefone
Terminal H.320
38
Adicionalmente definio dos diferentes tipos de componentes, o H.323 descreve protocolos que definem a codificao de udio e vdeo, registro e admisso (Registration, Admission and Status RAS), sinalizao de chamadas e de controle. O H.323 ainda especifica uma arquitetura de componentes obrigatrios e opcionais, que sero detalhados durante o curso, bem como todo o detalhamento do funcionamento dos protocolos.
Figura 2.16 Equipamentos de videoconferncia.
Multipoint Control Unit (MCU)

MCUs so responsveis por gerenciar conferncias multiponto, viabilizando a comunicao de trs ou mais pontos simultaneamente. Tambm permitem: 11 Criao de salas virtuais de conferncia. 11 Transcodificao de udio e vdeo para diferentes modelos de equipamentos e fabricantes. 11 Transcodificao de velocidades (bitrate). MCU formada por Controlador Multiponto (MC), um componente obrigatrio que gerencia a sinalizao de chamada.
Figura 2.17 Conferncia multiponto utilizando Multipoint Control Unit.
MCU
Multipoint Control Unit (MCU) ou unidade de controle multiponto um terminal de rede que (MC Multipoint Controller) e por um processador multiponto (MP Multipoint Processor). O primeiro componente mandatrio e executa as funcionalidades bsicas do servio, enquanto o processador multiponto possui carter opcional (e podem haver vrios destes) e tem a finalidade de prover o processamento necessrio para a realizao da conferncia multiponto (em especial a codificao de vdeo, que muito custosa em termos de processamento). Para viabilizar uma conferncia multiponto, o elemento fundamental a MCU, uma vez que possui funcionalidades que permitem negociao com as diversas entidades conectadas conferncia, a fim de estabelecer formatos comuns de comunicao. Para tanto, os terminais devem estabelecer canais de controle H.245 com a MCU.
prov recursos para suportar conexo multiponto. formada por uma controladora multiponto
39
Processadores Multiponto (MP) so opcionais, utilizados para manusear a mixagem de mdias, chaveamento ou outro processamento de mdia.
Figura 2.18 Controladores multiponto.
Gateway
Responsvel por fazer a interface H.323 para outras redes, tais como PSTN e sistemas H.320. Funes: 11 Traduo de protocolos H.323/SIP (IP) para H.320 (ISDN) ou o contrrio. 11 Possibilita o aumento de controle e centralizao das sadas de ISDN em pontos estratgicos na rede.
Terminal H.323
Telefone ISDN/PSTN
Terminal H.323
Gateway Telefone
Telefone IP phone
Terminal H.320
Figura 2.19 Cenrio de uso do gateway.
Os gateways so os tradutores da arquitetura H.323, responsveis por garantir que os diferentes elementos envolvidos em contextos de redes (tambm diferentes) possam se intercomunicar. Para promover tal interoperabilidade, um gateway executa a traduo entre os protocolos que rodam nas redes diferentes. Por exemplo: a traduo de protocolos que rodam em redes comutadas por circuito para protocolos de redes baseadas em pacotes IP (como o prprio H.323). Os servios de um gateway incluem: interoperabilidade entre padres de udio/vdeo e redes, converso de protocolos e formatos de udio e vdeo.
H.323 permite, por meio do uso de gateways, a converso entre protocolos como H.320 (ISDN) e H.324 (POTS), garantindo a integrao desses contextos com as aplicaes H.323, alm de padres no pertencentes a ITU, como SIP. Compartilha o recurso ISDN para todos os endpoints presentes na rede:
Figura 2.20 Exemplos de gateways.
40
Gatekeeper
Componente opcional no sistema H.323. Funes: 11 Gerenciar todos os recursos disponveis (terminais, gateways, MCU). 11 Pode permitir que chamadas sejam realizadas diretamente entre terminais ou centralizar, tanto a sinalizao como os dados. 11 Fornece servios avanados de administrao: 22 Traduo de endereos. 22 Controle de admisso (autenticao dos terminais). 22 Negociao de largura de banda. O gatekeeper pode ser visto como o crebro do esquema H.323. O funcionamento de um
gatekeeper anlogo a um servidor de gerncia multimdia, que executa as atividades de administrao e tomada de deciso. O gatekeeper prov os seguintes servios: resoluo de endereos, controle de admisso, gerenciamento de banda e de zona. Uma zona H.323 compreende o conjunto de todos os componentes arquiteturais H.323 assistidos por um nico gatekeeper. Em outras palavras, podemos dizer que uma zona uma coleo de terminais, gateways e MCUs gerenciados por um nico gatekeeper. Uma zona inclui, no mnimo, um terminal, e pode incluir MCUs ou gateways. Uma zona pode ser independente da topologia de rede e estar ligada a segmentos de rede mltiplos, conectados por roteadores e outros recursos. H tambm o conceito de domnios administrativos, que so grupos de zonas H.323 administrados pela mesma pessoa ou organizao (possuem mesmas regras de autenticao). Os gatekeepers podem tambm definir regras especficas para autenticao de componentes do seu domnio administrativo e outras regras para autenticao de componentes de diferentes domnios. Funes administrativas de um gatekeeper: 11 Traduo de endereos: chamadas originrias da rede H.323 podem utilizar um apelido (alias) para enderear terminais de destino. Chamadas originadas fora da rede H.323 e recebidas por um gateway podem utilizar um nmero de telefone E.164 (telefone convencional) para enderear os terminais-destino. O gatekeeper traduz esse endereo telefnico convencional em um endereo de rede IP. Por exemplo: (21) 222 6576 em 245.153.45:121. O terminal-destino pode ento ser identificado e contatado atravs do endereo IP. 11 Controle de admisso: o gatekeeper pode controlar a admisso dos terminais na rede utilizando mensagens Registration, Admission and Status (RAS), onde esto inclusos os pedidos de admisso (ARQ Admission Request), confirmao (ACF Admission Confirm) cada, significando a admisso de todos os terminais presentes na rede. 11 Controle de banda: o gatekeeper prov suporte ao controle de banda usando mensagens RAS de pedido de banda (BRQ Bandwidth Request), confirmao (ACF) e rejeio (ARJ). Com isso ele consegue controlar a banda que est sendo utilizada na rede, administrando-a atravs da permisso ou negao das novas conexes que forem solicitadas ou das mudanas de banda que forem solicitadas. Alm disso, o gatekeeper pode controlar o limite de conexes simultneas na rede H.323, caso necessrio. A banda disponvel tambm pode ser administrada de modo que as conexes de udio e vdeo no esgotem essa banda, permitindo que existam tambm conexes de dados. O controle de banda tambm pode no ser especificado, o que significa que sero aceitas todas as solicitaes de conexes e mudana de banda. 41
e rejeio (ARJ Admission Reject). A admisso de controle pode, ainda, no ser especifi-
11 Gerenciamento de zona: sendo o crebro do esquema H.323, um gatekeeper define uma rea H.323, que ser gerenciada por ele. Ele ento prov as funes j citadas de traduo de endereos, controle de admisso e controle de banda para os terminais, gateways e MCUs locados dentro desta zona. Funes opcionais de um gatekeeper: 11 Sinalizao de controle de mensagem: o gatekeeper pode rotear mensagens de sinalizao de chamadas entre os terminais H.323. Numa conferncia ponto-a-ponto, pode centralizar mensagens de sinalizao de chamadas H.225. Alternativamente, o gatekeeper pode permitir que os terminais enviem mensagens de sinalizao de chamadas H.225 diretamente para outros terminais. 11 Autorizao de chamadas: quando um terminal envia uma mensagem de sinalizao de chamada para o gatekeeper, o gatekeeper pode aceitar ou rejeitar a chamada, utilizando a especificao H.225. As razes que provocam a rejeio de uma chamada podem ser restries baseadas em tempo de conexo, permisses de acesso e/ou controle de banda. 11 Gerenciamento de chamada: o gatekeeper pode manter informaes sobre todas as chamadas ativas H.323; desta forma, possvel controlar as zonas provendo essas informaes de manuteno para as funes de gerenciamento de banda, realizar balanceamento de carga redirecionando as chamadas para diferentes terminais, entre outros.
Zona H.323
Definida por um nico gatekeeper e por todos os componentes conectados a ele:
ISDN
Sistema eletrnico Gateway
Terminal
Gatekeeper
Roteador
MCU
Zona H.323
Figura 2.21 Topologia de rede com gatekeeper.
42
Figura 2.22 Exemplo de elemento de borda.
Elementos de borda
Geralmente colocados com o gatekeeper, trocam informaes sobre endereos e participantes (internos e externos) para autorizao de chamadas entre domnios administrativos. Funcionam como um firewall traversal configurado para chamadas H.323.
Um domnio administrativo um conjunto de zonas sob um mesmo controle administrativo. Os elementos de borda so componentes opcionais, que, como os gatekeepers, realizam tarefas administrativas, porm no se comunicam diretamente com os terminais. Eles so componentes localizados nas bordas das redes H.323 que realizam tarefas de comunicao entre domnios administrativos. Entre estas tarefas esto a troca de informaes de controle de acesso e de informaes sobre o custo de ligaes, por exemplo. Em uma ligao de um terminal do domnio administrativo da organizao X com um terminal do domnio administrativo da organizao Y, por exemplo, podem ser utilizados elementos de borda em ambas as organizaes, que se comunicam trocando todas as informaes necessrias para efetuar a chamada.
Protocolos da arquitetura H.323

Alm de componentes j abordados, o H.323 tambm especifica os vrios protocolos utilizados no ambiente H.323.
Aplicaes multimdia, interface do usurio Controle e gerenciamento dos terminais
Aplicaes de dados
Controle de mdia Codecs de udio: G.711 G.723.1 G.729 Codecs de vdeo: H.261 H.263 H.264 RTCP
T.120
H.239
H.225.0
Sinalizao da chamada
H.245
H.225.0 RAS
TCP
Figura 2.23 Arquitetura do protocolo H.323.
TCP
UDP
TCP/UDP
TCP
UDP
IP
Vale lembrar que o H.323 independente das interfaces de rede e dos protocolos de transporte. Protocolos adotados pelo H.323: 11 Codificao de vdeo: H.261, H.263 e H.264. 11 Codificao de udio: G.711, G.729, G.723.1, G.726, G.722, G.728.
RTP
43
11 Controle: H.225 e H.245. 11 Dados: T.120 e H.239. 11 Transporte multimdia: RTP e RTCP. Em relao ao vdeo, mandatrio que todos os terminais H.323 possibilitem a codificao e decodificao de vdeo com resoluo QCIF e protocolo H.261, e para udio mandatrio o suporte a G.711. Os outros protocolos citados para udio e vdeo so opcionais. Os protocolos de vdeo e udio j foram comentados, enquanto os protocolos de controle e de transporte multimdia sero detalhados no restante deste captulo. Iniciaremos pelos protocolos RTP e RTCP, utilizados para transporte e controle sobre os dados de udio e vdeo.
Protocolos RTP e RTCP

11 RFC 3550 torna obsoleta a 1889 (RTP e RTCP). 11 Exemplo de pilha de protocolos RTP/RTCP com UDP e Ethernet. 11 RTP fica acima do nvel 4, no subnvel inferior do nvel de aplicao.
O RTP protocolo para aplicaes em tempo real (Real-time Transport Protocol) um protocolo especificado pelo IETF que prov um servio de entrega fim-a-fim de udio e vdeo em tempo real. o protocolo utilizado para o empacotamento de mdias numa conexo H.323 (e em muitos outros sistemas).
Aplicaes de dados
T.120
H.239
H.225.0
H.245
H.225.0 RAS
RTP
TCP
TCP
UDP
TCP/UDP
TCP
UDP
Figura 2.24 Destaque dos protocolos RTP e RTCP.
IP
44
Aplicao
Encapsulamento de mdia RTP dados UDP RTCP controle
IPv4 / IPv6 Unicast ou multicast
Ethernet
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 V=2 P X CC M PT Timestamp
Figura 2.25 Exemplo de pilha de protocolos (RTP/ RTCP) e RFC 3550.
Nmero de sequncia
Synchronization Source (SSRC) identier Contributing Source (CSRC) identiers
SEQ=1 SEQ=2 SEQ=3 SEQ=4 SEQ=5 SEQ=6 SEQ=7 SEQ=8

Perdas=10% SEQ=9
Figura 2.26 Exemplo de funcionamento do RTP.
SEQ=10
SEQ=1, tstamp=x SEQ=2, tstamp=x+eq 20ms SEQ=SEQ=3, tstamp=x+eq 40ms SEQ=4, tstamp=x+eq 60ms
45
O RTP costuma ser utilizado com User Datagram Protocol (UDP) e no Transmission Control Protocol (TCP), para evitar os atrasos devido aos processos de estabelecimento de conexo e SEQ=1 recuperao de falhas do TCP. O RTP prov ento as funcionalidades de um protocolo de
SEQ=2 transporte voltado para a transmisso de dados de udio e vdeo. Entre os mecanismos
existentes no RTP esto: SEQ=3 1SEQ=4 1 Sequenciamento: a funo de sequenciamento designa a atribuio de nmeros de sequncia aos pacotes, a fim de garantir o correto ordenamento dos pacotes e de SEQ=5 detectar perdas. SEQ=6 11 Sincronismo intramdia: a transmisso de pacotes em uma rede pode levar a uma situSEQ=7 ao em que pacotes de uma mesma mdia apresentem atrasos diferentes causados por SEQ=8 jitter, o que prejudica a apresentao da mdia no cliente. Nesse caso, haver a necessidade de uma sincronizao dos pacotes que compem a mdia. Essa sincronizao feita por meio de uma bufferizao, Perdas=10% de modo que os pacotes recebidos sejam exibidos no momento correto. Quando a sincronizao ocorre entre arquivos de mdia distintos, ou
SEQ=9 seja, a sincronia entre fluxos de udio e vdeo, denominamos de sincronismo intermdia.
11 Identificao de contedo: em redes sem garantia de QoS, a perda de pacotes e atrasos
SEQ=10 pode variar ao longo do tempo. O RTP fornece informao de contedo no intuito de permitir que codecs alterem dinamicamente sua capacidade de acomodar as perdas e atrasos detectados durante a transmisso. Isso feito atravs do campo Payload Type (PT). 11 Identificao de origem: consiste na marcao da origem do pacote, ou seja, quem o enviou.
SEQ=1, tstamp=x SEQ=2, tstamp=x+eq 20ms SEQ=SEQ=3, tstamp=x+eq 40ms SEQ=4, tstamp=x+eq 60ms SEQ=5, tstamp=x+eq 80ms
Figura 2.27 Exemplo de adaptao do jitter.
O protocolo de controle em tempo real (Real-time Transport Control Protocol RTCP) usado em conjunto com o RTP para servios de controle. Ao contrrio do RTP, RTCP no transporta a mdia em si (udio e vdeo), mas apenas informaes sobre estatsticas da transmisso e controle. A funo primria do RTCP prover informaes sobre a qualidade do servio, o que feito pela transmisso peridica de pacotes para todos os participantes de uma sesso RTP. Outras funcionalidades do RTCP incluem o controle sobre os identificadores dos terminais, para garantir que nomes dados aos terminais sejam nicos, e controle sobre a banda que ele
prprio utiliza, a fim de evitar sobrecarregar a rede com informaes de controle.
Protocolo H.225 RAS

RAS (Registration, Admission and Status): 11 Mensagens entre terminais/gateways e gatekeepers para: 11 Registro: gatekeeper gerencia registro de cada terminal. 11 Admisso: terminal requisita admisso para uma chamada. 11 Status: gatekeeper controla estado dos terminais e chamadas.
46
Mensagens mais importantes do RAS: 11 Solicitaes: Request (xRQ ). 22 RRQ: RegistrationRequest. 22 A RQ: AdmissionRequest. 22 GRQ: GatekeeperRequest. 11 Respostas: 22 Reject (xRJ) -- RRJ , A RJ , GRJ. 22 Confirm (xCF ) -- RCF, ACF, GCF.
O canal RAS realiza as funes de registro, admisso e estado de chamada por meio do protocolo H.225. O canal RAS (independente do canal das outras mensagens H.225) utiliza um servio UDP para registro e solicitao de admisso das chamadas. As mensagens RAS so utilizadas entre endpoints (termo que inclui gateways, MCUs e terminais) e gatekeepers para realizao de trs funes: 11 Registro: endpoints se registram em um gatekeeper (s podem se registrar em um gatekeeper), que controla as suas informaes de acesso (incluindo IP e nome de acesso). 11 Admisso: requisio de admisso em chamadas, utilizada pelo gatekeeper para controle das chamadas existentes e da banda disponvel. 11 Status: controle do estado dos endpoints, como, por exemplo, descobrir se um endpoint est disponvel ou no.
Aplicaes de dados
T.120
H.239
H.225.0
H.245
H.225.0 RAS
RTP
TCP
Figura 2.28 Destaque do protocolo H.225 RAS.
TCP
UDP
TCP/UDP
TCP
UDP
IP
Quando um terminal no est configurado para se registrar em um gatekeeper especfico, ele pode utilizar mensagens RAS para verificao dos gatekeepers presentes na rede e para solicitar, posteriormente, um registro em um deles processo chamado de descoberta de gatekeeper ( gatekeeper discovery ). Entre as mensagens chave do protocolo RAS esto as mensagens de solicitao de registro (e cancelamento de registro), admisso (e cancelamento) e busca por gatekeepers, e as respostas possveis para estas solicitaes.
47
Essas mensagens so identificadas por 3 letras, sendo que as ltimas duas identificam se uma mensagem de solicitao (xRQ: request ), confirmao (xCF: confirm) ou rejeio (xRJ: reject ). Essas mensagens so descritas brevemente abaixo: 11 RRQ (RegistrationRequest): requisio de um endpoint para se registrar em um gatekeeper. 11 Respostas: RCF (RegistrationConfirm) para confirmao ou RRJ (RegistrationReject) para rejeio. 11 ARQ (AdmissionRequest): requisio de admisso enviada de um endpoint para o gatekeeper. 11 Respostas: ACF (AdmissionConfirm) para confirmao ou RRJ (AdmissionReject) para rejeio. 11 GRQ (Gatekeeper Request): solicitao de gatekeepers existentes. enviado pelos endpoints por IP multicast de forma que os gatekeepers possam receber a mensagem mesmo que o endpoint no conhea os IPs dos gatekeepers. 11 GCF (GatekeeperConfirm): para confirmao ou GRJ (GatekeeperReject) para rejeio (endpoint no pode usar este gatekeeper).
Pode ser multicast, broadcast ou endereamento manual
Terminal 1 Para descobrir o gatekeeper Use porta X Para se juntar zona Para pedir permisso para iniciar chamada
Gatekeeper
GRQ GRJ/GCF RRQ RRJ/RCF ARQ ARJ/ACF Usando porta x Mensagem contm endereo para estabelecer chamada
Figura 2.29 Troca de mensagens RAS entre cliente e gatekeeper.
Usando porta x
Resposta: 224.0.1.41, porta 1718 Broadcast, porta 1719 Manual, porta 1719
Etapas na troca de mensagens H.225 RAS:

1. Terminal T1 envia mensagem GRQ (GatekeeperRequest ) para o grupo multicast 224.0.1.41
(porta 1718) ou em broadcast utilizando a porta 1719 (ou pode acessar o gatekeeper diretamente caso possua seu endereo). Os gatekeepers que receberem esta solicitao podem responder para o terminal informando seu endereo e aceitando que o terminal se registre nele.
2. Um gatekeeper responde para o terminal T1 com uma mensagem GCF (GatekeeperConfirm),
aceitando que o terminal se contate com ele. Nesta mensagem o gatekeeper informa a
porta que o cliente deve utilizar para se comunicar com ele (Porta X). O gatekeeper pode tambm responder com uma mensagem GRJ (GatekeeperReject), que nega ao terminal o uso deste gatekeeper.
3. O terminal T1 envia ento uma mensagem RRQ (RegisterRequest ) para o gatekeeper no
qual deseja se registrar utilizando a porta X.

4. O gatekeeper responde ao terminal T1 uma mensagem RCF (RegisterConfirm), confir-
mando o registro. Ele pode tambm responder com uma mensagem RRJ (Register Reject ) para rejeitar o registro do terminal.
48
5. Para admisso em uma chamada, o terminal envia uma mensagem ARQ ( AdmissionRequest)
para o gatekeeper (tambm utilizando a porta X). O gatekeeper pode ento aceitar o pedido (ACF AdmisionConfirm) ou rejeit-lo (ARJ AdmissionReject ). Esta mensagem contm o endereo de que o terminal precisa para estabelecer uma chamada.
Protocolo H.225 sinalizao de chamada

A sinalizao de chamada H.225.0 utilizada para conectar entidades H.323, sendo derivada do Q.931 e Q.932 (sinalizao de chamada ISDN). Mensagens disponibilizadas: 11 Setup: incio de chamada 11 Alerting : o terminal chamado avisa que est tocando 11 Connect : o terminal chamado avisa que atendeu a ligao 11 Release Complete: finalizao da chamada 11 Entre outras: Facility, Status, Progress, Information A funo de sinalizao de chamada recomendada pelo H.323 utiliza o protocolo H.225
para estabelecer a conexo entre terminais H.323. A sinalizao de chamada ativada pela troca de mensagens do protocolo H.225. As mensagens trocadas e procedimentos utilizados numa sinalizao de chamada executam as seguintes atividades: 11 Estabelecimento de chamada: solicitao e confirmao de incio de chamada. 11 Alertas de progresso da conexo: mensagens opcionais que podem ser trocadas enquanto uma conexo est sendo estabelecida, para que os terminais saibam o estado da conexo enquanto ela no est confirmada (ou cancelada). 11 Encerramento de chamada: solicitao e confirmao de encerramento de chamadas. Pode ser explicitamente enviada por um terminal para o outro ou pode ser enviada pelo gatekeeper caso ele detecte que um terminal est inativo.
Aplicaes de dados
T.120
H.239
H.225.0
H.245
H.225.0
RAS
RTP
TCP
Figura 2.30 H.225 Sinalizao de chamada.
TCP
UDP
TCP/UDP
TCP
UDP
IP
As mensagens de admisso so trocadas entre os terminais e o gatekeeper nos canais RAS. Nesse momento o gatekeeper determina se as mensagens de sinalizao H.225 sero roteadas por ele ou se sero trocadas diretamente entre os terminais.
49
Sinalizao de chamada roteada por gatekeeper

O gatekeeper recebe a mensagem de sinalizao de chamada atravs de um canal especfico para sinalizao com um terminal e executa o roteamento para outro terminal, atravs do canal de sinalizao de chamada desse outro terminal.
Sinalizao de chamada direta

Durante a confirmao de admisso, o gatekeeper indica quais terminais podem trocar diretamente mensagens de sinalizao de chamadas. Os terminais utilizam ento o canal de sinalizao de chamadas para trocar suas mensagens diretamente, sem que elas passem pelo gatekeeper. A sequncia de mensagens trocadas para estabelecer uma conexo com o H.225 comea pelo envio de uma mensagem de Setup. O terminal que recebe a solicitao de conexo pode ento responder com mensagens (opcionais) que indicam o progresso dessa conexo: Call proceding, Progress e Alerting. Assim que este terminal est devidamente pronto para estabelecer a conexo, ele envia uma mensagem Connect, e a conexo est estabelecida. A partir da os dados de mdia podem ser trocados entre os terminais. Para finalizar a conexo, algum dos terminais envia uma mensagem de Release.
Endereo informado pelo gatekeeper Terminal 1 Setup Call proceeding Endereo de transporte para estabelecimento do canal H.245 Alerting Connect Terminal 2
Porta 1720
Figura 2.31 Sinalizao de chamada direta entre clientes.
Note que a mensagem Progress utilizada somente por gateways para indicar ao ponto chamador que a chamada foi encaminhada outra rede a qual o gateway se liga. Essa mensagem possibilita que o terminal (ou gateway) que fez a ligao saiba que o outro gateway est tentando estabelecer a conexo, mas esta ainda no est completa. Alm dessas, as outras mensagens usadas na sinalizao H.225 so: 11 StatusEnquiry : encaminhada pelo gatekeeper para o ponto final da chamada para saber o status de uma chamada.
11 Status: resposta do ponto final mensagem StatusEnquiry do gatekeeper. 11 Facility : usadas entre os pontos finais e o gatekeeper para tratamento de condies especiais, por exemplo redirecionamento de chamadas.
Protocolo H.245
Tem como propsito prover o controle das sesses multimdia estabelecidas: 11 Troca de capacidades entre terminais. 11 Determinao de mestre e escravo. Descritores de capacidades (protocolos suportados) contm o conjunto de capacidades simultneas.
50
H.245 possui um canal de controle utilizado para transportar as mensagens de controle fim-a-fim, com o objetivo de administrar as sesses abertas do H.323. O canal de controle H.245 um canal lgico e est permanentemente aberto, ao contrrio dos canais de mdias. H.245 prov mensagens para abrir e fechar um canal lgico, que unidirecional. As mensagens de controle carregam informaes de diferentes naturezas, tais como: troca de capacidades, informaes de fechamento e abertura de canais lgicos utilizados para transmisso de mdias, mensagens de fluxo de controle, comandos gerais e sinalizaes e requisies de modos preferenciais.
Aplicaes de dados
T.120
H.239
H.225.0
H.245
H.225.0 RAS
RTP
TCP
Figura 2.32 Protocolo H.245.
TCP
UDP
TCP/UDP
TCP
UDP
IP
Troca de protocolos suportados

A troca de protocolos suportados (capability exchange) permite a terminais trocarem informaes sobre os protocolos suportados para transmisso e recepo (tipos de mdias: G.711, G.723, H.261, H.263 etc.); alm do tipo de mdia, detalhes tambm so fornecidos (taxas de transmisso, frames por segundo), permitindo que seja feita uma seleo mais inteligente dos codecs. Os descritores contm o conjunto de protocolos suportados de forma simultnea pelo terminal. Um mesmo terminal pode suportar diversos padres de codificao de vdeo, incluindo o H.261, H.263 e H.264, por exemplo. A ausncia de informaes sobre esse suporte indica que o terminal no est oferecendo uma possibilidade de escolha de modos de transmisso para o receptor.
Capacidades simultneas 1. G.723.1 2. G.711 3. H.261

Figura 2.33 Capacidades de transmisso e recepo dos codecs.
1 2
3 4
4. H.264 5. T.38 Tabela de capacidades
Descritor 1
Descritor 2
T.38 um padro ITU-T para transmisso de fax sobre IP (FoIP).
51
Determinao de mestre e escravo

Necessria para evitar que dois terminais tentem estabelecer ao mesmo tempo dois canais lgicos bidirecionais para o transporte de um mesmo fluxo, ou tentem se tornar ao mesmo tempo o controlador de uma chamada multiponto. Apenas o mestre pode inicializar estes tipos de evento.
Sinalizao de canais lgicos

Canais so abertos pela troca de mensagens Open Logical Channel (OLC). Canais de voz e vdeo so unidirecionais, ao passo que os canais de dados textuais podem ser bidirecionais. Cada ponto final que participa da chamada deve usar um canal lgico separado para transmitir os fluxos de informaes.
Controle de conferncia multiponto

O H.245 tambm usado para tarefas de conferncias multiponto, como a seleo de um modo de operao comum a todos integrantes e a definio do controlador da conferncia. Canal de controle: 11 Canal especial que transporta mensagens H.245. 11 H.245 geralmente transmitido em uma conexo TCP separada, mas tambm pode ser transmitido junto com o canal de sinalizao de chamadas H.225. Formato das mensagens: 11 As mensagens so formadas por diversas PDUs (Protocol Data Unit), que podem ser de 4 tipos: request, response, command e indication. As mensagens H.245 so formadas por diversos itens chamados PDU (Protocol Data Unit ), que contm os dados da mensagem. Estas unidades podem conter dados de quatro tipos: 11 Request : mensagens que necessitam de resposta imediata. Requisio de capacidades do outro terminal ou requisio de configurao de mestre e escravo, por exemplo; 11 Response: resposta a uma requisio; 11 Command: mensagens que requerem aes no receptor, mas no necessariamente uma resposta. Comandos como controle de fluxo, fim de sesso e controle sobre a codificao de vdeo (parametrizao); 11 Indication: indicaes no necessitam que o receptor tome alguma ao ou responda. So avisos de jitter e skew, por exemplo.
52
Terminal 1 TerminalCapabilitySet (1)

Mensagens do canal H.245 Mdia
Terminal 2
TerminalCapabilitySetAck (2) MasterSlaveDetermination (3) MasterSlaveDeterminationAck (4) OpenLogicalChannel (5)
udio: porta RTP destino: X
OpenLogicalChannelAck (6) OpenLogicalChannel (7)
Vdeo: porta RTP destino: Y

Figura 2.34 Mensagens H.245 entre dois terminais.
OpenLogicalChannelAck (8) Canal de udio Porta X Canal de vdeo Porta Y
A troca de mensagens H.245 entre dois terminais segue a seguinte sequncia:

1. O primeiro terminal (T1) envia uma mensagem TerminalCapabilitySet para o segundo
terminal (T2), para a troca de capacidades.

2. T2 conhece, ento, as capacidades de T1 enviando uma mensagem H.245
TerminalCapabilitySetAck, na qual ele inclui as suas capacidades.

3. T1 envia uma mensagem MasterSlaveDetermination para definio de mestre e escravo
da sesso.
4. T2 responde com a mensagem MasterSlaveDeterminationAck, que contm a definio de
quem ser o mestre e quem ser o escravo.

5. T1 abre um canal de udio com T2 enviando uma mensagem H.245 para abertura de canal
lgico (OpenLogicalChannel ). O endereo de transporte do canal RTCP includo na mensagem.

6. T2 conhece o estabelecimento de um canal de dados de T1 para T2 enviando uma
mensagem H.245 OpenLogicalChannelAck. Dentre as informaes dessa mensagem esto envio do fluxo de mdia RTP, e o endereo RTCP recm recebido por T1. Ao receber esta confirmao, T1 abre o canal de dados com T2.
7. T1 abre agora um canal de vdeo com T2 atravs de outra mensagem OpenLogicalChannel. 8. Como para o canal de udio, o terminal T2 responde para T1 com uma mensagem
includos o endereo de transporte RTP alocado por T2 para ser usado em T1 atravs do
OpenLogicalChannelAck. O terminal T1 recebe a mensagem e abre o canal de vdeo com T2.
53
Procedimentos de uma conexo H.323

Agora descreveremos as etapas envolvidas no processo completo de criao de uma chamada H.323, incluindo o estabelecimento da chamada com as mensagens H.225 e H.245 e a transmisso de mdias. Imaginemos o seguinte exemplo: uma rede contendo dois terminais H.323 (T1 e T2) j registrados a seu(s) devido(s) gatekeeper(s). A sinalizao de chamada direta ativada (sem passar pelo gatekeeper). O fluxo de mdia utiliza RTP. Efetuado o processo acima, o terminal est registrado em seu gatekeeper. A seguir, so detalhadas as etapas do estabelecimento de chamada H.323.
Terminal H.323 T1 1 (ARQ) 2 (ACF)
Gatekeeper
Terminal H.323 T2
3 (SETUP) 4 (Procedimento de chamada) 5 (ARQ) 6 (ACF) 7 (Alertar) 8 (Conectar)

H.225 RAS H.225.0/Q.391
Telefone toca
1. Terminal T1 envia mensagem ARQ ( AdmissionRequest ) para o gatekeeper utilizando o
canal RAS para requisio de admisso para o estabelecimento de uma nova chamada. T1 solicita o uso de sinalizao de chamada no modo direto, sem que as mensagens de controle (H.245) sejam roteadas pelo gatekeeper.
2. O gatekeeper confirma a admisso de T1 enviando uma mensagem ACF
Figura 2.35 Mensagens H.323 entre dois terminais com gatekeeper.
( AdmissionConfirmation) para T1. O gatekeeper indica na mensagem ACF que T1 pode usar sinalizao de chamada direta.
3. T1 envia uma mensagem de configurao de chamada H.225 para T2 solicitando uma conexo. 4. T2 responde com uma mensagem de prosseguimento de chamada a T1, ou seja, avisa
que a chamada est em progresso, mas que ainda no foi concluda.

5. Agora T2 tem que registrar no gatekeeper a requisio de admisso para o estabelecimento de
uma nova chamada. Atravs do canal RAS, envia uma mensagem ARQ para seu gatekeeper.
6. O gatekeeper confirma o registro enviando uma mensagem de confirmao ACF para T2. 7. T2 notifica T1 do estabelecimento da conexo, enviando uma mensagem de alerta H.225. 8. Por fim, T2 confirma o estabelecimento da conexo enviando uma mensagem de
conexo H.225 a T1, e a chamada est estabelecida.
54
Terminal T1
Gatekeeper 9. TerminalCapabilitySet
Terminal T2
Mensagens H.245 RTP (mdia)
10. TerminalCapabilitySetAck 11. MasterSlaveDetermination 12. MasterSlaveDeterminationAck 13. OpenLogicalChannel
udio: porta RTP destino: X
14. OpenLogicalChannelAck 15. OpenLogicalChannel
Vdeo: porta RTP destino: Y
16. OpenLogicalChannelAck Canal de udio Porta X Canal de vdeo Porta Y
Figura 2.36 Mensagens H.245 at estabelecer canal de udio.
9. O canal de controle H.245 estabelecido entre T1 e T2. T1 envia uma mensagem
TerminalCapabilitySet para T2, para a troca de capacidades.

10. T2 conhece, ento, as capacidades de T1 enviando uma mensagem H.245
TerminalCapabilitySetAck.
11. T1 envia uma mensagem MasterSlaveDetermination para deciso de mestre e escravo. 12. T2 responde com uma mensagem MasterSlaveDeterminationAck onde j estar decidido
quem o mestre e quem o escravo.

13. T1 abre um canal de udio com T2 enviando uma mensagem H.245 para abertura de
canal lgico (OpenLogicalChannel ). O endereo de transporte do canal RTCP includo na mensagem.

14. T2 conhece o estabelecimento de um canal unidirecional lgico de T1 para T2 enviando
uma mensagem H.245 OpenLogicalChannelAck. Dentre as informaes dessa mensagem esto includos o endereo de transporte RTP alocado por T2 para ser usado em T1 atravs do envio do fluxo de mdia RTP, e o endereo RTCP recm recebido por T1.
15. T1 abre outro canal com T2, agora para vdeo, atravs de uma mensagem H.245
OpenLogicalChannel. O endereo de transporte do canal RTCP est incluso na mensagem.

16. T2 conhece o estabelecimento do canal lgico atravs do envio da mensagem
OpenLogicalChannelAck.
55
Finalizao da sesso
Terminal H.323 T1 21 (Comando de Final de Sesso)
Gatekeeper
Terminal H.323 T2
22 (Comando de Final de Sesso) 23 (Release Completo) 24 (DRQ) 25 (DCF) 24 (DRQ) 25 (DCF)

Mensagens H.245 Mensagens H.225 Mensagens RAS
1. T2 inicia uma chamada de liberao, enviando para T1 uma mensagem H.245
EndSessionCommand.
2. T1 libera seu lado da chamada e confirma a liberao enviando uma mensagem
Figura 2.37 Mensagens H.245 de finalizao de sesso.
EndSessionCommand para T2.

3. T2 finaliza a chamada enviando uma mensagem H.225 para T1. 4. T1 e T2 informam ao gatekeeper o trmino da chamada enviando uma mensagem DRQ
w
A pgina Understanding H.323 Gatekee pers no site da Cisco contm uma boa descrio do funcionamento dos gatekeepers H.323 e dos protocolos de sinalizao H.255 e H.255 RAS.
(DisengageRequest ) para o gatekeeper.

5. O gatekeeper fica a par do encerramento da chamada de T1 e T2 e responde enviando
mensagens de confirmao DCF (DisengageConfirm) para T1 e T2. A figura seguinte apresenta um resumo do que foi visto, e referente captura mostrada na figura seguinte.
56
Terminal T1 Registration Request / Conrm Admission Request / Conrm Setup Permisso para aceitar ligao de T1
Gatekeeper
Terminal T2 Registration Request / Conrm
Permisso para ligar para T2
Setup Admission Conrm
Alerting
Alerting Admission Conrm
Connect
Connect
H.245 (Terminal Capabilities) H.245 (Open Logical Channel)
Canal de udio
Figura 2.38 Resumo da comunicao H.323.
Canal de vdeo
Padres para servios

H.350: 11 Recomendao estabelecida pela ITU-T. 11 Esquema padronizado para prover servio de diretrios para protocolos de conferncia, incluindo H.323, SIP, H.320 e protocolos no padronizados. 11 Utiliza LDAP. 11 Torna fcil a tarefa de encontrar e discar para usurios, suportando o gerenciamento de identidade para permitir alta escalabilidade na organizao e armazenamento de preferncias de chamada. O H.350 padroniza o modo como as informaes multimdia sobre conferncias so arma-
zenadas em diretrio de LDAP, de forma que a colaborao de multimdia possa se integrar mentos da srie incluem o documento H.350 bsico e os subdocumentos H.350.1, H.350.2 etc., cada um dirigindo-se a um protocolo particular de conferncia.
com diretrios de empresas para escalabilidade, gerenciamento e segurana. Os docu-
57
58
Atividade 1 Anlise de troca de mensagens direta entre dois clientes
Esta atividade dever ser realizada em dupla. Os alunos devero utilizar um software de videoconferncia para efetuar chamadas de udio e vdeo com o colega ao lado. A sinalizao do padro H.323 dever ser analisada com auxlio de um software analisador de pacotes (sniffer de redes, como o Wireshark ou tcpdump). Antes de iniciar as chamadas, deve-se iniciar a captura de pacotes para analisar todo o contedo que trafegar pela rede. Interrompa a captura logo aps ter terminado a ligao, para obter tambm o trfego de final de ligao. Alm disso, melhor ter capturas de poucos segundos para no deixar o software de anlise muito lento (com muitos pacotes a analisar). Faa a chamada utilizando o endereo IP do parceiro da dupla, e confirme que o software de videoconferncia no est configurado com gatekeeper. Para facilitar a identificao do trfego, utilize filtros que mostrem apenas o contedo desejado, como por exemplo h225 or h245 or rtp or rtcp. Responda:
1. Quais os IPs origem e destino envolvidos?
2. Quais as portas de origem e destino no H.225 (setup)?
3. Quantos e quais so os fluxos RTP existentes?
4. Para um fluxo RTP, quais as portas de mdia RTP e RTCP utilizadas?
5. Desenhe a troca de mensagens no espao abaixo com o apoio do Wireshark (statistics +
flow graph), detalhando os protocolos, como por exemplo: h.225 setup, h.225 admission
request/confirm, H.245, rtp audio etc. No Wireshark, utilize filtros como h225, h245, rtp e ip para facilitar a visualizao dos pacotes. Voc pode concatenar filtro como neste exemplo: h225 and ip.src == 192.168.0.100 and rtp.p_type==127 (mudar o IP para o IP correto da mquina desejada) ou h225 or h245.
59
Atividade 2 Anlise de troca de mensagens entre dois clientes com gatekeeper

Esta atividade dever ser realizada em dupla. Configure o software de videoconferncia para utilizar o gatekeeper disponibilizado pelo instrutor, conforme orientaes na prtica intermediria. Faa uma ligao novamente entre dois terminais atravs do IP, da mesma forma que na Atividade 1, e utilize o analisador de pacotes para observar as mensagens H.323 trocadas entre os terminais, e entre o gatekeeper e os dois terminais (mensagens H.225, H.245, RTP e RTCP). Discuta o resultado obtido com o colega.
1. Quais os IPs origem e destino envolvidos em todo o processo?
2. O trfego de mdia (pacotes da videoconferncia RTP) est indo diretamente entre os
terminais ou passando pelo gatekeeper.
3. Quais protocolos so utilizados para troca de mensagens diretamente entre os terminais
e quais passam pelo gatekeeper? Desenhe a troca de mensagens no espao abaixo com o apoio do Wireshark (statistics + flow graph), detalhando os protocolos, como, por exemplo: h.225 Registration Request, h.225 setup, h.225 admission request/confirm etc.
60
3
Plano de numerao e gatekeeper
objetivos
Ao final do captulo o aluno estar apto a identificar um plano de numerao E.164 e a configurar um gatekeeper em uma rede H.323.
conceitos
Padro ITU E.164, plano de numerao e plano de discagem, gatekeeper GnuGK (configuraes bsicas, plano de discagem e autenticao de clientes).
Padro ITU E.164

Plano de numerao internacional para a rede de telefonia pblica (e eventualmente para rede de dados). Define estrutura de nmeros e funcionalidade para 4 categorias: 11 Regies geogrficas (foco deste curso). 11 Servios globais. 11 Redes. 11 Grupos de pases.
w
A lista dos cdigos telefnicos de diversos pases pode ser vista em List_of_country_ calling_codes na Wikipedia.
O E.164 uma recomendao ITU-T que define o plano de numerao internacionalmente usado em redes de telefonia pblica e em algumas redes de dados. A recomendao define a estrutura da numerao e como estes nmeros devem ser analisados para que seja feito o seu roteamento. So definidas estruturas de numerao pases. Neste curso o foco dado categoria das regies geogrficas.
Captulo 3 - Plano de numerao e gatekeeper
para 4 categorias: regies geogrficas, servios globais, redes de computadores e grupo de
CP
CA
NA (15 - CP) dgitos Nmero de alcance nacional
1 a 3 dgitos
Mximo de 15 dgitos
Figura 3.1 Estrutura do ITU E.164.
Nmero de alcance internacional
Nmeros E.164 so limitados a no mximo 15 dgitos, normalmente representados com o prefixo +.
61
Exemplo: +555199998888. Nmeros para reas geogrficas so divididos em 3 partes: 11 CP = Cdigo do pas Usa-se de um a trs dgitos para representar o cdigo da regio. Em geral, o cdigo da regio representa um pas, exceto para Estados Unidos e Canad, que utilizam o mesmo cdigo. 11 CA = Cdigo de rea 11 NA = Nmero do assinante de responsabilidade da agncia reguladora do setor de cada pas a administrao de seu plano de numerao, incluindo a quantidade de dgitos utilizados para nmero do assinante, cdigo de rea etc.
Os nmeros E.164 so limitados a, no mximo, 15 dgitos, e normalmente so representados incluindo o prefixo +. Para a categoria de reas geogrficas, os nmeros E.164 so divididos em 3 partes: 11 CP: Cdigo do pas. Cdigo de 1 a 3 dgitos que representa a regio geogrfica em que o nmero se localiza. Em geral, o cdigo da regio representa um pas, exceto para Estados Unidos e Canad que utilizam o mesmo cdigo. 11 CA: Cdigo da rea. Cdigo (opcional) da regio dentro do pas. 11 NA: Nmero do assinante. Contm no mximo (15 CA CP) dgitos e o nmero que identifica cada assinante individualmente. O cdigo do pas estabelecido mundialmente, enquanto os cdigos de rea e nmeros de assinante so de responsabilidade da agncia reguladora do setor de cada pas.
Plano de numerao
O uso de um plano de numerao consistente em uma rede de videoconferncia simplifica a alocao de identificadores para terminais, e consequentemente facilita a discagem para o usurio final. O plano de numerao a definio de como ser a identificao numrica dos terminais e reas da videoconferncia e como ser feito o roteamento das chamadas atravs desses
identificadores. O plano de numerao muito importante, pois simplifica a identificao de terminais, e consequentemente facilita a discagem para o usurio final. A VideNET um exemplo de rede de videoconferncia de alcance global, e utiliza o esquema Global Dialing Schema (GDS), que um plano de numerao proposto para redes de vdeo e voz sobre IP; esse plano de endereamento muito similar ao plano de numerao do sistema telefnico internacional. Com o GDS, possvel numerar cada terminal de videocon Administrao de Videoconferncia
ferncia, sala virtual de MCUs e gateway. O plano de numerao permite a integrao com outras redes de videoconferncia e tambm com outros tipos de redes, tais como: 11 VoIP: estabelecimento de udio conferncia; 11 Public Switched Telephone Network (PSTN): terminais conectados via ISDN. Os identificadores atribudos para os terminais so vlidos apenas no mbito da rede local da videoconferncia e no necessrio que seja atribudo um identificador E.164 completo (15 dgitos) para cada terminal. Duas instituies podem, por exemplo, compartilhar os mesmos identificadores dos terminais, mas para elas interagirem devero possuir cdigos
w Para mais informaes

visite o site da VideNET.
62
de rea distintos. Dependendo do tamanho da rede de videoconferncia, os identificadores podem ser herdados da telefonia convencional (o que no quer dizer que eles sero acessveis a partir dela). O acesso a partir da rede de telefonia convencional requer conexo atravs de GW IP-PBX (dotados de interfaces BRI ou PRI para vdeo/udio ou FXO para udio). Identificao para terminais: 11 No necessariamente atribudo um identificador E.164 completo. 11 O identificador ser vlido apenas no mbito da rede local de videoconferncia. 11 Dependendo do tamanho da rede de videoconferncia, os identificadores podem ser herdados da telefonia convencional (isso no quer dizer que sero acessveis a partir dela). Para chamadas entre terminais na mesma rea pode simplesmente ser utilizada discagem de 4 dgitos. Exemplo: Terminal 1 liga para Terminal 2 discando: 2000. Para chamadas para terminais de fora da rede deve ser utilizado o cdigo de rea. Exemplo: Terminal 1 liga para Terminal 3 discando: 0 22 1000 (com prefixo de escape 0). O plano de discagem integra-se ao plano de numerao, fundamental para o desenvolvimento dessas e de outras facilidades. Terminal 1 na rea A Formato dos nmeros Prefixo da rea Nmero do terminal Nmero completo YY XXXX 11 1000 11 1000 Terminal 2 na rea A YY XXXX 11 2000 11 2000 Terminal 3 na rea B ZZ XXXX 22 1000 22 1000
Figura 3.2 Exemplo de numerao para trs terminais.
Para um terminal efetuar uma chamada para um terminal que est na mesma rea, pode simplesmente ser utilizada discagem de 4 dgitos. Por exemplo, o Terminal 1 (rea A) pode ligar para o Terminal 2 (rea A) discando apenas (2000). Para chamadas para terminais de fora da rede (rea) deve ser utilizado o cdigo de rea. Assim, para o Terminal 1 ligar para Terminal 3, por exemplo, ele deve discar (0 22 1000), necessitando discar um cdigo de escape antes, no caso 0, para informar que est ligado para fora da sua rea. Esse nmero
definido no plano de discagem. A numerao abreviada possvel graas ao recurso de reescrita do servidor de sinalizao gatekeeper para H.323 e proxy para SIP.
Plano de discagem
Funes do plano de discagem: 11 Permitir facilidade e flexibilidade para discagem. 11 Garantir que chamadas para fora da rea e pas possam ser facilmente encaminhadas. A discagem da rede de telefonia convencional brasileira, por exemplo, inclui os prefixos: 11 0 chamadas para fora da rea. 11 00 chamadas para fora do pas.
63
Qualquer tipo de discagem, por exemplo abreviada ou hiper abreviada, deve ser definida no plano de discagem. No H.323, os planos de numerao de discagem so implementados no gatekeeper.
Enquanto o plano de numerao define como ser a atribuio de identificadores aos terminais, o plano de discagem define como ser feita a discagem entre estes terminais. Uma das preocupaes garantir que chamadas para reas externas (fora da regio, fora do estado, fora do pas etc.) sejam facilmente encaminhadas. Essas ligaes externas normalmente so identificadas por prefixos durante a discagem. Na telefonia convencional brasileira, por exemplo, discagens para outras reas so identificadas pelos prefixos 0 e 00. Exemplos: 11 Para chamar um terminal de dentro da rede (4 dgitos): 1234 (interpretao feita pelo PABX). 11 Para chamar um terminal de uma rede remota dentro da cidade: 3333 1234. 11 Para chamar um terminal de uma rede remota dentro do pas: 0 51 3333 1234. 11 Discar para um terminal de uma rede fora do pas: 00 55 51 3333 1234. No plano de discagem tambm so definidos outros tipos de discagem, como a discagem abreviada ou hiper abreviada, que facilitam as chamadas entre terminais: 11 Discagem abreviada discagem local de 8 dgitos, utilizada na telefonia convencional. 11 Discagem hiper abreviada discagem ramal de 4 dgitos, utilizada em PABX. Redes distintas podem implementar planos de discagem diferentes. A implementao ocorre nos servidores de sinalizao, responsveis pelo roteamento das chamadas. No H.323, os planos de numerao de discagem so implementados no gatekeeper.
Gatekeeper GnuGK
Implementao de cdigo livre de um gatekeeper H.323 (licena GPL), que prov as diversas funcionalidades de um gatekeeper, entre elas: 11 Autenticao por SQL (BD), RADIUS, arquivos ou aplicaes externas. 11 Reescrita de nmeros (plano de discagem e numerao). 11 Modo proxy. Funciona em diversos sistemas operacionais: Linux, Windows, MacOS X, FreeBSD etc. GnuGK uma implementao de um gatekeeper que tem base nas bibliotecas PWlib (biblioteca para portabilidade de cdigo, especialmente relacionado rede, I/O e threads)
e OpenH323, esta ltima uma implementao de cdigo aberto do protocolo H.323. uma ferramenta de cdigo aberto (licena GPL), flexvel e que disponibiliza as diversas funcionalidades necessrias para um gatekeeper.
Uma das funcionalidades do GnuGK a autenticao de usurios para controle de admisso. Ele permite autenticao por bancos de dados SQL, servidores RADIUS (Remote Authentication Dial In User Service), LDAP (Lightway Directory Access Protocol ), alm de arquivos locais ou aplicaes externas. O GnuGK tambm permite reescrita de nmeros, para implementao do plano de numerao e discagem, faz o roteamento de chamadas, possui modo full proxy, possibilita controle de banda, suporta segurana por H.235, entre diversas outras funcionalidades. A aplicao funciona em diversos sistemas operacionais, entre eles Linux, Windows, MacOS X e FreeBSD.
64
Instalao do GnuGK
O primeiro passo para utilizao do GnuGK a instalao da aplicao. A instalao obviamente depende do sistema no qual o aplicativo ser instalado. O site do GnuGK disponibiliza verses da aplicao compiladas para diversos sistemas operacionais, incluindo Linux, Windows e MacOS. Para estes sistemas, basta obter os executveis e instal-los. O manual do GnuGK possui uma seo de instalao que pode auxiliar este processo. Para sistemas no suportados ou para fazer otimizaes/personalizaes na aplicao, possvel obter o cdigo-fonte do GnuGK e compil-lo para o sistema alvo. No Debian, aplicaes podem ser instaladas facilmente com o gerenciador de pacotes apt-get, que tambm permite instalar o GnuGK. Esta aplicao instala o GnuGK e todas as suas dependncias (todas as bibliotecas de que ele necessita). Normalmente o comando de instalao no Linux :
Consulte o manual do GnuGK em gnugk.org.
11 [-t] especifica o nvel de debug. Quanto maior o nmero de -ts, maior ser o nvel de debug. Para a opo de depurao o indicado o nvel de debug 3, ou seja, [-ttt]. Ao ser instalado no Linux, o GnuGK tambm instala um script que facilita a inicializao e finalizao do programa. Este script instalado em /etc/init.d/gnugk e possui as opes: Iniciar: /etc/init.d/gnugk start Parar: /etc/init.d/gnugk stop Reiniciar: /etc/init.d/gnugk restart
$ apt-get install gnugk

Mais detalhes de instalao e compilao podem ser vistos no manual do GnuGK.
Inicializao do GnuGK
11 O executvel aplicativo chama-se gnugk, que possui diversas opes para configurao. Para ver as opes possveis use o comando gnugk help. Exemplo de execuo:
gnugk c /etc/gnugk.ini o /var/log/gnugk.log ttt
A execuo do aplicativo GnuGK no Linux feita atravs do executvel chamado gnugk . Seguindo a instalao padro feita com o apt-get no Debian, este executvel estar instalado em /usr/sbin. Para execut-lo deve-se estar logado como superusurio (root). O GnuGK possui diversas opes que podem ser configuradas por linha de comando na execuo da aplicao. Para verificar as opes possveis basta digitar o comando:
gnugk --help
Algumas opes interessantes: 11 [-c arquivo_de_configurao] especifica o arquivo de configurao que ser utilizado (arquivo que ser descrito mais adiante). 11 [-o arquivo_de_log] especifica o arquivo onde ser gravado o log da aplicao.
65
Ao iniciar o GnuGK por este script, ele utiliza algumas configuraes padro especificadas pelo script: Arquivo de configurao: /etc/gatekeeper.ini Arquivo de log : /var/log/gnugk/gnugk.log Para ter certeza que o GnuGK est em execuo no Linux, possvel executar o comando abaixo que informa se o aplicativo est em execuo:
ps -ef | grep gnugk

Se o programa estiver em execuo, aparecer, entre outras informaes, uma linha contendo o nome e caminho do executvel do GnuGK: /usr/sbin/gnugk.
GnuGK no Windows
O GnuGK disponibilizado para Windows em dois formatos, servio e aplicao. Para iniciar o GnuGK (aplicao) basta executar: 11 gnugk.exe c etc/gnugk.ini Este arquivo segue o mesmo formato da verso Linux. Para modificar as configuraes basta fechar o GnuGK, editar o arquivo e iniciar o GnuGK novamente.
Alm da verso para Linux discutida ao longo deste captulo, o GnuGK tambm disponibilizado para a plataforma Windows em duas verses: 11 Servio: como o nome diz, a aplicao executada como um servio do sistema. 11 Aplicao: o GnuGK executado como uma aplicao padro do sistema. As duas verses so da mesma aplicao e possuem as mesmas funcionalidades, a nica diferena a forma como so executadas. Para executar o GnuGK (verso aplicao) basta dar dois cliques no seu executvel. O GnuGK buscar por um arquivo chamado gatekeeper.ini na mesma pasta onde est o executvel. Para especificar outro arquivo de configurao, possvel executar a aplicao com o comando -c. No exemplo abaixo, execute o arquivo gnugk.ini, que est dentro do diretrio etc :
gnugk.exe c etc/gnugk.ini
O GnuGK j vem com um arquivo gnugk.ini padro que pode ser utilizado inicialmente. Para modificar as configuraes do GnuGK basta editar o arquivo gnugk.ini e executar a apli cao. O GnuGK executado em uma janela do prompt de comando do Windows que ficar sendo exibida enquanto a aplicao est rodando.
Configurao do GnuGK (Windows, Linux e outros)

Estrutura do arquivo de configurao: 11 Arquivo texto padro composto por sees. 11 Cada seo contm um nome e uma lista de parmetros com seus respectivos valores. Para no precisar especificar a localizao do arquivo de configurao a cada execuo do GnuGK, crie um arquivo chamado de gatekeeper.ini no mesmo diretrio onde est o aplicativo do GnuGK ou copie o arquivo padro gnugk.ini do diretrio /etc e aps altere o nome.
66
Este arquivo organizado em diversas sees, cada uma delas contendo uma lista de parmetros com seus respectivos valores. As sees possuem nomes fixos e pr-determinados, que so colocados entre colchetes. Segue abaixo um exemplo de uma seo:
[NomeDaSecao1] Parametro1=Valor1 ParametroN=ValorN

Os parmetros tambm possuem nomes fixos e aceitam determinados valores, que variam conforme o parmetro. Atentar para a digitao dos parmetros e seus valores, pois eles so sensveis a maisculas e minsculas. O arquivo possui um requisito mnimo que a seo:
[Gatekeeper::Main] Fourtytwo=42
11 Outros parmetros da seo [Gatekeeper::Main]:
Name=H_323_ID_Gatekeeper Home=IP_do_Gatekeeper TimeToLive=300TotalBandwidth=512000 StatusPort=7000
O arquivo de configurao do GnuGK tem um requisito mnimo, que a presena da seo [Gatekeeper::Main] com o parmetro Fortytwo=42. A opo de configurao Fourtytwo=42 serve para indicar que o arquivo um arquivo de configurao do GnuGK. Outros parmetros possveis nesta seo: 11 Name: identificador do gatekeeper. O gatekeeper somente responder aos GRQs que forem direcionados para este ID e o usar em todas as mensagens com os terminais. 11 Home: endereo IP a partir do qual o gatekeeper receber requisies. Por default, o gatekeeper ouve todas as interfaces de seu host. 11 TimeToLive: tempo da validao do registro de um terminal (em segundos). O terminal deve periodicamente enviar mensagem RRQ tendo o bit keepAlive ativado para que seu registro no expire. Depois de expirado, o registro deve ser revalidado. 11 TotalBandwidth: largura de banda total disponvel para os terminais.
11 StatusPort: porta de status utilizada para monitoramento e controle do gatekeeper. Para adicionar comentrios no arquivo de configurao, insira o caractere ponto-e-vrgula antes do comentrio. Este recurso extremamente til para descrever modificaes ou para anular a funcionalidade de um parmetro sem a necessidade de apag-lo do arquivo. O ponto-e-vrgula (;) pode ser adicionado em qualquer parte, mas s tem efeito na prpria linha em que for utilizado, conforme pode ser visto abaixo:
[Gatekeeper::Main] ;Qualquer parametro ou texto apos um ; ser ignorado.
;O parametro abaixo identifica um arquivo de config do GnuGK.
67
Fortytwo=42 Name=GnuGk TimeToLive=60 ; EnableIPv6=1 ; utilizado em algumas mensagens RAS
;Valor modificado. O default 600. ;Este parmetro ser ignorado pelo GnuGK.
Se o arquivo de configurao for editado com o GnuGK em execuo, ser necessrio reinici-lo para que as novas configuraes tenham efeito. Se o servidor GnuGK for reiniciado, todas as chamadas realizadas atravs do gatekeeper sero desconectadas e novas chamadas somente sero possveis depois que o servidor estiver devidamente operacional. Para evitar essa indisponibilidade, pode ser utilizado o comando reload atravs da console de monitoramento, que ser vista a seguir.
Monitoramento do GnuGK
Porta de status: 11 Monitorar e controlar as funes do gatekeeper. 11 Estabelecer e desconectar chamadas. 11 Desconectar terminais. 11 Visualizar e alterar as configuraes em tempo real. 11 Desligar o gatekeeper. 11 Suas configuraes so feitas na seo [GkStatus::Auth]. 11 Acesso atravs da porta configurada (padro: 7000): 22 telnet IP do gatekeeper 7000 Deve ser configurada de tal forma que evite o uso indevido, causador de interrupo e utilizao inadequada dos recursos. A porta de status utilizada para monitorar as atividades do gatekeeper. A porta que ser utilizada configurada pelo parmetro StatusPort da seo [Gatekeeper::Main] do arquivo de configurao, j comentada. Alm de monitorar as atividades, pela porta de status possvel controlar chamadas e terminais (desconectar um terminal, por exemplo) e alterar configuraes do gatekeeper.
A grande vantagem de se comunicar com o gatekeeper pela porta de status a possibilidade de controlar remotamente este gatekeeeper. Se a porta de status configurada foi a 7000, por exemplo, basta criar uma conexo telnet com o gatekeeper na porta 7000 que ser possvel monitor-lo. Abaixo segue o comando para se conectar porta de status do gatekeeper local:
$ telnet localhost 7000 $ telnet 127.0.0.1 7000

Para se conectar a um gatekeeper remoto basta modificar o segundo parmetro para o IP do gatekeeper alvo. O acesso ao monitoramento deve ser realizado por telnet, mesmo que se esteja operando o computador onde est instalado o GnuGK. As configuraes especficas para a porta de status so feitas na seo [GkStatus::Auth] do arquivo de configurao. Esta seo possui alguns parmetros importantes para restringir o acesso porta de status, que so:
68
Shutdown
Permitir ou no o desligamento do gatekeeper pela porta de status. Dois valores possveis: 11 allow : permite desligamento. 11 forbid : no permite desligamento.
Rule
Define os hosts que tero permisso de acesso porta de status. Por padro no permite nenhuma conexo. Pode receber os valores: 11 forbid: desabilita quaisquer conexes; 11 allow : permite quaisquer conexes; 11 explicit: l um outro prametro ip=value onde ip o endereo do cliente de gerncia/monitoramento, value pode ser 1 (permite acesso), 0 (nega acesso) ou allow/forbid ou yes/no; 11 regex : valida o endereo IP do cliente atravs de uma expresso regular; 11 password: valida atravs de usurio e senha. Alm disso, estas regras podem ser combinadas por | ou &. Por exemplo:
rule=explicit | regex
O comando reload recarrega o arquivo de configurao sem a necessidade de reiniciar o GnuGK; entretanto, as configuraes s sero efetuadas em chamadas que forem iniciadas aps o comando, ou seja, chamadas em andamento no momento no sero afetadas. O endereo IP do cliente deve casar explicitamente (explicit) ou com a regra regex.
rule=regex & password

O endereo IP do cliente deve casar com a regra regex, e o usurio tem que fazer login com usurio e senha.
Regex
Expresso regular para validao do endereo que est tentando acessar a porta de status do gatekeeper. Parmetro utilizado quando rule=regex. Alm das opes citadas, a seo [GkStatus::Auth] tambm pode conter parmetros do tipo <username>=<senha> e <ip>=<allow/forbid> quando o parmetro rule contiver os valores password ou explicit, respectivamente. Exemplo de controle de autenticao na porta de status:
[GkStatus::Auth] Shutdown=allow|forbid rule=regex|password|explicit regex=^127\.0\.0\.1|^192\.168\.1\.(10|11)$ gkadmin=J48HbZsUJPk 192.168.1.12=allow ; password ; rule=explicit ; rule=regex
69
No exemplo acima, a expresso regular limita o acesso para os endereos local 127.0.0.1 (loopback) e dos IPs 192.168.1.10 e 192.168.1.11. Pelo parmetro gkadmin=ssssss, disponibilizado o acesso para qualquer endereo que utilizar nome de usurio gkadmin e a senha correta. A senha correta no a que aparece no exemplo, J48HbZsUJPk, pois este o valor da senha original aps ser criptografada pelo utilitrio addpasswd, que ser comentado posteriormente. Alm disso, como rule contm o valor explicit, foi includo o parmetro 192.168.1.12=allow, que permite acesso para o IP 192.168.1.12. Relembrando, para se conectar porta de status basta digitar o comando:
$ telnet localhost 7000

Comandos principais da porta de status:
h printallregistrations | rv | ? printcurrentcalls | cv shutdown unregisterallenpoints disconnetip [ip] disconnectalias [alias] reload debug cfg [seo]
Estando conectado, diversos comandos podem ser enviados porta de status para obter informaes sobre o gatekeeper ou solicitar que ele execute alguma ao. Principais comandos disponveis: 11 h: imprime todos os comandos; 11 printallregistrations | rv | ? : imprime todos os endpoints registrados (so 3 comandos separados pelo sinal |, e qualquer um deles pode ser utilizado); 11 printcurrentcalls | cv : imprime as chamadas em andamento; 11 shutdown: desliga o gatekeeper; 11 unregisterallendpoints: fora o cancelamento do registro de todos os endpoints registrados; 11 disconnectip [ip]: desconecta todas as chamadas de um determinado endereo IP; 11 disconnectalias [alias]: desconecta todas as chamadas de um determinado alias (usurio);
11 reload: recarrega as configuraes do arquivo de configuraes; 11 debug cfg [seo]: imprime as configuraes de uma determinada seo (do arquivo de configuraes). 11 Algumas alteraes do arquivo de configurao (principalmente as relacionadas com endereamento IP) no tero efeito mesmo aps o comando reload. Verifique o manual do GnuGK para mais detalhes.
Zoneamento
As zonas H.323 so definidas por um gatekeeper, e podem ser de domnios administrativos distintos. A segmentao em zonas permite a criao de grandes redes de videoconferncia.
70
Cada zona ser constituda por um gatekeeper e pelo menos terminais H.323. Mensagens LRQ/LCF so utilizadas para localizao do terminal remoto. Configurao do zoneamento no GnuGK: A seo [RasSrv::Neighbors] especifica todos os gatekeepers vizinhos. A sintaxe das linhas desta seo configurao :
<NomeGK>=IP_Gatekeeper;<prefixo1>,<prefixo2>
Exemplo:
[RasSrv::Neighbors] GKA=192.168.1.1;033,044 GKB=192.168.2.1;055 GKC=192.168.3.1;01

Na separao por zonas, os gatekeepers de diferentes zonas possuem referncias que os associam. Esta associao feita por nmeros E.164. Supondo que o GKA tenha prefixo 11, GKB 22 e GKC 33, a configurao para o GKA :
[RasSrv::Neighbors] GKB=192.168.2.1;022 GKC=192.168.3.1;033
ISDN
Sistema telefnico Gateway
Terminal
Gatekeeper
Roteador
MCU
Figura 3.3 Exemplo de zona H.323.
Zona H.323
As zonas H.323 so definidas por um gatekeeper nico, ao qual esto conectados outros elementos H.323 (terminais, MCU etc.). A segmentao em zonas permite a criao de grandes redes de videoconferncia, onde cada zona controlada pelo seu gatekeeper e pode constituir um domnio administrativo diferente das outras (uma zona H.323 de uma determinada empresa, por exemplo).
71
GK A
GK C
GK B
Figura 3.4 Cada gatekeeper possui duas referncias.
A comunicao entre os gatekeepers de zonas diferentes feita pela troca de mensagens LRQ/ LCF (Location Request/Location Confirm), que sero explicadas na sequncia deste captulo. Os gatekeepers podem ser associados de diversas maneiras. Uma maneira comum a organizao hierrquica, onde um gatekeeper (na figura abaixo, o DGK Directory Gatekeeper), corresponde ao nvel primrio da hierarquia, se comunicando com diversos outros gatekeepers de nvel secundrio (GK A, GK B, GK C). O nmero de nveis poderia ser aumentado, se necessrio. Neste modelo, o DGK conhece os 3 gatekeepers abaixo dele, ento esses 3 gatekeepers conhecem apenas o DGK.
Hierarquia de gatekeepers
A organizao das zonas H.323 pode tambm ser feita de forma hierrquica. Supondo que o DGK tenha prefixo 99, GKA tenha prefixo 11, GKB 22 e GKC 33, a configurao para o DGK :
[RasSrv::Neighbors] GKA=192.168.1.1;011
GKB=192.168.2.1;022 GKC=192.168.3.1;033
E para o GKA, GKB e GKC :
[RasSrv::Neighbors] DGK=192.168.1.254;*
DGK
GK A
GK B
GK C
Figura 3.5 Organizao hierrquica das zonas.
72
A referncia de um gatekeeper para o outro feita atravs de nmeros E.164 e IPs. Ou seja, especificado um nmero (ou um prefixo apenas) que ao ser acionado redirecionar a mensagem para o IP (gatekeeper) ligado a este nmero. Por exemplo:
DGK=192.168.2.1;55
A linha acima indica um nome, um IP e um nmero. Quando o gatekeeper que contm esta linha em sua configurao receber uma chamada contendo o prefixo 55, ele redirecionar esta chamada para o gatekeeper de IP 192.168.2.1, que chamado DGK. No GnuGK, as ligaes entre os gatekeepers so feitas na seo [RasSrv::Neighbors] do arquivo de configurao. Esta seo pode conter diversas linhas especificando os vizinhos deste gatekeeper, como no exemplo anterior. A sintaxe dessas linhas :
<NomeGK>=IP_Gatekeeper;<prefixo1>,<prefixo2>
Onde: 11 NomeGK : nome dado localmente ao gatekeeper. 11 IP_Gatekeeper : IP do gatekeeper. 11 Prefixo: nmeros deste gatekeeper. Podem ser utilizados diversos prefixos. Exemplos:
INTA=192.168.1.1;033,044 INTB=192.168.2.1;055 DGK=10.1.1.1;*

Para todas as chamadas recebidas, primeiro verificado se o nmero chamado no um nmero local, ou seja, um terminal conectado ao gatekeeper. Se no for o caso, ento o gatekeeper verifica seus vizinhos para reencaminhar a chamada. O asterisco (*) indica que para qualquer destino no conhecido (no um terminal local e no nenhum dos gatekeepers especificados) a localizao deve ser encaminhada ao DGK.
Mensagens LRQ
Em ambientes de videoconferncia onde diferentes zonas H.323 se interligam, os gatekeepers de cada rea precisam conversar entre si. Para a localizao de terminais, os gatekeepers de zonas diferentes trocam mensagens LRQ (e as respostas para estas): 11 LRQ: Requisio de Localizao 11 LCF: Confirmao de Localizao 11 LRJ: Rejeio de Localizao O processo de troca dessas mensagens se d quando um gatekeeper recebe uma chamada em que o destinatrio no conhecido por este gatekeeper, por exemplo. Neste caso, a troca de mensagens se d da seguinte forma: 11 Gatekeeper GK recebe chamada e no encontra destinatrio D (no um terminal registrado nele); 11 GK procura em sua lista de gatekeepers vizinhos quais devem ser consultados; 11 GK envia LRQ para este(s) vizinho(s), buscando pelo terminal D;
A sintaxe completa das configuraes mais complexa, onde pode ser inclusive atribuda uma senha para autenticao dos vizinhos. Mais detalhes podem ser encontrados na documentao do GnuGK.
73
11 O vizinho que encontra o destinatrio responde com uma mensagem LCF; 11 Se o vizinho no encontra o destinatrio, ele responde com uma mensagem LRJ. O comportamento dessas mensagens definido na seo [RasSrv::LRQFeatures], que contm os parmetros: ForwardLRQ 11 Permite ou no o encaminhamento das mensagens LRQ. ForwardResponse 11 Em 1, as respostas ao LRQ passam pelo gatekeeper. 11 Em 0, as respostas vo direto ao originador. ForwardHopCount 11 Quantidade de hops ou gatekeepers pelos quais as mensagens de LRQ passaro. 11 Semelhante ao campo TTL do protocolo IP. Para uma hierarquia de dois nveis, um exemplo de configurao :
[RasSrv::LRQFeatures] ForwardLRQ=depends ForwardResponse=1 ForwardHopCount=1

No GnuGK, o comportamento das mensagens LRQ e suas respostas definido na seo [RasSrv::LRQFeatures], que contm, entre outros, os parmetros a seguir.
ForwardLRQ
Aceita as opes: always
| never | depends.
Controla o encaminhamento das mensagens LRQ, se elas devem ser feitas sempre, nunca ou dependendo do hop count (se for maior que 1, a mensagem ser encaminhada; caso contrrio ser rejeitada).
ForwardResponse
Controla a necessidade do gatekeeper de receber o LCF quando encaminha mensagens LRQ. Se no configurado, o LCF pode ser encaminhado direto para quem originou o LRQ, sem passar por este gatekeeper.
ForwardHopCount
Atribui um valor numrico para a quantidade de hops ou gatekeepers pelos quais as men Administrao de Videoconferncia
sagens de LRQ passaro. Semelhante ao campo TTL do protocolo IP, utilizado para evitar loops infinitos. Padro de configurao desses parmetros: 11 ForwardHopCount: no definido. 11 ForwardLRQ: depends. 11 ForwardResponse: 0.
74
Reescrita de nmeros E.164

A funcionalidade de reescrita de nmero E.164 permite a implantao do plano de discagem. A partir de um determinado nmero chamado, uma ao de reescrita desse nmero realizada com o objetivo de encaminhar a chamada corretamente, o que feito na seo [RasSrv::RewriteE164]. Para cada regra de reescrita deve-se usar a sintaxe: [!]nmero-original=nmero-destino A implementao de um plano de numerao completo pode exigir dezenas de regras, que devem ser vistas sob dois aspectos: chamadas para dentro da zona ou chamadas para fora. A seguir exemplos com DGK hierrquico. Chamada do terminal A para o B (ambos na rea 11) 11 Direto pelo ramal: 2000 11 Com cdigo da rea: 11 2000 11 Regra (GK A): 11....=.... Chamada do terminal A para o C 11 Deve incluir cdigo de rea e escape: 0 33 1000 11 Regra (GK C): 033....=.... 22 GK A encaminha ligaes com prefixo 0 para o DGK. 22 DGK encaminha ligaes com prefixo 033 para GK C. A funcionalidade de reescrita de nmero E.164 permite a implantao do plano de discagem no GnuGK. A partir de um determinado nmero chamado, uma ao de reescrita
desse nmero realizada pelo gatekeeper com o objetivo de encaminhar a chamada para o terminal (ou gatekeeper) correto. Fazendo uma comparao com o sistema telefnico, por exemplo, se algum localizado no Rio Grande do Sul faz uma ligao para o Rio de Janeiro discando 0-xx-21-1234-1234, este nmero deve ser encaminhado para o terminal de nmero 1234-1234, sendo que os primeiros dgitos (0-xx-21) so apenas para permitir que a ligao seja encaminhada corretamente. No GnuGK, a reescrita dos nmeros feita na seo [RasSrv::RewriteE164], que pode possuir diversas regras com a seguinte sintaxe:
[!]nmero-original=nmero-destino
Se a regra comea com nmero-original, indica que este nmero deve ser substitudo por nmero-destino. Se a regra comea com o prefixo !, inverte-se o sentido da regra, fazendo com que os nmeros que no tm nmero-original como prefixo, tenham nmero-destino adicionado como prefixo. Tambm esto disponveis os caracteres curinga . e %. O caractere . indica que deve haver um dgito qualquer na posio em que ele est, enquanto % indica que o nmero daquela posio ser eliminado. Se tivermos, por exemplo, as seguintes regras de reescrita:
[RasSrv::RewriteE164] 08=188 !08=188 (substituio simples) (negao. Tudo que no for 08)
75
%%%%.=. 0044....=144....
Neste caso:
(elimina 4 dgitos) (iniciado com 0044 com pelo menos 4 dgitos mais)
11 Se discado 082222, o resultado da reescrita ser 1882222; 11 Se discado 092222, o resultado ser 188092222; 11 Se discado 11112000, o resultado ser 2000; 11 Se discado 00441234, o resultado ser 1441234. A implantao de um plano de numerao completo pode exigir dezenas de regras, e deve sempre ser vista sob dois aspectos: chamadas para dentro da zona ou chamadas para fora. Chamadas para dentro da zona so aquelas encaminhadas por outros gatekeepers com destino aos terminais da rede local de videoconferncia. Chamadas para fora da zona so aquelas com destino a outras redes de videoconferncia (outros gatekeepers). Os exemplos abaixo so novamente relacionados com ligaes telefnicas e mostram como podem ser necessrias diversas regras caso existam diversos pases, reas e terminais. Os exemplos so de regras em um gatekeeper no Brasil, na rea 21. Ele procura reescrever todos os nmeros para o formato <cdigo-pas><cdigo-rea><cdigo-terminal>, exceto as chamadas para terminais locais, que so reescritas para o nmero do terminal local. Exemplos usando o DGK: 11 Chamada do terminal A para o B (ambos na rea 11): 22 Chamada direto pelo ramal: 2000 22 Chamada com cdigo de rea: 11 2000 Regra (GK A) remove cdigo de rea: 11....=.... 11 Chamada do terminal A para o terminal C (rea 33): 22 Deve sempre ser adicionado ao ramal o cdigo de rea do destino e o dgito de escape: 0 33 1000 Regra (GK C): 033....=.... GK A encaminha ligaes com prefixo 0 para o DGK. O DGK encaminha ligaes com prefixo 033 para o GK C.
DGK
rea 11
rea 22
rea 33
GK A
GK B
GK C
Cliente A
1000
Cliente B
2000
Cliente C
1000
Figura 3.6 Chamada entre cliente de mesma rea.
76
DGK
rea 11
rea 22
rea 33
GK A
Figura 3.7 Chamada entre cliente de rea diferente.
GK B
GK C
Cliente A
1000
Cliente B
2000
Cliente C
1000
Autenticao
A autenticao e o registro de terminais so feitos atravs de mensagens RRQ e suas respostas (RCF, RRJ). No GnuGK, a autenticao configurada na seo [Gatekeeper::Auth]. Diversos mecanismos de autenticao disponveis: 11 Autenticao simples por alias e IP. 11 Utilizao de bancos de dados SQL. 11 Autenticao em servidores RADIUS, entre outros. A autenticao dos terminais feita atravs das mensagens RRQ (Registration Request ) enviadas dos terminais para o gatekeeper, e das respostas que o gatekeeper d a essas
mensagens, seja RRJ (Registration Reject ) ou RCF (Registration Confirm). Para mais detalhes das mensagens H.225, reveja o Captulo 2. No GnuGK, a configurao da autenticao de terminais feita inicialmente na seo [Gatekeeper::Auth] e se estende para outras sees conforme os mecanismos de autenticao selecionados. Esta seo tem, basicamente, a seguinte estrutura:
[Gatekeeper::Auth] <mecanismo1>=<regra>;RRQ
<mecanismo2>=<regra>;RRQ ...
O exemplo acima mostra a utilizao de dois mecanismos de validao, ambos aplicados sobre as mensagens RRQ. A sintaxe das linhas que especificam os mecanismos de validao a seguinte:
<mecanismo>=<regra>;RRQ
Onde: 11 <mecanismo>: indica como ser feita a autenticao: senha simples, utilizando banco de dados SQL, autenticao por IP, entre outras; 11 <regra>: define se este mecanismo obrigatrio, opcional, ou outras opes;
77
11 RRQ: identifica que o mecanismo ir atuar sobre as mensagens RRQ. Pode ser substitudo por outros valores, como ARQ e GRQ. No restante dos exemplos ser utilizado apenas RRQ para facilitar o entendimento.
Mecanismos
Existem diversos mecanismos de validao disponveis. Entre os mais importantes esto: 11 SimplePasswordAuth: validao por usurio e senha. 11 AliasAuth: valida uma tupla (alias, IP), onde alias pode ser o apelido ou ramal de um terminal. 11 SQLPasswordAuth: o mesmo que SimplePasswordAuth, mas utiliza um banco de dados SQL para armazenar as informaes (usurios e senhas). 11 SQLAliasAuth: o mesmo que AliasAuth, mas utilizando um banco de dados com os aliases. 11 RadAliasAuth: similar a AliasAuth, mas utilizando servidores RADIUS (Remote Authentication Dial In User Service), que um protocolo de redes que permite o uso de servios de autenticao, autorizao e contabilizao centralizados em um servidor. Um servidor RADIUS pode fazer a ponte entre o GnuGK e uma base LDAP. 11 RadAuth: validao de usurio e senha com base no H.235 e utilizando servidores RADIUS. No restante deste captulo sero vistos, principalmente, os mecanismos SimplePasswordAuth e AliasAuth. O addpasswd um utilitrio instalado com o GnuGK que permite a criao de senhas criptografadas para serem armazenadas no arquivo de configurao. Duas sees do arquivo de configuraes onde senhas costumam ser utilizadas so as sees GkStatus::Auth, para autenticao na conexo com a porta de status, e SimplePasswordAuth, para autenticao de terminais. A sintaxe do aplicativo simples, basta escolher o arquivo de configurao e a seo deste arquivo, onde a senha ser gravada e entrar com o nome de usurio e sua senha. A sintaxe e um exemplo seguem abaixo:
$ addpasswd [arquivo_de_config] [seo] [usurio] [senha] $ addpasswd /etc/gatekeeper.ini GkStatus::Auth admin senha123
Em relao s regras, so elas que especificam como (e quanto) o mecanismo deve ser utilizado. Antes de mostrar as regras disponveis, interessante observar que a execuo de um mecanismo pode ter como resultado um dos 3 valores a seguir:
11 ok : a requisio foi autenticada por este mecanismo; 11 fail: a autenticao com este mecanismo falhou e deve ser rejeitada (uma senha incorreta, por exemplo); 11 next: o mecanismo no pode realizar a autenticao (validao de um nome de usurio no existente na base de dados, por exemplo). V para o prximo mecanismo.
Regras
Sabendo dos possveis resultados, podemos verificar as regras disponveis: 11 optional: se no puder autenticar com este mecanismo, o prximo mecanismo ser utilizado;
78
11 required: a requisio deve ser autenticada utilizando o mecanismo especificado, caso contrrio ser rejeitada. Ainda assim, o prximo mecanismo configurado ser checado para validar o registro; 11 sufficient: o mesmo processo da regra required, com a diferena de que nenhum mecanismo depois desse ter validade. Ou seja, a resposta dada a este mecanismo a resposta final autenticao; 11 alternative: o mesmo que sufficient, porm, se o mecanismo no puder decidir se aceita ou nega o registro (se a resposta for next), ele passa a requisio para o prximo mecanismo. Vejamos alguns exemplos do uso de mecanismos e regras de autenticao: 11 Exemplo 1:
[Gatekeeper::Auth] AliasAuth=optional;RRQ SimplePasswordAuth=sufficient;RRQ default=allow

Neste exemplo, primeiro feita uma tentativa de autenticao por alias, que opcional. Portanto, se a resposta autenticao for ok ou next, o processo segue para o prximo mecanismo. Mas se a resposta for fail, a requisio de registro negada. O prximo mecanismo especificado o SimplePasswordAuth, onde feita a autenticao por usurio e senha. Este mecanismo sufficient e, portanto, decisivo: sua resposta ser a resposta final requisio. Vale observar que os detalhes de cada um desses mecanismos so configurados em sees especficas para cada mecanismo, por isso no so apresentados no exemplo. Alm dos mecanismos, o exemplo mostra a linha default=allow, que define como devem ser tratadas as requisies para as quais no foi especificado nenhum mecanismo. Por padro estamos aceitando (allow) todas as requisies diferentes de RRQ, que so tratadas pelos mecanismos especificados. 11 Exemplo 2:
[Gatekeeper::Auth] SimplePasswordAuth=alternative;RRQ RadAuth=sufficient;RRQ
Autenticao por alias (ID H.323 ou ramal): 11 AliasAuth utiliza a seo [RasSrv::RRQAuth], que possui a sintaxe: <identificador>=sigip:<endereo IP>:<porta> Exemplo:
[RasSrv::RRQAuth] 55551234=sigip:200.188.10.1:1720
55556789=sigip:156.130.25.9:1720
Autenticao por usurio e senha: 11 Os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth validam o registro dos terminais analisando usurio e senha de acesso.
default=allow
79
11 O uso de senha requer que o terminal tenha suporte especificao H.235. Autenticao por usurio e senha: 11 Assim como na validao por alias, cada mecanismo tem sua seo no arquivo de configuraes: 22 SimplePasswordAuth: utiliza a seo [SimplePasswordAuth] onde esto os dados de validao. SQLPaswordAuth: utiliza a seo [SQLPasswordAuth] para configurar um banco de dados SQL onde esto contidas as informaes de usurio e senha. RadAuth: utiliza a seo [RadAuth] e busca os dados de um servidor RADIUS. Neste segundo exemplo, a primeira autenticao feita por usurio e senha. Como est configurada como alternative, se o resultado for ok ou fail, esta ser a resposta final para a requisio. Mas, caso o resultado seja next, ser utilizado o segundo mecanismo, RadAuth, que dar a resposta final. A seguir sero discutidos dois mecanismos de autenticao: a autenticao por alias (especialmente o AliasAuth) e a autenticao por usurio e senha (especialmente o SimplePasswordAuth). Na autenticao por alias, ou seja, por apelido (identificador H.323) ou ramal, podem ser utilizados os mecanismos AliasAuth, SQLAliasAuth e RadAliasAuth. Eles validam as requisies analisando a associao de alias e endereo IP. Todos eles funcionam de maneira semelhante, mas so configurados em sees diferentes do arquivo de configuraes e armazenam os dados de autenticao em locais diferentes: 11 AliasAuth: utiliza a seo [RasSrv::RRQAuth], que onde esto armazenados os dados de autenticao;
11 SQLAliasAuth: utiliza a seo [SQLAliasAuth] e busca os dados para autenticao em um banco de dados SQL; 11 RadAliasAuth: utiliza a seo [RadAliasAuth] e busca os dados de um servidor RADIUS. Como citado, o mecanismo AliasAuth utiliza a seo [RasSrv::RRQAuth]. Esta seo possui comandos com a seguinte sintaxe:
<identificador>=sigip:<endereo IP>:<porta>
Onde: 11 <identificador>: alias que ser mapeado para o IP especificado. 11 <sigip>: uma das duas opes disponveis. A outra opo sigaddr, que informa que o IP e porta esto especificados no formato de uma expresso regular; sigip uma especializao do sigaddr, para utilizao do IP e porta no formato padro A.B.C.D:porta.
11 <endereo IP>: endereo IP para o qual o alias ser mapeado. 11 <porta>: porta para comunicao com o terminal de IP <endereo IP>. Exemplo:
[RasSrv::RRQAuth] 55551234=sigip:200.188.10.1:1720 55556789=sigip:156.130.25.9:1720
80
No exemplo, o terminal com ramal 55551234 mapeado para o IP 200.188.10.1.1 (porta 1720), enquanto o terminal com ramal 55556789 corresponde ao IP 156.130.25.9 (porta 1720 tambm). SimplePasswordAuth: 11 Utiliza a seo [SimplePasswordAuth] que possui a sintaxe:
<usurio>=<senha>
11 Senhas de acesso so criadas pelo utilitrio addpasswd. Na autenticao por usurio e senha, possvel utilizar os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth. Assim como na validao por alias, cada mecanismo tem sua seo no arquivo de configuraes: 11 SimplePasswordAuth: utiliza a seo [SimplePasswordAuth], que j contm os dados de validao; 11 SQLPaswordAuth: utiliza a seo [SQLPasswordAuth] para configurar um banco de dados SQL onde esto contidas as informaes de usurio e senha; 11 RadAuth: utiliza a seo [RadAuth] e busca os dados de um servidor RADIUS. Como citado, o mecanismo SimplePasswordAuth utiliza a seo [SimplePasswordAuth]. Esta seo possui os nomes de usurios e suas respectivas senhas, como no exemplo a seguir:
[SimplePasswordAuth] fulano=J4rfje7jdk= sicrano=ee533dgf4g= beltrano=YY64GGrfje7jdk=

A sintaxe de cada linha <usurio>=<senha>, sendo que estas senhas esto criptografadas, criadas pelo utilitrio addpasswd. O uso desta ferramenta j foi explicado e segue um exemplo: Sintaxe:
addpasswd <arquivo_config> <seo> <usurio> <senha>

Exemplo:
addpasswd /etc/gnugk.ini SimplePasswordAuth fulano senha

Todas as opes de autenticao disponveis, assim como detalhes das configuraes do servidor RADIUS e do banco de dados SQL, podem ser obtidos no manual do GnuGK.
Contabilizao
Gerao de registros das chamadas, imprescindvel para avaliar a utilizao do sistema. O GnuGK gera um registro com informaes detalhadas sobre cada uma das chamadas efetuadas atravs dele: tempo de chamada, origem, destino etc. Esse registro denominado Call Detail Record (CDR). Mecanismos de armazenar o CDR: 11 File Acct 11 Rad Acct 11 SQL Acct A configurao feita atravs da seo [Gatekeeper::Acct] .
81
A contabilizao no gatekeeper, ou seja, a gerao de registros das chamadas, imprescindvel para avaliar a utilizao do sistema. O GnuGK gera um registro, denominado Call Detail Record (CDR), que armazena informaes detalhadas sobre cada uma das chamadas efetuadas atravs do gatekeeper: tempo de chamada, origem, destino etc. Existem diversas maneiras de coletar e armazenar esses registros, como bancos de dados, arquivos texto, servidores externos, entre outros. A configurao da contabilizao no GnuGK feita atravs da seo [Gatekeeper::Acct]. As configuraes dessa seo seguem a seguinte sintaxe:
<mecanimo>=<regra>;evento1,evento2,...,eventoN
Os mecanismos e regras da seo de contabilizao funcionam nos mesmos moldes do processo de autenticao. Nessa seo podem ser definidos vrios mecanismos e tambm os eventos que sero contabilizados por cada mecanismo. Entre os mecanismos disponveis, os mais importantes so: 11 FileAcct: armazena os CDRs em arquivo texto; 11 RadAcct: envia os CDRs para um servidor RADIUS, que pode fazer o armazenamento dos dados como desejar; 11 SQLAcct: grava os registros diretamente em banco de dados SQL. Assim como na seo de autenticao, os mecanismos podem dar uma das trs respostas: ok, fail ou next. As regras tambm so as mesmas, mas funcionam de maneira um pouco diferente: 11 required: se o mecanismo falhou ao registrar o evento, define o resultado final do processo de contabilizao como fail. Aps este mecanismo o evento passado para o prximo mecanismo configurado; 11 optional: independente de sucesso ou falha, o prximo mecanismo configurado sempre ser considerado. Seu resultado no altera o resultado final do processo de contabilizao; 11 sufficient: similar ao required, mas em caso de sucesso o processo de contabilizao finalizado; 11 alternative: similar ao sufficient, pois para a execuo em caso de sucesso. Mas, em caso de falha, no define o resultado final (ao contrrio do que feito em sufficient e em required ). Como comentado, cada mecanismo pode registrar um ou mais eventos. Os eventos passveis de registro so: 11 start: registro gerado no incio de uma chamada (mensagem Setup); 11 stop: registro gerado no fim de uma chamada; 11 connect: uma chamada foi conectada; 11 update: a chamada est ativa e feita uma atualizao peridica para refletir a nova durao da chamada;
11 on: registro gerado no momento em que o gatekeeper ligado; 11 off : registro gerado no momento em que o gatekeeper desligado. Seguem exemplos de configuraes de contabilizao: Exemplo 1:
[Gatekeeper::Acct] RadAcct=optional;start,stop FileAcct=required;start,stop,on,off
82
Neste exemplo, primeiro feita uma tentativa de registro dos eventos start e stop utilizando um servidor RADIUS. Seja qual for o resultado deste mecanismo, o mecanismo FileAcct ser executado, onde sero armazenados os eventos start, stop, on e off. O resultado deste segundo mecanismo ser o resultado final do processo de contabilizao. Exemplo 2:
[Gatekeeper::Acct] RadAcct=alternative;start,stop SQLAcct=sufficient;stop

Neste segundo exemplo, feita uma tentativa de registro em um servidor RADIUS e, em caso de falha, feito o registro em um banco de dados. Novamente, para mais detalhes sobre a contabilizao no GnuGK aconselhvel consultar o seu manual.
Modos de operao
O gatekeeper pode operar de trs formas diferentes: 11 Modo direto: sinalizao e mdia so trocadas diretamente pelos terminais. 11 Modo roteamento: sinalizao trocada atravs do gatekeeper. 11 Modo proxy : sinalizao e mdia so trocadas atravs do gatekeeper.
O modo de operao do gatekeeper o controle sobre as informaes de uma chamada que sero encaminhadas atravs do gatekeeper e quais sero encaminhadas diretamente entre os terminais. O gatekeeper sempre responsvel pelas mensagens de registro de terminais (RAS), entretanto, em termos de sinalizao e mdia, pode operar de 3 formas diferentes.
Modo direto
11 Padro de funcionamento do GnuGK. 11 (+) Gatekeeper no se torna um ponto de falha e/ou gargalo na rede. 11 (-) No pode haver contabilizao das chamadas porque o gatekeeper no participa da inicializao e trmino das chamadas. Tanto sinalizao quanto mdia so trocadas diretamente pelos terminais, sem passar pelo
gatekeeper. A figura seguinte mostra este modo de operao, onde se pode ver que as nicas mensagens trocadas com o gatekeeper so as mensagens RAS, para registro dos terminais. J as mensagens H.225 de sinalizao e H.245 so trocadas diretamente pelos terminais.
Gatekeeper
H.225/H245 Call Signaling
Figura 3.8 Gatekeeper operando em modo direto.
RTP Channels
Terminal 1
Terminal 2
83
RA
.2 25
25
S RA
.2
O modo direto o padro de funcionamento do GnuGK e tem como principal vantagem o fato de que o gatekeeper no se torna um ponto de falha e/ou gargalo na rede caso existam muitas chamadas. Porm, no pode haver contabilizao das chamadas porque o gatekeeper no participa da inicializao e trmino das chamadas.
Modo roteamento
11 O gatekeeper participa de toda troca de sinalizao. 11 Mdia trocada diretamente entre os terminais. 11 (+) Possibilita o controle e a contabilizao de chamadas.
Sinalizao trocada atravs do gatekeeper, enquanto a mdia trocada diretamente entre os terminais. Como se pode ver na prxima figura, agora as mensagens H.225 de sinalizao e H.245 passam pelo gatekeeper; no GnuGK possvel indicar que s as mensagens H.225 de sinalizao passem pelo gatekeeper, enquanto o H.245 trocado diretamente pelos terminais, como ser visto na sequncia.
Gatekeeper
.2
25
RA
RTP Channels
Terminal 1
Terminal 2
Figura 3.9 Gatekeeper operando em modo roteamento.
Este modo de operao tem a vantagem de possibilitar o controle e a contabilizao de chamadas, e, como no modo direto, dificilmente o gatekeeper se tornar um gargalo na rede, pois ele s recebe mensagens de sinalizao, enquanto a mdia (os dados que realmente ocupam banda) trocada diretamente pelos terminais.
Modo proxy
Tanto sinalizao quanto mdia so trocadas atravs do gatekeeper. 11 (+) Auxilia quando existem terminais com endereos NAT.
11 (+) Auxilia quando existem firewalls na rede. No necessrio liberar o acesso a todos os terminais, mas apenas ao gatekeeper. 11 (+) Configurao de QoS; a poltica de QoS pode ser aplicada apenas ao endereo IP do gatekeeper. 11 (-) Pode tornar-se um ponto de falha e gargalo na rede. Tanto sinalizao quanto mdia so trocadas atravs do gatekeeper. Neste modo de operao, nenhum dado trocado diretamente entre os terminais, tudo passa pelo gatekeeper.
84
Gatekeeper
Ch an ne l
P RT
l ne an Ch
RA
.2 25
RT P
25
RA
.2
Figura 3.10 Gatekeeper operando em modo proxy.
Terminal 1
Terminal 2
Este modo possui algumas vantagens: 11 Auxilia quando existem terminais com endereos NAT invisveis ao mundo; 11 Auxilia quando existem firewalls na rede. Em um terminal, no necessrio liberar o acesso a todos os terminais, mas apenas ao gatekeeper, j que todas as mensagens e mdias sero recebidas do gatekeeper; 11 Configurao de QoS. A poltica de QoS pode ser aplicada apenas ao endereo IP do gatekeeper. J a grande desvantagem do modo proxy que o gatekeeper pode tornar-se um ponto de falha e gargalo na rede, j que todo o trfego de todas as chamadas passar por ele.
Configurando o GnuGK
O roteamento configurado na seo [RoutedMode]:
[RoutedMode] GKRouted=0|1 H245Routed=0|1 AcceptNeighborCalls=0|1

Configurando o GnuGK: 11 Quando GKRouted=0 e H245Routed=0, est em modo direto. 11 Quando GKRouted=1, habilita modo roteamento:
22 Se H245Routed=0, faz roteamento apenas de mensagens H.225. 22 Se H245Routed=1, faz roteamento tambm de mensagens H.245. AcceptNeighborCalls deve estar em 1 para que o gatekeeper reconhea outras zonas H.323 (outros gatekeepers). Para habilitar o modo proxy, deve-se configurar a seo [Proxy]:
[Proxy] Enable=1
Na seo de roteamento deve estar configurado GKRouted=1.
85
O modo de operao configurado no GnuGK em duas sees. O roteamento, que define se o gatekeeper far roteamento das mensagens H.225 e H.245 configurado na seo RoutedMode. Abaixo so exibidos os principais parmetros desta seo:
[RoutedMode] GKRouted=1 H245Routed=1 CallSignalPort=0 H245PortRange=30000-30999 AcceptNeighborCalls=1 AcceptUnregisteredCalls=0

O parmetro GKRouted indica se o gatekeeper far o roteamento de algum tipo de mensagem ou no, enquanto H245Routed indica se ele far roteamento das mensagens H.245. Assim, temos as seguintes opes de configurao: 11 Quando GKRouted=0 e H245Routed=0, est em modo direto (Direct Endpoint Call Signalling); 11 Quando GKRouted=1, habilita modo roteamento: 22 Se H245Routed=0, faz roteamento apenas das mensagens H.225 de sinalizao; 22 Se H245Routed=1, faz roteamento tambm de mensagens H.245. Esta seo possui diversos outros parmetros: CallSignalPort Porta de sinalizao do gatekeeper (padro 1721). No utilizada a porta 1720 para ser possvel executar um terminal H.323 de testes no mesmo computador do gatekeeper. Pode ser configurado com a opo 0 para deixar o gatekeeper escolher arbitrariamente uma porta. H245PortRange Portas para serem usadas para os canais de controle H.245. O padro 0, que deixa o sistema operacional selecionar as portas. AcceptNeighborCalls Permite ou no receber ligaes de gatekeepers vizinhos. O padro 1: permitir. AcceptUnregisteredCalls Permite ou no chamadas de terminais no registrados no gatekeeper. O padro 0: no permitir.
Na seo RoutedMode so configurados os modos de operao direto e roteamento. Para configurar o modo proxy, primeiro deve-se habilitar o roteamento (GKRouted=1) e ento configurar a seo [Proxy]. Com o modo proxy habilitado, no necessrio habilitar o roteamento H.245 (H245Routed), pois o gatekeeper far isso automaticamente quando necessrio.
[Proxy] Enable=1 ProxyAlways=0 InternalNetwork=192.168.1.0/24
86
ProxyForNAT=1 T120PortRange=4000-5000 RTPPortRange=1024-65535

A seo [Proxy] tambm possui diversos parmetros, entre eles: Enable Habilita ou desabilita o modo proxy. O padro 0, desabilitado. ProxyAlways Se setado, habilita o proxy sempre, independente das outras configuraes feitas nesta seo. InternalNetwork Especifica as redes internas ligadas ao gatekeeper. Por padro no especificado, o que faz o gatekeeper detectar as redes automaticamente. Pacotes transmitidos para estas redes internas usam a interface local do gatekeeper como transmissor (e no o IP padro ou IP externo definidos em outras sees do gatekeeper). interessante que o proxy pode ser desabilitado para redes internas mesmo que esteja habilitado para redes externas. ProxyForNAT Se habilitado (1), o gatekeeper funciona como proxy em chamadas onde um dos participantes est atrs de uma NAT. T120PortRange Portas para os canais de dados T.120. Por padro no especificado, o que deixa o sistema operacional alocar as portas. RTPPortRange Portas para os canais UDP para os canais RTP/RTCP. Por padro especifica as portas 1024-65535.
87
88
Atividade 1 Configurando o cliente e efetuando chamadas
Esta atividade dever ser realizada em dupla. Nesta atividade cada aluno dever configurar seu cliente para conectar ao GnuGK.
1. Configure os terminais de videoconferncia da dupla para utilizar o gatekeeper de um
dos membros da dupla (criado durante a seo terica);

2. Verifique, via telnet (putty), se os clientes esto conectados (usando a porta de status); 3. Efetue ligaes entre os terminais da dupla. Utilize o IP do seu colega para discar. 4. O gatekeeper aceita a chamada quando somente um dos terminais est utilizando-o?
Verifique.
Como o GnuGK e o cliente de videoconferncia esto na mesma mquina, a opo CallSignalPort=1720 NO deve estar configurada no GnuGK. Ao modificar o gatekeeper no software de videoconferncia, ele deve ser reinicializado para a configurao fazer efeito. Outra opo mudar o IP do gatekeeper para um IP errado, clicar em apply, mudar o IP para o correto e clicar em apply novamente.
Atividade 2 Configurando GnuGK para conexo de clientes autorizados

Configure o GnuGK para que ele s permita conexes de clientes autorizados. Esta autorizao ser feita por IP e ramal.
1. Incluir a seo [Gatekeeper::Auth] e o parmetro AliasAuth dentro dela. Verifique os
exemplos dados durante a aula;

2. Incluir a seo [RasSrv::RRQAuth], onde sero autenticados os terminais; 3. Um terminal da dupla ter o ramal 1000 e o outro ter o ramal 2000: 3.1.Exemplo de autorizao de um ramal: 1000=sigip:143.54.110.28:1720 4. Configurar o ramal de cada um dos terminais da dupla. Este ramal normalmente confi Captulo 3 - Roteiro de Atividades
gurado no mesmo painel de configuraes onde configurado o IP do gatekeeper;

5. Registrar os terminais da dupla ao gatekeeper e tentar fazer ligaes de um para o outro
utilizando os ramais (no mais os IPs como nas atividades anteriores).
89
Atividade 3 Habilitando modo proxy

Nesta atividade habilitaremos o modo proxy, que inclui o roteamento de mensagens H.225, H.245 e mdia atravs do GnuGK. As duplas devem interagir a fim de que cada dupla utilize o gatekeeper da outra, pois assim ser possvel visualizar corretamente a troca de mensagens no Wireshark, pois se um mesmo IP for cliente (terminal) e tambm gatekeeper, ficar mais difcil saber para onde so transmitidas as mensagens.
1. Incluir seo [RoutedMode]. Nesta seo, configurar parmetros GKRouted=1 e H245Routed=1. 2. Incluir seo [Proxy]. Nesta seo, configurar Enable=1. 3. Inicialize o Wireshark em ambas as mquinas para verificar se os pacotes H.245 e dados
de mdia esto sendo enviados e recebidos atravs do gatekeeper. Utilize o filtro h245 or rtp or rtcp no Wireshark.
4. Verifique a captura de pacotes entre os terminais e o gatekeeper. Por onde os pacotes
esto sendo transmitidos? H algum pacote transmitido diretamente entre os clientes?
5. Justifique como o modo proxy poderia ser til em um ambiente real de videoconferncia.
Atividade 4 Configurando o DGK na rede

Nesta atividade iremos configurar o gatekeeper para que as chamadas sejam efetuadas atravs do DGK, o gatekeeper central que far a comunicao entre os diversos gatekeepers da sala (os gatekeepers de cada dupla). Para isso cada dupla receber uma numerao com 2 dgitos (ex: 11, 22, 33, ...) que corresponder ao cdigo de rea da dupla. preciso desligar todos os gatekeepers que no sero utilizados e desabilitar a opo proxy que foi habilitada na atividade anterior. A atividade funcionar da seguinte maneira:
1. Ligaes feitas utilizando somente o ramal (1000 ou 2000) continuaro funcionando como
nas atividades anteriores: so ligaes locais que s utilizam o gatekeeper da dupla;

2. O zero como prefixo ser utilizado para indicar que a ligao ser feita para outra dupla
(outra rea, assim como ligaes telefnicas para outro DDD);

3. Todas as ligaes feitas utilizando o nmero zero como primeiro dgito sero encami-
nhadas para o DGK. O DGK, por sua vez, encaminhar a ligao para a dupla adequada;
4. Os gatekeepers das duplas conhecem apenas o DGK, que por sua vez conhece todos os
gatekeepers das duplas. A figura abaixo ilustra a arquitetura de gatekeepers que ser utilizada e como sero feitas as ligaes:
90
Chamada 2:
0222000
Gk dupla
11
DGK Chamada 1: 2000 ou 0112000 Gk dupla
Figura 3.11 Arquitetura de gatekeepers e estrutura das ligaes.
22
Mquina 1
1000
Mquina 2
2000
Mquina 1
1000
Mquina 2
2000
Utilize o Wireshark para depurar possveis problemas durante a atividade. Atividades:

1. Configurar seo [RasSrv::RewriteE164] para reescrita de ramais como no exemplo:
0111000 para 1000, 0112000 para 2000. Este exemplo vlido para a dupla 11. Ele indica que quando o gatekeeper receber uma ligao com o nmero 0111000, essa ligao ser direcionada para o ramal 1000 (o mesmo vlido para o ramal 2000).
2. Configurar seo [RasSrv::Neighbors] para incluir o DGK como um dos vizinhos do
gatekeeper. O professor informar o endereo IP do DGK.

3. Cada dupla dever informar o endereo IP do seu GnuGK para o instrutor configurar o DGK. 4. Efetuar chamadas entre os clientes da mesma dupla. Ex: Cliente 1000 da dupla 11 liga
para cliente 2000 tambm da dupla 11, discando: 2000 ou 0112000.

5. Efetuar chamadas para clientes de outra dupla: Ex: Cliente 1000 da dupla 11 liga para
cliente 1000 da dupla 22 discando: 0221000. Durante as atividades ocorreu alguma falha? Se sim, o Wireshark ajudou a identific-la?
91
92
4
Introduo ao SIP
objetivos
Proporcionar uma viso ampla do protocolo Session Initiation Protocol (SIP), bem como dos mtodos de configurao de um servidor SIP.
conceitos
Introduo ao SIP (arquitetura, requisies e respostas, exemplos), comparao entre SIP e H.323, servidor OpenSIPS (configuraes bsicas, plano de discagem e autenticao de clientes).
Session Initiation Protocol (SIP)

Protocolo de sinalizao para inicializao, modificao e fechamento de sesses interativas como: 11 Chamadas de voz (VoIP). 11 Videoconferncia. 11 Mensagens instantneas. 11 Jogos multi-usurio via internet. Protocolo para incio de sesso, utilizado em conjunto com outros protocolos: 11 SDP para descrio da sesso. 11 SAP anncio de sesso. 11 RTP/RTCP transmisso de dados e controle da transmisso. 11 RTSP controle de fluxo em tempo real. 11 SCCP controle de conferncia.
Captulo 4 - Introduo ao SIP
93
SIP Aplicao RTSP RTP SDP RTP
Transporte
TCP
UDP
Rede
IP
Camada de enlace
Ethernet
Figura 4.1 Protocolo de aplicao SIP.
SIP um protocolo que est na camada de aplicao. Alternativo ao H.323 que surgiu em meados da dcada de 1990, quando a primeira verso do H.323 j estava se tornando um padro. Inicialmente o SIP foi desenvolvido na Universidade de Columbia e, depois, submetido em 2002 como padro da Internet Engineering Task Force (IETF) RFC 3261. SIP um padro de sinalizao emergente para o estabelecimento de chamadas e conferncias em tempo real em redes IP. Ele j o padro mais utilizado atualmente para chamadas de voz sobre IP. J para chamadas de vdeo, o H.323 ainda domina, mas o SIP vem cada vez ganhando mais espao neste nicho. Uma sesso SIP pode incluir diferentes tipos de dados, como udio, vdeo, mensagens de texto, entre outros formatos. Podemos dizer que o protocolo SIP foi projetado com o intuito de estabelecer, modificar e manipular chamadas envolvendo um ou mais usurios numa rede IP de modo totalmente independente do contedo de mdia da chamada. O SIP um protocolo de aplicao que pode rodar sobre diversos protocolos e tipos de redes, como UDP, TCP, redes ATM e Frame Relay, entre outros. Ele segue a linha dos protocolos baseados em texto na internet, como o SMTP (Simple Mail Transfer Protocol) utilizado para correio eletrnico, e o HTTP para pginas web, utilizando mensagens de texto semelhantes s mensagens dos protocolos citados. importante observar que apesar do SIP poder ser executado sobre UDP, todas as suas mensagens exigem respostas. Portanto, a garantia de entrega deve, neste caso, ser controlada pelo nvel de aplicao. As mensagens existentes no SIP so utilizadas para inicializao, finalizao e configurao de chamadas. Ou seja, ele um protocolo para incio de sesso, e por isso utilizado em conjunto com outros protocolos, como SDP (Session Description Protocol ), SAP (Session Announcement Protocol ), RTP (Real-Time Transport Protocol ) e RTCP (RTP Control Protocol ) e
RTSP (Real-Time Streaming Protocol ).
Arquitetura do SIP
Arquitetura cliente/servidor em que agentes de usurio (os terminais) so formados por duas entidades: 11 User Agent Client (UAC): a parte cliente do agente, responsvel por iniciar as requisies SIP. 11 User Agent Server (UAS): a parte servidor do agente, responsvel por receber e responder as requisies SIP.
94
Um mesmo terminal pode ser UAC e UAS, dependendo da funo que est exercendo. Alm dos agentes de usurio, o SIP possui trs tipos de servidores: 11 Servidor de redirecionamento: redireciona pedidos SIP (retornando com a nova localizao). 11 Servidor de registro: aceita registros de entidades SIP. 11 Servidor de proxy: executa o roteamento de pedidos e respostas SIP. Peer to Peer tambm possvel!
A arquitetura SIP tem por base uma estrutura fundamentada na arquitetura cliente-servidor. Os terminais SIP so chamados de agentes de usurio. O agente de usurio dito inteligente, pois armazena e gerencia o estado da chamada. Tambm pode utilizar endereos de correio eletrnico ou nmero telefnico (E.164) na execuo das chamadas. Os agentes de usurio ainda podem aceitar e receber chamadas de outros agentes sem a necessidade de adicionar outros componentes SIP.
Figura 4.2 Comunicao peer to peer entre componentes SIP.
Os agentes de usurio so formados por duas entidades: 11 UAC User Agent Client a entidade que realiza o papel de cliente no agente de usurio. Responsvel pela inicializao dos pedidos de sesso (incio das chamadas) e envio de requisies. 11 UAS User Agent Server a entidade que realiza o papel de servidor no agente de usurio. responsvel pelo recebimento das requisies enviadas pelos UACs e pelas respostas enviadas a estas requisies. Alm dos agentes de usurios, o SIP especifica trs tipos de servidores: 11 SIP Proxy Server (servidores proxy): tipo de servidor intermedirio SIP, responsvel pelas tarefas de receber as requisies e envi-las aos outros servidores. Seu objetivo basicamente rotear as chamadas, ou seja, garantir que elas chegaro ao destino (ou at uma entidade mais prxima do destino). Ele age tanto como um cliente quanto como um servidor, roteando requisies e respostas. Eles tambm podem ser utilizados para implementar polticas nas chamadas (verificar permisses dos usurios, por exemplo) e podem atuar como conversores de mdias. 11 SIP Registrar (servidores de registro): servidor que recebe e processa mensagens de registro (REGISTER). Prov um mecanismo de localizao de usurios, associando IPs a endereos dos usurios (URIs identificadas no padro sip:usuario@dominio.com), com funcionamento anlogo ao de um servidor DNS. Vale observar que mais de um IP pode estar associado ao mesmo endereo, ou seja, um mesmo usurio pode estar registrado em diversas mquinas (IPs). 11 SIP Redirect Server (servidores de redirecionamento): o papel dos servidores de redirecionamento SIP, como o prprio nome j diz, redirecionar os pedidos ao servidor de registro. O servidor de redirecionamento SIP responde ao UAC, provendo as informaes de endereamento dos servidores e, ento, o cliente encaminha as requisies ao endereo fornecido.
95
A imagem seguinte ilustra a integrao entre todos os componentes da arquitetura SIP:
2 3 1 12 SIP Proxy
SIP Redirect Server
5 6
Location Service
4 11 SIP Proxy 10 7
x1 x2
x1 x2
8 9
<DIAL>
<RING>
SIP Proxy
Figura 4.3 Exemplo da organizao dos elementos SIP.
SIP registrar
Request Response
Na imagem, as mensagens com o prefixo x so independentes das outras e a troca delas feita antes das demais, durante o registro dos terminais no servidor registrar. As mensagens so iguais para os dois terminais: 11 O terminal envia uma mensagem de REGISTER para o servidor solicitando seu registro. Esta mensagem contm a identificao deste terminal; 11 O servidor registrar responde informando que o registro foi completado com sucesso ou insucesso (fornecendo, neste caso, o erro ocorrido). Segue abaixo a descrio das demais etapas da imagem:
1. Um determinado terminal (User Agent ) disca para outro terminal. o UAC deste terminal
que faz a requisio;

2. A requisio recebida por um SIP Proxy que consulta um servidor de redirecionamento
SIP para saber para onde esta requisio deve ser encaminhada;
3. O servidor de redirecionamento responde ao proxy; 4. O proxy ento contata outro proxy, cujo endereo foi informado pelo servidor de
redirecionamento;
5. O segundo proxy contata um servio de localizao para tentar encontrar o terminal destino;
6. O servio de localizao informa ao segundo proxy a localizao do terminal de destino; 7. O segundo proxy contata um terceiro proxy, que est mais prximo do destino; 8. O ltimo proxy da sequncia conhece o terminal destino e encaminha a ele a requisio; 9. O UAS do terminal destino responde requisio; 10. De 10 a 12, a resposta volta para o terminal de origem atravs dos proxies SIP. Note que
no preciso contatar servios de localizao ou de redirecionamento, pois o protocolo SIP guarda informaes para permitir que as respostas sejam encaminhadas pelo mesmo caminho percorrido pelas requisies.
96
Mensagens e respostas SIP

11 INVITE 11 ACK 11 BYE 11 CANCEL 11 OPTIONS 11 REGISTER Exemplos: BYE e CANCEL. 11 Ambas so mensagens enviadas com o intuito de finalizar a sesso. 11 BYE enviado aps a sesso j estar estabelecida. 11 CANCEL enviado para cancelar o estabelecimento da sesso (chamada ainda no atendida quando o telefone est tocando, por exemplo). Exemplo de uma requisio INVITE:
INVITE sip:aline@inf.ufrgs.br SIP/2.0 From: Marcos<sip:marcos@esr.rnp.br>;tag=1c41 To: sip:aline@inf.ufrgs.br Call-Id: a84b4c76e66710 Cseq: 1 INVITE Contact: Marcos<sip:marcos@143.54.12.10> Content-Type: application/sdp Content-Length: 304 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/2.1.11 (WinNT) Date: Thu, 08 Sep 2008 10:28:42 GMT Via: SIP/2.0/UDP sip.ufrgs.br;branch=z9hG4bKnashd
Alm dos campos do exemplo anterior, o INVITE utiliza o protocolo SDP para descrever a
sesso, especialmente em relao s mdias utilizadas. Exemplo:
v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol
97
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb
As requisies e possveis respostas do SIP esto definidas na RFC 3261, de 2002. A RFC define 6 possveis requisies e 6 classes de respostas, que seguem um formato similar ao protocolo http, onde as requisies so identificadas por palavras como REGISTER e INVITE, e as respostas so identificadas por um conjunto de 3 nmeros e classificadas conforme o primeiro nmero. As tabelas a seguir apresentam estas requisies e respostas com seus devidos significados: Requisitos (Cliente para servidor) INVITE Iniciar chamada Respostas (Servidor para cliente) 1xx Informacional (telefone tocando, por ex.) ACK Confirmao 2xx Sucesso (a mais usada 200 OK) BYE Finalizar chamada 3xx Redirecionamento (tpica de servidores redirect ) CANCEL Cancelar requisio pendente Funcionalidades Suportadas REGISTER Registro com o servidor de localizao 6xx 4xx Falha na requisio (usurio no disponvel, codec incompatvel etc) 5xx Falha no servidor (servidor indisponvel, feature no encontrada no servidor etc) Falha global (falha desconhecida, quando no nenhuma das outras)
Figura 4.4 Requisies da RFC 3261 (SIP).
OPTIONS
A seguir uma requisio INVITE para exemplificar o formato das requisies SIP:
INVITE sip:aline@inf.ufrgs.br SIP/2.0 From: Marcos<sip:marcos@esr.rnp.br>;tag=1c41 To: sip:aline@inf.ufrgs.br

Call-Id: a84b4c76e66710 Cseq: 1 INVITE Contact: Marcos<sip:marcos@143.54.12.10> Content-Type: application/sdp Content-Length: 304 Accept-Language: en
98
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/2.1.11 (WinNT) Date: Thu, 08 Sep 2008 10:28:42 GMT Via: SIP/2.0/UDP sip.ufrgs.br;branch=z9hG4bKnashd
No exemplo, o usurio de nome Marcos, identificado por sip:marcos@esr.rnp.br (na mquina de IP 143.54.12.10) est fazendo uma chamada para Aline, identificada por aline@inf.ufrgs.br. Estas informaes podem ser vistas nos campos From, To, Contact e no cabealho da mensagem. Outro campo bastante importante o campo Via, que indica para onde a resposta a esta requisio deve ser enviada, no caso o domnio sip.ufrgs.br. O uso deste campo permite que as respostas voltem facilmente para o originador da requisio. Alm dos campos padro, as requisies INVITE podem utilizar o protocolo SDP para descrever a sesso, com destaque para a descrio das mdias. O protocolo SDP tambm baseado em mensagens de texto e possui uma sintaxe bastante simples com diversas linhas no formato <atributo>=<valor>. Os atributos so formados por apenas uma letra, e os valores variam conforme o atributo que est sendo especificado. Abaixo exibido exemplo da descrio SDP de uma sesso:
v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb
Atributos exibidos no exemplo: 11 v : Verso do protocolo. 11 o: Originador da requisio. 11 s: Nome da sesso. 11 i: Informaes sobre a sesso. 11 u: URI da descrio. 11 e: E-mail. 11 t: Tempo de atividade da sesso. 11 m: Nome da mdia e tipo de transporte; identifica as mdias possveis nesta sesso.
99
Outros exemplos so o BYE e o CANCEL, mensagens enviadas para finalizar a sesso: BYE enviado aps a sesso estar estabelecida, e CANCEL enviado para cancelar o estabelecimento da sesso (por exemplo em uma chamada ainda no atendida quando o telefone est tocando). Quanto s possveis respostas, temos como exemplos as mais utilizadas: 2xx Sucesso 11 200 - OK. 3xx Redirecionamento 11 300 - Mltiplas escolhas. 11 301 - Movido permanentemente. 11 302 - Movido temporariamente. 4xx Falha na requisio 11 400 - Bad request. 11 401 - No autorizado. 11 482 - Loop detectado. 11 486 - Ocupado neste local. 5xx Falha no servidor 11 500 - Erro interno no servidor. 6xx Falha global 11 600 - Ocupado em todos os locais.
Registro SIP
O processo de registro no SIP feito atravs da requisio REGISTER. A requisio bastante simples, sendo enviada de um cliente SIP para um servidor SIP registrar.
Terminal REGISTER sip:esr.br SIP/2.0 From: sip:aluno@esr.br To: sip:aluno@esr.br Contact: sip:143.54.12.10 Expires: 3600 SIP Registrar
Informa que o usurio aluno@esr.br est na mquina 143.54.10.12. Vlido por 1 hora.
2 3
200 ok Banco de dados
Figura 4.5 Requisio REGISTER SIP.
No exemplo, (1) o terminal SIP envia a requisio de registro para o servidor localizado no endereo sip:esr.rnp.br. Entre as informaes da requisio esto: 11 To: contm o endereo de quem est se registrando, no caso aluno@esr.rnp.br. 11 From: contm o endereo de quem est enviando a requisio. Normalmente igual ao campo to, exceto quando a requisio de registro enviada por terceiros. 11 Contact: informa o endereo da mquina na qual o usurio pode ser encontrado. 11 Expires: durao do registro (em segundos). No exemplo, 1 hora.
100
(2) A requisio recebida pelo servidor registrar, que armazenar as informaes do novo usurio registrado, normalmente em um banco de dados. (3) Efetuado o registro no lado do servidor, ele responde para o cliente informando sucesso (cdigo 200).
Diagrama de uma chamada SIP

Terminal A Proxy Terminal B
Inicia a ligao
INVITE: sip:aluno@esr.br 100 trying 180 ringing
1 3
INVITE: sip:aluno@143.54.12.10 180 ringing 200 ok
2 4 5 6
Rings Resposta
200 ok ACK Comunicao de dados RTP BYE 200 ok
7 8 9
Figura 4.6 Troca de mensagens SIP entre dois terminais e um proxy.
Comunicao de dados
Finaliza ligao
O exemplo ilustra as mensagens SIP trocadas entre dois terminais e um proxy, localizado entre estes terminais, durante uma ligao. Os passos so descritos abaixo:
1. O terminal origem A inicia a ligao, discando para o terminal com endereo
sip:aluno@esr.rnp.br atravs de uma requisio INVITE;

2. O proxy interpreta a requisio e a encaminha para a mquina de endereo 143.54.12.10,
que a mquina na qual o usurio aluno@esr.rnp.br foi registrado. Aqui assumimos que o proxy j conhece o endereo do terminal destino B, que poderia ser descoberto com uma consulta a um servidor de localizao.
3. Enquanto a requisio est sendo encaminhada para o terminal B, o proxy avisa ao ter-
minal A que est tentando prosseguir com a comunicao (TRYING);

4. Assim que o terminal B recebe a requisio inicial (INVITE), ele alerta o usurio de que
uma chamada foi recebida, normalmente fazendo o telefone tocar (ring );

5. Assim que o usurio no terminal B atende a ligao, o terminal envia uma resposta com
cdigo 200 (OK), que recebida pelo proxy e encaminhada para o terminal origem;
6. Ao receber a resposta, o terminal A passa a conhecer o endereo direto do terminal B, e
encaminha para ele uma requisio do tipo ACK para confirmar que a ligao foi estabelecida. Neste ponto os terminais j trocaram suas capacidades atravs do protocolo SDP embutido nas mensagens INVITE e 200 (OK) e com isso j estabeleceram os parmetros da transmisso, entre eles os codecs de udio e vdeo e as portas para trocar esses dados;
101
7. Durante a comunicao a troca de dados feita usando o protocolo RTP; 8. Em determinado momento o usurio do terminal A decide finalizar a ligao (colocando
w
O site Tech-invite apresenta uma descrio do SIP baseada em exemplos, mostrando diversas requisies e respostas de forma grfica.
o fone no gancho). Seu terminal envia uma requisio do tipo BYE diretamente para o terminal B avisando que a ligao deve ser finalizada;
9. O terminal B recebe a requisio e envia uma resposta com o cdigo 200 (OK). A ligao
est finalizada.
Comparao SIP e H.323

Funcionalidades similares atravs de mecanismos diferentes: 11 SIP H.225 (RAS + Q.931) 11 SDP H.245 11 Utilizam o mesmo protocolo de transmisso de mdias: RTP/RTCP 11 SIP utiliza texto enquanto H.323 usa binrio (ASN.1) Comparao geral: 11 SIP utilizado largamente em aplicaes de VoIP. 11 H.323 mais utilizado para vdeo. 11 Utilizao de SIP com vdeo (videoconferncias) tem crescido e tende a ser to usual quanto H.323. 11 Normalmente os softwares e equipamentos baseados em H.323 tambm suportam o padro SIP. Exemplos: 11 Novas linhas de terminais dos principais fabricantes: Polycom, Cisco/Tandberg e Radvision. 11 Um grande nmero de softwares utilizam SIP para vdeo. 11 Consulte a lista de exemplos no site Product showcase of SIP Conferencing solutions.
Assim como o H.323, o SIP um protocolo que pode ser utilizado para videoconferncias em redes IP. Ele apresenta funcionalidades similares ao H.323, mas que so alcanadas atravs de mecanismos ou protocolos diferentes. A grande diferena entre os protocolos est em sua base: nos protocolos usados para a troca de mensagens (registro, sinalizao etc.). Enquanto o H.323 utiliza os protocolos H.225 e H.245, o SIP prov mensagens equivalentes s mensagens do H.225 e utiliza o SDP para prover funcionalidades equivalentes s do H.245. Outra diferena importante no formato de codificao das mensagens: enquanto o H.323 utiliza uma codificao binria (ASN.1), o SIP utiliza um modelo mais simples de mensagens textuais, com base em protocolos como o HTTP.
As entidades existentes na topologia de cada um dos protocolos tambm so diferentes, mas possuem certa equivalncia em suas funcionalidades. Os terminais H.323 so simplesmente chamados de terminais, enquanto os terminais SIP so normalmente chamados de agentes de usurios, e so formados por duas partes: UAS (servidor) e UAC (cliente). No que se refere ao registro de usurios, o gatekeeper do H.323 equivalente ao servidor SIP registrar. J para o redirecionamento de mensagens, o SIP utiliza proxies especficos ou servidores de redirecionamento, enquanto no H.323 este controle feito pelo gatekeeper. Alm disso, ambos os protocolos utilizam gateways para comunicao com redes externas.
102
Apesar das diferenas, os protocolos apresentam alguns pontos em comum: ambos utilizam o protocolo de transmisso de mdia RTP e suas mensagens de controle podem trafegar por UDP ou TCP. A tabela abaixo resume os principais aspectos dos protocolos SIP e H.323: SIP Codificao Topologia Textual (HTML) Entidades: UA, servidores de localizao, servidores de registro, servidores proxy etc. Via protocolo SDP Topologia hierarquia (DNS) UDP e TCP Registro HTTP Possui trs mtodos de encriptao H.323 Binrio (ASN.1) Entidades: gatekeeper, gateway, terminais etc. H.245 Anexo G: comunicao entre domnios administrativos UDP e TCP Gatekeeper H.235 H.235
Troca de capacidades Roteamento de chamadas Protocolo de transporte Registro Autenticao

Figura 4.7 Principais aspectos SIP e H.323.
Encriptao
O website Product showcase of SIP Conferencing solutions mostra uma lista de solues de conferncia que utilizam SIP.
aplicao atual de cada um dos protocolos, o uso do SIP j est amplamente w Quanto difundido para uso em aplicaes VoIP, enquanto o H.323 o mais utilizado para videoconferncias. Apesar disso, a utilizao do SIP para videoconferncias tem crescido, e ele tende a tornar-se to ou mais utilizado que o H.323. Um dos motivos para isso a tendncia no mercado para que equipamentos baseados em H.323 passem a suportar tambm o padro SIP. Diversas linhas de terminais dos principais fabricantes j suportam SIP (Polycom, Cisco/ Tandberg e Radvision), assim como um grande nmero de terminais em software.
OpenSIPS
11 Open SIP Server um software livre sob licena GPL. 11 Servidor SIP completo: registrar, location, proxy e redirect. Algumas caractersticas: 11 Segue uma arquitetura modular buscando escalabilidade. 11 Flexibilidade de programao (linguagem de script). 11 Suporte autenticao, autorizao e contabilizao via Radius ou SGBD.
Originalmente, o projeto OpenSIPS era chamado de OpenSER, mas a partir de 2008 este projeto se ramificou em dois, formando os projetos OpenSIPS e Kamailio. Entre as funcionalidades do OpenSIPS, ressalta-se a adaptao a sistemas pequenos com recursos limitados e tambm a sistemas grandes. capaz de suportar milhares de chamadas por segundo, e graas sua arquitetura modular permite a criao de novas funcionalidades (mdulos e API) conforme a necessidade do cliente. Segundo o site do projeto, em sistemas com 4GB de memria ele suporta 300 mil usurios on-line, e pode suportar at 5 mil chamadas por segundo quando em modo stateless.
103
11 Integrao com SGBDs: MySQL, Postgres, entre outros.
Instalao OpenSIPS
As ltimas verses do OpenSIPS podem ser obtidas no site. A instalao varia conforme a plataforma alvo. O OpenSIPS disponibiliza pacotes prontos para algumas plataformas: 11 OpenSUSE. 11 CentOS. 11 Debian (utilizada neste curso). 11 Fedora. Para outras plataformas possvel baixar e compilar o cdigo-fonte. Sendo uma aplicao de cdigo aberto, o OpenSIPS disponibiliza em sua pgina tanto o cdigo-fonte da aplicao quanto alguns pacotes (binrios) para sistemas especficos.
Atualmente, so disponibilizados pacotes para as plataformas OpenSUSE, CentOS, Fedora e Debian, sendo este ltimo utilizado neste curso. A instalao do OpenSIPS possui algumas peculiaridades conforme a plataforma na qual est sendo instalado. No consta no escopo deste curso a abordagem de todas as opes possveis, portanto a instalao ser feita de forma simples, utilizando pacotes j compilados. Este curso se baseia no uso do OpenSIPS em uma mquina virtual com o sistema Linux, o mesmo modelo adotado no captulo sobre GnuGK. Para instalar o OpenSIPS de forma prtica, basta fazer download do pacote para Debian e instal-lo com o gerenciador de pacotes. Aps a instalao do OpenSIPS, os arquivos mais importantes da aplicao estaro instalados em: 11 Arquivo de configuraes iniciais: /etc/default/opensips 11 Arquivo de configuraes gerais: /etc/opensips/opensips.cfg 11 Arquivos binrios: /usr/sbin/ 11 Mdulos: /usr/lib/opensips/modules/ 11 Logs: /var/log/ O arquivo de configuraes iniciais chamado opensips contm algumas configuraes bsicas necessrias para a inicializao do OpenSIPS, como o usurio e o grupo do sistema operacional que sero utilizados e a quantidade de memria que ser alocada para a aplicao. Este arquivo tambm contm uma opo chamada RUN_OPENSIPS que est inicialmente com o valor no, com intuito de no permitir a execuo da aplicao antes que ela seja configurada. Aps a configurao, basta modificar o valor desta opo para yes que a execuo do OpenSIPS liberada. J o arquivo opensips.cfg contm as configuraes do funcionamento do servidor Open Administrao de Videoconferncia
SIPS. Este arquivo segue um formato de linguagem script, que permite que as funcionalidades do servidor sejam programadas. As configuraes do restante deste captulo sero feitas neste arquivo. Os arquivos executveis da aplicao esto localizados no diretrio /usr/sbin/ e os mdulos utilizados esto em /usr/lib/opensips/modules/.
Inicializao OpenSIPS
Existem diversas opes de inicializao do OpenSIPS, que podem ser verificadas atravs do comando:
$ opensips h
104
Comando opensips: 11 [-f arquivo] especifica arquivo de configurao. 11 [-c] verifica se existem erros no arquivo de configurao. 11 [-d] nvel de debug; quanto maior o nmero de ds, maior ser o nvel de debug. 11 [-l protocolo:interface:porta] especifica as interfaces de rede que sero utilizadas (protocolos UDP ou TCP). Exemplo:
$ opensips l udp:192.168.1.100:5080 f /usr/local/etc/opensips/ opensips.cfg -d

O utilitrio opensipsctl um script utilizado para realizar operaes de manuteno no OpenSIPS. Este utilitrio muito til para diversas tarefas: 11 Iniciar/parar a aplicao. 11 Obter listagem de usurios on-line. 11 Informaes estatsticas de uso do sistema. O comando opensips deve ser usado pelo super usurio (root). Usurios normais normalmente no possuem acesso ao comando sem especificar o caminho completo da aplicao. Ou seja, um usurio normal precisaria executar o comando /usr/sbin/opensips. necessrio configurar o arquivo /etc/default/opensips antes de executar o OpenSIPS pela primeira vez. Para auxiliar a realizao de algumas tarefas, existe o utilitrio opensipsctl. Este script pode executar diversas tarefas, entre elas iniciar e parar a aplicao, obter listagem de usurios on-line e informaes estatsticas de uso do sistema. Alguns comandos possveis: 11 opensipsctl stop|start|restart 11 opensipsctl ul show exibe lista de usurios. 11 opensipsctl online exibe usurios on-line. 11 opensipsctl monitor monitora a aplicao atualizando as informaes periodicamente. Para uma lista de todas as opes possveis basta executar o comando opensipsctl sem nenhum parmetro adicional. Alm deste script, outra forma de inicializar o OpenSIPS utilizando o script do sistema operacional para inicializar a aplicao durante o boot:
$ /etc/init.d/opensips <opo>
Opes possveis: start, stop, restart, force-reload, debug e status. Para v-las, basta executar o comando sem fornecer nenhuma opo.
Se o OpenSIPS j estiver em execuo, o comando opensipsctl start vai falhar, o que normalmente acontece porque o sistema j iniciou a aplicao durante o boot. Portanto, primeiro pare a aplicao com /etc/init.d/opensips stop. Com as configuraes padro instaladas com OpenSIPS, ele j pode ser executado de forma funcional. Todos os clientes se registram automaticamente com o nome configurado (no cliente) e sem validao nenhuma. J possvel tambm fazer ligaes de um cliente para o outro informando o nome do usurio do outro cliente.
105
Arquitetura modular OpenSIPS

A estrutura do OpenSIPS pode ser dividida em duas partes: 11 Ncleo: responde pelo funcionamento bsico e controle dos mdulos. 11 Mdulos: cada um adiciona funcionalidades especficas ao software, inclusive as funcionalidades SIP. Principais mdulos: Funo proxy 11 Transaction (TM) 11 Stateless Replier (SL) 11 Record-Route e Route Mode (RR) Funo registrar 11 Registrar Funo location 11 Localizao de usurios (Usrloc) 11 Database API (MySQL, Postgres e DBtext) Funes gerais 11 Contabilizao (ACC) 11 Autenticao (AUTH) 11 Autenticao com banco de dados (AUTH_DB) Os mdulos so carregados atravs do arquivo de configuraes.
OpenSIPS adota uma arquitetura modular, onde o software composto por um ncleo bsico ao qual podem ser conectados diversos mdulos para prover funcionalidades ao software. 11 Ncleo: responde pelo funcionamento bsico e controle dos mdulos. O ncleo responsvel pelas configuraes locais, como nvel de depurao, portas TCP e UDP utilizadas, modo de operao etc; 11 Mdulos: existem diversos mdulos, sendo que cada um adiciona funcionalidades especficas ao software, inclusive as funcionalidades SIP. Os mdulos so carregados atravs do arquivo de configuraes, onde possvel passar parmetros para a sua inicializao. Ao carregar um mdulo, ele prover funes que podem ser utilizadas na programao do arquivo de configuraes. O OpenSIP disponibiliza diversos mdulos. Segue uma lista com uma breve descrio dos mais importantes:
11 Mdulo TM: processamento de transaes SIP stateful (transaes stateful e stateless sero explicadas posteriormente); 11 Mdulo SL (Stateless Replier): implementa a funo de proxy SIP stateless, ou seja, capaz de responder a requisies SIP sem manter o estado da comunicao; 11 Mdulo RR (Record-Route e Route Mode): implementa as funes de controle do modo de roteamento (Route); 11 Mdulo Registrar : implementa a lgica de processamento do mtodo REGISTER para registro de usurios;
106
11 Mdulo USRLOC (User Location): mantm a tabela de localizao de usurios e prov acesso a essa tabela para outros mdulos; 11 Mdulos DB_*: existem diversos mdulos com nome iniciado pelo prefixo DB_, o que indica que so mdulos que permitem a interao do OpenSIPS com alguma base de dados. H entre eles os mdulos DB_MYSQL, DB_POSTGRES e DB_TEXT, que proveem, respectivamente, comunicao com o banco de dados MySQL, com o banco de dados Postgres e com bancos de dados em formato texto; 11 Mdulo AUTH: implementa funes bsicas de autenticao; 11 Mdulo AUTH_DB: implementa funes de acesso a banco de dados para autenticao. Depende dos mdulos AUTH e de banco de dados (MySQL, Postgres etc).
w
A lista completa de mdulos pode ser encontrada no site do OpenSIPS (verso 1.6.0) em OpenSIPS Resources DocsModules16.
Configurao OpenSIPS
A estrutura do arquivo de configurao formada por arquivo texto padro composto por 3 sees: 11 Configuraes globais: configuraes gerais do sistema, como o nvel de depurao, controle sobre o log da aplicao, definio das interfaces de rede que sero utilizadas, entre outras. 11 Configuraes dos mdulos: carregamento dos mdulos e configuraes dos seus parmetros. 11 Lgica de roteamento: script que define o modo de funcionamento do sistema. Toda lgica de roteamento definida atravs de uma estrutura de configurao similar a uma linguagem de programao (declarao e chamada de funes, clusulas condicionais if, else etc). A seguir sero apresentadas essas 3 sees e discutidas algumas das configuraes mais importantes.
Configuraes globais
Existem diversas configuraes possveis nesta seo. As mais utilizadas so: 11 debug : opes: nmero entre 0 e 9. Define o nvel de depurao, ou seja, a quantidade de informaes exibida nos logs; 11 fork : opes: YES ou NO. Se YES, abre um processo para cada interface de rede e cada protocolo (TCP e UDP). Se NO, roda tudo em processo nico; 11 log_stderror: opes: YES ou NO. Indica se os erros devem ser enviados para a sada de erro padro do sistema (stderr) ou para o syslog. utilizada para depurao, pois facilita a verificao dos erros; 11 log_facility : parmetro que indica o facility para o syslog (mecanismo de log do sistema operacional). uma maneira de indicar a aplicao que gerou a mensagem de log;
11 listen: formato: <protocolo>:<IP>:<porta>. Indica o endereo IP/porta utilizado para aguardar as requisies e o protocolo que ser permitido neste IP/porta. Ex: listen=udp:143.54.12.10:5064; 11 alias: identificao do servidor local. A declarao de alias tem relao com a varivel myself, que utilizada no script para identificar se uma mensagem foi enviada para este servidor. Ex: alias=esr.rnp.br:5060.
107
Algumas opes da seo de configuraes globais:
debug=9 fork=yes|no
# Nvel de depurao # Proxy cria um processo para cada interface de rede ou gerencia tudo
num nico processo
log_stderror=Yes|no5 log_facility=LOG_LOCAL35 alias=lab.esr.rnp.br5
# Log de erros na sada stderr ou syslog # Parmetro para syslog # Nome deste servidor SIP
listen=192.168.1.100:5060 # Interface de rede para esperar requisies
A lista completa de parmetros da verso 1.6.0 pode ser encontrada em OpenSIPS Resources DocsCoreFcn16. Para rodar a aplicao em modo depurao, marque a opo fork=no e inicie o OpenSIPS com o comando: /etc/init.d/opensips debug.
Configuraes dos mdulos

Esta seo define todos os mdulos que sero carregados e define os parmetros que sero passados para configur-los. O carregamento dos mdulos feito de forma simples. A varivel mpath indica o diretrio onde esto os mdulos, que so carregados usando o comando loadmodule, como no exemplo abaixo:
mpath=/usr/lib/opensips/modules/ loadmodule sl.so loadmodule tm.so loadmodule registrar.so

A configurao dos parmetros dos mdulos feita com o comando modparam, como nos exemplos abaixo:
modparam(auth_db, db_url, mysql://opensips:opensipsrw@localhost/opensips) modparam(acc, repost_ack, 1) modparam(registrar, max_contacts, 10)

O comando modparam recebe trs argumentos: o nome do mdulo, o nome da varivel e o valor a ser atribudo varivel, respectivamente.
Lgica de roteamento
A lgica de roteamento define todo o tratamento que ser feito com as requisies recebidas pelo OpenSIPS, seja qual for o tipo dessas requisies (INVITE, REGISTER, BYE, CANCEL etc). O funcionamento do OpenSIPS se assemelha ao de um script que executado toda vez que uma requisio SIP recebida. O ponto de partida do script o bloco denominado route{}, que contm toda a lgica de roteamento (ou parte da lgica e chamadas para outros blocos, que contm o restante da lgica). Sempre que uma requisio recebida, tem incio a execuo sequencial dos comandos encontrados neste bloco. O processamento contnuo at o ponto onde ocorre a deciso final sobre a requisio: at a requisio ser encaminhada ou ignorada, por exemplo. O exemplo abaixo exemplifica de forma bastante simplificada o bloco route{}:
108
route { if(is_method(OPTIONS)) { # send reply for each options request sl_send_reply(200, ok); exit(); } route(1); }
route[1] { # forward according to uri forward(); }

No exemplo, o servidor responder a todas as requisies do tipo OPTIONS com uma mensagem 200/OK (definida no bloco if{}). Para as outras requisies, feita uma chamada a um bloco secundrio de roteamento route[1], que apenas encaminhar a requisio.
Modos de operao OpenSIPS

Um proxy SIP pode operar de dois modos: Modo Stateless Oferece melhor escalabilidade, pois no armazena informaes de estado e requer menos recursos, principalmente memria. O mdulo responsvel pelo modo stateless o SL. Toda funo iniciada por sl_ indica que a comunicao ser feita sem manter informaes de estado. Modo Stateful O mdulo responsvel pelo modo stateful o TM. Toda funo iniciada por t_ indica que o processo ser tratado como stateful. A escolha entre o estado stateless ou stateful importante, pois muda a forma com que algumas requisies so tratadas.
O modo stateless oferece melhor escalabilidade, pois no precisa armazenar tantas informaes de estado como no modo stateful, portanto, requer menos recursos (principalmente memria). O mdulo responsvel pelas funes stateless o SL. Ele fornece todas as funes cao ser feita sem manter informaes de estado. O mdulo responsvel pelas funes stateful o TM, que fornece as funes com prefixo t_. A escolha entre os estados stateless ou stateful importante, pois muda a forma com que algumas requisies so tratadas.
iniciadas por sl_, ou seja, o uso de qualquer funo com prefixo sl_ indica que a comuni-
109
A requisio CANCEL, por exemplo: 11 Em stateful, o script pode simplesmente chamar uma funo do mdulo TM (t_relay()) e ela saber como tratar a mensagem, pois o servidor guardou as informaes sobre a requisio inicial, o INVITE. 11 Em stateless, deve aplicar ao CANCEL toda a mesma lgica de roteamento aplicada para o INVITE, pois no manteve as informaes.
Alm disso, h algumas funcionalidades que necessitam do estado das transaes para funcionarem, como o mdulo de contabilizao (mdulo ACC). Associado aos mdulos stateless e stateful, est o mdulo RR (Record-route), que possibilita a gravao da rota pela qual as requisies passaram. Essa rota guardada no cabealho das mensagens atravs de duas funes principais: 11 record_route( ): grava a rota nas requisies. 11 loose_route( ): limpa a rota nas respostas. As imagens abaixo exemplificam as chamadas record_route( ) para gravar a rota de uma requisio INVITE e as chamadas loose_route( ) para liberar as rotas quando feita a requisio BYE (que est relacionada ao INVITE inicial). Como a rota foi gravada durante a requisio INVITE, garantido que a requisio BYE passar pelo servidor SIP que gravou seu endereo nesta rota.
record_route() INVITE INVITE record_route() INVITE
A Rota: A Rota: S1, S2, B
Servidor SIP S1
Rota: S1, A
Servidor SIP S2
B Rota: S2, S1, A Rota: S2, S1, A
Figura 4.8 Rota da requisio INVITE.
loose_route() BYE BYE
loose_route() BYE
A Rota: A Rota: S1, S2, B
Servidor SIP S1
Rota: A, S1
Servidor SIP S2
B Rota: S2, S1, A Rota: S2, S1, A

Figura 4.9 Rota da requisio BYE.
Antes de utilizar o script opensipsdbctl, o arquivo opensipsctlrc deve ser editado para incluir as configuraes de acesso ao banco de dados. Este arquivo est localizado em /etc/opensips/ e as variveis mais importantes que devem ser configuradas so: DBENGINE, DBHOST, DBNAME, DBRWUSER e DBRWPW. Elas j possuem os valores padro configurados, que sero os valores utilizados neste curso. A estrutura completa das tabelas necessrias para o funcionamento do OpenSIPS pode ser consultada no site do desenvolvedor.
110
Integrao com banco de dados OpenSIPS

Indispensvel para implantao de um servidor OpenSIPS. Vrios mdulos fazem uso de algum tipo de informao armazenada em banco de dados: 11 Registro de usurios (funo registrar ). 11 Contabilizao. 11 Localizao de usurios. 11 Entre outros. Mdulo carregado e configurado no arquivo de configuraes. Exemplo:
loadmodule mysql.so modparam(auth_db|usrloc|acc, db_url, mysql://opensips:opensipsrw@localhost/opensips)

A configurao das tabelas no banco de dados pode ser feita com o script opensipsdbctl:
$ opensipsdbctl create opensips

(cria o database opensips)
$ opensipsdbctl reinit opensips

(destri e recria todo o database opensips) Algumas operaes sobre o banco de dados tambm podem ser feitas com o script opensipsctl:
$ opensipsctl add <username> <password>

(cadastrar usurio)
$ opensipsctl rm <username>
(remover usurio)
$ opensipsctl passwd <username> <password>

(modificar a senha de um usurio cadastrado) O uso de um banco de dados indispensvel para implantao de um servidor OpenSIPS, mesmo que seja utilizado um banco mais simples, como em arquivos texto. Se nenhum banco de dados for utilizado, as informaes de localizao dos usurios registrados sero mantidas em memria, portanto em caso de falhas ou reinicializao do servidor, elas acabam sendo perdidas. Diversos mdulos do OpenSIPS utilizam algum tipo de informao armazenada em banco de dados, como por exemplo os mdulos de registro de usurios (servidor registrar ), contabilizao de ligaes e localizao de usurios. O OpenSIPS fornece diversos mdulos para integrao com alguns bancos de dados, entre eles: 11 DB_MYSQL: MySQL 11 DB_POSTGRES: PostgreSQL 11 DB_TEXT: Dbtext Assim como os outros mdulos comentados, os mdulos de banco de dados so carregados e configurados na seo de mdulos do arquivo de configuraes. O exemplo abaixo mostra o carregamento do mdulo para MySQL e da atribuio de dois parmetros aos mdulos:
q
111
loadmodule mysql.so modparam(auth_db|usrloc|acc, db_url, mysql://opensips:opensipsrw@localhost/opensips) modparam(usrloc, db_mode, 1)

No exemplo, a primeira linha carrega o mdulo enquanto as outras duas atribuem os parmetros. O primeiro parmetro atribudo aos mdulos AUTH_DB, USRLOC e ACC, enquanto o segundo parmetro s atribudo ao mdulo USRLOC (pois s existe neste mdulo). A configurao de db_url (que comum aos mdulos AUTH_DB, USRLOC, ACC e outros) diz respeito localizao e a informaes de acesso ao banco de dados. O valor atribudo a esta opo segue, na maioria dos casos, o formato: banco://usurio:senha@ip:porta/database. No exemplo, est sendo indicado que ser utilizado o usurio opensips com senha opensipsrw para se conectar ao database opensips do banco de dados MySQL localizado na mquina localhost. Este formato pode variar em casos como no uso do DB_TEXT, que segue um formato como o do exemplo abaixo:
modparam(auth_db , db_url, dbtext:///var/dbtext/opensips)

A configurao de db_mode uma opo do mdulo USRLOC e apenas diz respeito ao modo de acesso ao banco de dados: 11 0: desabilita o banco de dados. Todas as informaes so mantidas em memria; 11 1: as informaes chegam a ser armazenadas na memria, mas so gravadas imediatamente no banco de dados; 11 2: as informaes so armazenadas primeiramente na memria e sincronizadas de tempos em tempos com o banco de dados; 11 3: nenhuma informao mantida em memria. Todas as operaes so realizadas diretamente com o banco de dados. Esta opo existe, pois muitas vezes o acesso ao banco de dados pode ser demorado, portanto esta configurao permite personalizar a forma de acesso ao banco conforme as necessidades de cada servidor. A configurao das tabelas no banco de dados pode ser feita facilmente com um script fornecido pelo OpenSIPS, chamado opensipsdbctl:
$ opensipsdbctl create opensips

(cria o database opensips)
$ opensipsdbctl reinit opensips

(destri e recria todo o database opensips) Alm disso, algumas operaes sobre o banco de dados tambm podem ser feitas com o script opensipsctl, como o gerenciamento de usurios cadastrados:

(cadastrar usurio)
(remover usurio)
112

(modificar a senha de um usurio cadastrado)
Localizao de usurios OpenSIPS

A partir do momento em que uma requisio de INVITE recebida, o servidor SIP deve ser acionado para encaminhar a requisio ao seu destino, se o destino for de conhecimento do servidor. O mdulo responsvel pela funo que permite localizar usurios o USRLOC, atravs da funo lookup(). Abaixo exibido um pequeno script de roteamento do mtodo INVITE. No algoritmo, em primeiro lugar avaliado se o tipo da requisio realmente um INVITE (method==INVITE). Caso positivo, em seguida feita a busca pelo destino usando a funo lookup(location). A funo lookup() usa como parmetro a tabela onde se encontram as informaes de localizao dos usurios registrados, geralmente chamada location. Se o registro de localizao no for encontrado, uma mensagem apresentada ao cliente que originou a chamada e o processo finalizado. Mas se a informao do destino foi encontrada, a funo t_relay() invocada para que a requisio seja encaminhada para o destino. A partir da o software cliente do destinatrio receber a requisio de convite para estabelecimento de chamada.
if (method==INVITE) { if (!lookup(location)) { # busca usurio na tabela location
sl_send_reply(404, Not Found); return; }; if (!t_relay()) { # s depois tenta encaminhar a requisio sl_reply_error(); }; exit; }
Plano de discagem OpenSIPS

Como implementado um plano de discagem? Para a criao de um plano de discagem completo, equivalente ao visto no GnuGK, ser preciso definir uma estrutura composta 11 OpenSIPS recebe um nmero para o qual um terminal est discando. 11 O formato do nmero verificado. 11 O nmero reescrito em formato padro, para facilitar verificaes: 22 Cdigo do pas + cdigo de rea + nmero do terminal. de if s e else s. Exemplo:
q
# Discagem Nacional if (uri=~sip:0[1-9].*) { # sip:0 21 88889999@esr.rnp.br
113
strip(1); prefix(55);
# sip:21 88889999@esr.rnp.br # sip:55 21 88889999@esr.rnp.br
# Discagem Internacional } else if (uri=~sip:00[1-9].*) { # sip:00 55 21 88889999@esr.rnp.br strip(2); # sip:55 21 88889999@esr.rnp.br
# Discagem local } else if (uri=~sip:[2-9][0-9]{7}@.*) { # sip:88889999@esr.rnp.br prefix(5521); # sip:55 21 88889999@esr.rnp.br
} else { # qualquer endereo SIP invlido sl_send_reply(403, Forbidden); return; };

Para a criao de um plano de discagem completo, equivalente ao visto no GnuGK, preciso definir uma estrutura composta de IFs e ELSEs no script de configurao do OpenSIPS. No exemplo abaixo, o servidor OpenSIPS recebe um nmero para o qual um terminal est discando, verifica o formato deste nmero (se vlido ou no) e o reescreve em um formato padro que permite verificaes posteriores (localizar usurio, por exemplo). O formato para o qual o nmero reescrito : Cdigo do pas + cdigo de rea + nmero do terminal.
# Discagem Nacional if (uri=~sip:0[1-9].*) { # sip:0 21 88889999@esr.rnp.br strip(1); prefix(55); # sip:21 88889999@esr.rnp.br # sip:55 21 88889999@esr.rnp.br
# Discagem Internacional } else if (uri=~sip:00[1-9].*) { # sip:00 55 21 88889999@esr.rnp.br

strip(2);
# sip:55 21 88889999@esr.rnp.br
# Discagem local } else if (uri=~sip:[2-9][0-9]{7}@.*) { # sip:88889999@esr.rnp.br prefix(5521); rnp.br # sip:55 21 88889999@esr.
114
} else { # qualquer endereo SIP invlido sl_send_reply(403, Forbidden); return; };

Os endereos ao lado dos comandos exemplificam endereos SIP tratados por cada um dos blocos if. O primeiro if nos indica que uma chamada de longa distncia. Nesse caso devemos remover o dgito 0 (zero), que faz parte do plano de discagem e inserir os dgitos 55. O segundo if nos aponta para uma chamada internacional. Nesse caso precisamos apenas remover os dgitos do plano de discagem para chamada internacional (00). Em ltimo caso, a chamada ser do tipo local (8 dgitos). Nesse caso precisamos apenas inserir o Cdigo do pas + Cdigo de rea especficos.
Sobre a sintaxe do script

A expresso uri =~ indica que a varivel uri ser comparada com uma expresso regular. Expresses regulares utilizadas: 11 sip:0[1-9].*: endereo iniciado por sip:0 seguido de pelo menos um dgito entre 1 e 9. O bloco .* indica que podem existir 0 ou mais dgitos na sequncia; 11 sip:00[1-9].*: similar ao anterior, mas agora o endereo inicia por sip:00; 11 sip:[2-9][0-9]{7}@.* : endereo iniciado por sip:, seguido por um dgito entre 2 e 9. O bloco [0-9]{7} indica que a sequncia formada por exatamente 7 dgitos entre 0 e 9, formando portanto os 8 dgitos do endereo. Esses 8 dgitos so seguidos por uma arroba (@), que seguida por 0 ou mais dgitos.
Autenticao de clientes OpenSIPS

A autenticao SIP feita por requisies do tipo REGISTER. O servidor OpenSIPS trata estas requisies para liberar ou bloquear o acesso do terminal que fez a requisio. No OpenSIPS, a lgica de processamento do REGISTER envolve basicamente o uso das seguintes funes: 11 www_authorize(dominio, tabela) do mdulo AUTH_DB Valida as credenciais utilizadas para autenticao (usurio e senha enviados com o REGISTER) de acordo com a RFC 2617. Parmetros: <domnio>: domnio do servidor SIP. <tabela>: tabela do banco de dados que contm as informaes das credenciais. 11 ww_challenge(dominio, qop) do mdulo AUTH registro novamente. Parmetros: <domnio>: domnio do servidor SIP. <qop>: parmetro necessrio para o mecanismo de desafio-resposta, com valor 0 ou 1. 11 db_check_to() do mdulo URI Valida o campo To: , que na requisio REGISTER contm o endereo do terminal que est sendo registrado. Funo antes chamada de check_to() no mdulo URI_DB. Caso a autorizao falhe, esta chamada feita para desafiar o terminal a tentar o
115
11 save(tabela) do mdulo registrar Chamada aps o registro ser feito com sucesso, salva a informao de registro na tabela tabela. Script de exemplo da autenticao de usurios:
if (!www_authorize(esr.rnp.br, subscriber)) { autorizado www_challenge(esr.rnp.br, 0); exit; } # usurio foi autorizado if (!db_check_to()) { # campo To: invlido
# usurio no
sl_send_reply(403, Forbidden auth ID); exit; }
if (!save(location)) { registro sl_reply_error(); return; } exit;
# no conseguiu graver informaes de
No script, o primeiro passo uma tentativa de autenticao no domnio esr.rnp.br:
if (!www_authorize(esr.rnp.br, subscriber)) {
Em caso de falha, feito o desafio para o usurio fornecer novas credenciais:
www_challenge(esr.rnp.br, 0);
Caso a resposta para a autenticao seja positiva, feita a validao do campo To: da mensagem, que no REGISTER contm o endereo do terminal que est solicitando o registro:
if (!db_check_to()) {
Se o campo To: for invlido, enviado um aviso ao usurio informando que o ID de autenticao invlido:
sl_send_reply(403, Forbidden auth ID);

Se o campo To: for vlido, o script prossegue para o prximo passo, que a gravao do registro que foi feito:
if (!save(location)) {
Em caso de sucesso, o script finaliza e o registro est concludo. Em caso de falha, enviado um aviso de erro ao usurio:
116
sl_reply_error();
Como j comentado, se houver integrao com algum banco de dados o utilitrio opensipsctl pode ser utilizado para: 11 Cadastrar usurios:

11 Remover usurios:
11 Modificar a senha de um usurio cadastrado:
Contabilizao OpenSIPS
O registro das chamadas permite contabilizar a utilizao do sistema. Contabilizao utiliza o mdulo ACC: 11 Pode registrar eventos no sistema (Syslog), bancos de dados e RADIUS. 11 Utilizao do mdulo praticamente transparente no script: basta informar ao mdulo que os dados devem ser registrados e ele se encarrega do resto.
# seta a flag que ser usada para indicar ao ACC que deve iniciar contabilizao modparam(acc, db_flag, 1)
if (method==INVITE) { setflag(1); # avisa o ACC para contabilizar o INVITE } else if (method==BYE) { setflag(1); # avisa o ACC para contabilizar o BYE }
A gerao de registro das chamadas indispensvel para avaliar a utilizao do sistema. No OpenSIPS, toda a contabilizao feita pelo mdulo ACC. Este mdulo permite o registro de eventos no sistema (syslog), bancos de dados e RADIUS. A utilizao do mdulo praticamente transparente no script: basta informar ao mdulo que os dados devem ser registrados e ele se encarrega do resto. O mdulo permite contabilizar informaes a qualquer momento e tambm permite a personalizao das informaes que
sero gravadas. Mas h sempre um conjunto mnimo de informaes que so contabilizadas: 11 Nome do mtodo (INVITE, ACK, BYE, etc.). 11 Campos To, From e Call-Id do cabealho. 11 Cdigo e mensagem da resposta gerada. 11 Informaes de tempo de quando a transao foi finalizada.
117
Para realizar a contabilizao, o script deve basicamente chamar a funo setflag(ID) no momento adequado. O uso desta funo ser explicado com um script de exemplo abaixo:
loadmodule mysql.so # 1 loadmodule acc.so # 1
modparam(acc, db_url, mysql://opensips:senha@localhost/ opensips)# 2 modparam(acc, db_flag, 1) # 2 if (method==INVITE) { setflag(1); # 3 } else if (method==BYE) { setflag(1); # 4 }
Os identificadores # ao longo do script mostram as quatro etapas:
1. Carregamento do mdulo do banco de dados MySQL e do mdulo de contabilizao ACC. 2. Definidos dois atributos no mdulo ACC: 2.1.O primeiro para que ele utilize o banco de dados MySQL para armazenar as informaes; 2.2.O segundo define que a flag de contabilizao ser a com valor 1. Esta flag utili-
zada posteriormente para habilitar a contabilizao.

3. A chamada da funo setflag(1) 1 a flag definida no ACC habilita a contabilizao da
requisio que est sendo tratada, no caso INVITE;

4. O mesmo que o item anterior, mas agora habilita a contabilizao da requisio BYE.
Para uma contabilizao completa, aconselhvel monitorar pelo menos as requisies INVITE, ACK e BYE. Esses trs mtodos consistem da estrutura de uma transao SIP: Incio = INVITE, Estabelecimento = ACK e Fim = BYE.
Gerao de logs OpenSIPS

O log de eventos fundamental para o acompanhamento do funcionamento do sistema, diagnstico e resoluo de problemas. O mdulo XLOG oferece recursos poderosos para implementar o registro de eventos.
O registro de eventos fundamental para o acompanhamento do funcionamento do sistema, diagnstico e resoluo de problemas. No OpenSIPS, o responsvel pelas funes de log o mdulo XLOG. XLOG oferece recursos poderosos para implementar o registro de eventos, tendo como sua funo principal:
xlog(<Nvel>, <Mensagem Texto>)

11 Registra uma mensagem no sistema de log. 11 <nvel> opcional e indica a classe da mensagem: alerta, erro crtico etc.
118
Os valores so compatveis com o sistema syslog: 11 L_ALERT - log level 3 11 L_CRIT - log level 2 11 L_ERR - log level 1 11 L_WARN - log level 1 11 L_NOTICE - log level 2 11 L_INFO - log level 3 11 L_DBG - log level 4 As mensagens so armazenadas pelo sistema de log padro syslog em /var/log/. Algumas configuraes de log j foram mostradas, como as duas configuraes globais abaixo:
log_stderror=no log_facility=LOG_LOCAL3
# Log de erros na sada stderr # Parmetro para syslog
Outro recurso interessante do XLOG a possibilidade de usar variveis de ambiente (pseudo-variveis) junto da mensagem de texto. Existem diversas pseudo-variveis, como: 11 $dp Porta utilizada. 11 $dP Protocolo de transporte. 11 $du URI de destino. 11 $fu URI do campo From. 11 $fU Identificador de usurio da URI do campo From. 11 $rm Mtodo SIP. 11 $ru URI. 11 $tu URI do campo To. 11 $tU Identificador de usurio da URI do campo To. 11 $tf Hora/Dia. 11 $ua Dados do cliente SIP(UA). Abaixo temos um script exemplificando o uso do mdulo XLOG:
loadmodule xlog.so if (method==INVITE) { xlog(L_ALERT, Chegou um mtodo ($rm) para o usurio ($ru) \n); return;
} else if (method==REGISTER) { xlog(L_ALERT, Chegou um REGISTER de $fU ($ru) em $tf\n); return; }

A lista de pseudo-variveis do OpenSIPS pode ser localizada em OpenSIPS Resources.
119
120
Atividade 1 Ligao SIP atravs do X-Lite
Nesta atividade ser utilizado o software X-Lite para realizar chamadas entre dois terminais. O primeiro passo configurar o X-Lite, software que requer que o usurio configure uma conta local (com informaes bsicas apenas, como seu nome) e um servidor SIP. Este servidor SIP ser fornecido pelo instrutor. Configure o X-Lite e faa uma ligao para o colega de dupla. Para ligar basta utilizar o Username do colega, conforme configurado no X-Lite. Capture uma ligao completa entre seu terminal e o terminal do colega. Utilize um software de sniffer de redes, como Wireshark, e responda as questes a seguir:
1. Desenhe as mensagens SIP (protocolos e portas) trocadas entre as duas mquinas
clientes e com o servidor fornecido pelo instrutor. No Wireshark, utilize o menu Telephony -> VoIP Calls para ver o diagrama e apoiar o desenho.
2. O que mudou em relao s mensagens SIP obtidas na atividade durante a prtica inter-
mediria (ponto-a-ponto sem servidor)?
3. Acesse o menu Telephony -> VoIP Calls e tente escutar a conversa.
Atividade 2 Configurao e utilizao de um servidor SIP: OpenSIPS

Nesta atividade ser configurado um servidor OpenSIPS como o que foi utilizado pelo instrutor na atividade anterior. Este servidor est instalado na mquina virtual que ser fornecida pelo instrutor. O OpenSIPS j est instalado nas mquinas virtuais. O arquivo de configuraes padro est em: /etc/opensips/opensips.cfg. As configuraes do OpenSIPS na mquina virtual j permitem que ele seja utilizado, ou seja, nessa atividade no sero necessrias alteraes nas configuraes do servidor. O intuito desta atividade que cada dupla passe a utilizar o seu servidor OpenSIPS e aprenda os comandos mais importantes para gerenciar a aplicao. Os membros da dupla devero realizar os seguintes passos (leia as Dicas para uso do OpenSIPS, logo a seguir, como apoio para a execuo dos passos):
1. Iniciar/Parar a aplicao. 2. Verificar a localizao do arquivo de configurao. 3. Monitorar a aplicao. 4. Configurar o OpenSIPS da dupla no X-Lite e efetuar ligaes entre os terminais da dupla.
121
Dicas para uso do OpenSIPS

1. Verificar se o OpenSIPS est em execuo:
ps -ef | grep opensips

2. Para iniciar/parar/reiniciar a aplicao:
/etc/init.d/opensips start /etc/init.d/opensips stop /etc/init.d/opensips restart

3. Arquivos de configurao padro esto em:
/etc/opensips/opensips.cfg
4. Monitoramento do OpenSIPS:
opensipsctl monitor
Os arquivos do OpenSIPS encontram-se em: 11 Arquivo de configuraes iniciais: /etc/default/opensips. 11 Arquivo de configuraes gerais: /etc/opensips/opensips.cfg. 11 Arquivos binrios em: /usr/sbin/. 11 Mdulos em: /usr/lib/opensips/modules/.
Verifique na sua mquina virtual que a rede est configurada no modo Bridged e no no modo NAT utilizado por padro. Reinicie sua mquina virtual ao modificar o modo.
Atividade 3 Incluir validao de usurios no OpenSIPS

Na atividade anterior, o servidor OpenSIPS estava configurado de forma bastante bsica e sem restries de acesso: qualquer terminal poderia utilizar o servidor. Nesta atividade ser includa a validao bsica de usurios atravs de nome de usurio e senha. Para o cadastro dos usurios utilizado um banco de dados (MySQL) que j est instalado nas mquinas virtuais. A atividade ser habilitar a validao de usurios, incluir os usurios no banco de dados e efetuar ligaes utilizando clientes X-Lite devidamente registrados e autorizados no OpenSIPS. A autenticao j est preparada no OpenSIPS. Para habilit-la, descomente as seguintes linhas no arquivo /etc/opensips/opensips.cfg :
loadmodule db_mysql.so loadmodule auth.so loadmodule auth_db.so

V at a seo auth_db params e descomente as 4 chamadas modparam entre as linhas 151 e 155. No se esquea de descomentar tambm a quebra de linha do terceiro auth_db params.
122
No bloco de linhas 321 a 331, descomente os dois IFs para que a validao seja feita nas mensagens de REGISTER.
Saiba mais
Habilitada a autenticao, reinicie o servidor:
/etc/init.d/opensips stop /etc/init.d/opensips start

Aps habilitar a autenticao na aplicao, necessrio utilizar o banco de dados para cadastrar usurios. Faa o cadastro utilizando os comandos a seguir. Incluir e remover usurios e alterar senhas:
Se voc utiliza o vi ou vim para editar o arquivo, pode pular para a linha 321 com o comando :321<enter>. Voc tambm pode buscar por palavras usando: /<palavras procuradas >< enter >.
opensipsctl add <username> <senha> opensipsctl rm <username> opensipsctl passwd <username> <nova_senha>
Verificar os clientes cadastrados:
opensipsctl db show subscriber

Subscriber o nome da tabela que contm os usurios registrados. A partir de agora, os clientes X-Lite devero ser configurados com o username e senha conforme cadastrados no banco de dados, para que possam se autenticar no OpenSIPS. Faa esta configurao da mesma forma como configurou o OpenSIPS na primeira vez em que foi utilizado. Para que as novas configuraes tenham efeito, pode ser necessrio reiniciar o servidor OpenSips e os clientes. Teste a comunicao com dois usurios cadastrados. Funcionou?
Teste a comunicao com um cliente no cadastrado. Funcionou?
123
124
5
Redes de computadores e videoconferncia
objetivos
Familiarizar o aluno com princpios e conceitos associados infraestrutura das redes de computadores e sua influncia nas videoconferncias.
conceitos
Unicast x multicast; Portas e protocolos usados em H.323 e SIP; Uso de firewalls; Videoconferncia via NAT; Atrasos em transmisso multimdia; Uso de QoS em videoconferncia.
Infraestrutura bsica de redes

Velocidade de acesso refere-se velocidade possvel nos meios fsicos onde ser realizada a videoconferncia. importante obter um mapa dos pontos a serem conectados, pois isso definir muita coisa em relao ferramenta de videoconferncia a ser utilizada. Abaixo so descritos alguns dos meios mais utilizados em diferentes cenrios:
Rede local
11 Fibra tica;
Captulo 5 - Redes de computadores e videoconferncia
11 Par tranado: 22 Gigabit Ethernet (1000 Mbits/s); 22 Fast Ethernet (100 Mbits/s).
Acesso domstico
11 Linha telefnica comum (dial-up): 56 kbit/s; 11 Cabo coaxial (TV a cabo): 128 k ~ 10 Mbit/s; 11 ADSL: 128 k ~ 10 Mbit/s; 11 Wi-fi: 11Mbit/s; 54Mbit/s; etc.
Backbone
11 ATM, SDH, PDH, DWDM: 2M, 10M, 100M, 155 M, 622 M, 2.4 G, etc. 11 Satlite em vrias velocidades.
125
Um timo exemplo de backbone o da RNP, que conecta diversos locais do Brasil e possui conexes de diversas velocidades. Atualmente as conexes com maior largura de banda so conexes de 10 Gbit/s e 3 Gbit/s. Os enlaces de 3 e 10 Gbit/s chegam a 24 PoPs, conforme pode ser visto na figura abaixo:
Figura 5.1 Backbone RNP (fevereiro/2012).
Formas de trfego de redes para videoconferncia

11 Ponto-a-ponto 22 Unicast 11 Multiponto 22 Unicast 22 Multicast 22 Broadcast Em redes de computadores importante distinguir conexes ponto-a-ponto de conexes que envolvem mltiplos pontos (multiponto).
Ponto-a-ponto
Uma conexo ponto-a-ponto executada atravs de procedimentos de chamada do terminal de origem para o terminal de destino por meio de um nmero IP (no caso de redes locais e Internet) ou de identificao do equipamento (como um nmero ISDN). Esta conexo pode ser realizada sem o auxlio de um elemento gerenciador, baseada apenas na conexo direta entre os computadores. Em videoconferncias, este o modelo mais simples de comunicao, onde dois pontos esto conectados e trocam dados multimdia diretamente. Em redes IP este tipo de comunicao feita utilizando unicast, que trataremos na sequncia. A exibio dos dados para
126
o usurio simples neste caso, pois cada usurio recebe dados de apenas outro usurio, portanto vdeo, udio e outros elementos podem ser exibidos sem dificuldade.
Conexo ponto-a-ponto
Figura 5.2 Conexo ponto-a-ponto.
Terminal (origem)
Terminal (destino)
Multiponto
Uma conexo multiponto viabiliza a comunicao simultnea entre vrios participantes distribudos (3 ou mais), independente de sua localizao geogrfica. Em videoconferncias, normalmente os participantes esto conectados a uma unidade central que gerencia e processa o fluxo de mdias (udio, vdeo e dados) gerado na videoconferncia. O elemento centralizador em videoconferncias chamado MCU, a unidade de controle multiponto. Este componente cuida do processamento dos fluxos de udio e vdeo de forma a integrar todos os terminais de videoconferncia. Alm do uso de um elemento centralizador, h tambm a opo de fazer mltiplas conexes ponto-a-ponto entre todos os participantes. A exibio dos dados multimdia em videoconferncias com trs ou mais participantes apresenta desafios maiores do que em videoconferncias ponto-a-ponto. Normalmente so utilizadas duas formas de exibio: participante ativo ou presena contnua.
Conexo Multiponto
Gatekeeper
MCU
Figura 5.3 Conexo multiponto.
Terminal Terminal Terminal
Terminal
Participante ativo
Todos os terminais da videoconferncia visualizam a imagem do participante ativo naquele momento. Quando outro participante se tornar ativo, sua imagem ser comutada e, assim, ele passar a ser visualizado em todos os terminais da videoconferncia. O participante ativo normalmente aquele que est falando no momento. A deteco do participante ativo costuma ser feita pela MCU com base no nvel do sinal de udio de cada participante. Essa modalidade tambm conhecida como modo comutado por voz (Voice Switched Mode) e apresenta, em geral, uma boa qualidade de vdeo e udio, alm de permitir uma visualizao completa do participante ativo. indicada em casos sem muita alternncia entre os participantes ativos, como em palestras e apresentaes.
127
Figura 5.4 Videoconferncia exibindo apenas o participante ativo.
Presena contnua
Neste modo apresentada a imagem e o udio de todos os participantes ao mesmo tempo. Essa configurao recomendada para situaes em que exista uma participao ativa simultnea de vrios usurios na videoconferncia, como ocorre em reunies, por exemplo. Com este formato de exibio perde-se um pouco na qualidade (imagens so exibidas em tamanhos menores), mas ganha-se em contedo, j que possvel ver todos os participantes e no apenas um. Aplicaes que envolvem udio e vdeo, como sistemas de videoconferncia, geram um grande volume de dados na rede. O trfego gerado em uma rede depende da natureza da aplicao (udio, vdeo, imagens etc.) e do tipo de conexo entre as mquinas onde cada aplicao est sendo executada. O tipo de conexo avalia o estabelecimento da conexo sob a tica da transferncia de pacotes entre os terminais da rede: ponto-a-ponto ou multiponto. No caso de multiponto, ainda temos: conexo por difuso (broadcast), em que um pacote endereado a todos os demais terminais da rede; e conexo por difuso seletiva (multicast), em que um pacote endereado a um grupo pr-definido de terminais na rede. Para cada uma das formas de conexo, h um tipo de trfego gerado na rede: unicast, broadcast e multicast.
Click here to add another person to the conference
Figura 5.5 Videoconferncia com presena contnua.
128
Trfego unicast
O trfego unicast aquele gerado quando uma mquina envia pacotes para um nico destino (ou host) na rede. Nesse caso, uma mquina servidora que atende a quatro clientes deve gerar quatro diferentes fluxos para cada terminal, como mostra a figura. Esta forma de trfego permite fcil comunicao tanto do servidor para o cliente quanto do cliente para o servidor. Um exemplo prtico de trfego unicast o acesso a uma pgina web atravs de um servidor HTTP. A cada acesso, estabelecida uma conexo entre o servidor HTTP e o cliente que est fazendo o pedido. Um problema do unicast a gerao de trfego excessivo na rede quando um nmero elevado de solicitaes enviado ao servidor, uma vez que para cada pedido ser gerado um fluxo de retorno. Quando se trata da transmisso de vdeo, o problema agravado, j que os fluxos gerados contm grande volume de dados que so replicados para os respectivos clientes, o que compromete significativamente o desempenho da rede. Apesar deste problema, o unicast a forma de transmisso mais utilizada atualmente, mesmo para udio e vdeo. Um exemplo de uso desse modelo o YouTube, alm de outros sites de vdeo sob demanda.
Trfego Unicast
4 3 Roteador 1
Figura 5.6 Transmisso via unicast.
Terminal 1 Rede
2 1
Terminal 2
Servidor
Terminal 4
Terminal 3
Trfego broadcast
Com trfego broadcast uma mquina gera contedo para todas as demais na rede, de forma (o endereo de broadcast) utilizado, identificando que o pacote que contm a mensagem deve ser endereado para todas as mquinas da rede. No exemplo da Figura 5.7, a distribuio de pacotes feita a partir de uma estao terrestre (servidor) que envia os dados para o satlite que, por sua vez, reenvia simultaneamente para todos os terminais (broadcast). Desta forma, um nico fluxo sai do servidor e enviado para todos os clientes. Este mtodo muitas vezes utilizado para videoconferncias em zonas rurais ou em zonas com baixa infraestrutura de redes.
que todas as mquinas recebero a mesma informao enviada. Um endereo especfico
129
1 2 3
Terminal 1
Terminal 2
Servidor
Terminal 4
Terminal 3
Figura 5.7 Transmisso via broadcast.
Trfego multicast
O trfego multicast difere do broadcast porque, em vez de enviar pacotes para todos os ns da rede, envia pacotes apenas para um grupo pr-definido de mquinas. utilizada uma forma de endereamento especial para o envio dos pacotes, designando o endereo de um grupo de ns (conhecido como grupo multicast ) e no de todos os ns da rede. Sua principal vantagem a economia de largura de banda, permitindo que um mesmo fluxo seja transmitido para vrios ns. Ao contrrio do unicast, no so necessrios mltiplos fluxos para atender mltiplos clientes; apenas um fluxo suficiente. Para tanto, so necessrias tcnicas eficientes para o encaminhamento dos pacotes na rede, implementadas atravs de protocolos especficos para o roteamento desses pacotes. Este roteamento feito pelos equipamentos intermedirios da rede (switches e roteadores), que devem estar configurados para conhecer multicast e seus protocolos. O funcionamento do trfego multicast pode ser comparado, por exemplo, com o de uma estao de rdio. Em uma estao de rdio, o sinal transmitido em uma determinada frequncia, independentemente do receptor. Cada ouvinte, na sua casa e a partir do seu aparelho de recepo, encarregado de sintonizar o canal desejado. No trfego multicast, os ns que recebem o fluxo so configurados para a recepo desse trfego, podendo ser adicionados ou excludos atravs do uso de um protocolo especfico.
Terminal 1 Rede Roteador A (Querier)

Terminal 2
Servidor
Terminal 4
Terminal 3
Figura 5.8 Transmisso via multicast.
Multiponto: unicast x multicast

Como j comentado, uma transmisso multiponto pode ser alcanada com qualquer uma das formas de transmisso comentadas: unicast, multicast ou broadcast. Broadcast uma opo que raramente ser utilizada em redes de computadores devido sobrecarga que
130
inclui na rede, apesar de ser uma tima escolha para satlite. Em redes de computadores, a escolha deve ser feita entre unicast ou multicast. A figura abaixo ilustra a principal diferena entre essas formas de transmisso: a carga que cada um implica na rede.
UNICAST FON MULTICAST FON
ROTA ROTB
Figura 5.9 Comparao de uma transmisso em mltiplos fluxos unicast ou um fluxo multicast.
ROTA ROTB REC3 ROTF ROTD REC6 REC1 REC2 REC4 ROTF REC5 REC6 ROTC
ROTC REC3
ROTD REC1 REC2 REC4
REC5
Como com unicast necessrio um fluxo para cada receptor, ele obviamente gera mais trfego na rede do que o multicast, que uma forma de transmisso muito mais eficiente nesses casos, especialmente para transmisso de dados multimdia. Apesar disso, o unicast ainda a forma de transmisso mais utilizada. O principal motivo disso a falta de suporte ao multicast nos roteadores. Por apresentar uma complexidade adicional em relao ao unicast e por no ser to utilizado, muitas vezes o multicast negligenciado pelos administradores de redes na configurao de roteadores e switches. Com isso, o uso do multicast acaba sendo possvel apenas dentro de instituies onde est devidamente configurado, como o caso da rede da RNP. Alm disso, em alguns casos o multicast no a forma mais adequada de transmisso, como em sistemas de vdeo sob demanda, por exemplo. Nestes sistemas, os usurios podem fazer a requisio de incio de transmisso no momento em que desejarem, e desejam ver o vdeo desde o seu incio. Da mesma forma, os usurios tm a possibilidade de navegar para partes especficas do vdeo, sem que as mudanas feitas por um usurio interfiram nos outros usurios. Este , portanto, um cenrio para uso de mltiplas conexes unicast. Em transmisses multicast, todos os usurios recebero os mesmos dados, ou seja, recebero o vdeo no mesmo instante. Se um usurio solicitar o recebimento de um vdeo algum tempo aps o incio da transmisso, ele no poder ver o vdeo desde seu incio. Este o caso de transmisses ao vivo, streamings e tambm de videoconferncias. No intuito de facilitar o estudo e a utilizao do espao de endereamento, a IANA definiu uma diviso lgica que designa cinco classes para o endereamento da rede IP Internet verso 4. Essa diviso chamada de Classfull Addressing (endereamento de classes) e define as seguintes classes de endereos: A, B, C, D e E conforme ilustrado na figura.
131
Classe A
0 1 0
7 8
31
Classe B
1.0.0.1 126.255.255.254 0 2 10 128.1.0.1 191.255.255.254 0 3 110 192.0.1.1 223.255.254.254 0 4 1110 224.0.0.0 239.255.255.255 0 5 11110 240.0.0.0 254.255.255.254
15 16
31
23 24
31
Classe C
31
Classe D
31
Classe E
Figura 5.10 Classes de endereamento IP.
A Classe D reservada para multicast. Entretanto, na hora de determinar o grupo multicast, importante notar que, caso ele seja utilizado numa rede privada (IP de intranet), a recomendao da RFC 2365 sugere a utilizao dos endereos 239.192.0.0 / 14, ou seja, na faixa de 239.192.0.0 at 239.195.255.255, faixa denominada IPv4 organization local scope.
Multicast
Como os pacotes enviados pelo transmissor chegam at o receptor R1 utilizando multicast? Rede local: protocolo IGMP (Internet Group Management Protocol) 11 Criao e sada de grupos (mensagens join e leave) Backbone: protocolos de roteamento multicast 11 PIM (Protocol Independent Multicast) 11 DVMRP (Distance Vector Multicast Routing Protocol) 11 MOSPF (Multicast Open Shortest Path First) 11 MBGP (Multicast BGP) E se o backbone da rede no tiver multicast? 11 Mbone (multicast backbone): criao de tneis multicast sobre unicast. 11 Permite multicast ao longo de uma rede que no suporta multicast. 11 Tnel liga dois roteadores que suportam IP multicast atravs de um enlace ponto-a-ponto unicast. Em uma transmisso multicast, um dos principais aspectos que devem ser considerados a forma como os pacotes enviados chegaro aos receptores interessados (e somente a eles). No exemplo abaixo, como os pacotes enviados pelo transmissor (no topo) chegam
at o receptor R1?
132
Transmissor
Rt1
Rt2
Rt4
Figura 5.11 Caminho percorrido pelos pacotes multicast.
Protocolo IGMP R1
Rt3
Rt6
Rt5
Os principais responsveis por esta tarefa so o protocolo IGMP (na rede local) e os protocolos de roteamento multicast (no backbone). Internet Group Management Protocol (IGMP) o protocolo que gerencia grupos multicast na rede local, incluindo a criao e sada de grupos (mensagens de join e leave). Ele definido na RFC1112. Os protocolos de roteamento multicast definem como feita a comunicao entre os roteadores para construo da rvore-multicast que define as rotas dos pacotes multicast. Diversos protocolos podem ser utilizados, entre eles: 11 PIM (Protocol Independent Multicast). 11 DVMRP (Distance Vector Multicast Routing Protocol). 11 MOSPF (Multicast Open Shortest Path First). 11 MBGP (Multicast BGP). Portanto, antes de cogitar o uso do multicast em longa distncia, verifique se todos os roteadores do caminho suportam multicast. O multicast muitas vezes est disponvel apenas em redes corporativas, o que impossibilita seu uso para comunicao entre diferentes empresas, por exemplo, assim como no suportado na Internet. Uma alternativa para aproveitar as vantagens do multicast e contornar os problemas que ele apresenta o uso de tneis multicast. exemplo prtico da aplicao dos tneis o MBone (multicast backbone), que um backbone virtual criado nos anos 90 para permitir o uso de IP multicast sobre a internet. O MBone considerado uma rede virtual sobre a internet, composta de vrias ilhas com capacidade de multicast, interligadas por conexes unicast. Cada ilha formada por uma LAN ou grupo de LANs, que possuem um roteador especial chamado mrouter (multicast router), implementado em hardware ou software. Nos mrouters, os pacotes multicast so encapsulados em pacotes unicast normais e enviados com destino a outro mrouter. Todos os roteadores no caminho aceitaro o pacote como um pacote unicast comum. Ao chegar ao mrouter-destino, o cabealho unicast removido, restando assim o pacote multicast original. Esta tcnica chamada de tunelamento.
Os tneis so utilizados para conectar duas redes multicast atravs de um canal unicast. Um
133
A imagem abaixo exemplifica a conexo entre duas ilhas utilizando mrouters.
Transmissor de G1 G1 192.168.2.2 Hub/ switch Mrouter1. Tnel com 192.168.4.2 G1 192.168.4.2 Hub/ switch Mrouter2. Tnel com 192.168.2.2 G1 G1
Figura 5.12 Utilizao de tneis multicast.
Portas e protocolos dos padres H.323 e SIP

Para administrao de videoconferncias, muito importante ter conhecimento das portas e protocolos utilizados para monitoramento das atividades, configurao de equipamentos e, principalmente, importantes para configurao em redes protegidas por firewalls. A figura a seguir mostra um resumo das portas utilizadas em videoconferncias H.323: Porta 80 1503 1718 1719 1720 1731 1024-65535 1024-65535 1024-65535
Requerido Opcional Opcional Requerido Requerido Requerido Requerido Requerido Requerido Requerido Requerido
Protocolo TCP esttico TCP esttico UDP esttico UDP esttico TCP esttico TCP esttico TCP dinmico UDP dinmico UDP dinmico UDP dinmico
Descrio Interface HTTP T.120 Descoberta de gatekeeper Gatekeeper RAS H.323 Call Setup Audio Call Control H.245 RTP (vdeo) RTP (udio) RTCP
Clientes
MCU X
GK
X X X X X X X X X X X X X X X X X
Figura 5.13 Portas e protocolos utilizados com H.323.
X X
1024-65535
Na terceira coluna Protocolo, os itens estticos indicam que somente a respectiva porta utilizada, enquanto os itens dinmicos indicam que h um intervalo possvel de portas e que a porta que ser utilizada escolhida durante a comunicao. J as trs ltimas colunas indicam em quais entidades as portas so utilizadas, ou seja, quais entidades precisam ter acesso a essas portas. Em relao ao protocolo H.245, importante observar a possibilidade de utilizar o chamado H.245 tunneling, onde as mensagens H.245 so encapsuladas em mensagens H.225, utilizando assim a mesma porta usada pelo H.225. Ou seja, no necessria uma conexo
134
especfica para o H.245, pois as mensagens utilizaro a mesma conexo do H.225. Tambm importante citar que outras portas podem ser necessrias dependendo da aplicao ou do fabricante dos equipamentos que esto sendo utilizados. Em relao ao H.323, o SIP oferece maior facilidade em relao s portas utilizadas. A tabela abaixo resume as portas utilizadas pelo SIP: Porta 5060 5061 1024-65535
Figura 5.14 Portas e protocolos utilizados com o SIP.
Protocolo UDP e TCP esttico TCP esttico UDP Dinmico UDP Dinmico UDP Dinmico
Descrio Sinalizao SIP Se TLS (HTTPS) for virtualizado RTP (Vdeo) RTP (udio) RTCP
1024-65535 1024-65535
Como pode ser visto, utilizada basicamente a porta 5060 para toda a comunicao, enquanto os dados so enviados por RTP em portas UDP dinmicas, assim como no H.323.
Uso de firewalls em videoconferncia

Solues para os problemas de videoconferncia com firewalls: 11 A mais simples: abrir a(s) porta(s) requerida(s) para todo o trfego de rede. 11 A mais elegante: existem tecnologias de firewall implementadas em roteadores que entendem o trfego de rede SIP e H.323. Essas solues podem detectar as solicitaes de sinalizao de videoconferncia e executar a ao apropriada para permitir ao trfego atravessar o roteador ou o firewall. Exemplos de implementaes: 11 Radvision ECS Firewall Solution: opera juntamente com o gatekeeper ECS quando esse ltimo reside na DMZ entre a rede IP local e a externa. 11 Software de firewall da Check Point: produtos habilitados para H.323. 11 Tandberg Border Controller: elemento de borda que pode ser agregado topologia da rede.
Para entender as implicaes do uso de firewalls em videoconferncia H.323, importante saber como funcionam os diferentes tipos de firewalls.
Firewall do tipo Packet Filter (nvel IP)

Bloqueiam ou permitem conexes com base apenas no protocolo utilizado e nas informaes de endereamento contidas nos pacotes, mais especificamente IP e porta. No analisa a aplicao que est utilizando os dados, apenas verifica os cabealhos dos pacotes. Utiliza regras estabelecidas pelo administrador e necessita que sejam abertas todas as portas UDP e TCP utilizadas. Como existem portas dinmicas (principalmente para dados por RTP), deveriam ser liberadas todas as portas que possivelmente so utilizadas, ou seja, todas acima de 1024. Ambos os firewalls (de fonte e de destino) teriam de estar configurados de forma similar, o que reduz significativamente a proteo que o firewall implementado deveria fornecer.
Firewall do tipo Circuit gateway (nvel de transporte)

Este tipo de firewall procura validar a conexo e no apenas os pacotes que circulam por ele, ou seja, o firewall verifica se a conexo entre os dois fins vlida e s ento permite que
135
informaes sejam trocadas entre eles. A definio das conexes vlidas feita com base em regras criadas pelo administrador, que podem considerar aspectos como protocolo, endereos IP, usurio e senha, entre outros. Alm disso, as sesses costumam ter um tempo de durao, que aps expirado faz com que o trfego seja bloqueado. Firewalls utilizando esse mtodo entendem protocolos de aplicao comuns, como Telnet e FTP.
Firewall do tipo Application gateway (nvel de aplicao)

Consegue controlar a comunicao entre dois ns no nvel do protocolo de aplicao. Atua como um proxy, fazendo toda a troca de informaes entre os dois fins. Possui regras muito mais especficas e poderosas para permitir ou bloquear trfego. Alm das regras bsicas existentes nos outros tipos de firewall, permite, por exemplo, limitar o acesso a arquivos apenas de tipos determinados, personalizar regras de acordo com o usurio autenticado, permitir que comandos sejam executados apenas por determinados usurios, entre outros. o tipo de firewall mais sofisticado, porm isto os torna complexos, requerendo configuraes detalhadas das aplicaes que utilizam o firewall. Mesmo que o firewall ou o NAT sejam configurados corretamente para passar todo o trfego de vdeo desejado, ainda pode haver interferncia na videoconferncia. Isto ocorre porque o firewall / NAT so basicamente computadores, e possuem um limite quanto capacidade de trfego que podem processar. Se no so rpidos o bastante para lidar com o trfego apresentado a eles, pacotes podero ser descartados e uma variao do atraso poder ser introduzida nos pacotes que passarem por ele. Portanto, certifique-se de que o dispositivo firewall ou NAT rpido o bastante para fazer o seu trabalho. As solues para os problemas de videoconferncia com firewalls esto relacionadas ao tipo do firewall utilizado. Em todos os casos, a maneira mais simples liberar o acesso em todas as portas requeridas para a videoconferncia. Esta obviamente uma soluo no muito segura, pois libera qualquer tipo de trfego para as portas abertas. A soluo mais elegante a utilizao de um firewall mais inteligente, que trabalhe como um Application Gateway, interpretando o trfego de rede SIP e H.323. Essas solues podem detectar as solicitaes de sinalizao de videoconferncia e executar a ao apropriada para permitir ao trfego atravessar o roteador ou o firewall. Alguns exemplos de dispositivos que funcionam desta maneira so: 11 Radvision ECS Firewall Solution: opera juntamente com o gatekeeper ECS quando esse ltimo reside na DMZ entre a rede IP local e a externa. 11 Software de firewall da Check Point: produtos habilitados para H.323. 11 Tandberg Border Controller: elemento de borda que pode ser agregado topologia da rede.
Videoconferncia via NAT

11 Network Address Translation (NAT) permite que vrios computadores compartilhem uma nica conexo de IP, ou pode mapear IP + porta privada para IP + porta externa e, ento, suportar mltiplos endereos de IP privados.
NAT um servio que existe com intuito de permitir que vrios computadores compartilhem uma nica conexo de IP. utilizado geralmente para conectar diversos hosts de uma rede local com redes externas (por exemplo internet) utilizando um ou mais IPs externos. Um roteador habilitado para NAT pode mapear um conjunto IP + porta privada (rede local) para IP + porta externa e, ento, suportar mltiplos endereos de IP privados.
136
A figura seguinte exemplifica uma conexo entre dois hosts utilizando NAT. O host A est em uma rede privada que controlada por um NAT (site NAT), enquanto o host B est acessvel com um IP pblico na internet.
Domnio de endereo privado Site NAT 10.0.0.1 Origem: 10.0.0.1/2000 Destino: 192.9.200.1/80
Internet pblica
Origem: 139.130.1.1/3000 Destino: 192.9.200.1/80
192.9.200.1
NAT Binding 10.0.0.1/2000 139.130.1.1/3000

Figura 5.15 Conexes atravs de uma rede com NAT.
Host A Origem: 192.9.200.1 Destino: 10.0.0.1/2000 Origem: 192.9.200.1/80 Destino: 139.130.1.1/3000
Host B
A imagem mostra pacotes trocados em duas direes: de A para B e de B para A. A para B A mquina A envia um pacote contendo o endereo de IP de origem 10.0.0.1 e porta de origem 2000, que formam o endereo de A na rede privada. O roteador com NAT modifica a origem para o IP 139.130.1.1 e porta 3000, que forma o endereo pblico das mquinas da rede interna. No host B, sabe-se apenas que foi recebido um pacote da mquina 139.130.1.1 porta 3000. B para A Quando o host B responde para A, ele envia um pacote com destino 139.130.1.1 porta 3000. Ao receber este pacote, o roteador com NAT sabe, atravs de suas tabelas internas, que este endereo deve ser traduzido para o IP 10.0.0.1 porta 2000. No host A, sabe-se apenas que foi recebido um pacote do host B. Este exemplo mostra o mapeamento tanto do IP quanto da porta utilizada, mas h casos em que somente o IP trocado e a porta mantida. A forma com que o mapeamento feito diferente conforme o tipo de implementao da NAT.
11 Dificuldade 1: ligaes iniciadas a partir de terminais externos para um terminal que est atrs de um NAT. 11 Dificuldade 2: o NAT trabalha normalmente com o cabealho, e em alguns protocolos a parte de dados da mensagem possui o IP e porta. Exemplo: SIP.
Tipos de NAT
11 Full Cone: depois de conhecer o IP (depois que NAT criou tabela), qualquer host pode conectar no mesmo IP, por qualquer porta, chegando mquina origem. 11 Restricted Cone: depois de conhecer o IP (depois que NAT criou tabela), apenas o mesmo host pode conectar no IP, com mais de uma porta, chegando mquina origem. 11 Port Restricted Cone: retorno s funciona a partir do mesmo IP e porta. 11 Symmetric : similar ao Port Restricted Cone, mas neste modo NAT cria um novo item em sua tabela para cada pacote que S envia para hosts externos.
137
Abaixo so descritos quatro tipos de NAT existentes: Full Cone, Restricted Cone, Port Restricted Cone e Symmetric.
Full Cone
Neste modelo, aps NAT conhecer o endereo IP de um host interno, qualquer host externo consegue alcanar este host interno utilizando qualquer porta. Na imagem, quando o endereo interno S:Port1 (no formato <endereo IP>:<porta>) mapeado para o endereo externo Sext:Port1ext assim que S envia um pacote para D, qualquer host externo pode enviar pacotes para Sext:Port1ext que elas chegaro at o endereo interno S:Port1 (tanto D quanto H podem mandar pacotes).
Porta 1 Porta 2 S Porta 1 Porta 2 Porta 1 Porta 2 N
Figura 5.16 NAT do tipo Full Cone.
Restricted Cone
Funciona de maneira similar ao modelo Full Cone, mas com a restrio de que apenas o host D poder contatar S (pois o pacote inicial de S foi para D). Ou seja, se H tenta enviar um pacote para Sext:Port1ext, ele ser bloqueado. Ainda assim, D pode utilizar qualquer porta de origem para contatar S.
Porta 1 Porta 2 S Porta 1 Porta 2 X Porta 1 Porta 2 N
Figura 5.17 NAT do tipo Restricted Cone.
Port Restricted Cone

Semelhante ao Restricted Cone, mas agora D s consegue responder para S utilizando como porta de origem a porta que S utilizou para contatar D. Ou seja, se S utilizou o endereo S:Port1 para contatar D:Port1, D s poder enviar pacotes para S utilizando D:Port1 como origem e S:Port1 como destino.
Porta 1 Porta 2 S Porta 1 Porta 2 X X Porta 1 Porta 2 N
Figura 5.18 NAT do tipo Port Restricted Cone.
138
Symmetric
Assim como o modelo Port Restricted Cone, s permite que S receba dados de D:Port1. A diferena que neste modo a NAT cria um novo item em sua tabela para cada pacote que S envia para hosts externos. Ou seja, se S quiser contatar D e H ao mesmo tempo (utilizando Port1 como origem), sero criados dois itens na tabela, um para cada conexo (nos outros modelos seria utilizado apenas um item). Isso tem implicao direta no uso de sistemas criados para atravessar as NATs, como o STUN, que ser comentado na sequncia.
Porta 1 Porta 2 S Porta 1 Porta 2 X X Porta 1

Figura 5.19 NAT do tipo Port Restricted Cone.
Porta 2 N
Problemas gerados pelas NATs em videoconferncias

Um dos problemas do uso de NATs o tratamento de conexes iniciadas por um host que est fora da NAT. Utilizando como exemplo a imagem do incio deste captulo, onde temos o host A em uma rede privada com NAT e o host B conectado diretamente rede pblica, o problema acontece quando a conexo inicial parte do host B. O host B tentar contatar o host A utilizando o IP 139.130.1.1. Atravs deste IP os pacotes chegaro at o roteador com a NAT, porm ele no saber para qual host da rede interna estes pacotes devem ser redirecionados. Se a conexo parte do host A, entretanto, no h problemas, pois a NAT cria sua tabela e consegue tratar todos os pacotes posteriores.
Domnio de endereo privado Site NAT 10.0.0.1 Origem: 10.0.0.1/2000 Destino: 192.9.200.1/80
Internet pblica
Origem: 139.130.1.1/3000 Destino: 192.9.200.1/80
192.9.200.1
NAT Binding 10.0.0.1/2000 139.130.1.1/3000

Figura 5.20 Pacotes atravs de NAT.
Host A Origem: 192.9.200.1 Destino: 10.0.0.1/2000 Origem: 192.9.200.1/80 Destino: 139.130.1.1/3000
Host B
E como ficaria a situao se os dois hosts esto atrs de uma NAT? Neste caso nenhum dos dois pode iniciar a comunicao. As solues sero tratadas na sequncia deste captulo. Outro problema no uso de NATs que elas estabelecem o mapeamento de portas examinando o cabealho dos pacotes que so transmitidos. Isso funciona bem para a maioria das aplicaes, porm apresenta problemas com protocolos que utilizam portas dinmicas e/ou incluem a informao da porta utilizada na rea de dados do pacote (payload). E este justamente o caso dos padres de videoconferncia H.323 e SIP, onde as conexes RTP utilizam portas dinmicas, que so definidas pelos protocolos durante o estabelecimento da sesso, onde so trocadas mensagens que contm o valor da porta na rea de dados da mensagem.
139
O exemplo abaixo mostra uma mensagem INVITE do SIP, que contm dados tanto das portas utilizadas quanto dos IPs na rea de dados da mensagem. Em uma mensagem como essa, a NAT conseguiria apenas modificar IP e porta do cabealho, mas todos os valores de IP e porta exibidos no exemplo permaneceriam iguais.
INVITE sip:206@192.168.0.30:10455 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.24:5060;branch=z9hg4bkz9hg4bkf8e2c7ca Via: SIP/2.0/UDP 192.168.0.24:5060 From: <sip215@192.168.0.154;tag=414d5646-ad-407469a8 To: <sip:206@192.168.0.154> Contact: sip:215@192.168.0.24
Solues
Alternativas para a soluo do problema: 11 Protocolo H.460 22 Criado para firewall / NAT traversal com o padro H.323. 22 Utiliza um servidor que age como um proxy. 11 STUN (Session Traversal Utilities for NAT) 22 Servidor externo auxilia descoberta de IP pblico. 22 No pode ser utilizado com NAT simtrica. 11 TURN (Traversal Using Relays around NAT) 22 Utiliza um servidor que age como um proxy. 11 ICE (Interactive Connectivity Establishment) 22 STUN + TURN. A seguir esto descritas as principais formas para permitir que videoconferncias atravessem firewalls e NATs: H.460, STUN, TURN e ICE.
Protocolo H.460
O H.460 uma srie de extenses ao padro H.323 estabelecida pela ITU para possibilitar que videoconferncias H.323 atravessem firewalls e NATs. A implementao do H.460 inclui um servidor localizado na rede pblica (fora da NAT/firewall) que age como um proxy para todo o trfego da videoconferncia. Os terminais se registram neste servidor e abrem
canais de comunicao direta com o servidor. Ou seja, os terminais no se comunicam diretamente, mas atravs do servidor H.460. A grande vantagem desta abordagem que no necessrio criar regras especiais nos firewalls e tambm no necessrio que o firewall entenda o protocolo H.323. Basta configurar o firewall para que ele permita a comunicao com o servidor H.460 (um servidor confivel). Este mtodo simples de ser implementado e utilizado, o que o torna bastante prtico para ambientes com poucos terminais e videoconferncias rpidas. Ele se torna uma soluo problemtica especialmente quando existe um grande nmero de terminais fazendo ligaes ao mesmo tempo (a largura de banda do servidor pode no ser suficiente).
140
No site No Jitter, assista ao Video Tunnels Through the Firewall.
STUN
Session Traversal Utilities for NAT (STUN) um mecanismo definido na RFC 5389 que permite que entidades atrs de NATs descubram seus endereos pblicos e com isso viabiliza videoconferncias entre elas. Seu funcionamento baseado em um modelo cliente-servidor, onde o cliente (um terminal de videoconferncia) troca mensagens com um servidor (localizado na rede pblica) para descobrir informaes como: 11 Seu IP pblico; 11 O tipo de NAT na qual o cliente se encontra; 11 O mapeamento que o NAT est utilizando para este cliente. Alm disso, o protocolo tambm possibilita outras facilidades, como manter o mapeamento do NAT sempre ativo, para que no ocorram falhas na comunicao. O STUN foi inicialmente definido na RFC 3489, e costuma ser chamado de classic STUN. Esta verso do protocolo prov todas as funcionalidades mencionadas, e pode ser utilizado de forma independente de outros protocolos. Porm, foi descoberto que esta verso do protocolo no adequada em muitos casos, pois h casos em que a soluo funciona e h casos em que no funciona. E nos casos em que no funciona no h nada que possa ser feito. Em funo desse e de outros problemas, o STUN foi novamente especificado na RFC 5389, onde passou a ser apenas uma ferramenta utilizada como parte de uma soluo de NAT traversal completa (como o ICE, que ser descrito na sequncia). O principal problema do STUN que no funciona com NAT simtrica, que um tipo de NAT muito utilizado. O problema que a associao feita no NAT entre um terminal e o servidor STUN no pode ser utilizada para conexo entre este terminal e outro, ou seja, no pode ser utilizada para a videoconferncia. Isso ocorre porque o NAT simtrico cria diferentes associaes para cada conexo, mesmo para duas conexes feitas com um s terminal (que est atrs da NAT). Por exemplo, as solues que utilizam um servidor externo apenas para tarefas como descoberta do IP pblico (ex. STUN): dessa forma, o terminal 1 descobre o IP externo e interno do terminal 2 e os utiliza adequadamente.
Servidor da rede pblica NAT / Firewall NAT / Firewall

Rede interna
Rede interna
Dados multimdia
Figura 5.21 Soluo com servidor externo.
141
TURN
Traversal Using Relays around NAT (TURN) uma extenso do protocolo STUN, incluindo as mensagens TURN, que so em grande parte mensagens no formato STUN. Este protocolo definido na RFC 5766. Assim como no STUN, o TURN utiliza um servidor em uma rea pblica para permitir que os clientes faam conexes atravs de NATs. O TURN permite que um host atrs de um NAT (o cliente) solicite que outro host (o servidor) funcione como um servidor de relay, de redirecionamento de mensagens. O cliente pode ento utilizar o servidor para redirecionar pacotes para outros clientes e controlar como este redirecionamento feito. Com o uso deste servidor, mensagens podem ser trocadas bidirecionalmente entre dois clientes. A desvantagem do uso do TURN que o uso de um servidor de redirecionamento pode gerar problemas de atraso, jitter e outros problemas de rede e tambm necessita que o servidor tenha uma grande largura de banda disponvel.
ICE
Interactive Connectivity Establishment (ICE) especificado na RFC 5245 e define uma tcnica de NAT traversal para transmisses UDP estabelecidas em um modelo de oferta e resposta. O modelo oferta e resposta feito basicamente com o uso do protocolo SDP, onde so inseridos diversos IPs e portas, que so encaminhados para um cliente testar se possvel estabelecer uma conexo com eles. Esses IPs so definidos com uso do STUN. Alm disso, o ICE tambm utiliza o TURN quando necessrio. Simplificadamente, o ICE uma soluo completa de NAT traversal que utiliza o STUN sempre que possvel e o TURN quando necessrio (quando no possvel estabelecer uma conexo direta entre os dois hosts e ento necessrio um servidor de relay ). O ICE ainda no est maduro, e no adotado largamente na indstria, criando um problema no seu uso.
Suporte a NAT nos softwares de videoconferncia

Os fabricantes de softwares de videoconferncia tm se preocupado com os problemas causados pelas NATs e melhorias esto sendo implementadas nos clientes para resolver estas dificuldades. No PVX, por exemplo, as configuraes de NAT podem ser feitas atravs dos menus Rede -> Conexo na janela de configuraes da aplicao. O PVX oferece um mtodo de descoberta automtica do IP pblico de uma mquina que est atrs de uma NAT. Se este mtodo falhar, ele tambm permite que o usurio especifique manualmente o endereo. A tela de configuraes de rede do PVX, com a descoberta de NAT habilitada pode ser vista na imagem abaixo:
142
Figura 5.22 Interface de confi gurao PVX.
Conceitos de transmisso multimdia

11 Latncia 11 Jitter 11 Skew 11 Largura da banda 11 Atraso Para entender a qualidade de uma videoconferncia, necessrio analisar alguns fatores que influenciam na sincronizao e apresentao das mdias. As principais medidas so: latncia, jitter, skew e largura de banda. Alm destas medidas, importante ter conhecimento dos diversos fatores que causam atraso na transmisso.
Latncia
A latncia o tempo entre o incio de um evento e o momento que ele se torna perceptvel no destino. 11 Quais fatores influenciam na latncia? 11 Qual o grande incmodo da latncia? 11 Quais so os valores de latncia aceitveis em videoconferncias?
q
Latncias muito grandes podem dificultar a conversao atravs da rede, comprometendo o dilogo e a interatividade necessria para aplicaes como sistemas de videoconferncia. Supondo uma situao em que duas pessoas esto conversando por meio de um sistema de videoconferncia do tipo desktop, com grande atraso na transmisso dos pacotes. O interlocutor-origem envia uma pergunta para o interlocutor-destino. A grande latncia da rede faz com que o interlocutor-destino custe a receber os pacotes que contm esta mensagem. Enquanto isso, o interlocutor A, por no saber se o outro participante ouviu, continua enviando mensagens. Aps alguns milissegundos, vem a resposta do interlocutor-destino sobre a primeira pergunta efetuada, entrelaando o dilogo e dificultando a fluncia da conversa.
143
Os principais fatores responsveis por aumentar a latncia nas redes de computadores so o atraso de transmisso, de codificao e de empacotamento. Estes e outros atrasos sero descritos mais adiante neste captulo. Em aplicaes convencionais como correio eletrnico, por exemplo a latncia na transmisso passa despercebida pelos usurios do servio. J em aplicaes multimdia como sistemas de videoconferncia a latncia pode ser percebida e at mesmo comprometer todo o servio. Nesse caso, os pacotes devem ser entregues num perodo de tempo especfico, para dar prosseguimento apresentao da mdia. Sendo assim, dizemos que os requisitos de qualidade de servio em aplicaes multimdia so diferentes daqueles em aplicaes tradicionais. Apesar de no ser uma tcnica muito precisa, o atraso pode ser medido filmando um relgio em uma videoconferncia e ver quanto tempo ele demora a chegar ao destino. A imagem seguinte exemplifica como isso feito.
Figura 5.23 Medio de atraso em uma transmisso: 410 ms.
Nesta mquina est sendo filmado um relgio, em imagem transmitida para um sistema central (similar a um MCU), e este sistema est enviando a imagem de volta para a mquina, que a exibe na janela. Comparando os relgios temos: 11 Relgio no transmissor: 43:44,64. 11 Relgio no receptor: 43:44,23.00000. Com isso, percebemos que a diferena entre os relgios de 410 ms, ou seja, a latncia desta transmisso 410 ms no momento em que foi tirada a foto. E quais seriam os valores de latncia aceitveis em videoconferncias? Pesquisas mostram que atrasos abaixo de 100 ms so imperceptveis para o ser humano. Entre 100 ms e 200 ms so valores pouco perceptveis e tolerveis, e acima disso o atraso comea a perturbar a comunicao.
Jitter
Jitter a variao da latncia. No exemplo uma rajada de pacotes: nem todos chegam ao mesmo tempo (com mesma latncia).
144
# de pacotes recebidos Latncia
Jitter
Figura 5.24 Grfico de visualizao do jitter.
t
Utilizar somente a latncia no suficiente para definir a qualidade de transmisso, pois as redes no conseguem garantir uma entrega constante de pacotes ao destino (com mesma latncia). Dessa forma, os pacotes so entregues de forma varivel, isto , variando o tempo gasto de um pacote para outro. Essa flutuao na latncia conhecida como jitter e pode acarretar na descontinuidade na exibio da mdia. A principal estratgia para compensar o jitter utilizar buffers para armazenar os pacotes que chegam e, ento, minimizar esse efeito. O buffer cujo tamanho vai depender do jitter gera mais atraso na conversao, porm inibe a descontinuidade na exibio da mdia, ou seja, evita que o receptor fique algum tempo sem dados para exibir. Esse buffer vai servir como uma reserva para manter a taxa de entrega constante ao interlocutor. Da a importncia de latncia e jitter baixos em determinadas aplicaes sensveis a esses fatores, como a videoconferncia. Alguns exemplos prticos produzidos pelo jitter elevado so aquelas quebras durante a produo do udio no cliente: podem ocorrer estouros (pops) ou sons rpidos demais (clicks) durante a reproduo do udio.
Skew
Skew a diferena do tempo de chegada entre diferentes mdias que deveriam estar sincronizadas. Exemplo: udio e vdeo. 11 Qual o skew aceitvel em uma videoconferncia? 11 Quando o skew muito grande, necessrio algum mecanismo para sincronizao das mdias. Mecanismo utilizado: 11 Transmissor inclui o timestamp nos dados de udio e vdeo. 11 O timestamp indica o momento de tempo no qual os dados foram capturados. 11 O receptor utiliza timestamps para exibir os dados no momento certo.
q
145
# de pacotes recebidos
skew
vdeo
udio
t
Qual seria o skew aceitvel em uma videoconferncia? 11 < 20 ms: imperceptvel; 11 ~ 50 ms: percebe-se que h algo errado, mas no possvel saber qual mdia est adiantada e qual est atrasada; 11 > 50 ms: causa distrao da videoconferncia; 11 ~ 1 segundo: usurio mantm seu foco apenas no udio, deixando de prestar ateno no vdeo. Como vimos, apenas valores muito pequenos de skew podem ser ignorados (menos que 50 ms). Para valores maiores, necessrio que haja algum mecanismo que sincronize as mdias antes de sua exibio. O mecanismo utilizado baseia-se em timestamps, que so marcadores do instante no qual os dados foram capturados. O protocolo RTP (Real Time Transfer Protocol) e RTCP (RTP Control Protocol), definidos na RFC 3550, possuem campos especficos nos pacotes para incluso dessas informaes. Como funciona: 11 Transmissor inclui o timestamp nos dados de udio e vdeo: todos os pacotes levam essa informao de tempo. 11 Timestamp indica o momento no qual os dados foram capturados no transmissor: um buffer de udio e um de vdeo que foram capturados no mesmo instante possuem o mesmo timestamp. 11 O receptor utiliza os timestamps para exibir os dados no momento certo: se o udio est adiantado, por exemplo, ele deve esperar o vdeo para que possa ser exibido. A figura a seguir mostra um exemplo de adaptao na rede, provavelmente atravs de mudana
Figura 5.25 Grfico de visualizao do skew.
de codec, pois foi constatado que a taxa de perdas estava muito grande para o receptor.
146
SEQ=1 SEQ=2 SEQ=3 SEQ=4 SEQ=5 SEQ=1 SEQ=6 SEQ=2 SEQ=7 SEQ=3 SEQ=8 SEQ=4 SEQ=5 SEQ=6 SEQ=9 SEQ=7
Figura 5.26 RTP/RTCP e adap tao qualidade da transmisso.
Perdas=10%
SEQ=8 SEQ=10 Perdas=10% SEQ=9 RTCP monitora o QoS da sesso, e no tem nada a ver com o QoS da rede. SEQ=1, tstamp=x SEQ=10 Para se adaptar ao jitter, basta o receptor utilizar a informao de timestamp no pacote, como ilustra a figura a seguir. Veja que os pacotes esto chegando distanciados aleatoriaSEQ=2, tstamp=x+eq 20ms mente, porm, o receptor sabe exatamente o momento de enviar os mesmos sada. Para SEQ=SEQ=3, tstamp=x+eq 40ms isso, vai necessitar do buffer de jitter. SEQ=4, tstamp=x+eq 60ms SEQ=1, tstamp=x SEQ=5, tstamp=x+eq 80ms SEQ=2, tstamp=x+eq 20ms SEQ=SEQ=3, tstamp=x+eq 40ms
A figura a seguir mostra o cabealho do RTP. O campo PT (Payload Type) indica o tipo de codec utilizado. O campo Nmero de sequncia utilizado para o RTCP verificar a taxa de perdas, pois os pacotes so numerados. O campo timestamp marca o momento da captura do primeiro byte do pacote.
147
Figura 5.27 Uso do timestamp no RTP e tempo de chegada dos pacotes para adaptao ao jitter.
SEQ=4, tstamp=x+eq 60ms SEQ=5, tstamp=x+eq 80ms
1 0 1 2 P 3 X 4 5 6 CC 7 8 M 9 0 1 2 PT T imestamp 3 4 5 6 7 8 9
2 0 1 2 3 4 5 6 7 8 9
3 0 1
V=2
Nmero de seqncia
Synchronization Source (SSRC) identi er Contributing Source ( CSRC ) identi ers
Largura de banda
A largura de banda um fator limitante para videoconferncias, especialmente devido ao vdeo, que uma mdia que consome bastante banda. A banda pode ser um limitador da qualidade do vdeo. Por exemplo, tendo apenas 512 kbps disponveis, o vdeo deve ser comprimido o suficiente para que possa ser transmitido, ou pode-se definir a banda necessria conforme a qualidade desejada. 11 Por exemplo: deseja-se uma transmisso com resoluo 720x480, 30 quadros por segundo, com alta qualidade: necessria banda de 2 Mbps. As necessidades variam muito: 11 100 kbps em videoconferncias simples via webcam. 11 1,5 Gbps em transmisses de vdeo HD no comprimido. Aplicaes de videoconferncia so muito parecidas com aplicaes de voz em termos de latncia e jitter entretanto, podem utilizar alta largura de banda. Para determinar a largura de banda ideal para um sistema de videoconferncia, necessrio conhecer a demanda requerida pelo sistema em funo da capacidade que a infraestrutura de rede pode prover. Os requisitos de largura de banda de sistemas multimdia podem variar bas-
Figura 5.28 Cabealho do RTP.
tante, indo de 100 kbps a 1,5 Gbps (transmisso de vdeo HD no comprimido), por exemplo. A largura de banda um fator limitante para a videoconferncia, sendo necessrio ajustar a demanda da aplicao disponibilidade existente. Por exemplo: pode-se optar por vdeo de qualidade mais baixa em favor de manter os requisitos de transmisso multimdia ou, ento, considerar modificaes na infraestrutura da rede em prol de atingir a demanda requerida por um vdeo de maior qualidade.
Valores de referncia
Resumindo o que foi visto, temos como valores de referncia para cada uma das medidas descritas: Latncia 11 Idealmente abaixo de 200 ms.
Jitter 11 O mais baixo possvel; 11 Aplicao deve utilizar buffer de dados para se adaptar ao jitter e evitar problemas na exibio dos dados; 11 Quando maior o jitter, maior o buffer, ou seja, maior a latncia na exibio. Skew 11 Abaixo de 50 ms; 11 Para valores maiores necessita de sistema de sincronismo no receptor.
148
Largura de banda 11 Mnimo de 256 kbit/s para obter uma qualidade aceitvel em baixas resolues; 11 Boa qualidade em SD: 2 Mbit/s; 11 Qualidade mdia em HD: 4 Mbit/s.
Atraso na transmisso
O atraso total em uma transmisso o tempo entre a captura dos dados no transmissor e sua exibio no receptor. Esse tempo envolve uma srie de fatores como, por exemplo: atraso no meio fsico, atraso de processamento nos dispositivos intermedirios (como roteadores e switches), ou atraso devido ao tempo de espera nas filas de transmisso desses dispositivos. Na sequncia sero descritos os diversos fatores que podem causar atrasos, que so: 11 Time-sharing de processos na mquina; 11 Captura de udio e vdeo; 11 Codificao de udio e vdeo; 11 Empacotamento; 11 Transmisso fsica; 11 Equipamentos intermedirios (store and forward ); 11 Insero e desinsero; 11 Fila dos roteadores; 11 Adaptao ao jitter, skew e pacotes fora de ordem.
Atraso de Time-sharing de processos na mquina

Em uma mquina com processamento fraco ou com muita demanda de processamento dos processos em paralelo podem existir falhas na: 11 Codificao de vdeo. 11 Exibio dos dados (udio/vdeo). 11 Captura dos dados (udio/vdeo). Um processador onde o processamento est muito intenso (90% a 100%) na grande maioria das vezes gera algum desses problemas na videoconferncia. Muitas vezes melhor ter um vdeo com menos qualidade, porm sem perdas, do que um vdeo com altssima qualidade, como full HD, mas com perdas. Para que uma mquina execute diversos processos ao mesmo tempo, ela precisa fazer o escalonamento dos processos, que basicamente alternar a execuo entre todos os
processos permitindo que cada um execute por um curto espao de tempo. Time-sharing o nome dado a este compartilhamento do processamento feito entre os processos. Em uma mquina com processamento fraco ou que possua muita demanda de processamento dos processos em paralelo, podem ocorrer falhas em diversas etapas da videoconferncia: codificao de vdeo, exibio dos dados, captura dos dados etc. O time-sharing de processos est sendo considerado como um atraso, pois pode provocar o aumento na latncia da transmisso caso provoque demora em alguma etapa do processo (na codificao, por exemplo, que um processo que normalmente demanda bastante do processador).
149
Atraso de captura de udio e vdeo

udio 11 Placas normalmente capturam diversas amostras a cada intervalo de tempo. 11 Tpico: 64 amostras por pacote, e aps isso gera interrupo e disponibiliza todas para o usurio. 11 Atraso para 8.000 amostras/s. 22 64 amostras / 8000 amostras/s = 8ms para cada amostra. 11 Atraso para 44.100 amostras/s. 22 64 / 44.100 = 1,5 ms. Vdeo 11 Existe um pequeno atraso em funo da cmera utilizada, dos drivers e do software (ou biblioteca) utilizado para captura. O atraso de captura o tempo necessrio para se capturar uma quantidade mnima de
dados de udio ou vdeo. Para udio, esta quantidade um determinado nmero de amostras, enquanto para vdeo um quadro. As placas de captura de udio normalmente agrupam diversas amostras a cada intervalo de tempo. Tipicamente so capturadas 64 amostras que so disponibilizadas para o usurio apenas aps todas serem capturadas. Utilizando este conhecimento, possvel calcular quanto tempo necessrio para que um grupo de 64 amostras seja capturado: 11 Para sistemas com 8.000 amostras por segundo: 22 64 amostras / 8.000 amostras/s = 8 ms para cada amostra. 11 Para sistemas com 44.100 amostras por segundo: 22 64 amostras / 44.100 amostras/s = 1,5 ms para cada amostra. J no caso do vdeo a captura funciona de forma diferente. Normalmente os dados so disponibilizados quadro a quadro aps serem capturados, gerando um pequeno atraso em funo da cmera utilizada, dos drivers e do software (ou biblioteca) utilizado para captura.
Atraso de captura e codificao

No empacotamento de udio, alguns codecs necessitam de um tempo fixo para processar a codificao. Para codificao em tempo real, necessrio que o codificador processe os dados mais rapidamente do que eles esto sendo capturados. Por exemplo: 11 Vdeo com 30 quadros por segundo;
11 udio com 300 bytes de amostras a cada 25 ms. A codificao de udio no requer tanto processamento quanto a codificao de vdeo, e por isso a codificao de vdeo sempre tomada como parmetro de desempenho. Quando se deseja codificao em tempo real, o desempenho do processador ser o limitador dos parmetros da codificao, ou seja, se o processador no est conseguindo processar em tempo real, normalmente so modificados parmetros da codificao (como resoluo, taxa de quadros por segundo, entre outros) para reduzir a carga de processamento. Portanto, quando a codificao em tempo real, o nico atraso que a codificao adiciona o atraso inicial necessrio para a codificao dos primeiros blocos de dados.
150
O atraso de empacotamento na codificao este tempo necessrio em alguns codificadores para obter o primeiro conjunto de dados e codific-los. Na codificao de udio, alguns codificadores necessitam de um tempo fixo para processar os dados e tambm utilizam um look-ahead, ou seja, verificam amostras no futuro para codificar os dados atuais. Seguem dois exemplos.
G.723
11 Tempos de 30 ms mais look-ahead de 7,5 ms; 11 Atraso de empacotamento: 37,5 ms.
G.729
11 Tempos de 10 ms mais look-ahead de 5 ms; 11 Atraso de empacotamento: 15 ms. Ou seja, o G.723, por exemplo, codifica grupos de amostras de 30 ms e utiliza 7,5 ms de amostras no futuro para codificar cada grupo, totalizando um atraso de 37,5 ms. Para o codec de udio G.723 obter os 37,5ms de udio para codificao, ele deve esperar 5 interrupes da placa de udio. Empacotamento de vdeo: 11 Alguns algoritmos de predio de movimento utilizam quadros no futuro para melhorar a codificao. 11 Para isso necessrio criar um buffer de quadros, que gera atraso. Para codificao em tempo real, o codificador deve ser capaz de processar mais rpido do que os dados so capturados.
8ms 8ms 8ms 8ms 8ms
INT
INT
INT
INT
INT 30ms + 7,5ms
t1=40ms
Encoder
300 bytes
Figura 5.29 Atraso devido captura (t1) e codificao (t2).
t2
ES udio (24B) t
Na codificao de vdeo, h algoritmos tais como os utilizados para predio de movimento que tambm requerem quadros ainda no disponveis para codificar os dados atuais. Com isso torna-se necessrio criar um buffer de quadros, que resulta em um atraso na codificao. Alm disso, dependendo da complexidade do codec, das opes escolhidas e do desempenho da mquina, possvel que o codificador tenha algum atraso no incio da sua execuo, o que tambm pode gerar certo atraso.
151
Atraso no empacotamento
Tempo gasto para os dados serem empacotados antes de serem transmitidos. Atraso para os codecs: 11 G.729 = 8 kbps. 11 G.711 = 64 kbps. Pacotes de 1000 bytes (8000 bits): 11 G.729: 8000 bits por segundo = 1 pacote por segundo = 1s por pacote. 11 G.711: 64000 bits por segundo = 8 pacotes por segundo = 125ms por pacote. O atraso de empacotamento refere-se ao tempo gasto para os dados serem empacotados para serem transmitidos na rede. Por exemplo: em uma transmisso de voz a 64 kbps o
preenchimento de um pacote de dados com 1000 bytes (j includos os cabealhos UDP, RTP, etc.) toma 125 ms. O clculo feito da seguinte maneira: 11 1000 bytes correspondem a 8000 bits ou 8 kbits; 11 Com a transmisso de 64 kbit/s, podem ser enviados 8 destes pacotes por segundo (64/8); 11 8 pacotes por segundo quer dizer que enviado um a cada 125 ms (1/8). Analisando sob o ponto de vista dos codecs de udio: 11 G.729 = 8 kbps; 11 G.711 = 64 kbps. Temos: 11 Pacotes de 1000 bytes: 22 G.729: atraso de 1s; 22 G.711: atraso de 125 ms. 11 Pacotes de 100 bytes: 22 G.729: atraso de 100ms; 22 G.711: atraso de 12,5 ms.
Atraso no meio fsico

Atraso gerado enquanto os pacotes trafegam no meio fsico, que varia conforme o mtodo de transmisso utilizado e a distncia. Velocidade de transmisso: 11 Par tranado e fibra tica:
22 2/3 da velocidade da luz (300.000 km/s) = 200.000 km/s 11 Satlite: 22 Velocidade das ondas eletromagnticas um pouco menor que a da luz ao trafegar no ar = 286.000 km/s. 22 Satlite fica a 36.000 km de altitude. Atraso para transmisso de 400 km: 11 Fibra ou par tranado: 400 km 200.000 km/s = 2ms 11 Satlite: 2 * 36.000 km 286.000 km/s 250 ms
152
O atraso gerado no meio fsico o atraso de propagao dos sinais e varia conforme o mtodo de transmisso e a distncia da transmisso. Em cabos de par tranado e fibra tica, a velocidade de propagao dos sinais 2/3 da velocidade da luz (300.000 km/s), o que resulta em 200.000 km/s. J em transmisses por satlite, a velocidade de propagao a velocidade das ondas eletromagnticas no ar, que um pouco menor que a velocidade da luz: 286.000 km/s. Alm disso, importante observar que satlites se localizam a uma grande distncia da terra, a 36.000 km de altitude. Conhecendo a velocidade de propagao, pode ser calculado o atraso no meio fsico para uma transmisso entre dois pontos localizados a 400 km de distncia, por exemplo: 11 Fibra ou par tranado: 400 km 200.000 km/s = 2ms 11 Satlite: 2 * 36.000 km 286.000 km/s 250 ms Deve ser considerado duas vezes 36.000, pois o sinal deve subir at o satlite e descer novamente.
Atraso nos equipamentos intermedirios

11 Gerado devido aos roteadores e switches por onde os pacotes trafegam. 11 Switches: podem ser cut-through, store and forward ou adaptive. 11 Roteadores: store and forward 22 Atraso gerado devido ao custo de insero e desinsero. 22 Tempo de insero ou desinsero = tamanho do quadro/taxa de transmisso.
Este tipo de atraso gerado devido aos equipamentos intermedirios pelos quais os dados trafegam nas redes, mais especificamente os switches e roteadores. O atraso varia conforme o modo de funcionamento desses equipamentos. Switches operam em um dos trs modos explicados abaixo, enquanto os roteadores utilizam o modo store and forward. 11 Cut-through: switch comea a encaminhar os pacotes antes mesmo de receb-los por completo, o que diminui a latncia mas diminui a confiabilidade. 11 Store and forward: os pacotes so recebidos e armazenados pelo switch, ele verifica sua integridade e s depois o encaminha. 11 Adaptive: opera normalmente como cut-through, mas se ocorrem muitas falhas em determinada porta, ele passa a utilizar o mtodo store and forward para aquela porta. O mtodo store and forward ser o mtodo analisado, pois o que inclui o maior atraso entre os mtodos citados. Nestes equipamentos, os atrasos so chamados de atrasos de insero (durante o store) ou atrasos de desinsero ( forward ). Esses atrasos variam conforme o tamanho dos pacotes e a velocidade com a qual os equipamentos trabalham, e podem ser calculados da seguinte maneira: 11 Atraso de insero ou desinsero = tamanho do quadro/taxa de transmisso. Com isso, temos como exemplo o custo de insero de um pacote de 125 bytes para as seguintes velocidades: 11 13 kbit/s: (125 * 8) = pacotes de 1.000 bits 1.000 bits 13.000 bits/s 77 ms 11 2 Mbit/s: (125 * 8) 2.000.000 = 0,5 ms 11 100 Mbit/s: (125 * 8) 100.000.000 = 10 us 153
Atraso nas filas dos roteadores

Acontece em momentos de congestionamento nos roteadores. Cada pacote gera um atraso de desinsero. Exemplo: 11 Quando o pacote chega ao roteador, h 10 outros na sua frente. 11 Com atraso de desinsero de 0,5 ms, o atraso adicionado ao pacote por ter esperado na fila ser de 10 * 0,5 = 5 ms. Este tipo de atraso acontece em momentos de congestionamento nos roteadores, quando
os pacotes devem esperar que outros sejam encaminhados antes que possam ser encaminhados. Cada pacote esperado gera um atraso de desinsero. Portanto, o atraso nas filas tambm depende da velocidade dos roteadores. Teremos como exemplo uma transmisso a 2 Mbit/s e pacotes de 125 bytes, onde o atraso de desinsero de 0,5 ms. Se um pacote chega ao roteador e existem 10 pacotes na sua frente, ele dever aguardar por 10 desinseres antes de ser encaminhado. Ou seja, o atraso adicionado a este pacote ser de 10 * 0,5 = 5 ms.
Atraso de adaptao ao jitter, skew e pacotes fora de ordem

Como so resolvidos os problemas de jitter, skew e pacotes fora de ordem? 11 necessrio bufferizar os dados no receptor. 11 Quanto maior o jitter, skew ou quantidade de pacotes fora de ordem, maior dever ser o tamanho do buffer. 11 Quanto maior o buffer, maior o atraso gerado na exibio.
Como j comentado, jitter a variao da latncia e skew a desincronia das mdias (udio e vdeo). J pacotes fora de ordem um problema que pode acontecer em transmisso UDP, que normalmente o protocolo utilizado para transmisso de udio e vdeo. Os trs problemas so distintos, mas so resolvidos da mesma maneira: a criao de um buffer de dados no receptor. Com este buffer, o receptor consegue evitar os efeitos do jitter e fazer a sincronia das mdias e o ordenamento dos pacotes, porm inclui o atraso na exibio dos dados. Quanto maior o tamanho do buffer, maior ser o atraso gerado. O tamanho do buffer pode ser fixo ou adaptvel. Quanto maior o jitter ou o skew, maior dever ser o tamanho do buffer utilizado. O mesmo vlido para pacotes fora de ordem: se for detectado que muitos pacotes esto chegando fora de ordem, o tamanho do buffer pode ser adaptado para que seja possvel orden-los.
Resumo dos atrasos

11 Time-sharing de processos na mquina;
11 Captura de udio e vdeo; 11 Codificao de udio e vdeo; 11 Empacotamento; 11 Transmisso fsica; 11 Equipamentos intermedirios (store and forward ); 11 Insero e desinsero; 11 Fila dos roteadores; 11 Adaptao ao jitter, skew e pacotes fora de ordem.
154
Uso de QoS em videoconferncia

Objetivo de garantir que a videoconferncia vai atingir a qualidade pretendida, tendo a banda necessria, minimizando atraso, jitter e perda de pacotes. Em videoconferncias, a qualidade de servio pode ser buscada com ferramentas do H.323 e, principalmente, com tcnicas de QoS nas redes. O conceito de Quality of Service (QoS) significa garantir a qualidade do servio em foco, no caso videoconferncias. Em videoconferncias H.323, a qualidade de servio pode ser buscada com ferramentas do H.323 e/ou com a utilizao de tcnicas de QoS nas redes. Ambas alternativas sero vistas em duas etapas: 11 QoS no H.323. 11 QoS na rede.
QoS no H.323
O gatekeeper H.323 prov algumas funcionalidades para melhoria da qualidade do servio. O QoS um bloco adicional interligado ao gatekeeper e transmisso H.323. Gatekeeper 11 Controle simples baseado em um pool de chamadas. 11 Controla o somatrio da demanda de banda de todas as chamadas. 11 Limita a largura de banda utilizada negando novas chamadas. Problemas: 11 Gatekeepers conhecem apenas o trfego H.323 viso isolada. 11 Ignora a situao atual dos dispositivos de rede terminal pode solicitar 384 kbit/s e utilizar 500 kbit/s. 11 Utiliza a banda solicitada pelos terminais, no a que realmente foi utilizada. Uma forma de buscar a qualidade de servio em videoconferncias H.323 aliar as funcionalidades convencionais do sistema de videoconferncia s funcionalidades de QoS. O gatekeeper H.323 o componente do sistema de videoconferncia que pode fornecer alguma garantia de QoS.
de admisso executado pelo gatekeeper fundamentado numa espcie de pool canal coletivo das larguras de banda disponveis. Quando um terminal vai iniciar uma ligao, ele solicita ao gatekeeper determinada largura de banda. O gatekeeper, ento, libera ou bloqueia esta nova chamada conforme as outras chamadas que esto em andamento. Supondo que o gatekeeper est configurado para utilizar 2 Mbits/s e h duas videoconferncias de 800 kbit/s em andamento, apenas chamadas de menos de 400 kbit/s sero liberadas. Entretanto, as decises feitas pelo gatekeeper a respeito da disponibilidade da largura de banda podem no coincidir com a disponibilidade real da largura de banda na rede. possvel que o gatekeeper esteja configurado para utilizar 2Mbit/s (por ser a capacidade mxima da rede), mas a banda atualmente disponvel na rede de apenas 1 Mbit/s, devido a outros trfegos no H.323. Ou seja, o gatekeeper tem uma viso isolada da rede, considerando apenas o trfego H.323.
155
O controle de admisso a principal funo do gatekeeper para buscar QoS. Esse controle
Alm disso, os gatekeepers no podem controlar a quantidade de largura de banda realmente consumida pelos terminais. Por exemplo: um terminal pode fazer um pedido para uma chamada de 384 kbit/s e, ento, emitir 400 ou mais kbit/s de dados. Se esses dados no trafegarem via gatekeeper, que a soluo mais frequente, o gatekeeper no ter conhecimento da quantidade de dados realmente transmitida e poder haver uma sobrecarga de dados na rede.
Gatekeeper Solicita 389 Kbps Autoriza 389 Kbps
Terminal H.323
Sem
sca
liza
i nv
40
Kb
ps
Sobrecarga
Figura 5.30 Gatekeeper sem fiscalizar a banda utilizada pelos terminais.
QoS na rede
H duas arquiteturas de rede para QoS, que especificam como feita a classificao dos dados e o seu gerenciamento para implementao de QoS. So elas: 11 DiffServ (Differentiated Services) 22 Classificao por pacotes. 11 IntServ (Integrated Services) 22 Classificao por fluxos. 11 DiffServ (Differentiated Services) 11 Classificao feita por pacotes. 11 Utiliza marcao DSCP (Differentiated Services Code Point ). 22 6 bits no cabealho dos pacotes IP que permitem atribuir classes aos pacotes 11 Roteadores tratam os pacotes conforme seu tipo, atribuindo prioridade aos pacotes conforme sua classe. 11 Classes so definidas pelas aplicaes ou pelos operadores da rede.
IntServ (Integrated Services): 11 Classificao feita por fluxos. 11 Aplicaes que precisam QoS devem fazer reserva de recursos na rede. Para reservas utiliza os protocolos: 11 Flow Specs: descreve os objetivos da reserva. 11 RSVP: sinaliza as reservas ao longo das redes.
156
O controle do trfego de dados nos equipamentos intermedirios da rede (roteadores, principalmente) a forma mais garantida de se conseguir QoS em redes best-effort. Apesar de o gatekeeper possuir certo controle para QoS, apenas com o tratamento de QoS diretamente nos equipamentos das redes que possvel evitar problemas mais graves em transmisses multimdia como pacotes descartados, jitter, atrasos em filas, entre outros. A imagem abaixo mostra um esquema genrico do funcionamento de QoS na rede:
Classicao
Policiamento
Figura 5.31 Esquema do funcionamento de QoS nas redes.
Filas e escalonamento
Controle de admisso e polticas de controle
Classificao
Separao dos pacotes em classes distintas, seja esta separao feita para os pacotes individualmente ou para fluxos de uma aplicao. Assim, cada classe pode ter um tratamento individualizado. Como ser visto, a classificao no DiffServ feita por pacotes e no IntServ por fluxos.
Filas e escalonamento
De acordo com a classe dos pacotes, eles normalmente so agrupados em diferentes filas e tratados de forma diferenciada. Nas filas de prioridade, os pacotes de alta prioridade so entregues primeiro; quando no existem pacotes de alta prioridade na fila, so entregues os pacotes de mdia prioridade, e o mesmo vale para os pacotes de baixa prioridade.
Controle de admisso e polticas de controle

Basicamente, contratos so definidos para garantir o atendimento de um determinado servio de acordo com a capacidade dos equipamentos. Conhecendo as polticas j existentes, os equipamentos podem fazer o controle de admisso de novas polticas. Se os recursos forem sobrecarregados ou utilizados no limite, por exemplo, os equipamentos podem comear a rejeitar novas transmisses para os servios j existentes no serem comprometidos.
Policiamento
O policiamento dos contratos (assumidos no controle de admisso) procura garantir que os requisitos estabelecidos no contrato sejam respeitados. Quando essa funo configurada em um dispositivo, deve monitorar, controlar e reforar o uso de recursos da rede conforme o contrato assumido.
157
Arquiteturas de rede para suporte a QoS

H basicamente duas arquiteturas de rede que especificam como feita a classificao dos dados e o seu gerenciamento para implementao de QoS ao longo da rede. So elas: 11 DiffServ (Differentiated Services): utiliza classificao por pacotes. 11 IntServ (Integrated Services): utiliza classificao por fluxo.
DiffServ
No DiffServ (Differentiated Services), a classificao dos dados feita por pacotes, possuindo assim uma granularidade grossa (ao contrrio do IntServ que ser visto na sequncia). So atribudas classes aos pacotes utilizando a marcao DSCP (Differentiated Services Code Point), que basicamente o uso de 6 bits no cabealho dos pacotes IP. Os roteadores ao longo da rede so configurados para tratar os pacotes de forma diferente conforme sua classe, ou seja, pacotes com classes de maior prioridade passam a ter tratamento prioritrio nos roteadores. As classes utilizadas no so especificadas pelo DiffServ e devem ser definidas pelas aplicaes ou operadores da rede.
IntServ
No IntServ (Integrated Services)a classificao feita por fluxo de dados, tendo portanto uma granularidade mais fina que no DiffServ. Neste caso no basta a marcao dos pacotes, necessrio que as aplicaes que precisam QoS faam a reserva dos recursos necessrios na rede. Para reservas de recursos so utilizados dois protocolos, que, obviamente, devem ser implementados nos roteadores para que a reserva seja possvel: 11 Flow Specs: descreve os objetivos da reserva; 11 RSVP: sinaliza as reservas ao longo das redes. O Flow Specs o protocolo utilizado pelo IntServ para descrever os objetivos da reserva de recursos. Ele dividido em duas partes: 11 TSPEC: Traffic SPECification descreve como o fluxo de dados. Por exemplo, um fluxo de vdeo a 30 quadros por segundo onde cada quadro possui no mximo 20 KB, ou seja, cada quadro ocupa at 20 pacotes. 11 RSPEC: Request SPECification indica quais garantias o fluxo necessita: normal best-effort, Controlled Load (controle leve de QoS) ou Guaranteed (garantia mxima de QoS). O Reservation Protocol ( RSVP) o protocolo utilizado para reserva de recursos no modelo IntServ de QoS. Ele especificado pela RFC 2205. A principal funo desse protocolo possibilitar as reservas de recursos atravs de toda a rota de entrega de pacotes para determinado fluxo de dados. Quando uma aplicao requer QoS para a transmisso de um fluxo de dados, o RSVP utilizado para informar sobre a necessidade de QoS para todos os
roteadores ao longo da rota de transmisso do fluxo, garantindo, assim, a manuteno das condies desejadas. O protocolo composto basicamente de duas mensagens: PATH, espalhadas por toda rede pelos transmissores que desejam QoS, e RESV, enviadas pelos receptores que desejam receber uma transmisso. As mensagens RESV contm o protocolo Flow Specs, que descreve as caractersticas do trfego de dados e as necessidade de QoS que ele possui. Atravs dessas mensagens, os roteadores ficam sabendo da necessidade de QoS para determinado fluxo e decidem se eles podem atender esta demanda ou no. Se eles podem atender a demanda, simplesmente faro o encaminhamento dos pacotes. Se no podem, eles enviam mensagens aos receptores informando do problema.
158
Diserv Classicao de pacotes Backbone
Classica e escalona os pacotes
Acesso
Acesso
Sinalizao RSVP
Domnio
Figura 5.32 Sinalizao RSVP atravs da rota de um trfego com QoS.
159
160
Atividade 1 Gerar fluxos UDP e TCP com iperf
O iperf (ou jperf com interface grfica) uma ferramenta que permite, entre outras coisas, gerar trfego de rede em diversos formatos, sendo que nesta atividade nos interessam: 11 TCP; 11 UDP; 11 Unicast e multicast. Os objetivos de utilizao de um software gerador de trfego so vrios, e pode-se resumir nos seguintes cenrios: 11 Cenrio 1: suponha que, no seu local de trabalho, voc foi convocado para organizar uma videoconferncia ponto-a-ponto com uma regio com banda desconhecida. Voc precisa estimar quanta banda pode ser utilizada pela videoconferncia, a fim de configurar o software. Nesse caso pode testar vrias bandas em UDP unicast entre os dois pontos, at descobrir o limite sem perda de pacotes. 11 Cenrio 2: voc quer saber se o provedor da sua residncia ou local de trabalho est fornecendo a banda prometida. Para isso pode-se colocar o servidor num ponto de alta largura de banda, e o cliente no local de teste, fazendo transmisses em TCP para descobrir o mximo de banda. 11 Cenrio 3: voc quer utilizar multicast na sua videoconferncia, porm no sabe se a rede entre os pontos suporta multicast. Nesse caso, basta utilizar o software fornecendo um IP multicast para teste. 11 Cenrio 4: voc precisa saber se uma determinada porta est aberta no firewall entre a sua rede e a rede destino da videconferncia. Para isso basta utilizar o software na porta desejada, seja em TCP ou UDP, conforme desejado.
Etapas da atividade prtica

So trs as etapas desta atividade prtica. Todas devem ser executadas em dupla, onde um membro da dupla executa o servidor e outro o cliente.
1. Criao de fluxo UDP unicast
Crie trs fluxos entre sua mquina e o servidor na mquina do colega. Um deles de 100kbit/s, depois outro de 1Mbit/s e depois outro de 10Mbit/s. A durao de cada fluxo deve ser pelo menos de 10 segundos. Verifique o grfico de uso da banda atravs de um software de medio de banda da rede, como o DU Meter.
2. Criao de fluxo UDP multicast
Crie um fluxo UDP multicast entre sua mquina e o servidor do colega. Utilize a velocidade de 1Mbit/s. Confira atravs de um sniffer de redes, como o Wireshark, que o IP destino realmente o grupo multicast configurado no software iperf/jperf.
161
Modifique o grupo multicast utilizado para evitar conflitos. Coloque um IP no formato 239.1.1.x, com x sendo um valor aleatrio entre 1 e 254. Voc pode utilizar o nmero da sua mquina, por exemplo.
3. Criao de fluxo TCP unicast
Crie um fluxo TCP unicast entre sua mquina e a do servidor do colega. Qual a banda obtida na conexo? Explique.
No modo TCP no deve ser especificada a banda da transmisso (-b), pois o objetivo utilizar a maior banda possvel na rede.
Atividade 2 Identificar e analisar pacotes RTP e RTCP

Nesta atividade ser utilizada comunicao em duplas para identificar e analisar pacotes RTP e RTCP em uma comunicao ponto-a-ponto. Em duplas, os alunos devem fazer uma comunicao via software de videoconferncia e utilizar o Wireshark para responder as seguintes questes:
1. Qual a funo do RTCP? Qual a proporo do nmero de pacotes RTCP frente aos pacotes RTP?
2. Para o RTP, explique os campos verso, Payload Type, Sequence Number e timestamp.
3. Identifique os fluxos de mdia existentes entre transmissor e receptor. Filtre atravs do
Wireshark um deles (mquina 1 para mquina 2). Descubra se este fluxo de udio ou de vdeo. Em seguida, filtre o segundo fluxo da mquina 1 para a mquina 2. Esse fluxo
de udio ou vdeo? Para auxiliar na descoberta, pode-se utilizar como base o seguinte: tamanho do pacote, timestamp e nmero de sequncia; verifique o significado do campo Mark no RTP.
162
Atividade 3 Calcular atrasos na comunicao

Para o fluxo de udio da Atividade 2 (item 3), calcule:
1. Tempo mdio de insero (considere o tamanho do pacote visto na Atividade 2).
2. Atraso no meio fsico (considere 30m a distncia UTP entre sua mquina e o switch).
Use filtro parecido com rtp and ip.src == 192.168.0.100 and rtp.p_type==127, mudando o IP para o IP correto do transmissor.
163
164
6
Videoconferncia multiponto
objetivos
Permitir que o aluno compreenda e saiba analisar as caractersticas de sistemas de videoconferncia multiponto e suas diferenas fundamentais para tomar uma deciso bem fundamentada na hora da escolha.
conceitos
Videoconferncia multiponto, funcionamento e solues de Multipoint Control Units (MCUs), multiponto com vdeo escalvel.
Videoconferncia multiponto
H basicamente trs modelos possveis: 11 Modelo centralizado. 11 Modelo descentralizado. 11 Modelo hbrido.
Como funciona a transmisso em um cenrio de videoconferncia com mais dois participantes? Uma conferncia ponto-a-ponto envolve apenas dois pontos da rede. Em uma rede H.323, pode ocorrer entre dois terminais ou entre um terminal e um gateway. J uma conferncia que envolve mais que dois pontos chamada de conferncia multiponto. Em videoconferncias multiponto, o modelo de transmisso adotado definido, principalmente, em funo do nmero de transmissores. Quando h apenas um transmissor, o modelo mais apropriado diferente do modelo adequado para videoconferncias com mltiplos transmissores. Em uma aula remota, por exemplo, onde um professor est transmitindo seu udio e vdeo para mltiplos alunos que no transmitem seus dados, temos o modelo com apenas um transmissor. Neste caso, possvel utilizar multicast para transmisso dos dados do professor de forma otimizada: ele s precisa enviar os dados uma vez para alcanar todos os alunos. Seguindo o mesmo exemplo, se for necessrio que os alunos faam interaes com o professor, enviando perguntas por udio e vdeo, passamos a ter um modelo com mltiplos transmissores. Este modelo o que envolve maior complexidade em transmisses multiponto, sendo, portanto, o modelo em foco no restante deste captulo. Em videoconferncias multiponto, h basicamente trs modelos de transmisso possveis: o modelo centralizado, o modelo descentralizado e o modelo hbrido. 165
Captulo 6 - Videoconferncia multiponto
Modelo centralizado
Em uma sesso de videoconferncia baseada neste modelo, cada participante estabelece uma conexo com um componente central, chamado de Multipoint Control Unit (MCU). Cada participante envia um fluxo de udio e um de vdeo para a MCU. A distribuio do fluxo de udio, vdeo e dados para cada participante feita pela MCU, que mescla os vrios fluxos de udio, seleciona um fluxo de vdeo ou compe um novo fluxo com mltiplos vdeos e retransmite o resultado para todos os participantes. Essa composio de vdeos pode ser, por exemplo, uma tela dividida em quatro partes iguais, cada uma exibindo o vdeo de um dos participantes. O MCU gerencia a videoconferncia usando funes de controle H.245 e o elemento mais importante em uma videoconferncia centralizada. Ele pode enviar o fluxo de udio e vdeo atravs de unicast ou multicast.
MCU
Figura 6.1 Videoconferncia multiponto centralizada.
Modelo descentralizado
No modelo descentralizado, no h um componente central para controlar a conferncia como a MCU. Neste modelo so os prprios terminais que fazem o controle da comunicao e do trfego de dados multimdia. Uma diferena importante justamente o tratamento dos dados multimdia: enquanto no modelo centralizado a MCU faz o processamento de mdia, no modelo descentralizado os fluxos so enviados e recebidos por todos os participantes sobre uma base fim a fim, sendo que cada participante responsvel por sua prpria mesclagem de udio e seleo de vdeo. A transmisso dos dados multimdia entre os terminais pode ser feita utilizando unicast ou multicast.
Unicast
Com unicast, cada terminal deve transmitir seu fluxo para cada um dos outros terminais, assim como deve receber o fluxo de cada um dos terminais. Ou seja, para n terminais, cada
terminal deve enviar e receber n-1 fluxos. Este modelo apresenta um problema de escalabilidade quando a videoconferncia apresenta muitos terminais.
166
Figura 6.2 Videoconferncia multiponto descentralizada usando unicast.
Multicast
O uso de multicast reduz em parte o problema do modelo com unicast: agora cada terminal envia apenas um fluxo, mas continua recebendo n-1 fluxos. Com isso reduzido o upload de cada terminal, mas no reduzido o download.
Transmisso multicast
Figura 6.3 Videoconferncia multiponto descentralizada usando multicast.
Outra forma de visualizar a codificao escalvel vista na Figura 6.4 (Telepresence options, setembro de 2012 Jeff Scherz Video Interoperability in Lync 2013).
Figura 6.4 Exemplo de transmisso escalvel com quatro camadas se adaptando a dispositivos com diferentes resolues.
Modelo hbrido
O modelo hbrido tenta mesclar o melhor dos dois modelos anteriores, mantendo a consistncia dos dados atravs de um armazenamento centralizado que controla a conferncia, mas permitindo que os terminais tenham autonomia suficiente para fazer a transmisso de alguns dados de forma descentralizada.
167
Transmisso multicast
MCU
Figura 6.5 Videoconferncia multiponto hbrida.
Uma implementao hbrida pode: operar sobre uma rede multicast com cada usurio utilizando sua prpria verso das ferramentas; distribuir o fluxo de mdia de acordo com o modelo descentralizado, mas contendo algum mecanismo tal como um servidor na conferncia para controlar documentos compartilhados, ou arquivar a mdia de sesses que ocorreram. Portanto, o modelo hbrido tem a vantagem de prover armazenamento centralizado para sesses de videoconferncia para cada participante da sesso, sem ter que controlar cada instante da aplicao. Um exemplo de videoconferncia baseada no modelo hbrido utilizar uma MCU para manusear o udio, dados e controle de funes, mas distribuir o vdeo por multicast, com objetivo de otimizar a largura de banda.
MCU
11 Gerencia conferncias multiponto, viabilizando a comunicao entre 3 ou mais pontos simultaneamente. 11 Permite a criao de mltiplas salas virtuais de conferncia. 11 Pode transmitir os vdeos em unicast (para todos participantes) ou multicast. 11 Pode ser apenas um controlador de sinalizao (modelo hbrido) ou tambm controlar toda a mdia (modelo centralizado). Outras funcionalidades: 11 Realiza a transcodificao de velocidades (bitrate). 11 Servidor de streaming (suportado pela minoria das solues). 11 Sistema de gerenciamento via web com: 22 Controle sobre os participantes remotos.
22 Bloqueio de udio/vdeo remoto. 11 Mltiplos layouts de vdeo. A MCU a unidade responsvel pelo gerenciamento de conferncias multiponto, viabilizando a comunicao entre trs ou mais pontos simultaneamente. Uma MCU normalmente permite a criao de mltiplas salas virtuais de conferncia, podendo agir apenas como um controlador de sinalizao (no modelo hbrido) ou tambm controlar toda a transmisso multimdia (no modelo centralizado). Outras funcionalidades importantes da MCU: 11 Realizar a transcodificao de velocidades (variao no bitrate de codificao); 11 Servidor de streaming (suportado pela minoria das solues);
168
11 Sistema de gerenciamento via web com: 22 Controle sobre os participantes remotos; 22 Bloqueio de udio/vdeo remoto; 22 Mltiplos layouts de vdeo, conforme exemplo da figura seguinte.
Figura 6.6 Mltiplos layouts de vdeo.
Dois modos de operao para controle de udio e vdeo: Comutao por voz 11 Vdeo e udio de apenas um participante. 11 O participante ativo aquele que est falando no momento. Mixagem de vdeo e udio 11 Chamada de presena contnua. 11 Mltiplos vdeos e mltiplos udios mixados. Os vdeos so dispostos conforme o layout escolhido. A recomendao H.323 especifica que a MCU composta por dois elementos bsicos: um
Multipoint Controller (MC), obrigatrio para conferncias multiponto, e unidades Multipoint Processor (MP), opcionais. Apesar do MP ser opcional, uma MCU deve incluir pelo menos um para suportar a realizao de conferncias centralizadas. O Multipoint Controller (MC) tem como objetivo fazer o controle geral da conferncia, o que envolve fazer ou receber chamadas dos terminais, negociar as capacidades dos terminais e se comunicar com o MP quando for necessrio algum tratamento sobre os dados de udio e/ou vdeo. O MC no est presente em uma rede H.323 de maneira independente, mas sempre associado a uma entidade H.323. Uma das funcionalidades mais importantes do MC a negociao de capacidades com cada um dos terminais presentes conferncia, onde ele procura estabelecer capacidades comuns de udio, vdeo ou dados. Isto feito enviando um conjunto comum de capacidades (capability set) aos terminais conectados conferncia. Neste ponto, importante lembrar que cada terminal tambm fornece sua tabela de capacidades no incio da chamada ao elemento que contm o MC, que pode ainda rever tal conjunto de capacidades cada vez que um terminal entra ou deixa a conferncia. Este conjunto de capacidades tambm pode ser crucial para a determinao do tipo de conferncia (centralizada ou descentralizada) em questo. Cada conferncia possui somente um MC que executa a funo de gerenciamento. Este MC chamado MC ativo e, uma vez determinado, este status no modificado at o final da conferncia ou seja, durante o curso de uma conferncia H.323, o controle de gerncia jamais 169
transferido de um MC para outro. Eventualmente, quando dois terminais H.323, que possuem um MC cada, conectam-se atravs de uma chamada por exemplo, um terminal com um MC chamando uma MCU , uma regra deve ser determinada a fim de estabelecer o MC que se tornar o MC ativo. A ordem de preferncia utilizada definida pela seguinte funo: MC terminal < MC gateway < MC gatekeeper < MC MCU. Nesse caso, o MC presente em uma MCU tem preferncia total na escolha do MC ativo. O MC de um terminal s ser escolhido como MC ativo se nenhuma outra entidade estiver envolvida na chamada. Eventualmente, uma chamada para incio de uma conferncia pode ser estabelecida entre duas entidades de um mesmo tipo que possuam um MC. Para resolver este conflito, o protocolo H.245 utiliza um campo terminalType, que armazena um valor inteiro calculado com base nas caractersticas de cada um dos elementos. Os valores para este campo dependem do tipo de entidade, da presena ou no de MC e MP e, por fim, dos tipos de mdia suportados pelo MP: dados; dados e udio; dados, udio e vdeo (completa). Sendo assim, o MC da entidade que apresentar maior valor para terminalType assume o controle da conferncia. O Multipoint Processor (MP), a exemplo do MC, s existe associado a uma entidade H.323 tipicamente, uma MCU ou gateway. O MP se faz presente em uma conferncia apenas quando se trata do modo centralizado ou, possivelmente, no modelo hbrido. O MP tem por finalidade processar um ou mais fluxos de udio, vdeo ou dados, devolvendo o resultado deste processamento aos participantes da conferncia. Caso o MP processe vdeo, o resultado desse processamento pode ser: (1) a mixagem dos vdeos de diversos participantes de acordo com um layout escolhido; ou (2) a chamada comutao dos vdeos, onde apenas o vdeo de um participante utilizado (o participante ativo). No caso de vdeo comutado, somente o vdeo de um dos participantes exibido por vez. A seleo do vdeo que ser exibido feita detectando-se o usurio ativo no momento, ou seja, aquele com a posse da palavra. J os udios dos participantes so mixados e enviados para todos, ou seja, apesar de ser exibida apenas uma imagem, possvel ouvir os outros participantes. Esta tcnica chamada de comutao de vdeo ativada por voz (voiceactivated video switching). Se os participantes no so suficientemente disciplinados, aguardando sua vez de falar, este tipo de comutao pode ser problemtica, pois o vdeo pode ser continuamente chaveado assim que um participante comea a falar, impossibilitando uma visualizao inteligvel.
Figura 6.7 Vdeo comutado por voz.
No outro caso, vdeo mixado, os vdeos de diversos participantes so combinados em um novo vdeo que codificado e enviado aos participantes. Tipicamente, o MP divide o vdeo em vrias janelas distintas, cada uma com o vdeo em escala reduzida de um dos participantes. Normalmente, uma das janelas (normalmente maior que as outras) escolhida para aplicar uma comutao baseada em voz, enquanto as demais se mantm inalteradas,
170
a menos que um dos participantes deixe a conferncia. Esse modo chamado de presena contnua. Alguns fabricantes oferecem layouts diferentes como diferencial (como no exemplo visto anteriormente). O modo de presena contnua implica um elevado custo computacional para sua realizao, uma vez que o MP trabalha decodificando e recombinando vdeo de vrios participantes, em vez de simplesmente retransmitir determinado vdeo, como no modo de comutao por voz. A situao do udio permanece como no modo por comutao: o fluxo de udio enviado por cada um dos participantes combinado e o fluxo resultante enviado para todos. O MP deve ter o cuidado de garantir que nenhum participante receba seu prprio udio misturado com os demais; caso contrrio, haveria um desagradvel efeito de eco.
Figura 6.8 Vdeo com presena contnua.
Click here to add another person to the conference
Solues de MCUs
A escolha de uma soluo de MCU feita com base nos requisitos necessrios para as videoconferncias. importante que suportem os principais protocolos atuais: 11 Protocolos de vdeo: H.261, H.263 / H.263+ / H.263++ / H.264. 11 Resolues de vdeo: 11 CIF, QCIF e 4CIF 720p e 1080p (alta definio). 11 Protocolos de udio: G.711, G.722, G.722.1 e G.728. 11 Protocolo para compartilhamento de dados: T.120 e H.239. Quanto visualizao, devem suportar: 11 Variados layouts de vdeo. 11 Layouts com suporte a um grande nmero de participantes. 22 Geralmente, o nmero de referncia 16. 11 Formato widescreen. 11 Possibilidade de preview das cmeras dos participantes. 11 Controle do udio e vdeo dos participantes remotos (habilitar/desabilitar). 11 Mensagem de texto na tela (close caption).
171
Quanto segurana, devem suportar: 11 Configurao de direitos e privilgios para usurios. 11 Configurao de senha para conferncias. 11 Padro de encriptao ITU H.235 (pelo menos codificao AES). Tipos de solues: 11 Baseadas em hardware. 22 No-modulares: solues fechadas, que no podem ser agrupadas a outros mdulos posteriormente. 22 Baseadas em software (OpenMCU, por exemplo).
A escolha de uma soluo de MCU feita com base nos requisitos necessrios para as videoconferncias. Seguem abaixo alguns itens importantes que devem ser considerados para a escolha de uma soluo de MCU. importante que a soluo que suporte os principais protocolos atuais de vdeo (H.261, H.263 / H.263+ / H.263++, H.264) e os formatos (CIF, QCIF e 4CIF) em 720p e 1080p, para alta definio. Suportem tambm os protocolos de udio (G.711, G.722, G.722.1 e G.728) e protocolo para compartilhamento de dados (T.120, H.239). Quanto visualizao, devem suportar variados layouts de vdeo, layouts com suporte a um grande nmero de participantes onde geralmente, temos como referncia 16, suporte ao formato wide screen com possibilidade de preview das cmeras dos participantes (atravs de interface de gerenciamento web da MCU, por exemplo), deve permitir controlar o udio e o vdeo dos participantes remotos podendo habilitar e desabilita-lo e at mesmo exibir mensagens de texto na tela (close caption). Quanto segurana, devem permitir a configurao de direitos e privilgios para usurios, configurao de senha para conferncias e suporte ao padro de encriptao ITU H.235 (pelo menos codificao AES). As solues de MCU podem ser classificadas em dois tipos: as baseadas em software e as baseadas em hardware. As solues em hardware constituem solues comerciais completas para o oferecimento do servio de videoconferncia. So solues caras e geralmente utilizadas no meio profissional. Elas podem ser modulares, onde recursos (outros mdulos MP, por exemplo) podem ser agregados conforme a necessidade, e no-modulares, que so modelos mais fechados e no permitem expanso.
Figura 6.9 Equipamento MCU.
As solues baseadas em software so mais baratas, mas seu desempenho dependente do hardware onde sero implantadas. Essa dependncia torna o servio suscetvel e frgil. Porm, existem solues acessveis em cdigo aberto e que oferecem resultados satisfatrios em casos de conferncias experimentais, como por exemplo, a soluo OpenH323.
172
Solues de MCUs em hardware

11 Modelo modular. 11 Modelo no-modular: 22 Mesmos fabricantes dos modelos modulares. 22 A expanso s possvel atravs do cascateamento de MCUs, ou seja, no uma soluo to boa quando a expanso adicionando mdulos. 22 Por serem uma caixa fechada, so modelos mais baratos que os modulares. As solues de MCU em hardware, tanto os modelos modulares quanto os no-modulares, so disponibilizadas por diversos fabricantes. Os principais fabricantes atualmente so: Codian (que faz parte da Tandberg), Tandberg (que faz parte da Cisco), Polycom e Radvision. As MCUs modulares utilizam um chassi onde os mdulos so colocados e interligados. possvel, portanto, comprar a MCU bsica com apenas um mdulo e adicionar novos mdulos (Multipoint Processors) conforme necessidades futuras. J os modelos no-modulares so caixas fechadas, onde a expanso s possvel atravs do cascateamento de
MCUs. No cascateamento, as mltiplas MCUs operam como se houvesse apenas uma MCU na rede (cascateamento transparente ao usurio), mas ainda assim no uma soluo to otimizada como a expanso por adio de mdulos. Por esse motivo os modelos modulares costumam ser solues mais caras do que os modelos no modulares.
Figura 6.10 Exemplos de MCUs modulares.
As imagens abaixo exemplificam MCUs em hardware, incluindo modelos modulares e no-modulares:
Tandberg
Polycom
MPS 200
MPS 800
MGC 50
MGC 100
RMX 2000*
Codian
Radvision
MSE 8000*
173
SCOPIA 400
SCOPIA 1000
Polycom
MGC 25
Codian
Radvision
Figura 6.11 Exemplos de MCUs no-modulares.
Srie 4200
Srie 4500 (HD)
SCOPIA 12/24
Modelos de MCU que suportam alta definio esto sendo demandados em funo do crescente nmero de terminais que suportam alta definio.
Lifesize
Polycom
Tandberg*
Lifesize Room
Srie HDX 9000
Tandberg Edge
Figura 6.12 Exemplos de MCU.
Demonstrao de MCU RNP

11 MCU utilizada pela RNP: Polycom RMX4000. 11 Caractersticas: H.264 High Profile nvel 4 (720p, 1080p). 11 Custo aproximado: U$250.000,00. A Rede Nacional de Ensino e Pesquisa (RNP) utiliza a MCU modelo RMX 4000 da Polycom com 180 portas. Este equipamento permite a imerso em telepresena, com integrao a partir de diversas plataformas de conferncia e dispositivos mveis. Caractersticas: 11 H.264 High Profile; 11 Alocao dinmica de recursos; 11 Suporte multi-rede;
11 Integrao nativa com aplicativos; 11 Suporte a tecnologia UltimateHD da Polycom; 11 Salas de reunies virtuais sempre disponveis.
174
Figura 6.13 MCU RMX 4000.
Solues de MCUs em software

Soluo baseada em software, dependente dos recursos de hardware onde for implantada. OpenMCU: 11 Desenvolvida no projeto OpenH.323 (agora chamado H.323Plus). 11 Soluo open source. 11 Suporte a vdeo H.261 e H.263 com resolues QCIF e CIF. 11 Suporte a vrios codecs de udio (todos suportados pelo OpenH.323). 11 Combina no mximo vdeo de 4 participantes. 11 Suporta mltiplas salas de videoconferncia. Solues de MCU baseadas em software so solues normalmente muito mais baratas que solues em hardware, mas cujo desempenho depende diretamente da capacidade da
mquina na qual a soluo est instalada (isso inclui o desempenho do hardware e do sistema operacional que o controla). Normalmente esse desempenho bastante inferior do que o desempenho das solues em hardware (onde o hardware j otimizado para uso de MCU). Um exemplo de soluo MCU em software o OpenMCU, uma aplicao open source desenvolvida no projeto OpenH323 (agora chamado H323Plus). O OpenMCU uma soluo livre mas limitada, tendo como principais caractersticas: 11 Suporte a H.261 e H.263 com resolues QCIF e CIF; 11 Suporta todos os codecs de udio suportados pelo OpenH323; 11 Interface de configurao web; 11 Suporta mltiplas salas de videoconferncia e conexes simultneas;
11 Possibilita iniciar chamadas a partir da MCU para os terminais; Combina no mximo o vdeo de 4 participantes. MCUs em software normalmente possuem limitaes similares no nmero mximo de participantes. Assim, podem ser oferecidas diferentes verses do software, cada uma com suporte a um diferente nmero de participantes (o que usado para determinar o preo de venda).
175
Alternativa ao MCU: vdeo escalvel

Permite codificar um vdeo em mltiplas camadas. Cada camada representa o vdeo com determinadas configuraes de: 11 Resoluo. 11 Taxa de quadros por segundo. 11 Qualidade (medida PSNR). 11 Taxa de bits por segundo (bitrate). 11 Ou seja, o vdeo codificado apenas uma vez e pode ser transmitido e visualizado em diversas configuraes/qualidades. Comparao com MCU: 11 MCU precisa decodificar os dados, compor o novo vdeo e codific-lo. 11 Um roteador escalvel apenas faz a seleo e o encaminhamento dos pacotes ajustando o nmero de camadas de acordo com a capacidade do receptor. Vantagens sobre o uso de MCU: 11 Minimiza o atraso. 11 Minimiza o processamento (feito apenas nos terminais). 11 Resulta em equipamentos mais baratos que MCUs. 11 Maior qualidade, visto que no faz transcodificao. Desvantagens sobre o uso de MCU: 11 Necessita de um software codificador e decodificador escalvel nos terminais, exigindo maior processamento. 11 Dificuldade de interoperar entre diferentes fabricantes, pois o Scalable Video Coding (SVC) ainda pouco explorado. Codificao de vdeo escalvel, simplificadamente, uma forma de codificar um vdeo em diversas camadas cumulativas, onde as camadas inferiores possuem qualidade mais
baixa e servem como base para as camadas superiores, que adicionam qualidade ao vdeo. Podemos ter, por exemplo, um vdeo codificado com 3 camadas, sendo elas: 11 Camada 0: resoluo 160x120 e 15 quadros por segundo: 128 kbit/s; 11 Camada 1: agrega camada 0 o diferencial para uma resoluo 320x240 e 30 quadros por segundo: camada 1: 384kbit/s. Agregado camada 0 + 1 = 512 kbit/s; 11 Camada 2: agrega o diferencial para uma resoluo 640x480 e 30 quadros por segundo: camada 2: 512kbit/s. Agregado camada 0 + 1 + 2 = 1024 kbit/s.
As trs camadas do exemplo formam um vdeo apenas, e no trs vdeos. Com codificao de vdeo tradicional, para obter essas trs diferentes configuraes dos vdeos, seria necessrio codificar o vdeo trs vezes. Com codificao escalvel necessria apenas uma codificao. A desvantagem, porm, est no maior custo de processamento e em uma compactao um pouco menor do que a obtida com uma codificao no escalvel (20% menos eficiente, por exemplo). A imagem seguinte ilustra o processo de codificao escalvel.
176
Vdeo original Alta resoluo, qualidade alta TV Alta resoluo, qualidade baixa Codicao escalvel Baixa resoluo celular
Figura 6.14 Codificao escalvel em trs camadas.
PC
Codicao nica
O padro mais atual para codificao de vdeo escalvel o H.264 SVC (Scalable Video Coding ). Com esta forma de codificao, possvel substituir a MCU por um elemento chamado roteador escalvel, que apenas faz a seleo e o roteamento dos pacotes, um processo muito mais simples e rpido que o processo feito pela MCU.
Codicao escalvel
MCU
Decodicar Usurio 1 Usurio 2 Usurio 1
Decodicar Usurio 2
Compor Roteamento e seleo das camadas
Codicar
Usurio 3
Figura 6.15 Comparao do roteador escalvel com a MCU.
Usurio 3
Como pode ser visto na figura anterior, o processamento feito pela MCU inclui: a decodificao de todos os vdeos que ela recebe (todos os participantes da videoconferncia); a composio dos vdeos em um s vdeo; a codificao deste vdeo gerado. Todo este processo bastante complexo computacionalmente, incluindo assim o atraso na transmisso. tambm devido a essa complexidade que as MCUs so dispositivos caros, j que devem ter alto poder de processamento. J o modelo com roteador escalvel passa uma maior complexidade para os terminais, minimizando o trabalho do roteador escalvel, substituindo a MCU. Dessa forma, o roteador j recebe dos terminais os vdeos codificados de forma escalvel, e apenas seleciona as camadas que sero retransmitidas aos destinatrios, de acordo com a capacidade de processamento e banda de cada um. A decodificao e recodificao feitas pela MCU no so necessrias neste cenrio, e a composio dos diversos vdeos feita apenas no receptor, antes da exibio. 177
Utilizando as 3 camadas de vdeo utilizadas como exemplo anteriormente, uma transmisso escalvel pode se dar como no exemplo abaixo: 11 Os 4 participantes codificam seus vdeos de forma escalvel, com as 3 camadas citadas no exemplo, transmitindo-as para o roteador escalvel (que faz o papel do MCU); 11 O layout escolhido pelos participantes de um vdeo com maior resoluo (comutado por quem est falando no momento) e 3 vdeos com menor resoluo; 11 O roteador identifica que o participante A est falando, e por isso transmite as camadas 0 e 1 de seu vdeo (obtendo um vdeo com resoluo 320x240 e 30 quadros por segundo a 512 kbit/s); 11 Para os outros 3 participantes, o roteador transmite apenas a camada 0 (vdeos com resoluo 160x120 e 15 quadros por segundo a 128 kbit/s); 11 Com isso cada participante receber 3 vdeos com resoluo 160x120 e um vdeo com resoluo 320x240, com banda total de 896 kbit/s (4x128kbit/s + 1x384kbit/s); 11 Eventualmente, se um dos participantes no tivesse banda suficiente, ele poderia receber somente a camada 0 de todos os participantes, minimizando sua necessidade de banda. possvel fazer diversas configuraes de camadas variando resoluo, quadros por segundo e banda de cada camada de vdeo na codificao escalvel. Alm disso, tambm possvel fazer adaptao da banda dos vdeos dinamicamente, ou seja, o total de 896 kbit/s recebido por cada participante no exemplo anterior poderia ser reduzido pelo prprio rote ador em troca da perda de qualidade dos vdeos. Como podemos ver, existem algumas vantagens relacionadas utilizao de vdeo escalvel. Resumidamente, as vantagens em relao MCU so: 11 O atraso reduzido (no necessrio perder tempo em transcodificao e mixagem); 11 O processamento reduzido, pois feito apenas nos terminais. O roteador s um encaminhador de pacotes que determina tambm o nmero de camadas para cada terminal; 11 Equipamentos mais baratos que MCUs. Em termos de desvantagens, pode-se dizer que, como o modelo novo, no existe padronizao de sinalizao ainda, e a interoperabilidade entre diferentes fabricantes prejudicada. Alm disso, aumenta a necessidade de processamento nos terminais.
Estudo de caso de vdeo escalvel: empresa Vidyo

Vidyo uma empresa que desenvolve solues de videoconferncia baseadas em codificao de vdeo escalvel (padro H.264 SVC Scalable Video Coding ). Seu ncleo baseado em um roteador H.264 SVC.
Vidyo uma empresa que desenvolve uma soluo de videoconferncia baseada em codificao de vdeo escalvel, que uma alternativa ao modelo padro de videoconferncias multiponto que tm a MCU como elemento centralizador. A figura a seguir mostra a ideia de forma geral, onde a seta verde representa o fluxo de vdeo escalvel. Para conversar com outros tipos de conferncia, necessrio um gateway.
178
Figura 6.16 Estrutura da soluo da empresa Vidyo.
v
Acesse www.vidyo.com e assista ao vdeo Vidyo Desktop in Action
179
180
Atividade 1 Demonstrao das funcionalidades do Polycom V500
Nesta atividade o instrutor demonstrar as funcionalidades do terminal Polycom V500 em sala de aula. Entre os protocolos suportados por este terminal esto H.263, H.264, H.323, SIP e criptografia AES, entre outros. Sua especificao completa pode ser encontrada em Polycom Technical Specifications. Na demonstrao, deve ser ressaltada a possibilidade de administrao da soluo pela web atravs da porta 80 e tambm introduzindo o recurso People + Content, que ser apresentado na prxima atividade. Neste momento o instrutor deve realizar chamadas para o software de videoconferncia H.323 de alguns alunos e receber chamadas de outros alunos para demonstrar o uso do Polycom V500.
Atividade 2 Compartilhamento de documentos com People+Content

Nesta atividade o instrutor demonstrar a utilizao do aplicativo People+Content para compartilhar documentos com o terminal Polycom V500. Inicialmente deve-se estabelecer uma chamada entre o Polycom V500 do instrutor e algum aluno utilizando o Polycom PVX. Aps estabelecer a conexo, o aplicativo People+Content (instalado em qualquer mquina do laboratrio) estabelece conexo com o Polycom V500, entrando assim na conferncia.
181
182
7
Projeto de ambientes de videoconferncia
objetivos
Ao final do captulo o aluno deve possuir uma viso mais embasada dos elementos necessrios para efetuar o projeto de todos os aspectos envolvidos em uma sala de videoconferncia (ambiente fsico, udio e vdeo). Alm disso, deve entender os conceitos bsicos de tica em videoconferncia.
Projeto de salas de videoconferncia, levando em considerao o ambiente fsico (iluminao, visibilidade, acstica, climatizao), ambiente de udio (tipos e posicionamento dos microfones) e ambiente de vdeo (interferncias, acessrios), tica em videoconferncia e estudo de cenrios.
conceitos
Salas de videoconferncia
Diversos fatores em uma sala de videoconferncia influenciam na qualidade do servio de videoconferncia. Eles podem ser separados em trs classes: 11 Ambiente fsico. 11 Ambiente de udio. 11 Ambiente de vdeo.
O ambiente onde uma videoconferncia realizada possui diversos fatores que influenciam a qualidade do servio de videoconferncia. Esses fatores podem ser encaixados em trs grupos: ambiente fsico, ambiente de udio e ambiente de vdeo. Quando determinados adequadamente de acordo com a sala que ser usada para videoconferncia, esses fatores podem definir o sucesso ou fracasso das videoconferncias. Entre os fatores esto iluminao, visibilidade, acstica, mobilirio ergonmico e decorao. O projeto fsico da sala envolve a identificao destes elementos, a definio de suas caractersticas e a disposio dos mesmos no espao fsico alocado. O projeto uma etapa indispensvel para criao de uma sala de videoconferncia adequada, pois uma sala de videoconferncia possui muitas diferenas em relao a uma sala tradicional, como, por exemplo, se compararmos uma sala de aula tradicional com uma sala de aula adequada para aulas remotas por videoconferncia.
183
Captulo 7 - Projeto de ambientes de videoconferncia
Ambiente fsico
Os principais fatores que devem ser considerados na realizao de videoconferncia que esto relacionados ao ambiente fsico so: Iluminao 11 Influencia diretamente a qualidade das imagens. Recomendaes: 22 Evitar fontes externas de iluminao. 22 Utilizar fontes homogneas de luz. 22 Utilizar ambiente uniforme e pouco reflexivo. Visibilidade 11 Procure minimizar obstculos e interferncias visuais. 11 Maximize a rea de exibio das imagens. Acstica 11 Observe o tratamento acstico do ambiente para minimizar os rudos externos e internos que possam interferir no bom andamento da videoconferncia. 11 Use cortina, carpete e isolamento acstico para evitar mveis muito retos que reflitam o som. Climatizao 11 O ar-condicionado deve ser escolhido levando em considerao os rudos por ele gerados, na opo mais silenciosa possvel.
Iluminao
De nada adianta o avano tecnolgico das cmeras de vdeo nos ltimos anos, se a qualidade de iluminao proporcionada no ambiente no for adequada. Para alcanar um padro de qualidade pelo menos aceitvel, necessrio tomar alguns cuidados em relao iluminao do ambiente. Destacamos algumas recomendaes: 11 Evitar fontes externas de iluminao: evite, sempre que possvel, salas com janelas, de modo a neutralizar fontes externas de iluminao; no sendo possvel, deve-se utilizar cortinas do tipo black-out, que eliminam essas fontes de luz; 11 Utilizar fontes homogneas de luz: a sala deve ser iluminada de forma homognea, utilizando-se, preferencialmente, lmpadas fluorescentes do tipo luz do dia. Para assegurar a homogeneidade da iluminao, evite misturas de fontes de iluminao, como lmpadas incandescentes e iluminao fluorescente; 11 Ter um ambiente uniforme pouco reflexivo: utilize mobilirio de cores claras para evitar sombras no rosto dos participantes; as paredes devem ser lisas, de cores uniformes e
sem superfcies muito refletoras. As cores recomendadas so: cinza, azul e verde (claros), creme ou branco-gelo, com acabamento em cores foscas; 11 aconselhvel que a intensidade luminosa em uma sala de videoconferncia esteja situada na faixa de 700 a 1.100 luxes (valor um pouco acima do estabelecido pela norma da ABNT para iluminao de escritrios).
Lux Medida da intensidade de luminosidade. A luminosidade de uma sala pode ser verificada com o uso de um luxmetro.
184
Figura 7.1 Exemplo de luminosidade em sala de videoconferncia.
Visibilidade
A visibilidade uma caracterstica que leva em considerao a disposio do mobilirio ergonmico na sala de videoconferncia. Por exemplo, para que todas as pessoas possam ver as imagens sem obstruo, os monitores devem ser colocados em posies adequadas, com o menor nmero de obstrues entre os participantes e eles. A posio adequada varia muito conforme o propsito da videoconferncia (ensino distncia, reunies remotas etc.) e conforme o formato da sala na qual ela est sendo realizada, mas os monitores normalmente so dispostos na altura da viso dos participantes. Outro cuidado com o posicionamento da cmera, que deve ser colocada acima do monitor principal, para que seu ngulo de viso possa focalizar, na sua totalidade, tanto os participantes quanto a plateia. Entretanto, deve haver o cuidado de no colocar o monitor principal a uma altura que, ao posicionar a cmera sobre ele, cause a impresso de que a imagem dos participantes esteja sendo capturada do alto, quando na realidade est sendo capturada de frente. Resumindo, os monitores devem estar localizados num local onde todos os participantes possam v-los sem obstrues; a cmera (ou cmeras) deve estar localizada neste mesmo local, de forma a capturar os participantes e/ou palestrantes de frente, de forma que aparente que eles esto olhando para a cmera, quando na verdade esto olhando para os monitores.
Cmera
Figura 7.2 Exemplos de posicionamento dos monitores e cmeras em uma videoconferncia.
A figura a seguir mostra um exemplo do estdio do Inmetro-RS, utilizado para ministrar aulas por videoconferncia. Pode-se observar o detalhe da janela de fundo, que uma janela falsa. Com criatividade, uma TV de plasma e uma iluminao artificial, possvel simular diversos ambientes diferentes, conforme a necessidade. A figura tambm mostra um exemplo de ambiente mais rstico, porm com linhas suaves e onduladas. O ambiente foi projetado para permitir diversas vises pela cmera.
185
Cmera
Figura 7.3 Exemplo de estdio no Inmetro/RS.
Acstica
A acstica da sala fundamental para a qualidade do udio, aspecto primordial para uma videoconferncia. O nvel de pode deve ser medido atravs do auxlio de um decibelmetro, procurando manter uma taxa que no influencie o andamento da conversao entre os participantes da videoconferncia. Alm de observar o nvel de rudo (que no uma atividade to trivial), pode-se lanar mo dos seguintes aspectos: absoro e refletividade, nveis de rudo do ambiente, efeito de reverberao (eco), tamanho da sala e sua geometria. Para diminuir os rudos, algumas alternativas so: 11 Observar a composio dos elementos da sala, evitando o uso de materiais refletores (vidro, gesso, madeira, cermica) que podem influenciar na acstica e, portanto, no so recomendveis; 11 Evitar mveis muito retos, que refletem som; 11 Utilizar cortinas; 11 Utilizar carpete; 11 Isolar a sala acusticamente. Recomenda-se que o nvel de rudo mximo admissvel em uma sala de videoconferncia no ultrapasse 50 dB-SPL (decibel). Essa medida deve ser tomada com o ambiente vazio, todos os equipamentos ligados e com o auxlio de um medidor (decibelmetro) posicionado no centro da sala. Vale lembrar que dB-SPL a medida do som emitido (l-se: decibel Sound Pressure Level).
Decibelmetro Sonmetro eletroacstico com escala de leitura em decibis. Instrumento utilizado para medio de decibis.
Climatizao
A climatizao da sala deve prover condies climticas e trmicas agradveis aos participantes da videoconferncia. Uma sala com climatizao apropriada fundamental tanto para o conforto das pessoas quanto para o bom funcionamento dos equipamentos, pois um local bem climatizado saudvel para as pessoas e prolonga a vida til dos equipamentos. Para climatizao da sala utilizando aparelhos de ar-condicionado tambm muito importante considerar o nvel de rudo dos aparelhos utilizados, pois aparelhos muito barulhentos podem prejudicar o andamento de uma videoconferncia, como foi visto no item Acstica.
186
Ambiente de udio
Qualidade do udio: 11 possvel realizar uma videoconferncia sem vdeo, mas sem udio invivel. Microfones podem ser de diversos tipos: 11 Unidirecionais ou multidirecionais. 11 Com fio ou sem fio. 11 De mo, de mesa, de lapela ou headset. 11 Individuais ou de grupo. Microfones com ou sem fio: 11 Com fio perde mobilidade, mas dispensa a preocupao com pilhas, sendo vlido quando as pessoas esto em um ponto fixo, como uma mesa. Microfones individuais (unidirecionais) ou de grupo (omnidirecionais). A qualidade do udio um elemento primordial em uma videoconferncia. Quando uma
videoconferncia apresenta certas dificuldades (falhas) no vdeo, ainda assim possvel que a conferncia continue em execuo apenas com udio. Se ocorrerem quaisquer falhas no udio, porm, a conferncia torna-se invivel. Ou seja, falhas de udio incomodam e prejudicam muito mais uma conferncia do que falhas de vdeo, o que mostra a importncia em manter uma qualidade de udio alta. A escolha dos microfones que sero usados uma tarefa muito importante para buscar qualidade no udio de uma videoconferncia. Existem diversos modelos disponveis, que devem ser escolhidos conforme o formato da videoconferncia (aula, palestra, reunio etc.), a quantidade de participantes, o ambiente de videoconferncia, entre outros fatores.
Tipos de microfones e suas caractersticas

Os microfones podem ser separados em diversas categorias. Podem ser individuais ou de grupos, unidirecionais ou omnidirecionais, com fio ou sem fio, microfones de mo ou de mesa, entre outros. Abaixo sero descritos os principais tipos de microfones, as suas caractersticas, vantagens e desvantagens.
Microfones de mo
modelos profissionais de alta qualidade at modelos mais simples, de menor custo. Exigem que o interlocutor fique segurando o microfone na mo, o que inibe sua liberdade. Pode-se tambm utilizar um suporte fixo para o microfone, o que prejudica a mobilidade do usurio. Um problema comum que com o tempo o usurio de um microfone de mo esquece que est com ele e comea a afast-lo ou aproxim-lo da boca, provocando alterao na intensidade do udio captado e causando incmodo para os ouvintes (podendo at impossibilitar o entendimento do que est sendo dito).
So os microfones mais conhecidos e por isso so facilmente encontrados no mercado, com
187
Esto disponveis em modelos unidirecionais e ominidirecionais, com fio e sem fio. Normalmente so utilizados em salas de aula ou auditrios.
Figura 7.4 Microfone de mo preso a um suporte.
Microfones tipo headset

So os mais indicados para auditrios e salas de aula, pois deixam as mos completamente livres e ainda mantm o microfone sempre mesma distncia da boca, eliminando o problema das mudanas de intensidade do udio. Para auditrios e salas de aula indicado o uso dos modelos profissionais, que so sem fio e normalmente mais discretos (inclusive sem fones de ouvido, apenas com o microfone e seu suporte). Para conferncias onde cada participante est no seu computador, como webconferncias, o ideal a utilizao de headsets que possuem tanto fones de ouvido quanto microfone, dispensando as caixas acsticas. Esses modelos so bastante comuns no varejo de informtica, e possuem um custo extremamente acessvel.
Figura 7.5 Headset (P91N Encore Monaural Polaris).
Microfones de lapela
So modelos bastante discretos que so fixados na altura do peito. Esse modelo de microfone bastante sensvel por causa da distncia que fica da boca. Normalmente so omnidirecionais para compensar os movimentos feitos com a cabea. Essas caractersticas propiciam microfonia ou a realimentao acstica em salas com caixas de som, e, portanto, no so indicados para salas de videoconferncia. Se forem utilizados, deve-se ter muito cuidado no ajuste do posicionamento e do volume das caixas de som em relao posio do usurio do microfone. Uma caracterstica positiva dos microfones de lapela que eles permitem maior liberdade ao usurio e costumam ser pequenos e leves, causando menor incmodo.
Figura 7.6 Microfone de lapela Sennheiser G3.
188
Microfones de mesa
Em um ambiente onde h um grupo no muito grande de pessoas ao redor de uma mesa, fazendo uma reunio por videoconferncia, possvel utilizar microfones de mesa omnidirecionais. Esses microfones capturam som de todas as direes, permitindo que todas as pessoas ao redor da mesa possam falar utilizando o mesmo microfone. Esse tipo de microfone prtico para ambientes com grupos de pessoas, mas deve-se ter cuidado ao utiliz-los, pois como eles capturam o som de todas as direes, so mais suscetveis a rudos.
Figura 7.7 Microfone de mesa Polycom 221523327-001 HDX.
H outro tipo de microfone omnidirecional de mesa que pode ser mais adequado para evitar rudos e sons indesejveis. Microfones como o do exemplo abaixo podem, por exemplo, ser distribudos para grupos de alunos (grupos pequenos, para facilitar o acesso ao microfone), e quando algum deles deseja interagir com o professor, ele habilita seu microfone e faz a pergunta. Apesar de ser um microfone omnidirecional, este tipo de microfone s estar habilitado enquanto a pessoa estiver falando, evitando rudos de forma mais eficaz que os microfones de mesa omnidirecionais. H inclusive microfones como o do exemplo e unidirecionais, porm so mais caros e mais difceis de encontrar.
Figura 7.8 Microfone de mesa omnidirecional udio Technica ATR4700.
Microfones com fio x microfones sem fio

Os microfones com fio so mais baratos e fceis de encontrar; no entanto, existem situaes em que o interlocutor precisa movimentar-se, como por exemplo um palestrante em um auditrio, ou quando se deseja passar o microfone para uma das pessoas da plateia. Nestas situaes um microfone sem fio elimina os problemas decorrentes do fio no ser comprido o suficiente ou do fio enroscar no mobilirio, por exemplo. Apesar do microfone sem fio ser mais verstil, mais caro que o modelo correspondente com fio e requer a utilizao de pilhas, que precisaro ser trocadas periodicamente. A autonomia das pilhas pode variar de 6 a 30 horas, dependendo do modelo. A conexo mesa de som feita atravs de uma base receptora que possui uma antena para receber o sinal do microfone sem fio. Quando for utilizado mais de um microfone sem fio, imprescindvel que eles operem em canais de transmisso (faixa de frequncia) diferentes, para que um no cause interferncia no outro. A maioria dos microfones sem fio vem ajustada de fbrica para operar em determinados canais, sem possibilidade de ajuste posterior. Portanto, no ato da compra necessrio verificar se os microfones funcionam em canais diferentes. A figura a seguir mostra a comparao entre vantagens e desvantagens dos modelos de microfones com e sem fio.
189
Com fio Vantagens 11Mais baratos. 11Fceis de encontrar. 11A maioria funciona sem pilhas. Desvantagens 11Fios enroscam no mobilirio.
Sem fio 11Maior mobilidade.
11Mobilidade limitada.
11Mais caros.
11Demandam troca de pilhas.
11Quando as pilhas enfraquecem podem ocorrer interferncias. 11Maior dificuldade de encontrar. 11Podem interferir com outros microfones sem fio (se funcionarem na mesma frequncia).
Diretividade em microfones
Os microfones possuem diferentes ngulos de captao, e so classificados como: 11 Omnidirecionais: capturam sons vindos de todas as direes. 11 Direcionais: capturam melhor sons vindos da frente e rejeitam sons emitidos nos lados e atrs. Os microfones omnidirecionais captam os sons em todas as direes e so indicados em casos onde diversas pessoas vo compartilhar um mesmo microfone. No entanto deve-se
Figura 7.9 Comparao entre modelos de microfones.
tomar cuidado com o posicionamento e o volume das caixas de som, pois existe a possibilidade de captar o som das caixas acsticas ou outros rudos da sala. Para reduzir a captao de sons indesejados, deve-se utilizar microfones direcionais, que possuem baixa sensibilidade para os sons vindos de trs. importante observar que h diferentes sub-classificaes dos microfones unidirecionais, que podem ser cardioide, super-cardioide e hiper-cardioide. Microfones dos dois ltimos tipos citados podem capturar um pouco do som ao lado e atrs do microfone, apesar de serem unidirecionais. Durante o uso, os microfones nunca devem ser direcionados para as caixas acsticas, mesmo que sejam unidirecionais, para que no ocorram microfonias ou reverberao. A figura abaixo mostra o posicionamento ideal de um microfone em relao s caixas acsticas.
Caixa acstica
rea de sensibilidade do microfone unidirecional
Figura 7.10 Microfone com rea de sensibilidade voltada para as ondas sonoras das caixas acsticas localizadas atrs dele.
Cuidados gerais no uso dos microfones

Independentemente do tipo ou da quantidade de microfones, importante orientar as pessoas no sentido de evitar conversas paralelas em ambientes de videoconferncia, pois isso pode influenciar na qualidade do udio gerado. Como vimos, ao abordar a acstica devemos evitar ao mximo rudos externos e internos. As pessoas e os equipamentos utilizados (ar-condicionado, computadores, projetores, componentes de iluminao) so as principais fontes geradoras de rudos internos. Esse fato pode se agravar, caso haja mais de um microfone aberto ao mesmo tempo no ambiente,
190
comprometendo a qualidade do udio da comunicao, e consequentemente podendo perturbar os participantes. Um cuidado necessrio manter ligado apenas o microfone do interlocutor ativo, o coordenador da sala responsvel pela concesso da palavra aos participantes e pela orientao quanto ao uso dos microfones. Quando um microfone no est sendo utilizado, aconselhvel mant-lo desligado, evitando rudos desnecessrios.
Microfonia
Tambm chamada de realimentao de udio, causada quando um microfone est capturando o udio de uma fonte emissora do som do prprio microfone. Como evitar: 11 Se no estiver falando, desligue o microfone. 11 Utilizar microfones direcionais colocados estrategicamente para no receber diretamente o udio das caixas acsticas. Em geral, a realimentao provoca um rudo agudo (alta frequncia) que amplificado a cada vez que o udio capturado pelo microfone emitido pelas caixas de som. A microfonia ocorre frequentemente em videoconferncias quando o microfone est muito
prximo dos alto-falantes que esto emitindo o som remoto. Existem cuidados que podem evitar o problema: 11 Ajustar o posicionamento das caixas de som e dos microfones; 11 Adequar o volume do microfone para que seja capturada apenas a voz da pessoa que est falando, evitando capturar outros rudos. O uso de microfones unidirecionais facilita a reduo da captura de rudos; 11 Utilizao de microfones com cancelamento de eco. O cancelamento de eco pode tambm ser feito pelo software/hardware utilizado para videoconferncia. O cancelamento de eco um mecanismo capaz de detectar que os sons que esto sendo capturados j foram capturados/transmitidos antes (chamados de eco), sendo capaz de suprimir esses sons, isto , remov-los do sinal como se no tivessem sido capturados, evitando a realimentao.
Caixas acsticas
11 Necessrias em ambientes com grupos de pessoas, devem ser posicionadas de preferncia na frente da sala, no alto e direcionadas para o fundo da sala. Deve-se ajustar o 11 A orientao dos participantes fundamental: 22 Evitar conversas paralelas em ambientes de videoconferncia. 22 Manter microfone desligado quando no estiver falando e no apontar para a caixa de som. 11 Adequar o ganho dos microfones para evitar microfonias e eco. Os fones de ouvido so adequados para conferncias pequenas ou quando houver apenas volume do som para evitar microfonias. Cuidados:
q
uma pessoa assistindo a conferncia em um determinado lugar. Em salas de videoconferncia ou auditrios deve-se utilizar caixas acsticas, que requerem alguns cuidados quanto ao uso. O volume das caixas acsticas deve ser ajustado para que o udio possua uma intensidade de uma conversao. Se o som estiver muito baixo, as pessoas mais afastadas podero no escutar corretamente; se estiver muito alto, alm do desconforto de quem estiver mais prximo, os microfones podero captar o som e causar microfonia ou realimentao.
191
Quando a sala for grande, pode ser necessrio utilizar mais caixas acsticas, para que a intensidade do udio seja equilibrada entre as pessoas que esto sentadas mais frente e as que esto mais no fundo.
Disposio das caixas acsticas na sala

Um aspecto que merece grande ateno o posicionamento das caixas acsticas. Elas devem ser direcionadas da frente (onde est a tela de projeo) para o fundo da sala. Quando as caixas acsticas so fixadas nas paredes ou no teto, garante-se uma melhoria na disperso acstica, podendo inclusive usar menos potncia de udio do que se estivessem no cho. Em ambientes em que os participantes tiverem acesso ao microfone, o cuidado deve ser maior ainda para evitar que o microfone seja levado para posies onde as caixas de som fiquem direcionadas para a frente dele.
Caixas acsticas
Caixas acsticas
Correto Projetor
Errado
Figura 7.11 Exemplo de bom posicionamento das caixas acsticas e direo do microfone.
Ambiente de vdeo
Os cuidados relacionados ao ambiente de vdeo em uma conferncia so necessrios tanto para a captura do vdeo (local) quanto para a exibio do(s) vdeo(s) remoto(s). A imagem transmitida deve permitir aos participantes da videoconferncia observar as aes e reaes dos participantes conectados remotamente. Quanto maior a qualidade das imagens, maior o realismo e, portanto, mais a videoconferncia se aproximar de uma conferncia onde os
participantes interagem localmente. Uma vez gerada a imagem, outro ponto importante a sua exibio. Neste aspecto, importante observar o tamanho dos monitores (ou qualquer outro dispositivo que exibir os vdeos) e seu posicionamento.
192
Figura 7.12 Dispositivos de exibio de vdeo.
O tamanho correto da tela do monitor determinado pela distncia entre ele e os principais participantes da videoconferncia. A regra geral que a altura do monitor seja equivalente a 1/8 da distncia entre a tela e os espectadores. Normalmente pensa-se que quanto maior o monitor melhor a qualidade e a experincia que ele trar videoconferncia. Isso muitas vezes verdade, mas deve-se ter cuidado com o uso de monitores muito grandes muito prximos aos participantes, onde seu tamanho pode acabar prejudicando a videoconferncia. Em relao ao posicionamento, os monitores devem estar em um local visvel a todos participantes, sem obstrues entre eles. Normalmente as cmeras so posicionadas junto aos monitores para que os participantes, ao olharem para os monitores, tambm estejam olhando para as cmeras, evitando a situao onde o participante parece (nos pontos remotos) no estar olhando para os participantes remotos, mas para outra posio qualquer (olhar disperso). A qualidade da imagem tambm afetada pelo processo de codificao de vdeo. Alm das caractersticas tcnicas que envolvem o processo, h cuidados que devem ser tomados no ambiente de videoconferncia para auxiliar a codificao e maximizar a qualidade do vdeo. Um desses cuidados eliminar interferncias de fundo de cena. Se um palestrante est falando, o contedo mais importante da cena obviamente o palestrante, e no os objetos ao fundo. Um fundo com poucos objetos, como uma simples parede lisa, auxilia a codificao do vdeo e tambm evita disperso de ateno dos participantes que esto assistindo ao vdeo. Outros cuidados so: evitar movimentos constantes ou bruscos, que tambm dificultam a codificao de vdeo, e escolher adequadamente as roupas utilizadas, pois, assim como um fundo com muitos objetos, h roupas que dificultam a codificao do vdeo e tambm
podem distrair a audincia. Deve ser dada preferncia a roupas de cores slidas.
Projeto de sala
Fatores que devem ser considerados: 11 Natureza da sala e pblico-alvo. 11 Mobilirio e equipamentos. 11 Pblico-alvo. 11 Infraestrutura e layout.
O projeto de uma sala de videoconferncia na maioria dos aspectos um projeto arquitetnico, ou seja, uma tarefa destinada a arquitetos e engenheiros. A funo do profissional de videoconferncia conhecer o que deve ser levado em conta nessa organizao estrutural da sala e a disposio adequada dos equipamentos. Portanto, a funo desta seo no abordar todos os detalhes de como projetar uma sala de videoconferncia, mas sim citar
193
os aspectos mais importantes que devem ser considerados durante o projeto com intuito de melhorar a qualidade da videoconferncia. Os principais fatores que devem ser considerados so: natureza da sala, pblico-alvo, mobilirio, equipamentos e layout.
Natureza da sala e pblico alvo

11 Dedicada x Multipropsito. 11 Aplicaes especiais. Pblico-alvo: 11 Alunos x Profissionais. 11 Crianas x Adultos.
Conhecer se a sala vai ser dedicada ou no, bem como a utilizao dela por outras pessoas, traz mais diretivas para a sua correta concepo. Em relao natureza da sala, deve-se saber ser dedicada para videoconferncias ou se ser uma sala multipropsito. Uma sala dedicada facilita o projeto, j que pode ser projetada especificamente para as necessidades de uma videoconferncia. J uma sala multipropsito, ou seja, que ser utilizada para outros fins alm de videoconferncias, traz maiores dificuldades para o projeto. Neste caso, deve-se conhecer os requisitos tanto da videoconferncia quanto os do outro propsito para o qual a sala utilizada e tentar concili-los. Em uma sala de aula que tambm ser utilizada para videoconferncias, por exemplo, deve-se projetar uma sala que acomode todos os equipamentos de videoconferncia e tambm o mobilirio de uma sala de aula normal, como classes, quadro, possivelmente computadores, entre outros. Descrever a natureza da sala especialmente importante quando ela utilizada para aplicaes especiais, onde pode haver outras exigncias que no esto relacionadas com a videoconferncia explicitamente. Hoje em dia, a videoconferncia est sendo utilizada cada vez mais em telemedicina, por exemplo. Nesse caso, equipamentos especficos para visualizao de exames mdicos tambm so requeridos e podem compor a sala. De certa forma, a mesma relao acontece com o pblico-alvo, ou seja, conhecer o perfil das pessoas que vo utilizar o sistema tambm pode significar maior qualidade no oferecimento do servio. Pense na diferena entre uma sala projetada para reunies entre executivos e uma sala de aula para crianas, por exemplo.
Mobilirio e equipamentos
Mobilirio: 11 Evitar utilizar mveis muito retos e reflexivos que prejudicam a acstica. 11 Cuidar para que os mveis no fiquem na frente dos participantes.
11 Utilizar mveis com cores slidas, pois facilitam a compresso de vdeo. 11 Manter o ambiente limpo, sem muitos objetos pequenos sobre os mveis, a fim de facilitar a compresso de vdeo. Equipamentos: 11 Monitores e cmeras de vdeo. 11 Microfones e caixas de som. 11 Cmeras de documentos. O mobilirio de uma sala de videoconferncia inclui, principalmente, a definio e o posicionamento das cadeiras, mesas e equipamentos necessrios para a videoconferncia.
194
A escolha do mobilirio , em grande parte, apenas uma tarefa arquitetnica. Mas importante observar os aspectos do mobilirio que influenciam as videoconferncias. Recomenda-se evitar mveis muito lisos ou fabricados com materiais refletores, como vidro, gesso, madeira, cermica, pois refletem o som e podem prejudicar a acstica da sala.
Figura 7.13 Tipos de cadeiras.
Cadeiras para plateia em auditrio
Cadeira tpica para a mesa do conferencista
Destaque para cadeira com apoio
Cadeiras tpicas para plateia
Figura 7.14 Tipos de mesas.
Figura 7.15 Posicionamento dos equipamentos.
195
Sobre o posicionamento dos equipamentos, j foi comentada a importncia de se manter os monitores junto s cmeras (para que os participantes estejam sempre olhando para as cmeras) e de posicionar adequadamente microfones e caixas de som para evitar microfonias. Esses so os fatores mais importantes que devem ser observados em todos os ambientes de videoconferncia, mas existem outros detalhes que variam conforme o propsito da videoconferncia e os equipamentos utilizados.
Figura 7.16 Exemplo de organizao do ambiente.
A quantidade de pessoas que participam da videoconferncia e o tamanho da sala so fatores que influenciam na escolha do mobilirio e equipamentos que sero utilizados. Em um cenrio hipottico de reunio onde 10 pessoas participam em uma mesma sala, obviamente necessrio que a mesa e as cadeiras sejam suficientes para 10 pessoas, mas tambm necessrio que os equipamentos escolhidos sejam adequados para essa quantidade de pessoas: a cmera (ou as cmeras) deve ser capaz de filmar todas as pessoas (e possivelmente possibilitar o foco em cada uma delas), o microfone deve ser capaz de capturar o som de todos (ou devem ser utilizados diversos microfones), e todos devem ser capazes de visualizar o vdeo remoto, que influencia na escolha do posicionamento e tamanho do telo/televiso.
Infraestrutura e layout
Infraestrutura: 11 Tomadas. 11 Pontos de rede wired/wireless. 11 Velocidade da conexo/qualidade da conexo. 11 Layout (disposio dos elementos no ambiente). Em relao infraestrutura, as necessidades em uma sala para videoconferncia basicamente so: a necessidade de tomadas de energia adicionais bem localizadas (incluindo
tomadas sobressalentes, caso haja a necessidade de mover equipamentos); pontos de rede adicionais, novamente considerando equipamentos que podem ser movidos e tambm a ligao de equipamentos adicionais (como notebooks de participantes), ou ento a disponi Administrao de Videoconferncia
bilizao de redes sem fio e, principalmente, uma infraestrutura de rede com boa qualidade e uma conexo de alta velocidade com os pontos remotos. O aspecto mais importante a qualidade e velocidade da estrutura e conexo de rede existente na sala. A qualidade da videoconferncia altamente dependente da qualidade da rede de dados. De nada adianta a utilizao dos equipamentos mais avanados de videoconferncia se a rede de dados no suficientemente boa para trfego de dados de videoconferncia. Caractersticas desejadas: 11 Largura de banda um pouco acima da utilizada na videoconferncia (uma videoconferncia a 380 kbit/s no funcionar bem em uma rede com apenas 380 kbit/s; aconselhvel que a rede seja pelo menos 20% mais veloz para acomodar as flutuaes comuns no trfego multimdia);
196
11 Baixa variao no atraso dos pacotes (jitter); 11 Estabilidade e confiabilidade, isto , uma rede que funcione sem interrupes; 11 Se possvel, que seja uma rede dedicada para a videoconferncia, evitando que picos de trfegos concorrentes prejudiquem a qualidade da videoconferncia.
Preparao de uma videoconferncia

tarefa do administrador de videoconferncia: 11 Realizar toda a preparao necessria para a videoconferncia. 11 Instruir os participantes sobre como devem se comportar. 11 Gerar as orientaes para conduzir uma videoconferncia. Quatro etapas so importantes na preparao da videoconferncia: 11 Pr-conferncia. 11 Agendamento. 11 Incio e trmino. 11 Gerenciamento.
Os procedimentos de operao de uma sala de videoconferncia so orientaes para a conduo do processo. importante para o profissional de videoconferncia passar esse tipo de informao para seus clientes atravs de conversas ou manuais e contratos, caso necessrio. A maioria das pessoas que no possuem experincia com videoconferncias (e muitas vezes at mesmo pessoas j com experincia) tendem a se comportar de forma inadequada ao participar de uma videoconferncia. Por vezes, os participantes esquecem que no esto na mesma sala dos participantes remotos, e com isso no prestam ateno na forma como falam ao microfone ou ao posicionamento diante da cmera. Por outro lado, os participantes podem acabar ignorando a presena dos participantes remotos, como por exemplo no caso de alunos conversando paralelamente em sala de aula em que o professor esteja em um ponto remoto. Videoconferncias necessitam de cuidados especiais para que a comunicao ocorra de forma efetiva. tarefa do administrador da videoconferncia instruir os participantes sobre como devem se comportar e realizar toda a preparao para que a videoconferncia acontea de forma satisfatria.
Pr-conferncia
Etapa que antecede a videoconferncia, em que deve ser configurado e preparado o sistema que ser utilizado. Durante essa etapa, determina-se os participantes envolvidos, seus pontos de acesso, o coordenador da sesso (caso exista) e informaes de controle de acesso. preciso identificar as condies para a realizao da videoconferncia, e prever a disponibilidade de banda de cada participante. Nessa etapa todas as informaes relativas videoconferncia so definidas e descritas.
Etapa que antecede a videoconferncia, em que deve ser configurado e preparado o sistema que ser utilizado. nessa etapa que todas as informaes relativas videoconferncia so definidas e descritas, para que, a partir deste momento, a videoconferncia possa ser facilmente agendada e realizada.
197
Agendamento
Muito importante em videoconferncias para permitir que haja tempo suficiente para preparao do ambiente de videoconferncia. possvel: 11 Definir data e horrio. 11 Prever a disponibilidade das localidades e dos equipamentos. 11 Definir a equipe de operao. 11 Usar sistemas de agendamento via web. Assim como uma reunio, aula e atividades similares, uma videoconferncia precisa ser agendada. O agendamento ainda mais importante em uma videoconferncia do que em atividades presenciais, para que haja tempo suficiente para preparao do ambiente
de videoconferncia. Alm da definio de data e hora, no agendamento o usurio define (ou toma conhecimento) das condies para a realizao da videoconferncia. Entre os aspectos importantes no agendamento, esto: 11 Definir a equipe de operao, se necessria; 11 Prever a disponibilidade da localidade e dos equipamentos (equipamentos da prpria sala de videoconferncia ou equipamentos externos, como a MCU). comum o uso de sistemas de agendamento via web (internet ou intranet), sistemas que atualmente j agrupam todas as tarefas necessrias para o agendamento, inclusive notificam os participantes sobre a videoconferncia.
Incio e trmino da videoconferncia

Incio da videoconferncia: 11 Marcada pela data e horrio definidos na pr-conferncia e aberta assim que a conexo est estabelecida e o primeiro participante entra na sala. Trmino da videoconferncia: 11 Demarcado pela sada do ltimo participante da sala (virtual ou real) ou ento quando o tempo previsto se esgotar. 11 Quando um participante abandona uma sala, os demais participantes devem ser notificados da sua sada. O perodo entre o incio e o trmino da videoconferncia obviamente o perodo crtico
durante o qual ocorre a videoconferncia. A videoconferncia s ocorrer de forma devida se os processos durante a pr-conferncia foram realizados de forma correta. O incio da videoconferncia marcado pela data e horrio definidos, e ela aberta assim que a conexo se estabelece e o primeiro participante entra na sala.
O trmino da videoconferncia demarcado pela sada do ltimo participante da sala (virtual ou real) ou quando o tempo previsto se esgotar. Quando um participante abandona uma sala, os demais participantes devem ser notificados da sua sada.
Gerenciamento
Tarefa do administrador da videoconferncia ou de um participante eleito como coordenador/moderador. O moderador da sala virtual pode: 11 Autorizar novos participantes na sala. 11 Bloquear o udio de algum participante.
198
11 Mudar o layout de vdeo. 11 Excluir participantes. O gerenciamento da videoconferncia feito pelo administrador ou por um participante eleito como coordenador/moderador da sesso.
Etiqueta e boas prticas

Ao preparar um ambiente para uma videoconferncia importante adotar e evitar alguns procedimentos de boas prticas. Em ambiente de videoconferncia, adote:
11 Se voc moderador, chegue mais cedo para testar a configurao do sistema, evitando perda de tempo durante o perodo destinado conferncia. 11 importante falar um de cada vez, para no interromper os outros e no mudar o foco da tela. 11 Desative o microfone quando no estiver falando, para evitar mudanas de tela desnecessrias e impedir a captao de rudos indesejados. 11 Fale com voz alta e clara. 11 Espere o dobro do tempo habitual aps perguntas e comentrios, a fim de dar tempo para que sua fala chegue aos alunos. 11 Repita comentrios, se necessrio. 11 Mantenha uma posio apropriada diante da cmera. 11 Mantenha o contato visual com a lente da cmera e, caso existam, com os participantes locais. 11 Lembre-se de que os participantes remotos esto lhe vendo e preste ateno em como todos iro v-lo. Coloque os participantes dentro do campo de viso da cmera. 11 Vista roupas de preferncias de cores slidas ou padres escuros ou neutros. 11 Tenha em mente que sua audincia deve ter o foco em voc e no na sua roupa. 11 Prefira usar roupas, maquiagem e cabelos do modo mais simples possvel. No mximo tenha em mos um p translcido para tirar o brilho do nariz e das tmporas. A melhor opo por um visual natural e relaxado.
199
(b)
(a)
Figura 7.17 Adote fundos lisos, para evitar distraes e colaborar com a codificao.
Em aulas remotas, adote: 11 O professor deve dirigir-se aos participantes remotos pelo nome e lugar onde esto; para tanto, indicado preparar uma lista e um mapa dos assentos. 11 Comece as aulas com uma introduo informal, falando com todos os alunos de modo a iniciar o teste do udio deles e o seu prprio. 11 O professor precisa se posicionar para a cmera, buscando estar sempre bem iluminado e enquadrado, nunca caindo da tela nem cortando partes de seu corpo, exatamente como na televiso. Em ambiente de videoconferncia, evite: 11 Uma vez que tudo esteja pronto, evite a distrao de fazer ajustes e perturbar os outros com perguntas do tipo: Voc est me ouvindo? 11 Vozes que interrompem bruscamente so desagradveis. 11 Produzir barulho que possa perturbar a reunio (conversas paralelas, barulho com dedos, canetas etc.), pois a cmera e os microfones so muito sensveis e capazes de captar os sons mais sutis.
11 Diminuir o volume da voz no final da fala. 11 Comear a falar antes de ser focalizado pela cmera. 11 Erros gramaticais, grias e vcios de linguagem. 11 Usar jargo tcnico quando o assunto no for do escopo da reunio (plateia no especializada ou pblico leigo). 11 Falar sem uma preparao prvia. 11 Falar muito depressa ou muito devagar. 11 Movimentos rpidos e/ou largos que causem distoro na tela. Evite movimentao desnecessria para preservar a qualidade da imagem.
200
11 Expresses faciais inadequadas. Use o zoom, mas no se aproxime demais da cmera. 11 Ficar esttico ou andar nervosamente de um lado para o outro. 11 Fumar, mascar chicletes, chupar balas, brincar com objetos (chaveiros, canetas). 11 Vestir-se inadequadamente. 11 Vestir roupas totalmente pretas, ou com listras finas, de cores berrantes ou com estampas contrastantes. Evite o tweed, riscas ou outros padres muito pequenos. 11 Usar joias, colares ou braceletes grandes, pois podem bater no microfone e causar rudos estranhos. 11 Distraes visuais como maquiagem inapropriada, fundos carregados, padres complicados ou cores fortes. Evite o vermelho, cores brilhantes ou saturadas. 11 Microfones de lapela no so indicados com suteres e camisetas.
Estudo de caso 1: Auditrio

Neste estudo de caso e nos posteriores, sero dadas sugestes sobre como deve ser um ambiente de videoconferncia em relao aos seguintes aspectos: 11 Natureza da sala: nmero de pessoas e propsito de utilizao. 11 Pblico-alvo. 11 Mobilirio: moblia ergonmica. 11 Equipamentos: de udio, vdeo, videoconferncia e adicionais. 11 Layout: rea e disposio. No primeiro estudo de caso, sero apresentadas sugestes sobre como deve ser um auditrio no qual palestras e aulas sero transmitidas por videoconferncia. A seguir so abordados brevemente estes aspectos, e mais adiante sero detalhados alguns pontos importantes. 11 Natureza da sala: 60 pessoas, uso para videoconferncias. 11 Pblico-alvo: especialistas. 11 Mobilirio: mesas e cadeiras ergonmicas apropriadas. 11 Equipamentos: 22 udio: microfone unidirecional no palestrante (pode ser de lapela) e outro sem fio para perguntas.
22 Vdeo: projetores. 22 Videoconferncia: hardware especfico para sala ligado na mesa de som e compatvel com a conectividade disponvel. 22 Adicionais: cmeras auxiliares para troca de imagem (sistema de videoconferncia deve permitir mltiplas cmeras). 11 Layout: rea: ~ 120 m
Figura 7.18 Auditrio para videoconferncia.
201
O ambiente deve apresentar paredes dotadas de materiais isoladores acsticos, com o objetivo de minimizar a influncia de rudos externos no seu interior. O piso deve ser em carpete, e devem ser utilizados materiais isolantes para as paredes (l de rocha, l de vidro) e materiais antireverberao (placas de espuma acstica perfilada) e cortinas de tecido denso nas janelas. A rea da sala deve respeitar os critrios de acesso e proximidade. Geralmente estimada em um metro quadrado por ocupante da sala. A refrigerao da sala deve ser adequada, possibilitando um controle de umidade e constante renovao do ar. Tambm necessrio que existam tomadas e pontos de rede suficientes, e, se necessrio, acesso a redes sem fio. A intensidade luminosa total do ambiente deve ser de aproximadamente mil luxes com todas as luzes ligadas. No momento da projeo pode-se utilizar uma iluminao indireta para melhorar a visualizao da videoconferncia. As luminrias devero ser do tipo embutidas, em forro modular feito de placas de fibra mineral com propriedades trmicas e acsticas. O auditrio deve possuir um microfone unidirecional para cada apresentador da mesa e do plpito, alm de dois microfones multidirecionais estrategicamente localizados no incio das filas de cadeiras (plateia) e ao fundo do auditrio. Opcionalmente, podemos ter alguns microfones sem fio disponveis na plateia. O udio do ambiente deve ser provido por caixas de som embutidas no forro ou fixadas por suportes apropriados, ligadas mesa de som e dispostas uniformemente, de modo a oferecer aos palestrantes e plateia uma boa qualidade de som, sem realimentaes que provoquem microfonias. Monitor principal xado ao teto 38 PC de apoio Monitor de retorno xado ao teto 38
Cmera de documentos Mesa de udio e vdeo Principal aparelho de videoconferncia Plpito Telefone/Fax
Quadro Tela eltrica de projeo
Projetor multimdia
Degraus
Monitor de retorno xado ao teto 38
Cmera auxiliar
Monitor principal xado ao teto 38
Figura 7.19 Exemplo da planta de um auditrio para videoconferncia.
202
Estudo de caso 2: Sala de reunio

No segundo estudo de caso, ser avaliado um ambiente para salas de reunies com videoconferncia. 11 Natureza da sala: mximo de 10 pessoas; sala de aula/multipropsito. 11 Pblico-alvo: empresarial com diferentes perfis de pessoas. 11 Mobilirio: mesas e cadeiras apropriadas (verificar questes de acessibilidade, j que perfis diferentes usaro a sala). 11 Equipamentos: 22 udio: um microfone multidirecional; 22 Vdeo: TV de 32 ou projetor; 22 Videoconferncia: hardware especfico compatvel com conectividade disponvel; 22 Adicionais: quadro branco eletrnico e recurso para compartilhar dados do notebook. 11 Layout: rea: ~ 28 m
Figura 7.20 Imagem de exemplo de uma sala de reunies com videoconferncia.
203
Quadro interativo
TV
Tela para projeo
Tablado Equipamento de videoconferncia
Projetor
Cmera de documentos
Estudo de caso 3: Uso geral

O terceiro estudo de caso aborda uma sala de propsito geral, onde podem ser realizadas videoconferncias para reunies, aulas e palestras, entre outros. 11 Natureza da sala: 20 a 35 pessoas (sala de aula/multipropsito). 11 Pblico-alvo: estudantes, profissionais etc. 11 Mobilirio: mesas e cadeiras apropriadas. 11 Equipamentos: 22 udio: dois ou vrios multidirecionais; 22 Vdeo: TV de 42 ou projetor;
Figura 7.21 Esboo da planta de uma sala de reunies com videoconferncia.
22 Videoconferncia: hardware especfico compatvel com a conectividade disponvel; 22 Adicionais: cmera auxiliar, computador, cmera de documentos.
204
11 Layout: rea: ~ 54 m .
Figura 7.22 Sala de videoconferncia de propsito geral.
Tela eltrica de projeo TV 54 Equipamento de videoconferncia PC Cmera de documentos Telefone/Fax
Quadro branco
Tablado com 10 cm
Projetor multimdia
Cadeira com apoio para escrita
Circulao
Parede ou divisria acstica
Figura 7.23 Esboo da planta de uma sala de videoconferncia de propsito geral.
Piso com elevao de 0,5 cm
Cortina
Janela
Estudo de caso 4: Projeto da sala da ESR-RS

Este estudo de caso mostra o projeto de adaptao da sala de aula da ESR em Porto Alegre, que originalmente era uma sala de aula padro da ESR e foi transformada em uma sala de videoconferncia para transmisso das aulas ministradas nela para outras salas de aula da Escola Superior de Redes de outros estados. Este trabalho foi realizado no mbito do projeto Turmas Distribudas.
205
O projeto considerou diversos fatores, entre eles: 11 Adequao esttica geral; 11 Organizao do espao; 11 Ajuste cnico para vdeo; 11 Iluminao; 11 Acstica; 11 Planos de cmera/operao; 11 Sonorizao. A sala de aula original possua diversas caractersticas prejudiciais videoconferncia, entre elas: 11 Sala branca de perfil frio; 11 rea de trabalho dos alunos sem otimizao de espao; 11 Paleta: branco, preto e creme; 11 Iluminao fria (lmpadas fluorescentes) e plana; 11 Grande janela esquerda com cortina blackout; 11 Painis de Eucatex com perfis aparentes (desalinhados); 11 P direito baixo.
Figura 7.24 Mesas e mquinas dos alunos e janela com cortina blackout.
206
Figura 7.25 Entrada da sala de aula mostrando um pedao do quadro branco e divisria.
A proposta geral de modificaes da sala tem como principais mudanas: 11 Inverte posio da sala (porta passa a ficar no fundo da sala); 11 Frente ganha pintura dgrad, em tons mais vivos; 11 Troca dos aparelhos de ar-condicionado por modelos mais silenciosos; 11 Parte do teto mantida branca, para reduzir a sensao de teto baixo; 11 Paredes e parte do teto com isolamento acstico. recomendado deslocar os computadores para baixo da mesa e trocar para monitores maiores, de preferncia com ajuste de altura.
Figura 7.26 Proposta geral para reforma da sala.
Na sequncia sero descritos separadamente os itens mais importantes do projeto.
Acstica
Antes: 11 reas reflexivas em todas as paredes. 11 Nenhum trabalho de correo acstica (mesmo cortina blackout tem perfil reflexivo). 11 Caractersticas de ambincia (soma de todos os sons nesse ambiente) so desfavorveis para o sistema. 11 Ar-condicionado com rudo excessivo.
207
Depois: 11 Troca dos aparelhos de ar-condicionado. 11 Painis Sonare (Isover) passam a revestir as paredes, lateral direita e fundo. 11 Teto revestido com isolamento acstico e trmico (sobre o forro). Resultados: 11 Reduo imediata da reflexo em duas paredes (supresso da reverberao). 11 Melhora da ambincia. 11 Melhorias no isolamento acstico e trmico. 11 Ganhos nos resultados acsticos (reduo da reflexo nas frequncias mais altas gera som mais encorpado, com agudos mais limpos). 11 Melhorias estticas no ambiente.
Figura 7.27 Painis nas paredes melhoram a acstica da sala.
Planos de cmera/operao
11 Ambiente de operao frente e esquerda, concentrando as mquinas necessrias para o sistema de videoconferncia. 11 Telepresena televises posicionadas ao lado do professor ou no fundo da sala.
Cmera robotizada 1
11 Principal foco no apresentador e sua rea de trabalho. 11 Enquadramento tem bom acesso visualizao da rea frontal. 11 Fcil acesso visualizao do quadro branco e da lousa eletrnica. 11 Posicionamento permite bom alcance de zoom. 11 ngulo da cmera permite captar quadro branco sem incidncia de reflexos.
Figura 7.28 Ambiente de operao do sistema de videoconferncia e televises para telepresena.
208
Figura 7.29 Primeira cmera robotizada com foco no professor e no quadro branco.
Cmera robotizada 2
11 Posicionamento voltado aos alunos. 11 Foco secundrio no apresentador, podendo funcionar como cmera de apoio, quando o apresentador est no meio da sala, por exemplo. 11 Fcil visualizao de todo o ambiente presencial (alunos). 11 Uso das 6 posies de preset permite fcil enquadramento de qualquer grupo de alunos, pressionando uma nica tecla.
Figura 7.30 Segunda cmera robotizada com foco nos alunos.
Sonorizao
11 Combinao de microfones sem fio (headset e de mo). 11 Mesa de som. 11 Caixas acsticas: 22 Cobertura dos sinais de entrada. 22 Reproduo de sinais remotos aos participantes presenciais.
ticas, faz cobertura dos sinais de entrada e reproduo de sinais remotos aos participantes presenciais. Microfone sem fio para o professor e de mo para os alunos.
Figura 7.31 Microfones e posicionamento das caixas acsticas.
209
A combinao de microfones sem fio (headset e de mo) com mesa de som e caixas acs-
Imagens da sala nova

A viso frontal da sala pode ser vista a seguir.
Figura 7.32 Mobilirio (posicionamento dos equipamentos).
A imagem a seguir mostra a viso do fundo, com as TVs, o novo ar-condicionado e o posicionamento da cmera.
210
Figura 7.33 Viso do fundo da sala.
Atividade 1 Anlise de cenrios e elaborao do projeto das salas
Esta atividade consiste na anlise de diferentes cenrios onde necessrio o uso de videoconferncia e na elaborao de projetos de salas que possam ser utilizadas nos ambientes apresentados em cada cenrio. Sero apresentados 3 cenrios.
Cenrio 1
Uma empresa multinacional est implantando um sistema de videoconferncia para auxiliar na tomada de decises entre gerentes e funcionrios de suas unidades. So realizadas aproximadamente 10 reunies semanais entre os gerentes das 3 unidades e entre gerentes com seus coordenadores. As reunies contam com aproximadamente 2 pessoas de cada unidade, num mximo de 6 pessoas por reunio. Um dos requisitos da empresa efetuar a integrao de documentos no digitais; outro requisito a possibilidade de enviar apresentaes de slides em formato digital.
Cenrio 2
Uma escola particular est instalando um servio indito para promover o compartilhamento de conhecimento. O convnio assinado pela escola com uma comunidade carente da periferia prev uma sala de videoconferncia como meio de incluso digital. As crianas da comunidade tero acesso a aulas, palestras e atividades de entretenimento com as crianas da escola. A ideia compartilhar conhecimento e experincias entre crianas com idade entre 6 e 9 anos.
Cenrio 3
Uma escola deseja reformar uma sala de aula convencional para abrigar equipamentos de um sistema de videoconferncia. A sala possui um projetor multimdia, 50 cadeiras com apoio, uma TV de 29 polegadas e janelas laterais, estando localizada no lado de maior circulao da escola. Possui cabeamento e ar-condicionado, j tendo sido utilizada para abrigar um laboratrio de informtica. A escola atende ao ensino fundamental e deve disponibilizar o servio de videoconferncia para todos os alunos, com agendamento prvio.
Cenrio 4
Um grande hospital-escola na rea de cirurgia tem como objetivo trocar informaes com dois outros hospitais parceiros. Os trs hospitais possuem residncia mdica. Existem duas necessidades principais:
11 Um mdico especialista transmitir sua cirurgia em alta definio para os outros hospitais (incluindo udio) para que mdicos e alunos remotos possam aprender sua tcnica. Nesse caso, h a necessidade de interao com udio e vdeo em tempo real; 11 Possibilitar que um preceptor especialista em qualquer um dos hospitais possa orientar um cirurgio residente remotamente; para isso ele deve ter acesso completo a trs cmeras de alta definio no mnimo (videolaparoscpio, corpo do paciente e ambiente da sala cirrgica). Alm disso, ele deve transmitir sua imagem. Os hospitais esto locali-
211
zados em diferentes estados do pas, embora ligados atravs de um backbone de redes que permite velocidades de at 100Mbit/s.
Cenrio 5
Um grupo de mdicos localizados em diferentes reas com banda 3G (de aproximadamente 300 kbit/s) formou um grupo de trabalho sobre sua especialidade. Eles precisam se comunicar a partir de seus escritrios de forma simples, em reunies que consistem basicamente da transmisso de vdeo e udio de todos, compartilhamento de bloco de notas e apresentao de slides e vdeos.
212
8
Transmisso via streaming
objetivos
Oferecer ao aluno uma viso ampla sobre os conceitos e tecnologias empregados para streaming e gravao de videoconferncia.
conceitos
Streaming de vdeo versus download progressivo, solues de transmisso e gravao de videoconferncia, banda na rede ocupada de acordo com o nmero de usurios, necessidade de armazenamento de acordo com a qualidade da gravao.
Streaming de vdeo
11 Streaming uma forma de transmisso de dados multimdia, em que os clientes realizam uma solicitao dos dados para um servidor de streaming, e os dados so exibidos medida que so recebidos. Pode ser aplicado para transmisses ao vivo ou para mdias gravadas. Transmisses de televiso e rdio so exemplos de transmisses de mdia por streaming broadcast. A combinao do streaming com videoconferncia pode ser feita para: 11 Disponibilizar a videoconferncia para um maior nmero de pessoas. 11 Transmitir a videoconferncia aps ela ter acontecido, a partir de gravao. 11 Visualizar uma videoconferncia a partir do desktop utilizando players padro como Windows Media, QuickTime ou navegador web. 11 Facilitar a gravao: um dispositivo (ou software) recebe a videoconferncia por streaming e realiza a gravao. A grande desvantagem do streaming em videoconferncias a interao, pois um participante por streaming no pode interagir ao vivo na videoconferncia, porque a entrega participao desses clientes por salas de chat ou por e-mail, por exemplo. das mdias ocorre em apenas uma via. possvel amenizar o problema permitindo a
Transmisses por streaming so normalmente associadas a transmisses ao vivo, onde no h possibilidade de pausar o vdeo e continuar assistindo-o do ponto onde foi pausado. Porm, tambm pode ser utilizado para transmisso de mdias j gravadas. Uma pausa em uma transmisso por streaming faz com que o servidor pare de transmitir dados para o cliente, o contrrio do que acontece com transmisses utilizando download progressivo, conforme ser visto adiante. Outra caracterstica importante do streaming que ele permite a adaptao da dinmica da qualidade da transmisso conforme a capacidade dos clientes. Ou seja, se um cliente est recebendo vdeo com uma qualidade alta, por exemplo, e comea a acusar perda de dados
213
Captulo 8 - Transmisso via streaming
na transmisso, a prpria transmisso detecta essas perdas e faz com que a qualidade do vdeo seja reduzida para evitar as perdas. Para isso, o servidor obviamente deve suportar a adaptao dinmica da qualidade. Transmisses de televiso e rdio so exemplos de transmisses de mdia por streaming (e broadcast). A combinao do streaming com videoconferncia pode ser realizada para diversos propsitos. O principal propsito disponibilizar a videoconferncia para um maior nmero de pessoas. Transmisses por streaming so naturalmente mais escalveis do que os prprios sistemas de videoconferncia, ou seja, mais otimizado que diversos clientes recebam a videoconferncia por streaming do que permitir que se conectem diretamente ao sistema de videoconferncia. Alm disso, transmisses por streaming utilizam protocolos padro, e podem ser visualizadas em diversos aplicativos (players de vdeo), como Real, Windows Media, QuickTime ou mesmo o navegador web. O streaming tambm pode ser utilizado para transmitir a videoconferncia aps sua ocorrncia (a partir de uma gravao) ou at mesmo para facilitar a gravao: um dispositivo recebe a videoconferncia por streaming e realiza a gravao. Streaming pode aumentar a utilidade de uma videoconferncia, se a audincia da reunio for maior que o nmero de conexes simultneas suportadas pelo sistema utilizado. Nesse caso, participam interativamente apenas as pessoas principais da videoconferncia; os demais podem acompanhar a reunio recebendo o fluxo de mdias em um player. A grande desvantagem do streaming em videoconferncias em relao interao entre os participantes. Um participante por streaming no pode interagir ao vivo na videoconferncia, pois a entrega das mdias ocorre em apenas uma via (s recebe dados, sem enviar). possvel amenizar este problema permitindo a participao dos clientes em salas de chat ou por e-mail.
Streaming x Download progressivo

Debate sobre vantagens e desvantagens de ambos: 11 Qual ocupa mais espao em disco? 11 Qual permite analisar novamente partes j assistidas? 11 Qual possui a melhor qualidade de udio e vdeo?
Streaming e download progressivo so duas formas utilizadas para transferncia de udio e vdeo. O download progressivo uma forma de transmisso que se assemelha a um download tradicional, porm os dados de udio e vdeo so transferidos progressivamente para o computador, permitindo que se possa visualizar o contedo j recebido mesmo que ainda no tenha recebido todos os dados. Apesar de diferentes, o download progressivo e o streaming possuem muito em comum.
As particularidades das aplicaes do cliente tambm influenciam na diferenciao entre streaming e download progressivo. Uma aplicao de streaming pode, por exemplo, armazenar o vdeo e permitir que o usurio navegue nos dados recebidos, o que conceitualmente s pode ser feito com download progressivo.
214
A tabela a seguir compara os principais aspectos das duas tecnologias: Streaming Armazena vdeo temporariamente no cliente No* (mas o software cliente pode armazenar) No** (solicita de novo o streaming ao servidor via outro ponto do vdeo) Sim Sim Sim No Sim No No No Sim No Sim Download progressivo Sim
Permite voltar para determinado ponto do vdeo
Pausa e interrompe a transmisso Pode mudar a qualidade dinamicamente, se adaptando rede

Figura 8.1 Principais aspectos de streaming e download progressivo.
Adequado para eventos ao vivo Adequado para podcast Permite multicast
Tanto multicast quanto unicast podem ser utilizados para streaming de contedo multimdia. As diferenas entre eles j foram discutidas. Os principais aspectos que devem ser considerados na escolha da tecnologia mais adequada esto na tabela seguinte. Caracterstica Transmisso ao vivo
Figura 8.2 Principais aspectos do unicast e multicast.
Unicast
Multicast
Transmisso sob demanda Permite escalabilidade (banda requerida se mantm com o nmero de usurios)
Solues para transmisso e gravao

Existem solues em hardware e em software. Solues em hardware costumam ser especficas para videoconferncia. J solues baseadas em software so mais genricas, pois so solues para streaming e gravao de dados multimdia. As solues em hardware incluem uma interface H.323/SIP para interagir diretamente com a
videoconferncia e outras interfaces para servir os dados por streaming. O dispositivo funciona removendo o vdeo e o udio do pacote H.323/SIP, e os empacotando novamente no formato streaming configurado, como QuickTime, Real ou Windows Media. Esses dados so enviados
aos usurios que solicitam uma transmisso streaming, utilizando unicast ou multicast. Alguns dispositivos podem tambm gravar esses dados, podendo depois fornecer acesso sob demanda ao contedo. Alm disso, alguns modelos suportam inclusive a transmisso e gravao de mais de uma sesso de videoconferncia ao mesmo tempo. As solues em hardware so referenciadas tambm como all-in-one devices ou VideoConference Recorder (VCR). H diversos dispositivos em hardware disponveis no mercado para streaming e/ou gravao de videoconferncias. Abaixo so citados alguns modelos, mas o ideal conferir com os fabricantes os ltimos lanamentos.
215
Modelos que suportam apenas transmisso de videoconferncia: 11 MCUs VCON VCB, Codian (sries 4200 e 4500); 11 Endpoints Polycom VSX, Tandberg 880 e 990 MXP (somente multicast).
Figura 8.3 Modelos em hardware que suportam apenas transmisso de videoconferncia.
Modelos que suportam transmisso e gravao: 11 Starbak VCG Creation / Starbak Encoder; 11 MCU Codian MSE8000; 11 Codian VCR srie 2200; 11 Tandberg Content Server.
Figura 8.4 Modelos em hardware que suportam transmisso e gravao de videoconferncia.
H empresas que disponibilizam dispositivos de transmisso e gravao juntamente com um conjunto mais completo de equipamentos, fornecendo uma soluo completa para videoconferncia. Um exemplo a famlia de produtos Integrated Network Video (INV) da Starbak. O objetivo dos equipamentos integrar de forma fcil os diversos sistemas multimdia que uma instituio pode ter: videoconferncia, streaming, televiso por IP, entre outros. J as solues baseadas em software normalmente so mais genricas, voltadas para streaming e gravao de dados multimdia em geral, podendo tambm ser utilizadas para os dados de uma videoconferncia.
Solues baseadas em software

No lugar de um dispositivo de hardware dedicado, utilizada uma aplicao que pode ser instalada em um computador desktop tradicional. O desempenho da aplicao fica, obviamente, dependente do desempenho da mquina na qual est instalada. Essas solues normalmente so compostas por dois softwares distintos utilizados em conjunto: 11 Encoder: entidade que captura os dados, codifica e os envia para o servidor. 11 Servidor: responsvel pela distribuio e gravao dos dados que recebe do encoder.
216
Solues hbridas (soluo em software que recebe sinal de um HW de videoconferncia): 11 Necessidade de alguma forma de conexo do software videoconferncia. 22 A sada de A/V de um terminal de videoconferncia pode ser conectada a uma entrada da mquina onde a soluo est instalada (como se fosse uma cmera de vdeo) A visualizao do fluxo de mdias pelos usurios realizada atravs de um player padro compatvel com o protocolo de streaming utilizado. Players como Windows Media Player e
VideoLAN (VLC) suportam e podem exibir diversos formatos de streaming. Alm do streaming, na maioria dos softwares o contedo tambm pode ser gravado e disponibilizado para acesso sob demanda. Exemplos de solues baseadas em software: 11 Windows Media Server/Windows Media Encoder; 11 Helix Server/Real Producer; 11 Flash Server/Flash Encoder; 11 QuickTime; 11 VideoLAN (VLC); 11 xConference: comercializado com duas placas de captura e computador: 11 o cliente j recebe o computador com os recursos instalados e configurados. Existem tambm solues hbridas, onde desejvel transmitir via software uma videoconferncia H.323 executada em hardware. Como est sendo utilizada uma mquina convencional para a instalao do software, normalmente no h uma interface H.323/SIP pronta para receber os dados de uma videoconferncia e repass-los para a aplicao. Portanto, necessrio fazer com que, de alguma forma, os dados de uma videoconferncia cheguem at a aplicao para streaming e gravao. Com a existncia de um dispositivo de videoconferncia, sua sada de udio e vdeo pode ser conectada a uma entrada da mquina onde a soluo est instalada (a uma placa de
Figura 8.5 Integrao de servidores de streaming em uma videoconferncia.
captura, por exemplo, como se fosse uma cmera de vdeo). Com isso possvel indicar ao Encoder que obtenha os dados desta entrada e os envie para o servidor. A imagem seguinte mostra um diagrama geral de funcionamento dos servidores de streaming quando conectados a uma videoconferncia:
Endpoint
Servidor
1. Conecta-se a sada auxiliar do terminal na mquina onde est o codicador
Codicador
2. O codicador congurado para enviar os dados codicados para o servidor
Usurio assistindo sesso a partir de um player
217
3. Usurios acessam a transmisso atravs de uma URL
Conforme a imagem, o codificador conectado diretamente a um equipamento que est participando da videoconferncia. Normalmente os equipamentos possuem uma sada auxiliar que pode ser utilizada para conect-lo a uma mquina que possuam uma placa de captura. Este codificador ento integrado ao servidor que disponibilizar o vdeo por streaming para os clientes.
Requisitos principais para streaming e gravao

11 Streaming: processamento, memria e principalmente largura de banda. 11 Memria: quanto maior, maior a capacidade do servidor (mais usurios); atualmente j no um grande problema. Largura de banda: 11 Banda de sada do servidor de streaming varia conforme a taxa de transmisso da conferncia e quantidade de clientes. 11 Taxa de transmisso * nmero de clientes = banda de sada necessria. Para streaming, os principais requisitos so: capacidade de processamento, memria e
largura de banda. Capacidade de processamento necessria, obviamente, para a tarefa de servir diversos clientes que esto recebendo o streaming. Esta tarefa, porm, no a que requer maior capacidade de processamento. O que realmente requer processamento a converso de formatos de udio e vdeo (recodificao) para adaptar os fluxos conforme os clientes receptores dos dados. O problema de processamento no costuma existir em dispositivos em hardware, pois j vm prontos para a tarefa. Mas em sistemas em software necessrio ter cuidado com a mquina na qual o sistema ser instalado, para que ela tenha capacidade suficiente para processar os dados se for necessria a recodificao dos fluxos. Outro requisito necessrio para streaming memria. Quanto mais memria disponvel, mais clientes o servidor de streaming pode suportar. Atualmente, devido aos preos baixos das memrias e qualidade das aplicaes de streaming, memria j no um problema grave. Porm, pode se tornar um problema quando se entra na casa dos milhares de clientes simultneos. O requisito mais importante a largura de banda de sada, que define mais diretamente o nmero mximo de clientes que podem receber o streaming. A banda necessria varia conforme a taxa de transmisso da conferncia e a quantidade de clientes que se deseja atender. O clculo simples: taxa de transmisso * nmero de clientes = banda de sada necessria. Quantidade de receptores 3
Taxa de transmisso / Qualidade 300 kbps 1 Mbps 5 Mbps
Largura de banda necessria 900 kbps 3 Mbps 15 Mbps 6 Mbps 20 Mbps 100 Mbps 30 Mbps 100 Mbps 500 Mbps
20
300 kbps 1 Mbps 5 Mbps
100
218
Figura 8.6 Exemplos de largura de banda necessria para streaming.
1.000
300 Mbps 1 Gbps 5 Gbps
importante observar que a grande maioria dos codificadores de vdeo codifica o vdeo em taxas variveis Variable Bit Rate (VBR). Em funo disso, a banda ideal normalmente deve ser maior do que a banda mdia das transmisses, para suportar os momentos de pico. aconselhvel manter uma banda de segurana de 20% da banda total. Exemplo: se o codificador est configurado para 1 Mbit/s, deve-se prever uma banda total de 1,2 Mbit/s. Para gravao, o requisito mais importante a capacidade de armazenamento. O tamanho de um arquivo de mdia dado por: ( X kbps * S segundos) / (8 * 1024) = Y MB Onde: 11 X = taxa de codificao em bits por segundo; 11 S = tamanho do fluxo de mdias em segundos; 11 Y = tamanho total aproximado do arquivo em megabytes. Taxa de transmisso 37 kbps 50 kbps 100 kbps
Figura 8.7 Exemplos de espao requerido para o armazenamento de arquivos de mdia.
Tempo de contedo (minutos) 30 30 30 30 30 30
Tamanho aproximado do arquivo gravado 8.2 MB 11 MB 22 MB 67 MB 220 MB 880 MB
Vale ressaltar que antes de tomar uma deciso de gravar tudo em baixa qualidade, se pense cuidadosamente no futuro daquele contedo. Um contedo em alta qualidade sempre pode ser transmitido em menor qualidade, entretanto, um contedo em baixa qualidade ficar para sempre em baixa qualidade.
Servidores de streaming em software

Possuem duas aplicaes como base do sistema: 11 Codificador. 11 Servidor. Nos sistemas atuais temos: 11 Windows Media Services e Windows Media Encoder. 11 Helix Server e Real Producer (h uma verso open source: Helix DNA Server).
219
11 Flash Media Server e Flash Media Encoder (Red 5 um servidor de streaming open source similar ao Flash Server). 11 QuickTime Streaming Server e QuickTime Broadcaster (o equivalente open source o Darwin Streaming Server). Com alguns sistemas possvel utilizar mltiplos servidores para melhorar o desempenho. Quanto visualizao do streaming, solues costumam prover um player padro: 11 Windows Media Player. 11 Real Player (para Helix). 11 Flash Player. 11 QuickTime. 11 VLC um player que suporta a maioria dos protocolos e formatos. Sistemas de streaming normalmente tambm suportam serem servidores de vdeo sob demanda (VOD). Neste caso, no necessrio um codificador, pois os vdeos que sero disponibilizados so colocados em um diretrio e o servidor de streaming disponibiliza o acesso a eles. Servidores de streaming mais conhecidos: 11 Windows Media Services, da Microsoft; 11 Helix Server, da Real; 11 Flash Media Server, da Adobe; 11 QuickTime Streaming Server, da Apple. Todas essas solues de streaming no so compostas por apenas um software, mas pelo
menos por dois para gerao do contedo e streaming, e um para visualizao. As duas aplicaes para gerao do contedo tm funes semelhantes em todas as solues. So elas: 11 Codificador: entidade que faz a captura (seja de uma cmera, de arquivos ou outra fonte) e codificao dos dados. Chamado Encoder na maioria dos sistemas; 11 Servidor : recebe os dados do codificador e responsvel pela sua distribuio, ou seja, o streaming dos dados. Codificadores e servidores nas solues citadas: 11 Windows Media Services e Windows Media Encoder; 11 Helix Server e Real Producer; 11 Flash Media Server e Flash Media Encoder; 11 QuickTime Streaming Server e QuickTime Broadcaster.
Essas solues so comerciais (pagas). Mas importante citar que existem verses de cdigo aberto e livres para as solues Helix e Flash. A verso open source do Helix chamada Helix DNA Server (a verso comercial tambm conhecida por Helix Universal Server). Ela possui menos funcionalidades e suporta menos formatos do que a verso comercial, mas ainda assim possui as diversas funcionalidades bsicas necessrias para o streaming. Em relao ao Flash, h uma verso open source chamada Red5, que no diretamente associada ao Flash Media Server, como o Helix. Red5 vinculado ao Flash Server por utilizar protocolos e formatos semelhantes, como RTMP e FLV. J a aplicao open source equivalente ao QuickTime chamada de Darwin Streaming Server. Desenvolvida pela Apple, seu cdigo foi criado com base no QuickTime Streaming Server.
220
Outra observao importante sobre as solues que algumas so vinculadas a apenas um sistema operacional, o que pode dificultar o seu uso. O Windows Media Services s pode ser utilizado no Microsoft Windows Server 2003, enquanto o QuickTime Streaming Server s pode ser usado no OS X Server. As verses open source, porm, costumam suportar mais sistemas operacionais: o Darwin, por exemplo, pode ser executado em diversos sistemas operacionais, incluindo Windows, Linux e Mac OS. Com alguns sistemas possvel utilizar mltiplos servidores para melhorar o desempenho quando se deseja atender muitos usurios. A imagem seguinte mostra um exemplo onde so utilizados diversos servidores Windows Media Server e onde pode ser feito um balanceamento de carga entre eles.
Windows Media Player Network load balancing
Windows Media Player
Internet
Windows Media Encoder
Windows Media server
Windows Media server
Windows Media Player
Windows Media server Windows Media Player
Player A visualizao do streaming feita atravs de um player de mdia, que varia conforme a soluo de streaming utilizada, ou, mais especificamente, de acordo com o protocolo e os formatos/codecs utilizados. Diferentes sistemas utilizam diferentes protocolos e formatos, mas todos possuem um player associado soluo: 11 Windows Media Server: Windows Media Player; 11 Helix Server: Real Player; 11 Flash Media Server: Flash Player (normalmente utilizado na web); 11 QuickTime Streaming Server: QuickTime.
221
Figura 8.8 Servidores Windows Media Server com balanceamento de carga.
Windows Media
Alm dos players associados s solues, podem ser utilizados players de mdia genricos, desde que suportem os protocolos e formatos utilizados. Um exemplo o VideoLAN (VLC), um player que suporta a maioria dos protocolos e formatos utilizados.
A tabela a seguir mostra uma comparao entre os containers, formatos de udio e vdeo e protocolos utilizados em cada uma das solues citadas: Flash Container Vdeo udio Protocolo FLV VP6, H.264 AAC, MP3 RTMP Helix Real Media file format, ASF, 3GP, AVI Theora, Real Video, WMV, H.264 Vorbis, AAC, MP3 RTSP Windows ASF WMV WMA, MP3 MMS Apple MOV MPEG-4, H.264 AAC RTSP
Figura 8.9 Comparao entre os containers (formato de udio/vdeo).
Na tabela foram colocados apenas os itens mais significativos de cada sistema. H sistemas como o Helix, principalmente, que suportam diversos formatos alm dos citados. Esta tabela vlida para as verses pagas dos sistemas. A verso open source do Helix possui suporte a menos formatos e containers, mas as verses open source do Flash e QuickTime so bastante equivalentes com a tabela. Alm do streaming e gravao, os servidores de streaming normalmente tambm suportam vdeo sob demanda (VOD). Neste caso, no necessrio um codificador: os vdeos que sero disponibilizados so colocados em um diretrio e o servidor de streaming disponibiliza o acesso a eles, seja por streaming ou por download progressivo.
w
Para uma comparao detalhada dos sistemas de streaming, visite na Wikipedia a pgina com os diversos formatos e protocolos suportados por cada soluo: Comparison of streaming media systems.
222
Atividade 1 Utilizao do Windows Media Server
O servidor Windows Media Server (WMS) ser utilizado para fazer essa atividade prtica, em que o instrutor vai configurar um ponto de publicao no WMS, que ser utilizado para os alunos publicarem o contedo ao vivo gerado pelo codificador Windows Media.
Atividade 2 Transmisso de contedo com a sute Flash Media

Esta atividade individual, e bastante semelhante atividade anterior, porm sero utilizadas as ferramentas do Flash Media para criao, transmisso e recepo de contedo. O Flash Media Encoder far a captura de udio e vdeo, o Flash Media Server far a distribuio do contedo e o Flash Player ser utilizado para visualizar o contedo, atravs de um plug-in no navegador web. Nesta atividade todos esses componentes sero instalados na mquina do usurio. O primeiro passo a instalao do Flash Media Encoder e do Flash Media Server. O Flash Player j est instalado (se no estiver basta fazer seu download e instal-lo) e ser utilizado atravs de uma pgina web. No material adicional sero exibidas imagens que ilustram o processo de instalao das aplicaes com algumas dicas necessrias.
Descrio das atividades

Aps instalados os aplicativos necessrios, cada aluno dever executar os passos listados a seguir. Depois sero dadas dicas para a correta execuo das atividades. Efetue os testes a seguir: 11 Testar transmisso ao vivo, capturando da webcam e transmitindo; 11 Testar vdeo sob demanda (VOD); 11 Trabalhar em duplas: um aluno transmite e o outro recebe. Explore o codificador: 11 Modificar as taxas de codificao de vdeo; 11 Incluir mais de uma qualidade (so suportados diversos fluxos); 11 Testar a gravao em arquivo. Visualize o console de administrao, normalmente no mesmo grupo da instalao do ser Captulo 8 - Roteiro de Atividades
vidor. Consulte as estatsticas quando os clientes se conectam. Para acesso de outras mquinas e redes, observe as portas utilizadas e a liberao via firewall.
223
224
9
Videoconferncia web
objetivos
Permitir ao aluno experimentar diversos aplicativos de webconferncia, reforando os conceitos tericos estudados e comparando as diferentes solues.
conceitos
Conferncia web (webconferncia), modelos de servio de webconferncia, solues proprietrias (Adobe Connect, Cisco WebEx, FuzeMeeting, Google hangout) e solues de cdigo aberto (Mconf, Big Blue Button, OpenMeetings).
Conferncia Web (webconferncia)

Utiliza-se o navegador para efetuar a videoconferncia. Vantagens: 11 A grande vantagem a facilidade de uso. 11 Dispensa instalao de software cliente: a aplicao executada sobre o navegador. 22 Apesar disso, normalmente so necessrios plug-ins como o Flash. 11 Dispensa equipamentos especficos: normalmente utiliza-se uma webcam comum. 11 A maioria dos casos dispensa configurao de firewall em clientes, pois utiliza portas comuns, como a porta 80. 11 Criao, agendamento, gerncia de salas e usurios atravs de websites. 11 Entrar em uma conferncia clicando em uma URL. 11 Integrao com sistemas como Moodle e Joomla. Webconferncia o ato de conduzir apresentaes ou encontros remotamente utilizando ambiente web. Antigamente, os termos webconference e computer conference eram fre quentemente utilizados para referenciar discusses realizadas atravs de um painel de
a sistemas que permitem a comunicao em tempo real, enquanto as mensagens postadas recebem o nome de frum de discusso, entre outros nomes. Sistemas de webconferncia so normalmente compostos por um servidor responsvel por coordenar as diversas sesses/salas de participantes, e os clientes, que so aplicaes que rodam sobre um navegador web (aplicaes web). Esses sistemas na maioria das vezes tambm apresentam funcionalidades adicionais alm da troca de udio e vdeo, como quadro interativo, compartilhamento de aplicaes e slides.
225
Captulo 9 - Videoconferncia web
mensagens (frum), quase sempre de forma assncrona. Hoje, os termos fazem referncia
Diferenas de videoconferncias desktop

Com o avano das tecnologias de videoconferncias desktop e de videoconferncias web, as diferenas entre essas duas formas de interao por vdeo esto cada vez menores. Praticamente todos os sistemas atuais podem ser utilizados sobre a internet, sendo que a grande diferena entre eles passa a ser o software cliente. Em webconferncias, o software cliente uma aplicao executada dentro do navegador web (com excees), enquanto em videoconferncias desktop sempre necessria a instalao de uma aplicao adicional na mquina do usurio. As diferenas entre os dois modelos de videoconferncia por vezes no so muito claras. Diferenas entre sistemas em software para webconferncia e sistemas em hardware para videoconferncia so visveis e sero tratadas neste curso. H, porm, sistemas em software para videoconferncia que muitas vezes possuem caractersticas dos sistemas de webcon ferncia, alm de apenas interao por udio e vdeo como os sistemas em hardware. Por vezes tambm se considera como webconferncia sistemas com ferramentas como quadro branco, compartilhamento de tela e documentos, controle remoto, servidor centralizado para gravao, ferramentas normalmente no existentes em sistemas de videoconferncia, sobretudo nos sistemas em hardware. Alm disso, webconferncias utilizam uma arquitetura cliente-servidor, onde os dados (incluindo udio e vdeo) so enviados para um servidor e ento distribudos para os clientes. Isso facilita a comunicao em redes privadas e controladas por firewalls e NATs, pois o cliente s precisa se comunicar com o servidor e no com os diversos outros clientes conectados na videoconferncia. Outra vantagem da comunicao cliente-servidor que o servidor pode adaptar os fluxos de udio e vdeo individualmente, conforme a capacidade de cada cliente (reduzir resoluo de vdeo, adaptar taxa de transmisso etc.). As desvantagens so a necessidade de um servidor com alta capacidade de processamento e largura de banda e tambm o provvel aumento no atraso do sistema, j que os dados so processados por um elemento intermedirio (servidor). Apesar de ser possvel que sistemas de webconferncias funcionem no modelo peer-to-peer, eles costumam utilizar um servidor web pelo menos para servir as pginas aos clientes. Ou seja, o cliente acessa um endereo web, e um servidor deve responder a esta requisio enviando a ele a aplicao web para a webconferncia. Aplicaes web normalmente so desenvolvidas com tecnologias Flash, Java ou Silverlight. O padro HTML5 est avanando rapidamente e ser o provvel substituto das tecnologias atuais para desenvolvimento de aplicaes web, incluindo as de webconferncia.
Vantagens da webconferncia
A grande vantagem dos sistemas de webconferncia est na facilidade de efetuar uma vide Administrao de Videoconferncia
oconferncia, visto que tais sistemas funcionam via navegador web. importante observar que apesar do uso do navegador, os sistemas normalmente necessitam da instalao de plug-ins como o Adobe Flash. Mesmo assim, instalar um plug-in ainda mais vantajoso do que instalar uma aplicao especfica, pois o plug-in pode ser utilizado para diversos prop sitos (diversas aplicaes web utilizam Flash, por exemplo). Nesse tipo de sistema, um administrador da conferncia normalmente cria uma sala virtual e convida os participantes. Essa sala virtual gerenciada por um servidor localizado em algum ponto, porm isso transparente para os usurios. Assim, os sistemas de webconferncia no s aproveitam o computador do usurio, mas tambm aproveitam seu
226
navegador web, bem como a porta destinada ao navegador, que normalmente liberada no firewall, no demandando qualquer liberao de porta aos administradores de rede, o que muitas vezes pode ser traumtico em empresas com polticas rgidas de segurana. O acesso a esse tipo de conferncia costuma ser feito de forma bastante simples e intuitiva. Tudo gerenciado atravs de websites, incluindo a criao e o gerenciamento de conferncias, controle de usurios e agendamento, entre outros. Tambm so utilizados padres web difundidos, como HTTP e SSL, possibilitando tarefas como: 11 Convidar participantes por e-mail; 11 Entrar em uma conferncia com apenas um clique numa URL; 11 Integrao com sistemas de gerenciamento de contedo como Moodle e Joomla, entre outros.
Modelos de servio de webconferncia

Aluguel de salas de videoconferncia: 11 Aluga-se todo o ambiente, incluindo as salas onde os participantes estaro. 11 Necessrio deslocamento at o local. 11 Normalmente o modelo mais caro, pois tudo terceirizado. Aluguel de servidores de salas virtuais: 11 Aluga-se apenas o servidor de webconferncia. 11 Aluguel normalmente com valor fixo mensal. 11 Cliente costuma ser grtis, bastando acessar um website. Instalao local (on-site): 11 Instalao do servio de conferncia web localmente. 11 Mais aconselhvel para grandes empresas que podem manter o sistema. 11 Tambm aconselhado quando utilizados sistemas de webconferncia de cdigo aberto.
Aluguel de salas de videoconferncia

Diversas empresas possibilitam o aluguel de salas de videoconferncia como uma forma de reduzir custos de outras empresas; a vantagem nesta modalidade de servio que a companhia que necessita do servio no precisa adquirir equipamentos ou profissionais especializados na tecnologia, negociando diretamente com empresas que j possuem a estrutura pronta e oferecem suas salas. As pessoas devem se deslocar at essa sala, o que pode ser bom em termos de foco, mas definitivamente exige mais tempo. Normalmente so as solues mais caras, mas tambm as menos trabalhosas.
Aluguel de servidores de salas virtuais

Outro modelo aproveitar o conceito de sala virtual utilizado em webconferncias. Uma vez que no sistema de conferncia web as reunies so realizadas em computadores pessoais de usurios sem necessidade de equipamentos ou softwares especficos para este fim, possvel alugar apenas o servidor de webconferncia. Muitas provedoras de servios oferecem esta possibilidade, entre elas a Adobe, com o Adobe Connect, e a Cisco, com o Cisco WebEx. Os usurios normalmente pagam uma tarifa mensal para acessar o servio, com valores variando conforme a qualidade do servio (quantidade de usurios, qualidade de udio e vdeo etc.) e os servios adicionais aos quais se deseja ter acesso (gravao, armazenamento etc.). 227
Neste modelo, a aplicao cliente costuma ser de graa. Contratando o servio que disponibiliza o servidor, os usurios podem simplesmente acessar um determinado website e atravs dele acessar as conferncias.
Instalao local (on-site)

A instalao de sistemas de webconferncia em local prprio justificada quando h a necessidade de uma administrao mais centralizada ou uma customizao do modelo de negcios. Um exemplo quando uma empresa adquire uma soluo de conferncia web para disponibilizar para suas filiais ou para seus clientes. preciso lembrar que isto demandar uma srie de profissionais experientes para a administrao destes sistemas, bem como de uma estrutura tecnolgica (rede, servidores) que esteja de acordo com os requisitos de cada soluo. Por estes motivos, esse modelo recomendado para grandes empresas com alta demanda por videoconferncias. Esse modelo tambm pode ser utilizado em conjunto com as ferramentas de webconferncia de cdigo aberto que comearam a surgir nos ltimos anos. Com esses sistemas possvel obter e instalar o servidor em mquinas locais sem custos de software. Porm, obviamente ainda existe o custo de compra, instalao e manuteno dos servidores.
Solues de conferncia web

H diversas solues, a maioria delas proprietrias, que buscam o mesmo conjunto de funcionalidades, como: 11 Comunicao com udio e vdeo (cada vez se busca maior qualidade e adaptao capacidade de rede do cliente). 11 Capacidade de suportar o maior nmero possvel de clientes. 11 Chat. 11 Quadro branco interativo. 11 Compartilhamento de desktop. 11 Apresentaes (formatos como PDF, PPT e outros). 11 Gravao. 11 Suporte a diversos sistemas operacionais. Nesse captulo sero mostradas imagens dos aplicativos como referncia, para dar uma ideia da soluo. Porm, sabemos que a interface com o usurio muda medida que novas verses so lanadas. Recomenda-se o teste das solues nos sites dos fabricantes para experimentar a verso mais recente.
Existem diversas solues de webconferncia, sendo a maioria delas solues proprietrias (podem ser encontradas mais de 15 solues). H bem menos solues de cdigo aberto significativas, entre elas Big Blue Button, OpenMeetings e WebHuddle (este ltimo com pouca atividade nos ltimos anos). Nesta seo, foram escolhidas as solues proprietrias em destaque atualmente e solues de cdigo aberto, por serem mais acessveis. Entre as ferramentas proprietrias esto Adobe Connect e Cisco WebEx. Tambm ser apresentado o DimDim, soluo que teve seu incio como cdigo aberto mas que migrou para um modelo proprietrio. J as solues de cdigo aberto apresentadas so o OpenMeetings e o Big Blue Button, por possurem uma comunidade de desenvolvedores e usurios em atividade. Apesar de existirem diversas
228
solues no mercado, elas em geral so muito parecidas. Ou podemos dizer que os objetivos finais e as funcionalidades so as mesmas em praticamente todos os casos. A maioria das solues, por exemplo, possui udio, vdeo, chat, quadro branco e exibio de apresentaes. Com a constante evoluo dos sistemas, as funcionalidades de cada um mudam rapidamente. Portanto, uma referncia atualizada para saber as funcionalidades de cada ferramenta a internet. O grande diferencial de solues de webconferncia para solues de videoconferncia para desktop ou com dispositivos fsicos a facilidade de uso. A facilidade neste caso diz respeito a diversos fatores que facilitam o uso da aplicao no lado do cliente. Entre os fatores esto a facilidade em criar, ingressar e gerenciar conferncias, a no obrigatoriedade de instalao de software especfico para a videoconferncia (apesar da necessidade de plug-ins na maioria das vezes) e o uso de padres web, que influenciam nas questes de firewall e na integrao com outras ferramentas. O intuito desta seo apresentar de forma sucinta cada um dos sistemas, suas capacidades e interfaces. Est includa a prtica de trs sistemas: Adobe Connect, Big Blue Button e OpenMeetings. Outras solues sero apresentadas atravs de vdeos.
Adobe Connect
Soluo proprietria da Adobe, antigamente conhecida como Macromedia Breeze. Desenvolvido em Flash, o sistema funciona no modelo cliente-servidor. O servidor comercializado, enquanto o cliente grtis. Exemplo: no necessrio comprar o Adobe Connect para ingressar em uma conferncia da RNP. O sistema comercializado de duas maneiras: 11 Assinatura hospedada: usurio paga uma mensalidade e utiliza os servidores da Adobe. 11 Compra do software servidor para instalao local. Para ingressar na sesso: 11 possvel entrar como convidado, mediante autorizao do moderador (salas pblicas) ou atravs de usurio e senha (salas privadas). 11 Basta acessar uma URL onde ser visualizada a interface para entrar no sistema. Permisses: 11 Administrador. 11 Apresentador. 11 Participante. Layouts: 11 Utilizados para organizar os pods facilmente. 11 Podem ser pr-configurados e armazenados para acesso posterior. Adobe Connect uma soluo proprietria cuja arquitetura utiliza o modelo cliente-servidor. O
sistema est disponvel atravs de assinatura hospedada, em que o usurio paga uma mensalidade e utiliza servidores da Adobe, ou atravs da compra do software servidor para instalao local.
1. O aplicativo cliente desenvolvido inteiramente em Flash: basta ter o plug-in do Flash para a
aplicao ser exibida no navegador. Apesar do Flash ser um plug-in que deve ser instalado na mquina do usurio, ele j est disponvel na grande maioria das mquinas, o que um ponto positivo para o Adobe Connect, pois facilita seu uso. Segundo pesquisas, o Flash est instalado em 99% dos computadores que utilizam a internet (Statistics Adobe Flash Platform). Assim como o Flash, o Adobe Connect suportado nos sistemas Windows, Mac e Linux.
229
Ingressar em uma sesso

No Adobe Connect as salas podem ser pblicas ou privadas. Nas salas pblicas no necessria autenticao para entrada, ou seja, mesmo um usurio no cadastrado no servidor poder entrar na reunio. J nas salas privadas, o usurio dever fornecer um nome de usurio vlido e com permisso para que possa entrar na sala, isto , usurios sem identificao no podem acessar a videoconferncia. O acesso a uma videoconferncia feito de forma simples. Basta acessar uma URL (que normalmente indica o nome da sala de videoconferncia), e sero exibidos os campos para preencher nome de usurio e senha. Clicando em Prosseguir, o website carrega o ambiente de videoconferncia e o usurio j faz parte da sesso. O Adobe Connect oferece ferramentas de administrao que permitem agendar conferncias e enviar convites aos participantes. Algumas tarefas de administrao sero vistas adiante.
Interface do cliente
A interface do Adobe Connect baseada em pods, que so reas internas da aplicao (como janelas internas) que possuem alguma funo especfica na sala. Eles determinaro os recursos que sero utilizados durante a reunio. Na configurao bsica da sala, temos os seguintes pods: 11 Cmera e vdeo; 11 Lista de participantes; 11 Chat; 11 Notas (bloco de anotaes); 11 rea de compartilhamento, que possibilita o compartilhamento da tela, de documentos e de quadro branco.
Pods
Figura 9.1 Interface inicial padro do Adobe Connect.
A aplicao possui um menu na barra superior que permite a configurao de todos os pods, inclusive sua organizao na interface. A organizao dos pods na tela tambm pode ser feita atravs de layouts, que sero descritos mais adiante. A verso 8 do Adobe Connect
230
introduziu diversas melhorias na interface, visando facilitar o uso da ferramenta. Os componentes foram reorganizados, como pode ser visto na imagem seguinte, e foram includas novas funes como arrastar e soltar.
Figura 9.2 Interface do Adobe Connect 8.
Papis (permisses) dos usurios

Dentro de uma sala, os usurios podem ter trs nveis diferentes de permisso: 11 Administradores (hosts) controlam configuraes relacionadas sala, troca de layout, colocao de novos pods, mudana de nvel de permisso de outros participantes, uso de chat, voz e vdeo, compartilhamento de documentos, apresentaes e tela do computador; 11 Apresentadores o apresentador faz mudanas menos significativas no layout da sala, podendo maximizar e mover os pods, embora no conseguindo inserir novos. Ele ainda pode usar o chat e o pod de voz e vdeo, ou seja, compartilhar o seu udio e vdeo com a sala, e tambm compartilhar documentos e a tela do seu computador; 11 Participantes possuem permisso apenas para visualizar a sesso e interagir usando o chat. No desempenham nenhuma tarefa administrativa na sala e no tm permisso de alterao do layout. Os usurios so todos exibidos no pod com a lista de participantes, e seu cone indica qual o seu papel. Administradores podem modificar o papel dos usurios utilizando este mesmo pod.
Figura 9.3 Pod com a lista de usurios e boto para alterar permisses.
Promover usurio
231
Compartilhamento de udio e vdeo

O Adobe Connect permite interao atravs de udio e vdeo. No possui um limite de cmeras por sesso: o limite dado pela banda de rede. Suporta praticamente qualquer modelo de webcam reconhecido pelo sistema e tambm outros tipos de cmeras (como cmeras DV). Para compartilhar udio e vdeo necessrio primeiro permitir que a aplicao tenha acesso sua cmera e a seu microfone. O pod de vdeo possui um boto para isso. Assim que pressionado, exibida a tela padro do Flash para que o usurio permita que o Flash acesse seus dispositivos (ou apenas um deles). Permitindo o acesso, o vdeo do usurio passa a ser transmitido para todos os participantes.
Habilitar cmera e telefone O udio, porm, s comea a ser transmitido quando o usurio habilitar outra opo. Fora do pod de vdeo h o boto exibido na figura abaixo, que permite que o usurio habilite a transmisso de seu udio quando estiver falando.
Figura 9.4 Pod utilizado para habilitar vdeo e udio.
Flash Media Encoder
Fixar microfone
Figura 9.5 Boto para habilitar a transmisso de udio.
Uma das maiores crticas ao Adobe Connect sempre foi a qualidade mediana dos vdeos, muito inferior aos sistemas de desktop e em hardware que suportam alta definio. Na
verso 8, porm, o Adobe Connect melhorou a qualidade de vdeo e udio, suportando inicialmente resolues de at 640x480. Alm disso, foram includos outros detalhes importantes, como a capacidade de visualizar o seu vdeo antes de inici-lo e a integrao com sistemas que utilizam SIP.
Compartilhamento de documentos, tela e quadro branco

Tanto o compartilhamento de documentos, de tela (incluindo controle remoto) e quadro branco so funcionalidades disponibilizadas no pod de compartilhamento. Este pod ocupa grande parte da aplicao no layout padro, sendo o foco principal de muitas reunies.
232
Figura 9.6 Imagem do pod de compartilhamento.
O compartilhamento de documentos suporta diversos formatos de arquivos, como PPT, JPEG, PDF, PNG e inclusive vdeos (no formato FLV). O usurio seleciona os documentos que deseja compartilhar e os envia para o servidor. O servidor converte os dados para o formato adequado para exibio e distribui o contedo para os participantes da videoconferncia. No caso de vdeos, os participantes podem v-los por download progressivo assim que o documento estiver completo no servidor (upload completo).
Figura 9.7 Compartilhamento de uma apresentao.
A verso 8 do Adobe Connect inclui a possibilidade de arrastar e soltar (drag & drop) dos arquivos do computador para compartilh-los na videoconferncia. Outra funcionalidade do pod de compartilhamento o quadro branco, que funciona como uma lousa. O quadro colaborativo, ou seja, qualquer alterao feita vista por todos os participantes. Apenas bastante comuns em quadros brancos: desenhar linhas, formas geomtricas, setas, modificar cores, entre outros.
administradores e apresentadores podem usar essa funcionalidade. Ele possui ferramentas
233
Figura 9.8 Imagem do quadro branco que pode ser editado por todos.
Para compartilhar aplicaes que esto sendo utilizadas no computador do cliente, possvel usar o compartilhamento de tela. Com ele, pode ser compartilhada uma aplicao especfica ou toda a tela do computador, ou seja, os participantes passam a ver exatamente o que o cliente est fazendo em seu computador. Com o compartilhamento, o usurio pode ainda dar o controle de sua mquina para outro participante da sala, funcionalidade chamada de controle remoto.
Bate-papo (chat)
Alm de interao por udio e vdeo, as videoconferncias no Adobe Connect podem utilizar um pod de bate-papo (chat). Seu uso permite troca de mensagens de texto entre os usurios. O chat por padro pblico, mas possvel mandar mensagens para um usurio especfico (chat privado). Na verso 8, os chats pblico e privado so separados, facilitando a organizao. Alm disso, inclui formataes de texto (mudar a cor, mudar o estilo etc.) e a possibilidade de exportar o texto para RTF ou enviar por e-mail.
Figura 9.9 Pod para bate-papo (chat).
Outros pods
O Adobe Connect possui ainda pods para outras funcionalidades alm das j citadas. Um deles o pod para anotaes, que bastante simples e utilizado para, por exemplo, guardar a pauta da reunio. Outro pod interessante o pod de pesquisa (votao), onde pode-se incluir uma pergunta e diversas opes de respostas. Essa pesquisa ento apresentada a todos os participantes e no fim pode-se ver o resultado da votao.
234
Figura 9.10 Pod para pesquisa (votao).
Layouts
Os layouts so formas pr-configuradas de organizar os pods na tela. Eles podem ser criados pelos administradores e so facilmente acessados dentro de uma videoconferncia, utilizando a barra como a da figura seguinte.
Figura 9.11 Barra para mudana de layouts.
Layouts so extremamente teis para mudar a configurao da sala conforme o andamento da videoconferncia. Por exemplo: pode-se comear a videoconferncia com os pods de vdeo e chat ocupando praticamente toda a tela, para que os participantes possam se apresentar e dar incio sesso. Em seguida, muda-se para um layout onde vdeo e chat ocupam menos espao, possibilitando que o pod de compartilhamento ocupe grande parte da tela para exibir uma apresentao. Exemplos desses dois layouts so exibidos nas figuras seguintes.
Figura 9.12 Layouts com foco em: 1) vdeo e chat; e 2) apresentaes.
235
rea do apresentador
Administradores e apresentadores dispem ainda de uma rea de preparao do evento, que consiste em uma regio da tela que no mostrada para os participantes, apenas visvel para administradores e apresentadores. Assim, pode ser realizada comunicao sem interveno no ambiente comum a todos da reunio; qualquer pod pode ser usado nesta rea. Um recurso particularmente interessante o pod de moderao de chat; com ele associado ao chat da rea comum da sala, todas as entradas no chat sero direcionadas para um pod especial, chamado Question & Answer, onde sero respondidas e s depois de moderadas sero enviadas para a rea comum da sala. Na imagem seguinte est exibida a viso do administrador, com a rea de preparao habilitada.
Figura 9.13 Imagem do Adobe Connect exibindo a rea exclusiva para apresentadores.
Dispositivos mveis
Recentemente, a Adobe lanou clientes do Adobe Connect para os dispositivos mveis com os sistemas iOS (iPhone e iPad) e Android (verso 2.2 e superiores). O cliente para iOS foi lanado antes mesmo da verso 8 do Adobe Connect, enquanto o cliente Android foi lanado com a verso 8. Ambos os clientes so gratuitos. Basta fazer download da aplicao para participar de uma videoconferncia. Porm, so apenas visualizadores, ou seja, no
enviam nem udio nem vdeo, mas podem interagir por chat.
Funcionalidades administrativas
As funes administrativas do Adobe Connect so realizadas atravs de uma interface web que configura o servidor Adobe Connect. Esse sistema web permite o gerenciamento dos usurios, das salas de videoconferncia e dos arquivos armazenados no servidor (aqueles que foram compartilhados em videoconferncias). Outra funcionalidade importante que faz parte do gerenciamento do Adobe Connect a gravao das videoconferncias. O contedo fica disponvel no servidor e pode ser visualizado
236
posteriormente. Pode-se reproduzir a conferncia como se fosse um vdeo gravado, observando tudo o que aconteceu. Alm disso, o Adobe Connect armazena o estado da reunio: ela pode ser fechada e aberta de novo mais tarde e voltar ao estado em que estava (inclusive com os arquivos que foram compartilhados no pod de compartilhamento). A ferramenta permite executar tarefas de gerenciamento diretamente nas salas de videoconferncia pelos administradores. So tarefas como habilitar/desabilitar udio ou vdeo de algum participante, mudar permisses dos usurios, mudar ou criar layouts, entre outros.
Atividade de demonstrao do Adobe Connect

O instrutor vai demonstrar a administrao de uma sala de webconferncia. Os alunos devero se conectar e acompanhar a exibio do instrutor. 11 Nveis de permisso; 11 Pods (compartilhamento, vdeo, bate-papo, enquete); 11 rea do apresentador; 11 Layouts.
Cisco WebEx
WebEx inclui: 11 WebEx Meeting Center: soluo de webconferncia. 11 WebEx Training Center: voltado para e-learning. 11 WebEx Event Center: para eventos e seminrios. 11 MeetMeNow: aplicao mais simples para webconferncia entre at 15 indivduos. 11 Todas as solues so construdas sobre a mesma plataforma (MediaTone). 11 um dos principais sistemas de videoconferncia, assim como o Adobe Connect. 11 WebEx Meeting Center (desenvolvido em Java). 11 Suporte em vrios sistemas, como Windows, Mac, Solaris, Linux/Unix. Principais caractersticas: 11 Compartilhamento de desktop. 11 Controle de computador remoto. 11 Quadro branco. 11 Chat e chat privado durante as reunies. 11 Gravao das videoconferncias. 11 Compartilhamento de documentos (PPT, PDF etc.)
11 Oferecido apenas em forma de servio. WebEx o nome de uma empresa adquirida pela Cisco em 2007 e tambm o nome dado ao conjunto de solues de videoconferncia que esta empresa (e portanto, a Cisco) prov. Porm, o nome WebEx normalmente associado soluo de webconferncia da Cisco, visto que todas as solues so construdas sobre a mesma plataforma (chamada MediaTone), mas adaptadas para diferentes modelos de negcio. Neste curso, a soluo que mais se encaixa o WebEx Meeting Center, a soluo de webconferncia que possui muitas similaridades com solues como o Adobe Connect, por
237
11 Cliente para dispositivos mveis (iPad, iPhone, Android, Blackberry).
exemplo. Esta soluo de webconferncia ser referenciada apenas por WebEx no restante desta sesso. Assim como o Adobe Connect, o WebEx um dos sistemas de webconferncia mais conhecidos atualmente. um sistema baseado na web, com integrao de data e mdia em um navegador web padro. Ele comercializado apenas na forma de servio, onde os servidores WebEx so hospedados pela Cisco e os usurios alugam o servio com pagamentos mensais. O WebEx baseado na linguagem Java, que, assim como o Flash, j est bastante difundido nos computadores atuais. As plataformas suportadas so vrias: Windows, Mac, Solaris, Linux/Unix. A imagem seguinte mostra como a interface do WebEx Meeting Center. direita, exibida uma janela com as reas de participantes, chat, perguntas e respostas, vdeos e outros. No centro, ocupando grande parte da aplicao, est a rea para funes de gerenciamento (convidar participantes, por exemplo), quadro branco, compartilhamento de tela, e outras tarefas que, quando utilizadas, so o foco principal da conferncia.
Figura 9.14 Interface do WebEx Meeting Center.
O WebEx uma soluo muito parecida com o Adobe Connect, tendo, portanto, funcionalidades muito parecidas. Entre seus recursos esto: 11 Compartilhamento de desktop; 11 Controle de computador remoto; 22 Compartilhamento de udio e vdeo: a interface do WebEx Meeting Center permite at 6 vdeos ao mesmo tempo, com resoluo mxima de 640x360; 11 Quadro branco; 11 Chat e chat privado durante as reunies;
11 Gravao das videoconferncias; 11 Compartilhamento de documentos (PPT, PDF etc.): diferente do Adobe Connect: no converte e exibe na aplicao, apenas envia para um local comum e permite que os outros participantes faam download dos arquivos no seu formato original.
238
Figura 9.15 Cliente para dispositivos mveis (iPad, iPhone, Android, Blackberry); tela compartilhada do WebEx no iPhone.
Ao compartilhar um vdeo, o usurio transmite este vdeo para o servidor e depois os participantes podem acess-lo. No WebEx, cada participante precisa carregar o vdeo inteiro para ento exibi-lo, enquanto no Adobe Connect pode ser utilizado download progressivo, o usurio visualiza o vdeo medida que ele est sendo obtido. J foi citado que o Adobe Connect guarda o estado da reunio, permitindo que ela seja finalizada e acessada novamente mais tarde, voltando ao seu ltimo estado. J o WebEx no guarda o estado da reunio: se ela acaba, perde-se o seu estado.
FuzeMeeting
Com foco no compartilhamento de documentos e suportando alta resoluo, tambm possui comunicao por chat, vdeo e udio inclusive com integrao com o Skype. Suportado em qualquer sistema: 11 Windows, Mac, Linux, Solaris. 11 Suporte para dispositivos mveis: iPad, iPhone, BlackBerry, Android. Entre suas funcionalidades principais esto: 11 Compartilhamento de contedo em HD (imagens e vdeos). 11 Compartilhamento de desktop e controle remoto. 11 Executado no navegador em Flash. 11 Quadro branco e anotaes. 11 Gravao das videoconferncias para acesso posterior.
O FuzeMeeting outro sistema de webconferncia cuja principal diferencial ser voltado mais para compartilhamento de documentos e desktop do que para videoconferncia propriamente (de certa forma semelhante ao GoToMeeting). Desenvolvida em Flash, a ferramenta executada dentro do navegador, sem necessitar de plug-ins adicionais alm do Flash.
O FuzeMeeting ainda no possui interao por vdeo, mas possui comunicao por udio, que pode ser feita pelo microfone do computador, por um telefone ou pelo Skype. Seu compartilhamento de documentos permite compartilhar imagens, apresentaes e vdeos em alta resoluo e utilizar ferramentas de anotaes (inclusive quadro branco) e apontadores para trabalhar sobre estes documentos. Outras funcionalidades so o compartilhamento de desktop, controle remoto e gravao das conferncias para acesso posterior. A imagem seguinte mostra a interface da ferramenta.
239
Figura 9.16 Interface do FuzeMeeting compartilhando imagem em alta definio.
Uma das vantagens do FuzeMeeting o suporte a diversos sistemas operacionais e dispositivos mveis. Os criadores da ferramenta dizem que ela permite compartilhamento de qualquer coisa em sua tela, em alta resoluo e com qualquer pessoa, em qualquer lugar, em qualquer dispositivo ( with anyone, anywhere, on any device ). Na prtica, pode ser executado em Windows, Mac, Linux e Solaris e tambm possui aplicaes para iPad, iPhone, BlackBerry e Android.
Figura 9.17 FuzeMeeting em diversos sistemas e dispositivos.
O FuzeMeeting vendido como servio, e seu valor atualizado deve ser consultado no site.
Figura 9.18 Verso do FuzeMeeting com interao por udio e vdeo.
240
Google Hangout
11 Website: plus.google.com 11 Sistema proprietrio da google de uso livre 11 Utiliza codificao escalvel de vdeo 11 Facilmente integrado com todo o sistema google Principais caractersticas: 11 Compartilhamento de desktop 11 Compartilhamento de youtube 11 Chat 11 Compartilhamento de documentos (google docs)
O Google Hangout o sistema de webconferncia do Google, sendo bastante integrado com os outros sistemas dele, como Youtube e Google Docs. Apesar de ser um sistema proprietrio (no tem o cdigo aberto), seu uso livre, bastando ao usurio ter uma conta no Gmail. Permite compartilhamento de desktop, chat e outras facilidades interessantes, tanto para efetuar reunies de trabalho como para se divertir entre amigos. Uma caracterstica interessante do Google Hangout que o seu vdeo codificado de forma escalvel, resultando numa boa qualidade para a banda utilizada.
BigBlueButton (BBB)
Sistema de cdigo aberto (LGPL) que possui sistema de pods que permitem mover, redimensionar, organizar layout, entre outras funcionalidades. Desenvolvido basicamente em Flash e Java: 11 Cliente 100% Flash. 11 Servidor Java e Flash. As resolues atualmente suportadas so de 320x240 e 640x480. 11 640x480, com baixo fps (entre 10 e 15). A qualidade boa, mas no tima. Utiliza codificao Sorenson H.263, j estando em andamento o suporte a H.264. O Big Blue Button (BBB) uma das poucas solues de webconferncia de cdigo aberto.
Seu desenvolvimento teve incio em 2007, na Carleton University (Canad). Distribudo sob a licena LGPL, o funcionamento do BBB semelhante ao do Adobe Connect, sendo desenvolvido basicamente em Flash e Java (utilizado no servidor apenas). O cliente uma aplicao Flash que usa um navegador web. A interface da aplicao orgapodem ser movidas, redimensionadas e reorganizadas conforme o layout desejado. Apesar de possuir diversas funcionalidades interessantes, que sero vistas na sequncia, o BBB ainda no se iguala aos sistemas proprietrios em termos de recursos disponveis e de usabilidade, embora possua uma boa base de desenvolvedores ativos e seu uso esteja crescendo ao redor do mundo. Tudo indica que possivelmente se tornar uma alternativa boa e barata para os sistemas proprietrios. Sendo uma ferramenta de cdigo aberto, o BBB tem a vantagem de poder utilizar as diversas bibliotecas e sistemas de cdigo aberto existentes. Ele construdo com base em
nizada em janelas internas (pods), cada uma com uma funcionalidade especfica. As janelas
241
diversos outros sistemas de cdigo aberto, incluindo bibliotecas para codificao de udio e vdeo, servidor e proxy HTTP, servidor RTMP e converso de documentos, entre outros. Entre as funcionalidades do BBB esto: 11 Compartilhamento de apresentaes e documentos. 22 Suporta diversos formatos: PPT, PDF, PNG e JPEG, entre outros. 22 Possui mouse track : um apresentador pode utilizar o seu mouse para apontar pontos de uma apresentao ou documento. 11 Compartilhamento de tela. 11 Quadro branco, que permite escrever sobre as apresentaes. 11 Break-out de salas, que permite separar os participantes de uma sala em outras salas. 11 Integrao VoIP com Asterisk ou FreeSWITCH. 11 Chat pblico e privado, incluindo traduo automtica (com a ferramenta Google Translate). 11 Suporte para mais de 20 idiomas, incluindo portugus. Na prtica, tarefas como cadastrar e gerenciar usurios, criar salas novas, agendar reunies e visualizar gravaes, por exemplo, no so diretamente na interface do BBB. Deve ser utilizada alguma interface que se comunique com a API do BBB, como, por exemplo, as integraes do BBB para Moodle, Joomla e Mconf (que veremos ainda neste captulo). De certa forma, uma limitao do BBB, mas permite maior facilidade para integrao com outros sistemas. Na verso 0.71 do BBB, o foco do desenvolvimento foi em melhorias no udio, especialmente na integrao com sistemas VoIP. J a verso 0.8 inclui mecanismos para gravao e reproduo de gravaes, melhorias na qualidade do udio e na interface. A seguir imagem da interface do cliente no BBB.
l
importante observar que o BBB em si oferece apenas a interface para uma sala de webconferncia e as ferramentas dentro da sala, como: interao por udio, vdeo, chat, compartilhamento de tela e as outras funcionalidades citadas. No BBB, tarefas de natureza administrativa devem ser acessadas por uma API, ou seja, no fornecida interface para acesso a tais funcionalidades.
Figura 9.19 Imagem do BBB em teste com servidor em Washington.

O BBB suporta atualmente as resolues 320x240 e 640x480 para vdeo. Esta ltima tem baixa taxa de quadros por segundo (de 10 a 15). Apesar de ser uma medida subjetiva, o sistema fornece boa qualidade de vdeo, embora no tima. A qualidade equivalente atingida com o Adobe Connect. O sistema utiliza Speex para codificao de udio e Sorenson H.263 para vdeo, sendo que existem planos para migrar o sistema para o codec H.264. Como foi comentado, o servidor BBB desenvolvido em Java e Flash. Sua base em torno da ferramenta Red5, um servidor de fluxos RTMP. O BBB suporta mltiplas salas de webconferncia e j foram realizados testes de carga onde 193 pessoas se conectaram ao mesmo tempo em uma nica sala e 20 delas estavam com transmisso de vdeo habilitada. No
242
aconselhvel permitir a entrada de um nmero to grande de usurios, mas esse nmero mostra a capacidade que o sistema tem de suportar dezenas de participantes simultneos. Outra caracterstica importante do BBB a integrao com outros sistemas de cdigo aberto, como sistemas para wikis, sistemas de gerenciamento de contedo multimdia, sistemas para blogs etc. A seguir uma imagem com os sistemas que fornecem integrao com o BBB.
Figura 9.20 Integrao do BBB com outros sistemas de cdigo aberto.
d
Lista com os sistemas que fornecem integrao com o BBB pode ser acessada na pgina Integration do site da Big Blue Button.
Dicas para instalar sua verso do BBB: 11 O BBB executado em Linux (possui pacotes para Ubuntu). 11 A forma mais fcil e recomendada utilizar a mquina virtual disponibilizada. O BBB distribudo de trs formas: atravs do seu cdigo-fonte, atravs de pacotes pr-compilados para Linux, e atravs de uma mquina virtual que j vem com o sistema
pronto para utilizao. A forma mais fcil e rpida de colocar um servidor BBB em funcionamento atravs de sua mquina virtual. Esta mquina virtual nada mais do que uma instalao do sistema Ubuntu, pr-configurado para instalar o BBB quando for executada. Os procedimentos so simples e detalhes podem ser encontrados na documentao do BBB. O download da mquina virtual pode ser realizado no site da Big Blue Button. Para uso da mquina virtual importante: 11 Ter uma rede com DHCP habilitado; necessria uma mquina virtual aberta para que o BBB seja configurado corretamente. 11 Garantir que a mquina virtual esteja com rede em modo bridged . Se a conexo de rede no for configurada corretamente no modo automtico, alguns comandos podem ajudar na configurao:
$ sudo dhclient $ ifconfig
# configurar IP por DHCP # descobrir IP configurado
$ sudo bbb-conf --setip <ip> # configurar IP descoberto $ sudo bbb-conf --clean $ sudo bbb-conf --check
# reiniciar BBB # verificar configuraes do BBB
Neste curso ser utilizada uma mquina virtual preparada pelo instrutor com o BBB. Os alunos devem utilizar o navegador para acessar o IP que ser fornecido, ao entrar no site, basta inserir seu nome e entrar na conferncia. Nos fruns e listas de discusso para usurios e desenvolvedores na plataforma Big Blue Button do BBB, pode-se encontrar os planos futuros da equipe de desenvolvimento.
243
Entre as possveis funcionalidades que sero implementadas esto: 11 Cliente para dispositivos mveis como iPad, iPhone e dispositivos com Android; 11 Codificao com VP8/WebM/H.264 e, em funo disso, melhorar a qualidade do vdeo; 11 Interface do cliente em HTML5, eliminando o Flash inteira ou parcialmente.
Mconf
Mconf-Web: 11 Portal web que prov acesso ao sistema. 11 Prov salas virtuais, foruns de discussom, agendamento de eventos e outros; 11 Foi desenvolvido com baso na soluo de cdigo aberto Global Plaza, que possui um formato de rede social para realizao de eventos virtuais. BigBlueButton: 11 utilizado como o cliente para webconferncias; 11 Como o BigBlueButton um sistema de cdigo aberto, a equipe do Mconf tambm colabora com o seu desenvolvimento. Mconf-Mobile: 11 Cliente para dispositivos mveis; 11 Atualmente um cliente para dispositivos com Android; 11 Permite que os usurios participem de uma conferncia; 11 Possui praticamente todas as funcionalidades que existem no cliente desktop tradi cional: compartilhamento de udio, vdeo, apresentaes e bate-papo. O Mconf um sistema nacional de cdigo aberto, em desenvolvimento no grupo de pesquisa de Projetos em udio e Vdeo (PRAV) da Universidade Federal do Rio Grande do Sul
(UFRGS), que adiciona funcionalidades ao Big Blue Button para prover um sistema completo de webconferncia. A figura seguinte mostra diagrama dos blocos que formam o Mconf.
Figura 9.21 Diagrama dos componentes do Mconf.
Os trs componentes principais do Mconf so: o portal web (Mconf-Web), o ncleo de webconferncia BigBlueButton e o cliente para dispositivos mveis (Mconf-Mobile). O Mconf-Web o portal de acesso ao sistema, uma aplicao em Ruby on Rails que prov a criao de salas virtuais, fruns de discusso e agendamento de eventos. Este portal foi desenvolvido com base na soluo de cdigo aberto chamada Global Plaza, que possui um formato de rede social para realizao de eventos virtuais (eventos com webconferncia). A imagem seguinte mostra a tela inicial do portal web.
244
Webconference room Agenda Communities Inbox
Recente activity
Figura 9.22 Tela inicial do Mconf-Web, o portal web do Mconf.
O Big Blue Button utilizado como o cliente para webconferncias e por ser um sistema de cdigo aberto, a equipe do Mconf tambm colabora com o seu desenvolvimento. O outro bloco que forma o Mconf o cliente para aplicaes mveis. Atualmente, este componente formado por um cliente para dispositivos Android. Esta uma aplicao nativa para Android que permite que os usurios participem de uma conferncia com acesso a praticamente todas as funcionalidades do cliente desktop tradicional: compartilhamento de udio, vdeo, apresentaes e bate-papo. A figura seguinte mostra telas do cliente Android Mconf-Mobile.
w
Para saber mais sobre o projeto Mconf-Web: www.inf.ufrgs.br/prav
Figura 9.23 Mconf-Mobile, cliente Android do Mconf.
245
Duas funcionalidades principais adicionadas pelo Mconf: 11 Acesso federado 11 Escalabilidade Acesso federado: 11 O portal web est integrado federao nacional CAFe. 11 Permite que qualquer membro da federao acesse o Mconf. 11 Utiliza o protocolo Shibboleth. 11 Aumenta a segurana para os usurios e evita a necessidade de criao de mltiplas contas. Escalabilidade: 11 Um servidor BBB recomendado para 80 usurios simultneos (mas depende fortemente da mquina). 11 Para aumentar a capacidade existe o mdulo de escalabilidade. 11 Permite o uso de mltiplos servidores BBB em paralelo. 11 Com base em um mdulo de monitoramento (CPU, memria, banda de rede etc.), a criao das salas escolhe dinamicamente um servidor na rede de servidores BBB do Mconf (permite aumentar o nmero de salas de webconferncia simultneas). O Mconf est integrado a um mdulo Shibboleth, que prov autenticao federada no
Shibboleth Protocolo internacional para autenticao federada. Permite que usurios de diferentes servios sejam autenticados em provedores de identidade centralizados.
portal web. Mconf e diversos outros servios podem utilizar um mesmo servidor para autenticar os usurios. Para os usurios, a grande vantagem possuir um ponto de autenticao nico para diversos servios, o que aumenta a segurana e evita a necessidade de criao de contas em mltiplos servios. Atualmente o Mconf-Web um dos servios da federao brasileira CAFe (Federated Academic Community). Em relao escalabilidade, o Mconf est desenvolvendo ferramentas para permitir o uso de mltiplos servidores BigBlueButton e para escalar os componentes dentro de um servidor. Como foi comentado, um servidor BigBlueButton recomendado para sesses de 80 usurios simultneos. Para aumentar essa capacidade, a soluo mais direta melhorar o hardware no qual o servidor est instalado. Isto provavelmente aumentar a capacidade do BigBlueButton, mas no uma soluo escalvel, uma vez que se chegar a um limite na capacidade do hardware, no importa o quo bom ele seja. Outra soluo utilizar diversos servidores BigBlueButton em paralelo. Esta soluo aumenta o nmero de salas possveis, mas no aumenta a capacidade de uma sala, j que uma sala est (atualmente) vinculada a somente um servidor. Para incrementar esta soluo e chegar soluo mais completa, deve-se permitir mltiplos servidores BigBlueButton em
paralelo e tambm permitir que uma sala seja espalhada por mltiplos servidores. A soluo do Mconf para esse problema inclui um mdulo de monitoramento no Mconf, que gera estatsticas (CPU, memria, banda de rede) dos servidores Big Blue Button e permite acesso a elas no portal web. Com base nessas estatsticas, as salas sero criadas dinamicamente em diferentes servidores BigBlueButton localizados em regies geogrficas distintas. Como j comentado, o Mconf um sistema de cdigo aberto. O cdigo e toda a documentao do projeto esto disponveis para acesso na web, alm de um servidor onde o sistema pode ser utilizado gratuitamente.
246
OpenMeetings
Sua base similar do BBB, com diversos componentes comuns. desenvolvido em Flash e Java. 11 Cliente 100% Flash. 11 Servidor Java e Flash. Outra alternativa para webconferncias de cdigo aberto o OpenMeetings, que tem diversas semelhanas com o BBB e algumas com o Adobe Connect. O projeto do OpenMeetings foi iniciado em 2007 e seu desenvolvimento evoluiu at o ponto
em que est hoje, com cerca de 25 desenvolvedores ativos. distribudo sob a licena Eclipse Public License 1.0. Sua base similar do BBB, e eles possuem diversos componentes comuns. Assim como o BBB, desenvolvido basicamente em Flash e Java (utilizado no servidor apenas). O cliente, uma aplicao Flash, acessado por um navegador web. Seu servidor baseado no Red5 (assim como o BBB), e ele desenvolvido utilizando um framework para aplicaes web chamado OpenLaszlo. Em comparao com o BBB, ele possui mais funcionalidades, especialmente para tarefas de gerenciamento. Entre suas funcionalidades esto: 11 Quadro branco; 11 Compartilhamento de documentos de vrios formatos: PDF, DOC, ODP e PPT, entre outros. So disponibilizados em uma pasta no servidor e tambm podem ser vistos na conferncia; 11 Gravao, reproduo e download das gravaes; 11 Compartilhamento de tela e controle remoto (necessita de uma aplicao adicional em Java); 11 Possui tarefas de gerenciamento como controle de usurios e agendamento; 11 Votaes com respostas sim e no; 11 Suporte para mais de 20 idiomas (incluindo portugus). Abaixo so exibidas imagens da interface do OpenMeetings, a primeira dentro da webconferncia e a segunda na pgina de visualizao de gravaes.
Figura 9.24 Interface do OpenMeetings para agendamento.
247
Figura 9.25 Interface do OpenMeetings durante uma webconferncia.
Figura 9.26 Interface do OpenMeetings para visualizao de webconferncias gravadas.
Entre as integraes que o OpenMeetings possui com outros sistemas de cdigo aberto esto: 11 Moodle: permite criar e agendar webconferncias; 11 Facebook: o OpenMeetings possibilita que o login no sistema seja feito atravs da conta do usurio no Facebook; 11 Paypal: possibilita integrar a cobrana por servios de webconferncia no OpenMeetings; 11 Sugar CRM: ferramenta para relacionamento com clientes (Customer Relationship Management); 11 StudIP: plataforma de ensino (de certa forma semelhante ao Moodle). Como vimos, OpenMeetings possui diversas similaridades com o BBB. So ferramentas de cdigo aberto, sendo importante verificar as diferenas entre os dois sistemas para decidir aquele que melhor se adapta aos propsitos da pessoa ou instituio que busca um sistema
de webconferncia. Os dois sistemas possuem ambientes de demonstrao disponveis para o pblico, ento indispensvel utiliz-los para fazer uma anlise mais detalhada. Os principais aspectos da comparao entre os sistemas so: 11 Qualidade de vdeo e udio bastante similar; 11 OpenMeetings tem funes administrativas j integradas na interface, enquanto o BBB possui algumas dessas funcionalidades, mas fornece apenas a API para us-las, e no uma aplicao com interface com o usurio. Ou seja, o BBB necessita de outro 22 software que implemente a interface, enquanto o OpenMeetings possui as ferramentas integradas na mesma interface;
248
11 BBB possui documentao mais completa e melhor elaborada; 11 Interface do BBB mais limpa e intuitiva; 11 BBB possui integrao com VoIP; 11 BBB, via grupo Mconf, possui aplicativo para dispositivos mveis. Ao contrrio de outras ferramentas, o OpenMeetings no distribudo em uma mquina virtual pronta para uso. Para instalao local, deve-se obter o pacote com o cdigo-fonte da aplicao, que distribudo no website da ferramenta. Os pr-requisitos (bibliotecas) necessrios devem ser instalados manualmente, depois preciso editar alguns documentos do OpenMeetings e iniciar o servio. Os passos necessrios podem ser encontrados na wiki Installation Open Meetings.
Outras solues
Os sistemas citados at agora so os mais conhecidos e utilizados para webconferncia, mas existem diversas outras ferramentas. Entre os sistemas ainda no detalhados, selecionamos alguns para exibir imagens e links com o intuito de facilitar a consulta dos interessados em conhecer melhor outras alternativas. Os sistemas escolhidos foram: 11 Spreed (proprietrio); 11 Elluminate Live! (proprietrio); 11 WebHuddle (cdigo aberto). 11 Bluejeans (http://bluejeans.com) interopervel com H.323 e integrador de vrias tecnologias.
Spreed
O Spreed um sistema proprietrio de webconferncia. Fazendo cadastro no site possvel utilizar uma verso gratuita, com vrias limitaes (limite de 3 participantes, pouco espao de armazenamento de arquivos e outras). Possui verses pagas por $99 ao ano (20 participantes) e $299 ao ano (100 participantes). Apesar de ser pago, possui uma interface muito boa e bastante fcil de usar.
Figura 9.27 Interface do Spreed exibindo um vdeo e o compartilhamento de uma apresentao.
249
Figura 9.28 Interface do Spreed com foco no chat (exibido no centro).
Elluminate Live!
Sistema proprietrio da empresa Elluminate com foco em educao distncia. Utilizado pelo Virtual Conference Centre, permite realizar teste na aplicao pela pgina Getting Started Virtual Conference Centre (clique em Training Room).
Figura 9.29 Interface do Elluminate compartilhando um vdeo e um quadro branco.
250
Figura 9.30 Visualizando uma gravao do uso do Elluminate Live! compartilhando uma apresentao.
WebHuddle
Projetado para ser de fcil uso, apresenta diversas opes, incluindo integrao com solues de sistemas de teleconferncia de outras empresas. Com o sistema WebHuddle, possvel efetuar a gravao das apresentaes que podero ser reproduzidas futuramente atravs de qualquer navegador web.
251
252
Para as atividades a seguir h um conjunto de funcionalidades comuns a todas as ferramentas (ou maioria delas) que devem ser exploradas.
1. Compartilhar documentos e verificar os formatos possveis (apresentaes, imagens,
documentos texto, quadro branco);

2. Comunicar-se por udio e vdeo e avaliar a qualidade de ambos. Reparar na taxa de
quadros por segundo e no sincronismo de udio e vdeo;

3. Utilizar comunicao por chat; 4. Utilizar bloco de notas; 5. Avaliar a interface da aplicao. fcil para o usurio acessar e utilizar todos os recursos
disponveis?
6. Qual a banda utilizada pela aplicao?
Atividade 1 Administrao e utilizao do Adobe Connect

A turma dever se organizar em at seis grupos, onde cada integrante do grupo acessar a sala indicada pelo instrutor, e na sequncia os alunos faro o papel de participantes, apresentadores e hosts, para que possam utilizar o sistema e ver na prtica como ele se comporta.
Atividade 2 Utilizao do Mconf

Acesse o portal http://mconf.org e teste as funcionalidades indicadas neste captulo.
Atividade 3 Utilizao do Google Hangout

Acesse o Google Hangout e verifique as funcionalidades indicadas. Vale lembrar que, para criar um hangout, o interlocutor deve pertencer aos crculos da pessoa.
253
254
10
Videoconferncia em desktop
objetivos
Permitir ao aluno experimentar diversos aplicativos de videoconferncia em software, reforando os conceitos tericos estudados e comparando as diferentes solues.
conceitos
Solues em software para videoconferncia: IVA, EVO, VSee e Citrix gotomeeting.
IVA
Realizao de aulas sncronas atravs das unidades da ESR, de forma que um professor especialista dissemine seu conhecimento para diversas localidades, evitando custos com viagens sem perder qualidade de aula.
O Sistema Interativo de udio e Vdeo (IVA) um sistema de videoconferncia desenvolvido na Universidade Federal do Rio Grande do Sul (UFRGS), a partir de financiamento da Rede Nacional de Ensino e Pesquisa (RNP) e da Financiadora de Estudos e Projetos (FINEP), em parceria com o Inmetro. Na RNP, o projeto foi iniciado com o Grupo de Trabalho em Infraestrutura para Ensino a Distncia (GT-IEAD). O desenvolvimento principal do projeto aconteceu entre 2007 e 2008, sendo que em 2009 e 2010 foram realizados os testes do prottipo e a implantao da primeira verso para uso na ESR. O servio de aulas por videoconferncia na ESR com uso do IVA teve incio em 2011. O objetivo do sistema a realizao de aulas sncronas atravs das unidades da ESR. O professor especialista pode ministrar sua aula presencial em sala chamada de telessala,
Captulo 10 - Videoconferncia em desktop
para alunos remotos localizados em outras salas, que so chamadas de polos. importante frisar o foco do IVA na interatividade, pois a interao entre professor e alunos remotos essencial para obter qualidade similar das aulas presenciais. A imagem seguinte mostra a interao entre telessala e os polos remotos. O professor fica na telessala com uma turma de alunos presenciais, enquanto nos polos esto alunos remotos assistindo s aulas sincronamente. Um ouvinte remoto tambm pode se conectar e assistir aula.
255
Plo
RNP
Ouvinte Telesala
Plo Unindo alta qualidade de vdeo com o foco na interao, o IVA utiliza o conceito de telepresena, que recria, dentro das possibilidades tecnolgicas, condies de uma aula presencial sncrona. Na telessala, os alunos presenciais enxergam os slides do professor normalmente em um projetor. Nos polos, os alunos remotos tambm enxergam os slides do professor atravs de um projetor. O professor enxerga os alunos presenciais na telessala, e tambm enxerga os alunos remotos, porm em televises, onde a alta qualidade do vdeo permite ver detalhes, como um aluno levantando a mo para fazer uma pergunta. Os alunos presenciais enxergam o professor, e os alunos remotos tambm enxergam o professor, porm atravs de uma televiso.
Figura 10.1 Diagrama da comunicao entre telessala e polos remotos atravs do IVA.
Figura 10.2 Infraestrutura das salas.
(a) Telessala
(b) Polo
Quando um aluno faz uma pergunta, o operador da entidade sute muda a imagem principal para transmitir o vdeo do polo onde o aluno est. Essa imagem transmitida a todos.
Neste formato, as interaes entre professor e alunos remotos so feitas olho no olho. No momento em que um aluno remoto quer fazer uma pergunta, o seu sinal enviado para todos os outros pontos remotos (incluindo a telessala), portanto todos enxergam tanto o professor quanto o aluno fazendo a pergunta.
256
Figura 10.3 Aluno perguntando, todos enxergam professor e aluno.
O sistema IVA formando por trs entidades (softwares) principais. So eles o Moderador, a Sute e o Apresentador. O Moderador e a Sute so as entidades centrais do sistema, que formam uma sesso de videoconferncia IVA, enquanto o Apresentador o software utilizado nos pontos remotos e na telessala para captura e recepo de dados multimdia. Utilizaremos a primeira letra maiscula quando nos referirmos aos softwares do IVA, para evitar confuses (e.g. entidade Apresentador e a pessoa que tem papel de apresentador na sesso). O Moderador funciona como um gerente. Todas as outras entidades IVA se conectam a ele e so gerenciadas por ele. Na prtica, ele utilizado para moderar mensagens de chat e selecionar quais usurios so apresentadores e quais so apenas participantes. O Moderador pode se comunicar por chat com qualquer apresentador e tambm com a Sute. Alm disso, o Moderador recebe o sinal da transmisso de udio e vdeo que est sendo transmitido pela Sute. Na imagem a seguir, pode-se ver no canto superior esquerdo a lista de
Figura 10.4 Imagem do moderador IVA.
apresentadores. No canto inferior direito a lista de participantes. No centro, o chat pblico. No canto superior esquerdo a imagem principal da transmisso do sistema, e logo abaixo um chat privativo com o operador da Sute.
257
A sute o centralizador de mdias do IVA. Ela recebe os sinais de udio e vdeo de todos os apresentadores e escolhe qual desses sinais ser enviado para todos os clientes. Este envio feito utilizando multicast para otimizar a banda de transmisso necessria. Caso algum ponto no tenha multicast, existe outra entidade que faz a converso de multicast para unicast, servindo de forma independente cada um desses locais via unicast. O software Sute possui 6 previews, que so reas de pr-visualizao de udio e vdeo. O operador da Sute pode atribuir qualquer um dos apresentadores em um preview, podendo assim visualizar o seu vdeo e escutar o seu udio. Aps colocar os apresentadores nos previews, o operador pode facilmente selecionar um deles para colocar no ar, ou seja, enviar seus dados por multicast. Conceito de telepresena interao: 11 Perguntas so feitas olho no olho. 11 Todas as salas remotas recebem o sinal de udio e vdeo do aluno que est perguntando. 11 Professor conversa diretamente com o aluno. Conceito de telepresena: 11 Recria, dentro das possibilidades tecnolgicas, condies de uma aula presencial sncrona. 11 Professor enxerga alunos presenciais e polos remotos em televises. 11 Alunos presenciais enxergam slides do professor no projetor. 11 Alunos remotos enxergam slides do professor no projetor. 11 Alunos remotos enxergam a imagem do professor em uma televiso. Outras funcionalidades importantes da Sute so a mixagem de udio e a telepresena. A mixagem de udio permite que a Sute envie mais de um canal de udio simultaneamente, facilitando a interao entre as salas remotas. Qualquer vdeo de Apresentador que est em preview pode ser adicionado na mixagem, portanto, at 6 canais de udio podem ser mixados para envio. A telepresena permite que a Sute crie fluxos adicionais de envio de udio e vdeo. Qualquer um dos previews pode ser colocado em telepresena, o que indica que ele ser transmitido (tambm utilizando multicast) de forma independente do que est na transmisso principal (no ar). Na prtica, temos um sinal de transmisso no ar, que o sinal dos slides do professor. Temos tambm diversos outros sinais de telepresena, um para a cmera de vdeo do professor e um para a cmera de cada sala remota. Com isso todos os polos enxergam os slides e o vdeo do professor, e o professor pode visualizar todas as salas remotas.
258
Figura 10.5 Sute com 5 apre sentadores em preview e enviando os slides do professor na transmisso principal.
O IVA baseado em transmisso multicast. O maior problema de utilizar multicast que ele no suportado em todas as redes. Na verdade, no suportado na grande maioria das redes atuais. Pensando nisso, foi desenvolvida uma nova entidade IVA, chamada de Servidor de Streaming. Esta entidade responsvel por permitir que todos os pontos que no suportam multicast tenham acesso transmisso utilizando unicast. Software Moderador 11 Entidade gerente da sesso IVA. 11 Utilizado para moderar mensagens de chat e selecionar os participantes que atuaro como apresentadores. Software Sute 11 Central de dados multimdia: controla distribuio de udio e vdeo. 11 Seleciona o sinal que est sendo transmitido para todas as salas e os sinais que esto em telepresena. Software Apresentador 11 Responsvel pela transmisso de udio e vdeo. 11 Captura vdeo do professor, dos slides e das salas remotas. 11 Exibe imagens nas televises e projetores. A terceira das principais entidades do IVA chamada de Apresentador. Este software corticipante e transmitir esses dados para a Sute, alm de receber da Sute e exibir o vdeo que est no ar e o udio que est sendo mixado. Alm do uso de udio e vdeo, o Apresentador tambm pode se comunicar com o Moderador atravs de chat (todas as mensagens de um Apresentador so enviadas apenas para o Moderador, que pode decidir se elas devem ser repassadas para todos ou no). Outra funcionalidade do Apresentador a captura de tela, que utilizada para capturar slides, vdeos e qualquer outro material que o professor deseje utilizar. Basta abrir o material no computador que est executando um Apresentador com captura de tela que este material ser transmitido como vdeo para a Sute. O mesmo software Apresentador pode ser executado em modo Visualizador, que um Apresentador que no transmite udio nem vdeo, apenas recebe. Este Visualizador utilizado para receber dados de um canal de telepresena. Na prtica na ESR, eles so 259
responde ao cliente da sesso IVA, o responsvel por capturar o vdeo e o udio de um par-
associados s televises para exibir um plo nas TVs da telessala, ou para exibir o vdeo do professor nas TVs dos plos. A imagem a seguir mostra a tela do Apresentador durante a sesso, quando est capturando, transmitindo e recebendo udio e vdeo. Na parte inferior esquerda da imagem visto um vdeo que corresponde ao preview do vdeo capturado localmente (a cmera do usurio local). Abaixo ao lado direito do preview fica a rea de chat e os botes de controle de udio, vdeo, chat e outros. Atrs desses componentes e ocupando praticamente toda a tela da aplicao est o vdeo recebido da Sute (o vdeo no ar). Nesse caso, o apresentador remoto est mostrando algo no seu tablet. Vale lembrar que as reas sobrepostas imagem recebida podem ser minimizadas.
Figura 10.6 Imagem do apresentador IVA durante uma sesso.
Alm dos softwares citados do sistema IVA, tambm existe o software Chat, que funciona de forma semelhante ao Apresentador, mas que utilizado apenas para comunicao via chat (sem udio nem vdeo). O IVA foi desenvolvido com foco em educao a distncia, mas tambm pode ser utilizado para outros fins, como em reunies remotas. Como foi visto, na ESR os softwares que formam a base do IVA so instalados na telessala, enquanto os polos necessitam apenas dos clientes (o software apresentador). Abaixo so descritos os softwares utilizados na telessala e nos plos da ESR, que formam uma das organizaes arquiteturais utilizando o IVA. Softwares na telessala: a telessala o ponto central das aulas na ESR, portanto nela que esto instalados os servidores IVA. H uma mquina para o Moderador e uma para a Sute. Alm disso, h dois Apresentadores: um captura a cmera do professor, recebe o vdeo no ar e projeta este vdeo no telo (normalmente o vdeo dos slides do professor); o outro utilizado na mquina do professor, para capturar qualquer contedo que se deseje transmitir aos alunos: slides, vdeos, tela de aplicaes etc. Para que o professor veja os polos, existem duas televises na sala, cada uma delas ligada a um Visualizador que recebe o vdeo
de uma das salas. Eventualmente necessrio um software servidor de unicast, quando algum participante estiver em uma rede que no suporta multicast. Na telessala necessrio pelo menos um operador para controlar Moderador e Sute. Pode-se tambm utilizar dois operadores: um tcnico para controlar a Sute e um operador que tenha conhecimento na disciplina sendo ministrada para controlar o Moderador (possivelmente o monitor da aula).
260
Distribui o sinal por multicast
Recebe o sinal multicast encaminha mltiplos em unicast Visualizador Visualizador
Moderador
Sute
Servidor de streaming
Captura imagem do professor e projeta slides
Captura slides, vdeos e outros contedos
Sala remota 1
Sala remota 2
Apresentador
Figura 10.7 Softwares IVA na telessala da ESR.
Apresentador
Softwares nos polos (pontos remotos): os pontos remotos contm apenas os softwares clientes do IVA: o Apresentador e o Visualizador. O Apresentador utilizado para capturar o vdeo e udio da sala e tambm para receber o vdeo no ar e projet-lo em um telo e tambm tocar o udio da sesso. J o Visualizador ligado a uma televiso e sempre mostrar o vdeo do professor. As imagens seguintes mostram telessala na ESR-RS com o IVA em uso.
261
Figura 10.8 Sistema de controle com sute, moderador e apresentador e equipamentos de udio e vdeo.
Figura 10.9 Tela da sute com a seguinte distribuio (esquerda para a direita): vdeo do professor na telessala; tela do professor transmitindo um vdeo; polo ESR-RJ; polo UFRGS; polo ESR-DF; polo ESR-MT.
EVO
Enabling Virtual Organizations (EVO) utiliza como base o sistema de agentes MonALISA. O sistema adapta-se automaticamente s configuraes e estado da rede. Possui monitoramento fim a fim: 11 Monitora tanto o computador cliente quanto a rede. 11 Permite deteco de problemas como uso elevado de CPU e perda de pacotes.
EVO um sistema de videoconferncia desenvolvido pelo Californian Institute of Technology (Caltech), criado com o intuito principal de prover um servio para o trabalho com o Large Hadron Collider (LHC), o acelerador de partculas da European Organization for Nuclear Research (CERN), localizada na Sua. O EVO tambm foi disponibilizado para outros programas de ensino com foco em fsica (High Energy Physics). A base do EVO desenvolvida sobre o sistema de agentes MonALISA, o que possibilita o alcance global ao sistema e tambm o torna mais dinmico e autnomo. O EVO possui funcionalidades para adaptao automtica s configuraes e estado da rede e monitoramento fim a fim, incluindo monitoramento do computador cliente e da rede, o que permite a deteco de problemas como uso elevado de CPU e perda de pacotes.
A aplicao cliente do sistema chama-se Koala e desenvolvida em Java. O cliente tambm utiliza o visualizador de vdeos (ViEVO), que tem como caractersticas principais: 11 Troca de mensagens instantneas, com escolha de estado (ocupado, ausente etc.); 11 Integrao com rede telefnica; 11 Uso de OpenGL no cliente, o que melhora o desempenho e permite um sistema 3D de exibio de vdeos; 11 Criptografia de todos os dados trocados; 11 Suporte para mltiplas linguagens;
262
11 Compartilhamento de arquivos e tela; 11 Funes de quadro branco; 11 Gravao e reproduo das sesses; 11 Chat pblico e privado. O EVO s pode ser utilizado por usurios cadastrados. Portanto, o primeiro passo para utiliz-lo realizar o cadastro, que pode ser feito no website do EVO, clicando em Register. Concludo o registro, basta fazer o download da aplicao e fazer login no sistema. Como a aplicao em Java, ser realizado download do arquivo .jnlp, que ao ser executado carrega a aplicao. O arquivo pode ser encontrado no website clicando em Start EVO. A prxima figura exibe a tela inicial da aplicao juntamente com a caixa de dilogo utilizada para login no sistema.
Figura 10.10 Tela inicial do EVO e tela para login no sistema.
Aps o login, exibida a tela inicial da aplicao, onde pode ser encontrada uma lista com as reunies em andamento (pblicas ou privadas), a lista de amigos do usurio (parte inferior esquerda) e uma rea para chat (parte inferior direita). A imagem dessa tela pode ser vista abaixo.
Figura 10.11 Tela com os canais EVO, lista de amigos e rea de chat.
263
A partir da lista de reunies (chamadas de salas ou canais) o usurio pode selecionar uma delas para ingressar. Ao entrar em uma reunio, o sistema muda para a tela de reunies, que contm as configuraes possveis para ela: habilitar/desabilitar udio e vdeo, gravar, entre outras. Alm desta tela, udio e vdeo so exibidos em outra janela chamada ViEVO, que usa OpenGL para mostrar os vdeos com efeitos grficos que facilitam a usabilidade da aplicao. exibido um participante que est em foco no centro da tela e os outros na barra abaixo do vdeo principal. O participante em foco pode ser quem est falando no momento ou participante escolhido pelo usurio. A imagem seguinte mostra a tela de configuraes e o ViEVO, respectivamente. EVO possui o canal EVO TV aberto a todos os participantes, que pode ser usado para testar sua conexo.
Figura 10.12 Tela de configura es de canal no EVO e tela do ViEVO com vdeo dos participantes.
VSee
11 Soluo gratuita para uso pessoal no comercial, especfica para Windows. 11 O usurio faz login no sistema e visualiza sua lista de contatos. 11 Dados de udio e vdeo so trocados por P2P entre os participantes, se possvel, utilizando apenas uma porta UDP. 11 Em caso de falhas, utiliza tunelamento HTTP ou SSL. 11 H tambm um servidor para autenticao e controle da comunicao. possvel licenciar o servidor para instalao local. O VSee uma ferramenta proprietria de videoconferncia especfica para Windows que segue o formato de aplicativos para troca de mensagens instantneas, como MSN, Gtalk e
Skype. O usurio instala a aplicao, utiliza seu e-mail e senha para fazer login no sistema e com isso tem acesso sua lista de contatos. A partir desse ponto ele pode escolher contatos para se comunicar utilizando udio e vdeo, fazer reunies, compartilhar aplicaes e rea Administrao de Videoconferncia
lizar outras atividades em sistemas de videoconferncia. Apesar de ser uma soluo proprietria, o VSee livre para uso pessoal no comercial. Para uso comercial, o produto oferece diferentes planos. Um plano inclui a instalao local do servidor VSee, modelo semelhante compra do servidor Adobe Connect. Diferenciais do VSee, segundo seus desenvolvedores: 11 Baixo uso de banda: utiliza menos banda do que outras solues como Skype, WebEx, Polycom, Adobe e Cisco. 11 Funciona em qualquer tipo de rede, inclusive em redes wireless e 3G/EVDO. Adapta transmisso automaticamente conforme a rede.
264
A troca de dados de udio e vdeo no VSee feita com P2P entre os participantes, sempre que possvel. Para isso utilizada apenas uma porta UDP, o que reduz os problemas com bloqueio em firewalls. Em caso de falha desse mtodo, utilizado tunelamento HTTP ou SSL. Apesar disso existe um servidor VSee usado para autenticao e controle da comunicao entre os clientes. Principais caractersticas do VSee: 11 Facilidade de compartilhar aplicaes e desktop (one click sharing ): utiliza-se a prpria aplicao para abrir os arquivos e compartilhar aquela tela. O VSee cria uma barra de botes no topo da aplicao compartilhada, que serve para utilizar ferramentas de quadro branco, disponibilizar o controle remoto e cancelar compartilhamento. 11 Vdeo de alta resoluo; 11 Transferncia de arquivos simples por drag&drop; 11 Compartilhamento de vdeos; 11 Controle remoto de cmera; 11 Chat pblico e privado; 11 Utiliza criptografia AES de 256 bits; 11 Permite gravao local das videoconferncias. Para utilizar o VSee, o primeiro passo fazer download do instalador no site da ferramenta. Basta acessar o site do VSee e clicar em Try VSee Now. Aps a instalao, deve ser feito o login no sistema ou ento criar uma nova conta, tarefas realizadas atravs da mesma interface.
Figura 10.13 Telas de login e de criao de conta no VSee.
Ao fazer login, exibida a lista de contatos do usurio e o seu vdeo, que j inicia habilitado e pronto para transmisso.
265
Figura 10.14 Lista de contatos e vdeo do usurio.
A partir deste ponto utiliza-se a ferramenta clicando nos contatos ou nos cones na tela do vdeo local, onde pode-se iniciar reunies, compartilhar arquivos e aplicaes, iniciar e parar a gravao da videoconferncia, entre outras funes. A prxima figura exibe imagens da aplicao em execuo com mltiplos vdeos, chat e compartilhamento de aplicaes.
Figura 10.15 VSee com mltiplos vdeos e janela de chat.
266
Figura 10.16 Barra de ferramentas inserida pelo VSee em uma aplicao compartilhada.
Citrix GoToMeeting
Uma das solues de videoconferncia da Citrix: 11 GoToMeeting: foco em reunies. 11 GoToWebinar: para seminrios e apresentaes. 11 GoToTraining: treinamentos e aulas remotas. No 100% web, sendo necessrio instalar uma aplicao na mquina do usurio. 11 Basta acessar o website do GoToMeeting: a instalao automtica. 11 Possui as funcionalidades e facilidades de um sistema de webconferncia (HDFaces). 11 Ferramenta utilizada como base nas solues da Citrix para incluir transmisso de vdeo em alta qualidade. 11 Suporta at 6 vdeos de 640x320p 11 ou 1 vdeo de 1920x960p O Citrix GoToMeeting uma das solues de videoconferncia da empresa Citrix. Entre as solues desta empresa destacam-se: 11 Sistema com foco em reunies, com suporte para at 15 participantes; 11 Apresentaes e seminrios, suportando at mil participantes; 11 Utilizado para treinamentos e aulas remotas, com suporte a at 200 participantes. O GoToMeeting foi desenvolvido a princpio como um sistema para compartilhar a tela de
um computador com diversos outros computadores na internet. Ele utiliza os mecanismos GoToMyPC e GoToAssist para este fim, fornecendo com eles um bom mecanismo de compartilhamento de desktop e controle remoto. Ao longo dos anos, o sistema evoluiu para se tornar um sistema de videoconferncia completo, sendo tambm expandido para gerar os sistemas GoToWebinar e GoToTraining. A verso com compartilhamento de vdeo foi includa recentemente com a ferramenta HDFaces, que ser comentada adiante. O GoToMeeting oferecido apenas em forma de servio, por cerca de 50 dlares mensais. A capacidade neste plano de at 15 participantes. J os sistemas GoToWebinar e GoToTraining
suportam mais participantes, porm a um custo maior. Assim como os sistemas de webconferncia citados, possui as funcionalidades bsicas deste tipo de sistema: 11 udio e compartilhamento de tela. 11 Integrao com VoIP. 11 Controle de computador remoto. 11 Ferramentas de desenho. 11 Gravao de reunies. 11 Compartilhamento de aplicaes. 11 Chat.
267
O GoToMeeting considerado um sistema web, pois possui as facilidades e caractersticas de um sistema de webconferncia, embora necessite da instalao de um sistema prprio na mquina do usurio. Essa instalao, porm, bastante simples, feita a partir do website do GoToMeeting. A imagem seguinte mostra a aplicao instalada para uso do GoToMeeting. esquerda, a imagem do cone localizado na barra de notificaes do Windows para acesso aplicao. direita, a imagem da aplicao em si, onde podemos ver a lista de usurios (no centro), botes para configurar compartilhamento de desktop e controle remoto (no topo) e chat (na parte inferior), entre outros. Os passos para a utilizao do GoToMeeting podem ser vistos em Web Meeting | GoToMeeting.
w
Veja o tutorial das funcionalidades do GoToMeeting: How to Use GoToMeeting - An Informative Tutorial.
Figura 10.17 Imagem com o cone de acesso ao GoToMeeting (esquerda) e janela principal da aplicao (direita).
Uma novidade das solues da Citrix a ferramenta HDFaces, que servir como base comum para as diversas solues da empresa e que visa a transmisso de vdeo em alta definio (HD). O HDFaces suporta videoconferncias com uma resoluo mxima de 1920x960p, que pode ser atingida atravs de apenas um vdeo, ou pode ser alcanada pela soma das resolues de at 6 vdeos (6 vdeos de 640x320).
Figura 10.18 Demonstrao do GoToMeeting com o HDFaces.
268
Outras solues
Os sistemas citados at aqui foram escolhidos por serem os mais interessantes para os propsitos deste curso. Mas existem outros, entre os quais: 11 Polycom PVX. 11 Isabel Videoconference. 11 Skype (com vdeo). Alm dos sistemas que vimos, existem diversas outras solues, algumas com caracters-
ticas semelhantes e outras muito diferentes, mas todas capazes de transmitir udio e vdeo em tempo real. Entre os sistemas no detalhados, selecionamos alguns para exibir imagens e links para facilitar a consulta por parte dos interessados em conhecer melhor outras alternativas.
Polycom Telepresence m100

Sistema proprietrio que pode ser encontrado no website da Polycom. Possui uma verso de avaliao (trial) com a limitao de permitir ligaes de no mximo 5 minutos (PVX) ou 30 dias (telepresence m100).
Isabel Videoconference
11 Open Source (GPL), com 11 cdigo-fonte em Morfeo-Forge: Isabel Project. 11 Sistema servidor distribudo em Live CD Ubuntu.
Isabel Videoconference uma soluo de videoconferncia com cdigo aberto (licena GPL), desenvolvida pela Universidade Politcnica de Madrid. O sistema completo pode ser obtido fazendo download do cdigo-fonte da aplicao ou atravs de um Live CD baseado na distribuio Linux Ubuntu, em que o sistema distribudo. Com o Live CD, basta executar o sistema operacional do CD, que j estar com o Isabel pr-instalado para ser executado. Isabel utilizado por sistemas como o Global Plaza, que simplificadamente um servio on-line que prov espaos para realizao de videoconferncias.
w Principais caractersticas do Isabel:

O Global Plaza disponibiliza gravaes de videoconferncias realizadas com o Isabel, que podem ser acessadas por streaming no website Globalplaza.
11 Cliente pode se conectar de duas formas: aplicao web no navegador ou pela aplicao desktop (apenas para Ubuntu 8.04 ou superior). 11 Bloco de notas.
11 Quadro branco. 11 Captura e compartilhamento de tela do computador. 11 Cliente SIP.
Skype (com vdeo)

O Skype muito conhecido para realizar comunicao por udio via VoIP, mas j pode ser utilizado tambm para vdeo. Chamadas Skype para Skype so gratuitas, inclusive com vdeo. O Skype uma aplicao j muito conhecida para comunicao por udio via VoIP. H algum tempo j possvel utilizar o Skype tambm para comunicao com vdeo. Apesar de ser uma
aplicao proprietria, ligaes de Skype para Skype so gratuitas, inclusive ligaes com vdeo. 269
Figura 10.19 Skype fazendo comunicao com udio e vdeo.
270
Atividade 1 Utilizao do EVO
11 Acesse o site do Evo Gate, crie uma conta e acesse o cliente EVO. 11 Em dupla, explore as possibilidades do sistema e utilize os recursos de compartilhamento de documentos, chat e gravao da videoconferncia. 11 Em grupo de at quatro alunos, crie uma videoconferncia com os integrantes do grupo e teste o ViEVO.
Atividade 2 Utilizao do VSee

11 Efetue o download do VSee e clique em Try VSee Now. 11 Em dupla, explore todas as possibilidades da ferramenta, como compartilhamento de tela, aplicaes (PPT e vdeos), compartilhamento do navegador, chat e gravao de vdeos. 11 Em grupo de at quatro alunos crie uma videoconferncia com mltiplos participantes.
271
272
Bibliografia
11 Adobe Systems Incorporated. Real Time Messaging Protocol Chunk Stream http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/ devnet/rtmp/pdf/rtmp_specification_1.0.pdf. 2009. 11 H.323 Plus Project (antigo Open H.323) http://www.h323plus.org/ 11 HD changes the face of telepresence today http://www.ivci.com/newsletter0207part2.html 11 High definition (HD) videoconferencing http://www.tandbergusa.com/products/high_definition.jsp 11 Introduction to SIP http://ftp.iptel.org/pub/ser/0.8.14/doc/html/sip_introduction.html 11 ITU-R. Methodology for the subjective assessment of the quality of television picture. Junho de 2002. Rec. BT.500. 11 ITU-T. Subjective video quality assessment methods for multimedia applications. Rec. p. 910, 1999. 11 KAMISETTY, Rao; BOJKOVIC, Zoran; MILOVANOVIC, Dragorad. Introduction to Multimedia Communications: Applications, Middleware, Networking. 774 p. Wiley, 2006. 11 KEITH, Jack. Video Demystified: A Handbook for the Digital Engineer. 5th Edition. Newnes. 976 p., 2007. 11 LOPES, Paulo. Telemedicina e Telesade. UNIFESP, agosto de 2000. http://www.virtual.epm.br/material/tis/mat_apoio/telemed/telemed.pdf 11 Open H.323 Project http://www.openh323.org 11 Packetizer: videoconferencing http://www.packetizer.com/conf/ 11 Referncia terminologia e padres de videoconferncia http://www.c21video.com/standards.html 11 ROESLER, V.; CECAGNO, F.; DARONCO, Leonardo Crauss; DIXON, F. Mconf: an open source multiconference system for web and mobile devices. Complex Issues, 2012. http://www.intechopen.com/books/multimedia-a-multidisciplinary-approach-to-complex-issues/mconf-an-open-source-multiconference-system-for-web-and-mobile-devices
Bibliografia
In: KARYDIS, Ioannis (Org.). Multimedia: a Multidisciplinary Approach to
273
11 ROSENBERG, J.; SCHULZRINNE, H.; CAMARILLO, G.; JOHNSTON, A.; PETERSON, J.; SPARKS, R.; HANDLEY, M.; SCHOOLER, E. SIP: Session Initiation Protocol. IETF: Internet Engineering Task Force. RFC 3261, junho de 2002. 11 SCHULZRINNE et al. RFC 3550 RTP: A Transport Protocol for Real-Time Applications. Julho de 2003. 11 FIRESTONE, Scott; RAMALINGAM, Thiya; FRY, Steve. Voice and Video Conferencing Fundamentals. Ciscopress.com. 2007. 11 STUN: Simple Traversal of UDP Through NATs http://www.cin.ufpe.br/~mlmd/STUN.ppt 11 Telepresence Options Magazine http://www.telepresenceoptions.com/magazine/ 11 Videoconference archiving and streaming state of the art http://www.terena.org/activities/tf-vvc/TF-VVC_Activity-G_vc-archiving-streaming_v0.3.pdf 11 V ideoconferncia (documento de referncia) http://penta3.ufrgs.br/RNP/videoconferencia.pdf 11 Videoconferencing cookbook http://www.vide.net/cookbook/cookbook.en/
274
O livro de apoio ao curso Administrao de Videoconferncia
LIVRO DE APOIO AO CURSO
apresenta os protocolos utilizados para transmisso simultnea de udio, vdeo e dados. O aluno aprende a planejar, instalar e gerenciar a infraestrutura necessria operao de um sistema completo de videoconferncia. Atravs da anlise das alternativas de implementao, ao final do curso estar apto a especificar a soluo de videoconferncia mais adequada s necessidades de sua organizao; a administrar salas e montar o ambiente adequado para cada situao; a operar o servio, fornecer suporte aos participantes e resolver os problemas mais comuns. Este livro inclui os roteiros das atividades prticas e o contedo dos slides apresentados em sala de aula, apoiando profissionais na disseminao deste conhecimento em suas organizaes ou localidades de origem.

Administração de Videoconferência

Uploaded by

Document Information

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Administração de Videoconferência

Uploaded by

Copyright:

Administrao de

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Rio de Janeiro Escola Superior de Redes 2013

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Equipe ESR (em ordem alfabtica)

Escola Superior de Redes

3. Plano de numerao e gatekeeper

5. Redes de computadores e videoconferncia

7. Projeto de ambientes de videoconferncia

8. Transmisso via streaming

10. V ideoconferncia em desktop

Roteiro de Atividades 10271 Atividade 1 Utilizao do EVO271 Atividade 2 Utilizao do VSee271

Escola Superior de Redes

Convenes utilizadas neste livro

Figura 1.1 Picture phone AT&T 1964.

Captulo 1 - Conceitos fundamentais e solues

Figura 1.2 Servio da Bell System.

11 1998: lanadas a segunda verso da recomendao H.323 e a primeira verso do padro

11 1999: lanadas a terceira verso da recomendao H.323 e a segunda verso do padro

Elementos de uma video/webconferncia

Transmisso Codicao Vdeo Decodicao

Captulo 1 - Conceitos fundamentais e solues

Equipamentos de udio e vdeo

Sistemas dedicados (hardware)

Sistemas de mesa (desktop)

Tandberg 990 MXP

Polycom VSX 7000s

Figura 1.5 Estrutura de videoconferncia de mesa.

Figura 1.6 Exemplos de sistema de videoconferncia de mesa.

11 Computador com suporte multimdia. 11 Microfone e caixas de som (ou headset).

Captulo 1 - Conceitos fundamentais e solues

Figura 1.7 Exemplos de sistemas de webconferncia.

Cenrios: Ensino a Distncia (EAD)

Figura 1.8 Exemplos de cenrios de ensino a distncia. Fonte: http://www. unameseca.com.

1. No caso do uso de salas de aula tradicionais, um cenrio tpico posicionar o equipa-

Cenrios: reunies de trabalho

Figura 1.11 Exemplo de sala de telepresena (Cisco).

Captulo 1 - Conceitos fundamentais e solues

Figura 1.13 Cmera de documentos.

StarBoard Hitachi Entrada RGB, sada USB

Figura 1.14 Exemplos de quadro interativo.

A seguir veremos outras abordagens para quadros interativos.

Figura 1.15 Tablet.

Sistemas com alta definio

Razo de aspecto 4:3

Razo de aspecto 16:9

Figura 1.16 Exemplos de Standard Definition e High Definition.

Widescreen (20% mais largo)

Captulo 1 - Conceitos fundamentais e solues

Formato SD HD Resoluo mnima Full p: Vdeo progressivo i: Vdeo entrelaado

Resolues 720x480, 720x576 1280x720p 1920x1080i, 1920x1080p e maiores

Figura 1.18 Equipamentos com suporte a HD. Fonte: http://www. polycom.com.

Cmera Tandberg Precision HD

Polycom HDX Series

Monitor 16:9 Video 4:3

Monitor 4:3 Video 16:9

Figura 1.19 Exemplo de ajuste 4:3 e 16:9.

Figura 1.20 Tcnica de redimensionamento de vdeo.

Figura 1.21 Tcnica de redimen sionamento sem e com remoo de reas.

Captulo 1 - Conceitos fundamentais e solues

Figura 1.22 Comunicao ponto-a-ponto (1:1).

Imagem local e remota

Figura 1.23 Comunicao ponto-a-ponto (1:n).

Figura 1.24 Comunicao ponto-a-ponto (n:n).

Imagem local e remota