Administração de

Videoconferência
Graciela M. L. Martins Leonardo Daronco Valter Roesler

Administração de

Videoconferência

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Administração de

Videoconferência

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Rio de Janeiro Escola Superior de Redes 2013

Copyright © 2013 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ Diretor Geral

Nelson Simões
Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes
Coordenação

Luiz Coelho
Edição

Pedro Sangirardi
Coordenação Acadêmica de Mídias de Suporte à Colaboração Digital

Renato Duarte

Equipe ESR (em ordem alfabética)

Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato e Sergio de Souza
Capa, projeto visual e diagramação

Tecnodesign
Versão

3.0.0

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e Pesquisa e os autores não 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. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br info@esr.rnp.br

Dados Internacionais de Catalogação na Publicação (CIP) M381a Martins, Graciela M. L. Administração de Videoconferência / Graciela M. L. Martins, Valter Roesler; Colaboração 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. Videoconferência. 2. Transmissão de áudio e vídeo. 3. Padrões de vídeo. I. Roesler, Valter. II. Weber, Daniel. III. Daronco, Leonardo. IV. Título. CDD 006.7

Sumário
1. Conceitos fundamentais e soluções
Histórico da videoconferência 1 Videoconferência hoje 3 Definição de videoconferência 4 Objetivos da videoconferência  4 Elementos de uma video/webconferência 5 Tipos de videoconferência 7 Sistemas dedicados 7 Sistemas de mesa 8 Sistemas de webconferência 9 Cenários: Ensino a Distância (EAD) 10 Cenários: reuniões de trabalho 11 Cenários: telepresença 12 Cenários: Telemedicina 12 Dispositivos adicionais 13 Câmera de documentos 13 Quadro interativo 14 Sistemas com alta definição 15 Relação de aspecto 16 Estruturação de um serviço 17 Roteiro de Atividades 1 21 Atividade 1 – Sistema de conferência em desktop 21 Atividade 2 – Funcionalidades do sistema 21 Atividade 3 – Medindo o atraso da transmissão 22 iii

2. Padrões de videoconferência
Introdução a padrões e protocolos 23 Padronização 23 Princípios de codificação de áudio 24 Padrões de áudio 27 Princípios de codificação de vídeo 28 Redundância espacial 29 Redundância temporal 30 Redundância psicovisual 30 Redundância de codificação (entrópica) 31 Padrões de vídeo 31 H.264 33 MPEG 33 Padrões de dados 35 Padrões de comunicação  36 Padrão H.320 36 Padrão H.323 37 Multipoint Control Unit (MCU) 39 Gateway 40 Gatekeeper 41 Elementos de borda 43 Protocolos da arquitetura H.323 43 Protocolos RTP e RTCP 44 Protocolo H.225 RAS 46 Protocolo H.225 – sinalização de chamada 49 Protocolo H.245 50 Procedimentos de uma conexão H.323 54 Padrões para serviços  57 Roteiro de Atividades 2 59 Atividade 1 – Análise de troca de mensagens direta entre dois clientes  59 Atividade 2 – Análise de troca de mensagens entre dois clientes com gatekeeper 60

3. Plano de numeração e gatekeeper
Padrão ITU E.164 61 iv

Plano de numeração 62 Plano de discagem 63 Gatekeeper GnuGK 64 Instalação do GnuGK 65 Inicialização do GnuGK 65 GnuGK no Windows 66 Configuração do GnuGK (Windows, Linux e outros) 66 Monitoramento do GnuGK 68 Zoneamento 70 Hierarquia de gatekeepers 72 Mensagens LRQ 73 Reescrita de números E.164 75 Autenticação 77 Contabilização 81 Modos de operação 83 Modo direto 83 Modo roteamento 84 Modo proxy 84 Roteiro de Atividades 3 89 Atividade 1 – Configurando o cliente e efetuando chamadas 89 Atividade 2 – Configurando GnuGK para conexão de clientes autorizados 89 Atividade 3 – Habilitando modo proxy 90 Atividade 4 – Configurando o DGK na rede 90

4. Introdução ao SIP
Session Initiation Protocol (SIP) 93 Arquitetura do SIP 94 Mensagens e respostas SIP 97 Registro SIP 100 Diagrama de uma chamada SIP 101 Comparação SIP e H.323 102 OpenSIPS 103 Instalação OpenSIPS  104 Inicialização OpenSIPS  104 v

Arquitetura modular OpenSIPS  106 Configuração OpenSIPS  107 Lógica de roteamento 108 Modos de operação OpenSIPS  109 Integração com banco de dados OpenSIPS  111 Localização de usuários OpenSIPS  113 Plano de discagem OpenSIPS  113 Autenticação de clientes OpenSIPS  115 Contabilização OpenSIPS  117 Geração de logs OpenSIPS  118 Roteiro de Atividades 4 121 Atividade 1 – Ligação SIP através do X-Lite 121 Atividade 2 – Configuração e utilização de um servidor SIP: OpenSIPS 121 Atividade 3 – Incluir validação de usuários no OpenSIPS 122

5. Redes de computadores e videoconferência
Infraestrutura básica de redes 125 Formas de tráfego de redes para videoconferência 126 Ponto-a-ponto 126 Multiponto 127 Tráfego unicast 129 Tráfego broadcast 129 Tráfego multicast 130 Multiponto: unicast x multicast 130 Multicast 132 Portas e protocolos dos padrões H.323 e SIP 134 Uso de firewalls em videoconferência 135 Videoconferência via NAT 136 Tipos de NAT 137 Problemas gerados pelas NATs em videoconferências 139 Soluções 140 Suporte a NAT nos softwares de videoconferência 142 Conceitos de transmissão multimídia 143 Latência 143 Jitter 144 Skew 145

vi

Atraso na transmissão 149 Uso de QoS em videoconferência 155 QoS no H.323 155 QoS na rede 156 Arquiteturas de rede para suporte a QoS 158 Roteiro de Atividades 5 161 Atividade 1 – Gerar fluxos UDP e TCP com iperf  161 Atividade 2 – Identificar e analisar pacotes RTP e RTCP 162 Atividade 3 – Calcular atrasos na comunicação 163

6. Videoconferência multiponto
Videoconferência multiponto 165 Modelo centralizado 166 Modelo descentralizado 166 Multicast 167 Modelo híbrido 167 MCU 168 Soluções de MCUs  171 Soluções de MCUs em hardware 173 Demonstração de MCU – RNP 174 Soluções de MCUs em software 175 Alternativa ao MCU: vídeo escalável 176 Estudo de caso de vídeo escalável: empresa Vidyo 178 Roteiro de Atividades 6 181 Atividade 1 – Demonstração das funcionalidades do Polycom V500 181 Atividade 2 – Compartilhamento de documentos com People+Content 181

7. Projeto de ambientes de videoconferência
Salas de videoconferência 183 Ambiente físico 184 Iluminação 184 Visibilidade 185 Acústica 186 Climatização 186

vii

Ambiente de áudio 187 Tipos de microfones e suas características 187 Microfonia 191 Caixas acústicas 191 Ambiente de vídeo 192 Projeto de sala 193 Natureza da sala e público alvo 194 Mobiliário e equipamentos 194 Infraestrutura e layout 196 Preparação de uma videoconferência 197 Etiqueta e boas práticas 199 Estudo de caso 1: Auditório 201 Estudo de caso 2: Sala de reunião 203 Estudo de caso 3: Uso geral 204 Estudo de caso 4: Projeto da sala da ESR-RS 205 Acústica 207 Planos de câmera/operação 208 Sonorização 209 Roteiro de Atividades 7 211 Atividade 1 – Análise de cenários e elaboração do projeto das salas 211

8. Transmissão via streaming
Streaming de vídeo 213 Streaming x Download progressivo  214 Soluções para transmissão e gravação 215 Soluções baseadas em software 216 Requisitos principais para streaming e gravação 218 Servidores de streaming em software 219 Roteiro de Atividades 8 223 Atividade 1 – Utilização do Windows Media Server 223 Atividade 2 – Transmissão de conteúdo com a suíte Flash Media 223

9. Videoconferência web
Conferência Web (webconferência) 225

viii

Modelos de serviço de webconferência 227 Soluções de conferência web 228 Adobe Connect 229 Ingressar em uma sessão 230 Interface do cliente 230 Papéis (permissões) dos usuários 231 Compartilhamento de áudio e vídeo 232 Compartilhamento de documentos, tela e quadro branco 232 Bate-papo (chat) 234 Outros pods 234 Layouts 235 Área do apresentador 236 Dispositivos móveis 236 Funcionalidades administrativas 236 Cisco WebEx 237 FuzeMeeting 239 Google Hangout 241 BigBlueButton (BBB) 241 Mconf 244 OpenMeetings 247 Outras soluções 249 Spreed 249 Elluminate Live! 250 WebHuddle 251 Roteiro de Atividades 9 253 Atividade 1 – Administração e utilização do Adobe Connect 253 Atividade 2 – Utilização do Mconf 253 Atividade 3 – Utilização do Google Hangout 253

10. V ideoconferência em desktop
IVA 255 EVO 262 VSee 264 Citrix GoToMeeting 267 Outras soluções 269

ix

Roteiro de Atividades 10 271 Atividade 1 – Utilização do EVO 271 Atividade 2 – Utilização do VSee 271

Bibliografia  273

x

Escola Superior de Redes
A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR
A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

xi

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona 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 dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções 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 capítulos sobre os diversos aspectos necessários a uma compreensão mais aprofundada dos sistemas de videoconferência. A apresentação dos conceitos teóricos é consolidada com atividades práticas que reforçam o aprendizado. O livro aborda questões como fundamentos de videoconferência, padrões internacionais de videoconferência (H.323 e SIP), gerência de sistemas de videoconferência, ambientes de videoconferência, streaming e uso de aplicativos de videoconferência. O foco do livro está sobre os diferentes tipos de conferência com vídeo, implantação e administração de soluções de videoconferência, e nas melhores práticas para a elaboração de projetos de ambientes adequados para a realização dos diferentes tipos de videoconferência.

A quem se destina
O público-alvo deste curso é amplo, incluindo administradores de sistemas de videoconferência, gerentes de projeto relacionados a vídeo, profissionais interessados em transmissão de eventos via streaming, ou qualquer pessoa que necessite de um maior embasamento para solucionar problemas em ambientes de videoconferência. É desejável que os participantes tenham conhecimento prévio em redes de computadores e no uso de sistemas Linux.

xii

Convenções utilizadas neste livro
As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante
Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos.

Conteúdo de slide
Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo
Indica referência complementar disponível em site ou página na internet.

Símbolo
Indica um documento como referência complementar.

Símbolo
Indica um vídeo como referência complementar.

Símbolo
Indica um arquivo de aúdio como referência complementar.

Símbolo
Indica um aviso ou precaução a ser considerada.

Símbolo
Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo
Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso
Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: MARTINS, Graciela; DARONCO, Leonardo; ROESLER, Valter. Administração de Videoconferência. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas
Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 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 experiência na área de TI. Graduada em Ciência da Computação pela UNESP. Especializou-se em Aplicações de Comunicação e Colaboração na Internet durante o mestrado realizado na USP e, posteriormente, em Gestão Estratégica da Inovação Tecnológica pela UNICAMP. Atua na RNP na gestão de programas e projetos visando o provimento de soluções de TIC para as áreas de Educação e Cultura. Foi uma das responsáveis pela estruturação inicial do serviço de webconferência provido pela RNP. Leonardo Daronco é formado em Ciência da Computação pela Universidade Federal de Santa Maria (2007) e tem mestrado em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (2009). Tem experiência em assuntos relacionados à multimídia, codificação de vídeo, redes de computadores e programação. Trabalha atualmente no grupo de pesquisa PRAV (Projetos em Áudio e Vídeo) da Universidade Federal do Rio Grande do Sul (UFRGS), com pesquisa e desenvolvimento de sistemas multimídia para webconferência, ensino a distância e desenvolvimento em dispositivos móveis e sistemas web. Valter Roesler é formado em Engenharia Elétrica pela Universidade Federal do Rio Grande do Sul (1988), com mestrado (1993) e doutorado (2003) em Ciência da Computação pela UFRGS. Atualmente é Professor Adjunto na Universidade Federal do Rio Grande do Sul. Tem experiência na área de ciência da computação, com ênfase em redes de computadores, atuando principalmente nos temas: Telemedicina, Tele-educação, Multimídia, Redes de Computadores, Codificação de Vídeo e TV Digital. Coordenador do laboratório do PRAV (Projetos em Áudio e Vídeo). Líder do grupo de pesquisa do Núcleo de TV Digital da UFRGS e Núcleo de Telessaúde, no diretório dos grupos de pesquisa CNPq. Renato Duarte é formado em Ciência da Computação pela UniCarioca e trabalha há treze anos na área. Atualmente é responsável pela área acadêmica de Mídias de Suporte à Colaboração Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes da Rede Nacional de Ensino e Pesquisa (ESR-RNP). É responsável pela infraestrutura de TI de apoio à coordenação da ESR, e pelo preparo e validação dos laboratórios para execução das atividades práticas dos cursos da ESR.

xiv

1
Conceitos fundamentais e soluções
objetivos
Familiarizar o aluno com os princípios e conceitos fundamentais associados à videoconferência, bem como gerar um nivelamento entre os diferentes conceitos existentes.

conceitos

Cenários e aplicações de videoconferência, tipos de sistemas de videoconferência, conferência síncrona e assíncrona, taxa de quadros por segundo, resolução, banda, atraso, relação de aspecto.

Histórico da videoconferência
Este “telefone” apresenta muitas deficiências para ser considerado seriamente como um meio de comunicação. O dispositivo é inerentemente sem valor para nós. Esta frase foi traduzida de um memorando interno da companhia Western Union do ano de 1876*, e mostra a capacidade de mudança e evolução da tecnologia. Hoje sabemos como eles estavam enganados. Este mesmo problema já esteve também relacionado aos sistemas de videoconferência em seu início, mas com o avanço da tecnologia ficou claro que os sistemas de videoconferência são de grande utilidade.
*

Fonte: http://www.princeton.edu

Figura 1.1 Picture phone AT&T 1964.

Os sistemas de videoconferência foram criados em meados da década de 1960. Para se ter uma ideia, desde 1970 as centrais telefônicas já suportavam teleconferências baseadas em áudio, mas conferências por vídeo ainda não eram uma realidade. Foi a partir da década de 1980, porém, que os rumos da pesquisa e desenvolvimento caracterizaram esses sistemas do modo como são atualmente conhecidos.

Capítulo 1 - Conceitos fundamentais e soluções

1

O primeiro sistema de videoconferência 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 história das telecomunicações. O aparelho foi introduzido no mercado em 1970 e comercializado por cerca de U$ 160 dólares mensais. Um ano depois, a Ericsson lançou o primeiro vídeo-telefone transatlântico.

Figura 1.2 Serviço da Bell System.

A década de 1980 é marcada por avanços na pesquisa em transmissão de dados. Aproveitando a iniciativa da Arpanet, foram realizados vários experimentos com transmissão 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 é lançada a recomendação H.120 para codificação de vídeo, abrindo caminho para o surgimento da recomendação H.320, voltada para videoconferência. A década de 1990 continuou marcada por seguidas recomendações e pelo surgimento de padrões para regulamentar o desenvolvimento de sistemas de videoconferência. Também nessa década são conhecidos os primeiros sistemas de videoconferência comercializados no mercado pelas empresas Compression Lab, PictureTel e Mitsubishi. Vários acontecimentos marcaram a evolução dos sistemas de videoconferência, como:

11 1990: surge a recomendação para conferência ISDN. 11 1991: primeira videoconferência com áudio e vídeo utilizando o codec H.261. 11 1992: lançado o sistema de videoconferência CU-SeeMe, inicialmente apenas para
Macintosh e sem áudio.

11 1993: suporte a multiponto. 11 1994: suporte a áudio e versão para Windows. 11 1996: lançada a primeira versão da recomendação H.323 e do NetMeeting pela Microsoft.
Administração de Videoconferência

11 1998: lançadas a segunda versão da recomendação H.323 e a primeira versão do padrão
MPEG-4 para compressão de vídeo.

11 1999: lançadas a terceira versão da recomendação H.323 e a segunda versão do padrão
MPEG-4 para compressão de vídeo; o IETF divulga o SIP.

11 2000: Samsung lança o primeiro MPEG-4 streaming 3G. 11 2001: realizada a primeira “telecirurgia” transatlântica. 11 2003: lançado o padrão H.264; disseminação de redes de banda larga; maior acessibilidade a vídeo; uso de videoconferência na educação.

2

A partir da década de 1990, vários aplicativos começaram a ganhar espaço no mercado mundial, sobretudo para envio e recebimento de informações de áudio e vídeo sobre redes TCP/IP. Cada vez mais, aplicativos para o envio de áudio e vídeo exploravam e aprimoravam as técnicas para compressão de dados, permitindo a comunicação de usuários em rede com baixo custo e padrão de qualidade aceitável. A popularização dos sistemas de videoconferência foi impulsionada pela recomendação H.323 feita pela ITU-T em 1996, que permitiu o desenvolvimento padronizado de diversas soluções de software para videoconferência. Atualmente, as soluções para sistemas de videoconferência são comumente utilizadas no nosso dia a dia, seja na comunicação entre pessoas na internet ou integradas ao cotidiano das grandes corporações. A utilização desses sistemas extrapolou a área de negócios, estando hoje presente em atividades de ensino a distância, de telemedicina e de pesquisa científica, além de muitas outras aplicações. No Brasil, o mercado para sistemas de videoconferência acompanha a tendência de crescimento mundial. Cada vez mais empresas e usuários domésticos têm lançado mão desse recurso para realizar atividades do dia a dia, como conversar com amigos distantes ou tomar decisões de negócios em reuniões não presenciais. Portanto, é possível dizer que estamos caminhando para o mundo das soluções multimídia sobre redes IP, que não constituem apenas uma tendência da atualidade, mas sim uma necessidade para inclusão em um mercado a cada ano mais competitivo, ágil e rápido, demandando mais recursos para facilitar o relacionamento entre as empresas. Nesse sentido, nos próximos anos, a videoconferência será uma das ferramentas mais importantes no cenário dos negócios e da comunicação interpessoal.

Saiba mais
Leia o artigo de Lori Wilkerson sobre a história da videocon ferência: The History of Video Conferencing - Moving Ahead at the Speed of Video.

w H.323
H.320

Videoconferência hoje
Na sua 7ª versão, é o padrão mais consolidado para videoconferência.

q

Ainda bastante utilizado nas corporações, embora tenda a ser substituído por sistemas baseados em IP. SIP Consolidado para telefonia sobre IP. Webconferência O surgimento de clientes web tem possibilitado a realização de conferências via web.
Capítulo 1 - Conceitos fundamentais e soluções

Essa forma alternativa de videoconferência tem se destacado pela facilidade de uso. Atualmente, existem padrões já consolidados para a realização de videoconferências, que serão vistos ao longo do curso. O H.323 é o padrão mais consolidado e encontra-se em sua 7ª versão. O H.320, para uso em redes ISDN (Integrated Services Digital Network) é outro padrão bastante consolidado, mas tende a ser substituído pelos sistemas baseados em IP, como o H.323. Outro padrão que vem crescendo é o SIP. Inicialmente utilizado apenas para telefonia sobre IP (nicho dominado pelo SIP), vem sendo cada vez mais utilizado para videoconferências. Outro tipo de videoconferência que vem crescendo é conhecido como webconferência, se destacando pela facilidade de uso. As webconferências serão abordadas adiante.

3

Definição de videoconferência
Antes de definir o termo “videoconferência”, é importante comentar sua diferença em relação ao termo “webconferência”. Vídeo + Conferência Conferência onde há interação entre duas ou mais pessoas através de vídeo e normalmente também de áudio. Web + Conferência A palavra indica uma comunicação via web (internet), não necessariamente envolvendo vídeo (apesar de normalmente ser utilizado). Videoconferências são normalmente realizadas de três formas: através de softwares instalados em computadores pessoais, via hardwares dedicados e ainda pela utilização do navegador web no computador pessoal. Com a padronização dos sistemas web atuais, normalmente não é necessário instalar qualquer software adicional, bastando instalar um

q

plug-in no navegador para que o usuário obtenha todas as funcionalidades da conferência. É importante observar que a palavra “conferência” sugere a participação de três ou mais pessoas. Entretanto, uma videoconferência pode ser realizada entre duas ou mais pessoas.

Objetivos da videoconferência
Comunicação em tempo real entre duas ou mais pessoas geograficamente dispersas, normalmente em locais diferentes, através de áudio e vídeo.

q

A videoconferência é um recurso facilitador da comunicação entre pessoas. Por intermédio de uma videoconferência, duas ou mais pessoas participam de uma discussão 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 videoconferência consiste em viabilizar a comunicação em tempo real entre grupos de pessoas, com o uso simultâneo de áudio e vídeo, independentemente de sua localização geográfica. Assim, torna-se possível trabalhar cooperativamente por meio do compartilhamento de informações e de outros materiais de trabalho – como documentos, imagens ou planilhas – sem qualquer ônus proveniente da distância geográfica. Outras possibilidades da videoconferência:

11 Compartilhamento e apresentação de slides. 11 Compartilhamento de aplicações. 11 Bate-papo por chat. 11 Quadro branco (colaborativo).
Administração de Videoconferência

q

11 Troca de arquivos.
Além da troca de áudio e vídeo entre os participantes, os sistemas atuais têm disponibilizado diversas outras ferramentas que melhoram a comunicação e criam novas possibilidades para as videoconferências. Entre essas ferramentas estão bate-papo por chat, compartilhamento de apresentações, quadro branco colaborativo, troca de arquivos e compartilhamento de aplicações. Esta última ferramenta normalmente está presente nos sistemas de videoconferência de desktop e mostra claramente a integração que um sistema de videoconferência pode ter com o sistema base sobre o qual é executado (no caso a integração com o sistema operacional). Com a evolução da tecnologia e a redução dos custos

4

nos últimos anos, a videoconferência passou a ser usada como ferramenta de colaboração, aprendizagem e entretenimento. As videoconferências evoluíram muito nos últimos anos e ferramentas como as citadas já são comuns em muitos sistemas. Apesar disso, os sistemas continuam sendo chamados de “videoconferência”. Pode-se fazer uma analogia desta situação com a evolução do telefone celular, que deixou de ser apenas um dispositivo para efetuar e receber ligações telefônicas para se tornar um computador portátil, que pode inclusive realizar videoconferências. Apesar dessa evolução, eles continuam sendo chamados de “telefones celulares”, mesmo que ligações telefônicas não sejam, em alguns casos, a ferramenta mais utilizada do dispositivo.

Elementos de uma video/webconferência
11 Vídeo e áudio 11 Codificação e decodificação 11 Transmissão e recepção 11 Equipamentos de áudio e vídeo

q

Vídeo e áudio
A primeira etapa para uma videoconferência consiste na captura e digitalização dos sinais de áudio e vídeo que serão transmitidos. Para tal, existem diversos dispositivos diferentes. O vídeo pode ser capturado por câmeras variando desde webcams de baixo custo (que normalmente apresentam baixa qualidade) até câmeras profissionais que garantem alta qualidade (HD). Atualmente já existem câmeras pessoais capazes de capturar vídeo em alta resolução. 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 propósito.

Transmissão Codificação Vídeo Decodificação

Áudio
Figura 1.3 Elementos básicos de videoconferência.

Áudio e vídeo

Codificação e decodificação
Após a captura e digitalização, os dados são codificados (o que inclui sua compressão) para que possam ser transmitidos pela rede. O elemento essencial para este processo é o codec (COdificador/DECodificador), que atua nas funções de codificação e decodificação. A etapa de compressão algorítmica é fundamental para otimizar a transmissão das informações. O sinal original é reduzido para um tamanho “n” vezes menor através da codificação, o que

Capítulo 1 - Conceitos fundamentais e soluções

5

possibilita a transmissão dos dados e também a adaptação da transmissão conforme a rede disponível. No lado do receptor, o codec realiza a decodificação, que consiste em transformar os dados novamente para seu formato original, o que permite sua reprodução. Os codecs utilizados normalmente são os baseados em normas internacionais da ITU-T, e muitas vezes MPEG para vídeo. É possível afirmar que todos os sistemas de videoconferência utilizam o mesmo conjunto de codecs, ou uma variação deste conjunto. Ou seja, os codecs mais comuns para áudio e vídeo normalmente são suportados por diversos sistemas de videoconferência. O que difere de um sistema para outro são os mecanismos de compressão, ou seja, a parametrização da compressão algorítmica adotada pelo fabricante.

Transmissão e recepção
Após a codificação, os dados estão prontos para serem transmitidos. A transmissão dependerá das características da rede, onde um parâmetro extremamente importante é a banda disponível, que é utilizada para configuração da codificação de áudio e vídeo. A qualidade da rede muitas vezes é monitorada e utilizada para modificar a parametrização da codificação de áudio e vídeo. Se a rede está congestionada, por exemplo, o monitor de rede pode fazer com que a codificação do vídeo seja reduzida de 1 Mbit/s para 350 Kbit/s ou menos, reduzindo a qualidade do vídeo, mas ainda assim permitindo que a videoconferência continue funcional. Essa questão da adaptação automática às condições da rede ainda mobiliza a pesquisa, apesar de estar bastante consolidada. A organização dos pacotes na rede é feita com base em protocolos de rede, que muitas outras vezes são baseados em padrões abertos como o Real-time Transport Protocol (RTP), mas que outras vezes são protocolos proprietários dos desenvolvedores do software ou hardware que está sendo utilizado. Um protocolo é indispensável para que se saiba como os dados estão trafegando na rede e para possibilitar a recepção e organização dos dados que estão sendo recebidos.

Equipamentos de áudio e vídeo
A utilização de sistemas de videoconferência em diferentes áreas de atuação impulsiona o uso de equipamentos de áudio e vídeo cada vez mais sofisticados. Dependendo do sistema utilizado, é possível conectar diversos equipamentos à videoconferência. Por exemplo: no caso de uso em auditórios, 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 utilização de um microfone sem fio. No caso do vídeo, podem ser acrescentadas câmeras de vídeo auxiliares conectadas a
Administração de Videoconferência

uma mesa de vídeo. Esse caso é indicado quando, por exemplo, se deseja ter uma câmera focando o instrutor e outra focando a plateia. Além disso, já existem câmeras digitais de alta definição com controle remoto, e televisores com excelente resolução, que oferecem alta qualidade de vídeo e são utilizados em sistemas de salas. Esses equipamentos também são encontrados na versão desktop, em que temos um sistema com câmera fixa, microfone, fone de ouvido e alto-falante, permitindo videoconferências via IP ou internet.

6

Tipos de videoconferência
Há basicamente três tipos de sistemas de videoconferência:

11 Sistemas dedicados (hardware) 11 Sistemas de mesa (computador pessoal) 11 Sistemas de webconferência (navegador web)

q

Normalmente, imaginamos que os serviços de um sistema de videoconferência limitam-se à transmissão de vídeo e áudio entre os participantes de uma sala. Embora a funcionalidade básica da videoconferência seja a de encurtar distâncias, eliminando a necessidade da presença física dos participantes em uma reunião, podemos destacar duas classes de serviços essencialmente necessárias para suportar a interação entre os participantes de uma sala de videoconferência: comunicação e colaboração. A comunicação é a facilidade fundamental, enquanto a colaboração é utilizada quando os participantes, além de se comunicarem, ainda trabalham em conjunto compartilhando documentos, planilhas e imagens. A comunicação existe em todos os tipos de videoconferências existentes, enquanto a colaboração é o item que apresenta maiores diferenças conforme o tipo de videoconferência utilizado. Há basicamente três tipos de sistemas de videoconferência: sistemas dedicados de hardware, sistemas de mesa em computadores pessoais, e sistemas de webconferência que utilizam o navegador web.

Sistemas dedicados (hardware)
Geralmente presentes em grandes organizações, que fazem uso de dispositivos dedicados e de software integrado neste dispositivo. Os sistemas dedicados do tipo appliance apre sentam soluções mais robustas, confiáveis e normalmente mais práticas do que as soluções baseadas em PCs.

Sistemas de mesa (desktop)
Ao contrário dos sistemas dedicados, não exigem equipamentos especiais e caros. Sistemas desktop normalmente são vantajosos em relação ao custo (são executados em máquinas de propósito geral, além de poderem usar softwares freeware), mas a qualidade da videoconferência dependerá do hardware com que o sistema está sendo executado. Esses sistemas normalmente apresentam mais funcionalidades adicionais, como quadro interativo, compartilhamento de aplicações, compartilhamento de slides, entre outros.

Sistemas de webconferência
São normalmente compostos por um servidor, responsável por coordenar as diversas sessões/salas de participantes, e os clientes, que utilizam o navegador web. Esses sistemas também apresentam funcionalidades adicionais, como quadro interativo, compartilhamento de aplicações, slides, e assim por diante.
Capítulo 1 - Conceitos fundamentais e soluções

Sistemas dedicados
Todos os componentes (hardware e software) requeridos estão em um único equipamento, que é conectado a uma televisão ou monitor e à rede de dados. O controle do equipamento normalmente é feito à distância, por controle remoto, incluindo o controle da câmera (movimentação, zoom etc.). Existem modelos para diferentes propósitos: grupos grandes, grupos pequenos e ambientes individuais.

q

7

Os sistemas dedicados foram desenvolvidos principalmente para utilização de grupos de usuários, em salas de videoconferência: são sistemas dedicados, geralmente com alta capacidade de processamento e práticos para instalação. O equipamento (algumas vezes chamado de codec) é composto por um hardware dedicado, construído especificamente para videoconferências, os softwares necessários para configurar e utilizar o hardware e diversas entradas e saídas para periféricos. Normalmente os equipamentos já possuem uma câmera acoplada e são acessados a distância por controle remoto. Além disso, esses sistemas podem ser integrados a diversos periféricos, tais como: televisor, computador, videocassete, câmera de documentos e câmera auxiliar. Apesar da diferença existente entre as diversas marcas, versões e tipos de equipamentos, uma característica comum dos sistemas dedicados “topo de linha” é a maior qualidade. Como possuem um hardware dedicado de alto desempenho, estes equipamentos conseguem utilizar resoluções altas (vídeo em HD) e altas taxas de transmissão, o que garante qualidade de áudio e vídeo. Outra característica importante dos sistemas dedicados é a praticidade. Eles já contêm todos os componentes e aplicações necessárias para realizar uma videoconferência, sendo que normalmente só é necessário conectar o equipamento a um monitor, à rede de dados, realizar algumas configurações e ele já pode ser utilizado. São equipamentos que dificilmente requerem manutenção e teoricamente são imunes a vírus. 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. Além disso, este tipo de equipamento geralmente só permite atualizações para recursos específicos quando estiverem disponíveis.
Figura 1.4 Sistemas dedicados para videoconferência.

Polycom V500

Tandberg 990 MXP

Polycom VSX 7000s

Os sistemas dedicados são utilizados por aplicações que primam pela alta qualidade na transmissão de áudio e vídeo, tais como: ensino a distância, palestras, reuniões, telemedicina. Apesar de serem utilizados principalmente em ambientes coletivos, eles também podem ser utilizados individualmente. Hoje em dia, várias empresas disputam o mercado dos sistemas de videoconferência de grande porte, entre elas Polycom, Cisco, Tandberg e Sony.
Administração de Videoconferência

Sistemas de mesa
Recursos agregados ao computador pessoal para torná-lo adequado para uma videoconferência:

q

11 Computador com suporte multimídia 11 Microfone e caixas de som 11 Câmera de vídeo 11 Software (EVO, VSee, Ekiga etc.)

8

O grande diferencial dos sistemas de mesa está no aproveitamento do computador, que já é um equipamento amplamente difundido e utilizado. Estes sistemas normalmente são voltados para uso individual. Para utilizar um sistema deste tipo é necessária a instalação de software, microfone, câmera, e possivelmente outros componentes, que são facilmente acoplados a um computador pessoal, conforme pode ser visto na figura.

Figura 1.5 Estrutura de videoconferência de mesa.

A qualidade de som e imagem depende da qualidade da rede de transmissão e da capacidade de processamento da máquina. Atualmente, a maioria das soluções 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 usuários se comunicarem uns com os outros através de conexões ponto-a-ponto ou multiponto. O sistema adota o padrão H.323, adequado para operações em redes corporativas IP e na internet. O software EVO, da Caltech, é outro exemplo de sistema de mesa que tem evoluído muito nos últimos tempos. Ele conta com suporte H.323, SIP, chat, vários vídeos simultâneos e diversos outros recursos. Outros softwares conhecidos são 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 então o sistema de software livre Ekiga. Ambos suportam SIP e H.323.

Figura 1.6 Exemplos de sistema de videoconferência de mesa.

EVO

Vsee

Ekiga

Sistemas de webconferência
Utilizam o navegador web para efetuar a conferência:

11 Computador com suporte multimídia. 11 Microfone e caixas de som (ou headset).

q

Capítulo 1 - Conceitos fundamentais e soluções

9

11 Câmera de vídeo (webcam, handycam etc.). 11 Navegador web no cliente. 11 Necessitam de máquina servidora para gerência.

q

A grande vantagem dos sistemas de webconferência está na facilidade de efetuar uma videoconferência, visto que não é necessário para o usuário participante instalar qualquer tipo de software na sua máquina, pois tais sistemas funcionam via navegador web. Nesse tipo de sistema, um administrador da conferência normalmente cria uma “sala virtual” e convida os participantes. Essa sala virtual é gerenciada por um servidor localizado em algum ponto, porém isso é transparente para os usuários. Assim, os sistemas de webconferência não só aproveitam o computador do usuário, mas também aproveitam seu navegador web, bem como a porta destinada ao navegador, que normalmente é liberada no firewall, não demandando qualquer liberação de porta aos administradores de rede, o que muitas vezes pode ser traumático numa empresa com políticas rígidas de segurança.

Figura 1.7 Exemplos de sistemas de webconferência.

Adobe Connect

Cenários: Ensino a Distância (EAD)
Videoconferências para ensino a distância 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 auditórios. É necessária uma preparação básica para viabilizar aulas a distância, com uso de TVs ou telões para exibição dos vídeos e de um sistema de videoconferência dedicado para realizar a videoconferência em si. Serão dados dois exemplos abaixo: 1) um modelo mais simples, utilizando uma sala de aula tradicional e sem muitos recursos, permitindo basicamente a visualização do site remoto e dos slides do site remoto; e 2) um modelo mais completo, onde a videoconferência acontece em um auditório, permitindo a visualização adicional dos diversos pontos remotos participantes do evento.
Administração de Videoconferência

Figura 1.8 Exemplos de cenários de ensino a distância. Fonte: http://www. unameseca.com.

10

1. No caso do uso de salas de aula tradicionais, um cenário típico é posicionar o equipa-

mento de videoconferência na parte frontal da sala junto a duas televisões: em uma tela os alunos visualizam o professor e na outra as informações compartilhadas (apresentações, documentos, etc.). Se houver possibilidade de interação dos alunos com o professor remoto, existe um microfone junto ao equipamento de videoconferência, até onde o aluno se dirige para fazer sua pergunta. O microfone já está posicionado em um local de modo que o aluno apareça na câmera.
2. No caso de auditórios ou salas com melhor infraestrutura para videoconferência,

costuma-se utilizar, em vez de duas TVs, um ou mais telões. No telão é possível visualizar o instrutor e também os slides compartilhados, além dos outros participantes remotos. Em um modelo mais complexo também é possível distribuir diversos microfones na sala, para facilitar a interação dos alunos com o professor. No momento que o aluno começa a fazer sua pergunta, a câmera é apontada para ele, de forma manual ou automática.
Figura 1.9 Estrutura do sistema IVA.

Um cenário de aula a distância pode ser caracterizado por alunos distribuídos em vários pontos ou por um workshop reunindo especialistas para a discussão de um tema específico.

Adiante neste curso será detalhado o sistema Interativo de Vídeo 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 Distância de 2007-2008.
Capítulo 1 - Conceitos fundamentais e soluções

Cenários: reuniões de trabalho
Em comparação ao cenário de EAD, reuniões de trabalho normalmente são compostas por um número menor de participantes e terão muito mais interação entre os pontos remotos, ou seja, é uma discussão, não uma palestra. As reuniões são realizadas em salas usualmente com uma mesa ao centro e o equipamento de videoconferência em uma de suas pontas. Algumas vezes são utilizadas telas grandes para aumentar a sensação de que as pessoas estão no mesmo local (ver o cenário de telepresença a seguir). Por ser uma discussão, os participantes devem ter acesso fácil 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

Cenários: telepresença
Telepresença é o nome dado aos sistemas de videoconferência que procuram reduzir ao máximo a sensação de distância entre os pontos remotos, procurando criar a ilusão de que todos estejam em um mesmo ambiente. O cenário é semelhante ao das reuniões de trabalho, mas são utilizadas televisões ainda maiores e cuidadosamente posicionadas, para que as pessoas sejam exibidas com seu tamanho real e pareçam estar posicionadas no mesmo ambiente (sentadas na mesma mesa, por exemplo).

Figura 1.11 Exemplo de sala de telepresença (Cisco).

Cenários: Telemedicina
Operando desde 2006, a Rede Universitária de Telemedicina, um programa do Ministério da
Administração de Videoconferência

Ciência, Tecnologia e Inovação (MCTI) e executado pela Rede Nacional de Ensino e Pesquisa (RNP), formalizou a criação e implantação de núcleos de telemedicina/ telessaúde, garantindo a conectividade de 55 hospitais universitários e de ensino à rede Ipê da RNP. Em 2011, 8 novos núcleos de telemedicina RUTE foram inaugurados, faltando núcleos apenas em três estados (PI, RO, RR), que serão inaugurados em 2012. Além disso, pode-se destacar como iniciativas bem-sucedidas: 15 salas de videoconferência homologadas; mais de 600 vídeo e webconferências realizadas em 47 especialidades da saúde, com participação de 313 instituições; assinatura com a RNP de 28 novos termos de cooperação técnica com hospitais de ensino. A partir de 2012, 75 hospitais em todo o país serão integrados ao projeto.

12

Para a telemedicina, o fator mais importante de uma videoconferência costuma ser a qualidade das imagens. Para muitas aplicações na telemedicina é necessária alta qualidade na resolução de imagens para permitir, por exemplo, um diagnóstico correto de doenças. Outro exemplo é o projeto POA_S@UDE de telemedicina implementado no Hospital Materno Infantil Presidente Vargas (HMIPV), próximo ao centro de Porto Alegre/RS, onde um sistema é utilizado para realização de tele-ultrassonografias em pacientes de regiões mais remotas, onde é difícil o acesso a médicos especializados.

Figura 1.12 Médico remoto efetua laudo à distância. Fonte: http://www.inf. ufrgs.br/prav/pro jetos_poasaude.php

Dispositivos adicionais
Além da troca de áudio e vídeo entre os participantes, outro objetivo de uma videoconferência é promover suporte à colaboração e cooperação, oferecendo ferramentas que permitam a interação e o trabalho em grupo. Para tanto, já existem serviços de suporte à colaboração que vêm sendo agregados aos serviços de videoconferência, visando criar condições para o trabalho cooperativo entre equipes remotamente situadas. Uma alternativa para serviços de colaboração é a utilização de padrões internacionais, e um deles, utilizado para transferência de dados, é o protocolo ITU T.120. Esse protocolo designa uma família de padrões abertos que definem práticas para a transmissão de dados. Várias empresas adotam o T.120 nas suas respectivas soluções, tais como: Apple, AT&T, British Telecom, Cisco Systems, Intel, MCI, Microsoft e PictureTel. Os serviços de suporte à colaboração são implementados por ferramentas geralmente encontradas nos terminais de videoconferência. Como exemplos dessas ferramentas, podemos citar a câmera de documentos, o quadro interativo e o chat. A seguir, detalhamos algumas dessas ferramentas de colaboração visual.

Câmera de documentos
Câmera de alta resolução que captura e transmite imagens de documentos e outros objetos físicos. Valoriza e dá maior impacto às apresentações audiovisuais.

A câmera de documentos é utilizada para digitalizar documentos, objetos, formas tridimensionais, documentos impressos e material gráfico de qualquer natureza. Consiste numa câmera estática usada para enviar imagens (transformadas em vídeos) de documentos, materiais impressos, transparências, slides e raios-X, além de objetos tridimensionais.

Capítulo 1 - Conceitos fundamentais e soluções

q

13

Figura 1.13 Câmera de documentos.

Quadro interativo
Tudo o que é escrito ou desenhado no quadro é digitalizado, facilitando visualização remota. O clique do mouse pode ser feito com o dedo ou caneta diretamente no quadro branco. Sua aplicação ocorre principalmente em EAD, pois substitui o quadro-negro tradicional em salas de aula. O quadro interativo (ou eletrônico) oferece uma espécie de espaço virtual compartilhado pelos participantes, em que todas as ações realizadas são capturadas em tempo real e disponibilizadas (como vídeos) na videoconferência. 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 videoconferência.

q

StarBoard – Hitachi Entrada RGB, saída USB

Figura 1.14 Exemplos de quadro interativo.

A seguir veremos outras abordagens para quadros interativos.

Tablet
Administração de Videoconferência

Notebook ultraportátil (≈ 1 kg) com recursos para escrever ou inserir dados diretamente na tela por meio de uma caneta metálica. Permite a exibição de vídeos, inclusão de anotações e envio e gravação das imagens. É uma alternativa ao quadro eletrônico, já que a imagem do tablet pode ser projetada em uma tela.

q

14

iPad

Figura 1.15 Tablet.

Um tablet é um computador portátil (normalmente mais portátil e leve que um notebook) que permite a inserção de dados através do contato na tela do computador (multitouch). O contato normalmente é feito através de uma caneta ou dedo, que permite que o usuário desenhe, escreva e insira dados diversos na máquina como se estivesse escrevendo em uma folha de papel. Os dispositivos normalmente permitem escrever sobre aplicações e gravar estas anotações. Isso torna os tablets muito úteis em ambientes escolares, onde as anotações dos alunos podem ser inseridas sobre as apresentações do professor, por exemplo. Dependendo do sistema e das aplicações utilizadas, também é possível converter texto escrito à mão para texto no computador (inclusive equações).

Sistemas com alta definição
É importante ressaltar a diferença da relação de aspecto entre Standard Definition (SD) e High Definition (HD). SD não é um nome dado a apenas uma resolução específica, ou seja, há mais de um formato de vídeo que pode ser chamado de SD – o mesmo vale para HD. O SD é caracterizado pelas resoluções 720x480 e 720x576, que são utilizadas no sistema de televisão tradicional. Já o HD é caracterizado por resoluções 720p (1280x720) e 1080p ou 1080i (1920x1080), assim como resoluções maiores do que estas. As letras “p” e “i” na nomenclatura indicam sistemas “progressivos” ou “entrelaçados”, respectivamente. Devido a esta diferença entre as resoluções HD (e por questões de marketing), as resoluções 1920x1080 passaram a ser chamadas de Full HD, diferenciando-a das resoluções inferiores.

SD

Razão de aspecto 4:3

HD

Razão de aspecto 16:9

Figura 1.16 Exemplos de Standard Definition e High Definition.

Widescreen (20% mais largo)

Capítulo 1 - Conceitos fundamentais e soluções

15

Formato SD HD Resolução mínima Full p: Vídeo progressivo i: Vídeo entrelaçado

Resoluções 720x480, 720x576 1280x720p 1920x1080i, 1920x1080p e maiores
Figura 1.17 Resoluções SD e HD.

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

Câmera Tandberg Precision HD

Polycom HDX Series

O mercado de equipamentos de videoconferência é bastante competitivo, o que tem provocado um avanço tecnológico significativo nos últimos anos. Empresas como Polycom, Tandberg e Sony já disponibilizam equipamentos com alta definição, áudio e vídeo de excelente qualidade, o que torna a videoconferência mais realista e possibilita sua aplicação em outras áreas, como na telemedicina.

Relação de aspecto
É a proporção entre a largura e altura e dos pixels que compõem uma imagem digital.

11 Vídeo: arquivo “widescreen-explanation.swf”. 11 Adaptação da relação de aspecto ( pillarboxes e letterboxes). 11 Adaptação da relação de aspecto de 16:9 para 4:3. 11 Adaptação da relação de aspecto de 4:3 para 16:9.
Relação de aspecto (aspect ratio) é a proporção entre a largura e altura e dos pixels que

q

compõem uma imagem digital. O exemplo mais tradicional é a relação 4:3, utilizada na televisão analógica tradicional. Outra relação de aspecto comum atualmente é a 16:9, utilizada em televisões HD. Apesar de alguns dispositivos, como DVDs, exibirem conteúdos de 4:3 em 16:9 e vice-versa, muitas vezes é necessário adaptar esta relação de aspecto para o formato do dispositivo onde elas serão exibidas. Nestes casos são utilizadas as letterboxes, ou seja, as barras pretas na parte superior e inferior dos vídeos (ou nas laterais). Elas são utilizadas
Administração de Videoconferência

para que os vídeos possam ser exibidos em sua relação de aspecto original em dispositivos que utilizam outra resolução 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 adaptação da relação de aspecto, além da possibilidade de pillarboxes ou letterboxes, também é possível utilizar outras técnicas, que normalmente são o redimensionamento do vídeo e a remoção de alguma área dele.

X

X

Figura 1.20 Técnica de redimensionamento de vídeo.

Redimensionamento

Remoção de áreas

Para adaptar um vídeo em 16:9 para monitores 4:3, uma alternativa é redimensionar o vídeo, ou seja, encolher o vídeo horizontalmente até que sua relação de aspecto seja 4:3, o que acaba deformando as imagens. Uma alternativa é remover áreas laterais do vídeo, transformando-o em 4:3 sem necessidade de redimensionamento. Esta alternativa costuma ser chamada de pan and scan, e causa perdas de conteúdo do vídeo, já que algumas de suas partes serão completamente removidas. Porém, ela mantém as imagens com seu aspecto original. Para adaptar um vídeo em 4:3 para monitores 16:9, além do uso de pillarboxes, é possível utilizar dois outros métodos: redimensionamento com e sem remoção de áreas. Redimensionar um vídeo 4:3 para 16:9 gera uma expansão horizontal do vídeo, o que acaba deformando as imagens. Outra alternativa é remover barras na parte superior e inferior do vídeo (tornando-o 16:9) e depois redimensioná-lo para a resolução desejada. Esta última alternativa não deforma a imagem, mas gera perda de conteúdo do vídeo.

X

X

Figura 1.21 Técnica de redimen sionamento sem e com remoção de áreas.

Redimensionamento

Remoção de áreas

Estruturação de um serviço
Identificar as necessidades dos usuários:

11 Tipo de comunicação: ponto-a-ponto ou multiponto. 11 Qualidade: padrão SD ou HD. 11 Tipos de dados que serão compartilhados: documentos eletrônicos ou impressos,
vídeos etc.

q

Capítulo 1 - Conceitos fundamentais e soluções

17

Um serviço de comunicação é caracterizado por um canal de comunicação em que interlocutores enviam e recebem mensagens. O suporte à comunicação interpessoal é a essência de uma videoconferência. De acordo com a dinâmica estabelecida entre os interlocutores de um canal comunicativo, podemos distinguir o serviço de comunicação entre:
1. Comunicação 1:1 (um-para-um) 2. Comunicação 1:n (um-para-muitos) 3. Comunicação n:n (muitos-para-muitos)

As mensagens são transmitidas entre máquinas em uma rede de computadores através de chamadas, que podem ser (de acordo com as formas de comunicação citadas):
1. Ponto-a-ponto: uma máquina-origem envia mensagens para uma máquina-destino. 2. Multiponto unidirecional: uma máquina-origem envia mensagens para “n”

máquinas-destino.
3. Multiponto bidirecional: “n” máquinas enviam mensagens às demais.

Internet

Figura 1.22 Comunicação ponto-a-ponto (1:1).

No caso de uma comunicação ponto-a-ponto “um-para-um”, cada participante visualiza a imagem do participante remoto maximizada na tela. Além desta imagem, a maioria dos sistemas atuais permite que o participante veja a sua própria imagem em uma região reduzida da tela ( preview local para verificar se o enquadramento está bom). Geralmente, o participante pode escolher se deseja visualizar essas duas opções simultaneamente ou apenas a imagem remota.

Internet

Visão Local

Administração de Videoconferência

Imagem local e remota

Figura 1.23 Comunicação ponto-a-ponto (1:n).

Em uma comunicação ponto-a-ponto “um-para-muitos”, há um participante de um lado interagindo com um grupo que está em uma sala remota. Em relação à parte técnica da videoconferência, esta comunicação é praticamente igual às comunicações 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 também vale para os outros casos de comunicação).

18

Este modelo de comunicação é comum em encontros que envolvem vários participantes localizados em uma sala de apresentação, além de mais um participante remoto conectado a um terminal de videoconferência. Um exemplo prático desse tipo de situação é a apresentação de palestras a distância, em que um ponto de origem (o instrutor) interage por meio de videoconferência com um grupo de participantes remotos (alunos). Nesse caso, as mensagens seguem em uma chamada ponto-a-ponto da máquina-origem para a máquina-destino, embora a comunicação seja do tipo “um-para-muitos”. Neste modelo é necessário ter cuidados com o posicionamento do microfone e da câmera, especialmente na sala com vários participantes. A câmera deve ter uma visão de todos os participantes da sala e o microfone deve estar acessível a todos.

Internet

Visão Local

Visão Local

Figura 1.24 Comunicação ponto-a-ponto (n:n).

Imagem local e remota

Imagem local e remota

Em uma comunicação ponto-a-ponto “muitos para muitos”, há dois grupos, um em cada local, interagindo a partir de uma sala de videoconferência. Assim como no modelo anterior, também deve-se ter o cuidado adicional com o posicionamento da câmera e do microfone, neste caso não apenas em uma, mas em duas salas. Mais complexo que o modelo de comunicação ponto-a-ponto é o modelo multiponto, ou seja, uma situação onde temos mais de dois locais conectados em uma conferência. Há vários casos em que esse modelo é utilizado. Exemplos: numa reunião de negócios, 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

Visão Local
Capítulo 1 - Conceitos fundamentais e soluções

Figura 1.25 Comunicação multiponto.

Imagem local e remota

A chamada multiponto necessita de um controle especial para gerenciar os “n” fluxos gerados, e essa responsabilidade pode ser efetuada de diferentes maneiras, como através de uma entidade chamada Multipoint Control Unit (MCU), ou através de um sistema central por software, ou mesmo sem entidade central, onde cada participante envia o sinal a todos. Esses mecanismos serão detalhados posteriormente.

19

Entenda as necessidades dos usuários e conheça a estrutura que será usada nas videoconferências, além da verba disponível. Verifique ainda a sala que será usada para a instalação do sistema:

q

11 Sala: individual, de reunião ou de aula, ou ainda um auditório ou sala específica
(consultório, centro cirúrgico etc).

11 Qual o tipo de microfone adequado? 11 Qual o tipo de câmera de vídeo adequada? 11 Qual a banda de rede disponível?
O tópico da estrutura da sala de videoconferência será abordado em outra sessão deste curso. No momento basta dizer que a estruturação da sala é um ponto extremamente importante para a definição de um ambiente de videoconferência.

Para pensar
É importante ter uma estimativa da verba disponível para o projeto, pois muitas vezes é ela que determina a qualidade dos equipamentos e a quantidade de recursos adicionais que serão agregados ao sistema. Sistemas dedicados costumam ser mais práticos, mas apresentam custos elevados. Para reduzir os custos é possível buscar soluções em software, especialmente as soluções free, como o GNU Gatekeeper.

Por exemplo, se o caso for de comunicação multiponto e não houver verba para aquisição de um controlador de chamadas multiponto (MCU), isso pode ser um ponto crítico no projeto. Algumas alternativas:

11 Usar uma MCU de terceiros; 11 Adquirir equipamentos de videoconferência já com suporte multiponto; 11 Pensar na possibilidade de usar uma solução baseada na web (webconferência), onde
geralmente o suporte multiponto está implícito;

11 Utilizar MCU em software.
Assim, entendendo as necessidades dos usuários, conhecendo a estrutura que será usada nas videoconferências e a verba disponível, é possível especificar o equipamento e os recursos que serão necessários.

20

Administração de Videoconferência

Roteiro de Atividades 1
Atividade 1 – Sistema de conferência em desktop
O aluno deverá realizar uma conferência ponto-a-ponto (1:1) por áudio e vídeo com o colega ao lado. Para isso, deverá instalar e configurar o software disponibilizado para esta atividade, conforme as orientações do instrutor. Dicas para a configuração do software de videoconferência:

11 Geral: a aplicação pode solicitar nome de usuário; 11 Vídeo: verificar se a fonte de vídeo é a correta; 11 Áudio: verificar se a entrada e saída de áudio estão configuradas; 11 Rede:verificar se o adaptador de rede selecionado é o correto; 11 Protocolos: localizar os protocolos de comunicação disponíveis (SIP e H.323).
1. Realizada a verificação do aplicativo, os alunos se organizarão em duplas para realizar

uma chamada (1:1) com o software. Para isso, disque para o endereço IP do destino.
2. Ajuste o áudio e o vídeo da chamada. 3. Refaça a chamada invertendo o originador dela.

Atividade 2 – Funcionalidades do sistema
Nesta atividade vamos explorar as funcionalidades do software, monitorando o volume de tráfego da rede durante a realização de uma conferência. Para isso deve-se utilizar um software de análise de banda em tempo real, conforme orientação do instrutor. Os procedimentos descritos a seguir podem exigir o reinício das chamadas para que as configurações tenham efeito.

11 Nas configurações do software de videoconferência, altere a velocidade (taxa de conexão
ou banda) para o mínimo possível (desde que esse mínimo permita transmissão de áudio e vídeo). Verifique visualmente a qualidade. Refaça a chamada para o máximo de banda que o software oferece. Verifique a qualidade. Houve mudança visível de qualidade? Por quê?

11 Verifique a banda utilizada pela aplicação durante a chamada. Habilite e desabilite a
transmissão de vídeo para observar as diferenças. Verifique também se a banda de rede é fixa ou se há variações. Compartilhe algum tipo de dado (quadro branco, apresentaatividade do usuário. Responda as questões a seguir:
1. Por que as novas chamadas só podem ser feitas por IP? Por que não funciona chamar
Capítulo 1 - Roteiro de Atividades

ções ou desktop). Verifique as variações imediatas da rede conforme acontece alguma

pelo nome inserido nas configurações do software do colega?

21

2. Dado que dois pontos utilizam o sistema de videoconferência, 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 configuração do sistema de videoconferência, especificamente a de con-

figuração H.323 e SIP. Que protocolo de sinalização está sendo usado na comunicação entre os sistemas? Justifique.

Atividade 3 – Medindo o atraso da transmissão
Nesta atividade o aluno deverá medir o atraso que ocorre em uma sessão de videoconferência, desde a captura da imagem pela câmera até a exibição 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 cronômetro no computador. Passo 1: dispare o cronômetro na máquina A. Passo 2: a máquina A filma com a webcam o seu cronômetro, transmitindo essa imagem para a máquina B. Passo 3: a máquina B filma o sinal recebido de A, enviando-o de volta. Passo 4: agora a máquina A possui a imagem original do cronômetro rodando numa janela e a imagem do cronômetro que foi e voltou através do software de videoconferência. Com isso dá para saber o atraso de ida e volta. Capture a tela (printscreen) a partir da máquina A para ver o atraso. Responda às questões:
1. Cite pelo menos três causas de atrasos observados em videoconferências.

2. Qual o valor do atraso observado numa conexão abaixo de 256Kbit/s?

Administração de Videoconferência

3. Modifique a banda para ~2Mbit/s e meça novamente o atraso. Qual o valor do atraso?

Ele variou ou ficou igual? Justifique.

22

2
Padrões de videoconferência
objetivos
Proporcionar uma visão ampla dos padrões de videoconferência existentes atualmente com foco no padrão H.323.

conceitos

Princípios de codificação de áudio e vídeo, padrão de comunicação H.323, protocolo de sinalização H.323.

Introdução a padrões e protocolos
Imagine uma reunião com a participação de várias pessoas: para que haja uma comunicação efetiva entre todas elas, é necessário que os participantes se façam entender, dominando um mesmo idioma e vocabulário. Sem o estabelecimento de uma linguagem comum, não haverá entendimento entre os participantes da conversa. Imaginemos agora a mesma situação só que com computadores distribuídos em uma rede em vez de pessoas. Nesse caso, além da infraestrutura de redes, é necessária uma linguagem padronizada para que haja uma comunicação efetiva entre os computadores. Para garantir que os computadores “falem a mesma língua”, existem diversos padrões e protocolos que regem essa comunicação. Esses padrões e protocolos são objeto de estudo de diversas organizações, que trabalham no seu desenvolvimento e manutenção. Dentre estas organizações, as mais notáveis em relação a padrões de videoconferência são: ITU-T, IETF e MPEG.

Padronização
Organizações que estabelecem normas e protocolos para videoconferência: 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 organizações que atua no desenvolvimento de padrões reconhecidos internacionalmente, no intuito de viabilizar a interação entre computadores e outros equipamentos de telecomunicações. Esse órgão

internacional, responsável por estabelecer recomendações para telecomunicações, divide-se em grupos de estudo onde cada grupo é incumbido de investigar um conjunto de questões, cujos resultados definem as recomendações estabelecidas pela ITU-T.

Capítulo 2 - Padrões de videoconferência

q

23

Um desses grupos, responsável pela família ITU H.3xx, é encarregado por estabelecer recomendações para colaboração de dados e videoconferência, ou seja, pela formalização de padrões para comunicação multimídia sobre redes IP. A Internet Engineering Task Force (IETF) é uma comunidade internacional aberta, constituída de administradores, operadores e pesquisadores concentrados em padronizar a evolução da arquitetura da internet e a operação da rede. A IETF está aberta a qualquer indivíduo interessado. O trabalho técnico da IETF também é realizado em grupos de estudo, organizados por tópicos de interesse em diversas áreas, como distribuição, transporte, segurança etc. Outra preocupação de padronização diz respeito às estratégias de compressão e transmissão de dados multimídia. Hoje em dia, existem cada vez mais aplicações que envolvem áudio, vídeo e dados à disposição de um público distribuído e crescente. A explosão da internet na década de 1990 levou milhares de usuários a utilizarem esses serviços com intuito profissional, comercial ou doméstico. Assim, a internet agrega um volume de dados multimídia cada vez maior, o que eleva a demanda de banda e a necessidade de estratégias eficientes para transmissão desses dados. Nesse sentido, uma organização aborda mecanismos para codificação e transmissão de áudio e vídeo. O grupo Moving Picture Experts Group (MPEG) é uma organização que regulamenta padrões para transmissão e compressão de áudio e vídeo. Os esforços desse grupo contam, atualmente, com três padrões que incluem compressão de vídeo: MPEG-1, MPEG-2 e MPEG-4. O MPEG ainda possui outros padrões associados: o MPEG-7 – responsável pela descrição de conteúdo multimídia (metadados) – e o MPEG-21, responsável pela definição de um framework multimídia. Esse padrão será detalhado adiante. Os padrões ITU-T de videoconferência exigem dos fabricantes a implementação de um conjunto mínimo de padrões de compressão de áudio e vídeo. Há padrões opcionais que também podem ser utilizados nos sistemas de videoconferência. Além disso, cada fabricante pode adicionar padrões proprietários às suas soluções. Conjunto mínimo + padrões opcionais + padrões proprietários Os padrões de videoconferência especificam um conjunto mínimo de padrões ITU-T de compressão de áudio e vídeo que deve ser implementado para que um sistema seja homologado conforme este padrão. E além deste conjunto mínimo, existem os padrões opcionais, que normalmente são mais complexos, como o H.264 para vídeo. Muitos sistemas ainda incluem métodos proprietários de codificação de vídeo e áudio. Por serem métodos proprietários, onde muitas vezes apenas o próprio fabricante sabe como o método funciona, outros sistemas dificilmente terão suporte a esses métodos, o que impossibilita a interoperação entre os sistemas. Apesar disso, métodos proprietários podem ser utilizados como um diferencial quando um fabricante desenvolve um método novo ou otimiza um método de codificação, por exemplo. Nesse caso, normalmente o cliente deverá possuir
Administração de Videoconferência

q

equipamentos do mesmo fabricante em todas as pontas, a fim de poder utilizar o padrão.

Princípios de codificação de áudio
Como converter áudio analógico em digital? 11 PCM (Pulse Code Modulation): 11 sinal é discretizado (gera um erro de amostragem). Como minimizar o erro de quantização (duas formas)?

q

24

Qual taxa de amostragem deve ser utilizada supondo que: 11 Frequência da voz humana: 20 Hz – 6.000 Hz (porém banda de 4kHz oferece perfeita inteligibilidade). 11 Frequência do ouvido humano: 20 Hz – 20.000 Hz. 22 Qual o número de níveis e amostras no PCM comercial? 22 Compansão 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?

q

O primeiro passo para a codificação de áudio consiste na captura dos sinais sonoros (ondas sonoras) e na transformação deles em sinais digitais. Como esta conversão de sinais analógicos para sinais digitais é feita? Uma técnica bastante utilizada em telefonia é a técnica PCM, que analisa o sinal analógico em instantes uniformes de tempo, obtém a magnitude do sinal nestes instantes e representa esta magnitude de forma numérica (de forma binária). A imagem abaixo mostra um exemplo de um sinal de áudio analógico que será convertido para digital:

Figura 2.1 Onda analógica a ser convertida.

No gráfico 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 gráfico marcam os momentos em que serão obtidas amostras da onda sonora, ou seja, os momentos onde a magnitude da onda será representada por um número binário. O próximo gráfico mostra o resultado da aplicação 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 Aplicação do Pulse Code Modulation.

O eixo y mostra uma escala com um número para cada linha horizontal. Este número está representado em binário (com 3 bits para facilitar o entendimento) e corresponde ao símbolo 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 então o símbolo associado a esta

Capítulo 2 - Padrões de videoconferência

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 símbolos que a representam. Esses símbolos estão exibidos no gráfico ao longo do eixo x (“000”, “011”, “100” etc.). A linha cinza mostra o formato com que a onda passa a ser representada após 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 definição do número de amostras obtidas é um parâmetro muito importante do processo, que influencia diretamente na qualidade do sinal digital. Quanto maior o número de amostras, maior será a proximidade do sinal digital com o sinal analógico, mas também maior será a quantidade de dados necessários para representar este sinal. O teorema de Nyquist indica que a taxa de amostragem do sinal deve ser de pelo menos o dobro da frequência do sinal. Este teorema é muito usado como base para definição da taxa de amostragem utilizada. A definição da taxa de amostragem normalmente é baseada na frequência 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 inteligível, pois frequências altas são mais raras. Portanto, muitos sistemas que trabalham com voz humana tomam como base a frequência de 4 kHz. Segundo o teorema de Nyquist, a taxa de amostragem deve ser pelo menos duas vezes a frequência 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 frequências acima de 20 kHz não podem ser ouvidos. Este conhecimento costuma ser utilizado na digitalização de sons mais complexos que a voz, onde se deseja a capacidade de representação de todo o espectro de frequências 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 frequência máxima ouvida pelo homem. Outro parâmetro que influencia diretamente na qualidade do sinal digital é o número de bits utilizado em cada amostra. No exemplo anterior foram utilizados 3 bits por motivos didáticos. Com um número maior de bits é possível representar mais fielmente o sinal analógico (mais linhas horizontais no gráfico), reduzindo a diferença entre os sinais, o que é chamado de erro de quantização. Em CDs de áudio, são utilizados 16 bits para cada amostra. Em telefonia se trabalha com 8 bits por amostra. Outra técnica aplicada durante a digitalização de sinais sonoros é a compansão do sinal, representada na figura a seguir. Este processo é necessário, 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 digitalização, pois seriam necessários muitos bits para representar cada
Administração de Videoconferência

amostra (o ideal seriam 13 bits por amostra; comercialmente são usados 8). No processo de compansão, os sinais mais fracos são elevados e os mais fortes são reduzidos, e assim todos podem ser representados por um número fixo de bits, pois o sinal analógico da voz é “homogeneizado”. Dessa forma, se a pessoa fala baixo, sua voz é amplificada antes da digitalização. Se fala alto, não é amplificada. Assim, todos os sinais podem ser representados com os 8 bits, economizando na taxa de transmissão via rede. As duas formas mais utilizadas de compansão são chamadas de “lei A” (mais usada na Europa) e “lei μ” (mais usada nos Estados Unidos e Japão).

26

Vs

• Compansão segundo lei A ou µ (analógico)
Figura 2.3 Curva de compansão da voz (entrada/saída).

• Usar 13 bits e comprimir segundo lei A ou µ (digital)

Ve

Padrões de áudio
A figura abaixo mostra um resumo da faixa de frequência, taxas de transmissão e latência utilizada nos principais padrões de codificação de áudio. Padrão G.711 G.722 G.722.2 G.723.1 G.728 G.729
Figura 2.4 Resumo das faixas de frequência.

Faixa de frequência 300 Hz - 3.4 kHz 50 Hz - 7 kHz 50 Hz - 7 kHz 8 kHz 300 Hz - 3.4 kHz 8 kHz

Taxa de transmissão 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

Latência <1 <2 100 <2 25 - 35

Qualidade Excelente Boa Razoável Boa Boa

Abaixo temos uma breve descrição de cada um dos padrões: 11 G.711 – mandatório para todos os sistemas H.3xx. Possui áudio com qualidade de telefonia padrão. Indicado para uso em conferências com taxa disponível de pelo menos 128 kbit/s. 11 G.722 – produz áudio de boa qualidade, e aumenta a resposta em frequência em relação ao G.711 (vai até 7 kHz). 11 G.722.1 – possui taxas mais baixas de compressão (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 são úteis em condições de barulho de fundo e música. Licenciado pela VoiceAge 11 Adaptive Multi-Rate - WideBand (AMR-WB) – recomendado no anexo C do G.722.1, tornando possível o uso de uma resposta em frequência 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 latência e qualidade de áudio, muitas vezes é substituído pelo G.711. 11 G.726 – transmissão 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 comparação ao G.711, porém piora em termos de atraso.
Capítulo 2 - Padrões de videoconferência

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 extensões que utilizam as taxas de 6,4 e 11,8 kbit/s). 11 G.729a – anexo do G.729 que provê uma variação do original com menos computação, embora a qualidade da voz fique pior. Às vezes é usado quando há necessidade de envio simultâneo de voz e dados. 11 G.729b – outro anexo do G.729 que contém um método de compressão de silêncio, que possibilita a detecção de atividade (voz) no sinal. 11 G.729.1 – desenvolvido para prover melhor qualidade e mais flexibilidade do que o G.729, sendo interoperável com este. Opera nas taxas de 8 a 32 kbit/s.

Princípios de codificação de vídeo
11 O vídeo é uma sequência de imagens estáticas. 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 codificação de áudio, a codificação de vídeo é o processo de digitalização dos sinais analógicos de vídeo após serem capturados por algum dispositivo (como uma câmera de vídeo). 11 Um vídeo é um conjunto de imagens estáticas, dispostas em sequência e exibidas rapidamente uma após a outra. Em 1832, Plateau descobriu que são necessárias pelo menos 10 imagens por segundo para que um vídeo passe a ideia de movimento para uma pessoa, devido a um fenômeno no cérebro conhecido como “persistência retiniana”, que mantém a imagem na retina por alguns milisegundos após a imagem ter sido modificada.

q

Figura 2.5 Teoria de Plateau.

Atualmente são usadas taxas de 24 quadros (imagens) por segundo no cinema e 25 ou 30 quadros por segundo em sistemas de televisão. Sistemas mais modernos de alta capacidade já utilizam taxas de 50 e 60 quadros por segundo.
Administração de Videoconferência

Por que comprimir?
Calcule: 11 Taxa em bit/s de vídeo SD não comprimido (Standard Definition – 720x480, RGB, 30 qps) 11 Taxa em bit/s de vídeo HD não comprimido (High Definition – 1920x1080p, RGB, 30 qps)

q

28

Três componentes fundamentais: R, G e B compõem qualquer cor por emissão 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 vídeo analógico é capturado e convertido para o formato digital. O processo é diferente do utilizado para áudio. No vídeo, 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 três cores básicas, o vermelho, o verde e o azul, formando os três planos (ou matrizes) que compõem a imagem (RGB). Além do RGB, a imagem pode também ser representada de outras formas, como o YUV, muito utilizado na codificação de vídeo. 11 Para compressão dos vídeos gerados após a captura, os codificadores utilizam técnicas para reduzir redundâncias de diversos tipos presentes no vídeo: 11 Redundância espacial. 11 Redundância temporal. 11 Redundância psicovisual. 11 Redundância de codificação (entrópica).

q

Redundância espacial
A redundância espacial ocorre em pixels de uma mesma imagem, isto é, pixels vizinhos no espaço tendem a ser muito parecidos (ou iguais). É normal que imagens possuam regiões homogêneas, onde as cores são praticamente iguais. Estas regiões são 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 região é semelhante.

q

Capítulo 2 - Padrões de videoconferência

29

Figura 2.8 Áreas com redundância espacial.

Redundância temporal
Quadros vizinhos temporalmente possuem diversos pixels similares, seja na mesma posição (círculo azul) ou em posições próximas (círculo vermelho).

q

A redundância temporal é percebida entre quadros vizinhos. Assim como um quadro pode ter regiões muito homogêneas, dois quadros vizinhos podem ser muito parecidos. Nestes casos, o codificador pode simplesmente informar que determinada região de um quadro é exatamente igual à mesma região no quadro anterior (área maior marcada na imagem), ou então que esta região é igual uma região localizada em outro local no quadro anterior (área menor marcada na imagem). Essa indicação do deslocamento do bloco na imagem de referência é conhecida como “vetor de movimento”.
Quadro 1 Quadro 2

Figura 2.9 Áreas com redundância nos quadros.

Redundância psicovisual
O sistema visual humano é mais sensível às informações de brilho do que de cor, pois no olho humano existem 240 milhões de bastonetes (brilho) e 13 milhões de cones (cores). Por isso podem ser utilizados mais dados (bits) para representar brilho do que cores.
Administração de Videoconferência

q

Isso requer uma transformação do sistema RGB (Red Green Blue) para YCbCr (luminância Y – imagem em preto e branco e crominâncias Cb e Cr – cores associadas). Relações dos componentes de cores: redução de 4:4:4 para 4:2:2 (33% de compressão) ou 4:2:0 (50% de compressão). A redundância psicovisual leva em consideração 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 variações de brilho do que de cores. Na prática, isso corresponde a utilizar um número maior de bits para representação do brilho.

30

A redundância 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, após a captação da luz na câmera pelo CCD ou CMOS: 11 4:4:4 – amostragem total, sem compressão, utilizada mais em cinema, por causa das técnicas de chroma key. Mantém todas as cores na máxima resolução. 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 compressão de 33% do tamanho do vídeo digital, com o mínimo de perda em cor, sendo utilizada em todos os sistemas de TV digital. 11 4:2:0 – o quádruplo de bits para brilho (4) do que para os componentes de cor (2 para ambos), amostragem que comprime o sinal em 50% com perda mínima de cores, sendo usada nos sistemas de câmeras do tipo handycam, e também para videoconferências.

q

Redundância de codificação (entrópica)
A redundância de codificação não é vista na análise das imagens como as outras redundâncias, mas na análise da sequência de bits gerada após a codificação das imagens. Nesta sequência de bits, muitos padrões se repetem, como, por exemplo, sequências grandes de ZEs. Existem diversas técnicas para reduzir esta redundância (técnicas de codificação entrópica). Entre as técnicas utilizadas estão a codificação de Huffman, que representa os dados de entrada com símbolos, utilizando símbolos menores para os dados de entrada mais frequentes e símbolos maiores para os menos frequentes. Há também a codificação aritmética, que representa os dados por números de ponto flutuante. Ao contrário de outras técnicas utilizadas na compressão, a codificação entrópica não introduz perda, ou seja, a imagem codificada pode ser restaurada para seu estado original (exatamente como era) depois de decodificada. A compressão de vídeo é um artifício importante para os sistemas de videoconferência, pois reduz sensivelmente o fluxo de dados transmitidos na rede, embora, por outro lado, aumente a necessidade de processamento nos terminais da videoconferência, pois é necessário fazer a codificação/decodificação do vídeo para exibi-lo nos clientes, o que pode retardar um pouco a dinâmica do processo e provocar uma latência maior.

Padrões de vídeo
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++
Capítulo 2 - Padrões de videoconferência

H.264/AVC MPEG-4 parte 10 MPEG-4

H.265

Figura 2.10 Evolução dos padrões de vídeo.

1988 1990

1993

1995

1997

2000

2003

2013

O gráfico mostra a evolução na padronização da codificação de vídeo. A norma H.261, finalizada no início dos anos 90, foi a primeira iniciativa da organização ITU de gerar um padrão para aplicações de teleconferência. Alguns anos depois, o grupo MPEG lançou o padrão MPEG-1 visando principalmente aplicações de armazenamento de vídeo. Posteriormente as duas organizações lançaram em conjunto a especificação H.262/MPEG-2 (H.262 pela enti-

31

dade ITU e MPEG-2 pela organização MPEG), que veio a se tornar o padrão mais difundido para aplicações de vídeo digital, como DVD e TV digital. O H.263 veio como uma evolução do H.261, e teve algumas evoluções, como o H.263+ e H.263++. No final dos anos 90, o grupo MPEG lançou a especificação MPEG-4. Em paralelo, a organização ITU vinha trabalhando em um projeto de codificação ainda mais eficiente. As duas organizações então uniram esforços para lançar, em 2002, outra padronização conjunta, a H.264/AVC, que é a mesma norma MPEG-4 (parte 10). Alguns padrões do MPEG foram desenvolvidos em conjunto com o ITU-T e publicados pelas duas entidades com nomes diferentes, apesar dos padrões serem exatamente os mesmos. Este é o caso do MPEG-2 (parte 2), que é o mesmo padrão H.262 da ITU-T e especifica um modelo para codificação de vídeo. Outro caso de cooperação das entidades é no padrão MPEG-4 (parte 10) ( Advanced Video Coding – AVC), que corresponde ao padrão H.264 da ITU-T. Na verdade, a partir do MPEG-2 houve um esforço conjunto entre o MPEG e o ITU, conhecido como Joint Video Team ( JVT), e ambos trabalham em conjunto para definir os padrões da forma mais eficiente e também compatível, evitando incompatibilidades. É notável a alta capacidade de compressão de dados e flexibilidade do padrão H.264/AVC. Sua flexibilidade deve-se ao fato de poder ser aplicado a uma extensa variedade de aplicações, sendo eficiente, por exemplo, para taxas de bits e resoluções de vídeo altas e baixas. O preço a ser pago por todas as vantagens do H.264 é o poder de processamento exigido para codificação de vídeo superior ao dos outros algoritmos. O H.265 ou MPEG-H (parte 2) é também conhecido como High Efficiency Video Coding (HEVC). Sucessor do H.264 AVC, HEVC dobra a taxa de compressão quando comparado ao H.264, permitindo resoluções de 320x240 até 7680x4320. O formato padrão de vídeo para os serviços de videoconferência especificados na recomendação H.323 é baseado no formato Common Intermediate Format (CIF), que consiste na resolução 352x288. Esse padrão nasceu na especificação H.261. O CIF nasceu da necessidade de estabelecimento de um formato padrão para videoconferência que suportasse os dois principais formatos padronizados de TV em todo o mundo: Phase Alternating Line (PAL) A TV PAL utiliza 625 linhas para formação do quadro, a uma taxa de 24 quadros por segundo. Possui frequência de varredura vertical de 50 Hz e resolução 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, frequência de 60 Hz e resolução de 720 x 480 pixels. A figura seguinte mostra uma comparação entre as resoluções utilizadas nos padrões H.261 e H.263:
Administração de Videoconferência

Formato CIF Sub-QCIF QCIF CIF 4CIF 16CIF

Resolução (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 Comparação entre os padrões H.261 e H.263.

R: Requerido; O: Opcional; N: Não especificado

32

Como podemos observar na figura, o formato CIF apresenta variações que definem outros formatos de resolução. Formatos com menor resolução requerem menor largura de banda para transmissão, como é o caso do Sub-QCIF. Formatos com maior resolução, como é o caso do 4CIF, requerem maior largura de banda para a transmissão. Para o padrão H.323, o padrão para codificação de vídeo requerido é o H.261 com resolução QCIF. Assim, há a garantia de que todos os sistemas compatíveis com H.323 suportam pelo menos essa especificação.

H.264
Padrão de codificação de vídeo bastante utilizado atualmente, que usa novas técnicas não disponíveis no MPEG2, MPEG4 e H.263. Oferece o dobro da qualidade de vídeo do H.262 em qualquer taxa de transmissão. Tornou-se um padrão mandatório para sistemas de alta definição com os discos Blue Ray, e também para produtos de broadcast, cabo, videoconferência e outros eletrônicos diversos. Também é adotado na TV digital brasileira.

q

O H.264 é um padrão bastante utilizado atualmente em codificação de vídeo, sendo cada vez mais usado em sistemas de videoconferência. 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 contrário do MPEG-4, o H.264 tem um escopo mais reduzido e seu foco é a otimização da codificação de vídeo. Ele inclui diversas novas funcionalidades no processo de codificação em relação aos seus predecessores, buscando um balanço entre eficiência da codificação, complexidade e custo. O grau de compressão do padrão e a inclusão de outros componentes que envolvem estritamente vídeo e a flexibilidade permitida fazem com que seja uma grande promessa para o futuro das aplicações de videoconferência. Ele já é o padrão 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 padrão de codificação a ser usado pelo sistema brasileiro de TV digital.

MPEG
O MPEG foi um grupo estabelecido em 1988, com a meta de elaborar padrões genéricos para vídeo digital e compressão de áudio, definindo normas para multiplexar fluxo de áudio e vídeo. Padrões: 11 MPEG-1, MPEG-2, MPEG-4 e MPEG-H: possuem partes específicas de compressão de áudio e vídeo. 11 MPEG-7: descrição de conteúdo de mídia (metadados). 11 MPEG-21: definição de um framework multimídia.

q

Os padrões MPEG normalmente são divididos em diversas partes, cada uma especificando determinadas etapas ou processos da codificação (codificação de imagens, de áudio, processo de testes, entre outros). No MPEG-1, por exemplo, a parte 3 especifica codificação de áudio, sendo o formato de codificação que ficou conhecido pelo nome MP3. A parte que especifica codificação de vídeo normalmente é a parte 2 dos padrões, o que acontece no MPEG-1, MPEG-2 e MPEG-4.

Capítulo 2 - Padrões de videoconferência

33

O MPEG-1 é o padrão mais antigo da família MPEG, projetado inicialmente para ser capaz de comprimir cerca de 30 minutos de áudio e vídeo para um único CD. O MPEG-1 é uma estratégia eficiente de compressão e descompressão, mas qualitativamente deixa a desejar. Normalmente, as taxas utilizadas estão em torno de 1 a 1,5 Mbit/s. Desde que a compressão 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 não tem sido mais adotado em sistemas de videoconferência. Assim como o MPEG-1, o padrão MPEG-2 implementa um esquema para compressão de vídeo. Porém, o propósito inicial dos desenvolvedores do MPEG-2 era atender a aplicações de broadcast, o que trouxe novas especificidades ao esquema adotado, que representa uma evolução ao MPEG-1, sendo muito mais complexo e eficiente. Atualmente, o MPEG-2 cobre muitas variações de resolução e formato, visando também atender as especificações da TV de alta definição. O mercado disponibiliza um grande número de produtos que utilizam este formato, como DVD players, receptores de TV via satélite e receptores de TV a cabo. O MPEG-2 ainda é utilizado em videoconferências quando se deseja um método mais rápido e menos complexo de compressão ou manter a compatibilidade com sistemas antigos. O MPEG-4 é o mais novo dos padrões da família MPEG, introduzido em 1999. O maior diferencial do MPEG-4 é incluir novos métodos de codificação de vídeo que o tornam mais eficiente que o MPEG-2. Além disso, o MPEG-4 também é um padrão bastante mais extenso que o MPEG-2, sendo definido como um padrão para representação de objetos audiovisuais. O mecanismo de compressão é semelhante ao MPEG-2, mas este padrão procura tratar de diversos tipos de dados, como objetos (regiões de um vídeo), redes de pontos 2D e 3D, animações e texturas. Assim como no MPEG-2, o MPEG-4 também oferece uma variedade de perfis que podem ser utilizados, permitindo desde taxas muito baixas (para utilização em dispositivos móveis, por exemplo) até taxas bem maiores, que permitem transmissão de vídeo de alta qualidade. Comparando perfis equivalentes, o MPEG-4 requer maior processamento do que os padrões MPEG-2 e MPEG-1 para codificação e decodificação. Do mesmo modo como os demais esquemas de compressão MPEG, ele foi desenvolvido para aplicações de broadcast e streaming, onde a latência não se apresenta como uma questão tão crucial quanto em aplicações de videoconferência. O MPEG-4 apresenta duas partes relacionadas à codificação de vídeo: 11 MPEG-4 parte 2 : método também chamado de MPEG-4 Visual, representa a evolução da codificação do MPEG-2. Normalmente quando se fala apenas em MPEG-4, é esta parte do padrão 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. Não deve ser confundido com o MPEG-4 parte
Administração de Videoconferência

2, pois representa um formato de compressão diferente. O MPEG-4 parte 2 vem substituindo o MPEG-2 já há alguns anos, sendo utilizado em diversos vídeos na internet codificados através de codecs que implementam o padrão, como os já populares DivX e Quicktime 6. Já o MPEG-4 parte 10 corresponde ao H.264, que já possui diversas aplicações (como Blue-ray, TV digital brasileira, entre outras) e tende a se tornar o padrão mais utilizado, inclusive em videoconferências.

34

Uma breve descrição desses padrões é disponibilizada em “Videoconferencing Cookbook” no site da ViDe.

w Padrões de dados
Há dois padrões importantes homologados pela ITU-T: 11 T.120: série de protocolos para compartilhamento de dados com suporte a multiponto. Possibilita: 22 Compartilhamento de área de trabalho ou de aplicação. 22 Uso de quadro branco (bate-papo e transferência de arquivos). 11 H.239: possibilita a criação e o controle de canais de vídeo adicionais. 22 Canal de vídeo adicional para envio de apresentações, compartilhamento de tela do computador, entre outros. T.120 é uma família de padrões estabelecidos pela ITU e suportados pelo padrão H.323 (de uso não obrigatório). A norma T.120 regulamenta uma série de protocolos para o compartilhamento de dados em sistemas de videoconferência. O T.120 suporta comunicação

q

ponto-a-ponto e também comunicação multiponto, podendo ser utilizado através de um nó centralizador (servidor) ou não. Quando é utilizado em conjunto com um sistema de videoconferência, pode assumir duas estratégias: in-band (a troca de dados entre os terminais compartilham o mesmo canal utilizado para troca de vídeo e áudio) ou out-of-band (as cone xões de dados são feitas independentemente das conexões de multimídia). Dentre as principais aplicações do T.120, destacamos: compartilhamento de área de trabalho e aplicações, quadro branco (whiteboard ), bate-papo e transferência 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 família de protocolos H.32x (que inclui o H.323) e é utilizado para possibilitar a criação e o controle de canais multimídia adicionais na videoconferência. O H.239 é voltado para sistemas baseados nos padrões H.245 e H.320. Enquanto o H.245 permite a criação de múltiplos canais para vídeo, o H.320 permite apenas um canal. Com isso, em relação ao H.320, o H.239 traz a vantagem de permitir um canal adicional de vídeo, onde identificação dos canais (indicar que um canal de vídeo corresponde à apresentação do professor, por exemplo) e métodos para controlar estes canais em conferências multiponto, como permitir que apenas um participante esteja transmitindo um vídeo adicional – contendo a imagem de seu desktop, por exemplo.
Capítulo 2 - Padrões de videoconferência

pode ser transmitida, por exemplo, uma apresentação. Além disso, também permite a

35

Padrões de comunicação
A figura a seguir contém um resumo das principais recomendações ITU, com o tipo de redes para as quais elas são voltadas e os padrões de áudio e vídeo utilizados em cada uma. Padrões de comunicação H.310 H.320 H.323 H.324

Padrões de vídeo MPEG-2 H.261, H.263 H.261, H.263 H.263

Padrões 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 telefônica

Figura 2.13 Principais padrões ITU-T.

A família H.3xx é um conjunto de recomendações regulamentadas pela ITU-T que compõe o principal conjunto de recomendações relacionadas à videoconferência. Essas recomendações costumam ser chamadas de “guarda-chuva”, pois fazem referência a diversas outras recomendações, entre elas recomendações para codificação de áudio e vídeo, multiplexação, sinalização e controle. Estas recomendações referenciadas indicam as técnicas e protocolos que podem ser utilizadas nas diversas áreas da videoconferência. A recomendação H.323, por exemplo, faz referência aos protocolos H.261, H.263 e H.264 para codificação de vídeo. O núcleo de recomendações da família H.3xx é composto por: 11 H.310 – provê suporte para videoconferência sobre ATM e possui um nicho muito específico. 11 H.320 – padrão para transmissão de vídeo, á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 sinalização, totalizando 2 Mbit/s; BRI fornece dois canais de 64 kbit/s e um canal de sinalização de 16 kbit/s, totalizando 144 kbit/s. 11 H.323 – recomendação voltada para videoconferências em redes comutadas por pacotes sem garantia de qualidade de serviço (LANs, internet etc.). 11 H.324 – provê suporte para videoconferência de baixa largura de banda sobre PSTN (Public Switched Telephone Network ). Esse protocolo foi utilizado na Ásia pelo mercado de telefonia celular. Além dos padrões ITU, há um padrão IETF que deve ser destacado: 11 SIP – protocolo dominante na área de VoIP e cujo uso em videoconferências vem crescendo cada vez mais. Neste curso será dada ênfase aos protocolos H.323, durante esta sessão, e SIP em sessões
Administração de Videoconferência

posteriores.

Padrão H.320
O padrão H.320 é voltado para videoconferências em redes ISDN.

36

Estrutura de normas do H.320

Codecs de vídeo

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

Recomendações utilizadas pelo H.320: 11 Codificação de vídeo: H.261 e opcionalmente H.262, H.263 e H.264. 11 Codificação 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 padrões de controle. Abaixo há uma breve descrição de cada um deles: 11 H.221: define a estrutura de organização dos dados ( framing ) para canais de 64 a 1920 kbit/s em conferências. 11 H.242: define um sistema para estabelecer comunicação entre terminais audiovisuais (ponto-a-ponto) usando canais digitais de até 2 Mbit/s. 11 H.230: define o controle de sincronização de quadros e indicação de sinais para sistemas audiovisuais. 11 H.243: define procedimentos para estabelecer comunicação entre 3 ou mais terminais audiovisuais usando canais digitais de até 2 Mbit/s. Comunicação com o MCU.

Padrão H.323
Padrão mais difundido para transmissão de voz, vídeo e dados em tempo real, para uso em redes comutadas por pacotes. Foi o primeiro padrão para VoIP, mas perdeu espaço para o SIP. Principais componentes de uma rede H.323: 11 Terminais.

q

11 Gatekeeper. 11 Gateway. 11 Elementos de borda. Terminais H.323 são equipamentos que conectam-se à rede H.323, viabilizando a participação dos usuários em videoconferências. O H.323 é um padrão ITU que descreve protocolos, serviços e equipamentos necessários para comunicação multimídia incluindo áudio, vídeo e dados em redes sem garantia de qualidade de serviço. O H.323 vem sendo desenvolvido desde 1996 com o objetivo de prover comunicação multimídia sobre redes baseadas em IP – como a própria internet, IPX, LANs e

Capítulo 2 - Padrões de videoconferência

11 Unidade de Controle Multiponto (MCU).

37

WANs. Desde sua criação, o H.323 já sofreu muitas revisões, que incorporam novas características para adequá-lo às novas tendências. O H.323 também pode ser visto como uma derivação de outro padrão da família H.32x, o H.320, mas otimizado para uso na internet. Atualmente, o H.323 também conta com especificações para a inclusão de suporte à voz e telefonia sobre IP. O funcionamento do padrão H.323 é fundamentado numa espécie de “contrato” entre os componentes que interagem dentro de um ambiente H.323, permitindo que esses componentes troquem informações entre si. O H.323 também especifica os padrões utilizados para esta comunicação, que formam a “linguagem” utilizada pelos componentes para que eles possam se entender. A arquitetura H.323 é composta dos seguintes componentes: 11 Terminais: são computadores ou equipamentos dedicados utilizados como “pontos finais” (endpoints) da rede de comunicação. Esses equipamentos são responsáveis por fornecer suporte em tempo real às comunicações bidirecionais. Tipicamente, são representados por computadores pessoais com suporte multimídia e câmeras integradas ou equipamentos dedicados que já contêm câmera e captação 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 “cérebros” da rede, responsáveis pela gerência de outros componentes do H.323 e pelas funções de tradução de endereços e identificação dos elementos de videoconferência, autorização e gerenciamento. 11 Gateways: promovem o “entendimento comum”, ou seja, trabalham como tradutores responsáveis pela conexão em redes não integradas (fora da zona H.323), possibilitando a interoperabilidade com endpoints de redes baseadas em circuitos (por exemplo, RDSI). 11 MCU: Multipoint Control Units são responsáveis pela conferência multiponto, viabilizando que mais de dois participantes se comuniquem simultaneamente através da rede, analogamente ao que acontece em uma teleconferência via telefone.
Figura 2.15 Exemplo de cenário (terminais, MCU, gatekeeper, gateway).

Telefone IP phone Rede IP Telefone IP phone
Administração de Videoconferência

Gatekeeper

Roteador

Terminal H.323 Roteador

Gateway

MCU

ISDN Gateway Terminal H.323

PSTN / WIRELESS

Telefone

Terminal H.320

38

Adicionalmente à definição dos diferentes tipos de componentes, o H.323 descreve protocolos que definem a codificação de áudio e vídeo, registro e admissão (Registration, Admission and Status – RAS), sinalização de chamadas e de controle. O H.323 ainda especifica uma arquitetura de componentes obrigatórios e opcionais, que serão detalhados durante o curso, bem como todo o detalhamento do funcionamento dos protocolos.

Figura 2.16 Equipamentos de videoconferência.

Multipoint Control Unit (MCU)
MCUs são responsáveis por gerenciar conferências multiponto, viabilizando a comunicação de três ou mais pontos simultaneamente. Também permitem: 11 Criação de salas virtuais de conferência. 11 Transcodificação de áudio e vídeo para diferentes modelos de equipamentos e fabricantes. 11 Transcodificação de velocidades (bitrate). MCU é formada por Controlador Multiponto (MC), um componente obrigatório que gerencia a sinalização de chamada.

q

B

C

D

A

B

Figura 2.17 Conferência multiponto utilizando Multipoint Control Unit.

C

D

A

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 é mandatário e executa as funcionalidades básicas do serviço, enquanto o processador multiponto possui caráter opcional (e podem haver vários destes) e tem a finalidade de prover o processamento necessário para a realização da conferência multiponto (em especial a codificação de vídeo, que é muito custosa em termos de processamento). Para viabilizar uma conferência multiponto, o elemento fundamental é a MCU, uma vez que possui funcionalidades que permitem negociação com as diversas entidades conectadas à conferência, a fim de estabelecer formatos comuns de comunicação. Para tanto, os terminais devem estabelecer canais de controle H.245 com a MCU.
Capítulo 2 - Padrões de videoconferência

provê recursos para suportar conexão multiponto. É formada por uma controladora multiponto

39

Processadores Multiponto (MP) são opcionais, utilizados para manusear a mixagem de mídias, chaveamento ou outro processamento de mídia.

Figura 2.18 Controladores multiponto.

Gateway
Responsável por fazer a interface H.323 para outras redes, tais como PSTN e sistemas H.320. Funções: 11 Tradução de protocolos H.323/SIP (IP) para H.320 (ISDN) ou o contrário. 11 Possibilita o aumento de controle e centralização das saídas de ISDN em pontos estratégicos na rede.

q

Terminal H.323

Telefone ISDN/PSTN

Terminal H.323

Gateway Telefone

Telefone IP phone

Terminal H.320

Figura 2.19 Cenário de uso do gateway.

Os gateways são os “tradutores” da arquitetura H.323, responsáveis por garantir que os diferentes elementos envolvidos em contextos de redes (também diferentes) possam se intercomunicar. Para promover tal interoperabilidade, um gateway executa a tradução entre os protocolos que rodam nas redes diferentes. Por exemplo: a tradução de protocolos que rodam em redes comutadas por circuito para protocolos de redes baseadas em pacotes IP (como o próprio H.323). Os serviços de um gateway incluem: interoperabilidade entre padrões de áudio/vídeo e redes, conversão de protocolos e formatos de áudio e vídeo.
Administração de Videoconferência

H.323 permite, por meio do uso de gateways, a conversão entre protocolos como H.320 (ISDN) e H.324 (POTS), garantindo a integração desses contextos com as aplicações H.323, além de padrões não 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. Funções: 11 Gerenciar todos os recursos disponíveis (terminais, gateways, MCU). 11 Pode permitir que chamadas sejam realizadas diretamente entre terminais ou centralizar, tanto a sinalização como os dados. 11 Fornece serviços avançados de administração: 22 Tradução de endereços. 22 Controle de admissão (autenticação dos terminais). 22 Negociação de largura de banda. O gatekeeper pode ser visto como o “cérebro” do esquema H.323. O funcionamento de um

q

gatekeeper é análogo a um servidor de gerência multimídia, que executa as atividades de administração e tomada de decisão. O gatekeeper provê os seguintes serviços: resolução de endereços, controle de admissão, 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 coleção de terminais, gateways e MCUs gerenciados por um único gatekeeper. Uma zona inclui, no mínimo, um terminal, e pode incluir MCUs ou gateways. Uma zona pode ser independente da topologia de rede e estar ligada a segmentos de rede múltiplos, conectados por roteadores e outros recursos. Há também o conceito de domínios administrativos, que são grupos de zonas H.323 administrados pela mesma pessoa ou organização (possuem mesmas regras de autenticação). Os gatekeepers podem também definir regras específicas para autenticação de componentes do seu domínio administrativo e outras regras para autenticação de componentes de diferentes domínios. Funções administrativas de um gatekeeper: 11 Tradução de endereços: chamadas originárias da rede H.323 podem utilizar um apelido (alias) para endereçar terminais de destino. Chamadas originadas fora da rede H.323 e recebidas por um gateway podem utilizar um número de telefone E.164 (telefone convencional) para endereçar os terminais-destino. O gatekeeper traduz esse endereço telefônico convencional em um endereço de rede IP. Por exemplo: (21) 222 6576 em 245.153.45:121. O terminal-destino pode então ser identificado e contatado através do endereço IP. 11 Controle de admissão: o gatekeeper pode controlar a admissão dos terminais na rede utilizando mensagens Registration, Admission and Status (RAS), onde estão inclusos os pedidos de admissão (ARQ – Admission Request), confirmação (ACF – Admission Confirm) cada, significando a admissão 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), confirmação (ACF) e rejeição (ARJ). Com isso ele consegue controlar a banda que está sendo utilizada na rede, administrando-a através da permissão ou negação das novas conexões que forem solicitadas ou das mudanças de banda que forem solicitadas. Além disso, o gatekeeper pode controlar o limite de conexões simultâneas na rede H.323, caso necessário. A banda disponível também pode ser administrada de modo que as conexões de áudio e vídeo não esgotem essa banda, permitindo que existam também conexões de dados. O controle de banda também pode não ser especificado, o que significa que serão aceitas todas as solicitações de conexões e mudança de banda. 41
Capítulo 2 - Padrões de videoconferência

e rejeição (ARJ – Admission Reject). A admissão de controle pode, ainda, não ser especifi-

11 Gerenciamento de zona: sendo o “cérebro” do esquema H.323, um gatekeeper define uma área H.323, que será gerenciada por ele. Ele então provê as funções já citadas de tradução de endereços, controle de admissão e controle de banda para os terminais, gateways e MCUs locados dentro desta zona. Funções opcionais de um gatekeeper: 11 Sinalização de controle de mensagem: o gatekeeper pode rotear mensagens de sinalização de chamadas entre os terminais H.323. Numa conferência ponto-a-ponto, pode centralizar mensagens de sinalização de chamadas H.225. Alternativamente, o gatekeeper pode permitir que os terminais enviem mensagens de sinalização de chamadas H.225 diretamente para outros terminais. 11 Autorização de chamadas: quando um terminal envia uma mensagem de sinalização de chamada para o gatekeeper, o gatekeeper pode aceitar ou rejeitar a chamada, utilizando a especificação H.225. As razões que provocam a rejeição de uma chamada podem ser restrições baseadas em tempo de conexão, permissões de acesso e/ou controle de banda. 11 Gerenciamento de chamada: o gatekeeper pode manter informações sobre todas as chamadas ativas H.323; desta forma, é possível controlar as zonas provendo essas informações de manutenção para as funções 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 eletrônico Gateway

Terminal

Administração de Videoconferência

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 informações sobre endereços e participantes (internos e externos) para autorização de chamadas entre domínios administrativos. Funcionam como um firewall traversal configurado para chamadas H.323.

q

Um domínio administrativo é um conjunto de zonas sob um mesmo controle administrativo. Os elementos de borda são componentes opcionais, que, como os gatekeepers, realizam tarefas administrativas, porém não se comunicam diretamente com os terminais. Eles são componentes localizados nas bordas das redes H.323 que realizam tarefas de comunicação entre domínios administrativos. Entre estas tarefas estão a troca de informações de controle de acesso e de informações sobre o custo de ligações, por exemplo. Em uma ligação de um terminal do domínio administrativo da organização X com um terminal do domínio administrativo da organização Y, por exemplo, podem ser utilizados elementos de borda em ambas as organizações, que se comunicam trocando todas as informações necessárias para efetuar a chamada.

Protocolos da arquitetura H.323
Além de componentes já abordados, o H.323 também especifica os vários protocolos utilizados no ambiente H.323.

Aplicações multimídia, interface do usuário Controle e gerenciamento dos terminais

Aplicações de dados

Controle de mídia Codecs de áudio: G.711 G.723.1 G.729 Codecs de vídeo: H.261 H.263 H.264 RTCP

T.120

H.239

H.225.0
Sinalização 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 Codificação de vídeo: H.261, H.263 e H.264. 11 Codificação de áudio: G.711, G.729, G.723.1, G.726, G.722, G.728.

Capítulo 2 - Padrões de videoconferência

RTP

43

11 Controle: H.225 e H.245. 11 Dados: T.120 e H.239. 11 Transporte multimídia: RTP e RTCP. Em relação ao vídeo, é mandatório que todos os terminais H.323 possibilitem a codificação e decodificação de vídeo com resolução QCIF e protocolo H.261, e para áudio é mandatório o suporte a G.711. Os outros protocolos citados para áudio e vídeo são opcionais. Os protocolos de vídeo e áudio já foram comentados, enquanto os protocolos de controle e de transporte multimídia serão detalhados no restante deste capítulo. Iniciaremos pelos protocolos RTP e RTCP, utilizados para transporte e controle sobre os dados de áudio e vídeo.

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 nível 4, no subnível inferior do nível de aplicação.

q

O RTP protocolo para aplicações em tempo real (Real-time Transport Protocol) é um protocolo especificado pelo IETF que provê um serviço de entrega fim-a-fim de áudio e vídeo em tempo real. É o protocolo utilizado para o empacotamento de mídias numa conexão H.323 (e em muitos outros sistemas).

Aplicações multimídia, interface do usuário Controle e gerenciamento dos terminais

Aplicações de dados

Controle de mídia Codecs de áudio: G.711 G.723.1 G.729 Codecs de vídeo: H.261 H.263 H.264 RTCP

T.120

H.239

H.225.0
Sinalização da chamada

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

Administração de Videoconferência

Aplicação
Encapsulamento de mídia RTP dados UDP RTCP controle

IPv4 / IPv6 Unicast ou multicast

Ethernet

1

2

3

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.

Número de sequência

Synchronization Source (SSRC) identifier Contributing Source (CSRC) identifiers

SEQ=1 SEQ=2 SEQ=3 SEQ=4 SEQ=5 SEQ=6 SEQ=7 SEQ=8
Capítulo 2 - Padrões de videoconferência

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 não Transmission Control Protocol (TCP), para evitar os atrasos devido aos processos de estabelecimento de conexão e SEQ=1 recuperação de falhas do TCP. O RTP provê então as funcionalidades de um protocolo de

SEQ=2 transporte voltado para a transmissão de dados de áudio e vídeo. Entre os mecanismos
existentes no RTP estão: SEQ=3 1SEQ=4 1 Sequenciamento: a função de sequenciamento designa a atribuição de números de sequência aos pacotes, a fim de garantir o correto ordenamento dos pacotes e de SEQ=5 detectar perdas. SEQ=6 11 Sincronismo intramídia: a transmissão de pacotes em uma rede pode levar a uma situSEQ=7 ação em que pacotes de uma mesma mídia apresentem atrasos diferentes causados por SEQ=8 jitter, o que prejudica a apresentação da mídia no cliente. Nesse caso, haverá a necessidade de uma sincronização dos pacotes que compõem a mídia. Essa sincronização é feita por meio de uma “bufferização”, Perdas=10% de modo que os pacotes recebidos sejam exibidos no momento correto. Quando a sincronização ocorre entre arquivos de mídia distintos, ou

SEQ=9 seja, a sincronia é entre fluxos de áudio e vídeo, denominamos de “sincronismo intermídia”.
11 Identificação de conteúdo: em redes sem garantia de QoS, a perda de pacotes e atrasos

SEQ=10 pode variar ao longo do tempo. O RTP fornece informação de conteúdo no intuito de permitir que codecs alterem dinamicamente sua capacidade de acomodar as perdas e atrasos detectados durante a transmissão. Isso é feito através do campo Payload Type (PT). 11 Identificação de origem: consiste na marcação 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 adaptação do jitter.

O protocolo de controle em tempo real (Real-time Transport Control Protocol – RTCP) é usado em conjunto com o RTP para serviços de controle. Ao contrário do RTP, RTCP não transporta a mídia em si (áudio e vídeo), mas apenas informações sobre estatísticas da transmissão e controle. A função primária do RTCP é prover informações sobre a qualidade do serviço, o que é feito pela transmissão periódica de pacotes para todos os participantes de uma sessão 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
Administração de Videoconferência

próprio utiliza, a fim de evitar sobrecarregar a rede com informações 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 Admissão: terminal requisita admissão para uma chamada. 11 Status: gatekeeper controla estado dos terminais e chamadas.

q

46

Mensagens mais importantes do RAS: 11 Solicitações: 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.

q

O canal RAS realiza as funções de registro, admissão e estado de chamada por meio do protocolo H.225. O canal RAS (independente do canal das outras mensagens H.225) utiliza um serviço UDP para registro e solicitação de admissão das chamadas. As mensagens RAS são utilizadas entre endpoints (termo que inclui gateways, MCUs e terminais) e gatekeepers para realização de três funções: 11 Registro: endpoints se registram em um gatekeeper (só podem se registrar em um gatekeeper), que controla as suas informações de acesso (incluindo IP e nome de acesso). 11 Admissão: requisição de admissão em chamadas, utilizada pelo gatekeeper para controle das chamadas existentes e da banda disponível. 11 Status: controle do estado dos endpoints, como, por exemplo, descobrir se um endpoint está disponível ou não.

Aplicações multimídia, interface do usuário Controle e gerenciamento dos terminais

Aplicações de dados

Controle de mídia Codecs de áudio: G.711 G.723.1 G.729 Codecs de vídeo: H.261 H.263 H.264 RTCP

T.120

H.239

H.225.0
Sinalização da chamada

H.245

H.225.0 RAS

RTP

TCP
Figura 2.28 Destaque do protocolo H.225 RAS.

TCP

UDP

TCP/UDP

TCP

UDP
Capítulo 2 - Padrões de videoconferência

IP

Quando um terminal não está configurado para se registrar em um gatekeeper específico, ele pode utilizar mensagens RAS para verificação 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 estão as mensagens de solicitação de registro (e cancelamento de registro), admissão (e cancelamento) e busca por gatekeepers, e as respostas possíveis para estas solicitações.

47

Essas mensagens são identificadas por 3 letras, sendo que as últimas duas identificam se é uma mensagem de solicitação (xRQ: request ), confirmação (xCF: confirm) ou rejeição (xRJ: reject ). Essas mensagens são descritas brevemente abaixo: 11 RRQ (RegistrationRequest): requisição de um endpoint para se registrar em um gatekeeper. 11 Respostas: RCF (RegistrationConfirm) para confirmação ou RRJ (RegistrationReject) para rejeição. 11 ARQ (AdmissionRequest): requisição de admissão enviada de um endpoint para o gatekeeper. 11 Respostas: ACF (AdmissionConfirm) para confirmação ou RRJ (AdmissionReject) para rejeição. 11 GRQ (Gatekeeper Request): solicitação de gatekeepers existentes. É enviado pelos endpoints por IP multicast de forma que os gatekeepers possam receber a mensagem mesmo que o endpoint não conheça os IPs dos gatekeepers. 11 GCF (GatekeeperConfirm): para confirmação ou GRJ (GatekeeperReject) para rejeição (endpoint não pode usar este gatekeeper).
Pode ser multicast, broadcast ou endereçamento manual

Terminal 1 Para descobrir o gatekeeper Use porta X Para se juntar à zona Para pedir permissão para iniciar chamada

Gatekeeper

GRQ GRJ/GCF RRQ RRJ/RCF ARQ ARJ/ACF Usando porta x Mensagem contém endereço 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 endereço). Os gatekeepers que receberem esta solicitação podem responder para o terminal informando seu endereço 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
Administração de Videoconferência

porta que o cliente deve utilizar para se comunicar com ele (Porta X). O gatekeeper pode também responder com uma mensagem GRJ (GatekeeperReject), que nega ao terminal o uso deste gatekeeper.
3. O terminal T1 envia então 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 também responder com uma mensagem RRJ (Register Reject ) para rejeitar o registro do terminal.

48

5. Para admissão em uma chamada, o terminal envia uma mensagem ARQ ( AdmissionRequest)

para o gatekeeper (também utilizando a porta X). O gatekeeper pode então aceitar o pedido (ACF – AdmisionConfirm) ou rejeitá-lo (ARJ – AdmissionReject ). Esta mensagem contém o endereço de que o terminal precisa para estabelecer uma chamada.

Protocolo H.225 – sinalização de chamada
A sinalização de chamada H.225.0 é utilizada para conectar entidades H.323, sendo derivada do Q.931 e Q.932 (sinalização de chamada ISDN). Mensagens disponibilizadas: 11 Setup: início de chamada 11 Alerting : o terminal chamado avisa que está “tocando” 11 Connect : o terminal chamado avisa que atendeu a ligação 11 Release Complete: finalização da chamada 11 Entre outras: Facility, Status, Progress, Information A função de sinalização de chamada recomendada pelo H.323 utiliza o protocolo H.225

q

para estabelecer a conexão entre terminais H.323. A sinalização de chamada é ativada pela troca de mensagens do protocolo H.225. As mensagens trocadas e procedimentos utilizados numa sinalização de chamada executam as seguintes atividades: 11 Estabelecimento de chamada: solicitação e confirmação de início de chamada. 11 Alertas de progresso da conexão: mensagens opcionais que podem ser trocadas enquanto uma conexão está sendo estabelecida, para que os terminais saibam o estado da conexão enquanto ela não está confirmada (ou cancelada). 11 Encerramento de chamada: solicitação e confirmação 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.

Aplicações multimídia, interface do usuário Controle e gerenciamento dos terminais

Aplicações de dados

Controle de mídia Codecs de áudio: G.711 G.723.1 G.729 Codecs de vídeo: H.261 H.263 H.264 RTCP

T.120

H.239

H.225.0
Sinalização da chamada

H.245

H.225.0
Capítulo 2 - Padrões de videoconferência

RAS

RTP

TCP
Figura 2.30 H.225 Sinalização de chamada.

TCP

UDP

TCP/UDP

TCP

UDP

IP

As mensagens de admissão são trocadas entre os terminais e o gatekeeper nos canais RAS. Nesse momento o gatekeeper determina se as mensagens de sinalização H.225 serão roteadas por ele ou se serão trocadas diretamente entre os terminais.

49

Sinalização de chamada roteada por gatekeeper
O gatekeeper recebe a mensagem de sinalização de chamada através de um canal específico para sinalização com um terminal e executa o roteamento para outro terminal, através do canal de sinalização de chamada desse outro terminal.

Sinalização de chamada direta
Durante a confirmação de admissão, o gatekeeper indica quais terminais podem trocar diretamente mensagens de sinalização de chamadas. Os terminais utilizam então o canal de sinalização de chamadas para trocar suas mensagens diretamente, sem que elas passem pelo gatekeeper. A sequência de mensagens trocadas para estabelecer uma conexão com o H.225 começa pelo envio de uma mensagem de “Setup”. O terminal que recebe a solicitação de conexão pode então responder com mensagens (opcionais) que indicam o progresso dessa conexão: “Call proceding”, “Progress” e “Alerting”. Assim que este terminal está devidamente pronto para estabelecer a conexão, ele envia uma mensagem “Connect”, e a conexão está estabelecida. A partir daí os dados de mídia podem ser trocados entre os terminais. Para finalizar a conexão, algum dos terminais envia uma mensagem de “Release”.

Endereço informado pelo gatekeeper Terminal 1 Setup Call proceeding Endereço de transporte para estabelecimento do canal H.245 Alerting Connect Terminal 2

Porta 1720
Figura 2.31 Sinalização 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 ligação saiba que o outro gateway está tentando estabelecer a conexão, mas esta ainda não está completa. Além dessas, as outras mensagens usadas na sinalização H.225 são: 11 StatusEnquiry : encaminhada pelo gatekeeper para o ponto final da chamada para saber o status de uma chamada.
Administração de Videoconferência

11 Status: resposta do ponto final à mensagem StatusEnquiry do gatekeeper. 11 Facility : usadas entre os pontos finais e o gatekeeper para tratamento de condições especiais, por exemplo redirecionamento de chamadas.

Protocolo H.245
Tem como propósito prover o controle das sessões multimídia estabelecidas: 11 Troca de capacidades entre terminais. 11 Determinação de mestre e escravo. Descritores de capacidades (protocolos suportados) contêm o conjunto de capacidades simultâneas.

q

50

H.245 possui um canal de controle utilizado para transportar as mensagens de controle fim-a-fim, com o objetivo de administrar as sessões abertas do H.323. O canal de controle H.245 é um canal lógico e está permanentemente aberto, ao contrário dos canais de mídias. H.245 provê mensagens para abrir e fechar um canal lógico, que é unidirecional. As mensagens de controle carregam informações de diferentes naturezas, tais como: troca de capacidades, informações de fechamento e abertura de canais lógicos utilizados para transmissão de mídias, mensagens de fluxo de controle, comandos gerais e sinalizações e requisições de modos preferenciais.

Aplicações multimídia, interface do usuário Controle e gerenciamento dos terminais

Aplicações de dados

Controle de mídia Codecs de áudio: G.711 G.723.1 G.729 Codecs de vídeo: H.261 H.263 H.264 RTCP

T.120

H.239

H.225.0
Sinalização da chamada

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 informações sobre os protocolos suportados para transmissão e recepção (tipos de mídias: G.711, G.723, H.261, H.263 etc.); além do tipo de mídia, detalhes também são fornecidos (taxas de transmissão, frames por segundo), permitindo que seja feita uma seleção mais inteligente dos codecs. Os descritores contêm o conjunto de protocolos suportados de forma simultânea pelo terminal. Um mesmo terminal pode suportar diversos padrões de codificação de vídeo, incluindo o H.261, H.263 e H.264, por exemplo. A ausência de informações sobre esse suporte indica que o terminal não está oferecendo uma possibilidade de escolha de modos de transmissão para o receptor.
Capítulo 2 - Padrões de videoconferência

Capacidades simultâneas 1. G.723.1 2. G.711 3. H.261
Figura 2.33 Capacidades de transmissão e recepção dos codecs.

1 2

3 4

5

4. H.264 5. T.38 Tabela de capacidades

Descritor 1

Descritor 2

T.38 é um padrão ITU-T para transmissão de fax sobre IP (FoIP).

51

Determinação de mestre e escravo
Necessária para evitar que dois terminais tentem estabelecer ao mesmo tempo dois canais lógicos 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.

Sinalização de canais lógicos
Canais são abertos pela troca de mensagens Open Logical Channel (OLC). Canais de voz e vídeo são unidirecionais, ao passo que os canais de dados textuais podem ser bidirecionais. Cada ponto final que participa da chamada deve usar um canal lógico separado para transmitir os fluxos de informações.

Controle de conferência multiponto
O H.245 também é usado para tarefas de conferências multiponto, como a seleção de um modo de operação comum a todos integrantes e a definição do controlador da conferência. Canal de controle: 11 Canal especial que transporta mensagens H.245. 11 H.245 é geralmente transmitido em uma conexão TCP separada, mas também pode ser transmitido junto com o canal de sinalização de chamadas H.225. Formato das mensagens: 11 As mensagens são formadas por diversas PDUs (Protocol Data Unit), que podem ser de 4 tipos: request, response, command e indication. As mensagens H.245 são formadas por diversos itens chamados PDU (Protocol Data Unit ), que contêm os dados da mensagem. Estas unidades podem conter dados de quatro tipos: 11 Request : mensagens que necessitam de resposta imediata. Requisição de capacidades do outro terminal ou requisição de configuração de mestre e escravo, por exemplo; 11 Response: resposta a uma requisição; 11 Command: mensagens que requerem ações no receptor, mas não necessariamente uma resposta. Comandos como controle de fluxo, fim de sessão e controle sobre a codificação de vídeo (parametrização); 11 Indication: indicações não necessitam que o receptor tome alguma ação ou responda. São avisos de jitter e skew, por exemplo.

q

52

Administração de Videoconferência

Terminal 1 TerminalCapabilitySet (1)
Mensagens do canal H.245 Mídia

Terminal 2

TerminalCapabilitySetAck (2) MasterSlaveDetermination (3) MasterSlaveDeterminationAck (4) OpenLogicalChannel (5)

Áudio: porta RTP destino: X

OpenLogicalChannelAck (6) OpenLogicalChannel (7)

Vídeo: porta RTP destino: Y
Figura 2.34 Mensagens H.245 entre dois terminais.

OpenLogicalChannelAck (8) Canal de áudio Porta X Canal de vídeo Porta Y

A troca de mensagens H.245 entre dois terminais segue a seguinte sequência:
1. O primeiro terminal (T1) envia uma mensagem TerminalCapabilitySet para o segundo

terminal (T2), para a troca de capacidades.
2. T2 conhece, então, as capacidades de T1 enviando uma mensagem H.245

TerminalCapabilitySetAck, na qual ele inclui as suas capacidades.
3. T1 envia uma mensagem MasterSlaveDetermination para definição de mestre e escravo

da sessão.
4. T2 responde com a mensagem MasterSlaveDeterminationAck, que contém a definição 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

lógico (OpenLogicalChannel ). O endereço de transporte do canal RTCP é incluído na mensagem.
6. T2 conhece o estabelecimento de um canal de dados de T1 para T2 enviando uma

mensagem H.245 OpenLogicalChannelAck. Dentre as informações dessa mensagem estão envio do fluxo de mídia RTP, e o endereço RTCP recém recebido por T1. Ao receber esta confirmação, T1 abre o canal de dados com T2.
7. T1 abre agora um canal de vídeo com T2 através de outra mensagem OpenLogicalChannel. 8. Como para o canal de áudio, o terminal T2 responde para T1 com uma mensagem
Capítulo 2 - Padrões de videoconferência

incluídos o endereço de transporte RTP alocado por T2 para ser usado em T1 através do

OpenLogicalChannelAck. O terminal T1 recebe a mensagem e abre o canal de vídeo com T2.

53

Procedimentos de uma conexão H.323
Agora descreveremos as etapas envolvidas no processo completo de criação de uma chamada H.323, incluindo o estabelecimento da chamada com as mensagens H.225 e H.245 e a transmissão de mídias. Imaginemos o seguinte exemplo: uma rede contendo dois terminais H.323 (T1 e T2) já registrados a seu(s) devido(s) gatekeeper(s). A sinalização de chamada direta é ativada (sem passar pelo gatekeeper). O fluxo de mídia utiliza RTP. Efetuado o processo acima, o terminal está registrado em seu gatekeeper. A seguir, são 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 requisição de admissão para o estabelecimento de uma nova chamada. T1 solicita o uso de sinalização de chamada no modo direto, sem que as mensagens de controle (H.245) sejam roteadas pelo gatekeeper.
2. O gatekeeper confirma a admissão 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 sinalização de chamada direta.
3. T1 envia uma mensagem de configuração de chamada H.225 para T2 solicitando uma conexão. 4. T2 responde com uma mensagem de prosseguimento de chamada a T1, ou seja, avisa

que a chamada está em progresso, mas que ainda não foi concluída.
5. Agora T2 tem que registrar no gatekeeper a requisição de admissão para o estabelecimento de
Administração de Videoconferência

uma nova chamada. Através do canal RAS, envia uma mensagem ARQ para seu gatekeeper.
6. O gatekeeper confirma o registro enviando uma mensagem de confirmação ACF para T2. 7. T2 notifica T1 do estabelecimento da conexão, enviando uma mensagem de alerta H.225. 8. Por fim, T2 confirma o estabelecimento da conexão enviando uma mensagem de

conexão H.225 a T1, e a chamada está estabelecida.

54

Terminal T1

Gatekeeper 9. TerminalCapabilitySet

Terminal T2

Mensagens H.245 RTP (mídia)

10. TerminalCapabilitySetAck 11. MasterSlaveDetermination 12. MasterSlaveDeterminationAck 13. OpenLogicalChannel

Áudio: porta RTP destino: X

14. OpenLogicalChannelAck 15. OpenLogicalChannel

Vídeo: porta RTP destino: Y

16. OpenLogicalChannelAck Canal de áudio Porta X Canal de vídeo 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, então, as capacidades de T1 enviando uma mensagem H.245

TerminalCapabilitySetAck.
11. T1 envia uma mensagem MasterSlaveDetermination para decisão 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 lógico (OpenLogicalChannel ). O endereço de transporte do canal RTCP é incluído na mensagem.
14. T2 conhece o estabelecimento de um canal unidirecional lógico de T1 para T2 enviando

uma mensagem H.245 OpenLogicalChannelAck. Dentre as informações dessa mensagem estão incluídos o endereço de transporte RTP alocado por T2 para ser usado em T1 através do envio do fluxo de mídia RTP, e o endereço RTCP recém recebido por T1.
15. T1 abre outro canal com T2, agora para vídeo, através de uma mensagem H.245

OpenLogicalChannel. O endereço de transporte do canal RTCP está incluso na mensagem.
16. T2 conhece o estabelecimento do canal lógico através do envio da mensagem
Capítulo 2 - Padrões de videoconferência

OpenLogicalChannelAck.

55

Finalização da sessão

Terminal H.323 T1 21 (Comando de Final de Sessão)

Gatekeeper

Terminal H.323 T2

22 (Comando de Final de Sessão) 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 liberação, enviando para T1 uma mensagem H.245

EndSessionCommand.
2. T1 libera seu lado da chamada e confirma a liberação enviando uma mensagem

Figura 2.37 Mensagens H.245 de finalização de sessão.

EndSessionCommand para T2.
3. T2 finaliza a chamada enviando uma mensagem H.225 para T1. 4. T1 e T2 informam ao gatekeeper o término da chamada enviando uma mensagem DRQ

w
A página “Understanding H.323 Gatekee pers” no site da Cisco contém uma boa descrição do funcionamento dos gatekeepers H.323 e dos protocolos de sinalização 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 confirmação DCF (DisengageConfirm) para T1 e T2. A figura seguinte apresenta um resumo do que foi visto, e é referente à captura mostrada na figura seguinte.

56

Administração de Videoconferência

Terminal T1 Registration Request / Confirm Admission Request / Confirm Setup Permissão para aceitar ligação de T1

Gatekeeper

Terminal T2 Registration Request / Confirm

Permissão para ligar para T2

Setup Admission Confirm

Alerting

Alerting Admission Confirm

Connect

Connect

H.245 (Terminal Capabilities) H.245 (Open Logical Channel)

Canal de áudio
Figura 2.38 Resumo da comunicação H.323.

Canal de vídeo

Padrões para serviços
H.350: 11 Recomendação estabelecida pela ITU-T. 11 Esquema padronizado para prover serviço de diretórios para protocolos de conferência, incluindo H.323, SIP, H.320 e protocolos não padronizados. 11 Utiliza LDAP. 11 Torna fácil a tarefa de encontrar e discar para usuários, suportando o gerenciamento de identidade para permitir alta escalabilidade na organização e armazenamento de preferências de chamada. O H.350 padroniza o modo como as informações multimídia sobre conferências são arma-

q

zenadas em diretório de LDAP, de forma que a colaboração de multimídia possa se integrar mentos da série incluem o documento H.350 básico e os subdocumentos H.350.1, H.350.2 etc., cada um dirigindo-se a um protocolo particular de conferência.
Capítulo 2 - Padrões de videoconferência

com diretórios de empresas para escalabilidade, gerenciamento e segurança. Os docu-

57

58

Administração de Videoconferência

Roteiro de Atividades 2
Atividade 1 – Análise de troca de mensagens direta entre dois clientes
Esta atividade deverá ser realizada em dupla. Os alunos deverão utilizar um software de videoconferência para efetuar chamadas de áudio e vídeo com o colega ao lado. A sinalização do padrão H.323 deverá ser analisada com auxílio 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 conteúdo que trafegará pela rede. Interrompa a captura logo após ter terminado a ligação, para obter também o tráfego de final de ligação. Além disso, é melhor ter capturas de poucos segundos para não deixar o software de análise muito lento (com muitos pacotes a analisar). Faça a chamada utilizando o endereço IP do parceiro da dupla, e confirme que o software de videoconferência não está configurado com gatekeeper. Para facilitar a identificação do tráfego, utilize filtros que mostrem apenas o conteúdo 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 são os fluxos RTP existentes?

4. Para um fluxo RTP, quais as portas de mídia RTP e RTCP utilizadas?

5. Desenhe a troca de mensagens no espaço abaixo com o apoio do Wireshark (statistics +

flow graph), detalhando os protocolos, como por exemplo: “h.225 setup”, “h.225 admission
Capítulo 2 - Roteiro de Atividades

request/confirm”, “H.245”, “rtp audio” etc. No Wireshark, utilize filtros como h225, h245, rtp e ip para facilitar a visualização 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 máquina desejada) ou “h225 or h245”.

59

Atividade 2 – Análise de troca de mensagens entre dois clientes com gatekeeper
Esta atividade deverá ser realizada em dupla. Configure o software de videoconferência para utilizar o gatekeeper disponibilizado pelo instrutor, conforme orientações na prática intermediária. Faça uma ligação novamente entre dois terminais através 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 tráfego de mídia (pacotes da videoconferência RTP) está indo diretamente entre os

terminais ou passando pelo gatekeeper.

3. Quais protocolos são utilizados para troca de mensagens diretamente entre os terminais

e quais passam pelo gatekeeper? Desenhe a troca de mensagens no espaço 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

Administração de Videoconferência

3
Plano de numeração e gatekeeper
objetivos
Ao final do capítulo o aluno estará apto a identificar um plano de numeração E.164 e a configurar um gatekeeper em uma rede H.323.

conceitos

Padrão ITU E.164, plano de numeração e plano de discagem, gatekeeper GnuGK (configurações básicas, plano de discagem e autenticação de clientes).

Padrão ITU E.164
Plano de numeração internacional para a rede de telefonia pública (e eventualmente para rede de dados). Define estrutura de números e funcionalidade para 4 categorias: 11 Regiões geográficas (foco deste curso). 11 Serviços globais. 11 Redes. 11 Grupos de países.

q

w
A lista dos códigos telefônicos de diversos países pode ser vista em “List_of_country_ calling_codes” na Wikipedia.

O E.164 é uma recomendação ITU-T que define o plano de numeração internacionalmente usado em redes de telefonia pública e em algumas redes de dados. A recomendação define a estrutura da numeração e como estes números devem ser analisados para que seja feito o seu roteamento. São definidas estruturas de numeração países. Neste curso o foco é dado à categoria das regiões geográficas.
Capítulo 3 - Plano de numeração e gatekeeper

para 4 categorias: regiões geográficas, serviços globais, redes de computadores e grupo de

CP

CA

NA (15 - CP) dígitos Número de alcance nacional

1 a 3 dígitos

Máximo de 15 dígitos
Figura 3.1 Estrutura do ITU E.164.

Número de alcance internacional

Números E.164 são limitados a no máximo 15 dígitos, normalmente representados com o prefixo +.

61

Exemplo: +555199998888. Números para áreas geográficas são divididos em 3 partes: 11 CP = Código do país Usa-se de um a três dígitos para representar o código da região. Em geral, o código da região representa um país, exceto para Estados Unidos e Canadá, que utilizam o mesmo código. 11 CA = Código de área 11 NA = Número do assinante É de responsabilidade da agência reguladora do setor de cada país a administração de seu plano de numeração, incluindo a quantidade de dígitos utilizados para número do assinante, código de área etc.

q

Os números E.164 são limitados a, no máximo, 15 dígitos, e normalmente são representados incluindo o prefixo +. Para a categoria de áreas geográficas, os números E.164 são divididos em 3 partes: 11 CP: Código do país. Código de 1 a 3 dígitos que representa a região geográfica em que o número se localiza. Em geral, o código da região representa um país, exceto para Estados Unidos e Canadá que utilizam o mesmo código. 11 CA: Código da área. Código (opcional) da região dentro do país. 11 NA: Número do assinante. Contém no máximo (15 – CA – CP) dígitos e é o número que identifica cada assinante individualmente. O código do país é estabelecido mundialmente, enquanto os códigos de área e números de assinante são de responsabilidade da agência reguladora do setor de cada país.

Plano de numeração
O uso de um plano de numeração consistente em uma rede de videoconferência simplifica a alocação de identificadores para terminais, e consequentemente facilita a discagem para o usuário final. O plano de numeração é a definição de como será a identificação numérica dos terminais e áreas da videoconferência e como será feito o roteamento das chamadas através desses

q

identificadores. O plano de numeração é muito importante, pois simplifica a identificação de terminais, e consequentemente facilita a discagem para o usuário final. A VideNET é um exemplo de rede de videoconferência de alcance global, e utiliza o esquema Global Dialing Schema (GDS), que é um plano de numeração proposto para redes de vídeo e voz sobre IP; esse plano de endereçamento é muito similar ao plano de numeração do sistema telefônico internacional. Com o GDS, é possível numerar cada terminal de videocon Administração de Videoconferência

ferência, sala virtual de MCUs e gateway. O plano de numeração permite a integração com outras redes de videoconferência e também com outros tipos de redes, tais como: 11 VoIP: estabelecimento de áudio conferência; 11 Public Switched Telephone Network (PSTN): terminais conectados via ISDN. Os identificadores atribuídos para os terminais são válidos apenas no âmbito da rede local da videoconferência e não é necessário que seja atribuído um identificador E.164 completo (15 dígitos) para cada terminal. Duas instituições podem, por exemplo, compartilhar os mesmos identificadores dos terminais, mas para elas interagirem deverão possuir códigos

w Para mais informações
visite o site da VideNET.

62

de área distintos. Dependendo do tamanho da rede de videoconferência, os identificadores podem ser herdados da telefonia convencional (o que não quer dizer que eles serão acessíveis a partir dela). O acesso a partir da rede de telefonia convencional requer conexão através de GW IP-PBX (dotados de interfaces BRI ou PRI para vídeo/áudio ou FXO para áudio). Identificação para terminais: 11 Não necessariamente é atribuído um identificador E.164 completo. 11 O identificador será válido apenas no âmbito da rede local de videoconferência. 11 Dependendo do tamanho da rede de videoconferência, os identificadores podem ser herdados da telefonia convencional (isso não quer dizer que serão acessíveis a partir dela). Para chamadas entre terminais na mesma área pode simplesmente ser utilizada discagem de 4 dígitos. Exemplo: Terminal 1 liga para Terminal 2 discando: 2000. Para chamadas para terminais de fora da rede deve ser utilizado o código 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 numeração, fundamental para o desenvolvimento dessas e de outras facilidades. Terminal 1 na Área A Formato dos números Prefixo da área Número do terminal Número 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

q

Figura 3.2 Exemplo de numeração para três terminais.

Para um terminal efetuar uma chamada para um terminal que está na mesma área, pode simplesmente ser utilizada discagem de 4 dígitos. 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 código de área. Assim, para o Terminal 1 ligar para Terminal 3, por exemplo, ele deve discar (0 22 1000), necessitando discar um código de escape antes, no caso “0”, para informar que está ligado para fora da sua área. Esse número
Capítulo 3 - Plano de numeração e gatekeeper

é definido no plano de discagem. A numeração abreviada é possível graças ao recurso de reescrita do servidor de sinalização gatekeeper para H.323 e proxy para SIP.

Plano de discagem
Funções do plano de discagem: 11 Permitir facilidade e flexibilidade para discagem. 11 Garantir que chamadas para fora da área e país 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 país.

q

63

Qualquer tipo de discagem, por exemplo abreviada ou hiper abreviada, deve ser definida no plano de discagem. No H.323, os planos de numeração de discagem são implementados no gatekeeper.

q

Enquanto o plano de numeração define como será a atribuição de identificadores aos terminais, o plano de discagem define como será feita a discagem entre estes terminais. Uma das preocupações é garantir que chamadas para áreas externas (fora da região, fora do estado, fora do país etc.) sejam facilmente encaminhadas. Essas ligações externas normalmente são identificadas por prefixos durante a discagem. Na telefonia convencional brasileira, por exemplo, discagens para outras áreas são identificadas pelos prefixos 0 e 00. Exemplos: 11 Para chamar um terminal de dentro da rede (4 dígitos): 1234 (interpretação 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 país: 0 51 3333 1234. 11 Discar para um terminal de uma rede fora do país: 00 55 51 3333 1234. No plano de discagem também são 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 dígitos, utilizada na telefonia convencional. 11 Discagem hiper abreviada – discagem ramal de 4 dígitos, utilizada em PABX. Redes distintas podem implementar planos de discagem diferentes. A implementação ocorre nos servidores de sinalização, responsáveis pelo roteamento das chamadas. No H.323, os planos de numeração de discagem são implementados no gatekeeper.

Gatekeeper GnuGK
Implementação de código livre de um gatekeeper H.323 (licença GPL), que provê as diversas funcionalidades de um gatekeeper, entre elas: 11 Autenticação por SQL (BD), RADIUS, arquivos ou aplicações externas. 11 Reescrita de números (plano de discagem e numeração). 11 Modo proxy. Funciona em diversos sistemas operacionais: Linux, Windows, MacOS X, FreeBSD etc. GnuGK é uma implementação de um gatekeeper que tem base nas bibliotecas PWlib (biblioteca para portabilidade de código, especialmente relacionado à rede, I/O e threads)

q

e OpenH323, esta última uma implementação de código aberto do protocolo H.323. É uma ferramenta de código aberto (licença GPL), flexível e que disponibiliza as diversas funcionalidades necessárias para um gatekeeper.
Administração de Videoconferência

Uma das funcionalidades do GnuGK é a autenticação de usuários para controle de admissão. Ele permite autenticação por bancos de dados SQL, servidores RADIUS (Remote Authentication Dial In User Service), LDAP (Lightway Directory Access Protocol ), além de arquivos locais ou aplicações externas. O GnuGK também permite reescrita de números, para implementação do plano de numeração e discagem, faz o roteamento de chamadas, possui modo full proxy, possibilita controle de banda, suporta segurança por H.235, entre diversas outras funcionalidades. A aplicação funciona em diversos sistemas operacionais, entre eles Linux, Windows, MacOS X e FreeBSD.

64

Instalação do GnuGK
O primeiro passo para utilização do GnuGK é a instalação da aplicação. A instalação obviamente depende do sistema no qual o aplicativo será instalado. O site do GnuGK disponibiliza versões da aplicação compiladas para diversos sistemas operacionais, incluindo Linux, Windows e MacOS. Para estes sistemas, basta obter os executáveis e instalá-los. O manual do GnuGK possui uma seção de instalação que pode auxiliar este processo. Para sistemas não suportados ou para fazer otimizações/personalizações na aplicação, é possível obter o código-fonte do GnuGK e compilá-lo para o sistema alvo. No Debian, aplicações podem ser instaladas facilmente com o gerenciador de pacotes apt-get, que também permite instalar o GnuGK. Esta aplicação instala o GnuGK e todas as suas dependências (todas as bibliotecas de que ele necessita). Normalmente o comando de instalação no Linux é:

Consulte o manual do GnuGK em gnugk.org.

11 [-t] – especifica o nível de debug. Quanto maior o número de -t’s, maior será o nível de debug. Para a opção de depuração o indicado é o nível de debug 3, ou seja, [-ttt]. Ao ser instalado no Linux, o GnuGK também instala um script que facilita a inicialização e finalização do programa. Este script é instalado em /etc/init.d/gnugk e possui as opções: Iniciar: /etc/init.d/gnugk start Parar: /etc/init.d/gnugk stop Reiniciar: /etc/init.d/gnugk restart

Capítulo 3 - Plano de numeração e gatekeeper

d

$ apt-get install gnugk
Mais detalhes de instalação e compilação podem ser vistos no manual do GnuGK.

Inicialização do GnuGK
11 O executável aplicativo chama-se “gnugk”, que possui diversas opções para configuração. Para ver as opções possíveis use o comando gnugk –help. Exemplo de execução:

q

gnugk –c /etc/gnugk.ini –o /var/log/gnugk.log –ttt

A execução do aplicativo GnuGK no Linux é feita através do executável chamado “gnugk ”. Seguindo a instalação padrão feita com o apt-get no Debian, este executável estará instalado em /usr/sbin. Para executá-lo deve-se estar logado como superusuário (root). O GnuGK possui diversas opções que podem ser configuradas por linha de comando na execução da aplicação. Para verificar as opções possíveis basta digitar o comando:

gnugk --help
Algumas opções interessantes: 11 [-c arquivo_de_configuração] – especifica o arquivo de configuração que será utilizado (arquivo que será descrito mais adiante). 11 [-o arquivo_de_log] – especifica o arquivo onde será gravado o log da aplicação.

65

Ao iniciar o GnuGK por este script, ele utiliza algumas configurações padrão especificadas pelo script: Arquivo de configuração: /etc/gatekeeper.ini Arquivo de log : /var/log/gnugk/gnugk.log Para ter certeza que o GnuGK está em execução no Linux, é possível executar o comando abaixo que informa se o aplicativo está em execução:

ps -ef | grep gnugk
Se o programa estiver em execução, aparecerá, entre outras informações, uma linha contendo o nome e caminho do executável do GnuGK: /usr/sbin/gnugk.

GnuGK no Windows
O GnuGK é disponibilizado para Windows em dois formatos, serviço e aplicação. Para iniciar o GnuGK (aplicação) basta executar: 11 gnugk.exe –c etc/gnugk.ini Este arquivo segue o mesmo formato da versão Linux. Para modificar as configurações basta fechar o GnuGK, editar o arquivo e iniciar o GnuGK novamente.

q

Além da versão para Linux discutida ao longo deste capítulo, o GnuGK também é disponibilizado para a plataforma Windows em duas versões: 11 Serviço: como o nome diz, a aplicação é executada como um serviço do sistema. 11 Aplicação: o GnuGK é executado como uma aplicação padrão do sistema. As duas versões são da mesma aplicação e possuem as mesmas funcionalidades, a única diferença é a forma como são executadas. Para executar o GnuGK (versão aplicação) basta dar dois cliques no seu executável. O GnuGK buscará por um arquivo chamado gatekeeper.ini na mesma pasta onde está o executável. Para especificar outro arquivo de configuração, é possível executar a aplicação com o comando “-c”. No exemplo abaixo, execute o arquivo gnugk.ini, que está dentro do diretório etc :

gnugk.exe –c etc/gnugk.ini
O GnuGK já vem com um arquivo gnugk.ini padrão que pode ser utilizado inicialmente. Para modificar as configurações do GnuGK basta editar o arquivo gnugk.ini e executar a apli cação. O GnuGK é executado em uma janela do prompt de comando do Windows que ficará sendo exibida enquanto a aplicação está rodando.

Administração de Videoconferência

Configuração do GnuGK (Windows, Linux e outros)
Estrutura do arquivo de configuração: 11 Arquivo texto padrão composto por seções. 11 Cada seção contém um nome e uma lista de parâmetros com seus respectivos valores. Para não precisar especificar a localização do arquivo de configuração a cada execução do GnuGK, crie um arquivo chamado de gatekeeper.ini no mesmo diretório onde está o aplicativo do GnuGK ou copie o arquivo padrão gnugk.ini do diretório /etc e após altere o nome.

q

66

Este arquivo é organizado em diversas seções, cada uma delas contendo uma lista de parâmetros com seus respectivos valores. As seções possuem nomes fixos e pré-determinados, que são colocados entre colchetes. Segue abaixo um exemplo de uma seção:

[NomeDaSecao1] Parametro1=Valor1 ParametroN=ValorN
Os parâmetros também possuem nomes fixos e aceitam determinados valores, que variam conforme o parâmetro. Atentar para a digitação dos parâmetros e seus valores, pois eles são sensíveis a maiúsculas e minúsculas. O arquivo possui um requisito mínimo que é a seção:

q

[Gatekeeper::Main] Fourtytwo=42
11 Outros parâmetros da seção [Gatekeeper::Main]:

Name=H_323_ID_Gatekeeper Home=IP_do_Gatekeeper TimeToLive=300TotalBandwidth=512000 StatusPort=7000

O arquivo de configuração do GnuGK tem um requisito mínimo, que é a presença da seção [Gatekeeper::Main] com o parâmetro Fortytwo=42. A opção de configuração Fourtytwo=42 serve para indicar que o arquivo é um arquivo de configuração do GnuGK. Outros parâmetros possíveis nesta seção: 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: endereço IP a partir do qual o gatekeeper receberá requisições. Por default, o gatekeeper “ouve” todas as interfaces de seu host. 11 TimeToLive: tempo da validação do registro de um terminal (em segundos). O terminal deve periodicamente enviar mensagem RRQ tendo o bit keepAlive ativado para que seu registro não expire. Depois de expirado, o registro deve ser revalidado. 11 TotalBandwidth: largura de banda total disponível para os terminais.
Capítulo 3 - Plano de numeração e gatekeeper

11 StatusPort: porta de status utilizada para monitoramento e controle do gatekeeper. Para adicionar comentários no arquivo de configuração, insira o caractere ponto-e-vírgula antes do comentário. Este recurso é extremamente útil para descrever modificações ou para “anular” a funcionalidade de um parâmetro sem a necessidade de apagá-lo do arquivo. O ponto-e-vírgula (;) pode ser adicionado em qualquer parte, mas só tem efeito na própria 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 parâmetro será ignorado pelo GnuGK.

Se o arquivo de configuração for editado com o GnuGK em execução, será necessário reiniciá-lo para que as novas configurações tenham efeito. Se o servidor GnuGK for reiniciado, todas as chamadas realizadas através do gatekeeper serão desconectadas e novas chamadas somente serão possíveis depois que o servidor estiver devidamente operacional. Para evitar essa indisponibilidade, pode ser utilizado o comando reload através da console de monitoramento, que será vista a seguir.

Monitoramento do GnuGK
Porta de status: 11 Monitorar e controlar as funções do gatekeeper. 11 Estabelecer e desconectar chamadas. 11 Desconectar terminais. 11 Visualizar e alterar as configurações em tempo real. 11 Desligar o gatekeeper. 11 Suas configurações são feitas na seção [GkStatus::Auth]. 11 Acesso através da porta configurada (padrão: 7000): 22 telnet “IP do gatekeeper” 7000 Deve ser configurada de tal forma que evite o uso indevido, causador de interrupção e utilização inadequada dos recursos. A porta de status é utilizada para monitorar as atividades do gatekeeper. A porta que será utilizada é configurada pelo parâmetro StatusPort da seção [Gatekeeper::Main] do arquivo de configuração, já comentada. Além de monitorar as atividades, pela porta de status é possível controlar chamadas e terminais (desconectar um terminal, por exemplo) e alterar configurações do gatekeeper.

q

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 conexão telnet com o gatekeeper na porta 7000 que será possível monitorá-lo. Abaixo segue o comando para se conectar à porta de status do gatekeeper local:
Administração de Videoconferência

$ telnet localhost 7000 $ telnet 127.0.0.1 7000
Para se conectar a um gatekeeper remoto basta modificar o segundo parâmetro 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 configurações específicas para a porta de status são feitas na seção [GkStatus::Auth] do arquivo de configuração. Esta seção possui alguns parâmetros importantes para restringir o acesso à porta de status, que são:

68

Shutdown
Permitir ou não o desligamento do gatekeeper pela porta de status. Dois valores possíveis: 11 allow : permite desligamento. 11 forbid : não permite desligamento.

Rule
Define os hosts que terão permissão de acesso à porta de status. Por padrão não permite nenhuma conexão. Pode receber os valores: 11 forbid: desabilita quaisquer conexões; 11 allow : permite quaisquer conexões; 11 explicit: lê um outro pârametro ip=value onde ip é o endereço do cliente de gerência/monitoramento, value pode ser 1 (permite acesso), 0 (nega acesso) ou allow/forbid ou yes/no; 11 regex : valida o endereço IP do cliente através de uma expressão regular; 11 password: valida através de usuário e senha. Além disso, estas regras podem ser combinadas por “|” ou “&”. Por exemplo:

rule=explicit | regex
O comando reload recarrega o arquivo de configuração sem a necessidade de reiniciar o GnuGK; entretanto, as configurações só serão efetuadas em chamadas que forem iniciadas após o comando, ou seja, chamadas em andamento no momento não serão afetadas. O endereço IP do cliente deve casar explicitamente (explicit) ou com a regra regex.

rule=regex & password
O endereço IP do cliente deve casar com a regra regex, e o usuário tem que fazer login com usuário e senha.

Regex
Expressão regular para validação do endereço que está tentando acessar a porta de status do gatekeeper. Parâmetro utilizado quando rule=regex. Além das opções citadas, a seção [GkStatus::Auth] também pode conter parâmetros do tipo <username>=<senha> e <ip>=<allow/forbid> quando o parâmetro rule contiver os valores password ou explicit, respectivamente. Exemplo de controle de autenticação 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”

Capítulo 3 - Plano de numeração e gatekeeper

69

No exemplo acima, a expressão regular limita o acesso para os endereços local 127.0.0.1 (loopback) e dos IPs 192.168.1.10 e 192.168.1.11. Pelo parâmetro gkadmin=ssssss, é disponibilizado o acesso para qualquer endereço que utilizar nome de usuário gkadmin e a senha correta. A senha correta não é a que aparece no exemplo, J48HbZsUJPk, pois este é o valor da senha original após ser criptografada pelo utilitário addpasswd, que será comentado posteriormente. Além disso, como rule contém o valor explicit, foi incluído o parâmetro 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 [seção]
Estando conectado, diversos comandos podem ser enviados à porta de status para obter informações sobre o gatekeeper ou solicitar que ele execute alguma ação. Principais comandos disponíveis: 11 h: imprime todos os comandos; 11 printallregistrations | rv | ? : imprime todos os endpoints registrados (são 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: força o cancelamento do registro de todos os endpoints registrados; 11 disconnectip [ip]: desconecta todas as chamadas de um determinado endereço IP; 11 disconnectalias [alias]: desconecta todas as chamadas de um determinado alias (usuário);
Administração de Videoconferência

11 reload: recarrega as configurações do arquivo de configurações; 11 debug cfg [seção]: imprime as configurações de uma determinada seção (do arquivo de configurações). 11 Algumas alterações do arquivo de configuração (principalmente as relacionadas com endereçamento IP) não terão efeito mesmo após o comando reload. Verifique o manual do GnuGK para mais detalhes.

Zoneamento
As zonas H.323 são definidas por um gatekeeper, e podem ser de domínios administrativos distintos. A segmentação em zonas permite a criação de grandes redes de videoconferência.

q

70

Cada zona será constituída por um gatekeeper e pelo menos terminais H.323. Mensagens LRQ/LCF são utilizadas para localização do terminal remoto. Configuração do zoneamento no GnuGK: A seção [RasSrv::Neighbors] especifica todos os gatekeepers vizinhos. A sintaxe das linhas desta seção configuração é:

q

<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 separação por zonas, os gatekeepers de diferentes zonas possuem referências que os associam. Esta associação é feita por números E.164. Supondo que o GKA tenha prefixo 11, GKB 22 e GKC 33, a configuração para o GKA é:

[RasSrv::Neighbors] GKB=192.168.2.1;022 GKC=192.168.3.1;033

ISDN

Sistema telefônico Gateway

Terminal

Gatekeeper

Roteador

MCU

Figura 3.3 Exemplo de zona H.323.

Zona H.323

As zonas H.323 são definidas por um gatekeeper único, ao qual estão conectados outros elementos H.323 (terminais, MCU etc.). A segmentação em zonas permite a criação de grandes redes de videoconferência, onde cada zona é controlada pelo seu gatekeeper e pode constituir um domínio administrativo diferente das outras (uma zona H.323 de uma determinada empresa, por exemplo).

Capítulo 3 - Plano de numeração e gatekeeper

71

GK A

GK C

GK B

Figura 3.4 Cada gatekeeper possui duas referências.

A comunicação entre os gatekeepers de zonas diferentes é feita pela troca de mensagens LRQ/ LCF (Location Request/Location Confirm), que serão explicadas na sequência deste capítulo. Os gatekeepers podem ser associados de diversas maneiras. Uma maneira comum é a organização hierárquica, onde um gatekeeper (na figura abaixo, o DGK – Directory Gatekeeper), corresponde ao nível primário da hierarquia, se comunicando com diversos outros gatekeepers de nível secundário (GK A, GK B, GK C). O número de níveis poderia ser aumentado, se necessário. Neste modelo, o DGK conhece os 3 gatekeepers abaixo dele, então esses 3 gatekeepers conhecem apenas o DGK.

Hierarquia de gatekeepers
A organização das zonas H.323 pode também ser feita de forma hierárquica. Supondo que o DGK tenha prefixo 99, GKA tenha prefixo 11, GKB 22 e GKC 33, a configuração para o DGK é:

q

[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
Administração de Videoconferência

GK A

GK B

GK C

Figura 3.5 Organização hierárquica das zonas.

72

A referência de um gatekeeper para o outro é feita através de números E.164 e IPs. Ou seja, é especificado um número (ou um prefixo apenas) que ao ser acionado redirecionará a mensagem para o IP (gatekeeper) ligado a este número. Por exemplo:

DGK=192.168.2.1;55
A linha acima indica um nome, um IP e um número. Quando o gatekeeper que contém esta linha em sua configuração 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 ligações entre os gatekeepers são feitas na seção [RasSrv::Neighbors] do arquivo de configuração. Esta seção 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: números 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 número chamado não é um número local, ou seja, um terminal conectado ao gatekeeper. Se não for o caso, então o gatekeeper verifica seus vizinhos para reencaminhar a chamada. O asterisco (*) indica que para qualquer destino não conhecido (não é um terminal local e não é nenhum dos gatekeepers especificados) a localização deve ser encaminhada ao DGK.

Mensagens LRQ
Em ambientes de videoconferência onde diferentes zonas H.323 se interligam, os gatekeepers de cada área precisam “conversar” entre si. Para a localização de terminais, os gatekeepers de zonas diferentes trocam mensagens LRQ (e as respostas para estas): 11 LRQ: Requisição de Localização 11 LCF: Confirmação de Localização 11 LRJ: Rejeição de Localização O processo de troca dessas mensagens se dá quando um gatekeeper recebe uma chamada em que o destinatário não é conhecido por este gatekeeper, por exemplo. Neste caso, a troca de mensagens se dá da seguinte forma: 11 Gatekeeper “GK” recebe chamada e não encontra destinatário “D” (não é 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;

Capítulo 3 - Plano de numeração e gatekeeper

A sintaxe completa das configurações é mais complexa, onde pode ser inclusive atribuída uma senha para autenticação dos vizinhos. Mais detalhes podem ser encontrados na documentação do GnuGK.

d

q

73

11 O vizinho que encontra o destinatário responde com uma mensagem LCF; 11 Se o vizinho não encontra o destinatário, ele responde com uma mensagem LRJ. O comportamento dessas mensagens é definido na seção [RasSrv::LRQFeatures], que contém os parâmetros: ForwardLRQ 11 Permite ou não o encaminhamento das mensagens LRQ. ForwardResponse 11 Em 1, as respostas ao LRQ passam pelo gatekeeper. 11 Em 0, as respostas vão direto ao originador. ForwardHopCount 11 Quantidade de hops ou gatekeepers pelos quais as mensagens de LRQ passarão. 11 Semelhante ao campo TTL do protocolo IP. Para uma hierarquia de dois níveis, um exemplo de configuração é:

q

[RasSrv::LRQFeatures] ForwardLRQ=depends ForwardResponse=1 ForwardHopCount=1
No GnuGK, o comportamento das mensagens LRQ e suas respostas é definido na seção [RasSrv::LRQFeatures], que contém, entre outros, os parâmetros a seguir.

ForwardLRQ
Aceita as opções: 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 contrário será rejeitada).

ForwardResponse
Controla a necessidade do gatekeeper de receber o LCF quando encaminha mensagens LRQ. Se não configurado, o LCF pode ser encaminhado direto para quem originou o LRQ, sem passar por este gatekeeper.

ForwardHopCount
Atribui um valor numérico para a quantidade de hops ou gatekeepers pelos quais as men Administração de Videoconferência

sagens de LRQ passarão. Semelhante ao campo TTL do protocolo IP, é utilizado para evitar loops infinitos. Padrão de configuração desses parâmetros: 11 ForwardHopCount: não definido. 11 ForwardLRQ: depends. 11 ForwardResponse: 0.

74

Reescrita de números E.164
A funcionalidade de reescrita de número E.164 permite a implantação do plano de discagem. A partir de um determinado número chamado, uma ação de reescrita desse número é realizada com o objetivo de encaminhar a chamada corretamente, o que é feito na seção [RasSrv::RewriteE164]. Para cada regra de reescrita deve-se usar a sintaxe: [!]número-original=número-destino A implementação de um plano de numeração 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 hierárquico. Chamada do terminal A para o B (ambos na área 11) 11 Direto pelo ramal: 2000 11 Com código da área: 11 2000 11 Regra (GK A): 11....=.... Chamada do terminal A para o C 11 Deve incluir código de área e escape: 0 33 1000 11 Regra (GK C): 033....=.... 22 GK A encaminha ligações com prefixo 0 para o DGK. 22 DGK encaminha ligações com prefixo 033 para GK C. A funcionalidade de reescrita de número E.164 permite a implantação do plano de discagem no GnuGK. A partir de um determinado número chamado, uma ação de reescrita

q

desse número é realizada pelo gatekeeper com o objetivo de encaminhar a chamada para o terminal (ou gatekeeper) correto. Fazendo uma comparação com o sistema telefônico, por exemplo, se alguém localizado no Rio Grande do Sul faz uma ligação para o Rio de Janeiro discando “0-xx-21-1234-1234”, este número deve ser encaminhado para o terminal de número “1234-1234”, sendo que os primeiros dígitos (“0-xx-21”) são apenas para permitir que a ligação seja encaminhada corretamente. No GnuGK, a reescrita dos números é feita na seção [RasSrv::RewriteE164], que pode possuir diversas regras com a seguinte sintaxe:

[!]número-original=número-destino
Capítulo 3 - Plano de numeração e gatekeeper

Se a regra começa com número-original, indica que este número deve ser substituído por número-destino. Se a regra começa com o prefixo “!”, inverte-se o sentido da regra, fazendo com que os números que não têm número-original como prefixo, tenham número-destino adicionado como prefixo. Também estão disponíveis os caracteres curinga ‘.’ e ‘%’. O caractere ‘.’ indica que deve haver um dígito qualquer na posição em que ele está, enquanto ‘%’ indica que o número daquela posição será eliminado. Se tivermos, por exemplo, as seguintes regras de reescrita:

[RasSrv::RewriteE164] 08=188 !08=188 (substituição simples) (negação. Tudo que não for 08)

75

%%%%.=. 0044....=144....
Neste caso:

(elimina 4 dígitos) (iniciado com 0044 com pelo menos 4 dígitos 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 implantação de um plano de numeração 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 são aquelas encaminhadas por outros gatekeepers com destino aos terminais da rede local de videoconferência. Chamadas para fora da zona são aquelas com destino a outras redes de videoconferência (outros gatekeepers). Os exemplos abaixo são novamente relacionados com ligações telefônicas e mostram como podem ser necessárias diversas regras caso existam diversos países, áreas e terminais. Os exemplos são de regras em um gatekeeper no Brasil, na área 21. Ele procura reescrever todos os números para o formato <código-país><código-área><código-terminal>, exceto as chamadas para terminais locais, que são reescritas para o número 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 código de área: 11 2000 Regra (GK A) remove código de área: 11....=.... 11 Chamada do terminal A para o terminal C (área 33): 22 Deve sempre ser adicionado ao ramal o código de área do destino e o dígito de escape: 0 33 1000 Regra (GK C): 033....=.... GK A encaminha ligações com prefixo 0 para o DGK. O DGK encaminha ligações com prefixo 033 para o GK C.
DGK

Administração de Videoconferência

Á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

Autenticação
A autenticação e o registro de terminais são feitos através de mensagens RRQ e suas respostas (RCF, RRJ). No GnuGK, a autenticação é configurada na seção [Gatekeeper::Auth]. Diversos mecanismos de autenticação disponíveis: 11 Autenticação simples por alias e IP. 11 Utilização de bancos de dados SQL. 11 Autenticação em servidores RADIUS, entre outros. A autenticação dos terminais é feita através das mensagens RRQ (Registration Request ) enviadas dos terminais para o gatekeeper, e das respostas que o gatekeeper dá a essas

q

mensagens, seja RRJ (Registration Reject ) ou RCF (Registration Confirm). Para mais detalhes das mensagens H.225, reveja o Capítulo 2. No GnuGK, a configuração da autenticação de terminais é feita inicialmente na seção [Gatekeeper::Auth] e se estende para outras seções conforme os mecanismos de autenticação selecionados. Esta seção tem, basicamente, a seguinte estrutura:

[Gatekeeper::Auth] <mecanismo1>=<regra>;RRQ
Capítulo 3 - Plano de numeração e gatekeeper

<mecanismo2>=<regra>;RRQ ...
O exemplo acima mostra a utilização de dois mecanismos de validação, ambos aplicados sobre as mensagens RRQ. A sintaxe das linhas que especificam os mecanismos de validação é a seguinte:

<mecanismo>=<regra>;RRQ
Onde: 11 <mecanismo>: indica como será feita a autenticação: senha simples, utilizando banco de dados SQL, autenticação por IP, entre outras; 11 <regra>: define se este mecanismo é obrigatório, opcional, ou outras opções;

77

11 RRQ: identifica que o mecanismo irá atuar sobre as mensagens RRQ. Pode ser substituído por outros valores, como ARQ e GRQ. No restante dos exemplos será utilizado apenas RRQ para facilitar o entendimento.

Mecanismos
Existem diversos mecanismos de validação disponíveis. Entre os mais importantes estão: 11 SimplePasswordAuth: validação por usuário 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 informações (usuários 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 serviços de autenticação, autorização e contabilização centralizados em um servidor. Um servidor RADIUS pode fazer a ponte entre o GnuGK e uma base LDAP. 11 RadAuth: validação de usuário e senha com base no H.235 e utilizando servidores RADIUS. No restante deste capítulo serão vistos, principalmente, os mecanismos SimplePasswordAuth e AliasAuth. O addpasswd é um utilitário instalado com o GnuGK que permite a criação de senhas criptografadas para serem armazenadas no arquivo de configuração. Duas seções do arquivo de configurações onde senhas costumam ser utilizadas são as seções GkStatus::Auth, para autenticação na conexão com a porta de status, e SimplePasswordAuth, para autenticação de terminais. A sintaxe do aplicativo é simples, basta escolher o arquivo de configuração e a seção deste arquivo, onde a senha será gravada e entrar com o nome de usuário e sua senha. A sintaxe e um exemplo seguem abaixo:

$ addpasswd [arquivo_de_config] [seção] [usuário] [senha] $ addpasswd /etc/gatekeeper.ini GkStatus::Auth admin senha123
Em relação às regras, são elas que especificam como (e quanto) o mecanismo deve ser utilizado. Antes de mostrar as regras disponíveis, é interessante observar que a execução de um mecanismo pode ter como resultado um dos 3 valores a seguir:
Administração de Videoconferência

11 ok : a requisição foi autenticada por este mecanismo; 11 fail: a autenticação com este mecanismo falhou e deve ser rejeitada (uma senha incorreta, por exemplo); 11 next: o mecanismo não pode realizar a autenticação (validação de um nome de usuário não existente na base de dados, por exemplo). Vá para o próximo mecanismo.

Regras
Sabendo dos possíveis resultados, podemos verificar as regras disponíveis: 11 optional: se não puder autenticar com este mecanismo, o próximo mecanismo será utilizado;

78

11 required: a requisição deve ser autenticada utilizando o mecanismo especificado, caso contrário será rejeitada. Ainda assim, o próximo mecanismo configurado será checado para validar o registro; 11 sufficient: o mesmo processo da regra required, com a diferença de que nenhum mecanismo depois desse terá validade. Ou seja, a resposta dada a este mecanismo é a resposta final à autenticação; 11 alternative: o mesmo que sufficient, porém, se o mecanismo não puder decidir se aceita ou nega o registro (se a resposta for next), ele passa a requisição para o próximo mecanismo. Vejamos alguns exemplos do uso de mecanismos e regras de autenticação: 11 Exemplo 1:

[Gatekeeper::Auth] AliasAuth=optional;RRQ SimplePasswordAuth=sufficient;RRQ default=allow
Neste exemplo, primeiro é feita uma tentativa de autenticação por alias, que é opcional. Portanto, se a resposta à autenticação for ok ou next, o processo segue para o próximo mecanismo. Mas se a resposta for fail, a requisição de registro é negada. O próximo mecanismo especificado é o SimplePasswordAuth, onde é feita a autenticação por usuário e senha. Este mecanismo é sufficient e, portanto, decisivo: sua resposta será a resposta final à requisição. Vale observar que os detalhes de cada um desses mecanismos são configurados em seções específicas para cada mecanismo, por isso não são apresentados no exemplo. Além dos mecanismos, o exemplo mostra a linha default=allow, que define como devem ser tratadas as requisições para as quais não foi especificado nenhum mecanismo. Por padrão estamos aceitando (allow) todas as requisições diferentes de RRQ, que são tratadas pelos mecanismos especificados. 11 Exemplo 2:

[Gatekeeper::Auth] SimplePasswordAuth=alternative;RRQ RadAuth=sufficient;RRQ

Autenticação por alias (ID H.323 ou ramal): 11 AliasAuth utiliza a seção [RasSrv::RRQAuth], que possui a sintaxe: <identificador>=sigip:<endereço IP>:<porta> Exemplo:

q

[RasSrv::RRQAuth] 55551234=sigip:200.188.10.1:1720

55556789=sigip:156.130.25.9:1720
Autenticação por usuário e senha: 11 Os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth validam o registro dos terminais analisando usuário e senha de acesso.

Capítulo 3 - Plano de numeração e gatekeeper

default=allow

79

11 O uso de senha requer que o terminal tenha suporte à especificação H.235. Autenticação por usuário e senha: 11 Assim como na validação por alias, cada mecanismo tem sua seção no arquivo de configurações: 22 SimplePasswordAuth: utiliza a seção [SimplePasswordAuth] onde estão os dados de validação. SQLPaswordAuth: utiliza a seção [SQLPasswordAuth] para configurar um banco de dados SQL onde estão contidas as informações de usuário e senha. RadAuth: utiliza a seção [RadAuth] e busca os dados de um servidor RADIUS. Neste segundo exemplo, a primeira autenticação é feita por usuário e senha. Como está configurada como alternative, se o resultado for ok ou fail, esta será a resposta final para a requisição. Mas, caso o resultado seja next, será utilizado o segundo mecanismo, RadAuth, que dará a resposta final. A seguir serão discutidos dois mecanismos de autenticação: a autenticação por alias (especialmente o AliasAuth) e a autenticação por usuário e senha (especialmente o SimplePasswordAuth). Na autenticação por alias, ou seja, por apelido (identificador H.323) ou ramal, podem ser utilizados os mecanismos AliasAuth, SQLAliasAuth e RadAliasAuth. Eles validam as requisições analisando a associação de alias e endereço IP. Todos eles funcionam de maneira semelhante, mas são configurados em seções diferentes do arquivo de configurações e armazenam os dados de autenticação em locais diferentes: 11 AliasAuth: utiliza a seção [RasSrv::RRQAuth], que é onde estão armazenados os dados de autenticação;

q

11 SQLAliasAuth: utiliza a seção [SQLAliasAuth] e busca os dados para autenticação em um banco de dados SQL; 11 RadAliasAuth: utiliza a seção [RadAliasAuth] e busca os dados de um servidor RADIUS. Como citado, o mecanismo AliasAuth utiliza a seção [RasSrv::RRQAuth]. Esta seção possui comandos com a seguinte sintaxe:

<identificador>=sigip:<endereço IP>:<porta>
Onde: 11 <identificador>: alias que será mapeado para o IP especificado. 11 <sigip>: uma das duas opções disponíveis. A outra opção é sigaddr, que informa que o IP e porta estão especificados no formato de uma expressão regular; sigip é uma especialização do sigaddr, para utilização do IP e porta no formato padrão “A.B.C.D:porta”.
Administração de Videoconferência

11 <endereço IP>: endereço IP para o qual o alias será mapeado. 11 <porta>: porta para comunicação com o terminal de IP <endereço 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 também). SimplePasswordAuth: 11 Utiliza a seção [SimplePasswordAuth] que possui a sintaxe:

q

<usuário>=<senha>
11 Senhas de acesso são criadas pelo utilitário addpasswd. Na autenticação por usuário e senha, é possível utilizar os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth. Assim como na validação por alias, cada mecanismo tem sua seção no arquivo de configurações: 11 SimplePasswordAuth: utiliza a seção [SimplePasswordAuth], que já contém os dados de validação; 11 SQLPaswordAuth: utiliza a seção [SQLPasswordAuth] para configurar um banco de dados SQL onde estão contidas as informações de usuário e senha; 11 RadAuth: utiliza a seção [RadAuth] e busca os dados de um servidor RADIUS. Como citado, o mecanismo SimplePasswordAuth utiliza a seção [SimplePasswordAuth]. Esta seção possui os nomes de usuários e suas respectivas senhas, como no exemplo a seguir:

[SimplePasswordAuth] fulano=J4rfje7jdk= sicrano=ee533dgf4g= beltrano=YY64GGrfje7jdk=
A sintaxe de cada linha é <usuário>=<senha>, sendo que estas senhas estão criptografadas, criadas pelo utilitário addpasswd. O uso desta ferramenta já foi explicado e segue um exemplo: Sintaxe:

addpasswd <arquivo_config> <seção> <usuário> <senha>
Exemplo:

addpasswd /etc/gnugk.ini SimplePasswordAuth fulano senha
Todas as opções de autenticação disponíveis, assim como detalhes das configurações do servidor RADIUS e do banco de dados SQL, podem ser obtidos no manual do GnuGK.

Contabilização
Geração de registros das chamadas, imprescindível para avaliar a utilização do sistema. O GnuGK gera um registro com informações detalhadas sobre cada uma das chamadas efetuadas através 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 configuração é feita através da seção [Gatekeeper::Acct] .

q

Capítulo 3 - Plano de numeração e gatekeeper

81

A contabilização no gatekeeper, ou seja, a geração de registros das chamadas, é imprescindível para avaliar a utilização do sistema. O GnuGK gera um registro, denominado Call Detail Record (CDR), que armazena informações detalhadas sobre cada uma das chamadas efetuadas através 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 configuração da contabilização no GnuGK é feita através da seção [Gatekeeper::Acct]. As configurações dessa seção seguem a seguinte sintaxe:

<mecanimo>=<regra>;evento1,evento2,...,eventoN
Os mecanismos e regras da seção de contabilização funcionam nos mesmos moldes do processo de autenticação. Nessa seção podem ser definidos vários mecanismos e também os eventos que serão contabilizados por cada mecanismo. Entre os mecanismos disponíveis, os mais importantes são: 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 seção de autenticação, os mecanismos podem dar uma das três respostas: ok, fail ou next. As regras também são 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 contabilização como fail. Após este mecanismo o evento é passado para o próximo mecanismo configurado; 11 optional: independente de sucesso ou falha, o próximo mecanismo configurado sempre será considerado. Seu resultado não altera o resultado final do processo de contabilização; 11 sufficient: similar ao required, mas em caso de sucesso o processo de contabilização é finalizado; 11 alternative: similar ao sufficient, pois para a execução em caso de sucesso. Mas, em caso de falha, não define o resultado final (ao contrário do que é feito em sufficient e em required ). Como comentado, cada mecanismo pode registrar um ou mais eventos. Os eventos passíveis de registro são: 11 start: registro gerado no início 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 atualização periódica para refletir a nova duração da chamada;
Administração de Videoconferência

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 configurações de contabilização: 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 serão armazenados os eventos start, stop, on e off. O resultado deste segundo mecanismo será o resultado final do processo de contabilização. 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 contabilização no GnuGK é aconselhável consultar o seu manual.

Modos de operação
O gatekeeper pode operar de três formas diferentes: 11 Modo direto: sinalização e mídia são trocadas diretamente pelos terminais. 11 Modo roteamento: sinalização é trocada através do gatekeeper. 11 Modo proxy : sinalização e mídia são trocadas através do gatekeeper.

q

O modo de operação do gatekeeper é o controle sobre as informações de uma chamada que serão encaminhadas através do gatekeeper e quais serão encaminhadas diretamente entre os terminais. O gatekeeper sempre é responsável pelas mensagens de registro de terminais (RAS), entretanto, em termos de sinalização e mídia, pode operar de 3 formas diferentes.

Modo direto
11 Padrão de funcionamento do GnuGK. 11 (+) Gatekeeper não se torna um ponto de falha e/ou gargalo na rede. 11 (-) Não pode haver contabilização das chamadas porque o gatekeeper não participa da inicialização e término das chamadas. Tanto sinalização quanto mídia são trocadas diretamente pelos terminais, sem passar pelo

q

gatekeeper. A figura seguinte mostra este modo de operação, onde se pode ver que as únicas mensagens trocadas com o gatekeeper são as mensagens RAS, para registro dos terminais. Já as mensagens H.225 de sinalização e H.245 são 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

Capítulo 3 - Plano de numeração e gatekeeper

S

H

RA

.2 25

25

S RA

H

.2

O modo direto é o padrão de funcionamento do GnuGK e tem como principal vantagem o fato de que o gatekeeper não se torna um ponto de falha e/ou gargalo na rede caso existam muitas chamadas. Porém, não pode haver contabilização das chamadas porque o gatekeeper não participa da inicialização e término das chamadas.

Modo roteamento
11 O gatekeeper participa de toda troca de sinalização. 11 Mídia é trocada diretamente entre os terminais. 11 (+) Possibilita o controle e a contabilização de chamadas.

q

Sinalização é trocada através do gatekeeper, enquanto a mídia é trocada diretamente entre os terminais. Como se pode ver na próxima figura, agora as mensagens H.225 de sinalização e H.245 passam pelo gatekeeper; no GnuGK é possível indicar que só as mensagens H.225 de sinalização passem pelo gatekeeper, enquanto o H.245 é trocado diretamente pelos terminais, como será visto na sequência.
Gatekeeper

H

.2

25

RA

S

H.225/H245 Call Signaling

RTP Channels

Terminal 1

Terminal 2

Figura 3.9 Gatekeeper operando em modo roteamento.

Este modo de operação tem a vantagem de possibilitar o controle e a contabilização de chamadas, e, como no modo direto, dificilmente o gatekeeper se tornará um gargalo na rede, pois ele só recebe mensagens de sinalização, enquanto a mídia (os dados que realmente ocupam banda) é trocada diretamente pelos terminais.

Modo proxy
Tanto sinalização quanto mídia são trocadas através do gatekeeper. 11 (+) Auxilia quando existem terminais com endereços NAT.
Administração de Videoconferência

q

11 (+) Auxilia quando existem firewalls na rede. Não é necessário liberar o acesso a todos os terminais, mas apenas ao gatekeeper. 11 (+) Configuração de QoS; a política de QoS pode ser aplicada apenas ao endereço IP do gatekeeper. 11 (-) Pode tornar-se um ponto de falha e gargalo na rede. Tanto sinalização quanto mídia são trocadas através do gatekeeper. Neste modo de operação, nenhum dado é trocado diretamente entre os terminais, tudo passa pelo gatekeeper.

84

Gatekeeper

Ch an ne l

s

P RT

S

H

l ne an Ch

RA

.2 25

RT P

25

RA

H

.2

s

S

H.225/H245 Call Signaling

Figura 3.10 Gatekeeper operando em modo proxy.

Terminal 1

Terminal 2

Este modo possui algumas vantagens: 11 Auxilia quando existem terminais com endereços NAT “invisíveis” ao mundo; 11 Auxilia quando existem firewalls na rede. Em um terminal, não é necessário liberar o acesso a todos os terminais, mas apenas ao gatekeeper, já que todas as mensagens e mídias serão recebidas do gatekeeper; 11 Configuração de QoS. A política de QoS pode ser aplicada apenas ao endereço 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 tráfego de todas as chamadas passará por ele.

Configurando o GnuGK
O roteamento é configurado na seção [RoutedMode]:

q

[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:
Capítulo 3 - Plano de numeração e gatekeeper

22 Se H245Routed=0, faz roteamento apenas de mensagens H.225. 22 Se H245Routed=1, faz roteamento também de mensagens H.245. AcceptNeighborCalls deve estar em 1 para que o gatekeeper reconheça outras zonas H.323 (outros gatekeepers). Para habilitar o modo proxy, deve-se configurar a seção [Proxy]:

[Proxy] Enable=1
Na seção de roteamento deve estar configurado GKRouted=1.

85

O modo de operação é configurado no GnuGK em duas seções. O roteamento, que define se o gatekeeper fará roteamento das mensagens H.225 e H.245 é configurado na seção RoutedMode. Abaixo são exibidos os principais parâmetros desta seção:

[RoutedMode] GKRouted=1 H245Routed=1 CallSignalPort=0 H245PortRange=30000-30999 AcceptNeighborCalls=1 AcceptUnregisteredCalls=0
O parâmetro GKRouted indica se o gatekeeper fará o roteamento de algum tipo de mensagem ou não, enquanto H245Routed indica se ele fará roteamento das mensagens H.245. Assim, temos as seguintes opções de configuração: 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 sinalização; 22 Se H245Routed=1, faz roteamento também de mensagens H.245. Esta seção possui diversos outros parâmetros: CallSignalPort Porta de sinalização do gatekeeper (padrão é 1721). Não é utilizada a porta 1720 para ser possível executar um terminal H.323 de testes no mesmo computador do gatekeeper. Pode ser configurado com a opção 0 para deixar o gatekeeper escolher arbitrariamente uma porta. H245PortRange Portas para serem usadas para os canais de controle H.245. O padrão é 0, que deixa o sistema operacional selecionar as portas. AcceptNeighborCalls Permite ou não receber ligações de gatekeepers vizinhos. O padrão é 1: permitir. AcceptUnregisteredCalls Permite ou não chamadas de terminais não registrados no gatekeeper. O padrão é 0: não permitir.
Administração de Videoconferência

Na seção RoutedMode são configurados os modos de operação direto e roteamento. Para configurar o modo proxy, primeiro deve-se habilitar o roteamento (GKRouted=1) e então configurar a seção [Proxy]. Com o modo proxy habilitado, não é necessário habilitar o roteamento H.245 (H245Routed), pois o gatekeeper fará isso automaticamente quando necessário.

[Proxy] Enable=1 ProxyAlways=0 InternalNetwork=192.168.1.0/24

86

ProxyForNAT=1 T120PortRange=4000-5000 RTPPortRange=1024-65535
A seção [Proxy] também possui diversos parâmetros, entre eles: Enable Habilita ou desabilita o modo proxy. O padrão é 0, desabilitado. ProxyAlways Se setado, habilita o proxy sempre, independente das outras configurações feitas nesta seção. InternalNetwork Especifica as redes internas ligadas ao gatekeeper. Por padrão não é 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 não o IP padrão ou IP externo definidos em outras seções 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á atrás de uma NAT. T120PortRange Portas para os canais de dados T.120. Por padrão não é especificado, o que deixa o sistema operacional alocar as portas. RTPPortRange Portas para os canais UDP para os canais RTP/RTCP. Por padrão especifica as portas 1024-65535.

Capítulo 3 - Plano de numeração e gatekeeper

87

88

Administração de Videoconferência

Roteiro de Atividades 3
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 videoconferência da dupla para utilizar o gatekeeper de um

dos membros da dupla (criado durante a seção teórica);
2. Verifique, via telnet (putty), se os clientes estão conectados (usando a porta de status); 3. Efetue ligações 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 videoconferência estão na mesma máquina, a opção CallSignalPort=1720 NÃO deve estar configurada no GnuGK. Ao modificar o gatekeeper no software de videoconferência, ele deve ser reinicializado para a configuração fazer efeito. Outra opção é 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 conexão de clientes autorizados
Configure o GnuGK para que ele só permita conexões de clientes autorizados. Esta autorização será feita por IP e ramal.
1. Incluir a seção [Gatekeeper::Auth] e o parâmetro AliasAuth dentro dela. Verifique os

exemplos dados durante a aula;
2. Incluir a seção [RasSrv::RRQAuth], onde serão autenticados os terminais; 3. Um terminal da dupla terá o ramal 1000 e o outro terá o ramal 2000: 3.1. Exemplo de autorização 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 Capítulo 3 - Roteiro de Atividades

gurado no mesmo painel de configurações onde é configurado o IP do gatekeeper;
5. Registrar os terminais da dupla ao gatekeeper e tentar fazer ligações de um para o outro

utilizando os ramais (não 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 mídia através do GnuGK. As duplas devem interagir a fim de que cada dupla utilize o gatekeeper da outra, pois assim será possível visualizar corretamente a troca de mensagens no Wireshark, pois se um mesmo IP for cliente (terminal) e também gatekeeper, ficará mais difícil saber para onde são transmitidas as mensagens.
1. Incluir seção [RoutedMode]. Nesta seção, configurar parâmetros GKRouted=1 e H245Routed=1. 2. Incluir seção [Proxy]. Nesta seção, configurar Enable=1. 3. Inicialize o Wireshark em ambas as máquinas para verificar se os pacotes H.245 e dados

de mídia estão sendo enviados e recebidos através 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

estão sendo transmitidos? Há algum pacote transmitido diretamente entre os clientes?

5. Justifique como o modo proxy poderia ser útil em um ambiente real de videoconferência.

Atividade 4 – Configurando o DGK na rede
Nesta atividade iremos configurar o gatekeeper para que as chamadas sejam efetuadas através do DGK, o gatekeeper central que fará a comunicação entre os diversos gatekeepers da sala (os gatekeepers de cada dupla). Para isso cada dupla receberá uma numeração com 2 dígitos (ex: 11, 22, 33, ...) que corresponderá ao “código de área” da dupla. É preciso desligar todos os gatekeepers que não serão utilizados e desabilitar a opção proxy que foi habilitada na atividade anterior. A atividade funcionará da seguinte maneira:
1. Ligações feitas utilizando somente o ramal (1000 ou 2000) continuarão funcionando como
Administração de Videoconferência

nas atividades anteriores: são ligações locais que só utilizam o gatekeeper da dupla;
2. O zero como prefixo será utilizado para indicar que a ligação será feita para outra dupla

(outra área, assim como ligações telefônicas para outro DDD);
3. Todas as ligações feitas utilizando o número zero como primeiro dígito serão encami-

nhadas para o DGK. O DGK, por sua vez, encaminhará a ligação 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 serão feitas as ligações:

90

Chamada 2:

0222000

Gk dupla

11

DGK Chamada 1: 2000 ou 0112000 Gk dupla

Figura 3.11 Arquitetura de gatekeepers e estrutura das ligações.

22

Máquina 1

1000

Máquina 2

2000

Máquina 1

1000

Máquina 2

2000

Utilize o Wireshark para depurar possíveis problemas durante a atividade. Atividades:
1. Configurar seção [RasSrv::RewriteE164] para reescrita de ramais como no exemplo:

0111000 para 1000, 0112000 para 2000. Este exemplo é válido para a dupla 11. Ele indica que quando o gatekeeper receber uma ligação com o número 0111000, essa ligação será direcionada para o ramal 1000 (o mesmo é válido para o ramal 2000).
2. Configurar seção [RasSrv::Neighbors] para incluir o DGK como um dos vizinhos do

gatekeeper. O professor informará o endereço IP do DGK.
3. Cada dupla deverá informar o endereço 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 também 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?

Capítulo 3 - Roteiro de Atividades

91

92

Administração de Videoconferência

4
Introdução ao SIP
objetivos
Proporcionar uma visão ampla do protocolo Session Initiation Protocol (SIP), bem como dos métodos de configuração de um servidor SIP.

conceitos

Introdução ao SIP (arquitetura, requisições e respostas, exemplos), comparação entre SIP e H.323, servidor OpenSIPS (configurações básicas, plano de discagem e autenticação de clientes).

Session Initiation Protocol (SIP)
Protocolo de sinalização para inicialização, modificação e fechamento de sessões interativas como: 11 Chamadas de voz (VoIP). 11 Videoconferência. 11 Mensagens instantâneas. 11 Jogos multi-usuário via internet. Protocolo para início de sessão, utilizado em conjunto com outros protocolos: 11 SDP – para descrição da sessão. 11 SAP – anúncio de sessão. 11 RTP/RTCP – transmissão de dados e controle da transmissão. 11 RTSP – controle de fluxo em tempo real. 11 SCCP – controle de conferência.

q

Capítulo 4 - Introdução ao SIP

93

SIP Aplicação RTSP RTP SDP RTP

Transporte

TCP

UDP

Rede

IP

Camada de enlace

Ethernet

Figura 4.1 Protocolo de aplicação SIP.

SIP é um protocolo que está na camada de aplicação. Alternativo ao H.323 que surgiu em meados da década de 1990, quando a primeira versão do H.323 já estava se tornando um padrão. Inicialmente o SIP foi desenvolvido na Universidade de Columbia e, depois, submetido em 2002 como padrão da Internet Engineering Task Force (IETF) – RFC 3261. SIP é um padrão de sinalização emergente para o estabelecimento de chamadas e conferências em tempo real em redes IP. Ele já é o padrão mais utilizado atualmente para chamadas de voz sobre IP. Já para chamadas de vídeo, o H.323 ainda domina, mas o SIP vem cada vez ganhando mais espaço neste nicho. Uma sessão SIP pode incluir diferentes tipos de dados, como áudio, vídeo, 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 usuários numa rede IP de modo totalmente independente do conteúdo de mídia da chamada. O SIP é um protocolo de aplicação 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 eletrônico, e o HTTP para páginas 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 nível de aplicação. As mensagens existentes no SIP são utilizadas para inicialização, finalização e configuração de chamadas. Ou seja, ele é um protocolo para início de sessão, 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
Administração de Videoconferência

RTSP (Real-Time Streaming Protocol ).

Arquitetura do SIP
Arquitetura cliente/servidor em que agentes de usuário (os terminais) são formados por duas entidades: 11 User Agent Client (UAC): a parte “cliente” do agente, responsável por iniciar as requisições SIP. 11 User Agent Server (UAS): a parte “servidor” do agente, responsável por receber e responder as requisições SIP.

q

94

Um mesmo terminal pode ser UAC e UAS, dependendo da função que está exercendo. Além dos agentes de usuário, o SIP possui três tipos de servidores: 11 Servidor de redirecionamento: redireciona pedidos SIP (retornando com a nova localização). 11 Servidor de registro: aceita registros de entidades SIP. 11 Servidor de proxy: executa o roteamento de pedidos e respostas SIP. Peer to Peer também é possível!

q

A arquitetura SIP tem por base uma estrutura fundamentada na arquitetura cliente-servidor. Os terminais SIP são chamados de agentes de usuário. O agente de usuário é dito “inteligente”, pois armazena e gerencia o estado da chamada. Também pode utilizar endereços de correio eletrônico ou número telefônico (E.164) na execução das chamadas. Os agentes de usuário ainda podem aceitar e receber chamadas de outros agentes sem a necessidade de adicionar outros componentes SIP.

Figura 4.2 Comunicação peer to peer entre componentes SIP.

Os agentes de usuário são formados por duas entidades: 11 UAC – User Agent Client é a entidade que realiza o papel de cliente no agente de usuário. Responsável pela inicialização dos pedidos de sessão (início das chamadas) e envio de requisições. 11 UAS – User Agent Server é a entidade que realiza o papel de servidor no agente de usuário. É responsável pelo recebimento das requisições enviadas pelos UACs e pelas respostas enviadas a estas requisições. Além dos agentes de usuários, o SIP especifica três tipos de servidores: 11 SIP Proxy Server (servidores proxy): tipo de servidor intermediário SIP, responsável pelas tarefas de receber as requisições e enviá-las aos outros servidores. Seu objetivo é basicamente rotear as chamadas, ou seja, garantir que elas chegarão ao destino (ou até uma entidade mais próxima do destino). Ele age tanto como um cliente quanto como um servidor, roteando requisições e respostas. Eles também podem ser utilizados para implementar políticas nas chamadas (verificar permissões dos usuários, por exemplo) e podem atuar como conversores de mídias. 11 SIP Registrar (servidores de registro): servidor que recebe e processa mensagens de registro (REGISTER). Provê um mecanismo de localização de usuários, associando IPs a endereços dos usuários (URIs identificadas no padrão “sip:usuario@dominio.com”), com funcionamento análogo ao de um servidor DNS. Vale observar que mais de um IP pode estar associado ao mesmo endereço, ou seja, um mesmo usuário pode estar registrado em diversas máquinas (IPs). 11 SIP Redirect Server (servidores de redirecionamento): o papel dos servidores de redirecionamento SIP, como o próprio nome já diz, é redirecionar os pedidos ao servidor de registro. O servidor de redirecionamento SIP responde ao UAC, provendo as informações de endereçamento dos servidores e, então, o cliente encaminha as requisições ao endereço fornecido.
Capítulo 4 - Introdução ao SIP

95

A imagem seguinte ilustra a integração 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 organização dos elementos SIP.

SIP registrar

Request Response

Na imagem, as mensagens com o prefixo “x” são independentes das outras e a troca delas é feita antes das demais, durante o registro dos terminais no servidor registrar. As mensagens são iguais para os dois terminais: 11 O terminal envia uma mensagem de REGISTER para o servidor solicitando seu registro. Esta mensagem contém a identificação 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 descrição das demais etapas da imagem:
1. Um determinado terminal (User Agent ) disca para outro terminal. É o UAC deste terminal

que faz a requisição;
2. A requisição é recebida por um SIP Proxy que consulta um servidor de redirecionamento

SIP para saber para onde esta requisição deve ser encaminhada;
3. O servidor de redirecionamento responde ao proxy; 4. O proxy então contata outro proxy, cujo endereço foi informado pelo servidor de

redirecionamento;
5. O segundo proxy contata um serviço de localização para tentar encontrar o terminal destino;
Administração de Videoconferência

6. O serviço de localização informa ao segundo proxy a localização do terminal de destino; 7. O segundo proxy contata um terceiro proxy, que está mais próximo do destino; 8. O último proxy da sequência conhece o terminal destino e encaminha a ele a requisição; 9. O UAS do terminal destino responde à requisição; 10. De 10 a 12, a resposta volta para o terminal de origem através dos proxies SIP. Note que

não é preciso contatar serviços de localização ou de redirecionamento, pois o protocolo SIP guarda informações para permitir que as respostas sejam encaminhadas pelo mesmo caminho percorrido pelas requisições.

96

Mensagens e respostas SIP
11 INVITE 11 ACK 11 BYE 11 CANCEL 11 OPTIONS 11 REGISTER Exemplos: BYE e CANCEL. 11 Ambas são mensagens enviadas com o intuito de finalizar a sessão. 11 BYE é enviado após a sessão já estar estabelecida. 11 CANCEL é enviado para cancelar o estabelecimento da sessão (chamada ainda não atendida quando o telefone está tocando, por exemplo). Exemplo de uma requisição INVITE:

q

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
Além dos campos do exemplo anterior, o INVITE utiliza o protocolo SDP para descrever a
Capítulo 4 - Introdução ao SIP

sessão, especialmente em relação às mídias 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 requisições e possíveis respostas do SIP estão definidas na RFC 3261, de 2002. A RFC define 6 possíveis requisições e 6 classes de respostas, que seguem um formato similar ao protocolo http, onde as requisições são identificadas por palavras como REGISTER e INVITE, e as respostas são identificadas por um conjunto de 3 números e classificadas conforme o primeiro número. As tabelas a seguir apresentam estas requisições e respostas com seus devidos significados: Requisitos (Cliente para servidor) INVITE Iniciar chamada Respostas (Servidor para cliente) 1xx Informacional (telefone tocando, por ex.) ACK Confirmação 2xx Sucesso (a mais usada é 200 OK) BYE Finalizar chamada 3xx Redirecionamento (típica de servidores redirect ) CANCEL Cancelar requisição pendente Funcionalidades Suportadas REGISTER Registro com o servidor de localização 6xx 4xx Falha na requisição (usuário não disponível, codec incompatível etc) 5xx Falha no servidor (servidor indisponível, feature não encontrada no servidor etc) Falha global (falha desconhecida, quando não é nenhuma das outras)
Figura 4.4 Requisições da RFC 3261 (SIP).

OPTIONS

A seguir uma requisição INVITE para exemplificar o formato das requisições 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
Administração de Videoconferência

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 usuário de nome Marcos, identificado por sip:marcos@esr.rnp.br (na máquina de IP 143.54.12.10) está fazendo uma chamada para Aline, identificada por aline@inf.ufrgs.br. Estas informações podem ser vistas nos campos “From”, “To”, “Contact” e no cabeçalho da mensagem. Outro campo bastante importante é o campo “Via”, que indica para onde a resposta a esta requisição deve ser enviada, no caso o domínio sip.ufrgs.br. O uso deste campo permite que as respostas voltem facilmente para o originador da requisição. Além dos campos padrão, as requisições INVITE podem utilizar o protocolo SDP para descrever a sessão, com destaque para a descrição das mídias. O protocolo SDP também é baseado em mensagens de texto e possui uma sintaxe bastante simples com diversas linhas no formato <atributo>=<valor>. Os atributos são formados por apenas uma letra, e os valores variam conforme o atributo que está sendo especificado. Abaixo é exibido exemplo da descrição SDP de uma sessão:

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 : Versão do protocolo. 11 o: Originador da requisição. 11 s: Nome da sessão. 11 i: Informações sobre a sessão. 11 u: URI da descrição. 11 e: E-mail. 11 t: Tempo de atividade da sessão. 11 m: Nome da mídia e tipo de transporte; identifica as mídias possíveis nesta sessão.
Capítulo 4 - Introdução ao SIP

99

Outros exemplos são o BYE e o CANCEL, mensagens enviadas para finalizar a sessão: BYE é enviado após a sessão estar estabelecida, e CANCEL é enviado para cancelar o estabelecimento da sessão (por exemplo em uma chamada ainda não atendida quando o telefone está tocando). Quanto às possíveis respostas, temos como exemplos as mais utilizadas: 2xx – Sucesso 11 200 - OK. 3xx – Redirecionamento 11 300 - Múltiplas escolhas. 11 301 - Movido permanentemente. 11 302 - Movido temporariamente. 4xx – Falha na requisição 11 400 - Bad request. 11 401 - Não 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 através da requisição REGISTER. A requisição é 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

1

Informa que o usuário aluno@esr.br está na máquina 143.54.10.12. Válido por 1 hora.

Administração de Videoconferência

2 3
200 ok Banco de dados

Figura 4.5 Requisição REGISTER SIP.

No exemplo, (1) o terminal SIP envia a requisição de registro para o servidor localizado no endereço sip:esr.rnp.br. Entre as informações da requisição estão: 11 To: contém o endereço de quem está se registrando, no caso aluno@esr.rnp.br. 11 From: contém o endereço de quem está enviando a requisição. Normalmente é igual ao campo “to”, exceto quando a requisição de registro é enviada por terceiros. 11 Contact: informa o endereço da máquina na qual o usuário pode ser encontrado. 11 Expires: duração do registro (em segundos). No exemplo, 1 hora.

100

(2) A requisição é recebida pelo servidor registrar, que armazenará as informações do novo usuário registrado, normalmente em um banco de dados. (3) Efetuado o registro no lado do servidor, ele responde para o cliente informando sucesso (código 200).

Diagrama de uma chamada SIP
Terminal A Proxy Terminal B

Inicia a ligação

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 Comunicação de dados RTP BYE 200 – ok

7 8 9

Figura 4.6 Troca de mensagens SIP entre dois terminais e um proxy.

Comunicação de dados

Finaliza ligação

O exemplo ilustra as mensagens SIP trocadas entre dois terminais e um proxy, localizado entre estes terminais, durante uma ligação. Os passos são descritos abaixo:
1. O terminal origem A inicia a ligação, discando para o terminal com endereço

sip:aluno@esr.rnp.br através de uma requisição INVITE;
2. O proxy interpreta a requisição e a encaminha para a máquina de endereço 143.54.12.10,

que é a máquina na qual o usuário aluno@esr.rnp.br foi registrado. Aqui assumimos que o proxy já conhece o endereço do terminal destino B, que poderia ser descoberto com uma consulta a um servidor de localização.
3. Enquanto a requisição está sendo encaminhada para o terminal B, o proxy avisa ao ter-

minal A que está tentando prosseguir com a comunicação (TRYING);
4. Assim que o terminal B recebe a requisição inicial (INVITE), ele alerta o usuário de que

uma chamada foi recebida, normalmente fazendo o telefone tocar (ring );
Capítulo 4 - Introdução ao SIP

5. Assim que o usuário no terminal B atende a ligação, o terminal envia uma resposta com

código 200 (OK), que é recebida pelo proxy e encaminhada para o terminal origem;
6. Ao receber a resposta, o terminal A passa a conhecer o endereço direto do terminal B, e

encaminha para ele uma requisição do tipo ACK para confirmar que a ligação foi estabelecida. Neste ponto os terminais já trocaram suas capacidades através do protocolo SDP embutido nas mensagens INVITE e 200 (OK) e com isso já estabeleceram os parâmetros da transmissão, entre eles os codecs de áudio e vídeo e as portas para trocar esses dados;

101

7. Durante a comunicação a troca de dados é feita usando o protocolo RTP; 8. Em determinado momento o usuário do terminal A decide finalizar a ligação (colocando

w
O site Tech-invite apresenta uma descrição do SIP baseada em exemplos, mostrando diversas requisições e respostas de forma gráfica.

o fone no gancho). Seu terminal envia uma requisição do tipo BYE diretamente para o terminal B avisando que a ligação deve ser finalizada;
9. O terminal B recebe a requisição e envia uma resposta com o código 200 (OK). A ligação

está finalizada.

Comparação SIP e H.323
Funcionalidades similares através de mecanismos diferentes: 11 SIP ≈ H.225 (RAS + Q.931) 11 SDP ≈ H.245 11 Utilizam o mesmo protocolo de transmissão de mídias: RTP/RTCP 11 SIP utiliza texto enquanto H.323 usa binário (ASN.1) Comparação geral: 11 SIP é utilizado largamente em aplicações de VoIP. 11 H.323 é mais utilizado para vídeo. 11 Utilização de SIP com vídeo (videoconferências) tem crescido e tende a ser tão usual quanto H.323. 11 Normalmente os softwares e equipamentos baseados em H.323 também suportam o padrão SIP. Exemplos: 11 Novas linhas de terminais dos principais fabricantes: Polycom, Cisco/Tandberg e Radvision. 11 Um grande número de softwares utilizam SIP para vídeo. 11 Consulte a lista de exemplos no site “Product showcase of SIP Conferencing solutions”.

q

Assim como o H.323, o SIP é um protocolo que pode ser utilizado para videoconferências em redes IP. Ele apresenta funcionalidades similares ao H.323, mas que são alcançadas através de mecanismos ou protocolos diferentes. A grande diferença entre os protocolos está em sua base: nos protocolos usados para a troca de mensagens (registro, sinalização 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 diferença importante é no formato de codificação das mensagens: enquanto o H.323 utiliza uma codificação binária (ASN.1), o SIP utiliza um modelo mais simples de mensagens textuais, com base em protocolos como o HTTP.
Administração de Videoconferência

As entidades existentes na topologia de cada um dos protocolos também são diferentes, mas possuem certa equivalência em suas funcionalidades. Os terminais H.323 são simplesmente chamados de “terminais”, enquanto os terminais SIP são normalmente chamados de “agentes de usuários”, e são formados por duas partes: UAS (servidor) e UAC (cliente). No que se refere ao registro de usuários, o gatekeeper do H.323 é equivalente ao servidor SIP registrar. Já para o redirecionamento de mensagens, o SIP utiliza proxies específicos ou servidores de redirecionamento, enquanto no H.323 este controle é feito pelo gatekeeper. Além disso, ambos os protocolos utilizam gateways para comunicação com redes externas.

102

Apesar das diferenças, os protocolos apresentam alguns pontos em comum: ambos utilizam o protocolo de transmissão de mídia 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 Codificação Topologia Textual (HTML) Entidades: UA, servidores de localização, servidores de registro, servidores proxy etc. Via protocolo SDP Topologia hierarquia (DNS) UDP e TCP Registro HTTP Possui três métodos de encriptação H.323 Binário (ASN.1) Entidades: gatekeeper, gateway, terminais etc. H.245 Anexo G: comunicação entre domínios administrativos UDP e TCP Gatekeeper H.235 H.235

Troca de capacidades Roteamento de chamadas Protocolo de transporte Registro Autenticação
Figura 4.7 Principais aspectos SIP e H.323.

Encriptação

O website “Product showcase of SIP Conferencing solutions” mostra uma lista de soluções de conferência que utilizam SIP.

à aplicação atual de cada um dos protocolos, o uso do SIP já está amplamente w Quanto difundido para uso em aplicações VoIP, enquanto o H.323 é o mais utilizado para videoconferências. Apesar disso, a utilização do SIP para videoconferências tem crescido, e ele tende a tornar-se tão ou mais utilizado que o H.323. Um dos motivos para isso é a tendência no mercado para que equipamentos baseados em H.323 passem a suportar também o padrão SIP. Diversas linhas de terminais dos principais fabricantes já suportam SIP (Polycom, Cisco/ Tandberg e Radvision), assim como um grande número de terminais em software.

OpenSIPS
11 Open SIP Server é um software livre sob licença GPL. 11 Servidor SIP completo: registrar, location, proxy e redirect. Algumas características: 11 Segue uma arquitetura modular buscando escalabilidade. 11 Flexibilidade de programação (linguagem de script). 11 Suporte à autenticação, autorização e contabilização via Radius ou SGBD.

q

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 adaptação a sistemas pequenos com recursos limitados e também a sistemas grandes. É capaz de suportar milhares de chamadas por segundo, e graças à sua arquitetura modular permite a criação de novas funcionalidades (módulos e API) conforme a necessidade do cliente. Segundo o site do projeto, em sistemas com 4GB de memória ele suporta 300 mil usuários on-line, e pode suportar até 5 mil chamadas por segundo quando em modo stateless.

103

Capítulo 4 - Introdução ao SIP

11 Integração com SGBDs: MySQL, Postgres, entre outros.

Instalação OpenSIPS
As últimas versões do OpenSIPS podem ser obtidas no site. A instalação 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 é possível baixar e compilar o código-fonte. Sendo uma aplicação de código aberto, o OpenSIPS disponibiliza em sua página tanto o código-fonte da aplicação quanto alguns pacotes (binários) para sistemas específicos.

q

Atualmente, são disponibilizados pacotes para as plataformas OpenSUSE, CentOS, Fedora e Debian, sendo este último utilizado neste curso. A instalação do OpenSIPS possui algumas peculiaridades conforme a plataforma na qual está sendo instalado. Não consta no escopo deste curso a abordagem de todas as opções possíveis, portanto a instalação será feita de forma simples, utilizando pacotes já compilados. Este curso se baseia no uso do OpenSIPS em uma máquina virtual com o sistema Linux, o mesmo modelo adotado no capítulo sobre GnuGK. Para instalar o OpenSIPS de forma prática, basta fazer download do pacote para Debian e instalá-lo com o gerenciador de pacotes. Após a instalação do OpenSIPS, os arquivos mais importantes da aplicação estarão instalados em: 11 Arquivo de configurações iniciais: /etc/default/opensips 11 Arquivo de configurações gerais: /etc/opensips/opensips.cfg 11 Arquivos binários: /usr/sbin/ 11 Módulos: /usr/lib/opensips/modules/ 11 Logs: /var/log/ O arquivo de configurações iniciais chamado “opensips” contém algumas configurações básicas necessárias para a inicialização do OpenSIPS, como o usuário e o grupo do sistema operacional que serão utilizados e a quantidade de memória que será alocada para a aplicação. Este arquivo também contém uma opção chamada “RUN_OPENSIPS” que está inicialmente com o valor “no”, com intuito de não permitir a execução da aplicação antes que ela seja configurada. Após a configuração, basta modificar o valor desta opção para “yes” que a execução do OpenSIPS é liberada. Já o arquivo “opensips.cfg” contém as configurações do funcionamento do servidor Open Administração de Videoconferência

SIPS. Este arquivo segue um formato de linguagem script, que permite que as funcionalidades do servidor sejam programadas. As configurações do restante deste capítulo serão feitas neste arquivo. Os arquivos executáveis da aplicação estão localizados no diretório /usr/sbin/ e os módulos utilizados estão em /usr/lib/opensips/modules/.

Inicialização OpenSIPS
Existem diversas opções de inicialização do OpenSIPS, que podem ser verificadas através do comando:

q

$ opensips –h

104

Comando opensips: 11 [-f arquivo] – especifica arquivo de configuração. 11 [-c] – verifica se existem erros no arquivo de configuração. 11 [-d] – nível de debug; quanto maior o número de d’s, maior será o nível de debug. 11 [-l protocolo:interface:porta] – especifica as interfaces de rede que serão utilizadas (protocolos UDP ou TCP). Exemplo:

q

$ opensips –l udp:192.168.1.100:5080 –f /usr/local/etc/opensips/ opensips.cfg -d
O utilitário opensipsctl é um script utilizado para realizar operações de manutenção no OpenSIPS. Este utilitário é muito útil para diversas tarefas: 11 Iniciar/parar a aplicação. 11 Obter listagem de usuários on-line. 11 Informações estatísticas de uso do sistema. O comando opensips deve ser usado pelo super usuário (root). Usuários normais normalmente não possuem acesso ao comando sem especificar o caminho completo da aplicação. Ou seja, um usuário normal precisaria executar o comando /usr/sbin/opensips. É necessário configurar o arquivo /etc/default/opensips antes de executar o OpenSIPS pela primeira vez. Para auxiliar a realização de algumas tarefas, existe o utilitário opensipsctl. Este script pode executar diversas tarefas, entre elas iniciar e parar a aplicação, obter listagem de usuários on-line e informações estatísticas de uso do sistema. Alguns comandos possíveis: 11 opensipsctl stop|start|restart 11 opensipsctl ul show – exibe lista de usuários. 11 opensipsctl online – exibe usuários on-line. 11 opensipsctl monitor – monitora a aplicação atualizando as informações periodicamente. Para uma lista de todas as opções possíveis basta executar o comando opensipsctl sem nenhum parâmetro adicional. Além deste script, outra forma de inicializar o OpenSIPS é utilizando o script do sistema operacional para inicializar a aplicação durante o boot:

$ /etc/init.d/opensips <opção>
Opções possíveis: start, stop, restart, force-reload, debug e status. Para vê-las, basta executar o comando sem fornecer nenhuma opção.
Capítulo 4 - Introdução ao SIP

Se o OpenSIPS já estiver em execução, o comando opensipsctl start vai falhar, o que normalmente acontece porque o sistema já iniciou a aplicação durante o boot. Portanto, primeiro pare a aplicação com /etc/init.d/opensips stop. Com as configurações padrão 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 validação nenhuma. Já é possível também fazer ligações de um cliente para o outro informando o nome do usuário do outro cliente.

105

Arquitetura modular OpenSIPS
A estrutura do OpenSIPS pode ser dividida em duas partes: 11 Núcleo: responde pelo funcionamento básico e controle dos módulos. 11 Módulos: cada um adiciona funcionalidades específicas ao software, inclusive as funcionalidades SIP. Principais módulos: Função proxy 11 Transaction (TM) 11 Stateless Replier (SL) 11 Record-Route e Route Mode (RR) Função registrar 11 Registrar Função location 11 Localização de usuários (Usrloc) 11 Database API (MySQL, Postgres e DBtext) Funções gerais 11 Contabilização (ACC) 11 Autenticação (AUTH) 11 Autenticação com banco de dados (AUTH_DB) Os módulos são carregados através do arquivo de configurações.

q

OpenSIPS adota uma arquitetura modular, onde o software é composto por um núcleo básico ao qual podem ser conectados diversos módulos para prover funcionalidades ao software. 11 Núcleo: responde pelo funcionamento básico e controle dos módulos. O núcleo é responsável pelas configurações locais, como nível de depuração, portas TCP e UDP utilizadas, modo de operação etc; 11 Módulos: existem diversos módulos, sendo que cada um adiciona funcionalidades específicas ao software, inclusive as funcionalidades SIP. Os módulos são carregados através do arquivo de configurações, onde é possível passar parâmetros para a sua inicialização. Ao carregar um módulo, ele proverá funções que podem ser utilizadas na programação do arquivo de configurações. O OpenSIP disponibiliza diversos módulos. Segue uma lista com uma breve descrição dos mais importantes:
Administração de Videoconferência

11 Módulo TM: processamento de transações SIP stateful (transações stateful e stateless serão explicadas posteriormente); 11 Módulo SL (Stateless Replier): implementa a função de proxy SIP stateless, ou seja, é capaz de responder a requisições SIP sem manter o estado da comunicação; 11 Módulo RR (Record-Route e Route Mode): implementa as funções de controle do modo de roteamento (Route); 11 Módulo Registrar : implementa a lógica de processamento do método REGISTER para registro de usuários;

106

11 Módulo USRLOC (User Location): mantém a tabela de localização de usuários e provê acesso a essa tabela para outros módulos; 11 Módulos DB_*: existem diversos módulos com nome iniciado pelo prefixo “DB_”, o que indica que são módulos que permitem a interação do OpenSIPS com alguma base de dados. Há entre eles os módulos DB_MYSQL, DB_POSTGRES e DB_TEXT, que proveem, respectivamente, comunicação com o banco de dados MySQL, com o banco de dados Postgres e com bancos de dados em formato texto; 11 Módulo AUTH: implementa funções básicas de autenticação; 11 Módulo AUTH_DB: implementa funções de acesso a banco de dados para autenticação. Depende dos módulos AUTH e de banco de dados (MySQL, Postgres etc).

w
A lista completa de módulos pode ser encontrada no site do OpenSIPS (versão 1.6.0) em OpenSIPS Resources DocsModules16.

Configuração OpenSIPS
A estrutura do arquivo de configuração é formada por arquivo texto padrão composto por 3 seções: 11 Configurações globais: configurações gerais do sistema, como o nível de depuração, controle sobre o log da aplicação, definição das interfaces de rede que serão utilizadas, entre outras. 11 Configurações dos módulos: carregamento dos módulos e configurações dos seus parâmetros. 11 Lógica de roteamento: script que define o modo de funcionamento do sistema. Toda lógica de roteamento é definida através de uma estrutura de configuração similar a uma linguagem de programação (declaração e chamada de funções, cláusulas condicionais if, else etc). A seguir serão apresentadas essas 3 seções e discutidas algumas das configurações mais importantes.

q

Configurações globais
Existem diversas configurações possíveis nesta seção. As mais utilizadas são: 11 debug : opções: número entre 0 e 9. Define o nível de depuração, ou seja, a quantidade de informações exibida nos logs; 11 fork : opções: 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: opções: YES ou NO. Indica se os erros devem ser enviados para a saída de erro padrão do sistema (stderr) ou para o syslog. É utilizada para depuração, pois facilita a verificação dos erros; 11 log_facility : parâmetro que indica o facility para o syslog (mecanismo de log do sistema operacional). É uma maneira de indicar a aplicação que gerou a mensagem de log;
Capítulo 4 - Introdução ao SIP

11 listen: formato: <protocolo>:<IP>:<porta>. Indica o endereço IP/porta utilizado para aguardar as requisições e o protocolo que será permitido neste IP/porta. Ex: listen=udp:143.54.12.10:5064; 11 alias: identificação do servidor local. A declaração de alias tem relação com a variável myself, que é utilizada no script para identificar se uma mensagem foi enviada para este servidor. Ex: alias=esr.rnp.br:5060.

107

Algumas opções da seção de configurações globais:

debug=9 fork=yes|no

# Nível de depuração # 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.br”5

# Log de erros na saída stderr ou syslog # Parâmetro para syslog # Nome deste servidor SIP

listen=192.168.1.100:5060 # Interface de rede para esperar requisições

A lista completa de parâmetros da versão 1.6.0 pode ser encontrada em OpenSIPS Resources DocsCoreFcn16. Para rodar a aplicação em modo depuração, marque a opção fork=no e inicie o OpenSIPS com o comando: /etc/init.d/opensips debug.

Configurações dos módulos
Esta seção define todos os módulos que serão carregados e define os parâmetros que serão passados para configurá-los. O carregamento dos módulos é feito de forma simples. A variável mpath indica o diretório onde estão os módulos, que são carregados usando o comando loadmodule, como no exemplo abaixo:

mpath=“/usr/lib/opensips/modules/” loadmodule “sl.so” loadmodule “tm.so” loadmodule “registrar.so”
A configuração dos parâmetros dos módulos é 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 três argumentos: o nome do módulo, o nome da variável e o valor a ser atribuído à variável, respectivamente.

Administração de Videoconferência

Lógica de roteamento
A lógica de roteamento define todo o tratamento que será feito com as requisições recebidas pelo OpenSIPS, seja qual for o tipo dessas requisições (INVITE, REGISTER, BYE, CANCEL etc). O funcionamento do OpenSIPS se assemelha ao de um script que é executado toda vez que uma requisição SIP é recebida. O ponto de partida do script é o bloco denominado route{}, que contém toda a lógica de roteamento (ou parte da lógica e chamadas para outros blocos, que contêm o restante da lógica). Sempre que uma requisição é recebida, tem início a execução sequencial dos comandos encontrados neste bloco. O processamento é contínuo até o ponto onde ocorre a decisão final sobre a requisição: até a requisição 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 requisições do tipo OPTIONS com uma mensagem 200/OK (definida no bloco if{}). Para as outras requisições, é feita uma chamada a um bloco secundário de roteamento route[1], que apenas encaminhará a requisição.

Modos de operação OpenSIPS
Um proxy SIP pode operar de dois modos: Modo Stateless Oferece melhor escalabilidade, pois não armazena informações de estado e requer menos recursos, principalmente memória. O módulo responsável pelo modo stateless é o SL. Toda função iniciada por “sl_” indica que a comunicação será feita sem manter informações de estado. Modo Stateful O módulo responsável pelo modo stateful é o TM. Toda função 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 requisições são tratadas.

q

O modo stateless oferece melhor escalabilidade, pois não precisa armazenar tantas informações de estado como no modo stateful, portanto, requer menos recursos (principalmente memória). O módulo responsável pelas funções stateless é o SL. Ele fornece todas as funções cação será feita sem manter informações de estado. O módulo responsável pelas funções stateful é o TM, que fornece as funções com prefixo “t_”. A escolha entre os estados stateless ou stateful é importante, pois muda a forma com que algumas requisições são tratadas.
Capítulo 4 - Introdução ao SIP

iniciadas por “sl_”, ou seja, o uso de qualquer função com prefixo “sl_” indica que a comuni-

109

A requisição CANCEL, por exemplo: 11 Em stateful, o script pode simplesmente chamar uma função do módulo TM (t_relay()) e ela saberá como tratar a mensagem, pois o servidor guardou as informações sobre a requisição inicial, o INVITE. 11 Em stateless, deve aplicar ao CANCEL toda a mesma lógica de roteamento aplicada para o INVITE, pois não manteve as informações.

q

Além disso, há algumas funcionalidades que necessitam do estado das transações para funcionarem, como o módulo de contabilização (módulo ACC). Associado aos módulos stateless e stateful, está o módulo RR (Record-route), que possibilita a gravação da rota pela qual as requisições passaram. Essa rota é guardada no cabeçalho das mensagens através de duas funções principais: 11 record_route( ): grava a rota nas requisições. 11 loose_route( ): “limpa” a rota nas respostas. As imagens abaixo exemplificam as chamadas record_route( ) para gravar a rota de uma requisição INVITE e as chamadas loose_route( ) para liberar as rotas quando feita a requisição BYE (que está relacionada ao INVITE inicial). Como a rota foi gravada durante a requisição INVITE, é garantido que a requisição BYE passará pelo servidor SIP que gravou seu endereço nesta rota.
record_route() INVITE INVITE record_route() INVITE

q

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 requisição 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 requisição BYE.

Administração de Videoconferência

Antes de utilizar o script opensipsdbctl, o arquivo opensipsctlrc deve ser editado para incluir as configurações de acesso ao banco de dados. Este arquivo está localizado em /etc/opensips/ e as variáveis mais importantes que devem ser configuradas são: DBENGINE, DBHOST, DBNAME, DBRWUSER e DBRWPW. Elas já possuem os valores padrão configurados, que serão os valores utilizados neste curso. A estrutura completa das tabelas necessárias para o funcionamento do OpenSIPS pode ser consultada no site do desenvolvedor.

110

Integração com banco de dados OpenSIPS
Indispensável para implantação de um servidor OpenSIPS. Vários módulos fazem uso de algum tipo de informação armazenada em banco de dados: 11 Registro de usuários (função registrar ). 11 Contabilização. 11 Localização de usuários. 11 Entre outros. Módulo é carregado e configurado no arquivo de configurações. Exemplo:

q

loadmodule “mysql.so” modparam(“auth_db|usrloc|acc”, “db_url”, “mysql://opensips:opensipsrw@localhost/opensips”)
A configuração das tabelas no banco de dados pode ser feita com o script opensipsdbctl:

$ opensipsdbctl create opensips
(cria o database opensips)

$ opensipsdbctl reinit opensips
(destrói e recria todo o database opensips) Algumas operações sobre o banco de dados também podem ser feitas com o script opensipsctl:

$ opensipsctl add <username> <password>
(cadastrar usuário)

$ opensipsctl rm <username>
(remover usuário)

$ opensipsctl passwd <username> <password>
(modificar a senha de um usuário cadastrado) O uso de um banco de dados é indispensável para implantação de um servidor OpenSIPS, mesmo que seja utilizado um banco mais simples, como em arquivos texto. Se nenhum banco de dados for utilizado, as informações de localização dos usuários registrados serão mantidas em memória, portanto em caso de falhas ou reinicialização do servidor, elas acabam sendo perdidas. Diversos módulos do OpenSIPS utilizam algum tipo de informação armazenada em banco de dados, como por exemplo os módulos de registro de usuários (servidor registrar ), contabilização de ligações e localização de usuários. O OpenSIPS fornece diversos módulos para integração com alguns bancos de dados, entre eles: 11 DB_MYSQL: MySQL 11 DB_POSTGRES: PostgreSQL 11 DB_TEXT: Dbtext Assim como os outros módulos comentados, os módulos de banco de dados são carregados e configurados na seção de módulos do arquivo de configurações. O exemplo abaixo mostra o carregamento do módulo para MySQL e da atribuição de dois parâmetros aos módulos:

q
Capítulo 4 - Introdução ao SIP

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 módulo enquanto as outras duas atribuem os parâmetros. O primeiro parâmetro é atribuído aos módulos AUTH_DB, USRLOC e ACC, enquanto o segundo parâmetro só é atribuído ao módulo USRLOC (pois só existe neste módulo). A configuração de db_url (que é comum aos módulos AUTH_DB, USRLOC, ACC e outros) diz respeito à localização e a informações de acesso ao banco de dados. O valor atribuído a esta opção segue, na maioria dos casos, o formato: “banco://usuário:senha@ip:porta/database”. No exemplo, está sendo indicado que será utilizado o usuário “opensips” com senha “opensipsrw” para se conectar ao database opensips do banco de dados MySQL localizado na máquina 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 configuração de db_mode é uma opção do módulo USRLOC e apenas diz respeito ao modo de acesso ao banco de dados: 11 0: desabilita o banco de dados. Todas as informações são mantidas em memória; 11 1: as informações chegam a ser armazenadas na memória, mas são gravadas imediatamente no banco de dados; 11 2: as informações são armazenadas primeiramente na memória e sincronizadas de tempos em tempos com o banco de dados; 11 3: nenhuma informação é mantida em memória. Todas as operações são realizadas diretamente com o banco de dados. Esta opção existe, pois muitas vezes o acesso ao banco de dados pode ser demorado, portanto esta configuração permite personalizar a forma de acesso ao banco conforme as necessidades de cada servidor. A configuração 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
Administração de Videoconferência

(destrói e recria todo o database opensips) Além disso, algumas operações sobre o banco de dados também podem ser feitas com o script opensipsctl, como o gerenciamento de usuários cadastrados:

$ opensipsctl add <username> <password>
(cadastrar usuário)

$ opensipsctl rm <username>
(remover usuário)

112

$ opensipsctl passwd <username> <password>
(modificar a senha de um usuário cadastrado)

Localização de usuários OpenSIPS
A partir do momento em que uma requisição de INVITE é recebida, o servidor SIP deve ser acionado para encaminhar a requisição ao seu destino, se o destino for de conhecimento do servidor. O módulo responsável pela função que permite localizar usuários é o USRLOC, através da função lookup(). Abaixo é exibido um pequeno script de roteamento do método INVITE. No algoritmo, em primeiro lugar é avaliado se o tipo da requisição é realmente um INVITE (method==“INVITE”). Caso positivo, em seguida é feita a busca pelo destino usando a função lookup(“location”). A função lookup() usa como parâmetro a tabela onde se encontram as informações de localização dos usuários registrados, geralmente chamada location. Se o registro de localização não for encontrado, uma mensagem é apresentada ao cliente que originou a chamada e o processo é finalizado. Mas se a informação do destino foi encontrada, a função t_relay() é invocada para que a requisição seja encaminhada para o destino. A partir daí o software cliente do destinatário receberá a requisição de convite para estabelecimento de chamada.

if (method==”INVITE”) { if (!lookup(”location”)) { # busca usuário na tabela “location”

sl_send_reply(“404”, “Not Found”); return; }; if (!t_relay()) { # só depois tenta encaminhar a requisição sl_reply_error(); }; exit; }

Plano de discagem OpenSIPS
Como é implementado um plano de discagem? Para a criação de um plano de discagem completo, equivalente ao visto no GnuGK, será preciso definir uma estrutura composta 11 OpenSIPS recebe um número para o qual um terminal está discando. 11 O formato do número é verificado. 11 O número é reescrito em formato padrão, para facilitar verificações: 22 Código do país + código de área + número do terminal. de if ’s e else ’s. Exemplo:

q
Capítulo 4 - Introdução ao SIP

# 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 endereço SIP inválido sl_send_reply(“403”, “Forbidden”); return; };
Para a criação de um plano de discagem completo, equivalente ao visto no GnuGK, é preciso definir uma estrutura composta de IFs e ELSEs no script de configuração do OpenSIPS. No exemplo abaixo, o servidor OpenSIPS recebe um número para o qual um terminal está discando, verifica o formato deste número (se é válido ou não) e o reescreve em um formato padrão que permite verificações posteriores (localizar usuário, por exemplo). O formato para o qual o número é reescrito é: Código do país + código de área + número 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
Administração de Videoconferência

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 endereço SIP inválido sl_send_reply(“403”, “Forbidden”); return; };
Os endereços ao lado dos comandos exemplificam endereços SIP tratados por cada um dos blocos if. O primeiro if nos indica que é uma chamada de longa distância. Nesse caso devemos remover o dígito 0 (zero), que faz parte do plano de discagem e inserir os dígitos 55. O segundo if nos aponta para uma chamada internacional. Nesse caso precisamos apenas remover os dígitos do plano de discagem para chamada internacional (00). Em último caso, a chamada será do tipo local (8 dígitos). Nesse caso precisamos apenas inserir o Código do país + Código de área específicos.

Sobre a sintaxe do script
A expressão “uri =~” indica que a variável “uri” será comparada com uma expressão regular. Expressões regulares utilizadas: 11 sip:0[1-9].*: endereço iniciado por “sip:0” seguido de pelo menos um dígito entre 1 e 9. O bloco “.*” indica que podem existir 0 ou mais dígitos na sequência; 11 sip:00[1-9].*: similar ao anterior, mas agora o endereço inicia por “sip:00”; 11 sip:[2-9][0-9]{7}@.* : endereço iniciado por “sip:”, seguido por um dígito entre 2 e 9. O bloco “[0-9]{7}” indica que a sequência é formada por exatamente 7 dígitos entre 0 e 9, formando portanto os 8 dígitos do endereço. Esses 8 dígitos são seguidos por uma arroba (@), que é seguida por 0 ou mais dígitos.

Autenticação de clientes OpenSIPS
A autenticação SIP é feita por requisições do tipo REGISTER. O servidor OpenSIPS trata estas requisições para liberar ou bloquear o acesso do terminal que fez a requisição. No OpenSIPS, a lógica de processamento do REGISTER envolve basicamente o uso das seguintes funções: 11 www_authorize(dominio, tabela) – do módulo AUTH_DB Valida as credenciais utilizadas para autenticação (usuário e senha enviados com o REGISTER) de acordo com a RFC 2617. Parâmetros: <domínio>: domínio do servidor SIP. <tabela>: tabela do banco de dados que contém as informações das credenciais. 11 ww_challenge(dominio, qop) – do módulo AUTH registro novamente. Parâmetros: <domínio>: domínio do servidor SIP. <qop>: parâmetro necessário para o mecanismo de desafio-resposta, com valor 0 ou 1. 11 db_check_to() – do módulo URI Valida o campo “To:” , que na requisição REGISTER contém o endereço do terminal que está sendo registrado. Função antes chamada de check_to() no módulo URI_DB. Caso a autorização falhe, esta chamada é feita para “desafiar” o terminal a tentar o

q

115

Capítulo 4 - Introdução ao SIP

11 save(tabela) – do módulo registrar Chamada após o registro ser feito com sucesso, salva a informação de registro na tabela “tabela”. Script de exemplo da autenticação de usuários:

if (!www_authorize(“esr.rnp.br“, “subscriber”)) { autorizado www_challenge(“esr.rnp.br”, “0”); exit; } # usuário foi autorizado if (!db_check_to()) { # campo To: inválido

# usuário não

sl_send_reply(“403”, “Forbidden auth ID”); exit; }

if (!save(“location”)) { registro sl_reply_error(); return; } exit;

# não conseguiu graver informações de

No script, o primeiro passo é uma tentativa de autenticação no domínio “esr.rnp.br”:

if (!www_authorize(“esr.rnp.br“, “subscriber”)) {
Em caso de falha, é feito o desafio para o usuário fornecer novas credenciais:

www_challenge(“esr.rnp.br”, “0”);
Caso a resposta para a autenticação seja positiva, é feita a validação do campo “To:” da mensagem, que no REGISTER contém o endereço do terminal que está solicitando o registro:

if (!db_check_to()) {
Administração de Videoconferência

Se o campo “To:” for inválido, é enviado um aviso ao usuário informando que o ID de autenticação é inválido:

sl_send_reply(“403”, “Forbidden auth ID”);
Se o campo “To:” for válido, o script prossegue para o próximo passo, que é a gravação do registro que foi feito:

if (!save(“location”)) {
Em caso de sucesso, o script finaliza e o registro está concluído. Em caso de falha, é enviado um aviso de erro ao usuário:

116

sl_reply_error();
Como já comentado, se houver integração com algum banco de dados o utilitário opensipsctl pode ser utilizado para: 11 Cadastrar usuários:

$ opensipsctl add <username> <password>
11 Remover usuários:

$ opensipsctl rm <username>
11 Modificar a senha de um usuário cadastrado:

$ opensipsctl passwd <username> <password>

Contabilização OpenSIPS
O registro das chamadas permite contabilizar a utilização do sistema. Contabilização utiliza o módulo ACC: 11 Pode registrar eventos no sistema (Syslog), bancos de dados e RADIUS. 11 Utilização do módulo é praticamente transparente no script: basta informar ao módulo que os dados devem ser registrados e ele se encarrega do resto.

q

# seta a flag que será usada para indicar ao ACC que deve iniciar contabilização 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 geração de registro das chamadas é indispensável para avaliar a utilização do sistema. No OpenSIPS, toda a contabilização é feita pelo módulo ACC. Este módulo permite o registro de eventos no sistema (syslog), bancos de dados e RADIUS. A utilização do módulo é praticamente transparente no script: basta informar ao módulo que os dados devem ser registrados e ele se encarrega do resto. O módulo permite contabilizar informações a qualquer momento e também permite a personalização das informações que
Capítulo 4 - Introdução ao SIP

serão gravadas. Mas há sempre um conjunto mínimo de informações que são contabilizadas: 11 Nome do método (INVITE, ACK, BYE, etc.). 11 Campos “To”, “From” e “Call-Id” do cabeçalho. 11 Código e mensagem da resposta gerada. 11 Informações de tempo de quando a transação foi finalizada.

117

Para realizar a contabilização, o script deve basicamente chamar a função setflag(ID) no momento adequado. O uso desta função 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 módulo do banco de dados MySQL e do módulo de contabilização ACC. 2. Definidos dois atributos no módulo ACC: 2.1. O primeiro para que ele utilize o banco de dados MySQL para armazenar as informações; 2.2. O segundo define que a flag de contabilização será a com valor “1”. Esta flag é utili-

zada posteriormente para habilitar a contabilização.
3. A chamada da função setflag(1) – 1 é a flag definida no ACC – habilita a contabilização da

requisição que está sendo tratada, no caso INVITE;
4. O mesmo que o item anterior, mas agora habilita a contabilização da requisição BYE.

Para uma contabilização completa, é aconselhável monitorar pelo menos as requisições INVITE, ACK e BYE. Esses três métodos consistem da estrutura de uma transação SIP: Início = INVITE, Estabelecimento = ACK e Fim = BYE.

Geração de logs OpenSIPS
O log de eventos é fundamental para o acompanhamento do funcionamento do sistema, diagnóstico e resolução de problemas. O módulo XLOG oferece recursos poderosos para implementar o registro de eventos.
Administração de Videoconferência

q

O registro de eventos é fundamental para o acompanhamento do funcionamento do sistema, diagnóstico e resolução de problemas. No OpenSIPS, o responsável pelas funções de log é o módulo XLOG. XLOG oferece recursos poderosos para implementar o registro de eventos, tendo como sua função principal:

q

xlog(<Nível>, <Mensagem Texto>)
11 Registra uma mensagem no sistema de log. 11 <nível> é opcional e indica a classe da mensagem: alerta, erro crítico etc.

118

Os valores são compatíveis 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 são armazenadas pelo sistema de log padrão syslog em /var/log/. Algumas configurações de log já foram mostradas, como as duas configurações globais abaixo:

log_stderror=no log_facility=LOG_LOCAL3

# Log de erros na saída stderr # Parâmetro para syslog

Outro recurso interessante do XLOG é a possibilidade de usar variáveis de ambiente (pseudo-variáveis) junto da mensagem de texto. Existem diversas pseudo-variáveis, 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 usuário da URI do campo From. 11 $rm – Método SIP. 11 $ru – URI. 11 $tu – URI do campo To. 11 $tU – Identificador de usuário da URI do campo To. 11 $tf – Hora/Dia. 11 $ua – Dados do cliente SIP(UA). Abaixo temos um script exemplificando o uso do módulo XLOG:

loadmodule “xlog.so” if (method==“INVITE”) { xlog(“L_ALERT”, “Chegou um método ($rm) para o usuário ($ru) \n”); return;
Capítulo 4 - Introdução ao SIP

} else if (method==“REGISTER”) { xlog(“L_ALERT”, “Chegou um REGISTER de $fU ($ru) em $tf\n”); return; }
A lista de pseudo-variáveis do OpenSIPS pode ser localizada em “OpenSIPS Resources”.

119

120

Administração de Videoconferência

Roteiro de Atividades 4
Atividade 1 – Ligação SIP através 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 usuário configure uma conta local (com informações básicas apenas, como seu nome) e um servidor SIP. Este servidor SIP será fornecido pelo instrutor. Configure o X-Lite e faça uma ligação para o colega de dupla. Para ligar basta utilizar o “Username” do colega, conforme configurado no X-Lite. Capture uma ligação completa entre seu terminal e o terminal do colega. Utilize um software de sniffer de redes, como Wireshark, e responda as questões a seguir:
1. Desenhe as mensagens SIP (protocolos e portas) trocadas entre as duas máquinas

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 relação às mensagens SIP obtidas na atividade durante a prática inter-

mediária (ponto-a-ponto sem servidor)?

3. Acesse o menu “Telephony -> VoIP Calls” e tente escutar a conversa.

Atividade 2 – Configuração e utilização 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 máquina virtual que será fornecida pelo instrutor. O OpenSIPS já está instalado nas máquinas virtuais. O arquivo de configurações padrão está em: /etc/opensips/opensips.cfg. As configurações do OpenSIPS na máquina virtual já permitem que ele seja utilizado, ou seja, nessa atividade não serão necessárias alterações nas configurações 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 aplicação. Os membros da dupla deverão realizar os seguintes passos (leia as “Dicas para uso do OpenSIPS”, logo a seguir, como apoio para a execução dos passos):
1. Iniciar/Parar a aplicação. 2. Verificar a localização do arquivo de configuração. 3. Monitorar a aplicação. 4. Configurar o OpenSIPS da dupla no X-Lite e efetuar ligações entre os terminais da dupla.
Capítulo 4 - Roteiro de Atividades

121

Dicas para uso do OpenSIPS
1. Verificar se o OpenSIPS está em execução:

ps -ef | grep opensips
2. Para iniciar/parar/reiniciar a aplicação:

/etc/init.d/opensips start /etc/init.d/opensips stop /etc/init.d/opensips restart
3. Arquivos de configuração padrão estão em:

/etc/opensips/opensips.cfg
4. Monitoramento do OpenSIPS:

opensipsctl monitor
Os arquivos do OpenSIPS encontram-se em: 11 Arquivo de configurações iniciais: /etc/default/opensips. 11 Arquivo de configurações gerais: /etc/opensips/opensips.cfg. 11 Arquivos binários em: /usr/sbin/. 11 Módulos em: /usr/lib/opensips/modules/.

Verifique na sua máquina virtual que a rede está configurada no modo Bridged e não no modo NAT utilizado por padrão. Reinicie sua máquina virtual ao modificar o modo.

Atividade 3 – Incluir validação de usuários no OpenSIPS
Na atividade anterior, o servidor OpenSIPS estava configurado de forma bastante básica e sem restrições de acesso: qualquer terminal poderia utilizar o servidor. Nesta atividade será incluída a validação básica de usuários através de nome de usuário e senha. Para o cadastro dos usuários é utilizado um banco de dados (MySQL) que já está instalado nas máquinas virtuais. A atividade será habilitar a validação de usuários, incluir os usuários no banco de dados e efetuar ligações utilizando clientes X-Lite devidamente registrados e autorizados no OpenSIPS. A autenticação já está preparada no OpenSIPS. Para habilitá-la, descomente as seguintes linhas no arquivo /etc/opensips/opensips.cfg :
Administração de Videoconferência

loadmodule “db_mysql.so” loadmodule “auth.so” loadmodule “auth_db.so“
Vá até a seção “auth_db params” e descomente as 4 chamadas “modparam entre as linhas 151 e 155”. Não se esqueça de descomentar também a quebra de linha do terceiro “auth_db params”.

122

No bloco de linhas 321 a 331, descomente os dois IF’s para que a validação seja feita nas mensagens de REGISTER.

Saiba mais

l

Habilitada a autenticação, reinicie o servidor:

/etc/init.d/opensips stop /etc/init.d/opensips start
Após habilitar a autenticação na aplicação, é necessário utilizar o banco de dados para cadastrar usuários. Faça o cadastro utilizando os comandos a seguir. Incluir e remover usuários 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ê também 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 contém os usuários registrados. A partir de agora, os clientes X-Lite deverão ser configurados com o “username” e senha conforme cadastrados no banco de dados, para que possam se autenticar no OpenSIPS. Faça esta configuração da mesma forma como configurou o OpenSIPS na primeira vez em que foi utilizado. Para que as novas configurações tenham efeito, pode ser necessário reiniciar o servidor OpenSips e os clientes. Teste a comunicação com dois usuários cadastrados. Funcionou?

Teste a comunicação com um cliente não cadastrado. Funcionou?

123

Capítulo 4 - Roteiro de Atividades

124

Administração de Videoconferência

5
Redes de computadores e videoconferência
objetivos
Familiarizar o aluno com princípios e conceitos associados à infraestrutura das redes de computadores e sua influência nas videoconferências.

conceitos

Unicast x multicast; Portas e protocolos usados em H.323 e SIP; Uso de firewalls; Videoconferência via NAT; Atrasos em transmissão multimídia; Uso de QoS em videoconferência.

Infraestrutura básica de redes
“Velocidade de acesso” refere-se à velocidade possível nos meios físicos onde será realizada a videoconferência. É importante obter um “mapa” dos pontos a serem conectados, pois isso definirá muita coisa em relação à ferramenta de videoconferência a ser utilizada. Abaixo são descritos alguns dos meios mais utilizados em diferentes cenários:

Rede local
11 Fibra ótica;
Capítulo 5 - Redes de computadores e videoconferência

11 Par trançado: 22 Gigabit Ethernet (1000 Mbits/s); 22 Fast Ethernet (100 Mbits/s).

Acesso doméstico
11 Linha telefônica 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 Satélite em várias velocidades.

125

Um ótimo exemplo de backbone é o da RNP, que conecta diversos locais do Brasil e possui conexões de diversas velocidades. Atualmente as conexões com maior largura de banda são conexões 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 tráfego de redes para videoconferência
11 Ponto-a-ponto 22 Unicast 11 Multiponto 22 Unicast 22 Multicast 22 Broadcast Em redes de computadores é importante distinguir conexões ponto-a-ponto de conexões que envolvem múltiplos pontos (multiponto).

q

Administração de Videoconferência

Ponto-a-ponto
Uma conexão ponto-a-ponto é executada através de procedimentos de chamada do terminal de origem para o terminal de destino por meio de um número IP (no caso de redes locais e Internet) ou de identificação do equipamento (como um número ISDN). Esta conexão pode ser realizada sem o auxílio de um elemento gerenciador, baseada apenas na conexão direta entre os computadores. Em videoconferências, este é o modelo mais simples de comunicação, onde dois pontos estão conectados e trocam dados multimídia diretamente. Em redes IP este tipo de comunicação é feita utilizando unicast, que trataremos na sequência. A exibição dos dados para

126

o usuário é simples neste caso, pois cada usuário recebe dados de apenas outro usuário, portanto vídeo, áudio e outros elementos podem ser exibidos sem dificuldade.

Conexão ponto-a-ponto

Figura 5.2 Conexão ponto-a-ponto.

Terminal (origem)

Terminal (destino)

Multiponto
Uma conexão multiponto viabiliza a comunicação simultânea entre vários participantes distribuídos (3 ou mais), independente de sua localização geográfica. Em videoconferências, normalmente os participantes estão conectados a uma unidade central que gerencia e processa o fluxo de mídias (áudio, vídeo e dados) gerado na videoconferência. O elemento centralizador em videoconferências é chamado MCU, a unidade de controle multiponto. Este componente cuida do processamento dos fluxos de áudio e vídeo de forma a integrar todos os terminais de videoconferência. Além do uso de um elemento centralizador, há também a opção de fazer múltiplas conexões ponto-a-ponto entre todos os participantes. A exibição dos dados multimídia em videoconferências com três ou mais participantes apresenta desafios maiores do que em videoconferências ponto-a-ponto. Normalmente são utilizadas duas formas de exibição: participante ativo ou presença contínua.

Conexão Multiponto

Gatekeeper

MCU

Figura 5.3 Conexão multiponto.

Terminal Terminal Terminal

Terminal

Participante ativo
Todos os terminais da videoconferência 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 videoconferência. O participante ativo é normalmente aquele que está falando no momento. A detecção do participante ativo costuma ser feita pela MCU com base no nível do sinal de áudio de cada participante. Essa modalidade também é conhecida como “modo comutado por voz” (Voice Switched Mode) e apresenta, em geral, uma boa qualidade de vídeo e áudio, além de permitir uma visualização completa do participante ativo. É indicada em casos sem muita alternância entre os participantes ativos, como em palestras e apresentações.

127

Capítulo 5 - Redes de computadores e videoconferência

Figura 5.4 Videoconferência exibindo apenas o participante ativo.

Presença contínua
Neste modo é apresentada a imagem e o áudio de todos os participantes ao mesmo tempo. Essa configuração é recomendada para situações em que exista uma participação ativa simultânea de vários usuários na videoconferência, como ocorre em reuniões, por exemplo. Com este formato de exibição perde-se um pouco na qualidade (imagens são exibidas em tamanhos menores), mas ganha-se em conteúdo, já que é possível ver todos os participantes e não apenas um. Aplicações que envolvem áudio e vídeo, como sistemas de videoconferência, geram um grande volume de dados na rede. O tráfego gerado em uma rede depende da natureza da aplicação (áudio, vídeo, imagens etc.) e do tipo de conexão entre as máquinas onde cada aplicação está sendo executada. O tipo de conexão avalia o estabelecimento da conexão sob a ótica da transferência de pacotes entre os terminais da rede: ponto-a-ponto ou multiponto. No caso de multiponto, ainda temos: conexão por difusão (broadcast), em que um pacote é endereçado a todos os demais terminais da rede; e conexão por difusão seletiva (multicast), em que um pacote é endereçado a um grupo pré-definido de terminais na rede. Para cada uma das formas de conexão, há um tipo de tráfego gerado na rede: unicast, broadcast e multicast.

Administração de Videoconferência

Click here to add another person to the conference

Figura 5.5 Videoconferência com presença contínua.

128

Tráfego unicast
O tráfego unicast é aquele gerado quando uma máquina envia pacotes para um único destino (ou host) na rede. Nesse caso, uma máquina servidora que atende a quatro clientes deve gerar quatro diferentes fluxos para cada terminal, como mostra a figura. Esta forma de tráfego permite fácil comunicação tanto do servidor para o cliente quanto do cliente para o servidor. Um exemplo prático de tráfego unicast é o acesso a uma página web através de um servidor HTTP. A cada acesso, é estabelecida uma conexão entre o servidor HTTP e o cliente que está fazendo o pedido. Um problema do unicast é a geração de tráfego excessivo na rede quando um número elevado de solicitações é enviado ao servidor, uma vez que para cada pedido será gerado um fluxo de retorno. Quando se trata da transmissão de vídeo, o problema é agravado, já que os fluxos gerados contêm grande volume de dados que são replicados para os respectivos clientes, o que compromete significativamente o desempenho da rede. Apesar deste problema, o unicast é a forma de transmissão mais utilizada atualmente, mesmo para áudio e vídeo. Um exemplo de uso desse modelo é o YouTube, além de outros sites de vídeo sob demanda.

Tráfego Unicast

4 3 Roteador 1
Figura 5.6 Transmissão via unicast.

Terminal 1 Rede

2 1

2

3

4

Terminal 2

Servidor

Terminal 4

Terminal 3

Tráfego broadcast
Com tráfego broadcast uma máquina gera conteúdo para todas as demais na rede, de forma (o endereço de broadcast) é utilizado, identificando que o pacote que contém a mensagem deve ser endereçado para todas as máquinas da rede. No exemplo da Figura 5.7, a distribuição de pacotes é feita a partir de uma estação terrestre (servidor) que envia os dados para o satélite 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 método muitas vezes é utilizado para videoconferências em zonas rurais ou em zonas com baixa infraestrutura de redes.
Capítulo 5 - Redes de computadores e videoconferência

que todas as máquinas receberão a mesma informação enviada. Um endereço específico

129

1 2 3

Terminal 1

4

Terminal 2

Servidor

Terminal 4

Terminal 3

Figura 5.7 Transmissão via broadcast.

Tráfego multicast
O tráfego multicast difere do broadcast porque, em vez de enviar pacotes para todos os nós da rede, envia pacotes apenas para um grupo pré-definido de máquinas. É utilizada uma forma de endereçamento especial para o envio dos pacotes, designando o endereço de um grupo de nós (conhecido como grupo multicast ) e não de todos os nós da rede. Sua principal vantagem é a economia de largura de banda, permitindo que um mesmo fluxo seja transmitido para vários nós. Ao contrário do unicast, não são necessários múltiplos fluxos para atender múltiplos clientes; apenas um fluxo é suficiente. Para tanto, são necessárias técnicas eficientes para o encaminhamento dos pacotes na rede, implementadas através de protocolos específicos para o roteamento desses pacotes. Este roteamento é feito pelos equipamentos intermediários da rede (switches e roteadores), que devem estar configurados para conhecer multicast e seus protocolos. O funcionamento do tráfego multicast pode ser comparado, por exemplo, com o de uma estação de rádio. Em uma estação de rádio, o sinal é transmitido em uma determinada frequência, independentemente do receptor. Cada ouvinte, na sua casa e a partir do seu aparelho de recepção, é encarregado de sintonizar o canal desejado. No tráfego multicast, os nós que recebem o fluxo são configurados para a recepção desse tráfego, podendo ser adicionados ou excluídos através do uso de um protocolo específico.

Terminal 1 Rede Roteador A (Querier)
Administração de Videoconferência

Terminal 2

Servidor

Terminal 4

Terminal 3

Figura 5.8 Transmissão via multicast.

Multiponto: unicast x multicast
Como já comentado, uma transmissão multiponto pode ser alcançada com qualquer uma das formas de transmissão comentadas: unicast, multicast ou broadcast. Broadcast é uma opção que raramente será utilizada em redes de computadores devido à sobrecarga que

130

inclui na rede, apesar de ser uma ótima escolha para satélite. Em redes de computadores, a escolha deve ser feita entre unicast ou multicast. A figura abaixo ilustra a principal diferença entre essas formas de transmissão: a carga que cada um implica na rede.
UNICAST FON MULTICAST FON

ROTA ROTB
Figura 5.9 Comparação de uma transmissão em múltiplos 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 é necessário um fluxo para cada receptor, ele obviamente gera mais tráfego na rede do que o multicast, que é uma forma de transmissão muito mais eficiente nesses casos, especialmente para transmissão de dados multimídia. Apesar disso, o unicast ainda é a forma de transmissão mais utilizada. O principal motivo disso é a falta de suporte ao multicast nos roteadores. Por apresentar uma complexidade adicional em relação ao unicast e por não ser tão utilizado, muitas vezes o multicast é negligenciado pelos administradores de redes na configuração de roteadores e switches. Com isso, o uso do multicast acaba sendo possível apenas dentro de instituições onde está devidamente configurado, como é o caso da rede da RNP. Além disso, em alguns casos o multicast não é a forma mais adequada de transmissão, como em sistemas de vídeo sob demanda, por exemplo. Nestes sistemas, os usuários podem fazer a requisição de início de transmissão no momento em que desejarem, e desejam ver o vídeo desde o seu início. Da mesma forma, os usuários têm a possibilidade de navegar para partes específicas do vídeo, sem que as mudanças feitas por um usuário interfiram nos outros usuários. Este é, portanto, um cenário para uso de múltiplas conexões unicast. Em transmissões multicast, todos os usuários receberão os mesmos dados, ou seja, receberão o vídeo no mesmo instante. Se um usuário solicitar o recebimento de um vídeo algum tempo após o início da transmissão, ele não poderá ver o vídeo desde seu início. Este é o caso de transmissões ao vivo, streamings e também de videoconferências. No intuito de facilitar o estudo e a utilização do espaço de endereçamento, a IANA definiu uma divisão lógica que designa cinco classes para o endereçamento da rede IP Internet versão 4. Essa divisão é chamada de Classfull Addressing (endereçamento de classes) e define as seguintes classes de endereços: A, B, C, D e E – conforme ilustrado na figura.
Capítulo 5 - Redes de computadores e videoconferência

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 endereçamento 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 recomendação da RFC 2365 sugere a utilização dos endereços 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 Criação e saída 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 não tiver multicast? 11 Mbone (multicast backbone): criação de túneis multicast sobre unicast. 11 Permite multicast ao longo de uma rede que não suporta multicast. 11 Túnel liga dois roteadores que suportam IP multicast através de um enlace ponto-a-ponto unicast. Em uma transmissão multicast, um dos principais aspectos que devem ser considerados é a forma como os pacotes enviados chegarão aos receptores interessados (e somente a eles). No exemplo abaixo, como os pacotes enviados pelo transmissor (no topo) chegam
Administração de Videoconferência

q

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 responsáveis por esta tarefa são 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 criação e saída de grupos (mensagens de join e leave). Ele é definido na RFC1112. Os protocolos de roteamento multicast definem como é feita a comunicação entre os roteadores para construção 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 distância, verifique se todos os roteadores do caminho suportam multicast. O multicast muitas vezes está disponível apenas em redes corporativas, o que impossibilita seu uso para comunicação entre diferentes empresas, por exemplo, assim como não é suportado na Internet. Uma alternativa para aproveitar as vantagens do multicast e contornar os problemas que ele apresenta é o uso de túneis multicast. exemplo prático da aplicação dos túneis é 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 várias ilhas com capacidade de multicast, interligadas por conexões 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 são encapsulados em pacotes unicast normais e enviados com destino a outro mrouter. Todos os roteadores no caminho aceitarão o pacote como um pacote unicast comum. Ao chegar ao mrouter-destino, o cabeçalho unicast é removido, restando assim o pacote multicast original. Esta técnica é chamada de “tunelamento”.
Capítulo 5 - Redes de computadores e videoconferência

Os túneis são utilizados para conectar duas redes multicast através de um canal unicast. Um

133

A imagem abaixo exemplifica a conexão entre duas ilhas utilizando mrouters.

Transmissor de G1 G1 192.168.2.2 Hub/ switch Mrouter1. Túnel com 192.168.4.2 G1 192.168.4.2 Hub/ switch Mrouter2. Túnel com 192.168.2.2 G1 G1
Figura 5.12 Utilização de túneis multicast.

Portas e protocolos dos padrões H.323 e SIP
Para administração de videoconferências, é muito importante ter conhecimento das portas e protocolos utilizados para monitoramento das atividades, configuração de equipamentos e, principalmente, importantes para configuração em redes protegidas por firewalls. A figura a seguir mostra um resumo das portas utilizadas em videoconferências H.323: Porta 80 1503 1718 1719 1720 1731 1024-65535 1024-65535 1024-65535
Administração de Videoconferência

Requerido Opcional Opcional Requerido Requerido Requerido Requerido Requerido Requerido Requerido Requerido

Protocolo TCP estático TCP estático UDP estático UDP estático TCP estático TCP estático TCP dinâmico UDP dinâmico UDP dinâmico UDP dinâmico

Descrição Interface HTTP T.120 Descoberta de gatekeeper Gatekeeper RAS H.323 Call Setup Audio Call Control H.245 RTP (vídeo) 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 estáticos indicam que somente a respectiva porta é utilizada, enquanto os itens dinâmicos indicam que há um intervalo possível de portas e que a porta que será utilizada é escolhida durante a comunicação. Já as três últimas colunas indicam em quais entidades as portas são utilizadas, ou seja, quais entidades precisam ter acesso a essas portas. Em relação ao protocolo H.245, é importante observar a possibilidade de utilizar o chamado H.245 tunneling, onde as mensagens H.245 são encapsuladas em mensagens H.225, utilizando assim a mesma porta usada pelo H.225. Ou seja, não é necessária uma conexão

134

específica para o H.245, pois as mensagens utilizarão a mesma conexão do H.225. Também é importante citar que outras portas podem ser necessárias dependendo da aplicação ou do fabricante dos equipamentos que estão sendo utilizados. Em relação ao H.323, o SIP oferece maior facilidade em relação à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 estático TCP estático UDP Dinâmico UDP Dinâmico UDP Dinâmico

Descrição Sinalização SIP Se TLS (HTTPS) for virtualizado RTP (Vídeo) RTP (Áudio) RTCP

1024-65535 1024-65535

Como pode ser visto, é utilizada basicamente a porta 5060 para toda a comunicação, enquanto os dados são enviados por RTP em portas UDP dinâmicas, assim como no H.323.

Uso de firewalls em videoconferência
Soluções para os problemas de videoconferência com firewalls: 11 A mais simples: abrir a(s) porta(s) requerida(s) para todo o tráfego de rede. 11 A mais elegante: existem tecnologias de firewall implementadas em roteadores que entendem o tráfego de rede SIP e H.323. Essas soluções podem detectar as solicitações de sinalização de videoconferência e executar a ação apropriada para permitir ao tráfego atravessar o roteador ou o firewall. Exemplos de implementações: 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.

q

Para entender as implicações do uso de firewalls em videoconferência H.323, é importante saber como funcionam os diferentes tipos de firewalls.
Capítulo 5 - Redes de computadores e videoconferência

Firewall do tipo Packet Filter (nível IP)
Bloqueiam ou permitem conexões com base apenas no protocolo utilizado e nas informações de endereçamento contidas nos pacotes, mais especificamente IP e porta. Não analisa a aplicação que está utilizando os dados, apenas verifica os cabeçalhos dos pacotes. Utiliza regras estabelecidas pelo administrador e necessita que sejam abertas todas as portas UDP e TCP utilizadas. Como existem portas dinâmicas (principalmente para dados por RTP), deveriam ser liberadas todas as portas que possivelmente são 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 proteção que o firewall implementado deveria fornecer.

Firewall do tipo Circuit gateway (nível de transporte)
Este tipo de firewall procura validar a conexão e não apenas os pacotes que circulam por ele, ou seja, o firewall verifica se a conexão entre os dois fins é válida e só então permite que

135

informações sejam trocadas entre eles. A definição das conexões válidas é feita com base em regras criadas pelo administrador, que podem considerar aspectos como protocolo, endereços IP, usuário e senha, entre outros. Além disso, as sessões costumam ter um tempo de duração, que após expirado faz com que o tráfego seja bloqueado. Firewalls utilizando esse método entendem protocolos de aplicação comuns, como Telnet e FTP.

Firewall do tipo Application gateway (nível de aplicação)
Consegue controlar a comunicação entre dois nós no nível do protocolo de aplicação. Atua como um proxy, fazendo toda a troca de informações entre os dois fins. Possui regras muito mais específicas e poderosas para permitir ou bloquear tráfego. Além das regras básicas existentes nos outros tipos de firewall, permite, por exemplo, limitar o acesso a arquivos apenas de tipos determinados, personalizar regras de acordo com o usuário autenticado, permitir que comandos sejam executados apenas por determinados usuários, entre outros. É o tipo de firewall mais sofisticado, porém isto os torna complexos, requerendo configurações detalhadas das aplicações que utilizam o firewall. Mesmo que o firewall ou o NAT sejam configurados corretamente para passar todo o tráfego de vídeo desejado, ainda pode haver interferência na videoconferência. Isto ocorre porque o firewall / NAT são basicamente computadores, e possuem um limite quanto à capacidade de tráfego que podem processar. Se não são rápidos o bastante para lidar com o tráfego apresentado a eles, pacotes poderão ser descartados e uma variação do atraso poderá ser introduzida nos pacotes que passarem por ele. Portanto, certifique-se de que o dispositivo firewall ou NAT é rápido o bastante para fazer o seu trabalho. As soluções para os problemas de videoconferência com firewalls estão relacionadas ao tipo do firewall utilizado. Em todos os casos, a maneira mais simples é liberar o acesso em todas as portas requeridas para a videoconferência. Esta é obviamente uma solução não muito segura, pois libera qualquer tipo de tráfego para as portas abertas. A solução mais elegante é a utilização de um firewall mais inteligente, que trabalhe como um Application Gateway, interpretando o tráfego de rede SIP e H.323. Essas soluções podem detectar as solicitações de sinalização de videoconferência e executar a ação apropriada para permitir ao tráfego atravessar o roteador ou o firewall. Alguns exemplos de dispositivos que funcionam desta maneira são: 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.

Videoconferência via NAT
Administração de Videoconferência

11 Network Address Translation (NAT) permite que vários computadores compartilhem uma única conexão de IP, ou pode mapear “IP + porta” privada para “IP + porta” externa e, então, suportar múltiplos endereços de IP privados.

q

NAT é um serviço que existe com intuito de permitir que vários computadores compartilhem uma única conexão 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, então, suportar múltiplos endereços de IP privados.

136

A figura seguinte exemplifica uma conexão 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á acessível com um IP público na internet.

Domínio de endereço privado Site NAT 10.0.0.1 Origem: 10.0.0.1/2000 Destino: 192.9.200.1/80

Internet pública

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 Conexões através 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 direções: de A para B e de B para A. A para B A máquina A envia um pacote contendo o endereço de IP de origem 10.0.0.1 e porta de origem 2000, que formam o endereço 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 endereço público das máquinas da rede interna. No host B, sabe-se apenas que foi recebido um pacote da máquina 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, através de suas tabelas internas, que este endereço 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 implementação da NAT.
Capítulo 5 - Redes de computadores e videoconferência

11 Dificuldade 1: ligações iniciadas a partir de terminais externos para um terminal que está atrás de um NAT. 11 Dificuldade 2: o NAT trabalha normalmente com o cabeçalho, 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 à máquina 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 à máquina 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.

q

137

Abaixo são descritos quatro tipos de NAT existentes: Full Cone, Restricted Cone, Port Restricted Cone e Symmetric.

Full Cone
Neste modelo, após NAT conhecer o endereço IP de um host interno, qualquer host externo consegue alcançar este host interno utilizando qualquer porta. Na imagem, quando o endereço interno S:Port1 (no formato <endereço IP>:<porta>) é mapeado para o endereço externo Sext:Port1ext assim que S envia um pacote para D, qualquer host externo pode enviar pacotes para Sext:Port1ext que elas chegarão até o endereço interno S:Port1 (tanto D quanto H podem mandar pacotes).

Porta 1 Porta 2 S Porta 1 Porta 2 Porta 1 Porta 2 N

D

H

Figura 5.16 NAT do tipo Full Cone.

Restricted Cone
Funciona de maneira similar ao modelo Full Cone, mas com a restrição 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

D

H

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 endereço S:Port1 para contatar D:Port1, D só poderá enviar pacotes para S utilizando D:Port1 como origem e S:Port1 como destino.
Administração de Videoconferência

Porta 1 Porta 2 S Porta 1 Porta 2 X X Porta 1 Porta 2 N

D

H

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 diferença é 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), serão criados dois itens na tabela, um para cada conexão (nos outros modelos seria utilizado apenas um item). Isso tem implicação direta no uso de sistemas criados para “atravessar” as NATs, como o STUN, que será comentado na sequência.

Porta 1 Porta 2 S Porta 1 Porta 2 X X Porta 1
Figura 5.19 NAT do tipo Port Restricted Cone.

D

Porta 2 N

H

Problemas gerados pelas NATs em videoconferências
Um dos problemas do uso de NATs é o tratamento de conexões iniciadas por um host que está fora da NAT. Utilizando como exemplo a imagem do início deste capítulo, onde temos o host A em uma rede privada com NAT e o host B conectado diretamente à rede pública, o problema acontece quando a conexão inicial parte do host B. O host B tentará contatar o host A utilizando o IP 139.130.1.1. Através deste IP os pacotes chegarão até o roteador com a NAT, porém ele não saberá para qual host da rede interna estes pacotes devem ser redirecionados. Se a conexão parte do host A, entretanto, não há problemas, pois a NAT cria sua tabela e consegue tratar todos os pacotes posteriores.

Domínio de endereço privado Site NAT 10.0.0.1 Origem: 10.0.0.1/2000 Destino: 192.9.200.1/80

Internet pública

Origem: 139.130.1.1/3000 Destino: 192.9.200.1/80

192.9.200.1
Capítulo 5 - Redes de computadores e videoconferência

NAT Binding 10.0.0.1/2000 139.130.1.1/3000
Figura 5.20 Pacotes através 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 situação se os dois hosts estão atrás de uma NAT? Neste caso nenhum dos dois pode iniciar a comunicação. As soluções serão tratadas na sequência deste capítulo. Outro problema no uso de NATs é que elas estabelecem o mapeamento de portas examinando o cabeçalho dos pacotes que são transmitidos. Isso funciona bem para a maioria das aplicações, porém apresenta problemas com protocolos que utilizam portas dinâmicas e/ou incluem a informação da porta utilizada na área de dados do pacote (payload). E este é justamente o caso dos padrões de videoconferência H.323 e SIP, onde as conexões RTP utilizam portas dinâmicas, que são definidas pelos protocolos durante o estabelecimento da sessão, onde são trocadas mensagens que contém o valor da porta na área de dados da mensagem.

139

O exemplo abaixo mostra uma mensagem INVITE do SIP, que contém 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 cabeçalho, 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

Soluções
Alternativas para a solução do problema: 11 Protocolo H.460 22 Criado para firewall / NAT traversal com o padrão 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 público. 22 Não pode ser utilizado com NAT simétrica. 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 estão descritas as principais formas para permitir que videoconferências atravessem firewalls e NATs: H.460, STUN, TURN e ICE.

q

Protocolo H.460
O H.460 é uma série de extensões ao padrão H.323 estabelecida pela ITU para possibilitar que videoconferências H.323 “atravessem” firewalls e NATs. A implementação do H.460 inclui um servidor localizado na rede pública (fora da NAT/firewall) que age como um proxy para todo o tráfego da videoconferência. Os terminais se registram neste servidor e abrem
Administração de Videoconferência

canais de comunicação direta com o servidor. Ou seja, os terminais não se comunicam diretamente, mas através do servidor H.460. A grande vantagem desta abordagem é que não é necessário criar regras especiais nos firewalls e também não é necessário que o firewall entenda o protocolo H.323. Basta configurar o firewall para que ele permita a comunicação com o servidor H.460 (um servidor confiável). Este método é simples de ser implementado e utilizado, o que o torna bastante prático para ambientes com poucos terminais e videoconferências rápidas. Ele se torna uma solução problemática especialmente quando existe um grande número de terminais fazendo ligações ao mesmo tempo (a largura de banda do servidor pode não ser suficiente).

140

No site “No Jitter”, assista ao “Video Tunnels Through the Firewall”.

v

STUN
Session Traversal Utilities for NAT (STUN) é um mecanismo definido na RFC 5389 que permite que entidades atrás de NATs descubram seus endereços públicos e com isso viabiliza videoconferências entre elas. Seu funcionamento é baseado em um modelo cliente-servidor, onde o cliente (um terminal de videoconferência) troca mensagens com um servidor (localizado na rede pública) para descobrir informações como: 11 Seu IP público; 11 O tipo de NAT na qual o cliente se encontra; 11 O mapeamento que o NAT está utilizando para este cliente. Além disso, o protocolo também possibilita outras facilidades, como manter o mapeamento do NAT sempre ativo, para que não ocorram falhas na comunicação. O STUN foi inicialmente definido na RFC 3489, e costuma ser chamado de “classic STUN”. Esta versão do protocolo provê todas as funcionalidades mencionadas, e pode ser utilizado de forma independente de outros protocolos. Porém, foi descoberto que esta versão do protocolo não é adequada em muitos casos, pois há casos em que a solução funciona e há casos em que não funciona. E nos casos em que não funciona não há nada que possa ser feito. Em função 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 solução de NAT traversal completa (como o ICE, que será descrito na sequência). O principal problema do STUN é que não funciona com NAT simétrica, que é um tipo de NAT muito utilizado. O problema é que a associação feita no NAT entre um terminal e o servidor STUN não pode ser utilizada para conexão entre este terminal e outro, ou seja, não pode ser utilizada para a videoconferência. Isso ocorre porque o NAT simétrico cria diferentes associações para cada conexão, mesmo para duas conexões feitas com um só terminal (que está atrás da NAT). Por exemplo, as soluções que utilizam um servidor externo apenas para tarefas como descoberta do IP público (ex. STUN): dessa forma, o terminal 1 descobre o IP externo e interno do terminal 2 e os utiliza adequadamente.

Servidor da rede pública NAT / Firewall NAT / Firewall
Capítulo 5 - Redes de computadores e videoconferência

Rede interna

Rede interna

Dados multimídia
Figura 5.21 Solução com servidor externo.

141

TURN
Traversal Using Relays around NAT (TURN) é uma extensão do protocolo STUN, incluindo as mensagens TURN, que são 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 pública para permitir que os clientes façam conexões através de NATs. O TURN permite que um host atrás de um NAT (o cliente) solicite que outro host (o servidor) funcione como um servidor de relay, de redirecionamento de mensagens. O cliente pode então 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 também necessita que o servidor tenha uma grande largura de banda disponível.

ICE
Interactive Connectivity Establishment (ICE) é especificado na RFC 5245 e define uma técnica de NAT traversal para transmissões UDP estabelecidas em um modelo de oferta e resposta. O modelo oferta e resposta é feito basicamente com o uso do protocolo SDP, onde são inseridos diversos IPs e portas, que são encaminhados para um cliente testar se é possível estabelecer uma conexão com eles. Esses IPs são definidos com uso do STUN. Além disso, o ICE também utiliza o TURN quando necessário. Simplificadamente, o ICE é uma solução completa de NAT traversal que utiliza o STUN sempre que possível e o TURN quando necessário (quando não é possível estabelecer uma conexão direta entre os dois hosts e então é necessário um servidor de relay ). O ICE ainda não está maduro, e não é adotado largamente na indústria, criando um problema no seu uso.

Suporte a NAT nos softwares de videoconferência
Os fabricantes de softwares de videoconferência têm se preocupado com os problemas causados pelas NATs e melhorias estão sendo implementadas nos clientes para resolver estas dificuldades. No PVX, por exemplo, as configurações de NAT podem ser feitas através dos menus “Rede -> Conexão” na janela de configurações da aplicação. O PVX oferece um método de descoberta automática do IP público de uma máquina que está atrás de uma NAT. Se este método falhar, ele também permite que o usuário especifique manualmente o endereço. A tela de configurações de rede do PVX, com a descoberta de NAT habilitada pode ser vista na imagem abaixo:

142

Administração de Videoconferência

Figura 5.22 Interface de confi guração PVX.

Conceitos de transmissão multimídia
11 Latência 11 Jitter 11 Skew 11 Largura da banda 11 Atraso Para entender a qualidade de uma videoconferência, é necessário analisar alguns fatores que influenciam na sincronização e apresentação das mídias. As principais medidas são: latência, jitter, skew e largura de banda. Além destas medidas, é importante ter conhecimento dos diversos fatores que causam atraso na transmissão.

q

Latência
A latência é o tempo entre o início de um evento e o momento que ele se torna perceptível no destino. 11 Quais fatores influenciam na latência? 11 Qual é o grande incômodo da latência? 11 Quais são os valores de latência aceitáveis em videoconferências?

q
Capítulo 5 - Redes de computadores e videoconferência

Latências muito grandes podem dificultar a conversação através da rede, comprometendo o diálogo e a interatividade necessária para aplicações como sistemas de videoconferência. Supondo uma situação em que duas pessoas estão conversando por meio de um sistema de videoconferência do tipo desktop, com grande atraso na transmissão dos pacotes. O interlocutor-origem envia uma pergunta para o interlocutor-destino. A grande latência da rede faz com que o interlocutor-destino custe a receber os pacotes que contêm esta mensagem. Enquanto isso, o “interlocutor A”, por não saber se o outro participante ouviu, continua enviando mensagens. Após alguns milissegundos, vem a resposta do interlocutor-destino sobre a primeira pergunta efetuada, entrelaçando o diálogo e dificultando a fluência da conversa.

143

Os principais fatores responsáveis por aumentar a latência nas redes de computadores são o atraso de transmissão, de codificação e de empacotamento. Estes e outros atrasos serão descritos mais adiante neste capítulo. Em aplicações convencionais – como correio eletrônico, por exemplo – a latência na transmissão passa despercebida pelos usuários do serviço. Já em aplicações multimídia – como sistemas de videoconferência – a latência pode ser percebida e até mesmo comprometer todo o serviço. Nesse caso, os pacotes devem ser entregues num período de tempo específico, para dar prosseguimento à apresentação da mídia. Sendo assim, dizemos que os requisitos de qualidade de serviço em aplicações multimídia são diferentes daqueles em aplicações tradicionais. Apesar de não ser uma técnica muito precisa, o atraso pode ser medido filmando um relógio em uma videoconferência e ver quanto tempo ele demora a chegar ao destino. A imagem seguinte exemplifica como isso é feito.

Figura 5.23 Medição de atraso em uma transmissão: 410 ms.

Nesta máquina está sendo filmado um relógio, em imagem transmitida para um sistema central (similar a um MCU), e este sistema está enviando a imagem de volta para a máquina, que a exibe na janela. Comparando os relógios temos: 11 Relógio no transmissor: 43:44,64. 11 Relógio no receptor: 43:44,23.00000. Com isso, percebemos que a diferença entre os relógios é de 410 ms, ou seja, a latência desta transmissão é 410 ms no momento em que foi tirada a foto. E quais seriam os valores de latência aceitáveis em videoconferências? Pesquisas mostram que atrasos abaixo de 100 ms são imperceptíveis para o ser humano. Entre 100 ms e 200 ms são valores pouco perceptíveis e toleráveis, e acima disso o atraso começa a perturbar a comunicação.
Administração de Videoconferência

Jitter
Jitter é a variação da latência. No exemplo uma rajada de pacotes: nem todos chegam ao mesmo tempo (com mesma latência).

q

144

# de pacotes recebidos Latência

Jitter
Figura 5.24 Gráfico de visualização do jitter.

t
Utilizar somente a latência não é suficiente para definir a qualidade de transmissão, pois as redes não conseguem garantir uma entrega constante de pacotes ao destino (com mesma latência). Dessa forma, os pacotes são entregues de forma variável, isto é, variando o tempo gasto de um pacote para outro. Essa flutuação na latência é conhecida como jitter e pode acarretar na descontinuidade na exibição da mídia. A principal estratégia para compensar o jitter é utilizar buffers para armazenar os pacotes que chegam e, então, minimizar esse efeito. O buffer – cujo tamanho vai depender do jitter – gera mais atraso na conversação, porém inibe a descontinuidade na exibição da mídia, 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 importância de latência e jitter baixos em determinadas aplicações sensíveis a esses fatores, como a videoconferência. Alguns exemplos práticos produzidos pelo jitter elevado são aquelas quebras durante a produção do áudio no cliente: podem ocorrer estouros (pops) ou sons rápidos demais (clicks) durante a reprodução do áudio.

Skew
Skew é a diferença do tempo de chegada entre diferentes mídias que deveriam estar sincronizadas. Exemplo: áudio e vídeo. 11 Qual o skew aceitável em uma videoconferência? 11 Quando o skew é muito grande, é necessário algum mecanismo para sincronização das mídias. Mecanismo utilizado: 11 Transmissor inclui o timestamp nos dados de áudio e vídeo. 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
Capítulo 5 - Redes de computadores e videoconferência

145

# de pacotes recebidos

skew

vídeo

Áudio

t
Qual seria o skew aceitável em uma videoconferência? 11 < 20 ms: imperceptível; 11 ~ 50 ms: percebe-se que há algo errado, mas não é possível saber qual mídia está adiantada e qual está atrasada; 11 > 50 ms: causa distração da videoconferência; 11 ~ 1 segundo: usuário mantém seu foco apenas no áudio, deixando de prestar atenção no vídeo. Como vimos, apenas valores muito pequenos de skew podem ser ignorados (menos que 50 ms). Para valores maiores, é necessário que haja algum mecanismo que sincronize as mídias antes de sua exibição. O mecanismo utilizado baseia-se em timestamps, que são 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 específicos nos pacotes para inclusão dessas informações. Como funciona: 11 Transmissor inclui o timestamp nos dados de áudio e vídeo: todos os pacotes levam essa informação de tempo. 11 Timestamp indica o momento no qual os dados foram capturados no transmissor: um buffer de áudio e um de vídeo 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 vídeo para que possa ser exibido. A figura a seguir mostra um exemplo de adaptação na rede, provavelmente através de mudança
Administração de Videoconferência

Figura 5.25 Gráfico de visualização 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 tação à qualidade da transmissão.

Perdas=10%

SEQ=8 SEQ=10 Perdas=10% SEQ=9 RTCP monitora o QoS da sessão, e não 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 informação de timestamp no pacote, como ilustra a figura a seguir. Veja que os pacotes estão chegando distanciados aleatoriaSEQ=2, tstamp=x+eq 20ms mente, porém, o receptor sabe exatamente o momento de enviar os mesmos à saída. 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 cabeçalho do RTP. O campo PT (Payload Type) indica o tipo de codec utilizado. O campo “Número de sequência” é utilizado para o RTCP verificar a taxa de perdas, pois os pacotes são numerados. O campo “timestamp” marca o momento da captura do primeiro byte do pacote.

147

Capítulo 5 - Redes de computadores e videoconferência

Figura 5.27 Uso do timestamp no RTP e tempo de chegada dos pacotes para adaptação 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

Número de seqüência

Synchronization Source (SSRC) identi fier Contributing Source ( CSRC ) identi fiers

Largura de banda
A largura de banda é um fator limitante para videoconferências, especialmente devido ao vídeo, que é uma mídia que consome bastante banda. A banda pode ser um limitador da qualidade do vídeo. Por exemplo, tendo apenas 512 kbps disponíveis, o vídeo deve ser comprimido o suficiente para que possa ser transmitido, ou pode-se definir a banda necessária conforme a qualidade desejada. 11 Por exemplo: deseja-se uma transmissão com resolução 720x480, 30 quadros por segundo, com alta qualidade: é necessária banda de 2 Mbps. As necessidades variam muito: 11 100 kbps em videoconferências simples via webcam. 11 1,5 Gbps em transmissões de vídeo HD não comprimido. Aplicações de videoconferência são muito parecidas com aplicações de voz em termos de latência e jitter — entretanto, podem utilizar alta largura de banda. Para determinar a largura de banda ideal para um sistema de videoconferência, é necessário conhecer a demanda requerida pelo sistema em função da capacidade que a infraestrutura de rede pode prover. Os requisitos de largura de banda de sistemas multimídia podem variar bas-

q

Figura 5.28 Cabeçalho do RTP.

tante, indo de 100 kbps a 1,5 Gbps (transmissão de vídeo HD não comprimido), por exemplo. A largura de banda é um fator limitante para a videoconferência, sendo necessário ajustar a demanda da aplicação à disponibilidade existente. Por exemplo: pode-se optar por vídeo de qualidade mais baixa em favor de manter os requisitos de transmissão multimídia ou, então, considerar modificações na infraestrutura da rede em prol de atingir a demanda requerida por um vídeo de maior qualidade.

Valores de referência
Resumindo o que foi visto, temos como valores de referência para cada uma das medidas descritas: Latência 11 Idealmente abaixo de 200 ms.
Administração de Videoconferência

Jitter 11 O mais baixo possível; 11 Aplicação deve utilizar buffer de dados para se adaptar ao jitter e evitar problemas na exibição dos dados; 11 Quando maior o jitter, maior o buffer, ou seja, maior a latência na exibição. Skew 11 Abaixo de 50 ms; 11 Para valores maiores necessita de sistema de sincronismo no receptor.

148

Largura de banda 11 Mínimo de 256 kbit/s para obter uma qualidade aceitável em baixas resoluções; 11 Boa qualidade em SD: 2 Mbit/s; 11 Qualidade média em HD: 4 Mbit/s.

Atraso na transmissão
O atraso total em uma transmissão é o tempo entre a captura dos dados no transmissor e sua exibição no receptor. Esse tempo envolve uma série de fatores como, por exemplo: atraso no meio físico, atraso de processamento nos dispositivos intermediários (como roteadores e switches), ou atraso devido ao tempo de espera nas filas de transmissão desses dispositivos. Na sequência serão descritos os diversos fatores que podem causar atrasos, que são: 11 Time-sharing de processos na máquina; 11 Captura de áudio e vídeo; 11 Codificação de áudio e vídeo; 11 Empacotamento; 11 Transmissão física; 11 Equipamentos intermediários (store and forward ); 11 Inserção e desinserção; 11 Fila dos roteadores; 11 Adaptação ao jitter, skew e pacotes fora de ordem.

Atraso de Time-sharing de processos na máquina
Em uma máquina com processamento fraco ou com muita demanda de processamento dos processos em paralelo podem existir falhas na: 11 Codificação de vídeo. 11 Exibição dos dados (áudio/vídeo). 11 Captura dos dados (áudio/vídeo). Um processador onde o processamento está muito intenso (90% a 100%) na grande maioria das vezes gera algum desses problemas na videoconferência. Muitas vezes é melhor ter um vídeo com menos qualidade, porém sem perdas, do que um vídeo com altíssima qualidade, como full HD, mas com perdas. Para que uma máquina execute diversos processos ao mesmo tempo, ela precisa fazer o escalonamento dos processos, que é basicamente alternar a execução entre todos os

q

processos permitindo que cada um execute por um curto espaço de tempo. Time-sharing é o nome dado a este compartilhamento do processamento feito entre os processos. Em uma máquina com processamento fraco ou que possua muita demanda de processamento dos processos em paralelo, podem ocorrer falhas em diversas etapas da videoconferência: codificação de vídeo, exibição dos dados, captura dos dados etc. O time-sharing de processos está sendo considerado como um atraso, pois pode provocar o aumento na latência da transmissão caso provoque demora em alguma etapa do processo (na codificação, por exemplo, que é um processo que normalmente demanda bastante do processador).

149

Capítulo 5 - Redes de computadores e videoconferência

Atraso de captura de áudio e vídeo
Áudio 11 Placas normalmente capturam diversas amostras a cada intervalo de tempo. 11 Típico: 64 amostras por pacote, e após isso gera interrupção e disponibiliza todas para o usuário. 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. Vídeo 11 Existe um pequeno atraso em função da câmera utilizada, dos drivers e do software (ou biblioteca) utilizado para captura. O atraso de captura é o tempo necessário para se capturar uma quantidade mínima de

q

dados de áudio ou vídeo. Para áudio, esta quantidade é um determinado número de amostras, enquanto para vídeo é um quadro. As placas de captura de áudio normalmente agrupam diversas amostras a cada intervalo de tempo. Tipicamente são capturadas 64 amostras que são disponibilizadas para o usuário apenas após todas serem capturadas. Utilizando este conhecimento, é possível calcular quanto tempo é necessário 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 vídeo a captura funciona de forma diferente. Normalmente os dados são disponibilizados quadro a quadro após serem capturados, gerando um pequeno atraso em função da câmera utilizada, dos drivers e do software (ou biblioteca) utilizado para captura.

Atraso de captura e codificação
No empacotamento de áudio, alguns codecs necessitam de um tempo fixo para processar a codificação. Para codificação em tempo real, é necessário que o codificador processe os dados mais rapidamente do que eles estão sendo capturados. Por exemplo: 11 Vídeo com 30 quadros por segundo;
Administração de Videoconferência

q

11 Áudio com 300 bytes de amostras a cada 25 ms. A codificação de áudio não requer tanto processamento quanto a codificação de vídeo, e por isso a codificação de vídeo é sempre tomada como parâmetro de desempenho. Quando se deseja codificação em tempo real, o desempenho do processador será o limitador dos parâmetros da codificação, ou seja, se o processador não está conseguindo processar em tempo real, normalmente são modificados parâmetros da codificação (como resolução, taxa de quadros por segundo, entre outros) para reduzir a carga de processamento. Portanto, quando a codificação é em tempo real, o único atraso que a codificação adiciona é o atraso inicial necessário para a codificação dos primeiros blocos de dados.

150

O atraso de empacotamento na codificação é este tempo necessário em alguns codificadores para obter o primeiro conjunto de dados e codificá-los. Na codificação de áudio, alguns codificadores necessitam de um tempo fixo para processar os dados e também 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 codificação, ele deve esperar 5 interrupções da placa de áudio. Empacotamento de vídeo: 11 Alguns algoritmos de predição de movimento utilizam quadros “no futuro” para melhorar a codificação. 11 Para isso é necessário criar um buffer de quadros, que gera atraso. Para codificação em tempo real, o codificador deve ser capaz de processar mais rápido do que os dados são capturados.
8ms 8ms 8ms 8ms 8ms

q

INT

INT

INT

INT

INT 30ms + 7,5ms

Δ t1=40ms

Encoder
Capítulo 5 - Redes de computadores e videoconferência

300 bytes
Figura 5.29 Atraso devido à captura (t1) e codificação (t2).

Δ t2

ES Áudio (24B) t

Na codificação de vídeo, há algoritmos tais como os utilizados para predição de movimento que também requerem quadros ainda não disponíveis para codificar os dados atuais. Com isso torna-se necessário criar um buffer de quadros, que resulta em um atraso na codificação. Além disso, dependendo da complexidade do codec, das opções escolhidas e do desempenho da máquina, é possível que o codificador tenha algum atraso no início da sua execução, o que também 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 transmissão de voz a 64 kbps o

q

preenchimento de um pacote de dados com 1000 bytes (já incluídos os cabeçalhos UDP, RTP, etc.) toma 125 ms. O cálculo é feito da seguinte maneira: 11 1000 bytes correspondem a 8000 bits ou 8 kbits; 11 Com a transmissão 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 físico
Atraso gerado enquanto os pacotes trafegam no meio físico, que varia conforme o método de transmissão utilizado e a distância. Velocidade de transmissão: 11 Par trançado e fibra ótica:
Administração de Videoconferência

q

22 2/3 da velocidade da luz (300.000 km/s) = 200.000 km/s 11 Satélite: 22 Velocidade das ondas eletromagnéticas é um pouco menor que a da luz ao trafegar no ar = 286.000 km/s. 22 Satélite fica a 36.000 km de altitude. Atraso para transmissão de 400 km: 11 Fibra ou par trançado: 400 km ÷ 200.000 km/s = 2ms 11 Satélite: 2 * 36.000 km ÷ 286.000 km/s ≈ 250 ms

152

O atraso gerado no meio físico é o atraso de propagação dos sinais e varia conforme o método de transmissão e a distância da transmissão. Em cabos de par trançado e fibra ótica, a velocidade de propagação dos sinais é 2/3 da velocidade da luz (300.000 km/s), o que resulta em 200.000 km/s. Já em transmissões por satélite, a velocidade de propagação é a velocidade das ondas eletromagnéticas no ar, que é um pouco menor que a velocidade da luz: 286.000 km/s. Além disso, é importante observar que satélites se localizam a uma grande distância da terra, a 36.000 km de altitude. Conhecendo a velocidade de propagação, pode ser calculado o atraso no meio físico para uma transmissão entre dois pontos localizados a 400 km de distância, por exemplo: 11 Fibra ou par trançado: 400 km ÷ 200.000 km/s = 2ms 11 Satélite: 2 * 36.000 km ÷ 286.000 km/s ≈ 250 ms Deve ser considerado duas vezes 36.000, pois o sinal deve subir até o satélite e descer novamente.

Atraso nos equipamentos intermediários
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 inserção e desinserção. 22 Tempo de inserção ou desinserção = tamanho do quadro/taxa de transmissão.

q

Este tipo de atraso é gerado devido aos equipamentos intermediários 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 três modos explicados abaixo, enquanto os roteadores utilizam o modo store and forward. 11 Cut-through: switch começa a encaminhar os pacotes antes mesmo de recebê-los por completo, o que diminui a latência mas diminui a confiabilidade. 11 Store and forward: os pacotes são 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 método store and forward para aquela porta. O método store and forward será o método analisado, pois é o que inclui o maior atraso entre os métodos citados. Nestes equipamentos, os atrasos são chamados de atrasos de inserção (durante o store) ou atrasos de desinserção ( 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 inserção ou desinserção = tamanho do quadro/taxa de transmissão. Com isso, temos como exemplo o custo de inserção 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
Capítulo 5 - Redes de computadores e videoconferência

Atraso nas filas dos roteadores
Acontece em momentos de congestionamento nos roteadores. Cada pacote gera um atraso de desinserção. Exemplo: 11 Quando o pacote chega ao roteador, há 10 outros na sua frente. 11 Com atraso de desinserção 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

q

os pacotes devem esperar que outros sejam encaminhados antes que possam ser encaminhados. Cada pacote esperado gera um atraso de desinserção. Portanto, o atraso nas filas também depende da velocidade dos roteadores. Teremos como exemplo uma transmissão a 2 Mbit/s e pacotes de 125 bytes, onde o atraso de desinserção é de 0,5 ms. Se um pacote chega ao roteador e existem 10 pacotes na sua frente, ele deverá aguardar por 10 desinserções antes de ser encaminhado. Ou seja, o atraso adicionado a este pacote será de 10 * 0,5 = 5 ms.

Atraso de adaptação ao jitter, skew e pacotes fora de ordem
Como são resolvidos os problemas de jitter, skew e pacotes fora de ordem? 11 É necessário 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 exibição.

q

Como já comentado, jitter é a variação da latência e skew é a desincronia das mídias (áudio e vídeo). Já pacotes fora de ordem é um problema que pode acontecer em transmissão UDP, que normalmente é o protocolo utilizado para transmissão de áudio e vídeo. Os três problemas são distintos, mas são resolvidos da mesma maneira: a criação de um buffer de dados no receptor. Com este buffer, o receptor consegue evitar os efeitos do jitter e fazer a sincronia das mídias e o ordenamento dos pacotes, porém inclui o atraso na exibição dos dados. Quanto maior o tamanho do buffer, maior será o atraso gerado. O tamanho do buffer pode ser fixo ou adaptável. Quanto maior o jitter ou o skew, maior deverá ser o tamanho do buffer utilizado. O mesmo é válido para pacotes fora de ordem: se for detectado que muitos pacotes estão chegando fora de ordem, o tamanho do buffer pode ser adaptado para que seja possível ordená-los.

Resumo dos atrasos
11 Time-sharing de processos na máquina;
Administração de Videoconferência

11 Captura de áudio e vídeo; 11 Codificação de áudio e vídeo; 11 Empacotamento; 11 Transmissão física; 11 Equipamentos intermediários (store and forward ); 11 Inserção e desinserção; 11 Fila dos roteadores; 11 Adaptação ao jitter, skew e pacotes fora de ordem.

154

Uso de QoS em videoconferência
Objetivo de garantir que a videoconferência vai atingir a qualidade pretendida, tendo a banda necessária, minimizando atraso, jitter e perda de pacotes. Em videoconferências, a qualidade de serviço pode ser buscada com ferramentas do H.323 e, principalmente, com técnicas de QoS nas redes. O conceito de Quality of Service (QoS) significa garantir a qualidade do serviço em foco, no caso videoconferências. Em videoconferências H.323, a qualidade de serviço pode ser buscada com ferramentas do H.323 e/ou com a utilização de técnicas de QoS nas redes. Ambas alternativas serão vistas em duas etapas: 11 QoS no H.323. 11 QoS na rede.

q

QoS no H.323
O gatekeeper H.323 provê algumas funcionalidades para melhoria da qualidade do serviço. O QoS é um bloco adicional interligado ao gatekeeper e à transmissão H.323. Gatekeeper 11 Controle simples baseado em um pool de chamadas. 11 Controla o somatório da demanda de banda de todas as chamadas. 11 Limita a largura de banda utilizada negando novas chamadas. Problemas: 11 Gatekeepers conhecem apenas o tráfego H.323 – visão isolada. 11 Ignora a situação atual dos dispositivos de rede – terminal pode solicitar 384 kbit/s e utilizar 500 kbit/s. 11 Utiliza a banda solicitada pelos terminais, não a que realmente foi utilizada. Uma forma de buscar a qualidade de serviço em videoconferências H.323 é aliar as funcionalidades convencionais do sistema de videoconferência às funcionalidades de QoS. O gatekeeper H.323 é o componente do sistema de videoconferência que pode fornecer alguma garantia de QoS.

q

de admissão executado pelo gatekeeper é fundamentado numa espécie de pool – canal coletivo das larguras de banda disponíveis. Quando um terminal vai iniciar uma ligação, ele solicita ao gatekeeper determinada largura de banda. O gatekeeper, então, libera ou bloqueia esta nova chamada conforme as outras chamadas que estão em andamento. Supondo que o gatekeeper está configurado para utilizar 2 Mbits/s e há duas videoconferências de 800 kbit/s em andamento, apenas chamadas de menos de 400 kbit/s serão liberadas. Entretanto, as decisões feitas pelo gatekeeper a respeito da disponibilidade da largura de banda podem não coincidir com a disponibilidade real da largura de banda na rede. É possível que o gatekeeper esteja configurado para utilizar 2Mbit/s (por ser a capacidade máxima da rede), mas a banda atualmente disponível na rede é de apenas 1 Mbit/s, devido a outros tráfegos não H.323. Ou seja, o gatekeeper tem uma visão isolada da rede, considerando apenas o tráfego H.323.

155

Capítulo 5 - Redes de computadores e videoconferência

O controle de admissão é a principal função do gatekeeper para buscar QoS. Esse controle

Além disso, os gatekeepers não 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, então, emitir 400 ou mais kbit/s de dados. Se esses dados não trafegarem via gatekeeper, que é a solução mais frequente, o gatekeeper não 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

fisca

lizaç

ão

E

i nv

a

40

0

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 classificação dos dados e o seu gerenciamento para implementação de QoS. São elas: 11 DiffServ (Differentiated Services) 22 Classificação por pacotes. 11 IntServ (Integrated Services) 22 Classificação por fluxos. 11 DiffServ (Differentiated Services) 11 Classificação é feita por pacotes. 11 Utiliza marcação DSCP (Differentiated Services Code Point ). 22 6 bits no cabeçalho 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 são definidas pelas aplicações ou pelos operadores da rede.
Administração de Videoconferência

q

IntServ (Integrated Services): 11 Classificação é feita por fluxos. 11 Aplicações 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 tráfego de dados nos equipamentos intermediários 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 é possível evitar problemas mais graves em transmissões multimídia como pacotes descartados, jitter, atrasos em filas, entre outros. A imagem abaixo mostra um esquema genérico do funcionamento de QoS na rede:

Classificação

Policiamento

Figura 5.31 Esquema do funcionamento de QoS nas redes.

Filas e escalonamento

Controle de admissão e políticas de controle

Classificação
Separação dos pacotes em classes distintas, seja esta separação feita para os pacotes individualmente ou para fluxos de uma aplicação. Assim, cada classe pode ter um tratamento individualizado. Como será visto, a classificação no DiffServ é feita por pacotes e no IntServ por fluxos.

Filas e escalonamento
De acordo com a classe dos pacotes, eles normalmente são agrupados em diferentes filas e tratados de forma diferenciada. Nas filas de prioridade, os pacotes de alta prioridade são entregues primeiro; quando não existem pacotes de alta prioridade na fila, são entregues os pacotes de média prioridade, e o mesmo vale para os pacotes de baixa prioridade.
Capítulo 5 - Redes de computadores e videoconferência

Controle de admissão e políticas de controle
Basicamente, contratos são definidos para garantir o atendimento de um determinado serviço de acordo com a capacidade dos equipamentos. Conhecendo as políticas já existentes, os equipamentos podem fazer o controle de admissão de novas políticas. Se os recursos forem sobrecarregados ou utilizados no limite, por exemplo, os equipamentos podem começar a rejeitar novas transmissões para os serviços já existentes não serem comprometidos.

Policiamento
O policiamento dos contratos (assumidos no controle de admissão) procura garantir que os requisitos estabelecidos no contrato sejam respeitados. Quando essa função é configurada em um dispositivo, deve monitorar, controlar e reforçar 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 classificação dos dados e o seu gerenciamento para implementação de QoS ao longo da rede. São elas: 11 DiffServ (Differentiated Services): utiliza classificação por pacotes. 11 IntServ (Integrated Services): utiliza classificação por fluxo.

DiffServ
No DiffServ (Differentiated Services), a classificação dos dados é feita por pacotes, possuindo assim uma granularidade grossa (ao contrário do IntServ que será visto na sequência). São atribuídas classes aos pacotes utilizando a marcação DSCP (Differentiated Services Code Point), que é basicamente o uso de 6 bits no cabeçalho dos pacotes IP. Os roteadores ao longo da rede são configurados para tratar os pacotes de forma diferente conforme sua classe, ou seja, pacotes com classes de maior prioridade passam a ter tratamento prioritário nos roteadores. As classes utilizadas não são especificadas pelo DiffServ e devem ser definidas pelas aplicações ou operadores da rede.

IntServ
No IntServ (Integrated Services)a classificação é feita por fluxo de dados, tendo portanto uma granularidade mais fina que no DiffServ. Neste caso não basta a marcação dos pacotes, é necessário que as aplicações que precisam QoS façam a reserva dos recursos necessários na rede. Para reservas de recursos são utilizados dois protocolos, que, obviamente, devem ser implementados nos roteadores para que a reserva seja possível: 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 vídeo a 30 quadros por segundo onde cada quadro possui no máximo 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 máxima 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 função desse protocolo é possibilitar as reservas de recursos através de toda a rota de entrega de pacotes para determinado fluxo de dados. Quando uma aplicação requer QoS para a transmissão de um fluxo de dados, o RSVP é utilizado para informar sobre a necessidade de QoS para todos os
Administração de Videoconferência

roteadores ao longo da rota de transmissão do fluxo, garantindo, assim, a manutenção das condições 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 transmissão. As mensagens RESV contêm o protocolo Flow Specs, que descreve as características do tráfego de dados e as necessidade de QoS que ele possui. Através dessas mensagens, os roteadores ficam sabendo da necessidade de QoS para determinado fluxo e decidem se eles podem atender esta demanda ou não. Se eles podem atender a demanda, simplesmente farão o encaminhamento dos pacotes. Se não podem, eles enviam mensagens aos receptores informando do problema.

158

Diffserv Classificação de pacotes Backbone

Classifica e escalona os pacotes

Acesso

Acesso

Sinalização RSVP

Domínio

Figura 5.32 Sinalização RSVP através da rota de um tráfego com QoS.

159

Capítulo 5 - Redes de computadores e videoconferência

160

Administração de Videoconferência

Roteiro de Atividades 5
Atividade 1 – Gerar fluxos UDP e TCP com iperf
O iperf (ou jperf – com interface gráfica) é uma ferramenta que permite, entre outras coisas, gerar tráfego de rede em diversos formatos, sendo que nesta atividade nos interessam: 11 TCP; 11 UDP; 11 Unicast e multicast. Os objetivos de utilização de um software gerador de tráfego são vários, e pode-se resumir nos seguintes cenários: 11 Cenário 1: suponha que, no seu local de trabalho, você foi convocado para organizar uma videoconferência ponto-a-ponto com uma região com banda desconhecida. Você precisa estimar quanta banda pode ser utilizada pela videoconferência, a fim de configurar o software. Nesse caso pode testar várias bandas em UDP unicast entre os dois pontos, até descobrir o limite sem perda de pacotes. 11 Cenário 2: você quer saber se o provedor da sua residência 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 transmissões em TCP para descobrir o máximo de banda. 11 Cenário 3: você quer utilizar multicast na sua videoconferência, porém não sabe se a rede entre os pontos suporta multicast. Nesse caso, basta utilizar o software fornecendo um IP multicast para teste. 11 Cenário 4: você precisa saber se uma determinada porta está aberta no firewall entre a sua rede e a rede destino da videconferência. Para isso basta utilizar o software na porta desejada, seja em TCP ou UDP, conforme desejado.

Etapas da atividade prática
São três as etapas desta atividade prática. Todas devem ser executadas em dupla, onde um membro da dupla executa o servidor e outro o cliente.
1. Criação de fluxo UDP unicast

Crie três fluxos entre sua máquina e o servidor na máquina do colega. Um deles de 100kbit/s, depois outro de 1Mbit/s e depois outro de 10Mbit/s. A duração de cada fluxo deve ser pelo menos de 10 segundos. Verifique o gráfico de uso da banda através de um software de medição de banda da rede, como o DU Meter.
2. Criação de fluxo UDP multicast
Capítulo 5 - Roteiro de Atividades

Crie um fluxo UDP multicast entre sua máquina e o servidor do colega. Utilize a velocidade de 1Mbit/s. Confira através 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 aleatório entre 1 e 254. Você pode utilizar o número da sua máquina, por exemplo.

3. Criação de fluxo TCP unicast

Crie um fluxo TCP unicast entre sua máquina e a do servidor do colega. Qual a banda obtida na conexão? Explique.

No modo TCP não deve ser especificada a banda da transmissão (-b), pois o objetivo é utilizar a maior banda possível na rede.

Atividade 2 – Identificar e analisar pacotes RTP e RTCP
Nesta atividade será utilizada comunicação em duplas para identificar e analisar pacotes RTP e RTCP em uma comunicação ponto-a-ponto. Em duplas, os alunos devem fazer uma comunicação via software de videoconferência e utilizar o Wireshark para responder as seguintes questões:
1. Qual a função do RTCP? Qual a proporção do número de pacotes RTCP frente aos pacotes RTP?

2. Para o RTP, explique os campos “versão”, “Payload Type”, “Sequence Number” e “timestamp”.

3. Identifique os fluxos de mídia existentes entre transmissor e receptor. Filtre através do

Wireshark um deles (máquina 1 para máquina 2). Descubra se este fluxo é de áudio ou de vídeo. Em seguida, filtre o segundo fluxo da máquina 1 para a máquina 2. Esse fluxo
Administração de Videoconferência

é de áudio ou vídeo? Para auxiliar na descoberta, pode-se utilizar como base o seguinte: tamanho do pacote, timestamp e número de sequência; verifique o significado do campo “Mark” no RTP.

162

Atividade 3 – Calcular atrasos na comunicação
Para o fluxo de áudio da Atividade 2 (item 3), calcule:
1. Tempo médio de inserção (considere o tamanho do pacote visto na Atividade 2).

2. Atraso no meio físico (considere 30m a distância UTP entre sua máquina 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

Capítulo 5 - Roteiro de Atividades

164

Administração de Videoconferência

6
Videoconferência multiponto
objetivos
Permitir que o aluno compreenda e saiba analisar as características de sistemas de videoconferência multiponto e suas diferenças fundamentais para tomar uma decisão bem fundamentada na hora da escolha.

conceitos

Videoconferência multiponto, funcionamento e soluções de Multipoint Control Units (MCUs), multiponto com vídeo escalável.

Videoconferência multiponto
Há basicamente três modelos possíveis: 11 Modelo centralizado. 11 Modelo descentralizado. 11 Modelo híbrido.

q

Como funciona a transmissão em um cenário de videoconferência com mais dois participantes? Uma conferência 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 conferência que envolve mais que dois pontos é chamada de conferência multiponto. Em videoconferências multiponto, o modelo de transmissão adotado é definido, principalmente, em função do número de transmissores. Quando há apenas um transmissor, o modelo mais apropriado é diferente do modelo adequado para videoconferências com múltiplos transmissores. Em uma aula remota, por exemplo, onde um professor está transmitindo seu áudio e vídeo para múltiplos alunos que não transmitem seus dados, temos o modelo com apenas um transmissor. Neste caso, é possível utilizar multicast para transmissão dos dados do professor de forma otimizada: ele só precisa enviar os dados uma vez para alcançar todos os alunos. Seguindo o mesmo exemplo, se for necessário que os alunos façam interações com o professor, enviando perguntas por áudio e vídeo, passamos a ter um modelo com múltiplos transmissores. Este modelo é o que envolve maior complexidade em transmissões multiponto, sendo, portanto, o modelo em foco no restante deste capítulo. Em videoconferências multiponto, há basicamente três modelos de transmissão possíveis: o modelo centralizado, o modelo descentralizado e o modelo híbrido. 165
Capítulo 6 - Videoconferência multiponto

Modelo centralizado
Em uma sessão de videoconferência baseada neste modelo, cada participante estabelece uma conexão com um componente central, chamado de Multipoint Control Unit (MCU). Cada participante envia um fluxo de áudio e um de vídeo para a MCU. A distribuição do fluxo de áudio, vídeo e dados para cada participante é feita pela MCU, que mescla os vários fluxos de áudio, seleciona um fluxo de vídeo ou compõe um novo fluxo com múltiplos vídeos e retransmite o resultado para todos os participantes. Essa composição de vídeos pode ser, por exemplo, uma tela dividida em quatro partes iguais, cada uma exibindo o vídeo de um dos participantes. O MCU gerencia a videoconferência usando funções de controle H.245 e é o elemento mais importante em uma videoconferência centralizada. Ele pode enviar o fluxo de áudio e vídeo através de unicast ou multicast.

B

C

D

A

B

C

D

A

MCU

Figura 6.1 Videoconferência multiponto centralizada.

Modelo descentralizado
No modelo descentralizado, não há um componente central para controlar a conferência como a MCU. Neste modelo são os próprios terminais que fazem o controle da comunicação e do tráfego de dados multimídia. Uma diferença importante é justamente o tratamento dos dados multimídia: enquanto no modelo centralizado a MCU faz o processamento de mídia, no modelo descentralizado os fluxos são enviados e recebidos por todos os participantes sobre uma base fim a fim, sendo que cada participante é responsável por sua própria mesclagem de áudio e seleção de vídeo. A transmissão dos dados multimídia 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
Administração de Videoconferência

terminal deve enviar e receber n-1 fluxos. Este modelo apresenta um problema de escalabilidade quando a videoconferência apresenta muitos terminais.

166

Figura 6.2 Videoconferência 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 não é reduzido o download.

Transmissão multicast

Figura 6.3 Videoconferência multiponto descentralizada usando multicast.

Outra forma de visualizar a codificação escalável é vista na Figura 6.4 (Telepresence options, setembro de 2012 – Jeff Scherz – Video Interoperability in Lync 2013).

Figura 6.4 Exemplo de transmissão escalável com quatro camadas se adaptando a dispositivos com diferentes resoluções.

Modelo híbrido
O modelo híbrido tenta mesclar o melhor dos dois modelos anteriores, mantendo a consistência dos dados através de um armazenamento centralizado que controla a conferência, mas permitindo que os terminais tenham autonomia suficiente para fazer a transmissão de alguns dados de forma descentralizada.

167

Capítulo 6 - Videoconferência multiponto

Transmissão multicast

MCU

Figura 6.5 Videoconferência multiponto híbrida.

Uma implementação híbrida pode: operar sobre uma rede multicast com cada usuário utilizando sua própria versão das ferramentas; distribuir o fluxo de mídia de acordo com o modelo descentralizado, mas contendo algum mecanismo – tal como um servidor na conferência – para controlar documentos compartilhados, ou arquivar a mídia de sessões que ocorreram. Portanto, o modelo híbrido tem a vantagem de prover armazenamento centralizado para sessões de videoconferência para cada participante da sessão, sem ter que controlar cada instante da aplicação. Um exemplo de videoconferência baseada no modelo híbrido é utilizar uma MCU para manusear o áudio, dados e controle de funções, mas distribuir o vídeo por multicast, com objetivo de otimizar a largura de banda.

MCU
11 Gerencia conferências multiponto, viabilizando a comunicação entre 3 ou mais pontos simultaneamente. 11 Permite a criação de múltiplas salas virtuais de conferência. 11 Pode transmitir os vídeos em unicast (para todos participantes) ou multicast. 11 Pode ser apenas um controlador de sinalização (modelo híbrido) ou também controlar toda a mídia (modelo centralizado). Outras funcionalidades: 11 Realiza a transcodificação de velocidades (bitrate). 11 Servidor de streaming (suportado pela minoria das soluções). 11 Sistema de gerenciamento via web com: 22 Controle sobre os participantes remotos.
Administração de Videoconferência

q

22 Bloqueio de áudio/vídeo remoto. 11 Múltiplos layouts de vídeo. A MCU é a unidade responsável pelo gerenciamento de conferências multiponto, viabilizando a comunicação entre três ou mais pontos simultaneamente. Uma MCU normalmente permite a criação de múltiplas salas virtuais de conferência, podendo agir apenas como um controlador de sinalização (no modelo híbrido) ou também controlar toda a transmissão multimídia (no modelo centralizado). Outras funcionalidades importantes da MCU: 11 Realizar a transcodificação de velocidades (variação no bitrate de codificação); 11 Servidor de streaming (suportado pela minoria das soluções);

168

11 Sistema de gerenciamento via web com: 22 Controle sobre os participantes remotos; 22 Bloqueio de áudio/vídeo remoto; 22 Múltiplos layouts de vídeo, conforme exemplo da figura seguinte.

Figura 6.6 Múltiplos layouts de vídeo.

Dois modos de operação para controle de áudio e vídeo: Comutação por voz 11 Vídeo e áudio de apenas um participante. 11 O participante ativo é aquele que está falando no momento. Mixagem de vídeo e áudio 11 Chamada de presença contínua. 11 Múltiplos vídeos e múltiplos áudios mixados. Os vídeos são dispostos conforme o layout escolhido. A recomendação H.323 especifica que a MCU é composta por dois elementos básicos: um

q

Multipoint Controller (MC), obrigatório para conferências multiponto, e unidades Multipoint Processor (MP), opcionais. Apesar do MP ser opcional, uma MCU deve incluir pelo menos um para suportar a realização de conferências centralizadas. O Multipoint Controller (MC) tem como objetivo fazer o controle geral da conferência, o que envolve fazer ou receber chamadas dos terminais, negociar as capacidades dos terminais e se comunicar com o MP quando for necessário algum tratamento sobre os dados de áudio e/ou vídeo. O MC não 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 negociação de capacidades com cada um dos terminais presentes à conferência, onde ele procura estabelecer capacidades comuns de áudio, vídeo ou dados. Isto é feito enviando um conjunto comum de capacidades (capability set) aos terminais conectados à conferência. Neste ponto, é importante lembrar que cada terminal também fornece sua tabela de capacidades no início da chamada ao elemento que contém o MC, que pode ainda rever tal conjunto de capacidades cada vez que um terminal entra ou deixa a conferência. Este conjunto de capacidades também pode ser crucial para a determinação do tipo de conferência (centralizada ou descentralizada) em questão. Cada conferência possui somente um MC que executa a função de gerenciamento. Este MC é chamado MC ativo e, uma vez determinado, este status não é modificado até o final da conferência – ou seja, durante o curso de uma conferência H.323, o controle de gerência jamais 169
Capítulo 6 - Videoconferência multiponto

é transferido de um MC para outro. Eventualmente, quando dois terminais H.323, que possuem um MC cada, conectam-se através 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 preferência utilizada é definida pela seguinte função: MC terminal < MC gateway < MC gatekeeper < MC MCU. Nesse caso, o MC presente em uma MCU tem preferência 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 início de uma conferência 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 características de cada um dos elementos. Os valores para este campo dependem do tipo de entidade, da presença ou não de MC e MP e, por fim, dos tipos de mídia suportados pelo MP: dados; dados e áudio; dados, áudio e vídeo (completa). Sendo assim, o MC da entidade que apresentar maior valor para terminalType assume o controle da conferência. 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 conferência apenas quando se trata do modo centralizado ou, possivelmente, no modelo híbrido. O MP tem por finalidade processar um ou mais fluxos de áudio, vídeo ou dados, devolvendo o resultado deste processamento aos participantes da conferência. Caso o MP processe vídeo, o resultado desse processamento pode ser: (1) a mixagem dos vídeos de diversos participantes de acordo com um layout escolhido; ou (2) a chamada comutação dos vídeos, onde apenas o vídeo de um participante é utilizado (o participante ativo). No caso de vídeo comutado, somente o vídeo de um dos participantes é exibido por vez. A seleção do vídeo que será exibido é feita detectando-se o usuário ativo no momento, ou seja, aquele com a posse da palavra. Já os áudios dos participantes são mixados e enviados para todos, ou seja, apesar de ser exibida apenas uma imagem, é possível ouvir os outros participantes. Esta técnica é chamada de comutação de vídeo ativada por voz (voiceactivated video switching). Se os participantes não são suficientemente disciplinados, aguardando sua vez de falar, este tipo de comutação pode ser problemática, pois o vídeo pode ser continuamente chaveado assim que um participante começa a falar, impossibilitando uma visualização inteligível.

Administração de Videoconferência

Figura 6.7 Vídeo comutado por voz.

No outro caso, vídeo mixado, os vídeos de diversos participantes são combinados em um novo vídeo que é codificado e enviado aos participantes. Tipicamente, o MP divide o vídeo em várias janelas distintas, cada uma com o vídeo em escala reduzida de um dos participantes. Normalmente, uma das janelas (normalmente maior que as outras) é escolhida para aplicar uma comutação baseada em voz, enquanto as demais se mantêm inalteradas,

170

a menos que um dos participantes deixe a conferência. Esse modo é chamado de presença contínua. Alguns fabricantes oferecem layouts diferentes como diferencial (como no exemplo visto anteriormente). O modo de presença contínua implica um elevado custo computacional para sua realização, uma vez que o MP trabalha decodificando e recombinando vídeo de vários participantes, em vez de simplesmente retransmitir determinado vídeo, como no modo de comutação por voz. A situação do áudio permanece como no modo por comutação: 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 próprio áudio misturado com os demais; caso contrário, haveria um desagradável efeito de eco.

Figura 6.8 Vídeo com presença contínua.

Click here to add another person to the conference

Soluções de MCUs
A escolha de uma solução de MCU é feita com base nos requisitos necessários para as videoconferências. É importante que suportem os principais protocolos atuais: 11 Protocolos de vídeo: H.261, H.263 / H.263+ / H.263++ / H.264. 11 Resoluções de vídeo: 11 CIF, QCIF e 4CIF – 720p e 1080p (alta definição). 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 à visualização, devem suportar: 11 Variados layouts de vídeo. 11 Layouts com suporte a um grande número de participantes. 22 Geralmente, o número de referência é 16. 11 Formato widescreen. 11 Possibilidade de preview das câmeras dos participantes. 11 Controle do áudio e vídeo dos participantes remotos (habilitar/desabilitar). 11 Mensagem de texto na tela (close caption).

q

171

Capítulo 6 - Videoconferência multiponto

Quanto à segurança, devem suportar: 11 Configuração de direitos e privilégios para usuários. 11 Configuração de senha para conferências. 11 Padrão de encriptação ITU H.235 (pelo menos codificação AES). Tipos de soluções: 11 Baseadas em hardware. 22 Não-modulares: soluções fechadas, que não podem ser agrupadas a outros módulos posteriormente. 22 Baseadas em software (OpenMCU, por exemplo).

q

A escolha de uma solução de MCU é feita com base nos requisitos necessários para as videoconferências. Seguem abaixo alguns itens importantes que devem ser considerados para a escolha de uma solução de MCU. É importante que a solução que suporte os principais protocolos atuais de vídeo (H.261, H.263 / H.263+ / H.263++, H.264) e os formatos (CIF, QCIF e 4CIF) em 720p e 1080p, para alta definição. Suportem também 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 à visualização, devem suportar variados layouts de vídeo, layouts com suporte a um grande número de participantes onde geralmente, temos como referência 16, suporte ao formato wide screen com possibilidade de preview das câmeras dos participantes (através de interface de gerenciamento web da MCU, por exemplo), deve permitir controlar o áudio e o vídeo dos participantes remotos podendo habilitar e desabilita-lo e até mesmo exibir mensagens de texto na tela (close caption). Quanto à segurança, devem permitir a configuração de direitos e privilégios para usuários, configuração de senha para conferências e suporte ao padrão de encriptação ITU H.235 (pelo menos codificação AES). As soluções de MCU podem ser classificadas em dois tipos: as baseadas em software e as baseadas em hardware. As soluções em hardware constituem soluções comerciais completas para o oferecimento do serviço de videoconferência. São soluções caras e geralmente utilizadas no meio profissional. Elas podem ser modulares, onde recursos (outros módulos MP, por exemplo) podem ser agregados conforme a necessidade, e não-modulares, que são modelos mais fechados e não permitem expansão.

Administração de Videoconferência

Figura 6.9 Equipamento MCU.

As soluções baseadas em software são mais baratas, mas seu desempenho é dependente do hardware onde serão implantadas. Essa dependência torna o serviço suscetível e frágil. Porém, existem soluções acessíveis em código aberto e que oferecem resultados satisfatórios em casos de conferências experimentais, como por exemplo, a solução OpenH323.

172

Soluções de MCUs em hardware
11 Modelo modular. 11 Modelo não-modular: 22 Mesmos fabricantes dos modelos modulares. 22 A expansão só é possível através do cascateamento de MCUs, ou seja, não é uma solução tão boa quando a expansão adicionando módulos. 22 Por serem uma “caixa fechada”, são modelos mais baratos que os modulares. As soluções de MCU em hardware, tanto os modelos modulares quanto os não-modulares, são disponibilizadas por diversos fabricantes. Os principais fabricantes atualmente são: Codian (que faz parte da Tandberg), Tandberg (que faz parte da Cisco), Polycom e Radvision. As MCUs modulares utilizam um chassi onde os módulos são colocados e interligados. É possível, portanto, comprar a MCU básica com apenas um módulo e adicionar novos módulos (Multipoint Processors) conforme necessidades futuras. Já os modelos não-modulares são “caixas fechadas”, onde a expansão só é possível através do cascateamento de

q

MCUs. No cascateamento, as múltiplas MCUs operam como se houvesse apenas uma MCU na rede (cascateamento é transparente ao usuário), mas ainda assim não é uma solução tão otimizada como a expansão por adição de módulos. Por esse motivo os modelos modulares costumam ser soluções mais caras do que os modelos não modulares.
Figura 6.10 Exemplos de MCUs modulares.

As imagens abaixo exemplificam MCUs em hardware, incluindo modelos modulares e não-modulares:

Tandberg

Polycom

MPS 200

MPS 800

MGC 50

MGC 100

RMX 2000*

Codian

Radvision

MSE 8000*

173

Capítulo 6 - Videoconferência multiponto

SCOPIA 400

SCOPIA 1000

Polycom

MGC 25

Codian

Radvision
Figura 6.11 Exemplos de MCUs não-modulares.

Série 4200

Série 4500 (HD)

SCOPIA 12/24

Modelos de MCU que suportam alta definição estão sendo demandados em função do crescente número de terminais que suportam alta definição.

Lifesize

Polycom

Tandberg*

Lifesize Room

Série HDX 9000

Tandberg Edge

Figura 6.12 Exemplos de MCU.

Demonstração de MCU – RNP
11 MCU utilizada pela RNP: Polycom RMX4000. 11 Características: H.264 High Profile nível 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 imersão em telepresença, com integração a partir de diversas plataformas de conferência e dispositivos móveis. Características: 11 H.264 High Profile; 11 Alocação dinâmica de recursos; 11 Suporte à multi-rede;
Administração de Videoconferência

q

11 Integração nativa com aplicativos; 11 Suporte a tecnologia UltimateHD™ da Polycom; 11 Salas de reuniões virtuais sempre disponíveis.

174

Figura 6.13 MCU RMX 4000.

Soluções de MCUs em software
Solução baseada em software, dependente dos recursos de hardware onde for implantada. OpenMCU: 11 Desenvolvida no projeto OpenH.323 (agora chamado H.323Plus). 11 Solução open source. 11 Suporte a vídeo H.261 e H.263 com resoluções QCIF e CIF. 11 Suporte a vários codecs de áudio (todos suportados pelo OpenH.323). 11 Combina no máximo vídeo de 4 participantes. 11 Suporta múltiplas salas de videoconferência. Soluções de MCU baseadas em software são soluções normalmente muito mais baratas que soluções em hardware, mas cujo desempenho depende diretamente da capacidade da

q

máquina na qual a solução 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 soluções em hardware (onde o hardware já é otimizado para uso de MCU). Um exemplo de solução MCU em software é o OpenMCU, uma aplicação open source desenvolvida no projeto OpenH323 (agora chamado H323Plus). O OpenMCU é uma solução livre mas limitada, tendo como principais características: 11 Suporte a H.261 e H.263 com resoluções QCIF e CIF; 11 Suporta todos os codecs de áudio suportados pelo OpenH323; 11 Interface de configuração web; 11 Suporta múltiplas salas de videoconferência e conexões simultâneas;
Capítulo 6 - Videoconferência multiponto

11 Possibilita iniciar chamadas a partir da MCU para os terminais; Combina no máximo o vídeo de 4 participantes. MCUs em software normalmente possuem limitações similares no número máximo de participantes. Assim, podem ser oferecidas diferentes versões do software, cada uma com suporte a um diferente número de participantes (o que é usado para determinar o preço de venda).

175

Alternativa ao MCU: vídeo escalável
Permite codificar um vídeo em múltiplas camadas. Cada camada representa o vídeo com determinadas configurações de: 11 Resolução. 11 Taxa de quadros por segundo. 11 Qualidade (medida PSNR). 11 Taxa de bits por segundo (bitrate). 11 Ou seja, o vídeo é codificado apenas uma vez e pode ser transmitido e visualizado em diversas configurações/qualidades. Comparação com MCU: 11 MCU precisa decodificar os dados, compor o novo vídeo e codificá-lo. 11 Um roteador escalável apenas faz a seleção e o encaminhamento dos pacotes ajustando o número 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 não faz transcodificação. Desvantagens sobre o uso de MCU: 11 Necessita de um software codificador e decodificador escalável nos terminais, exigindo maior processamento. 11 Dificuldade de interoperar entre diferentes fabricantes, pois o Scalable Video Coding (SVC) ainda é pouco explorado. Codificação de vídeo escalável, simplificadamente, é uma forma de codificar um vídeo em diversas camadas cumulativas, onde as camadas inferiores possuem qualidade mais

q

baixa e servem como base para as camadas superiores, que adicionam qualidade ao vídeo. Podemos ter, por exemplo, um vídeo codificado com 3 camadas, sendo elas: 11 Camada 0: resolução 160x120 e 15 quadros por segundo: 128 kbit/s; 11 Camada 1: agrega à camada 0 o diferencial para uma resolução 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 resolução 640x480 e 30 quadros por segundo: camada 2: 512kbit/s. Agregado “camada 0 + 1 + 2” = 1024 kbit/s.
Administração de Videoconferência

As três camadas do exemplo formam um vídeo apenas, e não três vídeos. Com codificação de vídeo tradicional, para obter essas três diferentes configurações dos vídeos, seria necessário codificar o vídeo três vezes. Com codificação escalável é necessária apenas uma codificação. A desvantagem, porém, está no maior custo de processamento e em uma compactação um pouco menor do que a obtida com uma codificação não escalável (20% menos eficiente, por exemplo). A imagem seguinte ilustra o processo de codificação escalável.

176

Vídeo original Alta resolução, qualidade alta TV Alta resolução, qualidade baixa Codificação escalável Baixa resolução celular
Figura 6.14 Codificação escalável em três camadas.

PC

Codificação única

O padrão mais atual para codificação de vídeo escalável é o H.264 SVC (Scalable Video Coding ). Com esta forma de codificação, é possível substituir a MCU por um elemento chamado “roteador escalável”, que apenas faz a seleção e o roteamento dos pacotes, um processo muito mais simples e rápido que o processo feito pela MCU.

Codificação escalável

MCU

Decodificar Usuário 1 Usuário 2 Usuário 1

Decodificar Usuário 2

Compor Roteamento e seleção das camadas

Codificar

Usuário 3
Figura 6.15 Comparação do roteador escalável com a MCU.

Usuário 3

Como pode ser visto na figura anterior, o processamento feito pela MCU inclui: a decodificação de todos os vídeos que ela recebe (todos os participantes da videoconferência); a composição dos vídeos em um só vídeo; a codificação deste vídeo gerado. Todo este processo é bastante complexo computacionalmente, incluindo assim o atraso na transmissão. É também devido a essa complexidade que as MCUs são dispositivos caros, já que devem ter alto poder de processamento. Já o modelo com roteador escalável passa uma maior complexidade para os terminais, minimizando o trabalho do roteador escalável, substituindo a MCU. Dessa forma, o roteador já recebe dos terminais os vídeos codificados de forma escalável, e apenas seleciona as camadas que serão retransmitidas aos destinatários, de acordo com a capacidade de processamento e banda de cada um. A decodificação e recodificação feitas pela MCU não são necessárias neste cenário, e a composição dos diversos vídeos é feita apenas no receptor, antes da exibição. 177
Capítulo 6 - Videoconferência multiponto

Utilizando as 3 camadas de vídeo utilizadas como exemplo anteriormente, uma transmissão escalável pode se dar como no exemplo abaixo: 11 Os 4 participantes codificam seus vídeos de forma escalável, com as 3 camadas citadas no exemplo, transmitindo-as para o roteador escalável (que faz o papel do MCU); 11 O layout escolhido pelos participantes é de um vídeo com maior resolução (comutado por quem está falando no momento) e 3 vídeos com menor resolução; 11 O roteador identifica que o participante A está falando, e por isso transmite as camadas 0 e 1 de seu vídeo (obtendo um vídeo com resolução 320x240 e 30 quadros por segundo a 512 kbit/s); 11 Para os outros 3 participantes, o roteador transmite apenas a camada 0 (vídeos com resolução 160x120 e 15 quadros por segundo a 128 kbit/s); 11 Com isso cada participante receberá 3 vídeos com resolução 160x120 e um vídeo com resolução 320x240, com banda total de 896 kbit/s (4x128kbit/s + 1x384kbit/s); 11 Eventualmente, se um dos participantes não tivesse banda suficiente, ele poderia receber somente a camada 0 de todos os participantes, minimizando sua necessidade de banda. É possível fazer diversas configurações de camadas variando resolução, quadros por segundo e banda de cada camada de vídeo na codificação escalável. Além disso, também é possível fazer adaptação da banda dos vídeos dinamicamente, ou seja, o total de 896 kbit/s recebido por cada participante no exemplo anterior poderia ser reduzido pelo próprio rote ador em troca da perda de qualidade dos vídeos. Como podemos ver, existem algumas vantagens relacionadas à utilização de vídeo escalável. Resumidamente, as vantagens em relação à MCU são: 11 O atraso é reduzido (não é necessário perder tempo em transcodificação e mixagem); 11 O processamento é reduzido, pois é feito apenas nos terminais. O roteador é só um encaminhador de pacotes que determina também o número de camadas para cada terminal; 11 Equipamentos mais baratos que MCUs. Em termos de desvantagens, pode-se dizer que, como o modelo é novo, não existe padronização de sinalização ainda, e a interoperabilidade entre diferentes fabricantes é prejudicada. Além disso, aumenta a necessidade de processamento nos terminais.

Estudo de caso de vídeo escalável: empresa Vidyo
Vidyo é uma empresa que desenvolve soluções de videoconferência baseadas em codificação de vídeo escalável (padrão H.264 SVC – Scalable Video Coding ). Seu núcleo é baseado em um roteador H.264 SVC.
Administração de Videoconferência

q

Vidyo é uma empresa que desenvolve uma solução de videoconferência baseada em codificação de vídeo escalável, que é uma alternativa ao modelo padrão de videoconferências multiponto que têm a MCU como elemento centralizador. A figura a seguir mostra a ideia de forma geral, onde a seta verde representa o fluxo de vídeo escalável. Para conversar com outros tipos de conferência, é necessário um gateway.

178

Figura 6.16 Estrutura da solução da empresa Vidyo.

v
Acesse www.vidyo.com e assista ao vídeo “Vidyo Desktop in Action”

179

Capítulo 6 - Videoconferência multiponto

180

Administração de Videoconferência

Roteiro de Atividades 6
Atividade 1 – Demonstração 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 estão H.263, H.264, H.323, SIP e criptografia AES, entre outros. Sua especificação completa pode ser encontrada em Polycom Technical Specifications. Na demonstração, deve ser ressaltada a possibilidade de administração da solução pela web através da porta 80 e também introduzindo o recurso People + Content, que será apresentado na próxima atividade. Neste momento o instrutor deve realizar chamadas para o software de videoconferência 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 utilização 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. Após estabelecer a conexão, o aplicativo People+Content (instalado em qualquer máquina do laboratório) estabelece conexão com o Polycom V500, entrando assim na conferência.

181

Capítulo 6 - Roteiro de Atividades

182

Administração de Videoconferência

7
Projeto de ambientes de videoconferência
objetivos
Ao final do capítulo o aluno deve possuir uma visão mais embasada dos elementos necessários para efetuar o projeto de todos os aspectos envolvidos em uma sala de videoconferência (ambiente físico, áudio e vídeo). Além disso, deve entender os conceitos básicos de ética em videoconferência.

Projeto de salas de videoconferência, levando em consideração o ambiente físico (iluminação, visibilidade, acústica, climatização), ambiente de áudio (tipos e posicionamento dos microfones) e ambiente de vídeo (interferências, acessórios), ética em videoconferência e estudo de cenários.

conceitos

Salas de videoconferência
Diversos fatores em uma sala de videoconferência influenciam na qualidade do serviço de videoconferência. Eles podem ser separados em três classes: 11 Ambiente físico. 11 Ambiente de áudio. 11 Ambiente de vídeo.

q

O ambiente onde uma videoconferência é realizada possui diversos fatores que influenciam a qualidade do serviço de videoconferência. Esses fatores podem ser encaixados em três grupos: ambiente físico, ambiente de áudio e ambiente de vídeo. Quando determinados adequadamente de acordo com a sala que será usada para videoconferência, esses fatores podem definir o sucesso ou fracasso das videoconferências. Entre os fatores estão iluminação, visibilidade, acústica, mobiliário ergonômico e decoração. O projeto físico da sala envolve a identificação destes elementos, a definição de suas características e a disposição dos mesmos no espaço físico alocado. O projeto é uma etapa indispensável para criação de uma sala de videoconferência adequada, pois uma sala de videoconferência possui muitas diferenças em relação a uma sala tradicional, como, por exemplo, se compararmos uma sala de aula tradicional com uma sala de aula adequada para aulas remotas por videoconferência.

183

Capítulo 7 - Projeto de ambientes de videoconferência

Ambiente físico
Os principais fatores que devem ser considerados na realização de videoconferência que estão relacionados ao ambiente físico são: Iluminação 11 Influencia diretamente a qualidade das imagens. Recomendações: 22 Evitar fontes externas de iluminação. 22 Utilizar fontes homogêneas de luz. 22 Utilizar ambiente uniforme e pouco reflexivo. Visibilidade 11 Procure minimizar obstáculos e interferências visuais. 11 Maximize a área de exibição das imagens. Acústica 11 Observe o tratamento acústico do ambiente para minimizar os ruídos externos e internos que possam interferir no bom andamento da videoconferência. 11 Use cortina, carpete e isolamento acústico para evitar móveis muito retos que reflitam o som. Climatização 11 O ar-condicionado deve ser escolhido levando em consideração os ruídos por ele gerados, na opção mais silenciosa possível.

q

Iluminação
De nada adianta o avanço tecnológico das câmeras de vídeo nos últimos anos, se a qualidade de iluminação proporcionada no ambiente não for adequada. Para alcançar um padrão de qualidade pelo menos aceitável, é necessário tomar alguns cuidados em relação à iluminação do ambiente. Destacamos algumas recomendações: 11 Evitar fontes externas de iluminação: evite, sempre que possível, salas com janelas, de modo a neutralizar fontes externas de iluminação; não sendo possível, deve-se utilizar cortinas do tipo black-out, que eliminam essas fontes de luz; 11 Utilizar fontes homogêneas de luz: a sala deve ser iluminada de forma homogênea, utilizando-se, preferencialmente, lâmpadas fluorescentes do tipo “luz do dia”. Para assegurar a homogeneidade da iluminação, evite misturas de fontes de iluminação, como lâmpadas incandescentes e iluminação fluorescente; 11 Ter um ambiente uniforme pouco reflexivo: utilize mobiliário de cores claras para evitar sombras no rosto dos participantes; as paredes devem ser lisas, de cores uniformes e
Administração de Videoconferência

sem superfícies muito refletoras. As cores recomendadas são: cinza, azul e verde (claros), creme ou branco-gelo, com acabamento em cores foscas; 11 É aconselhável que a intensidade luminosa em uma sala de videoconferência esteja situada na faixa de 700 a 1.100 luxes (valor um pouco acima do estabelecido pela norma da ABNT para iluminação de escritórios).
Lux Medida da intensidade de luminosidade. A luminosidade de uma sala pode ser verificada com o uso de um luxímetro.

184

Figura 7.1 Exemplo de luminosidade em sala de videoconferência.

Visibilidade
A visibilidade é uma característica que leva em consideração a disposição do mobiliário ergonômico na sala de videoconferência. Por exemplo, para que todas as pessoas possam ver as imagens sem obstrução, os monitores devem ser colocados em posições adequadas, com o menor número de obstruções entre os participantes e eles. A posição adequada varia muito conforme o propósito da videoconferência (ensino à distância, reuniões remotas etc.) e conforme o formato da sala na qual ela está sendo realizada, mas os monitores normalmente são dispostos na altura da visão dos participantes. Outro cuidado é com o posicionamento da câmera, que deve ser colocada acima do monitor principal, para que seu ângulo de visão possa focalizar, na sua totalidade, tanto os participantes quanto a plateia. Entretanto, deve haver o cuidado de não colocar o monitor principal a uma altura que, ao posicionar a câmera sobre ele, cause a impressão 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 obstruções; a câmera (ou câmeras) deve estar localizada neste mesmo local, de forma a capturar os participantes e/ou palestrantes de frente, de forma que aparente que eles estão olhando para a câmera, quando na verdade estão olhando para os monitores.

Câmera
Figura 7.2 Exemplos de posicionamento dos monitores e câmeras em uma videoconferência.

A figura a seguir mostra um exemplo do estúdio do Inmetro-RS, utilizado para ministrar aulas por videoconferência. Pode-se observar o detalhe da janela de fundo, que é uma janela falsa. Com criatividade, uma TV de plasma e uma iluminação artificial, é possível simular diversos ambientes diferentes, conforme a necessidade. A figura também mostra um exemplo de ambiente mais rústico, porém com linhas suaves e onduladas. O ambiente foi projetado para permitir diversas visões pela câmera.

185

Capítulo 7 - Projeto de ambientes de videoconferência

Câmera

Figura 7.3 Exemplo de estúdio no Inmetro/RS.

Acústica
A acústica da sala é fundamental para a qualidade do áudio, aspecto primordial para uma videoconferência. O nível de pode deve ser medido através do auxílio de um decibelímetro, procurando manter uma taxa que não influencie o andamento da conversação entre os participantes da videoconferência. Além de observar o nível de ruído (que não é uma atividade tão trivial), pode-se lançar mão dos seguintes aspectos: absorção e refletividade, níveis de ruído do ambiente, efeito de reverberação (eco), tamanho da sala e sua geometria. Para diminuir os ruídos, algumas alternativas são: 11 Observar a composição dos elementos da sala, evitando o uso de materiais refletores (vidro, gesso, madeira, cerâmica) que podem influenciar na acústica e, portanto, não são recomendáveis; 11 Evitar móveis muito retos, que refletem som; 11 Utilizar cortinas; 11 Utilizar carpete; 11 Isolar a sala acusticamente. Recomenda-se que o nível de ruído máximo admissível em uma sala de videoconferência não ultrapasse 50 dB-SPL (decibel). Essa medida deve ser tomada com o ambiente vazio, todos os equipamentos ligados e com o auxílio de um medidor (decibelímetro) posicionado no centro da sala. Vale lembrar que dB-SPL é a medida do som emitido (lê-se: decibel – Sound Pressure Level).
Decibelímetro Sonômetro eletroacústico com escala de leitura em decibéis. Instrumento utilizado para medição de decibéis.

Climatização
Administração de Videoconferência

A climatização da sala deve prover condições climáticas e térmicas agradáveis aos participantes da videoconferência. Uma sala com climatização apropriada é fundamental tanto para o conforto das pessoas quanto para o bom funcionamento dos equipamentos, pois um local bem climatizado é saudável para as pessoas e prolonga a vida útil dos equipamentos. Para climatização da sala utilizando aparelhos de ar-condicionado também é muito importante considerar o nível de ruído dos aparelhos utilizados, pois aparelhos muito barulhentos podem prejudicar o andamento de uma videoconferência, como foi visto no item “Acústica”.

186

Ambiente de áudio
Qualidade do áudio: 11 É possível realizar uma videoconferência sem vídeo, mas sem áudio é inviável. Microfones podem ser de diversos tipos: 11 Unidirecionais ou multidirecionais. 11 Com fio ou sem fio. 11 De mão, de mesa, de lapela ou headset. 11 Individuais ou de grupo. Microfones com ou sem fio: 11 Com fio perde mobilidade, mas dispensa a preocupação com pilhas, sendo válido quando as pessoas estão em um ponto fixo, como uma mesa. Microfones individuais (unidirecionais) ou de grupo (omnidirecionais). A qualidade do áudio é um elemento primordial em uma videoconferência. Quando uma

q

videoconferência apresenta certas dificuldades (falhas) no vídeo, ainda assim é possível que a conferência continue em execução apenas com áudio. Se ocorrerem quaisquer falhas no áudio, porém, a conferência torna-se inviável. Ou seja, falhas de áudio incomodam e prejudicam muito mais uma conferência do que falhas de vídeo, o que mostra a importância em manter uma qualidade de áudio alta. A escolha dos microfones que serão usados é uma tarefa muito importante para buscar qualidade no áudio de uma videoconferência. Existem diversos modelos disponíveis, que devem ser escolhidos conforme o formato da videoconferência (aula, palestra, reunião etc.), a quantidade de participantes, o ambiente de videoconferência, entre outros fatores.

Tipos de microfones e suas características
Os microfones podem ser separados em diversas categorias. Podem ser individuais ou de grupos, unidirecionais ou omnidirecionais, com fio ou sem fio, microfones de mão ou de mesa, entre outros. Abaixo serão descritos os principais tipos de microfones, as suas características, vantagens e desvantagens.

Microfones de mão
modelos profissionais de alta qualidade até modelos mais simples, de menor custo. Exigem que o interlocutor fique segurando o microfone na mão, o que inibe sua liberdade. Pode-se também utilizar um suporte fixo para o microfone, o que prejudica a mobilidade do usuário. Um problema comum é que com o tempo o usuário de um microfone de mão esquece que está com ele e começa a afastá-lo ou aproximá-lo da boca, provocando alteração na intensidade do áudio captado e causando incômodo para os ouvintes (podendo até impossibilitar o entendimento do que está sendo dito).
Capítulo 7 - Projeto de ambientes de videoconferência

São os microfones mais conhecidos e por isso são facilmente encontrados no mercado, com

187

Estão disponíveis em modelos unidirecionais e ominidirecionais, com fio e sem fio. Normalmente são utilizados em salas de aula ou auditórios.

Figura 7.4 Microfone de mão preso a um suporte.

Microfones tipo headset
São os mais indicados para auditórios e salas de aula, pois deixam as mãos completamente livres e ainda mantém o microfone sempre à mesma distância da boca, eliminando o problema das mudanças de intensidade do áudio. Para auditórios e salas de aula é indicado o uso dos modelos profissionais, que são sem fio e normalmente mais discretos (inclusive sem fones de ouvido, apenas com o microfone e seu suporte). Para conferências onde cada participante está no seu computador, como webconferências, o ideal é a utilização de headsets que possuem tanto fones de ouvido quanto microfone, dispensando as caixas acústicas. Esses modelos são bastante comuns no varejo de informática, e possuem um custo extremamente acessível.

Figura 7.5 Headset (P91N Encore® Monaural Polaris).

Microfones de lapela
São modelos bastante discretos que são fixados na altura do peito. Esse modelo de microfone é bastante sensível por causa da distância que fica da boca. Normalmente são omnidirecionais para compensar os movimentos feitos com a cabeça. Essas características propiciam microfonia ou a realimentação acústica em salas com caixas de som, e, portanto, não são indicados para salas de videoconferência. Se forem utilizados, deve-se ter muito cuidado no ajuste do posicionamento e do volume das caixas de som em relação à posição do usuário do microfone. Uma característica positiva dos microfones de lapela é que eles permitem maior liberdade ao usuário e costumam ser pequenos e leves, causando menor incômodo.
Administração de Videoconferência

Figura 7.6 Microfone de lapela Sennheiser G3.

188

Microfones de mesa
Em um ambiente onde há um grupo não muito grande de pessoas ao redor de uma mesa, fazendo uma reunião por videoconferência, é possível utilizar microfones de mesa omnidirecionais. Esses microfones capturam som de todas as direções, permitindo que todas as pessoas ao redor da mesa possam falar utilizando o mesmo microfone. Esse tipo de microfone é prático para ambientes com grupos de pessoas, mas deve-se ter cuidado ao utilizá-los, pois como eles capturam o som de todas as direções, são mais suscetíveis a ruídos.

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 ruídos e sons indesejáveis. Microfones como o do exemplo abaixo podem, por exemplo, ser distribuídos 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 ruídos de forma mais eficaz que os microfones de mesa omnidirecionais. Há inclusive microfones como o do exemplo e unidirecionais, porém são mais caros e mais difíceis de encontrar.

Figura 7.8 Microfone de mesa omnidirecional Áudio Technica ATR4700.

Microfones com fio x microfones sem fio
Os microfones com fio são mais baratos e fáceis de encontrar; no entanto, existem situações em que o interlocutor precisa movimentar-se, como por exemplo um palestrante em um auditório, ou quando se deseja passar o microfone para uma das pessoas da plateia. Nestas situações um microfone sem fio elimina os problemas decorrentes do fio não ser comprido o suficiente ou do fio enroscar no mobiliário, por exemplo. Apesar do microfone sem fio ser mais versátil, é mais caro que o modelo correspondente com fio e requer a utilização de pilhas, que precisarão ser trocadas periodicamente. A autonomia das pilhas pode variar de 6 a 30 horas, dependendo do modelo. A conexão à mesa de som é feita através 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, é imprescindível que eles operem em canais de transmissão (faixa de frequência) diferentes, para que um não cause interferência no outro. A maioria dos microfones sem fio vem ajustada de fábrica para operar em determinados canais, sem possibilidade de ajuste posterior. Portanto, no ato da compra é necessário verificar se os microfones funcionam em canais diferentes. A figura a seguir mostra a comparação entre vantagens e desvantagens dos modelos de microfones com e sem fio.
Capítulo 7 - Projeto de ambientes de videoconferência

189

Com fio Vantagens 11Mais baratos. 11Fáceis de encontrar. 11A maioria funciona sem pilhas. Desvantagens 11Fios enroscam no mobiliário.

Sem fio 11Maior mobilidade.

11Mobilidade limitada.

11Mais caros.

11Demandam troca de pilhas.

11Quando as pilhas enfraquecem podem ocorrer interferências. 11Maior dificuldade de encontrar. 11Podem interferir com outros microfones sem fio (se funcionarem na mesma frequência).

Diretividade em microfones
Os microfones possuem diferentes ângulos de captação, e são classificados como: 11 Omnidirecionais: capturam sons vindos de todas as direções. 11 Direcionais: capturam melhor sons vindos da frente e rejeitam sons emitidos nos lados e atrás. Os microfones omnidirecionais captam os sons em todas as direções e são indicados em casos onde diversas pessoas vão compartilhar um mesmo microfone. No entanto deve-se

q

Figura 7.9 Comparação 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 acústicas ou outros ruídos da sala. Para reduzir a captação de sons indesejados, deve-se utilizar microfones direcionais, que possuem baixa sensibilidade para os sons vindos de trás. É importante observar que há diferentes sub-classificações 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 atrás do microfone, apesar de serem unidirecionais. Durante o uso, os microfones nunca devem ser direcionados para as caixas acústicas, mesmo que sejam unidirecionais, para que não ocorram microfonias ou reverberação. A figura abaixo mostra o posicionamento ideal de um microfone em relação às caixas acústicas.

Caixa acústica

Área de sensibilidade do microfone unidirecional

Administração de Videoconferência

Figura 7.10 Microfone com área de sensibilidade voltada para as ondas sonoras das caixas acústicas localizadas atrás 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 videoconferência, pois isso pode influenciar na qualidade do áudio gerado. Como vimos, ao abordar a acústica devemos evitar ao máximo ruídos externos e internos. As pessoas e os equipamentos utilizados (ar-condicionado, computadores, projetores, componentes de iluminação) são as principais fontes geradoras de ruídos 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 comunicação, e consequentemente podendo perturbar os participantes. Um cuidado necessário é manter ligado apenas o microfone do interlocutor ativo, o coordenador da sala responsável pela concessão da palavra aos participantes e pela orientação quanto ao uso dos microfones. Quando um microfone não está sendo utilizado, é aconselhável mantê-lo desligado, evitando ruídos desnecessários.

Microfonia
Também chamada de realimentação de áudio, é causada quando um microfone está capturando o áudio de uma fonte emissora do som do próprio microfone. Como evitar: 11 Se não estiver falando, desligue o microfone. 11 Utilizar microfones direcionais colocados estrategicamente para não receber diretamente o áudio das caixas acústicas. Em geral, a realimentação provoca um ruído agudo (alta frequência) que é amplificado a cada vez que o áudio capturado pelo microfone é emitido pelas caixas de som. A microfonia ocorre frequentemente em videoconferências quando o microfone está muito

q

próximo dos alto-falantes que estão 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 ruídos. O uso de microfones unidirecionais facilita a redução da captura de ruídos; 11 Utilização de microfones com cancelamento de eco. O cancelamento de eco pode também ser feito pelo software/hardware utilizado para videoconferência. O cancelamento de eco é um mecanismo capaz de detectar que os sons que estão sendo capturados já foram capturados/transmitidos antes (chamados de eco), sendo capaz de suprimir esses sons, isto é, removê-los do sinal como se não tivessem sido capturados, evitando a realimentação.

Caixas acústicas
11 Necessárias em ambientes com grupos de pessoas, devem ser posicionadas de preferência na frente da sala, no alto e direcionadas para o fundo da sala. Deve-se ajustar o 11 A orientação dos participantes é fundamental: 22 Evitar conversas paralelas em ambientes de videoconferência. 22 Manter microfone desligado quando não estiver falando e não apontar para a caixa de som. 11 Adequar o ganho dos microfones para evitar microfonias e eco. Os fones de ouvido são adequados para conferências pequenas ou quando houver apenas volume do som para evitar microfonias. Cuidados:

q
Capítulo 7 - Projeto de ambientes de videoconferência

uma pessoa assistindo a conferência em um determinado lugar. Em salas de videoconferência ou auditórios deve-se utilizar caixas acústicas, que requerem alguns cuidados quanto ao uso. O volume das caixas acústicas deve ser ajustado para que o áudio possua uma intensidade de uma conversação. Se o som estiver muito baixo, as pessoas mais afastadas poderão não escutar corretamente; se estiver muito alto, além do desconforto de quem estiver mais próximo, os microfones poderão captar o som e causar microfonia ou realimentação.

191

Quando a sala for grande, pode ser necessário utilizar mais caixas acústicas, para que a intensidade do áudio seja equilibrada entre as pessoas que estão sentadas mais à frente e as que estão mais no fundo.

Disposição das caixas acústicas na sala
Um aspecto que merece grande atenção é o posicionamento das caixas acústicas. Elas devem ser direcionadas da frente (onde está a tela de projeção) para o fundo da sala. Quando as caixas acústicas são fixadas nas paredes ou no teto, garante-se uma melhoria na dispersão acústica, podendo inclusive usar menos potência de áudio do que se estivessem no chão. Em ambientes em que os participantes tiverem acesso ao microfone, o cuidado deve ser maior ainda para evitar que o microfone seja levado para posições onde as caixas de som fiquem direcionadas para a frente dele.

Caixas acústicas

Caixas acústicas

Correto Projetor

Errado

Figura 7.11 Exemplo de bom posicionamento das caixas acústicas e direção do microfone.

Ambiente de vídeo
Os cuidados relacionados ao ambiente de vídeo em uma conferência são necessários tanto para a captura do vídeo (local) quanto para a exibição do(s) vídeo(s) remoto(s). A imagem transmitida deve permitir aos participantes da videoconferência observar as ações e reações dos participantes conectados remotamente. Quanto maior a qualidade das imagens, maior o realismo e, portanto, mais a videoconferência se aproximará de uma conferência onde os
Administração de Videoconferência

participantes interagem localmente. Uma vez gerada a imagem, outro ponto importante é a sua exibição. Neste aspecto, é importante observar o tamanho dos monitores (ou qualquer outro dispositivo que exibirá os vídeos) e seu posicionamento.

192

Figura 7.12 Dispositivos de exibição de vídeo.

O tamanho correto da tela do monitor é determinado pela distância entre ele e os principais participantes da videoconferência. A regra geral é que a altura do monitor seja equivalente a 1/8 da distância entre a tela e os espectadores. Normalmente pensa-se que quanto maior o monitor melhor a qualidade e a experiência que ele trará à videoconferência. Isso muitas vezes é verdade, mas deve-se ter cuidado com o uso de monitores muito grandes muito próximos aos participantes, onde seu tamanho pode acabar prejudicando a videoconferência. Em relação ao posicionamento, os monitores devem estar em um local visível a todos participantes, sem obstruções entre eles. Normalmente as câmeras são posicionadas junto aos monitores para que os participantes, ao olharem para os monitores, também estejam olhando para as câmeras, evitando a situação onde o participante parece (nos pontos remotos) não estar olhando para os participantes remotos, mas para outra posição qualquer (olhar disperso). A qualidade da imagem também é afetada pelo processo de codificação de vídeo. Além das características técnicas que envolvem o processo, há cuidados que devem ser tomados no ambiente de videoconferência para auxiliar a codificação e maximizar a qualidade do vídeo. Um desses cuidados é eliminar interferências de fundo de cena. Se um palestrante está falando, o conteúdo mais importante da cena é obviamente o palestrante, e não os objetos ao fundo. Um fundo com poucos objetos, como uma simples parede lisa, auxilia a codificação do vídeo e também evita dispersão de atenção dos participantes que estão assistindo ao vídeo. Outros cuidados são: evitar movimentos constantes ou bruscos, que também dificultam a codificação de vídeo, e escolher adequadamente as roupas utilizadas, pois, assim como um fundo com muitos objetos, há roupas que dificultam a codificação do vídeo e também
Capítulo 7 - Projeto de ambientes de videoconferência

podem distrair a audiência. Deve ser dada preferência a roupas de cores sólidas.

Projeto de sala
Fatores que devem ser considerados: 11 Natureza da sala e público-alvo. 11 Mobiliário e equipamentos. 11 Público-alvo. 11 Infraestrutura e layout.

q

O projeto de uma sala de videoconferência é na maioria dos aspectos um projeto arquitetônico, ou seja, uma tarefa destinada a arquitetos e engenheiros. A função do profissional de videoconferência é conhecer o que deve ser levado em conta nessa organização estrutural da sala e a disposição adequada dos equipamentos. Portanto, a função desta seção não é abordar todos os detalhes de como projetar uma sala de videoconferência, mas sim citar

193

os aspectos mais importantes que devem ser considerados durante o projeto com intuito de melhorar a qualidade da videoconferência. Os principais fatores que devem ser considerados são: natureza da sala, público-alvo, mobiliário, equipamentos e layout.

Natureza da sala e público alvo
11 Dedicada x Multipropósito. 11 Aplicações especiais. Público-alvo: 11 Alunos x Profissionais. 11 Crianças x Adultos.

q

Conhecer se a sala vai ser dedicada ou não, bem como a utilização dela por outras pessoas, traz mais diretivas para a sua correta concepção. Em relação à natureza da sala, deve-se saber será dedicada para videoconferências ou se será uma sala multipropósito. Uma sala dedicada facilita o projeto, já que pode ser projetada especificamente para as necessidades de uma videoconferência. Já uma sala multipropósito, ou seja, que será utilizada para outros fins além de videoconferências, traz maiores dificuldades para o projeto. Neste caso, deve-se conhecer os requisitos tanto da videoconferência quanto os do outro propósito para o qual a sala é utilizada e tentar conciliá-los. Em uma sala de aula que também será utilizada para videoconferências, por exemplo, deve-se projetar uma sala que acomode todos os equipamentos de videoconferência e também o mobiliário de uma sala de aula normal, como classes, quadro, possivelmente computadores, entre outros. Descrever a natureza da sala é especialmente importante quando ela é utilizada para aplicações especiais, onde pode haver outras exigências que não estão relacionadas com a videoconferência explicitamente. Hoje em dia, a videoconferência está sendo utilizada cada vez mais em telemedicina, por exemplo. Nesse caso, equipamentos específicos para visualização de exames médicos também são requeridos e podem compor a sala. De certa forma, a mesma relação acontece com o público-alvo, ou seja, conhecer o perfil das pessoas que vão utilizar o sistema também pode significar maior qualidade no oferecimento do serviço. Pense na diferença entre uma sala projetada para reuniões entre executivos e uma sala de aula para crianças, por exemplo.

Mobiliário e equipamentos
Mobiliário: 11 Evitar utilizar móveis muito retos e reflexivos que prejudicam a acústica. 11 Cuidar para que os móveis não fiquem na frente dos participantes.
Administração de Videoconferência

q

11 Utilizar móveis com cores sólidas, pois facilitam a compressão de vídeo. 11 Manter o ambiente “limpo”, sem muitos objetos pequenos sobre os móveis, a fim de facilitar a compressão de vídeo. Equipamentos: 11 Monitores e câmeras de vídeo. 11 Microfones e caixas de som. 11 Câmeras de documentos. O mobiliário de uma sala de videoconferência inclui, principalmente, a definição e o posicionamento das cadeiras, mesas e equipamentos necessários para a videoconferência.

194

A escolha do mobiliário é, em grande parte, apenas uma tarefa arquitetônica. Mas é importante observar os aspectos do mobiliário que influenciam as videoconferências. Recomenda-se evitar móveis muito lisos ou fabricados com materiais refletores, como vidro, gesso, madeira, cerâmica, pois refletem o som e podem prejudicar a acústica da sala.

Figura 7.13 Tipos de cadeiras.

Cadeiras para plateia em auditório

Cadeira típica para a mesa do conferencista

Destaque para cadeira com apoio

Cadeiras típicas para plateia

Figura 7.14 Tipos de mesas.

Figura 7.15 Posicionamento dos equipamentos.

195

Capítulo 7 - Projeto de ambientes de videoconferência

Sobre o posicionamento dos equipamentos, já foi comentada a importância de se manter os monitores junto às câmeras (para que os participantes estejam sempre olhando para as câmeras) e de posicionar adequadamente microfones e caixas de som para evitar microfonias. Esses são os fatores mais importantes que devem ser observados em todos os ambientes de videoconferência, mas existem outros detalhes que variam conforme o propósito da videoconferência e os equipamentos utilizados.

Figura 7.16 Exemplo de organização do ambiente.

A quantidade de pessoas que participam da videoconferência e o tamanho da sala são fatores que influenciam na escolha do mobiliário e equipamentos que serão utilizados. Em um cenário hipotético de reunião onde 10 pessoas participam em uma mesma sala, é obviamente necessário que a mesa e as cadeiras sejam suficientes para 10 pessoas, mas também é necessário que os equipamentos escolhidos sejam adequados para essa quantidade de pessoas: a câmera (ou as câmeras) 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 vídeo remoto, que influencia na escolha do posicionamento e tamanho do telão/televisão.

Infraestrutura e layout
Infraestrutura: 11 Tomadas. 11 Pontos de rede wired/wireless. 11 Velocidade da conexão/qualidade da conexão. 11 Layout (disposição dos elementos no ambiente). Em relação à infraestrutura, as necessidades em uma sala para videoconferência basicamente são: a necessidade de tomadas de energia adicionais bem localizadas (incluindo

q

tomadas sobressalentes, caso haja a necessidade de mover equipamentos); pontos de rede adicionais, novamente considerando equipamentos que podem ser movidos e também a ligação de equipamentos adicionais (como notebooks de participantes), ou então a disponi Administração de Videoconferência

bilização de redes sem fio e, principalmente, uma infraestrutura de rede com boa qualidade e uma conexão de alta velocidade com os pontos remotos. O aspecto mais importante é a qualidade e velocidade da estrutura e conexão de rede existente na sala. A qualidade da videoconferência é altamente dependente da qualidade da rede de dados. De nada adianta a utilização dos equipamentos mais avançados de videoconferência se a rede de dados não é suficientemente boa para tráfego de dados de videoconferência. Características desejadas: 11 Largura de banda um pouco acima da utilizada na videoconferência (uma videoconferência a 380 kbit/s não funcionará bem em uma rede com apenas 380 kbit/s; é aconselhável que a rede seja pelo menos 20% mais veloz para acomodar as flutuações comuns no tráfego multimídia);

196

11 Baixa variação no atraso dos pacotes (jitter); 11 Estabilidade e confiabilidade, isto é, uma rede que funcione sem interrupções; 11 Se possível, que seja uma rede dedicada para a videoconferência, evitando que picos de tráfegos concorrentes prejudiquem a qualidade da videoconferência.

Preparação de uma videoconferência
É tarefa do administrador de videoconferência: 11 Realizar toda a preparação necessária para a videoconferência. 11 Instruir os participantes sobre como devem se comportar. 11 Gerar as orientações para conduzir uma videoconferência. Quatro etapas são importantes na preparação da videoconferência: 11 Pré-conferência. 11 Agendamento. 11 Início e término. 11 Gerenciamento.

q

Os procedimentos de operação de uma sala de videoconferência são orientações para a condução do processo. É importante para o profissional de videoconferência passar esse tipo de informação para seus clientes através de conversas ou manuais e contratos, caso necessário. A maioria das pessoas que não possuem experiência com videoconferências (e muitas vezes até mesmo pessoas já com experiência) tendem a se comportar de forma inadequada ao participar de uma videoconferência. Por vezes, os participantes esquecem que não estão na mesma sala dos participantes remotos, e com isso não prestam atenção na forma como falam ao microfone ou ao posicionamento diante da câmera. Por outro lado, os participantes podem acabar ignorando a presença 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. Videoconferências necessitam de cuidados especiais para que a comunicação ocorra de forma efetiva. É tarefa do administrador da videoconferência instruir os participantes sobre como devem se comportar e realizar toda a preparação para que a videoconferência aconteça de forma satisfatória.

Pré-conferência
Etapa que antecede a videoconferência, 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 sessão (caso exista) e informações de controle de acesso. É preciso identificar as condições para a realização da videoconferência, e prever a disponibilidade de banda de cada participante. Nessa etapa todas as informações relativas à videoconferência são definidas e descritas.

q

Etapa que antecede a videoconferência, em que deve ser configurado e preparado o sistema que será utilizado. É nessa etapa que todas as informações relativas à videoconferência são definidas e descritas, para que, a partir deste momento, a videoconferência possa ser facilmente agendada e realizada.

197

Capítulo 7 - Projeto de ambientes de videoconferência

Agendamento
Muito importante em videoconferências para permitir que haja tempo suficiente para preparação do ambiente de videoconferência. É possível: 11 Definir data e horário. 11 Prever a disponibilidade das localidades e dos equipamentos. 11 Definir a equipe de operação. 11 Usar sistemas de agendamento via web. Assim como uma reunião, aula e atividades similares, uma videoconferência precisa ser agendada. O agendamento é ainda mais importante em uma videoconferência do que em atividades presenciais, para que haja tempo suficiente para preparação do ambiente

q

de videoconferência. Além da definição de data e hora, no agendamento o usuário define (ou toma conhecimento) das condições para a realização da videoconferência. Entre os aspectos importantes no agendamento, estão: 11 Definir a equipe de operação, se necessária; 11 Prever a disponibilidade da localidade e dos equipamentos (equipamentos da própria sala de videoconferência 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 necessárias para o agendamento, inclusive notificam os participantes sobre a videoconferência.

Início e término da videoconferência
Início da videoconferência: 11 Marcada pela data e horário definidos na pré-conferência e aberta assim que a conexão está estabelecida e o primeiro participante entra na sala. Término da videoconferência: 11 Demarcado pela saída do último participante da sala (virtual ou real) ou então quando o tempo previsto se esgotar. 11 Quando um participante abandona uma sala, os demais participantes devem ser notificados da sua saída. O período entre o início e o término da videoconferência é obviamente o período crítico

q

durante o qual ocorre a videoconferência. A videoconferência só ocorrerá de forma devida se os processos durante a pré-conferência foram realizados de forma correta. O início da videoconferência é marcado pela data e horário definidos, e ela é aberta assim que a conexão se estabelece e o primeiro participante entra na sala.
Administração de Videoconferência

O término da videoconferência é demarcado pela saída 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 saída.

Gerenciamento
Tarefa do administrador da videoconferência 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.

q

198

11 Mudar o layout de vídeo. 11 Excluir participantes. O gerenciamento da videoconferência é feito pelo administrador ou por um participante eleito como coordenador/moderador da sessão.

q

Etiqueta e boas práticas
Ao preparar um ambiente para uma videoconferência é importante adotar e evitar alguns procedimentos de boas práticas. Em ambiente de videoconferência, adote:

q

11 Se você é moderador, chegue mais cedo para testar a configuração do sistema, evitando perda de tempo durante o período destinado à conferência. 11 É importante falar um de cada vez, para não interromper os outros e não mudar o foco da tela. 11 Desative o microfone quando não estiver falando, para evitar mudanças de tela desnecessárias e impedir a captação de ruídos indesejados. 11 Fale com voz alta e clara. 11 Espere o dobro do tempo habitual após perguntas e comentários, a fim de dar tempo para que sua fala chegue aos alunos. 11 Repita comentários, se necessário. 11 Mantenha uma posição apropriada diante da câmera. 11 Mantenha o contato visual com a lente da câmera e, caso existam, com os participantes locais. 11 Lembre-se de que os participantes remotos estão lhe vendo e preste atenção em como todos irão vê-lo. Coloque os participantes dentro do campo de visão da câmera. 11 Vista roupas de preferências de cores sólidas ou padrões escuros ou neutros. 11 Tenha em mente que sua audiência deve ter o foco em você e não na sua roupa. 11 Prefira usar roupas, maquiagem e cabelos do modo mais simples possível. No máximo tenha em mãos um pó translúcido para tirar o brilho do nariz e das têmporas. A melhor opção é por um visual natural e relaxado.

199

Capítulo 7 - Projeto de ambientes de videoconferência

(b)

(a)

Figura 7.17 Adote fundos lisos, para evitar distrações e colaborar com a codificação.

Em aulas remotas, adote: 11 O professor deve dirigir-se aos participantes remotos pelo nome e lugar onde estão; para tanto, é indicado preparar uma lista e um mapa dos assentos. 11 Comece as aulas com uma introdução informal, falando com todos os alunos de modo a iniciar o teste do áudio deles e o seu próprio. 11 O professor precisa se posicionar “para” a câmera, buscando estar sempre bem iluminado e enquadrado, nunca “caindo” da tela nem cortando partes de seu corpo, exatamente como na televisão. Em ambiente de videoconferência, evite: 11 Uma vez que tudo esteja pronto, evite a distração de fazer ajustes e perturbar os outros com perguntas do tipo: “Você está me ouvindo?” 11 Vozes que interrompem bruscamente são desagradáveis. 11 Produzir barulho que possa perturbar a reunião (conversas paralelas, barulho com dedos, canetas etc.), pois a câmera e os microfones são muito sensíveis e capazes de captar os sons mais sutis.
Administração de Videoconferência

11 Diminuir o volume da voz no final da fala. 11 Começar a falar antes de ser focalizado pela câmera. 11 Erros gramaticais, gírias e vícios de linguagem. 11 Usar jargão técnico quando o assunto não for do escopo da reunião (plateia não especializada ou público leigo). 11 Falar sem uma preparação prévia. 11 Falar muito depressa ou muito devagar. 11 Movimentos rápidos e/ou largos que causem distorção na tela. Evite movimentação desnecessária para preservar a qualidade da imagem.

200

11 Expressões faciais inadequadas. Use o zoom, mas não se aproxime demais da câmera. 11 Ficar estático 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 padrões muito pequenos. 11 Usar joias, colares ou braceletes grandes, pois podem bater no microfone e causar ruídos estranhos. 11 Distrações visuais como maquiagem inapropriada, fundos carregados, padrões complicados ou cores fortes. Evite o vermelho, cores brilhantes ou saturadas. 11 Microfones de lapela não são indicados com suéteres e camisetas.

Estudo de caso 1: Auditório
Neste estudo de caso e nos posteriores, serão dadas sugestões sobre como deve ser um ambiente de videoconferência em relação aos seguintes aspectos: 11 Natureza da sala: número de pessoas e propósito de utilização. 11 Público-alvo. 11 Mobiliário: mobília ergonômica. 11 Equipamentos: de áudio, vídeo, videoconferência e adicionais. 11 Layout: área e disposição. No primeiro estudo de caso, serão apresentadas sugestões sobre como deve ser um auditório no qual palestras e aulas serão transmitidas por videoconferência. A seguir são abordados brevemente estes aspectos, e mais adiante serão detalhados alguns pontos importantes. 11 Natureza da sala: 60 pessoas, uso para videoconferências. 11 Público-alvo: especialistas. 11 Mobiliário: mesas e cadeiras ergonômicas apropriadas. 11 Equipamentos: 22 Áudio: microfone unidirecional no palestrante (pode ser de lapela) e outro sem fio para perguntas.
Capítulo 7 - Projeto de ambientes de videoconferência

22 Vídeo: projetores. 22 Videoconferência: hardware específico para sala ligado na mesa de som e compatível com a conectividade disponível. 22 Adicionais: câmeras auxiliares para troca de imagem (sistema de videoconferência deve permitir múltiplas câmeras). 11 Layout: área: ~ 120 m ²

Figura 7.18 Auditório para videoconferência.

201

O ambiente deve apresentar paredes dotadas de materiais isoladores acústicos, com o objetivo de minimizar a influência de ruídos 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 antireverberação (placas de espuma acústica perfilada) e cortinas de tecido denso nas janelas. A área da sala deve respeitar os critérios de acesso e proximidade. Geralmente é estimada em um metro quadrado por ocupante da sala. A refrigeração da sala deve ser adequada, possibilitando um controle de umidade e constante renovação do ar. Também é necessário que existam tomadas e pontos de rede suficientes, e, se necessário, 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 projeção pode-se utilizar uma iluminação indireta para melhorar a visualização da videoconferência. As luminárias deverão ser do tipo embutidas, em forro modular feito de placas de fibra mineral com propriedades térmicas e acústicas. O auditório deve possuir um microfone unidirecional para cada apresentador da mesa e do púlpito, além de dois microfones multidirecionais estrategicamente localizados no início das filas de cadeiras (plateia) e ao fundo do auditório. Opcionalmente, podemos ter alguns microfones sem fio disponíveis 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 realimentações que provoquem microfonias. Monitor principal fixado ao teto 38” PC de apoio Monitor de retorno fixado ao teto 38”

Câmera de documentos Mesa de áudio e vídeo Principal aparelho de videoconferência Púlpito Telefone/Fax

Quadro Tela elétrica de projeção

Projetor multimídia

Degraus

Administração de Videoconferência

Monitor de retorno fixado ao teto 38”

Câmera auxiliar

Monitor principal fixado ao teto 38”

Figura 7.19 Exemplo da planta de um auditório para videoconferência.

202

Estudo de caso 2: Sala de reunião
No segundo estudo de caso, será avaliado um ambiente para salas de reuniões com videoconferência. 11 Natureza da sala: máximo de 10 pessoas; sala de aula/multipropósito. 11 Público-alvo: empresarial com diferentes perfis de pessoas. 11 Mobiliário: mesas e cadeiras apropriadas (verificar questões de acessibilidade, já que perfis diferentes usarão a sala). 11 Equipamentos: 22 Áudio: um microfone multidirecional; 22 Vídeo: TV de 32” ou projetor; 22 Videoconferência: hardware específico compatível com conectividade disponível; 22 Adicionais: quadro branco eletrônico e recurso para compartilhar dados do notebook. 11 Layout: área: ~ 28 m ²

Figura 7.20 Imagem de exemplo de uma sala de reuniões com videoconferência.

203

Capítulo 7 - Projeto de ambientes de videoconferência

Quadro interativo

TV

Tela para projeção

Tablado Equipamento de videoconferência

Projetor

Câmera de documentos

Estudo de caso 3: Uso geral
O terceiro estudo de caso aborda uma sala de propósito geral, onde podem ser realizadas videoconferências para reuniões, aulas e palestras, entre outros. 11 Natureza da sala: 20 a 35 pessoas (sala de aula/multipropósito). 11 Público-alvo: estudantes, profissionais etc. 11 Mobiliário: mesas e cadeiras apropriadas. 11 Equipamentos: 22 Áudio: dois ou vários multidirecionais; 22 Vídeo: TV de 42” ou projetor;
Administração de Videoconferência

Figura 7.21 Esboço da planta de uma sala de reuniões com videoconferência.

22 Videoconferência: hardware específico compatível com a conectividade disponível; 22 Adicionais: câmera auxiliar, computador, câmera de documentos.

204

11 Layout: área: ~ 54 m ².

Figura 7.22 Sala de videoconferência de propósito geral.

Tela elétrica de projeção TV 54” Equipamento de videoconferência PC Câmera de documentos Telefone/Fax

Quadro branco

Tablado com 10 cm

Projetor multimídia

Cadeira com apoio para escrita

Circulação

Parede ou divisória acústica

Figura 7.23 Esboço da planta de uma sala de videoconferência de propósito geral.

Piso com elevação de 0,5 cm

Cortina

Janela

Estudo de caso 4: Projeto da sala da ESR-RS
Este estudo de caso mostra o projeto de adaptação da sala de aula da ESR em Porto Alegre, que originalmente era uma sala de aula padrão da ESR e foi transformada em uma sala de videoconferência para transmissão 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 Distribuídas.

205

Capítulo 7 - Projeto de ambientes de videoconferência

O projeto considerou diversos fatores, entre eles: 11 Adequação estética geral; 11 Organização do espaço; 11 Ajuste cênico para vídeo; 11 Iluminação; 11 Acústica; 11 Planos de câmera/operação; 11 Sonorização. A sala de aula original possuía diversas características prejudiciais à videoconferência, entre elas: 11 Sala branca de perfil frio; 11 Área de trabalho dos alunos sem otimização de espaço; 11 Paleta: branco, preto e creme; 11 Iluminação fria (lâmpadas fluorescentes) e plana; 11 Grande janela à esquerda com cortina blackout; 11 Painéis de Eucatex com perfis aparentes (desalinhados); 11 Pé direito baixo.

Figura 7.24 Mesas e máquinas dos alunos e janela com cortina blackout.

206

Administração de Videoconferência

Figura 7.25 Entrada da sala de aula mostrando um pedaço do quadro branco e divisória.

A proposta geral de modificações da sala tem como principais mudanças: 11 Inverte posição da sala (porta passa a ficar no fundo da sala); 11 Frente ganha pintura dégradé, em tons mais vivos; 11 Troca dos aparelhos de ar-condicionado por modelos mais silenciosos; 11 Parte do teto é mantida branca, para reduzir a sensação de teto baixo; 11 Paredes e parte do teto com isolamento acústico. É recomendado deslocar os computadores para baixo da mesa e trocar para monitores maiores, de preferência com ajuste de altura.

Figura 7.26 Proposta geral para reforma da sala.

Na sequência serão descritos separadamente os itens mais importantes do projeto.

Acústica
Antes: 11 Áreas reflexivas em todas as paredes. 11 Nenhum trabalho de correção acústica (mesmo cortina blackout tem perfil reflexivo). 11 Características de “ambiência” (soma de todos os sons nesse ambiente) são desfavoráveis para o sistema. 11 Ar-condicionado com ruído excessivo.

q

207

Capítulo 7 - Projeto de ambientes de videoconferência

Depois: 11 Troca dos aparelhos de ar-condicionado. 11 Painéis Sonare (Isover) passam a revestir as paredes, lateral direita e fundo. 11 Teto revestido com isolamento acústico e térmico (sobre o forro). Resultados: 11 Redução imediata da reflexão em duas paredes (supressão da reverberação). 11 Melhora da ambiência. 11 Melhorias no isolamento acústico e térmico. 11 Ganhos nos resultados acústicos (redução da reflexão nas frequências mais altas gera som mais encorpado, com agudos mais limpos). 11 Melhorias estéticas no ambiente.

q

Figura 7.27 Painéis nas paredes melhoram a acústica da sala.

Planos de câmera/operação
11 Ambiente de operação – à frente e à esquerda, concentrando as máquinas necessárias para o sistema de videoconferência. 11 Telepresença – televisões posicionadas ao lado do professor ou no fundo da sala.

Administração de Videoconferência

Câmera robotizada 1
11 Principal foco é no apresentador e sua área de trabalho. 11 Enquadramento tem bom acesso à visualização da área frontal. 11 Fácil acesso à visualização do quadro branco e da lousa eletrônica. 11 Posicionamento permite bom alcance de zoom. 11 Ângulo da câmera permite captar quadro branco sem incidência de reflexos.

q

Figura 7.28 Ambiente de operação do sistema de videoconferência e televisões para telepresença.

208

Figura 7.29 Primeira câmera robotizada com foco no professor e no quadro branco.

Câmera robotizada 2
11 Posicionamento voltado aos alunos. 11 Foco secundário no apresentador, podendo funcionar como câmera de apoio, quando o apresentador está no meio da sala, por exemplo. 11 Fácil visualização de todo o ambiente presencial (alunos). 11 Uso das 6 posições de preset permite fácil enquadramento de qualquer grupo de alunos, pressionando uma única tecla.

q

Figura 7.30 Segunda câmera robotizada com foco nos alunos.

Sonorização
11 Combinação de microfones sem fio (headset e de mão). 11 Mesa de som. 11 Caixas acústicas: 22 Cobertura dos sinais de entrada. 22 Reprodução de sinais remotos aos participantes presenciais.

q

ticas, faz cobertura dos sinais de entrada e reprodução de sinais remotos aos participantes presenciais. Microfone sem fio para o professor e de mão para os alunos.

Figura 7.31 Microfones e posicionamento das caixas acústicas.

209

Capítulo 7 - Projeto de ambientes de videoconferência

A combinação de microfones sem fio (headset e de mão) com mesa de som e caixas acús-

Imagens da sala nova
A visão frontal da sala pode ser vista a seguir.

Figura 7.32 Mobiliário (posicionamento dos equipamentos).

A imagem a seguir mostra a visão do fundo, com as TVs, o novo ar-condicionado e o posicionamento da câmera.

210

Administração de Videoconferência

Figura 7.33 Visão do fundo da sala.

Roteiro de Atividades 7
Atividade 1 – Análise de cenários e elaboração do projeto das salas
Esta atividade consiste na análise de diferentes cenários onde é necessário o uso de videoconferência e na elaboração de projetos de salas que possam ser utilizadas nos ambientes apresentados em cada cenário. Serão apresentados 3 cenários.

Cenário 1
Uma empresa multinacional está implantando um sistema de videoconferência para auxiliar na tomada de decisões entre gerentes e funcionários de suas unidades. São realizadas aproximadamente 10 reuniões semanais entre os gerentes das 3 unidades e entre gerentes com seus coordenadores. As reuniões contam com aproximadamente 2 pessoas de cada unidade, num máximo de 6 pessoas por reunião. Um dos requisitos da empresa é efetuar a integração de documentos não digitais; outro requisito é a possibilidade de enviar apresentações de slides em formato digital.

Cenário 2
Uma escola particular está instalando um serviço inédito para promover o compartilhamento de conhecimento. O convênio assinado pela escola com uma comunidade carente da periferia prevê uma sala de videoconferência como meio de inclusão digital. As crianças da comunidade terão acesso a aulas, palestras e atividades de entretenimento com as crianças da escola. A ideia é compartilhar conhecimento e experiências entre crianças com idade entre 6 e 9 anos.

Cenário 3
Uma escola deseja reformar uma sala de aula convencional para abrigar equipamentos de um sistema de videoconferência. A sala possui um projetor multimídia, 50 cadeiras com apoio, uma TV de 29 polegadas e janelas laterais, estando localizada no lado de maior circulação da escola. Possui cabeamento e ar-condicionado, já tendo sido utilizada para abrigar um laboratório de informática. A escola atende ao ensino fundamental e deve disponibilizar o serviço de videoconferência para todos os alunos, com agendamento prévio.

Cenário 4
Um grande hospital-escola na área de cirurgia tem como objetivo trocar informações com dois outros hospitais parceiros. Os três hospitais possuem residência médica. Existem duas necessidades principais:
Capítulo 7 - Roteiro de Atividades

11 Um médico especialista transmitir sua cirurgia em alta definição para os outros hospitais (incluindo áudio) para que médicos e alunos remotos possam aprender sua técnica. Nesse caso, há a necessidade de interação com áudio e vídeo em tempo real; 11 Possibilitar que um preceptor especialista em qualquer um dos hospitais possa orientar um cirurgião residente remotamente; para isso ele deve ter acesso completo a três câmeras de alta definição no mínimo (videolaparoscópio, corpo do paciente e ambiente da sala cirúrgica). Além disso, ele deve transmitir sua imagem. Os hospitais estão locali-

211

zados em diferentes estados do país, embora ligados através de um backbone de redes que permite velocidades de até 100Mbit/s.

Cenário 5
Um grupo de médicos 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 escritórios de forma simples, em reuniões que consistem basicamente da transmissão de vídeo e áudio de todos, compartilhamento de bloco de notas e apresentação de slides e vídeos.

212

Administração de Videoconferência

8
Transmissão via streaming
objetivos
Oferecer ao aluno uma visão ampla sobre os conceitos e tecnologias empregados para streaming e gravação de videoconferência.

conceitos

Streaming de vídeo versus download progressivo, soluções de transmissão e gravação de videoconferência, banda na rede ocupada de acordo com o número de usuários, necessidade de armazenamento de acordo com a qualidade da gravação.

Streaming de vídeo
11 Streaming é uma forma de transmissão de dados multimídia, em que os clientes realizam uma solicitação dos dados para um servidor de streaming, e os dados são exibidos à medida que são recebidos. Pode ser aplicado para transmissões ao vivo ou para mídias gravadas. Transmissões de televisão e rádio são exemplos de transmissões de mídia por streaming broadcast. A combinação do streaming com videoconferência pode ser feita para: 11 Disponibilizar a videoconferência para um maior número de pessoas. 11 Transmitir a videoconferência após ela ter acontecido, a partir de gravação. 11 Visualizar uma videoconferência a partir do desktop utilizando players padrão como Windows Media, QuickTime ou navegador web. 11 Facilitar a gravação: um dispositivo (ou software) recebe a videoconferência por streaming e realiza a gravação. A grande desvantagem do streaming em videoconferências é a interação, pois um participante por streaming não pode interagir ao vivo na videoconferência, porque a entrega participação desses clientes por salas de chat ou por e-mail, por exemplo. das mídias ocorre em apenas uma via. É possível amenizar o problema permitindo a

q

Transmissões por streaming são normalmente associadas a transmissões ao vivo, onde não há possibilidade de pausar o vídeo e continuar assistindo-o do ponto onde foi pausado. Porém, também pode ser utilizado para transmissão de mídias já gravadas. Uma pausa em uma transmissão por streaming faz com que o servidor pare de transmitir dados para o cliente, o contrário do que acontece com transmissões utilizando download progressivo, conforme será visto adiante. Outra característica importante do streaming é que ele permite a adaptação da dinâmica da qualidade da transmissão conforme a capacidade dos clientes. Ou seja, se um cliente está recebendo vídeo com uma qualidade alta, por exemplo, e começa a acusar perda de dados

213

Capítulo 8 - Transmissão via streaming

na transmissão, a própria transmissão detecta essas perdas e faz com que a qualidade do vídeo seja reduzida para evitar as perdas. Para isso, o servidor obviamente deve suportar a adaptação dinâmica da qualidade. Transmissões de televisão e rádio são exemplos de transmissões de mídia por streaming (e broadcast). A combinação do streaming com videoconferência pode ser realizada para diversos propósitos. O principal propósito é disponibilizar a videoconferência para um maior número de pessoas. Transmissões por streaming são naturalmente mais escaláveis do que os próprios sistemas de videoconferência, ou seja, é mais otimizado que diversos clientes recebam a videoconferência por streaming do que permitir que se conectem diretamente ao sistema de videoconferência. Além disso, transmissões por streaming utilizam protocolos padrão, e podem ser visualizadas em diversos aplicativos (players de vídeo), como Real, Windows Media, QuickTime ou mesmo o navegador web. O streaming também pode ser utilizado para transmitir a videoconferência após sua ocorrência (a partir de uma gravação) ou até mesmo para facilitar a gravação: um dispositivo recebe a videoconferência por streaming e realiza a gravação. Streaming pode aumentar a utilidade de uma videoconferência, se a audiência da reunião for maior que o número de conexões simultâneas suportadas pelo sistema utilizado. Nesse caso, participam interativamente apenas as pessoas principais da videoconferência; os demais podem acompanhar a reunião recebendo o fluxo de mídias em um player. A grande desvantagem do streaming em videoconferências é em relação à interação entre os participantes. Um participante por streaming não pode interagir ao vivo na videoconferência, pois a entrega das mídias ocorre em apenas uma via (só recebe dados, sem enviar). É possível amenizar este problema permitindo a participação 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 espaço em disco? 11 Qual permite analisar novamente partes já assistidas? 11 Qual possui a melhor qualidade de áudio e vídeo?

q

Streaming e download progressivo são duas formas utilizadas para transferência de áudio e vídeo. O download progressivo é uma forma de transmissão que se assemelha a um download tradicional, porém os dados de áudio e vídeo são transferidos progressivamente para o computador, permitindo que se possa visualizar o conteúdo já recebido mesmo que ainda não tenha recebido todos os dados. Apesar de diferentes, o download progressivo e o streaming possuem muito em comum.
Administração de Videoconferência

As particularidades das aplicações do cliente também influenciam na diferenciação entre streaming e download progressivo. Uma aplicação de streaming pode, por exemplo, armazenar o vídeo e permitir que o usuário 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 vídeo temporariamente no cliente Não* (mas o software cliente pode armazenar) Não** (solicita de novo o streaming ao servidor via outro ponto do vídeo) Sim Sim Sim Não Sim Não Não Não Sim Não Sim Download progressivo Sim

Permite voltar para determinado ponto do vídeo

Pausa e interrompe a transmissão 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 conteúdo multimídia. As diferenças entre eles já foram discutidas. Os principais aspectos que devem ser considerados na escolha da tecnologia mais adequada estão na tabela seguinte. Característica Transmissão ao vivo
Figura 8.2 Principais aspectos do unicast e multicast.

Unicast √ √

Multicast √

Transmissão sob demanda Permite escalabilidade (banda requerida se mantém com o número de usuários)

Soluções para transmissão e gravação
Existem soluções em hardware e em software. Soluções em hardware costumam ser específicas para videoconferência. Já soluções baseadas em software são mais genéricas, pois são soluções para streaming e gravação de dados multimídia. As soluções em hardware incluem uma interface H.323/SIP para interagir diretamente com a

q

videoconferência e outras interfaces para servir os dados por streaming. O dispositivo funciona removendo o vídeo e o áudio do pacote H.323/SIP, e os empacotando novamente no formato streaming configurado, como QuickTime, Real ou Windows Media. Esses dados são enviados
Capítulo 8 - Transmissão via streaming

aos usuários que solicitam uma transmissão streaming, utilizando unicast ou multicast. Alguns dispositivos podem também gravar esses dados, podendo depois fornecer acesso sob demanda ao conteúdo. Além disso, alguns modelos suportam inclusive a transmissão e gravação de mais de uma sessão de videoconferência ao mesmo tempo. As soluções em hardware são referenciadas também como all-in-one devices ou VideoConference Recorder (VCR). Há diversos dispositivos em hardware disponíveis no mercado para streaming e/ou gravação de videoconferências. Abaixo são citados alguns modelos, mas o ideal é conferir com os fabricantes os últimos lançamentos.

215

Modelos que suportam apenas transmissão de videoconferência: 11 MCUs – VCON VCB, Codian (séries 4200 e 4500); 11 Endpoints – Polycom VSX, Tandberg 880 e 990 MXP (somente multicast).

Figura 8.3 Modelos em hardware que suportam apenas transmissão de videoconferência.

Modelos que suportam transmissão e gravação: 11 Starbak VCG Creation / Starbak Encoder; 11 MCU Codian MSE8000; 11 Codian VCR série 2200; 11 Tandberg Content Server.

Figura 8.4 Modelos em hardware que suportam transmissão e gravação de videoconferência.

Há empresas que disponibilizam dispositivos de transmissão e gravação juntamente com um conjunto mais completo de equipamentos, fornecendo uma solução completa para videoconferência. Um exemplo é a família de produtos Integrated Network Video (INV) da Starbak. O objetivo dos equipamentos é integrar de forma fácil os diversos sistemas multimídia que uma instituição pode ter: videoconferência, streaming, televisão por IP, entre outros. Já as soluções baseadas em software normalmente são mais genéricas, voltadas para streaming e gravação de dados multimídia em geral, podendo também ser utilizadas para os dados de uma videoconferência.
Administração de Videoconferência

Soluções baseadas em software
No lugar de um dispositivo de hardware dedicado, é utilizada uma aplicação que pode ser instalada em um computador desktop tradicional. O desempenho da aplicação fica, obviamente, dependente do desempenho da máquina na qual está instalada. Essas soluções normalmente são compostas por dois softwares distintos utilizados em conjunto: 11 Encoder: entidade que captura os dados, codifica e os envia para o servidor. 11 Servidor: responsável pela distribuição e gravação dos dados que recebe do encoder.

q

216

Soluções híbridas (solução em software que recebe sinal de um HW de videoconferência): 11 Necessidade de alguma forma de conexão do software à videoconferência. 22 A saída de A/V de um terminal de videoconferência pode ser conectada a uma entrada da máquina onde a solução está instalada (como se fosse uma câmera de vídeo) A visualização do fluxo de mídias pelos usuários é realizada através de um player padrão compatível com o protocolo de streaming utilizado. Players como Windows Media Player e

q

VideoLAN (VLC) suportam e podem exibir diversos formatos de streaming. Além do streaming, na maioria dos softwares o conteúdo também pode ser gravado e disponibilizado para acesso sob demanda. Exemplos de soluções 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 também soluções híbridas, onde é desejável transmitir via software uma videoconferência H.323 executada em hardware. Como está sendo utilizada uma máquina convencional para a instalação do software, normalmente não há uma interface H.323/SIP pronta para receber os dados de uma videoconferência e repassá-los para a aplicação. Portanto, é necessário fazer com que, de alguma forma, os dados de uma videoconferência cheguem até a aplicação para streaming e gravação. Com a existência de um dispositivo de videoconferência, sua saída de áudio e vídeo pode ser conectada a uma entrada da máquina onde a solução está instalada (a uma placa de
Figura 8.5 Integração de servidores de streaming em uma videoconferência.

captura, por exemplo, como se fosse uma câmera de vídeo). Com isso é possível 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 videoconferência:

Endpoint

Servidor

1. Conecta-se a saída auxiliar do terminal na máquina onde está o codificador

Codificador

2. O codificador é configurado para enviar os dados codificados para o servidor

Usuário assistindo à sessão a partir de um player

217

Capítulo 8 - Transmissão via streaming

3. Usuários acessam a transmissão através de uma URL

Conforme a imagem, o codificador é conectado diretamente a um equipamento que está participando da videoconferência. Normalmente os equipamentos possuem uma saída auxiliar que pode ser utilizada para conectá-lo a uma máquina que possuam uma placa de captura. Este codificador é então integrado ao servidor que disponibilizará o vídeo por streaming para os clientes.

Requisitos principais para streaming e gravação
11 Streaming: processamento, memória e principalmente largura de banda. 11 Memória: quanto maior, maior a capacidade do servidor (mais usuários); atualmente já não é um grande problema. Largura de banda: 11 Banda de saída do servidor de streaming varia conforme a taxa de transmissão da conferência e quantidade de clientes. 11 Taxa de transmissão * número de clientes = banda de saída necessária. Para streaming, os principais requisitos são: capacidade de processamento, memória e

q

largura de banda. Capacidade de processamento é necessária, obviamente, para a tarefa de servir diversos clientes que estão recebendo o streaming. Esta tarefa, porém, não é a que requer maior capacidade de processamento. O que realmente requer processamento é a conversão de formatos de áudio e vídeo (recodificação) para adaptar os fluxos conforme os clientes receptores dos dados. O problema de processamento não costuma existir em dispositivos em hardware, pois já vêm prontos para a tarefa. Mas em sistemas em software é necessário ter cuidado com a máquina na qual o sistema será instalado, para que ela tenha capacidade suficiente para processar os dados se for necessária a recodificação dos fluxos. Outro requisito necessário para streaming é memória. Quanto mais memória disponível, mais clientes o servidor de streaming pode suportar. Atualmente, devido aos preços baixos das memórias e à qualidade das aplicações de streaming, memória já não é um problema grave. Porém, pode se tornar um problema quando se entra na casa dos milhares de clientes simultâneos. O requisito mais importante é a largura de banda de saída, que define mais diretamente o número máximo de clientes que podem receber o streaming. A banda necessária varia conforme a taxa de transmissão da conferência e a quantidade de clientes que se deseja atender. O cálculo é simples: taxa de transmissão * número de clientes = banda de saída necessária. Quantidade de receptores 3
Administração de Videoconferência

Taxa de transmissão / Qualidade 300 kbps 1 Mbps 5 Mbps

Largura de banda necessária 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

300 kbps 1 Mbps 5 Mbps

218

Figura 8.6 Exemplos de largura de banda necessária para streaming.

1.000

300 kbps 1 Mbps 5 Mbps

300 Mbps 1 Gbps 5 Gbps

É importante observar que a grande maioria dos codificadores de vídeo codifica o vídeo em taxas variáveis – Variable Bit Rate (VBR). Em função disso, a banda ideal normalmente deve ser maior do que a banda média das transmissões, para suportar os momentos de pico. É aconselhável manter uma “banda de segurança” 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 gravação, o requisito mais importante é a capacidade de armazenamento. O tamanho de um arquivo de mídia é dado por: ( X kbps * S segundos) / (8 * 1024) = Y MB Onde: 11 X = taxa de codificação em bits por segundo; 11 S = tamanho do fluxo de mídias em segundos; 11 Y = tamanho total aproximado do arquivo em megabytes. Taxa de transmissão 37 kbps 50 kbps 100 kbps
Figura 8.7 Exemplos de espaço requerido para o armazenamento de arquivos de mídia.

Tempo de conteúdo (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

300 kbps 1 Mbps 4 Mbps

Vale ressaltar que antes de tomar uma decisão de gravar tudo em baixa qualidade, se pense cuidadosamente no futuro daquele conteúdo. Um conteúdo em alta qualidade sempre pode ser transmitido em menor qualidade, entretanto, um conteúdo em baixa qualidade ficará para sempre em baixa qualidade.
Capítulo 8 - Transmissão via streaming

Servidores de streaming em software
Possuem duas aplicações 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 versão open source: Helix DNA Server).

q

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 é possível utilizar múltiplos servidores para melhorar o desempenho. Quanto à visualização do streaming, soluções costumam prover um player padrão: 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 também suportam serem servidores de vídeo sob demanda (VOD). Neste caso, não é necessário um codificador, pois os vídeos que serão disponibilizados são colocados em um diretório 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 soluções de streaming não são compostas por apenas um software, mas pelo

q

menos por dois para geração do conteúdo e streaming, e um para visualização. As duas aplicações para geração do conteúdo têm funções semelhantes em todas as soluções. São elas: 11 Codificador: entidade que faz a captura (seja de uma câmera, de arquivos ou outra fonte) e codificação dos dados. Chamado Encoder na maioria dos sistemas; 11 Servidor : recebe os dados do codificador e é responsável pela sua distribuição, ou seja, o streaming dos dados. Codificadores e servidores nas soluções 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.
Administração de Videoconferência

Essas soluções são comerciais (pagas). Mas é importante citar que existem versões de código aberto e livres para as soluções Helix e Flash. A versão open source do Helix é chamada Helix DNA Server (a versão comercial é também conhecida por Helix Universal Server). Ela possui menos funcionalidades e suporta menos formatos do que a versão comercial, mas ainda assim possui as diversas funcionalidades básicas necessárias para o streaming. Em relação ao Flash, há uma versão open source chamada Red5, que não é 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 aplicação open source equivalente ao QuickTime é chamada de Darwin Streaming Server. Desenvolvida pela Apple, seu código foi criado com base no QuickTime Streaming Server.

220

Outra observação importante sobre as soluções é que algumas são 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 versões open source, porém, 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 é possível utilizar múltiplos servidores para melhorar o desempenho quando se deseja atender muitos usuários. A imagem seguinte mostra um exemplo onde são 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 visualização do streaming é feita através de um player de mídia, que varia conforme a solução 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 à solução: 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

Capítulo 8 - Transmissão via streaming

Figura 8.8 Servidores Windows Media Server com balanceamento de carga.

Windows Media

Além dos players associados às soluções, podem ser utilizados players de mídia genéricos, 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 comparação entre os containers, formatos de áudio e vídeo e protocolos utilizados em cada uma das soluções citadas: Flash Container Vídeo Á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 Comparação entre os containers (formato de áudio/vídeo).

Na tabela foram colocados apenas os itens mais significativos de cada sistema. Há sistemas como o Helix, principalmente, que suportam diversos formatos além dos citados. Esta tabela é válida para as versões pagas dos sistemas. A versão open source do Helix possui suporte a menos formatos e containers, mas as versões open source do Flash e QuickTime são bastante equivalentes com a tabela. Além do streaming e gravação, os servidores de streaming normalmente também suportam vídeo sob demanda (VOD). Neste caso, não é necessário um codificador: os vídeos que serão disponibilizados são colocados em um diretório e o servidor de streaming disponibiliza o acesso a eles, seja por streaming ou por download progressivo.

w
Para uma comparação detalhada dos sistemas de streaming, visite na Wikipedia a página com os diversos formatos e protocolos suportados por cada solução: “Comparison of streaming media systems”.

222

Administração de Videoconferência

Roteiro de Atividades 8
Atividade 1 – Utilização do Windows Media Server
O servidor Windows Media Server (WMS) será utilizado para fazer essa atividade prática, em que o instrutor vai configurar um ponto de publicação no WMS, que será utilizado para os alunos publicarem o conteúdo ao vivo gerado pelo codificador Windows Media.

Atividade 2 – Transmissão de conteúdo com a suíte Flash Media
Esta atividade é individual, e bastante semelhante à atividade anterior, porém serão utilizadas as ferramentas do Flash Media para criação, transmissão e recepção de conteúdo. O Flash Media Encoder fará a captura de áudio e vídeo, o Flash Media Server fará a distribuição do conteúdo e o Flash Player será utilizado para visualizar o conteúdo, através de um plug-in no navegador web. Nesta atividade todos esses componentes serão instalados na máquina do usuário. O primeiro passo é a instalação do Flash Media Encoder e do Flash Media Server. O Flash Player já está instalado (se não estiver basta fazer seu download e instalá-lo) e será utilizado através de uma página web. No material adicional serão exibidas imagens que ilustram o processo de instalação das aplicações com algumas dicas necessárias.

Descrição das atividades
Após instalados os aplicativos necessários, cada aluno deverá executar os passos listados a seguir. Depois serão dadas dicas para a correta execução das atividades. Efetue os testes a seguir: 11 Testar transmissão ao vivo, capturando da webcam e transmitindo; 11 Testar vídeo sob demanda (VOD); 11 Trabalhar em duplas: um aluno transmite e o outro recebe. Explore o codificador: 11 Modificar as taxas de codificação de vídeo; 11 Incluir mais de uma qualidade (são suportados diversos fluxos); 11 Testar a gravação em arquivo. Visualize o console de administração, normalmente no mesmo grupo da instalação do ser Capítulo 8 - Roteiro de Atividades

vidor. Consulte as estatísticas quando os clientes se conectam. Para acesso de outras máquinas e redes, observe as portas utilizadas e a liberação via firewall.

223

224

Administração de Videoconferência

9
Videoconferência web
objetivos
Permitir ao aluno experimentar diversos aplicativos de webconferência, reforçando os conceitos teóricos estudados e comparando as diferentes soluções.

conceitos

Conferência web (webconferência), modelos de serviço de webconferência, soluções proprietárias (Adobe Connect, Cisco WebEx, FuzeMeeting, Google hangout) e soluções de código aberto (Mconf, Big Blue Button, OpenMeetings).

Conferência Web (webconferência)
Utiliza-se o navegador para efetuar a videoconferência. Vantagens: 11 A grande vantagem é a facilidade de uso. 11 Dispensa instalação de software cliente: a aplicação é executada sobre o navegador. 22 Apesar disso, normalmente são necessários plug-ins como o Flash. 11 Dispensa equipamentos específicos: normalmente utiliza-se uma webcam comum. 11 A maioria dos casos dispensa configuração de firewall em clientes, pois utiliza portas comuns, como a porta 80. 11 Criação, agendamento, gerência de salas e usuários através de websites. 11 Entrar em uma conferência clicando em uma URL. 11 Integração com sistemas como Moodle e Joomla. Webconferência é o ato de conduzir apresentações ou encontros remotamente utilizando ambiente web. Antigamente, os termos webconference e computer conference eram fre quentemente utilizados para referenciar discussões realizadas através de um painel de

q

a sistemas que permitem a comunicação em tempo real, enquanto as mensagens postadas recebem o nome de fórum de discussão, entre outros nomes. Sistemas de webconferência são normalmente compostos por um servidor responsável por coordenar as diversas sessões/salas de participantes, e os clientes, que são aplicações que rodam sobre um navegador web (aplicações web). Esses sistemas na maioria das vezes também apresentam funcionalidades adicionais além da troca de áudio e vídeo, como quadro interativo, compartilhamento de aplicações e slides.

225

Capítulo 9 - Videoconferência web

mensagens (fórum), quase sempre de forma assíncrona. Hoje, os termos fazem referência

Diferenças de videoconferências desktop
Com o avanço das tecnologias de videoconferências desktop e de videoconferências web, as diferenças entre essas duas formas de interação por vídeo estão cada vez menores. Praticamente todos os sistemas atuais podem ser utilizados sobre a internet, sendo que a grande diferença entre eles passa a ser o software cliente. Em webconferências, o software cliente é uma aplicação executada dentro do navegador web (com exceções), enquanto em videoconferências desktop é sempre necessária a instalação de uma aplicação adicional na máquina do usuário. As diferenças entre os dois modelos de videoconferência por vezes não são muito claras. Diferenças entre sistemas em software para webconferência e sistemas em hardware para videoconferência são visíveis e serão tratadas neste curso. Há, porém, sistemas em software para videoconferência que muitas vezes possuem características dos sistemas de webcon ferência, além de apenas interação por áudio e vídeo como os sistemas em hardware. Por vezes também se considera como webconferência sistemas com ferramentas como quadro branco, compartilhamento de tela e documentos, controle remoto, servidor centralizado para gravação, ferramentas normalmente não existentes em sistemas de videoconferência, sobretudo nos sistemas em hardware. Além disso, webconferências utilizam uma arquitetura cliente-servidor, onde os dados (incluindo áudio e vídeo) são enviados para um servidor e então distribuídos para os clientes. Isso facilita a comunicação em redes privadas e controladas por firewalls e NATs, pois o cliente só precisa se comunicar com o servidor e não com os diversos outros clientes conectados na videoconferência. Outra vantagem da comunicação cliente-servidor é que o servidor pode adaptar os fluxos de áudio e vídeo individualmente, conforme a capacidade de cada cliente (reduzir resolução de vídeo, adaptar taxa de transmissão etc.). As desvantagens são a necessidade de um servidor com alta capacidade de processamento e largura de banda e também o provável aumento no atraso do sistema, já que os dados são processados por um elemento intermediário (servidor). Apesar de ser possível que sistemas de webconferências funcionem no modelo peer-to-peer, eles costumam utilizar um servidor web pelo menos para servir as páginas aos clientes. Ou seja, o cliente acessa um endereço web, e um servidor deve responder a esta requisição enviando a ele a aplicação web para a webconferência. Aplicações web normalmente são desenvolvidas com tecnologias Flash, Java ou Silverlight. O padrão HTML5 está avançando rapidamente e será o provável substituto das tecnologias atuais para desenvolvimento de aplicações web, incluindo as de webconferência.

Vantagens da webconferência
A grande vantagem dos sistemas de webconferência está na facilidade de efetuar uma vide Administração de Videoconferência

oconferência, visto que tais sistemas funcionam via navegador web. É importante observar que apesar do uso do navegador, os sistemas normalmente necessitam da instalação de plug-ins como o Adobe Flash. Mesmo assim, instalar um plug-in ainda é mais vantajoso do que instalar uma aplicação específica, pois o plug-in pode ser utilizado para diversos propó sitos (diversas aplicações web utilizam Flash, por exemplo). Nesse tipo de sistema, um administrador da conferência normalmente cria uma “sala virtual” e convida os participantes. Essa sala virtual é gerenciada por um servidor localizado em algum ponto, porém isso é transparente para os usuários. Assim, os sistemas de webconferência não só aproveitam o computador do usuário, mas também aproveitam seu

226

navegador web, bem como a porta destinada ao navegador, que normalmente é liberada no firewall, não demandando qualquer liberação de porta aos administradores de rede, o que muitas vezes pode ser traumático em empresas com políticas rígidas de segurança. O acesso a esse tipo de conferência costuma ser feito de forma bastante simples e intuitiva. Tudo é gerenciado através de websites, incluindo a criação e o gerenciamento de conferências, controle de usuários e agendamento, entre outros. Também são utilizados padrões web difundidos, como HTTP e SSL, possibilitando tarefas como: 11 Convidar participantes por e-mail; 11 Entrar em uma conferência com apenas um clique numa URL; 11 Integração com sistemas de gerenciamento de conteúdo como Moodle e Joomla, entre outros.

Modelos de serviço de webconferência
Aluguel de salas de videoconferência: 11 Aluga-se todo o ambiente, incluindo as salas onde os participantes estarão. 11 Necessário 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 webconferência. 11 Aluguel normalmente com valor fixo mensal. 11 Cliente costuma ser grátis, bastando acessar um website. Instalação local (on-site): 11 Instalação do serviço de conferência web localmente. 11 Mais aconselhável para grandes empresas que podem manter o sistema. 11 Também aconselhado quando utilizados sistemas de webconferência de código aberto.

q

Aluguel de salas de videoconferência
Diversas empresas possibilitam o aluguel de salas de videoconferência como uma forma de reduzir custos de outras empresas; a vantagem nesta modalidade de serviço é que a companhia que necessita do serviço não 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 são as soluções mais caras, mas também as menos trabalhosas.

Aluguel de servidores de salas virtuais
Outro modelo é aproveitar o conceito de sala virtual utilizado em webconferências. Uma vez que no sistema de conferência web as reuniões são realizadas em computadores pessoais de usuários sem necessidade de equipamentos ou softwares específicos para este fim, é possível alugar apenas o servidor de webconferência. Muitas provedoras de serviços oferecem esta possibilidade, entre elas a Adobe, com o Adobe Connect, e a Cisco, com o Cisco WebEx. Os usuários normalmente pagam uma tarifa mensal para acessar o serviço, com valores variando conforme a qualidade do serviço (quantidade de usuários, qualidade de áudio e vídeo etc.) e os serviços adicionais aos quais se deseja ter acesso (gravação, armazenamento etc.). 227
Capítulo 9 - Videoconferência web

Neste modelo, a aplicação cliente costuma ser de graça. Contratando o serviço que disponibiliza o servidor, os usuários podem simplesmente acessar um determinado website e através dele acessar as conferências.

Instalação local (on-site)
A instalação de sistemas de webconferência em local próprio é justificada quando há a necessidade de uma administração mais centralizada ou uma customização do modelo de negócios. Um exemplo é quando uma empresa adquire uma solução de conferência web para disponibilizar para suas filiais ou para seus clientes. É preciso lembrar que isto demandará uma série de profissionais experientes para a administração destes sistemas, bem como de uma estrutura tecnológica (rede, servidores) que esteja de acordo com os requisitos de cada solução. Por estes motivos, esse modelo é recomendado para grandes empresas com alta demanda por videoconferências. Esse modelo também pode ser utilizado em conjunto com as ferramentas de webconferência de código aberto que começaram a surgir nos últimos anos. Com esses sistemas é possível obter e instalar o servidor em máquinas locais sem custos de software. Porém, obviamente ainda existe o custo de compra, instalação e manutenção dos servidores.

Soluções de conferência web
Há diversas soluções, a maioria delas proprietárias, que buscam o mesmo conjunto de funcionalidades, como: 11 Comunicação com áudio e vídeo (cada vez se busca maior qualidade e adaptação à capacidade de rede do cliente). 11 Capacidade de suportar o maior número possível de clientes. 11 Chat. 11 Quadro branco interativo. 11 Compartilhamento de desktop. 11 Apresentações (formatos como PDF, PPT e outros). 11 Gravação. 11 Suporte a diversos sistemas operacionais. Nesse capítulo serão mostradas imagens dos aplicativos como referência, para dar uma ideia da solução. Porém, sabemos que a interface com o usuário muda à medida que novas versões são lançadas. Recomenda-se o teste das soluções nos sites dos fabricantes para experimentar a versão mais recente.

q

Administração de Videoconferência

Existem diversas soluções de webconferência, sendo a maioria delas soluções proprietárias (podem ser encontradas mais de 15 soluções). Há bem menos soluções de código aberto significativas, entre elas Big Blue Button, OpenMeetings e WebHuddle (este último com pouca atividade nos últimos anos). Nesta seção, foram escolhidas as soluções proprietárias em destaque atualmente e soluções de código aberto, por serem mais acessíveis. Entre as ferramentas proprietárias estão Adobe Connect e Cisco WebEx. Também será apresentado o DimDim, solução que teve seu início como código aberto mas que migrou para um modelo proprietário. Já as soluções de código aberto apresentadas são o OpenMeetings e o Big Blue Button, por possuírem uma comunidade de desenvolvedores e usuários em atividade. Apesar de existirem diversas

228

soluções no mercado, elas em geral são muito parecidas. Ou podemos dizer que os objetivos finais e as funcionalidades são as mesmas em praticamente todos os casos. A maioria das soluções, por exemplo, possui áudio, vídeo, chat, quadro branco e exibição de apresentações. Com a constante evolução dos sistemas, as funcionalidades de cada um mudam rapidamente. Portanto, uma referência atualizada para saber as funcionalidades de cada ferramenta é a internet. O grande diferencial de soluções de webconferência para soluções de videoconferência para desktop ou com dispositivos físicos é a facilidade de uso. A “facilidade” neste caso diz respeito a diversos fatores que facilitam o uso da aplicação no lado do cliente. Entre os fatores estão a facilidade em criar, ingressar e gerenciar conferências, a não obrigatoriedade de instalação de software específico para a videoconferência (apesar da necessidade de plug-ins na maioria das vezes) e o uso de padrões web, que influenciam nas questões de firewall e na integração com outras ferramentas. O intuito desta seção é apresentar de forma sucinta cada um dos sistemas, suas capacidades e interfaces. Está incluída a prática de três sistemas: Adobe Connect, Big Blue Button e OpenMeetings. Outras soluções serão apresentadas através de vídeos.

Adobe Connect
Solução proprietária da Adobe, antigamente conhecida como Macromedia Breeze. Desenvolvido em Flash, o sistema funciona no modelo cliente-servidor. O servidor é comercializado, enquanto o cliente é grátis. Exemplo: não é necessário comprar o Adobe Connect para ingressar em uma conferência da RNP. O sistema é comercializado de duas maneiras: 11 Assinatura hospedada: usuário paga uma mensalidade e utiliza os servidores da Adobe. 11 Compra do software servidor para instalação local. Para ingressar na sessão: 11 É possível entrar como convidado, mediante autorização do moderador (salas públicas) ou através de usuário e senha (salas privadas). 11 Basta acessar uma URL onde será visualizada a interface para entrar no sistema. Permissões: 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 solução proprietária cuja arquitetura utiliza o modelo cliente-servidor. O

q

sistema está disponível através de assinatura hospedada, em que o usuário paga uma mensalidade e utiliza servidores da Adobe, ou através da compra do software servidor para instalação local.
1. O aplicativo cliente é desenvolvido inteiramente em Flash: basta ter o plug-in do Flash para a

aplicação ser exibida no navegador. Apesar do Flash ser um plug-in que deve ser instalado na máquina do usuário, ele já está disponível na grande maioria das máquinas, 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

Capítulo 9 - Videoconferência web

Ingressar em uma sessão
No Adobe Connect as salas podem ser públicas ou privadas. Nas salas públicas não é necessária autenticação para entrada, ou seja, mesmo um usuário não cadastrado no servidor poderá entrar na reunião. Já nas salas privadas, o usuário deverá fornecer um nome de usuário válido e com permissão para que possa entrar na sala, isto é, usuários sem identificação não podem acessar a videoconferência. O acesso a uma videoconferência é feito de forma simples. Basta acessar uma URL (que normalmente indica o nome da sala de videoconferência), e serão exibidos os campos para preencher nome de usuário e senha. Clicando em “Prosseguir”, o website carrega o ambiente de videoconferência e o usuário já faz parte da sessão. O Adobe Connect oferece ferramentas de administração que permitem agendar conferências e enviar convites aos participantes. Algumas tarefas de administração serão vistas adiante.

Interface do cliente
A interface do Adobe Connect é baseada em “pods”, que são áreas internas da aplicação (como janelas internas) que possuem alguma função específica na sala. Eles determinarão os recursos que serão utilizados durante a reunião. Na configuração básica da sala, temos os seguintes pods: 11 Câmera e vídeo; 11 Lista de participantes; 11 Chat; 11 Notas (bloco de anotações); 11 Área de compartilhamento, que possibilita o compartilhamento da tela, de documentos e de quadro branco.

Pods

Administração de Videoconferência

Figura 9.1 Interface inicial padrão do Adobe Connect.

A aplicação possui um menu na barra superior que permite a configuração de todos os pods, inclusive sua organização na interface. A organização dos pods na tela também pode ser feita através de layouts, que serão descritos mais adiante. A versão 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 incluídas novas funções como “arrastar e soltar”.

Figura 9.2 Interface do Adobe Connect 8.

Papéis (permissões) dos usuários
Dentro de uma sala, os usuários podem ter três níveis diferentes de permissão: 11 Administradores (hosts) – controlam configurações relacionadas à sala, troca de layout, colocação de novos pods, mudança de nível de permissão de outros participantes, uso de chat, voz e vídeo, compartilhamento de documentos, apresentações e tela do computador; 11 Apresentadores – o apresentador faz mudanças menos significativas no layout da sala, podendo maximizar e mover os pods, embora não conseguindo inserir novos. Ele ainda pode usar o chat e o pod de voz e vídeo, ou seja, compartilhar o seu áudio e vídeo com a sala, e também compartilhar documentos e a tela do seu computador; 11 Participantes – possuem permissão apenas para visualizar a sessão e interagir usando o chat. Não desempenham nenhuma tarefa administrativa na sala e não têm permissão de alteração do layout. Os usuários são todos exibidos no pod com a lista de participantes, e seu ícone indica qual o seu papel. Administradores podem modificar o papel dos usuários utilizando este mesmo pod.

Figura 9.3 Pod com a lista de usuários e botão para alterar permissões.

Promover usuário

231

Capítulo 9 - Videoconferência web

Compartilhamento de áudio e vídeo
O Adobe Connect permite interação através de áudio e vídeo. Não possui um limite de câmeras por sessão: o limite é dado pela banda de rede. Suporta praticamente qualquer modelo de webcam reconhecido pelo sistema e também outros tipos de câmeras (como câmeras DV). Para compartilhar áudio e vídeo é necessário primeiro permitir que a aplicação tenha acesso à sua câmera e a seu microfone. O pod de vídeo possui um botão para isso. Assim que pressionado, é exibida a tela padrão do Flash para que o usuário permita que o Flash acesse seus dispositivos (ou apenas um deles). Permitindo o acesso, o vídeo do usuário passa a ser transmitido para todos os participantes.

Habilitar câmera e telefone O áudio, porém, só começa a ser transmitido quando o usuário habilitar outra opção. Fora do pod de vídeo há o botão exibido na figura abaixo, que permite que o usuário habilite a transmissão de seu áudio quando estiver falando.

Figura 9.4 Pod utilizado para habilitar vídeo e áudio.

Flash Media Encoder

Fixar microfone

Figura 9.5 Botão para habilitar a transmissão de áudio.

Uma das maiores críticas ao Adobe Connect sempre foi a qualidade mediana dos vídeos, muito inferior aos sistemas de desktop e em hardware que suportam alta definição. Na
Administração de Videoconferência

versão 8, porém, o Adobe Connect melhorou a qualidade de vídeo e áudio, suportando inicialmente resoluções de até 640x480. Além disso, foram incluídos outros detalhes importantes, como a capacidade de visualizar o seu vídeo antes de iniciá-lo e a integração 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 são funcionalidades disponibilizadas no pod de compartilhamento. Este pod ocupa grande parte da aplicação no layout padrão, sendo o foco principal de muitas reuniões.

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 vídeos (no formato FLV). O usuário seleciona os documentos que deseja compartilhar e os envia para o servidor. O servidor converte os dados para o formato adequado para exibição e distribui o conteúdo para os participantes da videoconferência. No caso de vídeos, os participantes podem vê-los por download progressivo assim que o documento estiver completo no servidor (upload completo).

Figura 9.7 Compartilhamento de uma apresentação.

A versão 8 do Adobe Connect inclui a possibilidade de “arrastar e soltar” (drag & drop) dos arquivos do computador para compartilhá-los na videoconferência. Outra funcionalidade do pod de compartilhamento é o quadro branco, que funciona como uma lousa. O quadro é colaborativo, ou seja, qualquer alteração feita é vista por todos os participantes. Apenas bastante comuns em quadros brancos: desenhar linhas, formas geométricas, setas, modificar cores, entre outros.
Capítulo 9 - Videoconferência web

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 aplicações que estão sendo utilizadas no computador do cliente, é possível usar o compartilhamento de tela. Com ele, pode ser compartilhada uma aplicação específica 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 usuário pode ainda dar o controle de sua máquina para outro participante da sala, funcionalidade chamada de “controle remoto”.

Bate-papo (chat)
Além de interação por áudio e vídeo, as videoconferências no Adobe Connect podem utilizar um pod de bate-papo (chat). Seu uso permite troca de mensagens de texto entre os usuários. O chat por padrão é público, mas é possível mandar mensagens para um usuário específico (chat privado). Na versão 8, os chats público e privado são separados, facilitando a organização. Além disso, inclui formatações 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).

Administração de Videoconferência

Outros pods
O Adobe Connect possui ainda pods para outras funcionalidades além das já citadas. Um deles é o pod para anotações, que é bastante simples e utilizado para, por exemplo, guardar a pauta da reunião. Outro pod interessante é o pod de pesquisa (votação), onde pode-se incluir uma pergunta e diversas opções de respostas. Essa pesquisa é então apresentada a todos os participantes e no fim pode-se ver o resultado da votação.

234

Figura 9.10 Pod para pesquisa (votação).

Layouts
Os layouts são formas pré-configuradas de organizar os pods na tela. Eles podem ser criados pelos administradores e são facilmente acessados dentro de uma videoconferência, utilizando a barra como a da figura seguinte.
Figura 9.11 Barra para mudança de layouts.

Layouts são extremamente úteis para mudar a configuração da sala conforme o andamento da videoconferência. Por exemplo: pode-se começar a videoconferência com os pods de vídeo e chat ocupando praticamente toda a tela, para que os participantes possam se apresentar e dar início à sessão. Em seguida, muda-se para um layout onde vídeo e chat ocupam menos espaço, possibilitando que o pod de compartilhamento ocupe grande parte da tela para exibir uma apresentação. Exemplos desses dois layouts são exibidos nas figuras seguintes.

Figura 9.12 Layouts com foco em: 1) vídeo e chat; e 2) apresentações.

235

Capítulo 9 - Videoconferência web

Área do apresentador
Administradores e apresentadores dispõem ainda de uma área de preparação do evento, que consiste em uma região da tela que não é mostrada para os participantes, apenas visível para administradores e apresentadores. Assim, pode ser realizada comunicação sem intervenção no ambiente comum a todos da reunião; qualquer pod pode ser usado nesta área. Um recurso particularmente interessante é o pod de moderação de chat; com ele associado ao chat da área comum da sala, todas as entradas no chat serão direcionadas para um pod especial, chamado Question & Answer, onde serão respondidas e só depois de moderadas serão enviadas para a área comum da sala. Na imagem seguinte está exibida a visão do administrador, com a área de preparação habilitada.

Figura 9.13 Imagem do Adobe Connect exibindo a área exclusiva para apresentadores.

Dispositivos móveis
Recentemente, a Adobe lançou clientes do Adobe Connect para os dispositivos móveis com os sistemas iOS (iPhone e iPad) e Android (versão 2.2 e superiores). O cliente para iOS foi lançado antes mesmo da versão 8 do Adobe Connect, enquanto o cliente Android foi lançado com a versão 8. Ambos os clientes são gratuitos. Basta fazer download da aplicação para participar de uma videoconferência. Porém, são apenas visualizadores, ou seja, não
Administração de Videoconferência

enviam nem áudio nem vídeo, mas podem interagir por chat.

Funcionalidades administrativas
As funções administrativas do Adobe Connect são realizadas através de uma interface web que configura o servidor Adobe Connect. Esse sistema web permite o gerenciamento dos usuários, das salas de videoconferência e dos arquivos armazenados no servidor (aqueles que foram compartilhados em videoconferências). Outra funcionalidade importante que faz parte do gerenciamento do Adobe Connect é a gravação das videoconferências. O conteúdo fica disponível no servidor e pode ser visualizado

236

posteriormente. Pode-se “reproduzir” a conferência como se fosse um vídeo gravado, observando tudo o que aconteceu. Além disso, o Adobe Connect armazena o estado da reunião: 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 videoconferência pelos administradores. São tarefas como habilitar/desabilitar áudio ou vídeo de algum participante, mudar permissões dos usuários, mudar ou criar layouts, entre outros.

Atividade de demonstração do Adobe Connect
O instrutor vai demonstrar a administração de uma sala de webconferência. Os alunos deverão se conectar e acompanhar a exibição do instrutor. 11 Níveis de permissão; 11 Pods (compartilhamento, vídeo, bate-papo, enquete); 11 Área do apresentador; 11 Layouts.

Cisco WebEx
WebEx inclui: 11 WebEx Meeting Center: solução de webconferência. 11 WebEx Training Center: voltado para e-learning. 11 WebEx Event Center: para eventos e seminários. 11 MeetMeNow: aplicação mais simples para webconferência entre até 15 indivíduos. 11 Todas as soluções são construídas sobre a mesma plataforma (MediaTone). 11 É um dos principais sistemas de videoconferência, assim como o Adobe Connect. 11 WebEx Meeting Center (desenvolvido em Java). 11 Suporte em vários sistemas, como Windows, Mac, Solaris, Linux/Unix. Principais características: 11 Compartilhamento de desktop. 11 Controle de computador remoto. 11 Quadro branco. 11 Chat e chat privado durante as reuniões. 11 Gravação das videoconferências. 11 Compartilhamento de documentos (PPT, PDF etc.)

q

11 Oferecido apenas em forma de serviço. WebEx é o nome de uma empresa adquirida pela Cisco em 2007 e também o nome dado ao conjunto de soluções de videoconferência que esta empresa (e portanto, a Cisco) provê. Porém, o nome WebEx é normalmente associado à solução de webconferência da Cisco, visto que todas as soluções são construídas sobre a mesma plataforma (chamada MediaTone), mas adaptadas para diferentes modelos de negócio. Neste curso, a solução que mais se encaixa é o WebEx Meeting Center, a solução de webconferência que possui muitas similaridades com soluções como o Adobe Connect, por

237

Capítulo 9 - Videoconferência web

11 Cliente para dispositivos móveis (iPad, iPhone, Android, Blackberry).

exemplo. Esta solução de webconferência será referenciada apenas por WebEx no restante desta sessão. Assim como o Adobe Connect, o WebEx é um dos sistemas de webconferência mais conhecidos atualmente. É um sistema baseado na web, com integração de data e mídia em um navegador web padrão. Ele é comercializado apenas na forma de serviço, onde os servidores WebEx são hospedados pela Cisco e os usuários alugam o serviço com pagamentos mensais. O WebEx é baseado na linguagem Java, que, assim como o Flash, já está bastante difundido nos computadores atuais. As plataformas suportadas são várias: 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, vídeos e outros. No centro, ocupando grande parte da aplicação, está a área para funções de gerenciamento (convidar participantes, por exemplo), quadro branco, compartilhamento de tela, e outras tarefas que, quando utilizadas, são o foco principal da conferência.

Figura 9.14 Interface do WebEx Meeting Center.

O WebEx é uma solução muito parecida com o Adobe Connect, tendo, portanto, funcionalidades muito parecidas. Entre seus recursos estão: 11 Compartilhamento de desktop; 11 Controle de computador remoto; 22 Compartilhamento de áudio e vídeo: a interface do WebEx Meeting Center permite até 6 vídeos ao mesmo tempo, com resolução máxima de 640x360; 11 Quadro branco; 11 Chat e chat privado durante as reuniões;
Administração de Videoconferência

11 Gravação das videoconferências; 11 Compartilhamento de documentos (PPT, PDF etc.): diferente do Adobe Connect: não converte e exibe na aplicação, apenas envia para um local comum e permite que os outros participantes façam download dos arquivos no seu formato original.

238

Figura 9.15 Cliente para dispositivos móveis (iPad, iPhone, Android, Blackberry); tela compartilhada do WebEx no iPhone.

Ao compartilhar um vídeo, o usuário transmite este vídeo para o servidor e depois os participantes podem acessá-lo. No WebEx, cada participante precisa carregar o vídeo inteiro para então exibi-lo, enquanto no Adobe Connect pode ser utilizado download progressivo, o usuário visualiza o vídeo à medida que ele está sendo obtido. Já foi citado que o Adobe Connect guarda o estado da reunião, permitindo que ela seja finalizada e acessada novamente mais tarde, voltando ao seu último estado. Já o WebEx não guarda o estado da reunião: se ela acaba, perde-se o seu estado.

FuzeMeeting
Com foco no compartilhamento de documentos e suportando alta resolução, também possui comunicação por chat, vídeo e áudio inclusive com integração com o Skype. Suportado em “qualquer sistema”: 11 Windows, Mac, Linux, Solaris. 11 Suporte para dispositivos móveis: iPad, iPhone, BlackBerry, Android. Entre suas funcionalidades principais estão: 11 Compartilhamento de conteúdo em HD (imagens e vídeos). 11 Compartilhamento de desktop e controle remoto. 11 Executado no navegador em Flash. 11 Quadro branco e anotações. 11 Gravação das videoconferências para acesso posterior.

q

O FuzeMeeting é outro sistema de webconferência cuja principal diferencial é ser voltado mais para compartilhamento de documentos e desktop do que para videoconferência propriamente (de certa forma semelhante ao GoToMeeting). Desenvolvida em Flash, a ferramenta é executada dentro do navegador, sem necessitar de plug-ins adicionais além do Flash.
Capítulo 9 - Videoconferência web

O FuzeMeeting ainda não possui interação por vídeo, mas possui comunicação por áudio, que pode ser feita pelo microfone do computador, por um telefone ou pelo Skype. Seu compartilhamento de documentos permite compartilhar imagens, apresentações e vídeos em alta resolução e utilizar ferramentas de anotações (inclusive quadro branco) e apontadores para trabalhar sobre estes documentos. Outras funcionalidades são o compartilhamento de desktop, controle remoto e gravação das conferências para acesso posterior. A imagem seguinte mostra a interface da ferramenta.

239

Figura 9.16 Interface do FuzeMeeting compartilhando imagem em alta definição.

Uma das vantagens do FuzeMeeting é o suporte a diversos sistemas operacionais e dispositivos móveis. Os criadores da ferramenta dizem que ela permite compartilhamento de qualquer coisa em sua tela, em alta resolução e com qualquer pessoa, em qualquer lugar, em qualquer dispositivo (“ with anyone, anywhere, on any device ”). Na prática, pode ser executado em Windows, Mac, Linux e Solaris e também possui aplicações para iPad, iPhone, BlackBerry e Android.

Figura 9.17 FuzeMeeting em diversos sistemas e dispositivos.

O FuzeMeeting é vendido como serviço, e seu valor atualizado deve ser consultado no site.
Administração de Videoconferência

Figura 9.18 Versão do FuzeMeeting com interação por áudio e vídeo.

240

Google Hangout
11 Website: plus.google.com 11 Sistema proprietário da google de uso livre 11 Utiliza codificação escalável de vídeo 11 Facilmente integrado com todo o sistema google Principais características: 11 Compartilhamento de desktop 11 Compartilhamento de youtube 11 Chat 11 Compartilhamento de documentos (google docs)

q

O Google Hangout é o sistema de webconferência do Google, sendo bastante integrado com os outros sistemas dele, como Youtube e Google Docs. Apesar de ser um sistema proprietário (não tem o código aberto), seu uso é livre, bastando ao usuário ter uma conta no Gmail. Permite compartilhamento de desktop, chat e outras facilidades interessantes, tanto para efetuar reuniões de trabalho como para se divertir entre amigos. Uma característica interessante do Google Hangout é que o seu vídeo é codificado de forma escalável, resultando numa boa qualidade para a banda utilizada.

BigBlueButton (BBB)
Sistema de código 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 resoluções atualmente suportadas são de 320x240 e 640x480. 11 640x480, com baixo fps (entre 10 e 15). A qualidade é boa, mas não ótima. Utiliza codificação Sorenson H.263, já estando em andamento o suporte a H.264. O Big Blue Button (BBB) é uma das poucas soluções de webconferência de código aberto.

q

Seu desenvolvimento teve início em 2007, na Carleton University (Canadá). Distribuído sob a licença LGPL, o funcionamento do BBB é semelhante ao do Adobe Connect, sendo desenvolvido basicamente em Flash e Java (utilizado no servidor apenas). O cliente é uma aplicação Flash que usa um navegador web. A interface da aplicação é orgapodem ser movidas, redimensionadas e reorganizadas conforme o layout desejado. Apesar de possuir diversas funcionalidades interessantes, que serão vistas na sequência, o BBB ainda não se iguala aos sistemas proprietários em termos de recursos disponíveis 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 proprietários. Sendo uma ferramenta de código aberto, o BBB tem a vantagem de poder utilizar as diversas bibliotecas e sistemas de código aberto existentes. Ele é construído com base em
Capítulo 9 - Videoconferência web

nizada em janelas internas (pods), cada uma com uma funcionalidade específica. As janelas

241

diversos outros sistemas de código aberto, incluindo bibliotecas para codificação de áudio e vídeo, servidor e proxy HTTP, servidor RTMP e conversão de documentos, entre outros. Entre as funcionalidades do BBB estão: 11 Compartilhamento de apresentações 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 apresentação ou documento. 11 Compartilhamento de tela. 11 Quadro branco, que permite escrever sobre as apresentações. 11 Break-out de salas, que permite separar os participantes de uma sala em outras salas. 11 Integração VoIP com Asterisk ou FreeSWITCH. 11 Chat público e privado, incluindo tradução automática (com a ferramenta Google Translate). 11 Suporte para mais de 20 idiomas, incluindo português. Na prática, tarefas como cadastrar e gerenciar usuários, criar salas novas, agendar reuniões e visualizar gravações, por exemplo, não são diretamente na interface do BBB. Deve ser utilizada alguma interface que se comunique com a API do BBB, como, por exemplo, as integrações do BBB para Moodle, Joomla e Mconf (que veremos ainda neste capítulo). De certa forma, é uma limitação do BBB, mas permite maior facilidade para integração com outros sistemas. Na versão 0.71 do BBB, o foco do desenvolvimento foi em melhorias no áudio, especialmente na integração com sistemas VoIP. Já a versão 0.8 inclui mecanismos para gravação e reprodução de gravações, 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 webconferência e as ferramentas dentro da sala, como: interação por áudio, vídeo, chat, compartilhamento de tela e as outras funcionalidades citadas. No BBB, tarefas de natureza administrativa devem ser acessadas por uma API, ou seja, não é fornecida interface para acesso a tais funcionalidades.

Figura 9.19 Imagem do BBB em teste com servidor em Washington.
Administração de Videoconferência

O BBB suporta atualmente as resoluções 320x240 e 640x480 para vídeo. 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 vídeo, embora não ótima. A qualidade é equivalente à atingida com o Adobe Connect. O sistema utiliza Speex para codificação de áudio e Sorenson H.263 para vídeo, 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 múltiplas salas de webconferência e já foram realizados testes de carga onde 193 pessoas se conectaram ao mesmo tempo em uma única sala e 20 delas estavam com transmissão de vídeo habilitada. Não é

242

aconselhável permitir a entrada de um número tão grande de usuários, mas esse número mostra a capacidade que o sistema tem de suportar dezenas de participantes simultâneos. Outra característica importante do BBB é a integração com outros sistemas de código aberto, como sistemas para wikis, sistemas de gerenciamento de conteúdo multimídia, sistemas para blogs etc. A seguir uma imagem com os sistemas que fornecem integração com o BBB.

Figura 9.20 Integração do BBB com outros sistemas de código aberto.

d
Lista com os sistemas que fornecem integração com o BBB pode ser acessada na página Integration do site da Big Blue Button.

Dicas para instalar sua versão do BBB: 11 O BBB é executado em Linux (possui pacotes para Ubuntu). 11 A forma mais fácil e recomendada é utilizar a máquina virtual disponibilizada. O BBB é distribuído de três formas: através do seu código-fonte, através de pacotes pré-compilados para Linux, e através de uma máquina virtual que já vem com o sistema

q

pronto para utilização. A forma mais fácil e rápida de colocar um servidor BBB em funcionamento é através de sua máquina virtual. Esta máquina virtual nada mais é do que uma instalação do sistema Ubuntu, pré-configurado para instalar o BBB quando for executada. Os procedimentos são simples e detalhes podem ser encontrados na documentação do BBB. O download da máquina virtual pode ser realizado no site da Big Blue Button. Para uso da máquina virtual é importante: 11 Ter uma rede com DHCP habilitado; é necessária uma máquina virtual aberta para que o BBB seja configurado corretamente. 11 Garantir que a máquina virtual esteja com rede em modo “bridged ”. Se a conexão de rede não for configurada corretamente no modo automático, alguns comandos podem ajudar na configuração:

q

$ 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 configurações do BBB
Capítulo 9 - Videoconferência web

Neste curso será utilizada uma máquina 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 conferência. Nos fóruns e listas de discussão para usuários e desenvolvedores na plataforma Big Blue Button do BBB, pode-se encontrar os planos futuros da equipe de desenvolvimento.

243

Entre as possíveis funcionalidades que serão implementadas estão: 11 Cliente para dispositivos móveis como iPad, iPhone e dispositivos com Android; 11 Codificação com VP8/WebM/H.264 e, em função disso, melhorar a qualidade do vídeo; 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 discussãom, agendamento de eventos e outros; 11 Foi desenvolvido com baso na solução de código aberto Global Plaza, que possui um formato de rede social para realização de eventos virtuais. BigBlueButton: 11 É utilizado como o cliente para webconferências; 11 Como o BigBlueButton é um sistema de código aberto, a equipe do Mconf também colabora com o seu desenvolvimento. Mconf-Mobile: 11 Cliente para dispositivos móveis; 11 Atualmente é um cliente para dispositivos com Android; 11 Permite que os usuários participem de uma conferência; 11 Possui praticamente todas as funcionalidades que existem no cliente desktop tradi cional: compartilhamento de áudio, vídeo, apresentações e bate-papo. O Mconf é um sistema nacional de código aberto, em desenvolvimento no grupo de pesquisa de Projetos em Áudio e Vídeo (PRAV) da Universidade Federal do Rio Grande do Sul

q

(UFRGS), que adiciona funcionalidades ao Big Blue Button para prover um sistema completo de webconferência. A figura seguinte mostra diagrama dos blocos que formam o Mconf.

Administração de Videoconferência

Figura 9.21 Diagrama dos componentes do Mconf.

Os três componentes principais do Mconf são: o portal web (Mconf-Web), o núcleo de webconferência BigBlueButton e o cliente para dispositivos móveis (Mconf-Mobile). O Mconf-Web é o portal de acesso ao sistema, uma aplicação em Ruby on Rails que provê a criação de salas virtuais, fóruns de discussão e agendamento de eventos. Este portal foi desenvolvido com base na solução de código aberto chamada Global Plaza, que possui um formato de rede social para realização de eventos virtuais (eventos com webconferência). 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 webconferências e por ser um sistema de código aberto, a equipe do Mconf também colabora com o seu desenvolvimento. O outro bloco que forma o Mconf é o cliente para aplicações móveis. Atualmente, este componente é formado por um cliente para dispositivos Android. Esta é uma aplicação nativa para Android que permite que os usuários participem de uma conferência com acesso a praticamente todas as funcionalidades do cliente desktop tradicional: compartilhamento de áudio, vídeo, apresentações 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

Capítulo 9 - Videoconferência web

Duas funcionalidades principais adicionadas pelo Mconf: 11 Acesso federado 11 Escalabilidade Acesso federado: 11 O portal web está integrado à federação nacional CAFe. 11 Permite que qualquer membro da federação acesse o Mconf. 11 Utiliza o protocolo Shibboleth. 11 Aumenta a segurança para os usuários e evita a necessidade de criação de múltiplas contas. Escalabilidade: 11 Um servidor BBB é recomendado para 80 usuários simultâneos (mas depende fortemente da máquina). 11 Para aumentar a capacidade existe o módulo de escalabilidade. 11 Permite o uso de múltiplos servidores BBB em paralelo. 11 Com base em um módulo de monitoramento (CPU, memória, banda de rede etc.), a criação das salas escolhe dinamicamente um servidor na rede de servidores BBB do Mconf (permite aumentar o número de salas de webconferência simultâneas). O Mconf está integrado a um módulo Shibboleth, que provê autenticação federada no

q

Shibboleth Protocolo internacional para autenticação federada. Permite que usuários de diferentes serviços sejam autenticados em provedores de identidade centralizados.

portal web. Mconf e diversos outros serviços podem utilizar um mesmo servidor para autenticar os usuários. Para os usuários, a grande vantagem é possuir um ponto de autenticação único para diversos serviços, o que aumenta a segurança e evita a necessidade de criação de contas em múltiplos serviços. Atualmente o Mconf-Web é um dos serviços da federação brasileira CAFe (Federated Academic Community). Em relação à escalabilidade, o Mconf está desenvolvendo ferramentas para permitir o uso de múltiplos servidores BigBlueButton e para escalar os componentes dentro de um servidor. Como foi comentado, um servidor BigBlueButton é recomendado para sessões de 80 usuários simultâneos. Para aumentar essa capacidade, a solução mais direta é melhorar o hardware no qual o servidor está instalado. Isto provavelmente aumentará a capacidade do BigBlueButton, mas não é uma solução escalável, uma vez que se chegará a um limite na capacidade do hardware, não importa o quão bom ele seja. Outra solução é utilizar diversos servidores BigBlueButton em paralelo. Esta solução aumenta o número de salas possíveis, mas não aumenta a capacidade de uma sala, já que uma sala está (atualmente) vinculada a somente um servidor. Para incrementar esta solução e chegar à solução mais completa, deve-se permitir múltiplos servidores BigBlueButton em
Administração de Videoconferência

paralelo e também permitir que uma sala seja “espalhada” por múltiplos servidores. A solução do Mconf para esse problema inclui um módulo de monitoramento no Mconf, que gera estatísticas (CPU, memória, banda de rede) dos servidores Big Blue Button e permite acesso a elas no portal web. Com base nessas estatísticas, as salas serão criadas dinamicamente em diferentes servidores BigBlueButton localizados em regiões geográficas distintas. Como já comentado, o Mconf é um sistema de código aberto. O código e toda a documentação do projeto estão disponíveis para acesso na web, além 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 webconferências de código aberto é o OpenMeetings, que tem diversas semelhanças com o BBB e algumas com o Adobe Connect. O projeto do OpenMeetings foi iniciado em 2007 e seu desenvolvimento evoluiu até o ponto

q

em que está hoje, com cerca de 25 desenvolvedores ativos. É distribuído sob a licença 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 aplicação Flash, é acessado por um navegador web. Seu servidor é baseado no Red5 (assim como o BBB), e ele é desenvolvido utilizando um framework para aplicações web chamado OpenLaszlo. Em comparação com o BBB, ele possui mais funcionalidades, especialmente para tarefas de gerenciamento. Entre suas funcionalidades estão: 11 Quadro branco; 11 Compartilhamento de documentos de vários formatos: PDF, DOC, ODP e PPT, entre outros. São disponibilizados em uma pasta no servidor e também podem ser vistos na conferência; 11 Gravação, reprodução e download das gravações; 11 Compartilhamento de tela e controle remoto (necessita de uma aplicação adicional em Java); 11 Possui tarefas de gerenciamento como controle de usuários e agendamento; 11 Votações com respostas “sim” e “não”; 11 Suporte para mais de 20 idiomas (incluindo português). Abaixo são exibidas imagens da interface do OpenMeetings, a primeira dentro da webconferência e a segunda na página de visualização de gravações.

Figura 9.24 Interface do OpenMeetings para agendamento.

247

Capítulo 9 - Videoconferência web

Figura 9.25 Interface do OpenMeetings durante uma webconferência.

Figura 9.26 Interface do OpenMeetings para visualização de webconferências gravadas.

Entre as integrações que o OpenMeetings possui com outros sistemas de código aberto estão: 11 Moodle: permite criar e agendar webconferências; 11 Facebook: o OpenMeetings possibilita que o login no sistema seja feito através da conta do usuário no Facebook; 11 Paypal: possibilita integrar a cobrança por serviços de webconferência 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. São ferramentas de código aberto, sendo importante verificar as diferenças entre os dois sistemas para decidir aquele que melhor se adapta aos propósitos da pessoa ou instituição que busca um sistema
Administração de Videoconferência

de webconferência. Os dois sistemas possuem ambientes de demonstração disponíveis para o público, então é indispensável utilizá-los para fazer uma análise mais detalhada. Os principais aspectos da comparação entre os sistemas são: 11 Qualidade de vídeo e áudio é bastante similar; 11 OpenMeetings tem funções administrativas já integradas na interface, enquanto o BBB possui algumas dessas funcionalidades, mas fornece apenas a API para usá-las, e não uma aplicação com interface com o usuário. 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 documentação mais completa e melhor elaborada; 11 Interface do BBB é mais limpa e intuitiva; 11 BBB possui integração com VoIP; 11 BBB, via grupo Mconf, possui aplicativo para dispositivos móveis. Ao contrário de outras ferramentas, o OpenMeetings não é distribuído em uma máquina virtual pronta para uso. Para instalação local, deve-se obter o pacote com o código-fonte da aplicação, que é distribuído no website da ferramenta. Os pré-requisitos (bibliotecas) necessários devem ser instalados manualmente, depois é preciso editar alguns documentos do OpenMeetings e iniciar o serviço. Os passos necessários podem ser encontrados na wiki Installation Open Meetings.

Outras soluções
Os sistemas citados até agora são os mais conhecidos e utilizados para webconferência, mas existem diversas outras ferramentas. Entre os sistemas ainda não 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 (proprietário); 11 Elluminate Live! (proprietário); 11 WebHuddle (código aberto). 11 Bluejeans (http://bluejeans.com) – interoperável com H.323 e integrador de várias tecnologias.

Spreed
O Spreed é um sistema proprietário de webconferência. Fazendo cadastro no site é possível utilizar uma versão gratuita, com várias limitações (limite de 3 participantes, pouco espaço de armazenamento de arquivos e outras). Possui versões pagas por $99 ao ano (20 participantes) e $299 ao ano (100 participantes). Apesar de ser pago, possui uma interface muito boa e é bastante fácil de usar.

Figura 9.27 Interface do Spreed exibindo um vídeo e o compartilhamento de uma apresentação.

249

Capítulo 9 - Videoconferência web

Figura 9.28 Interface do Spreed com foco no chat (exibido no centro).

Elluminate Live!
Sistema proprietário da empresa Elluminate com foco em educação à distância. Utilizado pelo Virtual Conference Centre, permite realizar teste na aplicação pela página Getting Started – Virtual Conference Centre (clique em “Training Room”).

Figura 9.29 Interface do Elluminate compartilhando um vídeo e um quadro branco.

250

Administração de Videoconferência

Figura 9.30 Visualizando uma gravação do uso do Elluminate Live! compartilhando uma apresentação.

WebHuddle
Projetado para ser de fácil uso, apresenta diversas opções, incluindo integração com soluções de sistemas de teleconferência de outras empresas. Com o sistema WebHuddle, é possível efetuar a gravação das apresentações que poderão ser reproduzidas futuramente através de qualquer navegador web.

251

Capítulo 9 - Videoconferência web

252

Administração de Videoconferência

Roteiro de Atividades 9
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 possíveis (apresentações, imagens,

documentos texto, quadro branco);
2. Comunicar-se por áudio e vídeo e avaliar a qualidade de ambos. Reparar na taxa de

quadros por segundo e no sincronismo de áudio e vídeo;
3. Utilizar comunicação por chat; 4. Utilizar bloco de notas; 5. Avaliar a interface da aplicação. É fácil para o usuário acessar e utilizar todos os recursos

disponíveis?
6. Qual a banda utilizada pela aplicação?

Atividade 1 – Administração e utilização 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 sequência os alunos farão o papel de participantes, apresentadores e hosts, para que possam utilizar o sistema e ver na prática como ele se comporta.

Atividade 2 – Utilização do Mconf
Acesse o portal http://mconf.org e teste as funcionalidades indicadas neste capítulo.

Atividade 3 – Utilização do Google Hangout
Acesse o Google Hangout e verifique as funcionalidades indicadas. Vale lembrar que, para criar um hangout, o interlocutor deve pertencer aos círculos da pessoa.

253

Capítulo 9 - Roteiro de Atividades

254

Administração de Videoconferência

10
Videoconferência em desktop
objetivos
Permitir ao aluno experimentar diversos aplicativos de videoconferência em software, reforçando os conceitos teóricos estudados e comparando as diferentes soluções.

conceitos

Soluções em software para videoconferência: IVA, EVO, VSee e Citrix gotomeeting.

IVA
Realização de aulas síncronas através 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.

q

O Sistema Interativo de Áudio e Vídeo (IVA) é um sistema de videoconferência 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 Distância (GT-IEAD). O desenvolvimento principal do projeto aconteceu entre 2007 e 2008, sendo que em 2009 e 2010 foram realizados os testes do protótipo e a implantação da primeira versão para uso na ESR. O serviço de aulas por videoconferência na ESR com uso do IVA teve início em 2011. O objetivo do sistema é a realização de aulas síncronas através das unidades da ESR. O professor especialista pode ministrar sua aula presencial em sala chamada de telessala,
Capítulo 10 - Videoconferência em desktop

para alunos remotos localizados em outras salas, que são chamadas de polos. É importante frisar o foco do IVA na interatividade, pois a interação entre professor e alunos remotos é essencial para obter qualidade similar à das aulas presenciais. A imagem seguinte mostra a interação entre telessala e os polos remotos. O professor fica na telessala com uma turma de alunos presenciais, enquanto nos polos estão alunos remotos assistindo às aulas sincronamente. Um ouvinte remoto também pode se conectar e assistir à aula.

255

Pólo

RNP
Ouvinte Telesala

Pólo Unindo alta qualidade de vídeo com o foco na interação, o IVA utiliza o conceito de telepresença, que recria, dentro das possibilidades tecnológicas, condições de uma aula presencial síncrona. Na telessala, os alunos presenciais enxergam os slides do professor normalmente em um projetor. Nos polos, os alunos remotos também enxergam os slides do professor através de um projetor. O professor enxerga os alunos presenciais na telessala, e também enxerga os alunos remotos, porém em televisões, onde a alta qualidade do vídeo permite ver detalhes, como um aluno levantando a mão para fazer uma pergunta. Os alunos presenciais enxergam o professor, e os alunos remotos também enxergam o professor, porém através de uma televisão.
Figura 10.1 Diagrama da comunicação entre telessala e polos remotos através do IVA.

Figura 10.2 Infraestrutura das salas.

(a) Telessala

(b) Polo

Quando um aluno faz uma pergunta, o operador da entidade “suíte” muda a imagem principal para transmitir o vídeo do polo onde o aluno está. Essa imagem é transmitida a todos.
Administração de Videoconferência

Neste formato, as interações entre professor e alunos remotos são 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 três entidades (softwares) principais. São eles o Moderador, a Suíte e o Apresentador. O Moderador e a Suíte são as entidades centrais do sistema, que formam uma sessão de videoconferência IVA, enquanto o Apresentador é o software utilizado nos pontos remotos e na telessala para captura e recepção de dados multimídia. Utilizaremos a primeira letra maiúscula quando nos referirmos aos softwares do IVA, para evitar confusões (e.g. entidade “Apresentador” e a pessoa que tem papel de “apresentador” na sessão). O Moderador funciona como um gerente. Todas as outras entidades IVA se conectam a ele e são gerenciadas por ele. Na prática, ele é utilizado para moderar mensagens de chat e selecionar quais usuários são apresentadores e quais são apenas participantes. O Moderador pode se comunicar por chat com qualquer apresentador e também com a Suíte. Além disso, o Moderador recebe o sinal da transmissão de áudio e vídeo que está sendo transmitido pela Suíte. 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 público. No canto superior esquerdo a imagem principal da transmissão do sistema, e logo abaixo um chat privativo com o operador da Suíte.

257

Capítulo 10 - Videoconferência em desktop

A suíte é o centralizador de mídias do IVA. Ela recebe os sinais de áudio e vídeo 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 transmissão necessária. Caso algum ponto não tenha multicast, existe outra entidade que faz a conversão de multicast para unicast, servindo de forma independente cada um desses locais via unicast. O software Suíte possui 6 previews, que são áreas de pré-visualização de áudio e vídeo. O operador da Suíte pode atribuir qualquer um dos apresentadores em um preview, podendo assim visualizar o seu vídeo e escutar o seu áudio. Após 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 telepresença – interação: 11 Perguntas são feitas “olho no olho”. 11 Todas as salas remotas recebem o sinal de áudio e vídeo do aluno que está perguntando. 11 Professor conversa diretamente com o aluno. Conceito de telepresença: 11 Recria, dentro das possibilidades tecnológicas, condições de uma aula presencial síncrona. 11 Professor enxerga alunos presenciais e polos remotos em televisões. 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 televisão. Outras funcionalidades importantes da Suíte são a mixagem de áudio e a telepresença. A mixagem de áudio permite que a Suíte envie mais de um canal de áudio simultaneamente, facilitando a interação entre as salas remotas. Qualquer vídeo de Apresentador que está em preview pode ser adicionado na mixagem, portanto, até 6 canais de áudio podem ser mixados para envio. A telepresença permite que a Suíte crie fluxos adicionais de envio de áudio e vídeo. Qualquer um dos previews pode ser colocado em telepresença, o que indica que ele será transmitido (também utilizando multicast) de forma independente do que está na transmissão principal (no ar). Na prática, temos um sinal de transmissão “no ar”, que é o sinal dos slides do professor. Temos também diversos outros sinais de telepresença, um para a câmera de vídeo do professor e um para a câmera de cada sala remota. Com isso todos os polos enxergam os slides e o vídeo do professor, e o professor pode visualizar todas as salas remotas.

q

258

Administração de Videoconferência

Figura 10.5 Suíte com 5 apre sentadores em preview e enviando os slides do professor na transmissão principal.

O IVA é baseado em transmissão multicast. O maior problema de utilizar multicast é que ele não é suportado em todas as redes. Na verdade, não é suportado na grande maioria das redes atuais. Pensando nisso, foi desenvolvida uma nova entidade IVA, chamada de Servidor de Streaming. Esta entidade é responsável por permitir que todos os pontos que não suportam multicast tenham acesso à transmissão utilizando unicast. Software “Moderador” 11 Entidade gerente da sessão IVA. 11 Utilizado para moderar mensagens de chat e selecionar os participantes que atuarão como apresentadores. Software “Suíte” 11 Central de dados multimídia: controla distribuição de áudio e vídeo. 11 Seleciona o sinal que está sendo transmitido para todas as salas e os sinais que estão em telepresença. Software “Apresentador” 11 Responsável pela transmissão de áudio e vídeo. 11 Captura vídeo do professor, dos slides e das salas remotas. 11 Exibe imagens nas televisões e projetores. A terceira das principais entidades do IVA é chamada de Apresentador. Este software corticipante e transmitir esses dados para a Suíte, além de receber da Suíte e exibir o vídeo que está no ar e o áudio que está sendo mixado. Além do uso de áudio e vídeo, o Apresentador também pode se comunicar com o Moderador através de chat (todas as mensagens de um Apresentador são enviadas apenas para o Moderador, que pode decidir se elas devem ser repassadas para todos ou não). Outra funcionalidade do Apresentador é a captura de tela, que é utilizada para capturar slides, vídeos 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 vídeo para a Suíte. O mesmo software Apresentador pode ser executado em modo Visualizador, que é um Apresentador que não transmite áudio nem vídeo, apenas recebe. Este Visualizador é utilizado para receber dados de um canal de telepresença. Na prática na ESR, eles são 259
Capítulo 10 - Videoconferência em desktop

q

responde ao cliente da sessão IVA, o responsável por capturar o vídeo e o áudio de um par-

associados às televisões para exibir um pólo nas TVs da telessala, ou para exibir o vídeo do professor nas TVs dos pólos. A imagem a seguir mostra a tela do Apresentador durante a sessão, quando está capturando, transmitindo e recebendo áudio e vídeo. Na parte inferior esquerda da imagem é visto um vídeo que corresponde ao preview do vídeo capturado localmente (a câmera do usuário local). Abaixo ao lado direito do preview fica a área de chat e os botões de controle de áudio, vídeo, chat e outros. Atrás desses componentes e ocupando praticamente toda a tela da aplicação está o vídeo recebido da Suíte (o vídeo “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 sessão.

Além dos softwares citados do sistema IVA, também existe o software Chat, que funciona de forma semelhante ao Apresentador, mas que é utilizado apenas para comunicação via chat (sem áudio nem vídeo). O IVA foi desenvolvido com foco em educação a distância, mas também pode ser utilizado para outros fins, como em reuniões remotas. Como foi visto, na ESR os softwares que formam a base do IVA são instalados na telessala, enquanto os polos necessitam apenas dos clientes (o software apresentador). Abaixo são descritos os softwares utilizados na telessala e nos pólos da ESR, que formam uma das organizações arquiteturais utilizando o IVA. Softwares na telessala: a telessala é o ponto central das aulas na ESR, portanto é nela que estão instalados os servidores IVA. Há uma máquina para o Moderador e uma para a Suíte. Além disso, há dois Apresentadores: um captura a câmera do professor, recebe o vídeo “no ar” e projeta este vídeo no telão (normalmente o vídeo dos slides do professor); o outro é utilizado na máquina do professor, para capturar qualquer conteúdo que se deseje transmitir aos alunos: slides, vídeos, tela de aplicações etc. Para que o professor veja os polos, existem duas televisões na sala, cada uma delas ligada a um Visualizador que recebe o vídeo
Administração de Videoconferência

de uma das salas. Eventualmente é necessário um software servidor de unicast, quando algum participante estiver em uma rede que não suporta multicast. Na telessala é necessário pelo menos um operador para controlar Moderador e Suíte. Pode-se também utilizar dois operadores: um técnico para controlar a Suíte 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 múltiplos em unicast Visualizador Visualizador

Moderador

Suíte

Servidor de streaming

Captura imagem do professor e projeta slides

Captura slides, vídeos e outros conteúdos

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 contêm apenas os softwares clientes do IVA: o Apresentador e o Visualizador. O Apresentador é utilizado para capturar o vídeo e áudio da sala e também para receber o vídeo “no ar” e projetá-lo em um telão e também tocar o áudio da sessão. Já o Visualizador é ligado a uma televisão e sempre mostrará o vídeo do professor. As imagens seguintes mostram telessala na ESR-RS com o IVA em uso.

261

Capítulo 10 - Videoconferência em desktop

Figura 10.8 Sistema de controle com suíte, moderador e apresentador e equipamentos de áudio e vídeo.

Figura 10.9 Tela da suíte com a seguinte distribuição (esquerda para a direita): vídeo do professor na telessala; tela do professor transmitindo um vídeo; 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 configurações e estado da rede. Possui monitoramento fim a fim: 11 Monitora tanto o computador cliente quanto a rede. 11 Permite detecção de problemas como uso elevado de CPU e perda de pacotes.

q

EVO é um sistema de videoconferência desenvolvido pelo Californian Institute of Technology (Caltech), criado com o intuito principal de prover um serviço para o trabalho com o Large Hadron Collider (LHC), o acelerador de partículas da European Organization for Nuclear Research (CERN), localizada na Suíça. O EVO também foi disponibilizado para outros programas de ensino com foco em física (High Energy Physics). A base do EVO é desenvolvida sobre o sistema de agentes MonALISA, o que possibilita o alcance global ao sistema e também o torna mais dinâmico e autônomo. O EVO possui funcionalidades para adaptação automática às configurações e estado da rede e monitoramento fim a fim, incluindo monitoramento do computador cliente e da rede, o que permite a detecção de problemas como uso elevado de CPU e perda de pacotes.
Administração de Videoconferência

A aplicação cliente do sistema chama-se Koala e é desenvolvida em Java. O cliente também utiliza o visualizador de vídeos (ViEVO), que tem como características principais: 11 Troca de mensagens instantâneas, com escolha de estado (ocupado, ausente etc.); 11 Integração com rede telefônica; 11 Uso de OpenGL no cliente, o que melhora o desempenho e permite um sistema 3D de exibição de vídeos; 11 Criptografia de todos os dados trocados; 11 Suporte para múltiplas linguagens;

262

11 Compartilhamento de arquivos e tela; 11 Funções de quadro branco; 11 Gravação e reprodução das sessões; 11 Chat público e privado. O EVO só pode ser utilizado por usuários cadastrados. Portanto, o primeiro passo para utilizá-lo é realizar o cadastro, que pode ser feito no website do EVO, clicando em “Register”. Concluído o registro, basta fazer o download da aplicação e fazer login no sistema. Como a aplicação é em Java, será realizado download do arquivo “.jnlp”, que ao ser executado carrega a aplicação. O arquivo pode ser encontrado no website clicando em “Start EVO”. A próxima figura exibe a tela inicial da aplicação juntamente com a caixa de diálogo utilizada para login no sistema.

Figura 10.10 Tela inicial do EVO e tela para login no sistema.

Após o login, é exibida a tela inicial da aplicação, onde pode ser encontrada uma lista com as reuniões em andamento (públicas ou privadas), a lista de amigos do usuário (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

Capítulo 10 - Videoconferência em desktop

A partir da lista de reuniões (chamadas de salas ou canais) o usuário pode selecionar uma delas para ingressar. Ao entrar em uma reunião, o sistema muda para a tela de reuniões, que contém as configurações possíveis para ela: habilitar/desabilitar áudio e vídeo, gravar, entre outras. Além desta tela, áudio e vídeo são exibidos em outra janela chamada ViEVO, que usa OpenGL para mostrar os vídeos com efeitos gráficos que facilitam a usabilidade da aplicação. É exibido um participante que está em foco no centro da tela e os outros na barra abaixo do vídeo principal. O participante em foco pode ser quem está falando no momento ou participante escolhido pelo usuário. A imagem seguinte mostra a tela de configurações e o ViEVO, respectivamente. EVO possui o canal “EVO TV” aberto a todos os participantes, que pode ser usado para testar sua conexão.

Figura 10.12 Tela de configura ções de canal no EVO e tela do ViEVO com vídeo dos participantes.

VSee
11 Solução gratuita para uso pessoal não comercial, específica para Windows. 11 O usuário faz login no sistema e visualiza sua lista de contatos. 11 Dados de áudio e vídeo são trocados por P2P entre os participantes, se possível, utilizando apenas uma porta UDP. 11 Em caso de falhas, utiliza tunelamento HTTP ou SSL. 11 Há também um servidor para autenticação e controle da comunicação. É possível licenciar o servidor para instalação local. O VSee é uma ferramenta proprietária de videoconferência específica para Windows que segue o formato de aplicativos para troca de mensagens instantâneas, como MSN, Gtalk e

q

Skype. O usuário instala a aplicação, 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 vídeo, fazer reuniões, compartilhar aplicações e rea Administração de Videoconferência

lizar outras atividades em sistemas de videoconferência. Apesar de ser uma solução proprietária, o VSee é livre para uso pessoal não comercial. Para uso comercial, o produto oferece diferentes planos. Um plano inclui a instalação 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 soluções como Skype, WebEx, Polycom, Adobe e Cisco. 11 Funciona em qualquer tipo de rede, inclusive em redes wireless e 3G/EVDO. Adapta transmissão automaticamente conforme a rede.

q

264

A troca de dados de áudio e vídeo no VSee é feita com P2P entre os participantes, sempre que possível. Para isso é utilizada apenas uma porta UDP, o que reduz os problemas com bloqueio em firewalls. Em caso de falha desse método, é utilizado tunelamento HTTP ou SSL. Apesar disso existe um servidor VSee usado para autenticação e controle da comunicação entre os clientes. Principais características do VSee: 11 Facilidade de compartilhar aplicações e desktop (one click sharing ): utiliza-se a própria aplicação para abrir os arquivos e compartilhar aquela tela. O VSee cria uma barra de botões no topo da aplicação compartilhada, que serve para utilizar ferramentas de quadro branco, disponibilizar o controle remoto e cancelar compartilhamento. 11 Vídeo de alta resolução; 11 Transferência de arquivos simples por “drag&drop”; 11 Compartilhamento de vídeos; 11 Controle remoto de câmera; 11 Chat público e privado; 11 Utiliza criptografia AES de 256 bits; 11 Permite gravação local das videoconferências. 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”. Após a instalação, deve ser feito o login no sistema ou então criar uma nova conta, tarefas realizadas através da mesma interface.

Figura 10.13 Telas de login e de criação de conta no VSee.

Ao fazer login, é exibida a lista de contatos do usuário e o seu vídeo, que já inicia habilitado e pronto para transmissão.

265

Capítulo 10 - Videoconferência em desktop

Figura 10.14 Lista de contatos e vídeo do usuário.

A partir deste ponto utiliza-se a ferramenta clicando nos contatos ou nos ícones na tela do vídeo local, onde pode-se iniciar reuniões, compartilhar arquivos e aplicações, iniciar e parar a gravação da videoconferência, entre outras funções. A próxima figura exibe imagens da aplicação em execução com múltiplos vídeos, chat e compartilhamento de aplicações.

Administração de Videoconferência

Figura 10.15 VSee com múltiplos vídeos e janela de chat.

266

Figura 10.16 Barra de ferramentas inserida pelo VSee em uma aplicação compartilhada.

Citrix GoToMeeting
Uma das soluções de videoconferência da Citrix: 11 GoToMeeting: foco em reuniões. 11 GoToWebinar: para seminários e apresentações. 11 GoToTraining: treinamentos e aulas remotas. Não é 100% web, sendo necessário instalar uma aplicação na máquina do usuário. 11 Basta acessar o website do GoToMeeting: a instalação é automática. 11 Possui as funcionalidades e facilidades de um sistema de webconferência (HDFaces). 11 Ferramenta utilizada como base nas soluções da Citrix para incluir transmissão de vídeo em alta qualidade. 11 Suporta até 6 vídeos de 640x320p 11 ou 1 vídeo de 1920x960p O Citrix GoToMeeting é uma das soluções de videoconferência da empresa Citrix. Entre as soluções desta empresa destacam-se: 11 Sistema com foco em reuniões, com suporte para até 15 participantes; 11 Apresentações e seminários, suportando até mil participantes; 11 Utilizado para treinamentos e aulas remotas, com suporte a até 200 participantes. O GoToMeeting foi desenvolvido a princípio como um sistema para compartilhar a tela de

q

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 videoconferência completo, sendo também expandido para gerar os sistemas GoToWebinar e GoToTraining. A versão com compartilhamento de vídeo foi incluída recentemente com a ferramenta HDFaces, que será comentada adiante. O GoToMeeting é oferecido apenas em forma de serviço, por cerca de 50 dólares mensais. A capacidade neste plano é de até 15 participantes. Já os sistemas GoToWebinar e GoToTraining
Capítulo 10 - Videoconferência em desktop

suportam mais participantes, porém a um custo maior. Assim como os sistemas de webconferência citados, possui as funcionalidades básicas deste tipo de sistema: 11 Áudio e compartilhamento de tela. 11 Integração com VoIP. 11 Controle de computador remoto. 11 Ferramentas de desenho. 11 Gravação de reuniões. 11 Compartilhamento de aplicações. 11 Chat.

q

267

O GoToMeeting é considerado um sistema web, pois possui as facilidades e características de um sistema de webconferência, embora necessite da instalação de um sistema próprio na máquina do usuário. Essa instalação, porém, é bastante simples, feita a partir do website do GoToMeeting. A imagem seguinte mostra a aplicação instalada para uso do GoToMeeting. À esquerda, a imagem do ícone localizado na barra de notificações do Windows para acesso à aplicação. À direita, a imagem da aplicação em si, onde podemos ver a lista de usuários (no centro), botões para configurar compartilhamento de desktop e controle remoto (no topo) e chat (na parte inferior), entre outros. Os passos para a utilização 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 aplicação (direita).

Uma novidade das soluções da Citrix é a ferramenta HDFaces, que servirá como base comum para as diversas soluções da empresa e que visa a transmissão de vídeo em alta definição (HD). O HDFaces suporta videoconferências com uma resolução máxima de 1920x960p, que pode ser atingida através de apenas um vídeo, ou pode ser alcançada pela soma das resoluções de até 6 vídeos (6 vídeos de 640x320).

Administração de Videoconferência

Figura 10.18 Demonstração do GoToMeeting com o HDFaces.

268

Outras soluções
Os sistemas citados até aqui foram escolhidos por serem os mais interessantes para os propósitos deste curso. Mas existem outros, entre os quais: 11 Polycom PVX. 11 Isabel Videoconference. 11 Skype (com vídeo). Além dos sistemas que vimos, existem diversas outras soluções, algumas com caracterís-

q

ticas semelhantes e outras muito diferentes, mas todas capazes de transmitir áudio e vídeo em tempo real. Entre os sistemas não 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 proprietário que pode ser encontrado no website da Polycom. Possui uma versão de avaliação (trial) com a limitação de permitir ligações de no máximo 5 minutos (PVX) ou 30 dias (telepresence m100).

Isabel Videoconference
11 Open Source (GPL), com 11 código-fonte em Morfeo-Forge: Isabel Project. 11 Sistema servidor distribuído em Live CD Ubuntu.

q

Isabel Videoconference é uma solução de videoconferência com código aberto (licença GPL), desenvolvida pela Universidade Politécnica de Madrid. O sistema completo pode ser obtido fazendo download do código-fonte da aplicação ou através de um Live CD baseado na distribuição Linux Ubuntu, em que o sistema é distribuído. 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 serviço on-line que provê espaços para realização de videoconferências.

w Principais características do Isabel:
O Global Plaza disponibiliza gravações de videoconferências realizadas com o Isabel, que podem ser acessadas por streaming no website Globalplaza.

q

11 Cliente pode se conectar de duas formas: aplicação web no navegador ou pela aplicação desktop (apenas para Ubuntu 8.04 ou superior). 11 Bloco de notas.
Capítulo 10 - Videoconferência em desktop

11 Quadro branco. 11 Captura e compartilhamento de tela do computador. 11 Cliente SIP.

Skype (com vídeo)
O Skype é muito conhecido para realizar comunicação por áudio via VoIP, mas já pode ser utilizado também para vídeo. Chamadas Skype para Skype são gratuitas, inclusive com vídeo. O Skype é uma aplicação já muito conhecida para comunicação por áudio via VoIP. Há algum tempo já é possível utilizar o Skype também para comunicação com vídeo. Apesar de ser uma

q

aplicação proprietária, ligações de Skype para Skype são gratuitas, inclusive ligações com vídeo. 269

Figura 10.19 Skype fazendo comunicação com áudio e vídeo.

270

Administração de Videoconferência

Roteiro de Atividades 10
Atividade 1 – Utilização 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 gravação da videoconferência. 11 Em grupo de até quatro alunos, crie uma videoconferência com os integrantes do grupo e teste o ViEVO.

Atividade 2 – Utilização 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, aplicações (PPT e vídeos), compartilhamento do navegador, chat e gravação de vídeos. 11 Em grupo de até quatro alunos crie uma videoconferência com múltiplos participantes.

271

Capítulo 10 - Roteiro de Atividades

272

Administração de Videoconferência

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 Telesaúde. 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 Referência à terminologia e padrões de videoconferência – 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 ideoconferência (documento de referência) – http://penta3.ufrgs.br/RNP/videoconferencia.pdf 11 Videoconferencing cookbook – http://www.vide.net/cookbook/cookbook.en/

274

Administração de Videoconferência

O livro de apoio ao curso Administração de Videoconferência

LIVRO DE APOIO AO CURSO

apresenta os protocolos utilizados para transmissão simultânea de áudio, vídeo e dados. O aluno aprende a planejar, instalar e gerenciar a infraestrutura necessária à operação de um sistema completo de videoconferência. Através da análise das alternativas de implementação, ao final do curso estará apto a especificar a solução de videoconferência mais adequada às necessidades de sua organização; a administrar salas e montar o ambiente adequado para cada situação; a operar o serviço, fornecer suporte aos participantes e resolver os problemas mais comuns. Este livro inclui os roteiros das atividades práticas e o conteúdo dos slides apresentados em sala de aula, apoiando profissionais na disseminação deste conhecimento em suas organizações ou localidades de origem.

Sign up to vote on this title
UsefulNot useful