Administracao de Videoconferencia

Administrao de
Videoconferncia
Graciela M. L. Martins
Leonardo Daronco
Valter Roesler
Administrao de
Videoconferncia
Leonardo Daronco
Valter Roesler
Administrao de
Videoconferncia
Leonardo Daronco
Valter Roesler
Rio de Janeiro
Escola Superior de Redes
2013
Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP

Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho

Coordenao
Luiz Coelho
Edio
Pedro Sangirardi
Coordenao Acadmica de Mdias de Suporte Colaborao Digital
Renato Duarte
Equipe ESR (em ordem alfabtica)
Celia Maciel, Cristiane Oliveira, Derlina Miranda, Edson Kowask, Elimria Barbosa,
Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato e Sergio de Souza
Capa, projeto visual e diagramao
Tecnodesign
Verso
3.0.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuio
Rua Lauro Mller, 116 sala 1103

22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP)

M381a
Martins, Graciela M. L.

Administrao de Videoconferncia / Graciela M. L. Martins, Valter Roesler; Colaborao

de Daniel Weber e Leonardo Daronco. 3. ed. Rio de Janeiro: RNP/ESR, 2011.

290 p. : il. ; 28 cm.

Bibliografia: p. 273-274.
ISBN 978-85-63630-14-8

1. Videoconferncia. 2. Transmisso de udio e vdeo. 3. Padres de vdeo. I. Roesler,

Valter. II. Weber, Daniel. III. Daronco, Leonardo. IV. Ttulo.

CDD 006.7
Sumrio
1. Conceitos fundamentais e solues
Histrico da videoconferncia1
Videoconferncia hoje3
Definio de videoconferncia4
Objetivos da videoconferncia 4
Elementos de uma video/webconferncia5
Tipos de videoconferncia7
Sistemas dedicados7
Sistemas de mesa8
Sistemas de webconferncia9
Cenrios: Ensino a Distncia (EAD)10
Cenrios: reunies de trabalho11
Cenrios: telepresena12
Cenrios: Telemedicina12
Dispositivos adicionais13
Cmera de documentos13
Quadro interativo14
Sistemas com alta definio15
Relao de aspecto16
Estruturao de um servio17
Roteiro de Atividades 121
Atividade 1 Sistema de conferncia em desktop21
Atividade 2 Funcionalidades do sistema21
Atividade 3 Medindo o atraso da transmisso22
iii
2. Padres de videoconferncia
Introduo a padres e protocolos23
Padronizao23
Princpios de codificao de udio24
Padres de udio27
Princpios de codificao de vdeo28
Redundncia espacial29
Redundncia temporal30
Redundncia psicovisual30
Redundncia de codificao (entrpica)31
Padres de vdeo31
H.26433
MPEG33
Padres de dados35
Padres de comunicao 36
Padro H.32036
Padro H.32337
Multipoint Control Unit (MCU)39
Gateway40
Gatekeeper41
Elementos de borda43
Protocolos da arquitetura H.32343
Protocolos RTP e RTCP44
Protocolo H.225 RAS46
Protocolo H.225 sinalizao de chamada49
Protocolo H.24550
Procedimentos de uma conexo H.32354
Padres para servios 57
Atividade 1 Anlise de troca de mensagens direta entre dois clientes 59
Atividade 2 Anlise de troca de mensagens entre dois clientes com gatekeeper60
3. Plano de numerao e gatekeeper

Padro ITU E.16461
iv
Plano de numerao62
Plano de discagem63
Gatekeeper GnuGK64
Instalao do GnuGK65
Inicializao do GnuGK65
GnuGK no Windows66
Configurao do GnuGK (Windows, Linux e outros)66
Monitoramento do GnuGK68
Zoneamento70
Hierarquia de gatekeepers72
Mensagens LRQ73
Reescrita de nmeros E.16475
Autenticao77
Contabilizao81
Modos de operao83
Modo direto83
Modo roteamento84
Modo proxy84
Atividade 1 Configurando o cliente e efetuando chamadas89
Atividade 2 Configurando GnuGK para conexo de clientes autorizados89
Atividade 3 Habilitando modo proxy90
Atividade 4 Configurando o DGK na rede90
4. Introduo ao SIP
Session Initiation Protocol (SIP)93
Arquitetura do SIP94
Mensagens e respostas SIP97
Registro SIP100
Diagrama de uma chamada SIP101
Comparao SIP e H.323102
OpenSIPS103
Instalao OpenSIPS 104
Inicializao OpenSIPS 104
v
Arquitetura modular OpenSIPS 106

Configurao OpenSIPS 107
Lgica de roteamento108
Modos de operao OpenSIPS 109
Integrao com banco de dados OpenSIPS 111
Localizao de usurios OpenSIPS 113
Plano de discagem OpenSIPS 113
Autenticao de clientes OpenSIPS 115
Contabilizao OpenSIPS 117
Gerao de logs OpenSIPS 118
Atividade 1 Ligao SIP atravs do X-Lite121
Atividade 2 Configurao e utilizao de um servidor SIP: OpenSIPS121
Atividade 3 Incluir validao de usurios no OpenSIPS122
5. Redes de computadores e videoconferncia

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

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

Streaming de vdeo213
Streaming x Download progressivo 214
Solues para transmisso e gravao215
Solues baseadas em software216
Requisitos principais para streaming e gravao218
Servidores de streaming em software219
Atividade 1 Utilizao do Windows Media Server223
Atividade 2 Transmisso de contedo com a sute Flash Media223
9. Videoconferncia web
Conferncia Web (webconferncia)225
viii
Modelos de servio de webconferncia227

Solues de conferncia web228
Adobe Connect229
Ingressar em uma sesso230
Interface do cliente230
Papis (permisses) dos usurios231
Compartilhamento de udio e vdeo232
Compartilhamento de documentos, tela e quadro branco232
Bate-papo (chat)234
Outros pods234
Layouts235
rea do apresentador236
Dispositivos mveis236
Funcionalidades administrativas236
Cisco WebEx237
FuzeMeeting239
Google Hangout241
BigBlueButton (BBB)241
Mconf244
OpenMeetings247
Outras solues249
Spreed249
Elluminate Live!250
WebHuddle251
Atividade 1 Administrao e utilizao do Adobe Connect253
Atividade 2 Utilizao do Mconf253
Atividade 3 Utilizao do Google Hangout253
10. Videoconferncia em desktop

IVA255
EVO262
VSee264
Citrix GoToMeeting267
Outras solues269
ix

Atividade 1 Utilizao do EVO271
Atividade 2 Utilizao do VSee271
Bibliografia 273

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa
(RNP) responsvel pela disseminao do conhecimento em Tecnologias da Informao
e Comunicao (TIC).
A ESR nasce com a proposta de ser a formadora e disseminadora de competncias em
TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica
do corpo funcional das organizaes usurias da RNP, para o exerccio de competncias
aplicveis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao
Digital e Governana de TI.
A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao
e execuo de planos de capacitao para formao de multiplicadores para projetos
educacionais como: formao no uso da conferncia web para a Universidade Aberta do
Brasil (UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.
A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema
semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias.
Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.
xi
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas
de estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de
atuao do futuro especialista que se pretende formar.
As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de
tempo para as atividades prticas, conforme descrio a seguir:
Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor
levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando
a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que
o aluno se coloque em posio de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).
Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades
proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar
dvidas e oferecer explicaes complementares.
Terceira etapa: discusso das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das solues possveis para
resolv-la, devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so
convidados a comentar as solues encontradas e o instrutor retoma tpicos que tenham
gerado dvidas, estimulando a participao dos alunos. O instrutor sempre estimula os
alunos a encontrarem solues alternativas s sugeridas por ele e pelos colegas e, caso
existam, a coment-las.
Sobre o curso
O livro de apoio ao curso composto de 10 captulos sobre os diversos aspectos necessrios a uma compreenso mais aprofundada dos sistemas de videoconferncia. A apresentao dos conceitos tericos consolidada com atividades prticas que reforam o
aprendizado. O livro aborda questes como fundamentos de videoconferncia, padres
internacionais de videoconferncia (H.323 e SIP), gerncia de sistemas de videoconferncia,
ambientes de videoconferncia, streaming e uso de aplicativos de videoconferncia.
O foco do livro est sobre os diferentes tipos de conferncia com vdeo, implantao e administrao de solues de videoconferncia, e nas melhores prticas para a elaborao de projetos
de ambientes adequados para a realizao dos diferentes tipos de videoconferncia.
A quem se destina
O pblico-alvo deste curso amplo, incluindo administradores de sistemas de videoconferncia, gerentes de projeto relacionados a vdeo, profissionais interessados em transmisso
de eventos via streaming, ou qualquer pessoa que necessite de um maior embasamento
para solucionar problemas em ambientes de videoconferncia. desejvel que os participantes tenham conhecimento prvio em redes de computadores e no uso de sistemas Linux.
xii
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro:
Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da
sada de comandos.
Contedo de slide
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo
Indica um documento como referncia complementar.
Smbolo
Indica um vdeo como referncia complementar.
Smbolo
Indica um arquivo de adio como referncia complementar.
Smbolo
Indica um aviso ou precauo a ser considerada.
Smbolo
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.
Smbolo
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: MARTINS, Graciela; DARONCO, Leonardo; ROESLER, Valter. Administrao
de Videoconferncia. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br
xiii
Sobre os autores
Graciela M. L. Martins tem 14 anos de experincia na rea de TI. Graduada em Cincia da
Computao pela UNESP. Especializou-se em Aplicaes de Comunicao e Colaborao na
Internet durante o mestrado realizado na USP e, posteriormente, em Gesto Estratgica
da Inovao Tecnolgica pela UNICAMP. Atua na RNP na gesto de programas e projetos
visando o provimento de solues de TIC para as reas de Educao e Cultura. Foi uma das
responsveis pela estruturao inicial do servio de webconferncia provido pela RNP.
Leonardo Daronco formado em Cincia da Computao pela Universidade Federal de
Santa Maria (2007) e tem mestrado em Cincia da Computao pela Universidade Federal
do Rio Grande do Sul (2009). Tem experincia em assuntos relacionados multimdia, codificao de vdeo, redes de computadores e programao. Trabalha atualmente no grupo de
pesquisa PRAV (Projetos em udio e Vdeo) da Universidade Federal do Rio Grande do Sul
(UFRGS), com pesquisa e desenvolvimento de sistemas multimdia para webconferncia,
ensino a distncia e desenvolvimento em dispositivos mveis e sistemas web.
Valter Roesler formado em Engenharia Eltrica pela Universidade Federal do Rio Grande
do Sul (1988), com mestrado (1993) e doutorado (2003) em Cincia da Computao pela
UFRGS. Atualmente Professor Adjunto na Universidade Federal do Rio Grande do Sul.
Tem experincia na rea de cincia da computao, com nfase em redes de computadores, atuando principalmente nos temas: Telemedicina, Tele-educao, Multimdia, Redes
de Computadores, Codificao de Vdeo e TV Digital. Coordenador do laboratrio do PRAV
(Projetos em udio e Vdeo). Lder do grupo de pesquisa do Ncleo de TV Digital da UFRGS
e Ncleo de Telessade, no diretrio dos grupos de pesquisa CNPq.
Renato Duarte formado em Cincia da Computao pela UniCarioca e trabalha h treze
anos na rea. Atualmente responsvel pela rea acadmica de Mdias de Suporte Colaborao Digital e coordena a equipe de analistas das unidades da Escola Superior de Redes
da Rede Nacional de Ensino e Pesquisa (ESR-RNP). responsvel pela infraestrutura de TI
de apoio coordenao da ESR, e pelo preparo e validao dos laboratrios para execuo
das atividades prticas dos cursos da ESR.
xiv
1
objetivos
Conceitos fundamentais e solues

Familiarizar o aluno com os princpios e conceitos fundamentais associados
videoconferncia, bem como gerar um nivelamento entre os diferentes
conceitos existentes.
ferncia sncrona e assncrona, taxa de quadros por segundo, resoluo, banda, atraso,
relao de aspecto.
conceitos
Cenrios e aplicaes de videoconferncia, tipos de sistemas de videoconferncia, con-
Histrico da videoconferncia
Este telefone apresenta muitas deficincias para ser considerado seriamente como um meio de
comunicao. O dispositivo inerentemente sem valor para ns.
Esta frase foi traduzida de um memorando interno da companhia Western Union do ano de
1876*, e mostra a capacidade de mudana e evoluo da tecnologia. Hoje sabemos como
eles estavam enganados. Este mesmo problema j esteve tambm relacionado aos sistemas
de videoconferncia em seu incio, mas com o avano da tecnologia ficou claro que os sistemas de videoconferncia so de grande utilidade.
Fonte: http://www.princeton.edu
Figura 1.1
Picture phone
AT&T 1964.
Os sistemas de videoconferncia foram criados em meados da dcada de 1960. Para se ter

uma ideia, desde 1970 as centrais telefnicas j suportavam teleconferncias baseadas em
udio, mas conferncias por vdeo ainda no eram uma realidade. Foi a partir da dcada de
1980, porm, que os rumos da pesquisa e desenvolvimento caracterizaram esses sistemas
Captulo 1 - Conceitos fundamentais e solues
do modo como so atualmente conhecidos.

1
O primeiro sistema de videoconferncia data de 1964, ano em que a empresa americana

AT&T apresenta o picture phone em uma feira em Nova York, e o mundo conhece o primeiro
telefone com imagem da histria das telecomunicaes. O aparelho foi introduzido no
mercado em 1970 e comercializado por cerca de U$ 160 dlares mensais. Um ano depois,
a Ericsson lanou o primeiro vdeo-telefone transatlntico.
Figura 1.2
Servio da Bell
System.
A dcada de 1980 marcada por avanos na pesquisa em transmisso de dados. Aproveitando a iniciativa da Arpanet, foram realizados vrios experimentos com transmisso de voz
em pacotes digitais, impulsionando o desenvolvimento de protocolos especiais para
tratamento destes pacotes, como o Network Voice Protocol (1973) e, mais tarde o Packet
Video Protocol (1981).
Em 1982 lanada a recomendao H.120 para codificao de vdeo, abrindo caminho para
o surgimento da recomendao H.320, voltada para videoconferncia. A dcada de 1990
continuou marcada por seguidas recomendaes e pelo surgimento de padres para regulamentar o desenvolvimento de sistemas de videoconferncia. Tambm nessa dcada so
conhecidos os primeiros sistemas de videoconferncia comercializados no mercado pelas
empresas Compression Lab, PictureTel e Mitsubishi. Vrios acontecimentos marcaram a
evoluo dos sistemas de videoconferncia, como:
11
1990: surge a recomendao para conferncia ISDN.
11
1991: primeira videoconferncia com udio e vdeo utilizando o codec H.261.
11
1992: lanado o sistema de videoconferncia CU-SeeMe, inicialmente apenas para
Macintosh e sem udio.
11
1993: suporte a multiponto.
11
1994: suporte a udio e verso para Windows.
Administrao de Videoconferncia
11
1996: lanada a primeira verso da recomendao H.323 e do NetMeeting pela Microsoft.
11
1998: lanadas a segunda verso da recomendao H.323 e a primeira verso do padro
MPEG-4 para compresso de vdeo.
11
1999: lanadas a terceira verso da recomendao H.323 e a segunda verso do padro
MPEG-4 para compresso de vdeo; o IETF divulga o SIP.
11
2000: Samsung lana o primeiro MPEG-4 streaming 3G.
11
2001: realizada a primeira telecirurgia transatlntica.
11
2003: lanado o padro H.264; disseminao de redes de banda larga; maior acessibilidade a vdeo; uso de videoconferncia na educao.
A partir da dcada de 1990, vrios aplicativos comearam a ganhar espao no mercado

mundial, sobretudo para envio e recebimento de informaes de udio e vdeo sobre redes
TCP/IP. Cada vez mais, aplicativos para o envio de udio e vdeo exploravam e aprimoravam
as tcnicas para compresso de dados, permitindo a comunicao de usurios em rede com
baixo custo e padro de qualidade aceitvel.
A popularizao dos sistemas de videoconferncia foi impulsionada pela recomendao
H.323 feita pela ITU-T em 1996, que permitiu o desenvolvimento padronizado de diversas
solues de software para videoconferncia. Atualmente, as solues para sistemas de
videoconferncia so comumente utilizadas no nosso dia a dia, seja na comunicao entre
pessoas na internet ou integradas ao cotidiano das grandes corporaes. A utilizao desses
sistemas extrapolou a rea de negcios, estando hoje presente em atividades de ensino a
distncia, de telemedicina e de pesquisa cientfica, alm de muitas outras aplicaes.
No Brasil, o mercado para sistemas de videoconferncia acompanha a tendncia de
crescimento mundial. Cada vez mais empresas e usurios domsticos tm lanado mo
desse recurso para realizar atividades do dia a dia, como conversar com amigos distantes
ou tomar decises de negcios em reunies no presenciais. Portanto, possvel dizer
que estamos caminhando para o mundo das solues multimdia sobre redes IP, que no
constituem apenas uma tendncia da atualidade, mas sim uma necessidade para incluso
em um mercado a cada ano mais competitivo, gil e rpido, demandando mais recursos
para facilitar o relacionamento entre as empresas. Nesse sentido, nos prximos anos, a
videoconferncia ser uma das ferramentas mais importantes no cenrio dos negcios e da
comunicao interpessoal.
Videoconferncia hoje
Leia o artigo de Lori

Wilkerson sobre a
histria da videoconferncia: The History
of Video Conferencing
- Moving Ahead at the
Speed of Video.
w H.323
Na sua 7 verso, o padro mais consolidado para videoconferncia.

H.320
Ainda bastante utilizado nas corporaes, embora tenda a ser substitudo por sistemas
baseados em IP.
SIP
Consolidado para telefonia sobre IP.
Webconferncia
O surgimento de clientes web tem possibilitado a realizao de conferncias via web.
Essa forma alternativa de videoconferncia tem se destacado pela facilidade de uso.
Atualmente, existem padres j consolidados para a realizao de videoconferncias, que
sero vistos ao longo do curso. O H.323 o padro mais consolidado e encontra-se em sua
7 verso. O H.320, para uso em redes ISDN (Integrated Services Digital Network) outro
padro bastante consolidado, mas tende a ser substitudo pelos sistemas baseados em IP,
como o H.323. Outro padro que vem crescendo o SIP. Inicialmente utilizado apenas para
telefonia sobre IP (nicho dominado pelo SIP), vem sendo cada vez mais utilizado para videoconferncias. Outro tipo de videoconferncia que vem crescendo conhecido como webconferncia, se destacando pela facilidade de uso. As webconferncias sero abordadas adiante.
Saiba mais
Definio de videoconferncia
Antes de definir o termo videoconferncia, importante comentar sua diferena em
relao ao termo webconferncia.

Vdeo + Conferncia
Conferncia onde h interao entre duas ou mais pessoas atravs de vdeo e normalmente tambm de udio.
Web + Conferncia
A palavra indica uma comunicao via web (internet), no necessariamente envolvendo
vdeo (apesar de normalmente ser utilizado).
Videoconferncias so normalmente realizadas de trs formas: atravs de softwares
instalados em computadores pessoais, via hardwares dedicados e ainda pela utilizao
do navegador web no computador pessoal. Com a padronizao dos sistemas web atuais,
normalmente no necessrio instalar qualquer software adicional, bastando instalar um
plug-in no navegador para que o usurio obtenha todas as funcionalidades da conferncia.
importante observar que a palavra conferncia sugere a participao de trs ou mais
pessoas. Entretanto, uma videoconferncia pode ser realizada entre duas ou mais pessoas.
Objetivos da videoconferncia
Comunicao em tempo real entre duas ou mais pessoas geograficamente dispersas,
normalmente em locais diferentes, atravs de udio e vdeo.

A videoconferncia um recurso facilitador da comunicao entre pessoas. Por intermdio
de uma videoconferncia, duas ou mais pessoas participam de uma discusso e, embora se
encontrem em lugares diferentes, podem ver e ouvir umas s outras como se estivessem
reunidas no mesmo local. A grande vantagem dos sistemas de videoconferncia consiste em
viabilizar a comunicao em tempo real entre grupos de pessoas, com o uso simultneo de
udio e vdeo, independentemente de sua localizao geogrfica. Assim, torna-se possvel
trabalhar cooperativamente por meio do compartilhamento de informaes e de outros
materiais de trabalho como documentos, imagens ou planilhas sem qualquer nus proveniente da distncia geogrfica.
Outras possibilidades da videoconferncia:
11
Compartilhamento e apresentao de slides.
11
Compartilhamento de aplicaes.
11
Bate-papo por chat.
11
Quadro branco (colaborativo).
11
Troca de arquivos.
Alm da troca de udio e vdeo entre os participantes, os sistemas atuais tm disponibilizado diversas outras ferramentas que melhoram a comunicao e criam novas possibilidades para as videoconferncias. Entre essas ferramentas esto bate-papo por chat,
compartilhamento de apresentaes, quadro branco colaborativo, troca de arquivos e
compartilhamento de aplicaes. Esta ltima ferramenta normalmente est presente nos
sistemas de videoconferncia de desktop e mostra claramente a integrao que um sistema
de videoconferncia pode ter com o sistema base sobre o qual executado (no caso a integrao com o sistema operacional). Com a evoluo da tecnologia e a reduo dos custos
nos ltimos anos, a videoconferncia passou a ser usada como ferramenta de colaborao,
aprendizagem e entretenimento. As videoconferncias evoluram muito nos ltimos anos e
ferramentas como as citadas j so comuns em muitos sistemas. Apesar disso, os sistemas
continuam sendo chamados de videoconferncia.
Pode-se fazer uma analogia desta situao com a evoluo do telefone celular, que deixou
de ser apenas um dispositivo para efetuar e receber ligaes telefnicas para se tornar um
computador porttil, que pode inclusive realizar videoconferncias. Apesar dessa evoluo,
eles continuam sendo chamados de telefones celulares, mesmo que ligaes telefnicas
no sejam, em alguns casos, a ferramenta mais utilizada do dispositivo.
Elementos de uma video/webconferncia

11
Vdeo e udio
11
Codificao e decodificao
11
Transmisso e recepo
11
Equipamentos de udio e vdeo
Vdeo e udio
A primeira etapa para uma videoconferncia consiste na captura e digitalizao dos sinais
de udio e vdeo que sero transmitidos. Para tal, existem diversos dispositivos diferentes.
O vdeo pode ser capturado por cmeras variando desde webcams de baixo custo (que normalmente apresentam baixa qualidade) at cmeras profissionais que garantem alta qualidade
(HD). Atualmente j existem cmeras pessoais capazes de capturar vdeo em alta resoluo.
O udio normalmente capturado por dispositivos de headset (fone de ouvido com microfone) quando se deseja maior privacidade, ou por microfones, que podem ser de diversos
modelos, conforme seu propsito.
Transmisso
Codicao
Decodicao
udio
udio e vdeo
Figura 1.3
Elementos bsicos
de videoconferncia.
Codificao e decodificao
Aps a captura e digitalizao, os dados so codificados (o que inclui sua compresso) para
que possam ser transmitidos pela rede. O elemento essencial para este processo o codec
(COdificador/DECodificador), que atua nas funes de codificao e decodificao. A etapa
de compresso algortmica fundamental para otimizar a transmisso das informaes.
O sinal original reduzido para um tamanho n vezes menor atravs da codificao, o que
Vdeo
possibilita a transmisso dos dados e tambm a adaptao da transmisso conforme a rede

disponvel. No lado do receptor, o codec realiza a decodificao, que consiste em transformar os dados novamente para seu formato original, o que permite sua reproduo.
Os codecs utilizados normalmente so os baseados em normas internacionais da ITU-T,
e muitas vezes MPEG para vdeo. possvel afirmar que todos os sistemas de videoconferncia utilizam o mesmo conjunto de codecs, ou uma variao deste conjunto. Ou seja, os
codecs mais comuns para udio e vdeo normalmente so suportados por diversos sistemas
de videoconferncia. O que difere de um sistema para outro so os mecanismos de compresso, ou seja, a parametrizao da compresso algortmica adotada pelo fabricante.
Transmisso e recepo
Aps a codificao, os dados esto prontos para serem transmitidos. A transmisso depender das caractersticas da rede, onde um parmetro extremamente importante a banda
disponvel, que utilizada para configurao da codificao de udio e vdeo. A qualidade da
rede muitas vezes monitorada e utilizada para modificar a parametrizao da codificao
de udio e vdeo. Se a rede est congestionada, por exemplo, o monitor de rede pode fazer
com que a codificao do vdeo seja reduzida de 1 Mbit/s para 350 Kbit/s ou menos, reduzindo a qualidade do vdeo, mas ainda assim permitindo que a videoconferncia continue
funcional. Essa questo da adaptao automtica s condies da rede ainda mobiliza a pesquisa, apesar de estar bastante consolidada.
A organizao dos pacotes na rede feita com base em protocolos de rede, que muitas
outras vezes so baseados em padres abertos como o Real-time Transport Protocol (RTP),
mas que outras vezes so protocolos proprietrios dos desenvolvedores do software ou
hardware que est sendo utilizado. Um protocolo indispensvel para que se saiba como os
dados esto trafegando na rede e para possibilitar a recepo e organizao dos dados que
esto sendo recebidos.
Equipamentos de udio e vdeo

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

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

Ao contrrio dos sistemas dedicados, no exigem equipamentos especiais e caros. Sistemas
desktop normalmente so vantajosos em relao ao custo (so executados em mquinas de
propsito geral, alm de poderem usar softwares freeware), mas a qualidade da videoconferncia depender do hardware com que o sistema est sendo executado. Esses sistemas
normalmente apresentam mais funcionalidades adicionais, como quadro interativo, compartilhamento de aplicaes, compartilhamento de slides, entre outros.
So normalmente compostos por um servidor, responsvel por coordenar as diversas

sesses/salas de participantes, e os clientes, que utilizam o navegador web. Esses sistemas
tambm apresentam funcionalidades adicionais, como quadro interativo, compartilhamento
de aplicaes, slides, e assim por diante.
Sistemas dedicados
Todos os componentes (hardware e software) requeridos esto em um nico equipamento, que conectado a uma televiso ou monitor e rede de dados.
O controle do equipamento normalmente feito distncia, por controle remoto,
incluindo o controle da cmera (movimentao, zoom etc.). Existem modelos para diferentes propsitos: grupos grandes, grupos pequenos e ambientes individuais.
Sistemas de webconferncia
Os sistemas dedicados foram desenvolvidos principalmente para utilizao de grupos

de usurios, em salas de videoconferncia: so sistemas dedicados, geralmente com alta
capacidade de processamento e prticos para instalao. O equipamento (algumas vezes
chamado de codec) composto por um hardware dedicado, construdo especificamente
para videoconferncias, os softwares necessrios para configurar e utilizar o hardware e
diversas entradas e sadas para perifricos. Normalmente os equipamentos j possuem uma
cmera acoplada e so acessados a distncia por controle remoto. Alm disso, esses sistemas podem ser integrados a diversos perifricos, tais como: televisor, computador, videocassete, cmera de documentos e cmera auxiliar. Apesar da diferena existente entre as
diversas marcas, verses e tipos de equipamentos, uma caracterstica comum dos sistemas
dedicados topo de linha a maior qualidade. Como possuem um hardware dedicado de
alto desempenho, estes equipamentos conseguem utilizar resolues altas (vdeo em HD) e
altas taxas de transmisso, o que garante qualidade de udio e vdeo.
Outra caracterstica importante dos sistemas dedicados a praticidade. Eles j contm
todos os componentes e aplicaes necessrias para realizar uma videoconferncia, sendo
que normalmente s necessrio conectar o equipamento a um monitor, rede de dados,
realizar algumas configuraes e ele j pode ser utilizado. So equipamentos que dificilmente
requerem manuteno e teoricamente so imunes a vrus. O reflexo das vantagens citadas
para os dispositivos dedicados visto no custo dos equipamentos, que costuma ser alto e
representa a maior desvantagem que eles apresentam. Alm disso, este tipo de equipamento
geralmente s permite atualizaes para recursos especficos quando estiverem disponveis.
Polycom V500
Tandberg 990 MXP
Polycom VSX 7000s
Os sistemas dedicados so utilizados por aplicaes que primam pela alta qualidade na
transmisso de udio e vdeo, tais como: ensino a distncia, palestras, reunies, telemedicina.
Apesar de serem utilizados principalmente em ambientes coletivos, eles tambm podem ser
utilizados individualmente. Hoje em dia, vrias empresas disputam o mercado dos sistemas
de videoconferncia de grande porte, entre elas Polycom, Cisco, Tandberg e Sony.
Sistemas de mesa
Recursos agregados ao computador pessoal para torn-lo adequado para uma videoconferncia:
11
Computador com suporte multimdia
11
Microfone e caixas de som
11
Cmera de vdeo
11
Software (EVO, VSee, Ekiga etc.)
Figura 1.4
Sistemas
dedicados para
videoconferncia.
O grande diferencial dos sistemas de mesa est no aproveitamento do computador, que

j um equipamento amplamente difundido e utilizado. Estes sistemas normalmente so
voltados para uso individual. Para utilizar um sistema deste tipo necessria a instalao
de software, microfone, cmera, e possivelmente outros componentes, que so facilmente
acoplados a um computador pessoal, conforme pode ser visto na figura.
Figura 1.5
Estrutura de
videoconferncia
de mesa.
A qualidade de som e imagem depende da qualidade da rede de transmisso e da capacidade de processamento da mquina. Atualmente, a maioria das solues pode operar em
taxas que variam de 64 Kbit/s a 2 Mbit/s. Um dos pioneiros nesse ramo foi o sistema da
White Pine / First Virtual Communication, o CU-SeeMe, que disponibiliza recursos para os
usurios se comunicarem uns com os outros atravs de conexes ponto-a-ponto ou multiponto. O sistema adota o padro H.323, adequado para operaes em redes corporativas IP
e na internet.
O software EVO, da Caltech, outro exemplo de sistema de mesa que tem evoludo muito
nos ltimos tempos. Ele conta com suporte H.323, SIP, chat, vrios vdeos simultneos e
diversos outros recursos. Outros softwares conhecidos so o Windows Messenger, Microsoft
Office Live Meeting, MSN Messenger e Windows Live Messenger. No Windows Vista chama-se Windows Meeting Space. Ao longo deste curso, o aluno poder utilizar para seu estudo
o software Polycom Telepresence m100 ou ento o sistema de software livre Ekiga. Ambos
Figura 1.6
Exemplos de
sistema de
videoconferncia
de mesa.
EVO
Vsee
Sistemas de webconferncia
Utilizam o navegador web para efetuar a conferncia:
11
Computador com suporte multimdia.
11
Microfone e caixas de som (ou headset).
Ekiga
suportam SIP e H.323.
11
Cmera de vdeo (webcam, handycam etc.).
11
Navegador web no cliente.
11
Necessitam de mquina servidora para gerncia.
A grande vantagem dos sistemas de webconferncia est na facilidade de efetuar uma videoconferncia, visto que no necessrio para o usurio participante instalar qualquer tipo
de software na sua mquina, pois tais sistemas funcionam via navegador web. Nesse tipo
de sistema, um administrador da conferncia normalmente cria uma sala virtual e convida
os participantes. Essa sala virtual gerenciada por um servidor localizado em algum ponto,
porm isso transparente para os usurios.
Assim, os sistemas de webconferncia no s aproveitam o computador do usurio, mas
tambm aproveitam seu navegador web, bem como a porta destinada ao navegador, que
normalmente liberada no firewall, no demandando qualquer liberao de porta aos
administradores de rede, o que muitas vezes pode ser traumtico numa empresa com polticas rgidas de segurana.
Figura 1.7
Exemplos de
sistemas de
webconferncia.
Adobe Connect
Cenrios: Ensino a Distncia (EAD)

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

Em comparao ao cenrio de EAD, reunies de trabalho normalmente so compostas por
um nmero menor de participantes e tero muito mais interao entre os pontos remotos,
ou seja, uma discusso, no uma palestra.
As reunies so realizadas em salas usualmente com uma mesa ao centro e o equipamento
de videoconferncia em uma de suas pontas. Algumas vezes so utilizadas telas grandes
para aumentar a sensao de que as pessoas esto no mesmo local (ver o cenrio de
telepresena a seguir). Por ser uma discusso, os participantes devem ter acesso fcil aos
Figura 1.9
Estrutura do
sistema IVA.
microfones, e para isso costumam ser utilizados microfones multidirecionais.

11
Figura 1.10
Federal Emergency
Management
Agency (FEMA).
Fonte:
http://www.photolibrary.fema.gov
Cenrios: telepresena
Telepresena o nome dado aos sistemas de videoconferncia que procuram reduzir ao
mximo a sensao de distncia entre os pontos remotos, procurando criar a iluso de
que todos estejam em um mesmo ambiente. O cenrio semelhante ao das reunies de
trabalho, mas so utilizadas televises ainda maiores e cuidadosamente posicionadas, para
que as pessoas sejam exibidas com seu tamanho real e paream estar posicionadas no
mesmo ambiente (sentadas na mesma mesa, por exemplo).
Figura 1.11
Exemplo de sala de
telepresena (Cisco).
Cenrios: Telemedicina
Operando desde 2006, a Rede Universitria de Telemedicina, um programa do Ministrio da
12
Cincia, Tecnologia e Inovao (MCTI) e executado pela Rede Nacional de Ensino e Pesquisa
(RNP), formalizou a criao e implantao de ncleos de telemedicina/ telessade, garantindo a conectividade de 55 hospitais universitrios e de ensino rede Ip da RNP. Em 2011,
8 novos ncleos de telemedicina RUTE foram inaugurados, faltando ncleos apenas em trs
estados (PI, RO, RR), que sero inaugurados em 2012. Alm disso, pode-se destacar como
iniciativas bem-sucedidas: 15 salas de videoconferncia homologadas; mais de 600 vdeo e
webconferncias realizadas em 47 especialidades da sade, com participao de 313 instituies; assinatura com a RNP de 28 novos termos de cooperao tcnica com hospitais de
ensino. A partir de 2012, 75 hospitais em todo o pas sero integrados ao projeto.
Para a telemedicina, o fator mais importante de uma videoconferncia costuma ser a qualidade das imagens. Para muitas aplicaes na telemedicina necessria alta qualidade na
resoluo de imagens para permitir, por exemplo, um diagnstico correto de doenas.
Outro exemplo o projeto POA_S@UDE de telemedicina implementado no Hospital Materno
Infantil Presidente Vargas (HMIPV), prximo ao centro de Porto Alegre/RS, onde um sistema
utilizado para realizao de tele-ultrassonografias em pacientes de regies mais remotas,
onde difcil o acesso a mdicos especializados.
Figura 1.12
Mdico remoto
efetua laudo
distncia. Fonte:
http://www.inf.
ufrgs.br/prav/projetos_poasaude.php
Dispositivos adicionais
Alm da troca de udio e vdeo entre os participantes, outro objetivo de uma videoconferncia promover suporte colaborao e cooperao, oferecendo ferramentas que
permitam a interao e o trabalho em grupo. Para tanto, j existem servios de suporte
colaborao que vm sendo agregados aos servios de videoconferncia, visando criar condies para o trabalho cooperativo entre equipes remotamente situadas.
Uma alternativa para servios de colaborao a utilizao de padres internacionais, e um
deles, utilizado para transferncia de dados, o protocolo ITU T.120. Esse protocolo designa
uma famlia de padres abertos que definem prticas para a transmisso de dados. Vrias
empresas adotam o T.120 nas suas respectivas solues, tais como: Apple, AT&T, British
Telecom, Cisco Systems, Intel, MCI, Microsoft e PictureTel.
Os servios de suporte colaborao so implementados por ferramentas geralmente
encontradas nos terminais de videoconferncia. Como exemplos dessas ferramentas,
podemos citar a cmera de documentos, o quadro interativo e o chat. A seguir, detalhamos
Cmera de documentos
Cmera de alta resoluo que captura e transmite imagens de documentos e outros
objetos fsicos. Valoriza e d maior impacto s apresentaes audiovisuais.

A cmera de documentos utilizada para digitalizar documentos, objetos, formas tridimensionais, documentos impressos e material grfico de qualquer natureza. Consiste numa
cmera esttica usada para enviar imagens (transformadas em vdeos) de documentos,
materiais impressos, transparncias, slides e raios-X, alm de objetos tridimensionais.
algumas dessas ferramentas de colaborao visual.
13
Figura 1.13
Cmera de
documentos.
Quadro interativo
Tudo o que escrito ou desenhado no quadro digitalizado, facilitando visualizao remota.
O clique do mouse pode ser feito com o dedo ou caneta diretamente no quadro branco.
Sua aplicao ocorre principalmente em EAD, pois substitui o quadro-negro tradicional
em salas de aula.
O quadro interativo (ou eletrnico) oferece uma espcie de espao virtual compartilhado
pelos participantes, em que todas as aes realizadas so capturadas em tempo real e
disponibilizadas (como vdeos) na videoconferncia. Em outras palavras, esse recurso
permite capturar tudo o que escrito ou desenhado em um quadro branco comum, em
cores e em tempo real, e transmitir esses dados diretamente para o microcomputador ou
sistema de videoconferncia.
StarBoard Hitachi
Entrada RGB, sada USB
Figura 1.14
Exemplos de
quadro interativo.
A seguir veremos outras abordagens para quadros interativos.
Tablet
14
Notebook ultraporttil ( 1 kg) com recursos para escrever ou inserir dados diretamente
na tela por meio de uma caneta metlica. Permite a exibio de vdeos, incluso de anotaes e envio e gravao das imagens. uma alternativa ao quadro eletrnico, j que a
imagem do tablet pode ser projetada em uma tela.
iPad
Figura 1.15
Tablet.
Um tablet um computador porttil (normalmente mais porttil e leve que um notebook)

que permite a insero de dados atravs do contato na tela do computador (multitouch).
O contato normalmente feito atravs de uma caneta ou dedo, que permite que o usurio
desenhe, escreva e insira dados diversos na mquina como se estivesse escrevendo em uma
folha de papel. Os dispositivos normalmente permitem escrever sobre aplicaes e gravar
estas anotaes. Isso torna os tablets muito teis em ambientes escolares, onde as anotaes dos alunos podem ser inseridas sobre as apresentaes do professor, por exemplo.
Dependendo do sistema e das aplicaes utilizadas, tambm possvel converter texto
escrito mo para texto no computador (inclusive equaes).
Sistemas com alta definio

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

um avano tecnolgico significativo nos ltimos anos. Empresas como Polycom, Tandberg e
Sony j disponibilizam equipamentos com alta definio, udio e vdeo de excelente qualidade, o que torna a videoconferncia mais realista e possibilita sua aplicao em outras
reas, como na telemedicina.
Relao de aspecto
a proporo entre a largura e altura e dos pixels que compem uma imagem digital.
11
Vdeo: arquivo widescreen-explanation.swf.
11
Adaptao da relao de aspecto (pillarboxes e letterboxes).
11
Adaptao da relao de aspecto de 16:9 para 4:3.
11
Adaptao da relao de aspecto de 4:3 para 16:9.
Relao de aspecto (aspect ratio) a proporo entre a largura e altura e dos pixels que
compem uma imagem digital. O exemplo mais tradicional a relao 4:3, utilizada na televiso analgica tradicional. Outra relao de aspecto comum atualmente a 16:9, utilizada
em televises HD. Apesar de alguns dispositivos, como DVDs, exibirem contedos de 4:3 em
16:9 e vice-versa, muitas vezes necessrio adaptar esta relao de aspecto para o formato
do dispositivo onde elas sero exibidas. Nestes casos so utilizadas as letterboxes, ou seja,
as barras pretas na parte superior e inferior dos vdeos (ou nas laterais). Elas so utilizadas
16
para que os vdeos possam ser exibidos em sua relao de aspecto original em dispositivos
que utilizam outra resoluo de aspecto sem distorcer as imagens.
Monitor 16:9
Video 4:3
Monitor 4:3
Video 16:9
Figura 1.19
Exemplo de ajuste
4:3 e 16:9.
Para adaptao da relao de aspecto, alm da possibilidade de pillarboxes ou letterboxes,

tambm possvel utilizar outras tcnicas, que normalmente so o redimensionamento do
vdeo e a remoo de alguma rea dele.
Figura 1.20
Tcnica de
redimensionamento
de vdeo.
Redimensionamento
Remoo de reas
Para adaptar um vdeo em 16:9 para monitores 4:3, uma alternativa redimensionar o vdeo,
ou seja, encolher o vdeo horizontalmente at que sua relao de aspecto seja 4:3, o que acaba
deformando as imagens. Uma alternativa remover reas laterais do vdeo, transformando-o em 4:3 sem necessidade de redimensionamento. Esta alternativa costuma ser chamada
de pan and scan, e causa perdas de contedo do vdeo, j que algumas de suas partes sero
completamente removidas. Porm, ela mantm as imagens com seu aspecto original.
Para adaptar um vdeo em 4:3 para monitores 16:9, alm do uso de pillarboxes, possvel
utilizar dois outros mtodos: redimensionamento com e sem remoo de reas. Redimensionar um vdeo 4:3 para 16:9 gera uma expanso horizontal do vdeo, o que acaba deformando as imagens. Outra alternativa remover barras na parte superior e inferior do vdeo
(tornando-o 16:9) e depois redimension-lo para a resoluo desejada. Esta ltima alterna-
Figura 1.21
Tcnica de redimensionamento sem
e com remoo
de reas.
Redimensionamento
Remoo de reas
Estruturao de um servio
Identificar as necessidades dos usurios:
11
Tipo de comunicao: ponto-a-ponto ou multiponto.
11
Qualidade: padro SD ou HD.
11
Tipos de dados que sero compartilhados: documentos eletrnicos ou impressos,
tiva no deforma a imagem, mas gera perda de contedo do vdeo.
vdeos etc.
17
Um servio de comunicao caracterizado por um canal de comunicao em que interlocutores enviam e recebem mensagens. O suporte comunicao interpessoal a essncia
de uma videoconferncia. De acordo com a dinmica estabelecida entre os interlocutores de
um canal comunicativo, podemos distinguir o servio de comunicao entre:
1. Comunicao 1:1 (um-para-um)
2. Comunicao 1:n (um-para-muitos)
3. Comunicao n:n (muitos-para-muitos)
As mensagens so transmitidas entre mquinas em uma rede de computadores atravs de

chamadas, que podem ser (de acordo com as formas de comunicao citadas):
1. Ponto-a-ponto: uma mquina-origem envia mensagens para uma mquina-destino.
2. Multiponto unidirecional: uma mquina-origem envia mensagens para n
mquinas-destino.
3. Multiponto bidirecional: n mquinas enviam mensagens s demais.
Internet
Figura 1.22
Comunicao
ponto-a-ponto (1:1).
No caso de uma comunicao ponto-a-ponto um-para-um, cada participante visualiza a

imagem do participante remoto maximizada na tela. Alm desta imagem, a maioria dos sistemas atuais permite que o participante veja a sua prpria imagem em uma regio reduzida
da tela (preview local para verificar se o enquadramento est bom). Geralmente, o participante pode escolher se deseja visualizar essas duas opes simultaneamente ou apenas a
imagem remota.
Internet
Viso Local
18
Imagem local e remota
Em uma comunicao ponto-a-ponto um-para-muitos, h um participante de um lado

interagindo com um grupo que est em uma sala remota. Em relao parte tcnica da
videoconferncia, esta comunicao praticamente igual s comunicaes ponto-a-ponto
um-para-um. Tanto o grupo quanto a pessoa que est sozinha pode escolher se deseja
visualizar a imagem local e remota simultaneamente ou apenas a remota. Ou ainda
compartilhar um documento em vez da imagem local (isso tambm vale para os outros
casos de comunicao).
Figura 1.23
Comunicao
ponto-a-ponto (1:n).
Este modelo de comunicao comum em encontros que envolvem vrios participantes localizados em uma sala de apresentao, alm de mais um participante remoto conectado a um
terminal de videoconferncia. Um exemplo prtico desse tipo de situao a apresentao de
palestras a distncia, em que um ponto de origem (o instrutor) interage por meio de videoconferncia com um grupo de participantes remotos (alunos). Nesse caso, as mensagens seguem
em uma chamada ponto-a-ponto da mquina-origem para a mquina-destino, embora a
comunicao seja do tipo um-para-muitos. Neste modelo necessrio ter cuidados com o
posicionamento do microfone e da cmera, especialmente na sala com vrios participantes.
A cmera deve ter uma viso de todos os participantes da sala e o microfone deve estar
acessvel a todos.
Internet
Viso Local
Figura 1.24
Comunicao
ponto-a-ponto (n:n).
Viso Local
Em uma comunicao ponto-a-ponto muitos para muitos, h dois grupos, um em cada

local, interagindo a partir de uma sala de videoconferncia. Assim como no modelo anterior,
tambm deve-se ter o cuidado adicional com o posicionamento da cmera e do microfone,
neste caso no apenas em uma, mas em duas salas.
Mais complexo que o modelo de comunicao ponto-a-ponto o modelo multiponto, ou seja,
uma situao onde temos mais de dois locais conectados em uma conferncia. H vrios
casos em que esse modelo utilizado. Exemplos: numa reunio de negcios, na qual estejam
conectadas a matriz da empresa e duas (ou mais) filiais; uma aula remota, com o professor
presente numa sala, e duas (ou mais) salas remotas apenas com alunos e monitores.
Internet
Figura 1.25
Comunicao
multiponto.
A chamada multiponto necessita de um controle especial para gerenciar os n fluxos

gerados, e essa responsabilidade pode ser efetuada de diferentes maneiras, como atravs
de uma entidade chamada Multipoint Control Unit (MCU), ou atravs de um sistema central
por software, ou mesmo sem entidade central, onde cada participante envia o sinal a todos.
Esses mecanismos sero detalhados posteriormente.
Viso Local
19
Entenda as necessidades dos usurios e conhea a estrutura que ser usada nas videoconferncias, alm da verba disponvel. Verifique ainda a sala que ser usada para a
instalao do sistema:
11
Sala: individual, de reunio ou de aula, ou ainda um auditrio ou sala especfica
(consultrio, centro cirrgico etc).
11
Qual o tipo de microfone adequado?
11
Qual o tipo de cmera de vdeo adequada?
11
Qual a banda de rede disponvel?
O tpico da estrutura da sala de videoconferncia ser abordado em outra sesso deste
curso. No momento basta dizer que a estruturao da sala um ponto extremamente
importante para a definio de um ambiente de videoconferncia.
Para pensar
importante ter uma estimativa da verba disponvel para o projeto, pois muitas
vezes ela que determina a qualidade dos equipamentos e a quantidade de recursos
adicionais que sero agregados ao sistema. Sistemas dedicados costumam ser mais
prticos, mas apresentam custos elevados. Para reduzir os custos possvel buscar
solues em software, especialmente as solues free, como o GNU Gatekeeper.
Por exemplo, se o caso for de comunicao multiponto e no houver verba para aquisio
de um controlador de chamadas multiponto (MCU), isso pode ser um ponto crtico no
projeto. Algumas alternativas:
11
Usar uma MCU de terceiros;
11
Adquirir equipamentos de videoconferncia j com suporte multiponto;
11
Pensar na possibilidade de usar uma soluo baseada na web (webconferncia), onde
geralmente o suporte multiponto est implcito;
11
Utilizar MCU em software.
Assim, entendendo as necessidades dos usurios, conhecendo a estrutura que ser usada
nas videoconferncias e a verba disponvel, possvel especificar o equipamento e os
recursos que sero necessrios.
20
Atividade 1 Sistema de conferncia em desktop
O aluno dever realizar uma conferncia ponto-a-ponto (1:1) por udio e vdeo com o colega
ao lado. Para isso, dever instalar e configurar o software disponibilizado para esta atividade, conforme as orientaes do instrutor.
Dicas para a configurao do software de videoconferncia:
11
Geral: a aplicao pode solicitar nome de usurio;
11
Vdeo: verificar se a fonte de vdeo a correta;
11
udio: verificar se a entrada e sada de udio esto configuradas;
11
Rede:verificar se o adaptador de rede selecionado o correto;
11
Protocolos: localizar os protocolos de comunicao disponveis (SIP e H.323).
1. Realizada a verificao do aplicativo, os alunos se organizaro em duplas para realizar
uma chamada (1:1) com o software. Para isso, disque para o endereo IP do destino.
2. Ajuste o udio e o vdeo da chamada.
3. Refaa a chamada invertendo o originador dela.
Atividade 2 Funcionalidades do sistema

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

ou banda) para o mnimo possvel (desde que esse mnimo permita transmisso de udio e
vdeo). Verifique visualmente a qualidade. Refaa a chamada para o mximo de banda que
o software oferece. Verifique a qualidade. Houve mudana visvel de qualidade? Por qu?
11
Verifique a banda utilizada pela aplicao durante a chamada. Habilite e desabilite a
transmisso de vdeo para observar as diferenas. Verifique tambm se a banda de rede
es ou desktop). Verifique as variaes imediatas da rede conforme acontece alguma
atividade do usurio.
Responda as questes a seguir:
1. Por que as novas chamadas s podem ser feitas por IP? Por que no funciona chamar
pelo nome inserido nas configuraes do software do colega?
Captulo 1 - Roteiro de Atividades
fixa ou se h variaes. Compartilhe algum tipo de dado (quadro branco, apresenta-
21
2. Dado que dois pontos utilizam o sistema de videoconferncia, suponha que o ponto A
selecionou a velocidade 128 kbit/s e o ponto B selecionou 2 Mbit/s. Ao iniciarem uma

chamada, qual ser a velocidade utilizada?
3. Acesse a tela de configurao do sistema de videoconferncia, especificamente a de con-
figurao H.323 e SIP. Que protocolo de sinalizao est sendo usado na comunicao
entre os sistemas? Justifique.
Atividade 3 Medindo o atraso da transmisso

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

de sinalizao H.323.
Introduo a padres e protocolos

Imagine uma reunio com a participao de vrias pessoas: para que haja uma comunicao
efetiva entre todas elas, necessrio que os participantes se faam entender, dominando
um mesmo idioma e vocabulrio. Sem o estabelecimento de uma linguagem comum, no
haver entendimento entre os participantes da conversa. Imaginemos agora a mesma situao s que com computadores distribudos em uma rede em vez de pessoas. Nesse caso,
alm da infraestrutura de redes, necessria uma linguagem padronizada para que haja
uma comunicao efetiva entre os computadores.
Para garantir que os computadores falem a mesma lngua, existem diversos padres e
protocolos que regem essa comunicao. Esses padres e protocolos so objeto de estudo
de diversas organizaes, que trabalham no seu desenvolvimento e manuteno. Dentre
estas organizaes, as mais notveis em relao a padres de videoconferncia so: ITU-T,
IETF e MPEG.
Padronizao
Organizaes que estabelecem normas e protocolos para videoconferncia:
11 Telecomunication Standardization Sector do International Telecommunications

Union (ITU-T).
11 Internet Engineering Task Force (IETF).
11 Moving Picture Experts Group (MPEG).
A International Telecommunication Union (ITU) uma dessas organizaes que atua no
desenvolvimento de padres reconhecidos internacionalmente, no intuito de viabilizar a
interao entre computadores e outros equipamentos de telecomunicaes. Esse rgo
internacional, responsvel por estabelecer recomendaes para telecomunicaes, divide-se em grupos de estudo onde cada grupo incumbido de investigar um conjunto de ques-
Captulo 2 - Padres de videoconferncia
objetivos
Padres de videoconferncia
tes, cujos resultados definem as recomendaes estabelecidas pela ITU-T.

23
Um desses grupos, responsvel pela famlia ITU H.3xx, encarregado por estabelecer recomendaes para colaborao de dados e videoconferncia, ou seja, pela formalizao de
padres para comunicao multimdia sobre redes IP.
A Internet Engineering Task Force (IETF) uma comunidade internacional aberta, constituda
de administradores, operadores e pesquisadores concentrados em padronizar a evoluo da
arquitetura da internet e a operao da rede. A IETF est aberta a qualquer indivduo interessado. O trabalho tcnico da IETF tambm realizado em grupos de estudo, organizados por
tpicos de interesse em diversas reas, como distribuio, transporte, segurana etc.
Outra preocupao de padronizao diz respeito s estratgias de compresso e transmisso
de dados multimdia. Hoje em dia, existem cada vez mais aplicaes que envolvem udio,
vdeo e dados disposio de um pblico distribudo e crescente. A exploso da internet na
dcada de 1990 levou milhares de usurios a utilizarem esses servios com intuito profissional, comercial ou domstico. Assim, a internet agrega um volume de dados multimdia
cada vez maior, o que eleva a demanda de banda e a necessidade de estratgias eficientes
para transmisso desses dados. Nesse sentido, uma organizao aborda mecanismos para
codificao e transmisso de udio e vdeo. O grupo Moving Picture Experts Group (MPEG)
uma organizao que regulamenta padres para transmisso e compresso de udio e vdeo.
Os esforos desse grupo contam, atualmente, com trs padres que incluem compresso de
vdeo: MPEG-1, MPEG-2 e MPEG-4. O MPEG ainda possui outros padres associados: o MPEG-7
responsvel pela descrio de contedo multimdia (metadados) e o MPEG-21, responsvel
pela definio de um framework multimdia. Esse padro ser detalhado adiante.
Os padres ITU-T de videoconferncia exigem dos fabricantes a implementao de um
conjunto mnimo de padres de compresso de udio e vdeo.

H padres opcionais que tambm podem ser utilizados nos sistemas de videoconferncia.
Alm disso, cada fabricante pode adicionar padres proprietrios s suas solues.
Conjunto mnimo + padres opcionais + padres proprietrios
Os padres de videoconferncia especificam um conjunto mnimo de padres ITU-T de
compresso de udio e vdeo que deve ser implementado para que um sistema seja homologado conforme este padro. E alm deste conjunto mnimo, existem os padres opcionais,
que normalmente so mais complexos, como o H.264 para vdeo.
Muitos sistemas ainda incluem mtodos proprietrios de codificao de vdeo e udio. Por
serem mtodos proprietrios, onde muitas vezes apenas o prprio fabricante sabe como o
mtodo funciona, outros sistemas dificilmente tero suporte a esses mtodos, o que impossibilita a interoperao entre os sistemas. Apesar disso, mtodos proprietrios podem ser
utilizados como um diferencial quando um fabricante desenvolve um mtodo novo ou otimiza
um mtodo de codificao, por exemplo. Nesse caso, normalmente o cliente dever possuir
24
equipamentos do mesmo fabricante em todas as pontas, a fim de poder utilizar o padro.
Princpios de codificao de udio

Como converter udio analgico em digital?
11 PCM (Pulse Code Modulation):
11 sinal discretizado (gera um erro de amostragem).
Como minimizar o erro de quantizao (duas formas)?
Qual taxa de amostragem deve ser utilizada supondo que:
11 Frequncia da voz humana: 20 Hz 6.000 Hz (porm banda de 4kHz oferece perfeita

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

No processo de companso, os sinais mais fracos so elevados e os mais fortes so reduzidos, e assim todos podem ser representados por um nmero fixo de bits, pois o sinal
analgico da voz homogeneizado. Dessa forma, se a pessoa fala baixo, sua voz amplificada antes da digitalizao. Se fala alto, no amplificada. Assim, todos os sinais podem
ser representados com os 8 bits, economizando na taxa de transmisso via rede. As duas
formas mais utilizadas de companso so chamadas de lei A (mais usada na Europa) e
lei (mais usada nos Estados Unidos e Japo).
Vs
Companso segundo lei A ou (analgico)

Usar 13 bits e comprimir segundo lei A ou (digital)
Figura 2.3
Curva de companso da voz
(entrada/sada).
Ve
Padres de udio
A figura abaixo mostra um resumo da faixa de frequncia, taxas de transmisso e latncia
utilizada nos principais padres de codificao de udio.
Padro
Faixa de frequncia
Taxa de transmisso
Latncia
Qualidade
G.711
300 Hz - 3.4 kHz
64 kbit/s
<1
Excelente
G.722
50 Hz - 7 kHz
48,56 ou 64 kbit/s
<2
G.722.2
50 Hz - 7 kHz
6,6 - 23,85 kbit/s
G.723.1
8 kHz
5,3 ou 6,3 kbit/s
100
Razovel
G.728
300 Hz - 3.4 kHz
16 kbit/s
<2
Boa
G.729
8 kHz
8 kbit/s
25 - 35
Boa
Abaixo temos uma breve descrio de cada um dos padres:

11 G.711 mandatrio para todos os sistemas H.3xx. Possui udio com qualidade de telefonia
padro. Indicado para uso em conferncias com taxa disponvel de pelo menos 128 kbit/s.
11 G.722 produz udio de boa qualidade, e aumenta a resposta em frequncia em relao
ao G.711 (vai at 7 kHz).
11 G.722.1 possui taxas mais baixas de compresso (24 e 32 kbit/s), mas mantendo o udio
na mesma qualidade do G.722 ou at melhor. Licenciado pela Polycom como Siren14.
11 G.722.2 a 12 kbit/s prov excelente qualidade de voz em ambiente calmo. Taxas mais
altas so teis em condies de barulho de fundo e msica. Licenciado pela VoiceAge
Corporation como AMR-WB.
11 Adaptive Multi-Rate - WideBand (AMR-WB) recomendado no anexo C do G.722.1,
tornando possvel o uso de uma resposta em frequncia de 14 kHz em vez de 7 kHz. Da
os nomes dados pela Polycom: Siren7 e Siren14.
11 G.723.1 requer baixa largura de banda (5,3 e 6,3 kbit/s) e usado para VoIP. Devido ao
tempo de latncia e qualidade de udio, muitas vezes substitudo pelo G.711.
11 G.726 transmisso de voz nas taxas 16, 24, 32 e 40 kbit/s. Geralmente transmitido a
32 kbit/s, o que acarreta na economia de 50% na capacidade de uso da rede em comparao ao G.711, porm piora em termos de atraso.
Figura 2.4
Resumo das faixas
de frequncia.
Boa
27
11 G.728 utiliza taxa de 16 kbit/s com baixo atraso (menor que 2 ms) e boa qualidade de voz.
11 G.729 costuma ser utilizado para VoIP e opera com taxa de 8 kbit/s (apresenta extenses que utilizam as taxas de 6,4 e 11,8 kbit/s).
11 G.729a anexo do G.729 que prov uma variao do original com menos computao,
embora a qualidade da voz fique pior. s vezes usado quando h necessidade de envio
simultneo de voz e dados.
11 G.729b outro anexo do G.729 que contm um mtodo de compresso de silncio, que
possibilita a deteco de atividade (voz) no sinal.
11 G.729.1 desenvolvido para prover melhor qualidade e mais flexibilidade do que o G.729,
sendo interopervel com este. Opera nas taxas de 8 a 32 kbit/s.
Princpios de codificao de vdeo

11 O vdeo uma sequncia de imagens estticas. Principais taxas usadas atualmente
(quadros por segundo):

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

quadros por segundo em sistemas de televiso. Sistemas mais modernos de alta capacidade
j utilizam taxas de 50 e 60 quadros por segundo.
28
Por que comprimir?

Calcule:
11 Taxa em bit/s de vdeo SD no comprimido (Standard Definition 720x480, RGB, 30 qps)
11 Taxa em bit/s de vdeo HD no comprimido (High Definition 1920x1080p, RGB, 30 qps)
Trs componentes fundamentais: R, G e B compem qualquer cor por emisso luminosa.
Figura 2.6
A Practical Guide
to Video and Audio
Compression.
Fonte: Cliff Wooton,
Focal Press, 2007.
Vermelho Amarelo
R
G
B
Cyan
Azul
Violeta
255
0
255
255
0
255
0
255
0
0
255
0
255
255
255
Assim como o udio, o vdeo analgico capturado e convertido para o formato digital.
O processo diferente do utilizado para udio. No vdeo, cada imagem capturada por
diversos sensores, que capturam a intensidade de cada ponto da imagem e convertem esta
intensidade para um valor representado digitalmente, formando uma matriz de valores que
representa a imagem capturada. Cada valor destes representa um pixel da imagem. Para
cada imagem, o processo normalmente feito para as trs cores bsicas, o vermelho, o
verde e o azul, formando os trs planos (ou matrizes) que compem a imagem (RGB). Alm
do RGB, a imagem pode tambm ser representada de outras formas, como o YUV, muito
utilizado na codificao de vdeo.
11 Para compresso dos vdeos gerados aps a captura, os codificadores utilizam tc-
nicas para reduzir redundncias de diversos tipos presentes no vdeo:

11 Redundncia espacial.
11 Redundncia temporal.
11 Redundncia psicovisual.
11 Redundncia de codificao (entrpica).
Redundncia espacial
A redundncia espacial ocorre em pixels de uma mesma imagem, isto , pixels vizinhos
no espao tendem a ser muito parecidos (ou iguais).
normal que imagens possuam regies homogneas, onde as cores so praticamente
iguais. Estas regies so facilmente compactadas, porque de modo simplificado o codificador pode informar a cor de um bloco de pixels apenas uma vez e indicar que toda uma
regio semelhante.
Figura 2.7
Componentes RGB.
Verde
29
Figura 2.8
reas com redundncia espacial.
Redundncia temporal
Quadros vizinhos temporalmente possuem diversos pixels similares, seja na mesma
posio (crculo azul) ou em posies prximas (crculo vermelho).

A redundncia temporal percebida entre quadros vizinhos. Assim como um quadro pode
ter regies muito homogneas, dois quadros vizinhos podem ser muito parecidos. Nestes
casos, o codificador pode simplesmente informar que determinada regio de um quadro
exatamente igual mesma regio no quadro anterior (rea maior marcada na imagem),
ou ento que esta regio igual uma regio localizada em outro local no quadro anterior
(rea menor marcada na imagem). Essa indicao do deslocamento do bloco na imagem de
referncia conhecida como vetor de movimento.
Quadro 1
Quadro 2
Figura 2.9
reas com redundncia nos quadros.
Redundncia psicovisual
O sistema visual humano mais sensvel s informaes de brilho do que de cor, pois no
olho humano existem 240 milhes de bastonetes (brilho) e 13 milhes de cones (cores).
Por isso podem ser utilizados mais dados (bits) para representar brilho do que cores.
Isso requer uma transformao do sistema RGB (Red Green Blue) para YCbCr (luminncia
Y imagem em preto e branco e crominncias Cb e Cr cores associadas).
Relaes dos componentes de cores: reduo de 4:4:4 para 4:2:2 (33% de compresso) ou
4:2:0 (50% de compresso).
A redundncia psicovisual leva em considerao o conhecimento sobre o sistema visual
humano. Sabe-se que o olho humano possui muito mais componentes que percebem o
brilho das imagens do que componentes que percebem as cores, portanto muito mais
interessante representar mais variaes de brilho do que de cores. Na prtica, isso corresponde a utilizar um nmero maior de bits para representao do brilho.
30
A redundncia psicovisual aplicada por sistemas de cores como o YCbCr, que utiliza
um plano para o brilho (Y) e dois para cores (Cb e Cr), que pode ser utilizado de diversas
maneiras na amostragem do sinal, aps a captao da luz na cmera pelo CCD ou CMOS:
11 4:4:4 amostragem total, sem compresso, utilizada mais em cinema, por causa das
tcnicas de chroma key. Mantm todas as cores na mxima resoluo.

11 4:2:2 o dobro de bits para brilho (4) do que para cada componente de cor (2 para
cada). Esse tipo de amostragem j permite uma compresso de 33% do tamanho do
vdeo digital, com o mnimo de perda em cor, sendo utilizada em todos os sistemas
de TV digital.
11 4:2:0 o qudruplo de bits para brilho (4) do que para os componentes de cor (2 para
ambos), amostragem que comprime o sinal em 50% com perda mnima de cores, sendo
usada nos sistemas de cmeras do tipo handycam, e tambm para videoconferncias.
Redundncia de codificao (entrpica)

A redundncia de codificao no vista na anlise das imagens como as outras redundncias, mas na anlise da sequncia de bits gerada aps a codificao das imagens. Nesta
sequncia de bits, muitos padres se repetem, como, por exemplo, sequncias grandes
de ZEs. Existem diversas tcnicas para reduzir esta redundncia (tcnicas de codificao
entrpica). Entre as tcnicas utilizadas esto a codificao de Huffman, que representa os
dados de entrada com smbolos, utilizando smbolos menores para os dados de entrada
mais frequentes e smbolos maiores para os menos frequentes. H tambm a codificao
aritmtica, que representa os dados por nmeros de ponto flutuante. Ao contrrio de outras
tcnicas utilizadas na compresso, a codificao entrpica no introduz perda, ou seja, a
imagem codificada pode ser restaurada para seu estado original (exatamente como era)
depois de decodificada.
A compresso de vdeo um artifcio importante para os sistemas de videoconferncia,
pois reduz sensivelmente o fluxo de dados transmitidos na rede, embora, por outro lado,
aumente a necessidade de processamento nos terminais da videoconferncia, pois
necessrio fazer a codificao/decodificao do vdeo para exibi-lo nos clientes, o que pode
retardar um pouco a dinmica do processo e provocar uma latncia maior.
Padres de vdeo
H.261
H.263
H.262
MPEG-2
Joint ITU-T
MPEG Standards
Figura 2.10
Evoluo dos
padres de vdeo.
H.263+
MPEG
Standards
MPEG-1
1984
1988 1990
H.263++
H.264/AVC
MPEG-4 parte 10
H.265
MPEG-4
1993
1995
1997
2000
2003
2013
O grfico mostra a evoluo na padronizao da codificao de vdeo. A norma H.261, finalizada no incio dos anos 90, foi a primeira iniciativa da organizao ITU de gerar um padro
para aplicaes de teleconferncia. Alguns anos depois, o grupo MPEG lanou o padro
MPEG-1 visando principalmente aplicaes de armazenamento de vdeo. Posteriormente as
duas organizaes lanaram em conjunto a especificao H.262/MPEG-2 (H.262 pela enti-
ITU-T
Standards
31
dade ITU e MPEG-2 pela organizao MPEG), que veio a se tornar o padro mais difundido
para aplicaes de vdeo digital, como DVD e TV digital. O H.263 veio como uma evoluo do
H.261, e teve algumas evolues, como o H.263+ e H.263++.
No final dos anos 90, o grupo MPEG lanou a especificao MPEG-4. Em paralelo, a organizao ITU vinha trabalhando em um projeto de codificao ainda mais eficiente. As duas
organizaes ento uniram esforos para lanar, em 2002, outra padronizao conjunta, a
H.264/AVC, que a mesma norma MPEG-4 (parte 10). Alguns padres do MPEG foram desenvolvidos em conjunto com o ITU-T e publicados pelas duas entidades com nomes diferentes,
apesar dos padres serem exatamente os mesmos. Este o caso do MPEG-2 (parte 2), que
o mesmo padro H.262 da ITU-T e especifica um modelo para codificao de vdeo. Outro
caso de cooperao das entidades no padro MPEG-4 (parte 10) (Advanced Video Coding
AVC), que corresponde ao padro H.264 da ITU-T. Na verdade, a partir do MPEG-2 houve
um esforo conjunto entre o MPEG e o ITU, conhecido como Joint Video Team ( JVT), e ambos
trabalham em conjunto para definir os padres da forma mais eficiente e tambm compatvel, evitando incompatibilidades.
notvel a alta capacidade de compresso de dados e flexibilidade do padro H.264/AVC.
Sua flexibilidade deve-se ao fato de poder ser aplicado a uma extensa variedade de aplicaes, sendo eficiente, por exemplo, para taxas de bits e resolues de vdeo altas e baixas.
O preo a ser pago por todas as vantagens do H.264 o poder de processamento exigido
para codificao de vdeo superior ao dos outros algoritmos. O H.265 ou MPEG-H (parte 2)
tambm conhecido como High Efficiency Video Coding (HEVC). Sucessor do H.264 AVC,
HEVC dobra a taxa de compresso quando comparado ao H.264, permitindo resolues de
320x240 at 7680x4320.
O formato padro de vdeo para os servios de videoconferncia especificados na recomendao H.323 baseado no formato Common Intermediate Format (CIF), que consiste na
resoluo 352x288. Esse padro nasceu na especificao H.261. O CIF nasceu da necessidade de estabelecimento de um formato padro para videoconferncia que suportasse os
dois principais formatos padronizados de TV em todo o mundo:
Phase Alternating Line (PAL)
A TV PAL utiliza 625 linhas para formao do quadro, a uma taxa de 24 quadros por
segundo. Possui frequncia de varredura vertical de 50 Hz e resoluo de 720 x 576 pixels.
National Television Standard Committee (NTSC) e PAL-M
A TV NTSC ou PAL-M utiliza 525 linhas por quadro, 30 quadros por segundo, frequncia de
60 Hz e resoluo de 720 x 480 pixels. A figura seguinte mostra uma comparao entre as
resolues utilizadas nos padres H.261 e H.263:
32
Formato CIF
Resoluo (em pixels)
H.261
H.263
Sub-QCIF
128 x 96
QCIF
176 x 144
CIF
352 x 288
4CIF
702 x 576
16CIF
1.408 x 1.152
R: Requerido; O: Opcional; N: No especificado
Figura 2.11
Comparao entre
os padres H.261 e
H.263.
Como podemos observar na figura, o formato CIF apresenta variaes que definem outros
formatos de resoluo. Formatos com menor resoluo requerem menor largura de banda
para transmisso, como o caso do Sub-QCIF. Formatos com maior resoluo, como o caso
do 4CIF, requerem maior largura de banda para a transmisso. Para o padro H.323, o padro
para codificao de vdeo requerido o H.261 com resoluo QCIF. Assim, h a garantia de
que todos os sistemas compatveis com H.323 suportam pelo menos essa especificao.
H.264
Padro de codificao de vdeo bastante utilizado atualmente, que usa novas tcnicas no
disponveis no MPEG2, MPEG4 e H.263. Oferece o dobro da qualidade de vdeo do H.262

em qualquer taxa de transmisso. Tornou-se um padro mandatrio para sistemas de alta
definio com os discos Blue Ray, e tambm para produtos de broadcast, cabo, videoconferncia e outros eletrnicos diversos. Tambm adotado na TV digital brasileira.
O H.264 um padro bastante utilizado atualmente em codificao de vdeo, sendo cada vez
mais usado em sistemas de videoconferncia. Ele foi especificado pela ITU-T em conjunto
com o grupo MPEG, sendo nomeado H.264 pela ITU-T e MPEG-4 (parte 10) ou MPEG-4 AVC,
de Advanced Video Coding, pelo MPEG.
Ao contrrio do MPEG-4, o H.264 tem um escopo mais reduzido e seu foco a otimizao da
codificao de vdeo. Ele inclui diversas novas funcionalidades no processo de codificao
em relao aos seus predecessores, buscando um balano entre eficincia da codificao,
complexidade e custo.
O grau de compresso do padro e a incluso de outros componentes que envolvem estritamente vdeo e a flexibilidade permitida fazem com que seja uma grande promessa para
o futuro das aplicaes de videoconferncia. Ele j o padro adotado nos sistemas mais
modernos, principalmente os que requerem alta qualidade, como nos casos dos discos
Blue Ray. O H.264 foi adotado como o padro de codificao a ser usado pelo sistema
brasileiro de TV digital.
MPEG
O MPEG foi um grupo estabelecido em 1988, com a meta de elaborar padres genricos
para vdeo digital e compresso de udio, definindo normas para multiplexar fluxo de
udio e vdeo.
Padres:
11 MPEG-1, MPEG-2, MPEG-4 e MPEG-H: possuem partes especficas de compresso de
11 MPEG-7: descrio de contedo de mdia (metadados).
11 MPEG-21: definio de um framework multimdia.
Os padres MPEG normalmente so divididos em diversas partes, cada uma especificando
determinadas etapas ou processos da codificao (codificao de imagens, de udio, processo de testes, entre outros). No MPEG-1, por exemplo, a parte 3 especifica codificao de
udio, sendo o formato de codificao que ficou conhecido pelo nome MP3. A parte que
especifica codificao de vdeo normalmente a parte 2 dos padres, o que acontece no
MPEG-1, MPEG-2 e MPEG-4.
udio e vdeo.
33
O MPEG-1 o padro mais antigo da famlia MPEG, projetado inicialmente para ser capaz
de comprimir cerca de 30 minutos de udio e vdeo para um nico CD. O MPEG-1 uma
estratgia eficiente de compresso e descompresso, mas qualitativamente deixa a desejar.
Normalmente, as taxas utilizadas esto em torno de 1 a 1,5 Mbit/s. Desde que a compresso
H.263 vem sendo utilizada na maioria dos sistemas baseados em H.323 j que fornece
a mesma qualidade de imagem com uma taxa semelhante , o MPEG-1 no tem sido mais
adotado em sistemas de videoconferncia.
Assim como o MPEG-1, o padro MPEG-2 implementa um esquema para compresso de
vdeo. Porm, o propsito inicial dos desenvolvedores do MPEG-2 era atender a aplicaes
de broadcast, o que trouxe novas especificidades ao esquema adotado, que representa uma
evoluo ao MPEG-1, sendo muito mais complexo e eficiente. Atualmente, o MPEG-2 cobre
muitas variaes de resoluo e formato, visando tambm atender as especificaes da TV
de alta definio. O mercado disponibiliza um grande nmero de produtos que utilizam este
formato, como DVD players, receptores de TV via satlite e receptores de TV a cabo.
O MPEG-2 ainda utilizado em videoconferncias quando se deseja um mtodo mais rpido
e menos complexo de compresso ou manter a compatibilidade com sistemas antigos.
O MPEG-4 o mais novo dos padres da famlia MPEG, introduzido em 1999. O maior
diferencial do MPEG-4 incluir novos mtodos de codificao de vdeo que o tornam mais
eficiente que o MPEG-2. Alm disso, o MPEG-4 tambm um padro bastante mais extenso
que o MPEG-2, sendo definido como um padro para representao de objetos audiovisuais.
O mecanismo de compresso semelhante ao MPEG-2, mas este padro procura tratar
de diversos tipos de dados, como objetos (regies de um vdeo), redes de pontos 2D e 3D,
animaes e texturas.
Assim como no MPEG-2, o MPEG-4 tambm oferece uma variedade de perfis que podem ser
utilizados, permitindo desde taxas muito baixas (para utilizao em dispositivos mveis, por
exemplo) at taxas bem maiores, que permitem transmisso de vdeo de alta qualidade. Comparando perfis equivalentes, o MPEG-4 requer maior processamento do que os padres MPEG-2 e
MPEG-1 para codificao e decodificao. Do mesmo modo como os demais esquemas de compresso MPEG, ele foi desenvolvido para aplicaes de broadcast e streaming, onde a latncia
no se apresenta como uma questo to crucial quanto em aplicaes de videoconferncia.
O MPEG-4 apresenta duas partes relacionadas codificao de vdeo:
11 MPEG-4 parte 2: mtodo tambm chamado de MPEG-4 Visual, representa a evoluo da
codificao do MPEG-2. Normalmente quando se fala apenas em MPEG-4, esta parte do
padro que est sendo referenciada.
11 MPEG-4 parte 10: foi definida em conjunto com o ITU-T e chamada de Advanced Video
Coding (AVC) pelo MPEG e H.264 pelo ITU-T. No deve ser confundido com o MPEG-4 parte
34
2, pois representa um formato de compresso diferente.

O MPEG-4 parte 2 vem substituindo o MPEG-2 j h alguns anos, sendo utilizado em
diversos vdeos na internet codificados atravs de codecs que implementam o padro,
como os j populares DivX e Quicktime 6. J o MPEG-4 parte 10 corresponde ao H.264, que
j possui diversas aplicaes (como Blue-ray, TV digital brasileira, entre outras) e tende a se
tornar o padro mais utilizado, inclusive em videoconferncias.
Uma breve descrio

desses padres
disponibilizada em
Videoconferencing
Cookbook no site
da ViDe.
w Padres de dados
H dois padres importantes homologados pela ITU-T:
11 T.120: srie de protocolos para compartilhamento de dados com suporte a multiponto. Possibilita:
22 Compartilhamento de rea de trabalho ou de aplicao.
22 Uso de quadro branco (bate-papo e transferncia de arquivos).
11 H.239: possibilita a criao e o controle de canais de vdeo adicionais.
22 Canal de vdeo adicional para envio de apresentaes, compartilhamento de tela
do computador, entre outros.
T.120 uma famlia de padres estabelecidos pela ITU e suportados pelo padro H.323
(de uso no obrigatrio). A norma T.120 regulamenta uma srie de protocolos para o compartilhamento de dados em sistemas de videoconferncia. O T.120 suporta comunicao
ponto-a-ponto e tambm comunicao multiponto, podendo ser utilizado atravs de um n
centralizador (servidor) ou no. Quando utilizado em conjunto com um sistema de videoconferncia, pode assumir duas estratgias: in-band (a troca de dados entre os terminais
compartilham o mesmo canal utilizado para troca de vdeo e udio) ou out-of-band (as conexes de dados so feitas independentemente das conexes de multimdia).
Dentre as principais aplicaes do T.120, destacamos: compartilhamento de rea de trabalho e aplicaes, quadro branco (whiteboard), bate-papo e transferncia de arquivos.
Exemplo de equipamento que facilita a captura de dados para uso do H.239:
Figura 2.12
Polycom Visual
Concert.
O H.239 faz parte da famlia de protocolos H.32x (que inclui o H.323) e utilizado para
possibilitar a criao e o controle de canais multimdia adicionais na videoconferncia.
O H.239 voltado para sistemas baseados nos padres H.245 e H.320. Enquanto o H.245
permite a criao de mltiplos canais para vdeo, o H.320 permite apenas um canal. Com isso,
pode ser transmitida, por exemplo, uma apresentao. Alm disso, tambm permite a
identificao dos canais (indicar que um canal de vdeo corresponde apresentao do
professor, por exemplo) e mtodos para controlar estes canais em conferncias multiponto,
como permitir que apenas um participante esteja transmitindo um vdeo adicional contendo
a imagem de seu desktop, por exemplo.
em relao ao H.320, o H.239 traz a vantagem de permitir um canal adicional de vdeo, onde
35
Padres de comunicao
A figura a seguir contm um resumo das principais recomendaes ITU, com o tipo de redes
para as quais elas so voltadas e os padres de udio e vdeo utilizados em cada uma.
Padres de
comunicao
Padres de vdeo
Padres de udio
Redes
H.310
MPEG-2
MPEG-2
Redes ATM
H.320
H.261, H.263
G.711, G.722 e G.728
Redes ISDN e dedicadas
H.323
H.261, H.263
G.711, G.722, G.723,

G.728 e G.729
Redes de pacotes (IP)
H.324
H.263
G.723.1
Rede telefnica
A famlia H.3xx um conjunto de recomendaes regulamentadas pela ITU-T que compe o

principal conjunto de recomendaes relacionadas videoconferncia. Essas recomendaes
costumam ser chamadas de guarda-chuva, pois fazem referncia a diversas outras recomendaes, entre elas recomendaes para codificao de udio e vdeo, multiplexao, sinalizao e controle. Estas recomendaes referenciadas indicam as tcnicas e protocolos que
podem ser utilizadas nas diversas reas da videoconferncia. A recomendao H.323, por
exemplo, faz referncia aos protocolos H.261, H.263 e H.264 para codificao de vdeo.
O ncleo de recomendaes da famlia H.3xx composto por:
11 H.310 prov suporte para videoconferncia sobre ATM e possui um nicho muito especfico.
11 H.320 padro para transmisso de vdeo, udio e dados em tempo real em redes ISDN
(Integrated Services Digital Network). disponibilizado de duas formas: PRI fornece 30
canais de 64 kbit/s e dois canais de sinalizao, totalizando 2 Mbit/s; BRI fornece dois
canais de 64 kbit/s e um canal de sinalizao de 16 kbit/s, totalizando 144 kbit/s.
11 H.323 recomendao voltada para videoconferncias em redes comutadas por pacotes
sem garantia de qualidade de servio (LANs, internet etc.).
11 H.324 prov suporte para videoconferncia de baixa largura de banda sobre PSTN
(Public Switched Telephone Network). Esse protocolo foi utilizado na sia pelo mercado de
telefonia celular.
Alm dos padres ITU, h um padro IETF que deve ser destacado:
11 SIP protocolo dominante na rea de VoIP e cujo uso em videoconferncias vem
crescendo cada vez mais.
Neste curso ser dada nfase aos protocolos H.323, durante esta sesso, e SIP em sesses
36
posteriores.
Padro H.320
O padro H.320 voltado para videoconferncias em redes ISDN.
Figura 2.13
Principais
padres ITU-T.
Estrutura de normas do H.320
Codecs de vdeo
H.264
Codecs de udio
G.711
G.722
G.728
Controle
H.221
H.242
H.230
Dados
T.120
Controle
H.239
H.243
Recomendaes utilizadas pelo H.320:

11 Codificao de vdeo: H.261 e opcionalmente H.262, H.263 e H.264.
11 Codificao de udio: G.711 e opcionalmente G.722, G.728, G.723.1 e G.729.
11 Controle: H.221, H.242, H.243 e H.230.
11 Dados: T.120 e H.239.
A base do H.320 est nos seus padres de controle. Abaixo h uma breve descrio de cada
um deles:
11 H.221: define a estrutura de organizao dos dados ( framing) para canais de 64 a 1920
kbit/s em conferncias.
11 H.242: define um sistema para estabelecer comunicao entre terminais audiovisuais
(ponto-a-ponto) usando canais digitais de at 2 Mbit/s.
11 H.230: define o controle de sincronizao de quadros e indicao de sinais para sistemas
audiovisuais.
11 H.243: define procedimentos para estabelecer comunicao entre 3 ou mais terminais
audiovisuais usando canais digitais de at 2 Mbit/s. Comunicao com o MCU.
Padro H.323
Padro mais difundido para transmisso de voz, vdeo e dados em tempo real, para uso
em redes comutadas por pacotes. Foi o primeiro padro para VoIP, mas perdeu espao
para o SIP.
Principais componentes de uma rede H.323:
11 Terminais.
11 Unidade de Controle Multiponto (MCU).
11 Gatekeeper.
11 Gateway.
11 Elementos de borda.
Terminais H.323 so equipamentos que conectam-se rede H.323, viabilizando a participao dos usurios em videoconferncias.
O H.323 um padro ITU que descreve protocolos, servios e equipamentos necessrios
para comunicao multimdia incluindo udio, vdeo e dados em redes sem garantia de
qualidade de servio. O H.323 vem sendo desenvolvido desde 1996 com o objetivo de prover
comunicao multimdia sobre redes baseadas em IP como a prpria internet, IPX, LANs e
Figura 2.14
Estrutura de
normas do H.320.
H.263
H.261
37
WANs. Desde sua criao, o H.323 j sofreu muitas revises, que incorporam novas caractersticas para adequ-lo s novas tendncias. O H.323 tambm pode ser visto como uma
derivao de outro padro da famlia H.32x, o H.320, mas otimizado para uso na internet.
Atualmente, o H.323 tambm conta com especificaes para a incluso de suporte voz e
telefonia sobre IP.
O funcionamento do padro H.323 fundamentado numa espcie de contrato entre os
componentes que interagem dentro de um ambiente H.323, permitindo que esses componentes troquem informaes entre si. O H.323 tambm especifica os padres utilizados para
esta comunicao, que formam a linguagem utilizada pelos componentes para que eles
possam se entender.
A arquitetura H.323 composta dos seguintes componentes:
11 Terminais: so computadores ou equipamentos dedicados utilizados como pontos
finais (endpoints) da rede de comunicao. Esses equipamentos so responsveis por
fornecer suporte em tempo real s comunicaes bidirecionais. Tipicamente, so representados por computadores pessoais com suporte multimdia e cmeras integradas ou
equipamentos dedicados que j contm cmera e captao de som ligados a um televisor
ou projetor. Em alguns momentos o termo endpoint utilizado na norma H.323 para
referenciar qualquer elemento capaz de receber ou iniciar chamadas, seja um terminal,
gateway ou MCU.
11 Gatekeepers: conhecidos como os crebros da rede, responsveis pela gerncia de
outros componentes do H.323 e pelas funes de traduo de endereos e identificao
dos elementos de videoconferncia, autorizao e gerenciamento.
11 Gateways: promovem o entendimento comum, ou seja, trabalham como tradutores
responsveis pela conexo em redes no integradas (fora da zona H.323), possibilitando
a interoperabilidade com endpoints de redes baseadas em circuitos (por exemplo, RDSI).
11 MCU: Multipoint Control Units so responsveis pela conferncia multiponto, viabilizando
que mais de dois participantes se comuniquem simultaneamente atravs da rede, analogamente ao que acontece em uma teleconferncia via telefone.
Telefone
IP phone
Figura 2.15
Exemplo de
cenrio (terminais,
MCU, gatekeeper,
gateway).
Gatekeeper
Rede IP
Roteador
Telefone
IP phone
38
Terminal H.323
Gateway
MCU
Roteador
ISDN
Gateway
PSTN /
WIRELESS
Terminal H.323
Telefone
Terminal H.320
Adicionalmente definio dos diferentes tipos de componentes, o H.323 descreve protocolos

que definem a codificao de udio e vdeo, registro e admisso (Registration, Admission and
Status RAS), sinalizao de chamadas e de controle. O H.323 ainda especifica uma arquitetura de componentes obrigatrios e opcionais, que sero detalhados durante o curso, bem
como todo o detalhamento do funcionamento dos protocolos.
Figura 2.16
Equipamentos de
videoconferncia.
Multipoint Control Unit (MCU)

MCUs so responsveis por gerenciar conferncias multiponto, viabilizando a comuni-
cao de trs ou mais pontos simultaneamente. Tambm permitem:

11 Criao de salas virtuais de conferncia.
11 Transcodificao de udio e vdeo para diferentes modelos de equipamentos e fabricantes.
11 Transcodificao de velocidades (bitrate).
MCU formada por Controlador Multiponto (MC), um componente obrigatrio que
gerencia a sinalizao de chamada.
MCU
Multipoint Control Unit (MCU) ou unidade de controle multiponto um terminal de rede que
prov recursos para suportar conexo multiponto. formada por uma controladora multiponto
(MC Multipoint Controller) e por um processador multiponto (MP Multipoint Processor).
O primeiro componente mandatrio e executa as funcionalidades bsicas do servio, enquanto
o processador multiponto possui carter opcional (e podem haver vrios destes) e tem a
finalidade de prover o processamento necessrio para a realizao da conferncia multiponto
(em especial a codificao de vdeo, que muito custosa em termos de processamento).
Para viabilizar uma conferncia multiponto, o elemento fundamental a MCU, uma vez que
possui funcionalidades que permitem negociao com as diversas entidades conectadas
conferncia, a fim de estabelecer formatos comuns de comunicao. Para tanto, os terminais devem estabelecer canais de controle H.245 com a MCU.
Figura 2.17
Conferncia
multiponto utilizando Multipoint
Control Unit.
39
Processadores Multiponto (MP) so opcionais, utilizados para manusear a mixagem de

mdias, chaveamento ou outro processamento de mdia.
Figura 2.18
Controladores
multiponto.
Gateway
Responsvel por fazer a interface H.323 para outras redes, tais como PSTN e sistemas
H.320. Funes:
11 Traduo de protocolos H.323/SIP (IP) para H.320 (ISDN) ou o contrrio.
11 Possibilita o aumento de controle e centralizao das sadas de ISDN em pontos estratgicos na rede.
Terminal H.323
Telefone
ISDN/PSTN
Terminal H.323
Gateway
Telefone
Telefone IP phone
Terminal H.320
Figura 2.19
Cenrio de uso
do gateway.
Os gateways so os tradutores da arquitetura H.323, responsveis por garantir que os

diferentes elementos envolvidos em contextos de redes (tambm diferentes) possam se
intercomunicar. Para promover tal interoperabilidade, um gateway executa a traduo entre
os protocolos que rodam nas redes diferentes. Por exemplo: a traduo de protocolos que
rodam em redes comutadas por circuito para protocolos de redes baseadas em pacotes IP
(como o prprio H.323). Os servios de um gateway incluem: interoperabilidade entre
padres de udio/vdeo e redes, converso de protocolos e formatos de udio e vdeo.
40
H.323 permite, por meio do uso de gateways, a converso entre protocolos como H.320
(ISDN) e H.324 (POTS), garantindo a integrao desses contextos com as aplicaes H.323,
alm de padres no pertencentes a ITU, como SIP. Compartilha o recurso ISDN para todos
os endpoints presentes na rede:
Figura 2.20
Exemplos de
gateways.
Gatekeeper
Componente opcional no sistema H.323. Funes:
11 Gerenciar todos os recursos disponveis (terminais, gateways, MCU).

11 Pode permitir que chamadas sejam realizadas diretamente entre terminais ou centralizar, tanto a sinalizao como os dados.
11 Fornece servios avanados de administrao:
22 Traduo de endereos.
22 Controle de admisso (autenticao dos terminais).
22 Negociao de largura de banda.
O gatekeeper pode ser visto como o crebro do esquema H.323. O funcionamento de um
gatekeeper anlogo a um servidor de gerncia multimdia, que executa as atividades de administrao e tomada de deciso. O gatekeeper prov os seguintes servios: resoluo de endereos, controle de admisso, gerenciamento de banda e de zona. Uma zona H.323 compreende
o conjunto de todos os componentes arquiteturais H.323 assistidos por um nico gatekeeper.
Em outras palavras, podemos dizer que uma zona uma coleo de terminais, gateways
e MCUs gerenciados por um nico gatekeeper. Uma zona inclui, no mnimo, um terminal, e
pode incluir MCUs ou gateways. Uma zona pode ser independente da topologia de rede e estar
ligada a segmentos de rede mltiplos, conectados por roteadores e outros recursos.
H tambm o conceito de domnios administrativos, que so grupos de zonas H.323 administrados pela mesma pessoa ou organizao (possuem mesmas regras de autenticao).
Os gatekeepers podem tambm definir regras especficas para autenticao de componentes do seu domnio administrativo e outras regras para autenticao de componentes de
diferentes domnios.
Funes administrativas de um gatekeeper:
11 Traduo de endereos: chamadas originrias da rede H.323 podem utilizar um apelido
(alias) para enderear terminais de destino. Chamadas originadas fora da rede H.323 e
recebidas por um gateway podem utilizar um nmero de telefone E.164 (telefone convencional) para enderear os terminais-destino. O gatekeeper traduz esse endereo telefnico
convencional em um endereo de rede IP. Por exemplo: (21) 222 6576 em 245.153.45:121.
O terminal-destino pode ento ser identificado e contatado atravs do endereo IP.
11 Controle de admisso: o gatekeeper pode controlar a admisso dos terminais na rede
utilizando mensagens Registration, Admission and Status (RAS), onde esto inclusos os
e rejeio (ARJ Admission Reject). A admisso de controle pode, ainda, no ser especificada, significando a admisso de todos os terminais presentes na rede.
11 Controle de banda: o gatekeeper prov suporte ao controle de banda usando mensagens RAS de pedido de banda (BRQ Bandwidth Request), confirmao (ACF) e rejeio
(ARJ). Com isso ele consegue controlar a banda que est sendo utilizada na rede, administrando-a atravs da permisso ou negao das novas conexes que forem solicitadas ou
das mudanas de banda que forem solicitadas. Alm disso, o gatekeeper pode controlar
o limite de conexes simultneas na rede H.323, caso necessrio. A banda disponvel
tambm pode ser administrada de modo que as conexes de udio e vdeo no esgotem
essa banda, permitindo que existam tambm conexes de dados. O controle de banda
tambm pode no ser especificado, o que significa que sero aceitas todas as solicitaes
pedidos de admisso (ARQ Admission Request), confirmao (ACF Admission Confirm)
de conexes e mudana de banda.

41
11 Gerenciamento de zona: sendo o crebro do esquema H.323, um gatekeeper define

uma rea H.323, que ser gerenciada por ele. Ele ento prov as funes j citadas de
traduo de endereos, controle de admisso e controle de banda para os terminais,
gateways e MCUs locados dentro desta zona.
Funes opcionais de um gatekeeper:
11 Sinalizao de controle de mensagem: o gatekeeper pode rotear mensagens de sinalizao de chamadas entre os terminais H.323. Numa conferncia ponto-a-ponto, pode
centralizar mensagens de sinalizao de chamadas H.225. Alternativamente, o gatekeeper
pode permitir que os terminais enviem mensagens de sinalizao de chamadas H.225
diretamente para outros terminais.
11 Autorizao de chamadas: quando um terminal envia uma mensagem de sinalizao de
chamada para o gatekeeper, o gatekeeper pode aceitar ou rejeitar a chamada, utilizando a
especificao H.225. As razes que provocam a rejeio de uma chamada podem ser restries baseadas em tempo de conexo, permisses de acesso e/ou controle de banda.
11 Gerenciamento de chamada: o gatekeeper pode manter informaes sobre todas as
chamadas ativas H.323; desta forma, possvel controlar as zonas provendo essas informaes de manuteno para as funes de gerenciamento de banda, realizar balanceamento de carga redirecionando as chamadas para diferentes terminais, entre outros.
Zona H.323
Definida por um nico gatekeeper e por todos os componentes conectados a ele:
ISDN
Sistema
eletrnico
Gateway
Terminal
42
Gatekeeper
Roteador
MCU
Zona H.323
Figura 2.21
Topologia de rede
com gatekeeper.
Figura 2.22
Exemplo de
elemento de borda.
Elementos de borda
Geralmente colocados com o gatekeeper, trocam informaes sobre endereos e partici-
pantes (internos e externos) para autorizao de chamadas entre domnios administrativos. Funcionam como um firewall traversal configurado para chamadas H.323.
Um domnio administrativo um conjunto de zonas sob um mesmo controle administrativo.
Os elementos de borda so componentes opcionais, que, como os gatekeepers, realizam
tarefas administrativas, porm no se comunicam diretamente com os terminais. Eles so
componentes localizados nas bordas das redes H.323 que realizam tarefas de comunicao
entre domnios administrativos. Entre estas tarefas esto a troca de informaes de controle de acesso e de informaes sobre o custo de ligaes, por exemplo. Em uma ligao
de um terminal do domnio administrativo da organizao X com um terminal do domnio
administrativo da organizao Y, por exemplo, podem ser utilizados elementos de borda em
ambas as organizaes, que se comunicam trocando todas as informaes necessrias para
efetuar a chamada.
Protocolos da arquitetura H.323

Alm de componentes j abordados, o H.323 tambm especifica os vrios protocolos utilizados no ambiente H.323.
Aplicaes multimdia, interface do usurio
T.120
H.239
Controle de mdia
Codecs
de udio:
Codecs
de vdeo:
G.711
H.261
G.723.1
H.263
G.729
H.264
RTCP
Controle e gerenciamento
dos terminais
H.225.0
Sinalizao
da chamada
H.245
H.225.0
RAS
RTP
TCP
TCP
Figura 2.23
Arquitetura do
protocolo H.323.
TCP/UDP
UDP
TCP
UDP
IP
Vale lembrar que o H.323 independente das interfaces de rede e dos protocolos de transporte.
Protocolos adotados pelo H.323:
11 Codificao de vdeo: H.261, H.263 e H.264.
11 Codificao de udio: G.711, G.729, G.723.1, G.726, G.722, G.728.
Aplicaes de dados
43
11 Controle: H.225 e H.245.

11 Dados: T.120 e H.239.
11 Transporte multimdia: RTP e RTCP.
Em relao ao vdeo, mandatrio que todos os terminais H.323 possibilitem a codificao e
decodificao de vdeo com resoluo QCIF e protocolo H.261, e para udio mandatrio o
suporte a G.711. Os outros protocolos citados para udio e vdeo so opcionais.
Os protocolos de vdeo e udio j foram comentados, enquanto os protocolos de controle e de
transporte multimdia sero detalhados no restante deste captulo. Iniciaremos pelos protocolos RTP e RTCP, utilizados para transporte e controle sobre os dados de udio e vdeo.
Protocolos RTP e RTCP
11 RFC 3550 torna obsoleta a 1889 (RTP e RTCP).

11 Exemplo de pilha de protocolos RTP/RTCP com UDP e Ethernet.
11 RTP fica acima do nvel 4, no subnvel inferior do nvel de aplicao.
O RTP protocolo para aplicaes em tempo real (Real-time Transport Protocol) um protocolo especificado pelo IETF que prov um servio de entrega fim-a-fim de udio e vdeo em
tempo real. o protocolo utilizado para o empacotamento de mdias numa conexo H.323
(e em muitos outros sistemas).
Aplicaes de dados
T.120
H.239
Controle de mdia
Codecs
de udio:
Codecs
de vdeo:
G.711
H.261
G.723.1
H.263
RTCP
H.264
G.729
dos terminais
H.225.0
Sinalizao
da chamada
H.245
H.225.0
RAS
RTP
TCP
TCP
TCP/UDP
UDP
IP
44
TCP
UDP
Figura 2.24
Destaque dos protocolos RTP e RTCP.
Aplicao
Encapsulamento
de mdia
RTP
RTCP
dados
controle
UDP
IPv4 / IPv6
Unicast ou multicast
Ethernet
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V=2 P X
CC
PT
Nmero de sequncia
Timestamp
Synchronization Source (SSRC) identier
Figura 2.25
Exemplo de pilha
de protocolos (RTP/
RTCP) e RFC 3550.
Contributing Source (CSRC) identiers
SEQ=1
SEQ=2
SEQ=3
SEQ=4
SEQ=5
SEQ=6
SEQ=7
Perdas=10%
SEQ=9
Figura 2.26
Exemplo de funcionamento do RTP.
SEQ=10
SEQ=1, tstamp=x
SEQ=8
SEQ=2, tstamp=x+eq 20ms

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

RAS (Registration, Admission and Status):
11 Mensagens entre terminais/gateways e gatekeepers para:
11 Registro: gatekeeper gerencia registro de cada terminal.
11 Admisso: terminal requisita admisso para uma chamada.
11 Status: gatekeeper controla estado dos terminais e chamadas.
Mensagens mais importantes do RAS:

11 Solicitaes: Request (xRQ).
22 RRQ: RegistrationRequest.
22 ARQ: AdmissionRequest.
22 GRQ: GatekeeperRequest.
11 Respostas:
22 Reject (xRJ) -- RRJ, ARJ, GRJ.
22 Confirm (xCF) -- RCF, ACF, GCF.
O canal RAS realiza as funes de registro, admisso e estado de chamada por meio do protocolo H.225. O canal RAS (independente do canal das outras mensagens H.225) utiliza um
servio UDP para registro e solicitao de admisso das chamadas. As mensagens RAS so
utilizadas entre endpoints (termo que inclui gateways, MCUs e terminais) e gatekeepers para
realizao de trs funes:
11 Registro: endpoints se registram em um gatekeeper (s podem se registrar em um
gatekeeper), que controla as suas informaes de acesso (incluindo IP e nome de acesso).
11 Admisso: requisio de admisso em chamadas, utilizada pelo gatekeeper para controle
das chamadas existentes e da banda disponvel.
11 Status: controle do estado dos endpoints, como, por exemplo, descobrir se um endpoint
est disponvel ou no.
Aplicaes de dados
T.120
H.239
Controle de mdia
Codecs
de udio:
Codecs
de vdeo:
G.711
H.261
G.723.1
H.263
RTCP
H.264
G.729
dos terminais
H.225.0
Sinalizao
da chamada
H.245
H.225.0
RAS
TCP
UDP
TCP
TCP
UDP
Figura 2.28
Destaque do protocolo H.225 RAS.
TCP/UDP
IP
Quando um terminal no est configurado para se registrar em um gatekeeper especfico,

ele pode utilizar mensagens RAS para verificao dos gatekeepers presentes na rede e para
solicitar, posteriormente, um registro em um deles processo chamado de descoberta de
gatekeeper (gatekeeper discovery).
Entre as mensagens chave do protocolo RAS esto as mensagens de solicitao de registro
(e cancelamento de registro), admisso (e cancelamento) e busca por gatekeepers, e as respostas possveis para estas solicitaes.
RTP
47
Essas mensagens so identificadas por 3 letras, sendo que as ltimas duas identificam
se uma mensagem de solicitao (xRQ: request), confirmao (xCF: confirm) ou rejeio
(xRJ: reject). Essas mensagens so descritas brevemente abaixo:
11 RRQ (RegistrationRequest): requisio de um endpoint para se registrar em um gatekeeper.
11 Respostas: RCF (RegistrationConfirm) para confirmao ou RRJ (RegistrationReject)
para rejeio.
11 ARQ (AdmissionRequest): requisio de admisso enviada de um endpoint para o gatekeeper.
11 Respostas: ACF (AdmissionConfirm) para confirmao ou RRJ (AdmissionReject)
para rejeio.
11 GRQ (Gatekeeper Request): solicitao de gatekeepers existentes. enviado pelos
endpoints por IP multicast de forma que os gatekeepers possam receber a mensagem
mesmo que o endpoint no conhea os IPs dos gatekeepers.
11 GCF (GatekeeperConfirm): para confirmao ou GRJ (GatekeeperReject) para rejeio
(endpoint no pode usar este gatekeeper).
Terminal 1
Pode ser multicast,

broadcast ou
endereamento manual
Para descobrir
o gatekeeper
Use porta X
GRQ
GRJ/GCF
RRQ
Para se juntar
zona
Para pedir
permisso para
iniciar chamada
Gatekeeper
Usando porta x
Resposta:
224.0.1.41, porta 1718
Broadcast, porta 1719
Manual, porta 1719
RRJ/RCF
ARQ
Usando porta x
ARJ/ACF
Mensagem contm
endereo para
estabelecer chamada
Etapas na troca de mensagens H.225 RAS:

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

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

A sinalizao de chamada H.225.0 utilizada para conectar entidades H.323, sendo
derivada do Q.931 e Q.932 (sinalizao de chamada ISDN).

Mensagens disponibilizadas:
11 Setup: incio de chamada
11 Alerting: o terminal chamado avisa que est tocando
11 Connect: o terminal chamado avisa que atendeu a ligao
11 Release Complete: finalizao da chamada
11 Entre outras: Facility, Status, Progress, Information
A funo de sinalizao de chamada recomendada pelo H.323 utiliza o protocolo H.225
para estabelecer a conexo entre terminais H.323. A sinalizao de chamada ativada pela
troca de mensagens do protocolo H.225. As mensagens trocadas e procedimentos utilizados
numa sinalizao de chamada executam as seguintes atividades:
11 Estabelecimento de chamada: solicitao e confirmao de incio de chamada.
11 Alertas de progresso da conexo: mensagens opcionais que podem ser trocadas
enquanto uma conexo est sendo estabelecida, para que os terminais saibam o estado
da conexo enquanto ela no est confirmada (ou cancelada).
11 Encerramento de chamada: solicitao e confirmao de encerramento de chamadas.
Pode ser explicitamente enviada por um terminal para o outro ou pode ser enviada pelo
gatekeeper caso ele detecte que um terminal est inativo.
T.120
H.239
Controle de mdia
Codecs
de udio:
Codecs
de vdeo:
G.711
H.261
G.723.1
H.263
RTCP
H.264
G.729
dos terminais
H.225.0
Sinalizao
da chamada
H.245
H.225.0
RAS
RTP
TCP
Figura 2.30
H.225 Sinalizao
de chamada.
TCP
TCP/UDP
UDP
TCP
UDP
IP
As mensagens de admisso so trocadas entre os terminais e o gatekeeper nos canais RAS.

Nesse momento o gatekeeper determina se as mensagens de sinalizao H.225 sero
Aplicaes de dados
roteadas por ele ou se sero trocadas diretamente entre os terminais.

49
Sinalizao de chamada roteada por gatekeeper

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

Durante a confirmao de admisso, o gatekeeper indica quais terminais podem trocar
diretamente mensagens de sinalizao de chamadas. Os terminais utilizam ento o canal
de sinalizao de chamadas para trocar suas mensagens diretamente, sem que elas passem
pelo gatekeeper.
A sequncia de mensagens trocadas para estabelecer uma conexo com o H.225 comea
pelo envio de uma mensagem de Setup. O terminal que recebe a solicitao de conexo
pode ento responder com mensagens (opcionais) que indicam o progresso dessa conexo:
Call proceding, Progress e Alerting. Assim que este terminal est devidamente pronto
para estabelecer a conexo, ele envia uma mensagem Connect, e a conexo est estabelecida. A partir da os dados de mdia podem ser trocados entre os terminais. Para finalizar
a conexo, algum dos terminais envia uma mensagem de Release.
Endereo
informado pelo
gatekeeper
Terminal 1
Terminal 2
Setup
Call proceeding
Endereo de
transporte para
estabelecimento
do canal H.245
Porta
1720
Alerting
Figura 2.31
Sinalizao de
chamada direta
entre clientes.
Connect
Note que a mensagem Progress utilizada somente por gateways para indicar ao ponto
chamador que a chamada foi encaminhada outra rede a qual o gateway se liga. Essa mensagem possibilita que o terminal (ou gateway) que fez a ligao saiba que o outro gateway
est tentando estabelecer a conexo, mas esta ainda no est completa.
Alm dessas, as outras mensagens usadas na sinalizao H.225 so:
11 StatusEnquiry: encaminhada pelo gatekeeper para o ponto final da chamada para saber
o status de uma chamada.

11 Status: resposta do ponto final mensagem StatusEnquiry do gatekeeper.
11 Facility: usadas entre os pontos finais e o gatekeeper para tratamento de condies
especiais, por exemplo redirecionamento de chamadas.
Protocolo H.245
Tem como propsito prover o controle das sesses multimdia estabelecidas:
11 Troca de capacidades entre terminais.
11 Determinao de mestre e escravo.
Descritores de capacidades (protocolos suportados) contm o conjunto de
capacidades simultneas.
50
H.245 possui um canal de controle utilizado para transportar as mensagens de controle

fim-a-fim, com o objetivo de administrar as sesses abertas do H.323. O canal de controle
H.245 um canal lgico e est permanentemente aberto, ao contrrio dos canais de mdias.
H.245 prov mensagens para abrir e fechar um canal lgico, que unidirecional. As mensagens de controle carregam informaes de diferentes naturezas, tais como: troca de capacidades, informaes de fechamento e abertura de canais lgicos utilizados para transmisso
de mdias, mensagens de fluxo de controle, comandos gerais e sinalizaes e requisies de
modos preferenciais.
Aplicaes de dados
T.120
H.239
Controle de mdia
Codecs
de udio:
Codecs
de vdeo:
G.711
H.261
G.723.1
H.263
RTCP
H.264
G.729
dos terminais
H.225.0
Sinalizao
da chamada
H.245
H.225.0
RAS
RTP
TCP
TCP
TCP/UDP
UDP
Figura 2.32
Protocolo H.245.
TCP
UDP
IP
Troca de protocolos suportados

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

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

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

O H.245 tambm usado para tarefas de conferncias multiponto, como a seleo de um
modo de operao comum a todos integrantes e a definio do controlador da conferncia.
Canal de controle:
11 Canal especial que transporta mensagens H.245.

11 H.245 geralmente transmitido em uma conexo TCP separada, mas tambm pode
ser transmitido junto com o canal de sinalizao de chamadas H.225.
Formato das mensagens:
11 As mensagens so formadas por diversas PDUs (Protocol Data Unit), que podem ser
de 4 tipos: request, response, command e indication.
As mensagens H.245 so formadas por diversos itens chamados PDU (Protocol Data Unit),
que contm os dados da mensagem. Estas unidades podem conter dados de quatro tipos:
11 Request: mensagens que necessitam de resposta imediata. Requisio de capacidades
do outro terminal ou requisio de configurao de mestre e escravo, por exemplo;
11 Response: resposta a uma requisio;
11 Command: mensagens que requerem aes no receptor, mas no necessariamente uma
resposta. Comandos como controle de fluxo, fim de sesso e controle sobre a codificao
de vdeo (parametrizao);
11 Indication: indicaes no necessitam que o receptor tome alguma ao ou responda.
So avisos de jitter e skew, por exemplo.
52
Terminal 1
Terminal 2
TerminalCapabilitySet (1)
Mensagens do
canal H.245
Mdia
TerminalCapabilitySetAck (2)
MasterSlaveDetermination (3)
MasterSlaveDeterminationAck (4)
OpenLogicalChannel (5)
udio:
porta RTP destino: X
OpenLogicalChannelAck (6)
OpenLogicalChannel (7)
Vdeo:
porta RTP destino: Y
OpenLogicalChannelAck (8)
Canal de udio
Figura 2.34
Mensagens
H.245 entre
dois terminais.
Porta X
Canal de vdeo
Porta Y
A troca de mensagens H.245 entre dois terminais segue a seguinte sequncia:

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

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

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

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

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

Agora descreveremos as etapas envolvidas no processo completo de criao de uma
chamada H.323, incluindo o estabelecimento da chamada com as mensagens H.225 e H.245
e a transmisso de mdias. Imaginemos o seguinte exemplo: uma rede contendo dois
terminais H.323 (T1 e T2) j registrados a seu(s) devido(s) gatekeeper(s). A sinalizao de
chamada direta ativada (sem passar pelo gatekeeper). O fluxo de mdia utiliza RTP.
Efetuado o processo acima, o terminal est registrado em seu gatekeeper. A seguir, so
detalhadas as etapas do estabelecimento de chamada H.323.
Terminal
H.323
T1
Gatekeeper
Terminal
H.323
T2
1 (ARQ)
2 (ACF)
3 (SETUP)
4 (Procedimento de chamada)
5 (ARQ)
Telefone toca
6 (ACF)
7 (Alertar)
8 (Conectar)
H.225 RAS
H.225.0/Q.391
1. Terminal T1 envia mensagem ARQ (AdmissionRequest) para o gatekeeper utilizando o
canal RAS para requisio de admisso para o estabelecimento de uma nova chamada.
T1 solicita o uso de sinalizao de chamada no modo direto, sem que as mensagens de
controle (H.245) sejam roteadas pelo gatekeeper.
2. O gatekeeper confirma a admisso de T1 enviando uma mensagem ACF
(AdmissionConfirmation) para T1. O gatekeeper indica na mensagem ACF que T1 pode

usar sinalizao de chamada direta.
3. T1 envia uma mensagem de configurao de chamada H.225 para T2 solicitando uma conexo.
4. T2 responde com uma mensagem de prosseguimento de chamada a T1, ou seja, avisa
que a chamada est em progresso, mas que ainda no foi concluda.
5. Agora T2 tem que registrar no gatekeeper a requisio de admisso para o estabelecimento de
54
uma nova chamada. Atravs do canal RAS, envia uma mensagem ARQ para seu gatekeeper.
6. O gatekeeper confirma o registro enviando uma mensagem de confirmao ACF para T2.
7. T2 notifica T1 do estabelecimento da conexo, enviando uma mensagem de alerta H.225.
8. Por fim, T2 confirma o estabelecimento da conexo enviando uma mensagem de
conexo H.225 a T1, e a chamada est estabelecida.
Figura 2.35
Mensagens H.323
entre dois terminais
com gatekeeper.
Terminal T1
Gatekeeper
Terminal T2
9. TerminalCapabilitySet
Mensagens H.245
10. TerminalCapabilitySetAck
RTP (mdia)
11. MasterSlaveDetermination
12. MasterSlaveDeterminationAck
13. OpenLogicalChannel
udio:
porta RTP destino: X
14. OpenLogicalChannelAck
15. OpenLogicalChannel
Vdeo:
porta RTP destino: Y
16. OpenLogicalChannelAck
Canal de udio
Porta X
Canal de vdeo
Porta Y
9. O canal de controle H.245 estabelecido entre T1 e T2. T1 envia uma mensagem
TerminalCapabilitySet para T2, para a troca de capacidades.

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

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

na mensagem.
14. T2 conhece o estabelecimento de um canal unidirecional lgico de T1 para T2 enviando
uma mensagem H.245 OpenLogicalChannelAck. Dentre as informaes dessa mensagem

esto includos o endereo de transporte RTP alocado por T2 para ser usado em T1
atravs do envio do fluxo de mdia RTP, e o endereo RTCP recm recebido por T1.
15. T1 abre outro canal com T2, agora para vdeo, atravs de uma mensagem H.245
OpenLogicalChannel. O endereo de transporte do canal RTCP est incluso na mensagem.

16. T2 conhece o estabelecimento do canal lgico atravs do envio da mensagem
OpenLogicalChannelAck.
Figura 2.36
Mensagens H.245
at estabelecer
canal de udio.
55
Finalizao da sesso
Terminal
H.323
T1
Gatekeeper
Terminal
H.323
T2
21 (Comando de Final de Sesso)

22 (Comando de Final de Sesso)
23 (Release Completo)
Mensagens H.245
24 (DRQ)
24 (DRQ)
25 (DCF)
25 (DCF)
1. T2 inicia uma chamada de liberao, enviando para T1 uma mensagem H.245
EndSessionCommand.
2. T1 libera seu lado da chamada e confirma a liberao enviando uma mensagem
Mensagens H.225
Mensagens RAS
Figura 2.37
Mensagens H.245
de finalizao
de sesso.
EndSessionCommand para T2.

3. T2 finaliza a chamada enviando uma mensagem H.225 para T1.
4. T1 e T2 informam ao gatekeeper o trmino da chamada enviando uma mensagem DRQ
(DisengageRequest) para o gatekeeper.

5. O gatekeeper fica a par do encerramento da chamada de T1 e T2 e responde enviando
mensagens de confirmao DCF (DisengageConfirm) para T1 e T2.

A figura seguinte apresenta um resumo do que foi visto, e referente captura mostrada
na figura seguinte.
56
w
A pgina Understanding H.323 Gatekeepers no site da Cisco
contm uma boa
descrio do funcionamento dos gatekeepers
H.323 e dos protocolos
de sinalizao H.255 e
H.255 RAS.
Terminal T1
Gatekeeper
Registration Request / Conrm
Registration Request / Conrm
Permisso
para ligar
para T2
Terminal T2
Admission Request / Conrm

Setup
Setup
Admission Conrm
Permisso
para aceitar
ligao de
T1
Alerting
Alerting
Admission Conrm
Connect
Connect
H.245 (Terminal Capabilities)

H.245 (Open Logical Channel)
Canal de udio
Figura 2.38
Resumo da comunicao H.323.
Canal de vdeo
Padres para servios

H.350:
11 Recomendao estabelecida pela ITU-T.

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

No Wireshark, utilize filtros como h225, h245, rtp e ip para facilitar a visualizao dos pacotes.
Voc pode concatenar filtro como neste exemplo: h225 and ip.src == 192.168.0.100 and
rtp.p_type==127 (mudar o IP para o IP correto da mquina desejada) ou h225 or h245.
flow graph), detalhando os protocolos, como por exemplo: h.225 setup, h.225 admission
59
Atividade 2 Anlise de troca de mensagens entre dois clientes com gatekeeper

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

Ao final do captulo o aluno estar apto a identificar um plano de numerao E.164
e a configurar um gatekeeper em uma rede H.323.
conceitos
Padro ITU E.164, plano de numerao e plano de discagem, gatekeeper GnuGK

(configuraes bsicas, plano de discagem e autenticao de clientes).
Padro ITU E.164

Plano de numerao internacional para a rede de telefonia pblica (e eventualmente
para rede de dados).

Define estrutura de nmeros e funcionalidade para 4 categorias:
11 Regies geogrficas (foco deste curso).
11 Servios globais.
11 Redes.
11 Grupos de pases.
A lista dos cdigos

telefnicos de diversos
pases pode ser vista
em List_of_country_
calling_codes na
Wikipedia.
O E.164 uma recomendao ITU-T que define o plano de numerao internacionalmente

usado em redes de telefonia pblica e em algumas redes de dados.
A recomendao define a estrutura da numerao e como estes nmeros devem ser
analisados para que seja feito o seu roteamento. So definidas estruturas de numerao
para 4 categorias: regies geogrficas, servios globais, redes de computadores e grupo de
pases. Neste curso o foco dado categoria das regies geogrficas.
CP
1 a 3 dgitos
CA
NA
(15 - CP) dgitos
Nmero de alcance nacional
Mximo de 15 dgitos
Figura 3.1
Estrutura do
ITU E.164.
Nmero de alcance internacional
Nmeros E.164 so limitados a no mximo 15 dgitos, normalmente representados com o
Captulo 3 - Plano de numerao e gatekeeper
prefixo +.
61
Exemplo: +555199998888.
Nmeros para reas geogrficas so divididos em 3 partes:

11 CP = Cdigo do pas
Usa-se de um a trs dgitos para representar o cdigo da regio. Em geral, o cdigo da regio
representa um pas, exceto para Estados Unidos e Canad, que utilizam o mesmo cdigo.
11 CA = Cdigo de rea
11 NA = Nmero do assinante
de responsabilidade da agncia reguladora do setor de cada pas a administrao de
seu plano de numerao, incluindo a quantidade de dgitos utilizados para nmero do
assinante, cdigo de rea etc.
Os nmeros E.164 so limitados a, no mximo, 15 dgitos, e normalmente so representados
incluindo o prefixo +. Para a categoria de reas geogrficas, os nmeros E.164 so divididos
em 3 partes:
11 CP: Cdigo do pas. Cdigo de 1 a 3 dgitos que representa a regio geogrfica em que o
nmero se localiza. Em geral, o cdigo da regio representa um pas, exceto para Estados
Unidos e Canad que utilizam o mesmo cdigo.
11 CA: Cdigo da rea. Cdigo (opcional) da regio dentro do pas.
11 NA: Nmero do assinante. Contm no mximo (15 CA CP) dgitos e o nmero que
identifica cada assinante individualmente.
O cdigo do pas estabelecido mundialmente, enquanto os cdigos de rea e nmeros de
assinante so de responsabilidade da agncia reguladora do setor de cada pas.
Plano de numerao
O uso de um plano de numerao consistente em uma rede de videoconferncia
simplifica a alocao de identificadores para terminais, e consequentemente facilita a

discagem para o usurio final.
O plano de numerao a definio de como ser a identificao numrica dos terminais
e reas da videoconferncia e como ser feito o roteamento das chamadas atravs desses
identificadores. O plano de numerao muito importante, pois simplifica a identificao de
terminais, e consequentemente facilita a discagem para o usurio final.
A VideNET um exemplo de rede de videoconferncia de alcance global, e utiliza o esquema
Global Dialing Schema (GDS), que um plano de numerao proposto para redes de vdeo
e voz sobre IP; esse plano de endereamento muito similar ao plano de numerao do
sistema telefnico internacional. Com o GDS, possvel numerar cada terminal de videoconferncia, sala virtual de MCUs e gateway.
O plano de numerao permite a integrao com outras redes de videoconferncia e
tambm com outros tipos de redes, tais como:
11 VoIP: estabelecimento de udio conferncia;
11 Public Switched Telephone Network (PSTN): terminais conectados via ISDN.
Os identificadores atribudos para os terminais so vlidos apenas no mbito da rede local
da videoconferncia e no necessrio que seja atribudo um identificador E.164 completo
(15 dgitos) para cada terminal. Duas instituies podem, por exemplo, compartilhar os
mesmos identificadores dos terminais, mas para elas interagirem devero possuir cdigos
62
w Para mais informaes

visite o site da VideNET.
de rea distintos. Dependendo do tamanho da rede de videoconferncia, os identificadores

podem ser herdados da telefonia convencional (o que no quer dizer que eles sero acessveis a partir dela).
O acesso a partir da rede de telefonia convencional requer conexo atravs de GW IP-PBX
(dotados de interfaces BRI ou PRI para vdeo/udio ou FXO para udio).
Identificao para terminais:

11 No necessariamente atribudo um identificador E.164 completo.
11 O identificador ser vlido apenas no mbito da rede local de videoconferncia.
11 Dependendo do tamanho da rede de videoconferncia, os identificadores podem ser
herdados da telefonia convencional (isso no quer dizer que sero acessveis a partir dela).
Para chamadas entre terminais na mesma rea pode simplesmente ser utilizada discagem de 4 dgitos. Exemplo: Terminal 1 liga para Terminal 2 discando: 2000.
Para chamadas para terminais de fora da rede deve ser utilizado o cdigo de rea.
Exemplo: Terminal 1 liga para Terminal 3 discando: 0 22 1000 (com prefixo de escape 0).
O plano de discagem integra-se ao plano de numerao, fundamental para o desenvolvimento dessas e de outras facilidades.
Terminal 2
na rea A
Terminal 3
na rea B
Formato dos nmeros
YY XXXX
YY XXXX
ZZ XXXX
Prefixo da rea
11
11
22
Nmero do terminal
1000
2000
1000
Nmero completo
11 1000
11 2000
22 1000
Para um terminal efetuar uma chamada para um terminal que est na mesma rea, pode
simplesmente ser utilizada discagem de 4 dgitos. Por exemplo, o Terminal 1 (rea A) pode
ligar para o Terminal 2 (rea A) discando apenas (2000). Para chamadas para terminais de
fora da rede (rea) deve ser utilizado o cdigo de rea. Assim, para o Terminal 1 ligar para
Terminal 3, por exemplo, ele deve discar (0 22 1000), necessitando discar um cdigo de
escape antes, no caso 0, para informar que est ligado para fora da sua rea. Esse nmero
definido no plano de discagem.
A numerao abreviada possvel graas ao recurso de reescrita do servidor de sinalizao
gatekeeper para H.323 e proxy para SIP.
Plano de discagem
Funes do plano de discagem:
11 Permitir facilidade e flexibilidade para discagem.
11 Garantir que chamadas para fora da rea e pas possam ser facilmente encaminhadas.
A discagem da rede de telefonia convencional brasileira, por exemplo, inclui os prefixos:
11 0 chamadas para fora da rea.
11 00 chamadas para fora do pas.
Figura 3.2
Exemplo de
numerao para
trs terminais.
Terminal 1
na rea A
63
Qualquer tipo de discagem, por exemplo abreviada ou hiper abreviada, deve ser definida
no plano de discagem. No H.323, os planos de numerao de discagem so implementados no gatekeeper.

Enquanto o plano de numerao define como ser a atribuio de identificadores aos terminais, o plano de discagem define como ser feita a discagem entre estes terminais. Uma das
preocupaes garantir que chamadas para reas externas (fora da regio, fora do estado,
fora do pas etc.) sejam facilmente encaminhadas. Essas ligaes externas normalmente
so identificadas por prefixos durante a discagem. Na telefonia convencional brasileira, por
exemplo, discagens para outras reas so identificadas pelos prefixos 0 e 00. Exemplos:
11 Para chamar um terminal de dentro da rede (4 dgitos): 1234 (interpretao feita pelo PABX).
11 Para chamar um terminal de uma rede remota dentro da cidade: 3333 1234.
11 Para chamar um terminal de uma rede remota dentro do pas: 0 51 3333 1234.
11 Discar para um terminal de uma rede fora do pas: 00 55 51 3333 1234.
No plano de discagem tambm so definidos outros tipos de discagem, como a discagem
abreviada ou hiper abreviada, que facilitam as chamadas entre terminais:
11 Discagem abreviada discagem local de 8 dgitos, utilizada na telefonia convencional.
11 Discagem hiper abreviada discagem ramal de 4 dgitos, utilizada em PABX.
Redes distintas podem implementar planos de discagem diferentes. A implementao
ocorre nos servidores de sinalizao, responsveis pelo roteamento das chamadas.
No H.323, os planos de numerao de discagem so implementados no gatekeeper.
Gatekeeper GnuGK
Implementao de cdigo livre de um gatekeeper H.323 (licena GPL), que prov as
diversas funcionalidades de um gatekeeper, entre elas:

11 Autenticao por SQL (BD), RADIUS, arquivos ou aplicaes externas.
11 Reescrita de nmeros (plano de discagem e numerao).
11 Modo proxy.
Funciona em diversos sistemas operacionais: Linux, Windows, MacOS X, FreeBSD etc.
GnuGK uma implementao de um gatekeeper que tem base nas bibliotecas PWlib
(biblioteca para portabilidade de cdigo, especialmente relacionado rede, I/O e threads)
e OpenH323, esta ltima uma implementao de cdigo aberto do protocolo H.323. uma
ferramenta de cdigo aberto (licena GPL), flexvel e que disponibiliza as diversas funcionali-
dades necessrias para um gatekeeper.
64
Uma das funcionalidades do GnuGK a autenticao de usurios para controle de admisso.

Ele permite autenticao por bancos de dados SQL, servidores RADIUS (Remote Authentication
Dial In User Service), LDAP (Lightway Directory Access Protocol), alm de arquivos locais ou
aplicaes externas.
O GnuGK tambm permite reescrita de nmeros, para implementao do plano de numerao e discagem, faz o roteamento de chamadas, possui modo full proxy, possibilita controle
de banda, suporta segurana por H.235, entre diversas outras funcionalidades. A aplicao
funciona em diversos sistemas operacionais, entre eles Linux, Windows, MacOS X e FreeBSD.
O primeiro passo para utilizao do GnuGK a instalao da aplicao. A instalao obviamente depende do sistema no qual o aplicativo ser instalado. O site do GnuGK disponibiliza verses da aplicao compiladas para diversos sistemas operacionais, incluindo Linux,
Windows e MacOS. Para estes sistemas, basta obter os executveis e instal-los. O manual
do GnuGK possui uma seo de instalao que pode auxiliar este processo. Para sistemas
no suportados ou para fazer otimizaes/personalizaes na aplicao, possvel obter o
cdigo-fonte do GnuGK e compil-lo para o sistema alvo.
No Debian, aplicaes podem ser instaladas facilmente com o gerenciador de pacotes
apt-get, que tambm permite instalar o GnuGK. Esta aplicao instala o GnuGK e todas as
suas dependncias (todas as bibliotecas de que ele necessita). Normalmente o comando de
instalao no Linux :
$ apt-get install gnugk

Mais detalhes de instalao e compilao podem ser vistos no manual do GnuGK.
Inicializao do GnuGK
11 O executvel aplicativo chama-se gnugk, que possui diversas opes para configurao.
Para ver as opes possveis use o comando gnugk help.

Exemplo de execuo:
gnugk c /etc/gnugk.ini o /var/log/gnugk.log ttt
A execuo do aplicativo GnuGK no Linux feita atravs do executvel chamado gnugk.

Seguindo a instalao padro feita com o apt-get no Debian, este executvel estar instalado
em /usr/sbin. Para execut-lo deve-se estar logado como superusurio (root).
O GnuGK possui diversas opes que podem ser configuradas por linha de comando na
execuo da aplicao. Para verificar as opes possveis basta digitar o comando:
gnugk --help
Algumas opes interessantes:
11 [-c arquivo_de_configurao] especifica o arquivo de configurao que ser utilizado
(arquivo que ser descrito mais adiante).
11 [-o arquivo_de_log] especifica o arquivo onde ser gravado o log da aplicao.
11 [-t] especifica o nvel de debug. Quanto maior o nmero de -ts, maior ser o nvel de
debug. Para a opo de depurao o indicado o nvel de debug 3, ou seja, [-ttt].
Ao ser instalado no Linux, o GnuGK tambm instala um script que facilita a inicializao e
finalizao do programa. Este script instalado em /etc/init.d/gnugk e possui as opes:
Iniciar: /etc/init.d/gnugk start
Parar: /etc/init.d/gnugk stop
Reiniciar: /etc/init.d/gnugk restart
Consulte o manual do
GnuGK em gnugk.org.
Instalao do GnuGK
65
Ao iniciar o GnuGK por este script, ele utiliza algumas configuraes padro especificadas
pelo script:
Arquivo de configurao: /etc/gatekeeper.ini
Arquivo de log: /var/log/gnugk/gnugk.log
Para ter certeza que o GnuGK est em execuo no Linux, possvel executar o comando
abaixo que informa se o aplicativo est em execuo:
ps -ef | grep gnugk

Se o programa estiver em execuo, aparecer, entre outras informaes, uma linha contendo o nome e caminho do executvel do GnuGK: /usr/sbin/gnugk.
GnuGK no Windows
O GnuGK disponibilizado para Windows em dois formatos, servio e aplicao. Para
iniciar o GnuGK (aplicao) basta executar:

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

Estrutura do arquivo de configurao:
11 Arquivo texto padro composto por sees.
11 Cada seo contm um nome e uma lista de parmetros com seus respectivos valores.
Para no precisar especificar a localizao do arquivo de configurao a cada execuo do
GnuGK, crie um arquivo chamado de gatekeeper.ini no mesmo diretrio onde est o aplicativo do GnuGK ou copie o arquivo padro gnugk.ini do diretrio /etc e aps altere o nome.
Este arquivo organizado em diversas sees, cada uma delas contendo uma lista de parmetros com seus respectivos valores. As sees possuem nomes fixos e pr-determinados,
que so colocados entre colchetes. Segue abaixo um exemplo de uma seo:
[NomeDaSecao1]
Parametro1=Valor1
ParametroN=ValorN
Os parmetros tambm possuem nomes fixos e aceitam determinados valores, que variam
conforme o parmetro. Atentar para a digitao dos parmetros e seus valores, pois eles
so sensveis a maisculas e minsculas.
O arquivo possui um requisito mnimo que a seo:
[Gatekeeper::Main]
Fourtytwo=42
11 Outros parmetros da seo [Gatekeeper::Main]:
Name=H_323_ID_Gatekeeper
Home=IP_do_Gatekeeper
TimeToLive=300TotalBandwidth=512000
StatusPort=7000
O arquivo de configurao do GnuGK tem um requisito mnimo, que a presena da seo

[Gatekeeper::Main] com o parmetro Fortytwo=42. A opo de configurao Fourtytwo=42
serve para indicar que o arquivo um arquivo de configurao do GnuGK. Outros parmetros possveis nesta seo:
11 Name: identificador do gatekeeper. O gatekeeper somente responder aos GRQs que
forem direcionados para este ID e o usar em todas as mensagens com os terminais.
11 Home: endereo IP a partir do qual o gatekeeper receber requisies. Por default, o
gatekeeper ouve todas as interfaces de seu host.
11 TimeToLive: tempo da validao do registro de um terminal (em segundos). O terminal
deve periodicamente enviar mensagem RRQ tendo o bit keepAlive ativado para que seu
registro no expire. Depois de expirado, o registro deve ser revalidado.
11 StatusPort: porta de status utilizada para monitoramento e controle do gatekeeper.

Para adicionar comentrios no arquivo de configurao, insira o caractere ponto-e-vrgula
antes do comentrio. Este recurso extremamente til para descrever modificaes ou
para anular a funcionalidade de um parmetro sem a necessidade de apag-lo do arquivo.
O ponto-e-vrgula (;) pode ser adicionado em qualquer parte, mas s tem efeito na prpria
linha em que for utilizado, conforme pode ser visto abaixo:
[Gatekeeper::Main]
;Qualquer parametro ou texto apos um ; ser ignorado.
;O parametro abaixo identifica um arquivo de config do GnuGK.
11 TotalBandwidth: largura de banda total disponvel para os terminais.
67
Fortytwo=42
Name=GnuGk
; utilizado em algumas mensagens RAS
TimeToLive=60
;Valor modificado. O default 600.
; EnableIPv6=1
;Este parmetro ser ignorado pelo GnuGK.
Se o arquivo de configurao for editado com o GnuGK em execuo, ser necessrio

reinici-lo para que as novas configuraes tenham efeito. Se o servidor GnuGK for
reiniciado, todas as chamadas realizadas atravs do gatekeeper sero desconectadas
e novas chamadas somente sero possveis depois que o servidor estiver devidamente operacional. Para evitar essa indisponibilidade, pode ser utilizado o comando
reload atravs da console de monitoramento, que ser vista a seguir.
Monitoramento do GnuGK
Porta de status:
11 Monitorar e controlar as funes do gatekeeper.

11 Estabelecer e desconectar chamadas.
11 Desconectar terminais.
11 Visualizar e alterar as configuraes em tempo real.
11 Desligar o gatekeeper.
11 Suas configuraes so feitas na seo [GkStatus::Auth].
11 Acesso atravs da porta configurada (padro: 7000):
22 telnet IP do gatekeeper 7000
Deve ser configurada de tal forma que evite o uso indevido, causador de interrupo e
utilizao inadequada dos recursos.
A porta de status utilizada para monitorar as atividades do gatekeeper. A porta que ser
utilizada configurada pelo parmetro StatusPort da seo [Gatekeeper::Main] do arquivo
de configurao, j comentada. Alm de monitorar as atividades, pela porta de status
possvel controlar chamadas e terminais (desconectar um terminal, por exemplo) e alterar
configuraes do gatekeeper.
A grande vantagem de se comunicar com o gatekeeper pela porta de status a possibilidade
de controlar remotamente este gatekeeeper. Se a porta de status configurada foi a 7000, por
exemplo, basta criar uma conexo telnet com o gatekeeper na porta 7000 que ser possvel
monitor-lo. Abaixo segue o comando para se conectar porta de status do gatekeeper local:
68
$ telnet localhost 7000

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

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

Comandos principais da porta de status:
h
printallregistrations | rv | ?
printcurrentcalls | cv
shutdown
unregisterallenpoints
disconnetip [ip]
disconnectalias [alias]
reload
debug cfg [seo]
Estando conectado, diversos comandos podem ser enviados porta de status para obter
informaes sobre o gatekeeper ou solicitar que ele execute alguma ao. Principais
comandos disponveis:
11 h: imprime todos os comandos;
11 printallregistrations | rv | ?: imprime todos os endpoints registrados (so 3 comandos
separados pelo sinal |, e qualquer um deles pode ser utilizado);
11 printcurrentcalls | cv: imprime as chamadas em andamento;
11 shutdown: desliga o gatekeeper;
11 unregisterallendpoints: fora o cancelamento do registro de todos os endpoints registrados;
11 disconnectip [ip]: desconecta todas as chamadas de um determinado endereo IP;
11 disconnectalias [alias]: desconecta todas as chamadas de um determinado alias (usurio);

11 reload: recarrega as configuraes do arquivo de configuraes;
11 debug cfg [seo]: imprime as configuraes de uma determinada seo (do arquivo
de configuraes).
11 Algumas alteraes do arquivo de configurao (principalmente as relacionadas com
endereamento IP) no tero efeito mesmo aps o comando reload. Verifique o manual
do GnuGK para mais detalhes.
Zoneamento
As zonas H.323 so definidas por um gatekeeper, e podem ser de domnios administrativos
distintos. A segmentao em zonas permite a criao de grandes redes de videoconferncia.
70
Cada zona ser constituda por um gatekeeper e pelo menos terminais H.323. Mensa-
gens LRQ/LCF so utilizadas para localizao do terminal remoto.

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

de cada rea precisam conversar entre si. Para a localizao de terminais, os gatekeepers de
zonas diferentes trocam mensagens LRQ (e as respostas para estas):
11 LRQ: Requisio de Localizao
11 LCF: Confirmao de Localizao

11 LRJ: Rejeio de Localizao
O processo de troca dessas mensagens se d quando um gatekeeper recebe uma chamada
em que o destinatrio no conhecido por este gatekeeper, por exemplo. Neste caso, a
troca de mensagens se d da seguinte forma:
11 Gatekeeper GK recebe chamada e no encontra destinatrio D (no um terminal
registrado nele);
11 GK procura em sua lista de gatekeepers vizinhos quais devem ser consultados;
11 GK envia LRQ para este(s) vizinho(s), buscando pelo terminal D;
A sintaxe completa das

configuraes mais
complexa, onde pode
ser inclusive atribuda
uma senha para
autenticao dos
vizinhos. Mais detalhes
podem ser encontrados na documentao do GnuGK.
Mensagens LRQ
73
11 O vizinho que encontra o destinatrio responde com uma mensagem LCF;

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

A funcionalidade de reescrita de nmero E.164 permite a implantao do plano de discagem.
A partir de um determinado nmero chamado, uma ao de reescrita desse nmero

realizada com o objetivo de encaminhar a chamada corretamente, o que feito na seo
[RasSrv::RewriteE164].
Para cada regra de reescrita deve-se usar a sintaxe: [!]nmero-original=nmero-destino
A implementao de um plano de numerao completo pode exigir dezenas de regras, que
devem ser vistas sob dois aspectos: chamadas para dentro da zona ou chamadas para fora.
A seguir exemplos com DGK hierrquico.
Chamada do terminal A para o B (ambos na rea 11)
11 Direto pelo ramal: 2000
11 Com cdigo da rea: 11 2000
11 Regra (GK A): 11....=....
Chamada do terminal A para o C
11 Deve incluir cdigo de rea e escape: 0 33 1000
11 Regra (GK C): 033....=....
22 GK A encaminha ligaes com prefixo 0 para o DGK.
22 DGK encaminha ligaes com prefixo 033 para GK C.
A funcionalidade de reescrita de nmero E.164 permite a implantao do plano de discagem no GnuGK. A partir de um determinado nmero chamado, uma ao de reescrita
desse nmero realizada pelo gatekeeper com o objetivo de encaminhar a chamada para o
terminal (ou gatekeeper) correto. Fazendo uma comparao com o sistema telefnico, por
exemplo, se algum localizado no Rio Grande do Sul faz uma ligao para o Rio de Janeiro
discando 0-xx-21-1234-1234, este nmero deve ser encaminhado para o terminal de
nmero 1234-1234, sendo que os primeiros dgitos (0-xx-21) so apenas para permitir
que a ligao seja encaminhada corretamente.
No GnuGK, a reescrita dos nmeros feita na seo [RasSrv::RewriteE164], que pode
possuir diversas regras com a seguinte sintaxe:
Se a regra comea com nmero-original, indica que este nmero deve ser substitudo por
nmero-destino. Se a regra comea com o prefixo !, inverte-se o sentido da regra, fazendo
com que os nmeros que no tm nmero-original como prefixo, tenham nmero-destino
adicionado como prefixo.
Tambm esto disponveis os caracteres curinga . e %. O caractere . indica que deve haver
um dgito qualquer na posio em que ele est, enquanto % indica que o nmero daquela
posio ser eliminado.
Se tivermos, por exemplo, as seguintes regras de reescrita:
[RasSrv::RewriteE164]
08=188
(substituio simples)
!08=188
(negao. Tudo que no for 08)
[!]nmero-original=nmero-destino
75
%%%%.=.
(elimina 4 dgitos)
0044....=144....
(iniciado com 0044 com pelo menos 4 dgitos mais)
Neste caso:
11 Se discado 082222, o resultado da reescrita ser 1882222;
11 Se discado 092222, o resultado ser 188092222;
11 Se discado 11112000, o resultado ser 2000;
11 Se discado 00441234, o resultado ser 1441234.
A implantao de um plano de numerao completo pode exigir dezenas de regras, e deve
sempre ser vista sob dois aspectos: chamadas para dentro da zona ou chamadas para fora.
Chamadas para dentro da zona so aquelas encaminhadas por outros gatekeepers com
destino aos terminais da rede local de videoconferncia. Chamadas para fora da zona so
aquelas com destino a outras redes de videoconferncia (outros gatekeepers).
Os exemplos abaixo so novamente relacionados com ligaes telefnicas e mostram como
podem ser necessrias diversas regras caso existam diversos pases, reas e terminais.
Os exemplos so de regras em um gatekeeper no Brasil, na rea 21. Ele procura reescrever
todos os nmeros para o formato <cdigo-pas><cdigo-rea><cdigo-terminal>, exceto as
chamadas para terminais locais, que so reescritas para o nmero do terminal local.
Exemplos usando o DGK:
11 Chamada do terminal A para o B (ambos na rea 11):
22 Chamada direto pelo ramal: 2000
22 Chamada com cdigo de rea: 11 2000
Regra (GK A) remove cdigo de rea: 11....=....
11 Chamada do terminal A para o terminal C (rea 33):
22 Deve sempre ser adicionado ao ramal o cdigo de rea do destino e o dgito de escape:
0 33 1000
Regra (GK C): 033....=....
GK A encaminha ligaes com prefixo 0 para o DGK.
O DGK encaminha ligaes com prefixo 033 para o GK C.
DGK
76
Cliente A
1000
rea 11
rea 22
rea 33
GK A
GK B
GK C
Cliente B
2000
Cliente C
1000
Figura 3.6
Chamada
entre cliente de
mesma rea.
DGK
rea 22
rea 33
GK A
GK B
GK C
Cliente A
1000
Cliente B
2000
Cliente C
1000
Autenticao
A autenticao e o registro de terminais so feitos atravs de mensagens RRQ e suas res-
postas (RCF, RRJ). No GnuGK, a autenticao configurada na seo [Gatekeeper::Auth].

Diversos mecanismos de autenticao disponveis:
11 Autenticao simples por alias e IP.
11 Utilizao de bancos de dados SQL.
11 Autenticao em servidores RADIUS, entre outros.
A autenticao dos terminais feita atravs das mensagens RRQ (Registration Request)
enviadas dos terminais para o gatekeeper, e das respostas que o gatekeeper d a essas
mensagens, seja RRJ (Registration Reject) ou RCF (Registration Confirm). Para mais detalhes das
mensagens H.225, reveja o Captulo 2.
No GnuGK, a configurao da autenticao de terminais feita inicialmente na seo
[Gatekeeper::Auth] e se estende para outras sees conforme os mecanismos de autenticao selecionados. Esta seo tem, basicamente, a seguinte estrutura:
[Gatekeeper::Auth]
<mecanismo1>=<regra>;RRQ
<mecanismo2>=<regra>;RRQ
...
O exemplo acima mostra a utilizao de dois mecanismos de validao, ambos aplicados
sobre as mensagens RRQ. A sintaxe das linhas que especificam os mecanismos de validao
a seguinte:
<mecanismo>=<regra>;RRQ
Onde:
11 <mecanismo>: indica como ser feita a autenticao: senha simples, utilizando banco de
dados SQL, autenticao por IP, entre outras;
11 <regra>: define se este mecanismo obrigatrio, opcional, ou outras opes;
Figura 3.7
Chamada entre
cliente de rea
diferente.
rea 11
77
11 RRQ: identifica que o mecanismo ir atuar sobre as mensagens RRQ. Pode ser substitudo
por outros valores, como ARQ e GRQ. No restante dos exemplos ser utilizado apenas
RRQ para facilitar o entendimento.
Mecanismos
Existem diversos mecanismos de validao disponveis. Entre os mais importantes esto:
11 SimplePasswordAuth: validao por usurio e senha.
11 AliasAuth: valida uma tupla (alias, IP), onde alias pode ser o apelido ou ramal de um
terminal.
11 SQLPasswordAuth: o mesmo que SimplePasswordAuth, mas utiliza um banco de dados
SQL para armazenar as informaes (usurios e senhas).
11 SQLAliasAuth: o mesmo que AliasAuth, mas utilizando um banco de dados com os aliases.
11 RadAliasAuth: similar a AliasAuth, mas utilizando servidores RADIUS (Remote
Authentication Dial In User Service), que um protocolo de redes que permite o uso de
servios de autenticao, autorizao e contabilizao centralizados em um servidor.
Um servidor RADIUS pode fazer a ponte entre o GnuGK e uma base LDAP.
11 RadAuth: validao de usurio e senha com base no H.235 e utilizando servidores RADIUS.
No restante deste captulo sero vistos, principalmente, os mecanismos SimplePasswordAuth e AliasAuth.
O addpasswd um utilitrio instalado com o GnuGK que permite a criao de senhas criptografadas para serem armazenadas no arquivo de configurao. Duas sees do arquivo
de configuraes onde senhas costumam ser utilizadas so as sees GkStatus::Auth, para
autenticao na conexo com a porta de status, e SimplePasswordAuth, para autenticao
de terminais.
A sintaxe do aplicativo simples, basta escolher o arquivo de configurao e a seo deste
arquivo, onde a senha ser gravada e entrar com o nome de usurio e sua senha. A sintaxe e
um exemplo seguem abaixo:
$ addpasswd [arquivo_de_config] [seo] [usurio] [senha]

$ addpasswd /etc/gatekeeper.ini GkStatus::Auth admin senha123
Em relao s regras, so elas que especificam como (e quanto) o mecanismo deve ser utilizado. Antes de mostrar as regras disponveis, interessante observar que a execuo de um
mecanismo pode ter como resultado um dos 3 valores a seguir:
78
11 ok: a requisio foi autenticada por este mecanismo;

11 fail: a autenticao com este mecanismo falhou e deve ser rejeitada (uma senha incorreta, por exemplo);
11 next: o mecanismo no pode realizar a autenticao (validao de um nome de usurio
no existente na base de dados, por exemplo). V para o prximo mecanismo.
Regras
Sabendo dos possveis resultados, podemos verificar as regras disponveis:
11 optional: se no puder autenticar com este mecanismo, o prximo mecanismo ser utilizado;
11 required: a requisio deve ser autenticada utilizando o mecanismo especificado, caso

contrrio ser rejeitada. Ainda assim, o prximo mecanismo configurado ser checado
para validar o registro;
11 sufficient: o mesmo processo da regra required, com a diferena de que nenhum
mecanismo depois desse ter validade. Ou seja, a resposta dada a este mecanismo a
resposta final autenticao;
11 alternative: o mesmo que sufficient, porm, se o mecanismo no puder decidir se aceita ou
nega o registro (se a resposta for next), ele passa a requisio para o prximo mecanismo.
Vejamos alguns exemplos do uso de mecanismos e regras de autenticao:
11 Exemplo 1:
[Gatekeeper::Auth]
AliasAuth=optional;RRQ
SimplePasswordAuth=sufficient;RRQ
default=allow
Neste exemplo, primeiro feita uma tentativa de autenticao por alias, que opcional. Portanto, se a resposta autenticao for ok ou next, o processo segue para o prximo mecanismo. Mas se a resposta for fail, a requisio de registro negada. O prximo mecanismo
especificado o SimplePasswordAuth, onde feita a autenticao por usurio e senha. Este
mecanismo sufficient e, portanto, decisivo: sua resposta ser a resposta final requisio.
Vale observar que os detalhes de cada um desses mecanismos so configurados em sees
especficas para cada mecanismo, por isso no so apresentados no exemplo.
Alm dos mecanismos, o exemplo mostra a linha default=allow, que define como devem ser
tratadas as requisies para as quais no foi especificado nenhum mecanismo. Por padro
estamos aceitando (allow) todas as requisies diferentes de RRQ, que so tratadas pelos
mecanismos especificados.
11 Exemplo 2:
[Gatekeeper::Auth]
SimplePasswordAuth=alternative;RRQ
default=allow
Autenticao por alias (ID H.323 ou ramal):
11 AliasAuth utiliza a seo [RasSrv::RRQAuth], que possui a sintaxe:
<identificador>=sigip:<endereo IP>:<porta>
Exemplo:
[RasSrv::RRQAuth]
55551234=sigip:200.188.10.1:1720
55556789=sigip:156.130.25.9:1720
Autenticao por usurio e senha:
11 Os mecanismos SimplePasswordAuth, SQLPasswordAuth e RadAuth validam o
RadAuth=sufficient;RRQ
registro dos terminais analisando usurio e senha de acesso.

79
11 O uso de senha requer que o terminal tenha suporte especificao H.235.
Autenticao por usurio e senha:

11 Assim como na validao por alias, cada mecanismo tem sua seo no arquivo
de configuraes:
22 SimplePasswordAuth: utiliza a seo [SimplePasswordAuth] onde esto os dados
de validao.
SQLPaswordAuth: utiliza a seo [SQLPasswordAuth] para configurar um banco de dados
SQL onde esto contidas as informaes de usurio e senha.
RadAuth: utiliza a seo [RadAuth] e busca os dados de um servidor RADIUS.
Neste segundo exemplo, a primeira autenticao feita por usurio e senha. Como est
configurada como alternative, se o resultado for ok ou fail, esta ser a resposta final para a
requisio. Mas, caso o resultado seja next, ser utilizado o segundo mecanismo, RadAuth,
que dar a resposta final. A seguir sero discutidos dois mecanismos de autenticao: a
autenticao por alias (especialmente o AliasAuth) e a autenticao por usurio e senha
(especialmente o SimplePasswordAuth).
Na autenticao por alias, ou seja, por apelido (identificador H.323) ou ramal, podem ser
utilizados os mecanismos AliasAuth, SQLAliasAuth e RadAliasAuth. Eles validam as requisies analisando a associao de alias e endereo IP. Todos eles funcionam de maneira
semelhante, mas so configurados em sees diferentes do arquivo de configuraes e
armazenam os dados de autenticao em locais diferentes:
11 AliasAuth: utiliza a seo [RasSrv::RRQAuth], que onde esto armazenados os dados
de autenticao;
11 SQLAliasAuth: utiliza a seo [SQLAliasAuth] e busca os dados para autenticao em um
banco de dados SQL;
11 RadAliasAuth: utiliza a seo [RadAliasAuth] e busca os dados de um servidor RADIUS.
Como citado, o mecanismo AliasAuth utiliza a seo [RasSrv::RRQAuth]. Esta seo possui
comandos com a seguinte sintaxe:
<identificador>=sigip:<endereo IP>:<porta>
Onde:
11 <identificador>: alias que ser mapeado para o IP especificado.
11 <sigip>: uma das duas opes disponveis. A outra opo sigaddr, que informa que o IP
e porta esto especificados no formato de uma expresso regular; sigip uma especiali Administrao de Videoconferncia
zao do sigaddr, para utilizao do IP e porta no formato padro A.B.C.D:porta.
80
11 <endereo IP>: endereo IP para o qual o alias ser mapeado.

11 <porta>: porta para comunicao com o terminal de IP <endereo IP>.
Exemplo:
[RasSrv::RRQAuth]
55551234=sigip:200.188.10.1:1720
55556789=sigip:156.130.25.9:1720
No exemplo, o terminal com ramal 55551234 mapeado para o IP 200.188.10.1.1 (porta 1720),
enquanto o terminal com ramal 55556789 corresponde ao IP 156.130.25.9 (porta 1720 tambm).
SimplePasswordAuth:
11 Utiliza a seo [SimplePasswordAuth] que possui a sintaxe:
<usurio>=<senha>
11 Senhas de acesso so criadas pelo utilitrio addpasswd.
Na autenticao por usurio e senha, possvel utilizar os mecanismos SimplePasswordAuth,
SQLPasswordAuth e RadAuth. Assim como na validao por alias, cada mecanismo tem sua
seo no arquivo de configuraes:
11 SimplePasswordAuth: utiliza a seo [SimplePasswordAuth], que j contm os dados
de validao;
11 SQLPaswordAuth: utiliza a seo [SQLPasswordAuth] para configurar um banco de
dados SQL onde esto contidas as informaes de usurio e senha;
11 RadAuth: utiliza a seo [RadAuth] e busca os dados de um servidor RADIUS.
Como citado, o mecanismo SimplePasswordAuth utiliza a seo [SimplePasswordAuth]. Esta
seo possui os nomes de usurios e suas respectivas senhas, como no exemplo a seguir:
[SimplePasswordAuth]
fulano=J4rfje7jdk=
sicrano=ee533dgf4g=
beltrano=YY64GGrfje7jdk=
A sintaxe de cada linha <usurio>=<senha>, sendo que estas senhas esto criptografadas,
criadas pelo utilitrio addpasswd. O uso desta ferramenta j foi explicado e segue um exemplo:
Sintaxe:
addpasswd <arquivo_config> <seo> <usurio> <senha>

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

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

11 off: registro gerado no momento em que o gatekeeper desligado.
Seguem exemplos de configuraes de contabilizao:
Exemplo 1:
[Gatekeeper::Acct]
RadAcct=optional;start,stop
FileAcct=required;start,stop,on,off
Neste exemplo, primeiro feita uma tentativa de registro dos eventos start e stop utilizando
um servidor RADIUS. Seja qual for o resultado deste mecanismo, o mecanismo FileAcct ser
executado, onde sero armazenados os eventos start, stop, on e off. O resultado deste segundo
mecanismo ser o resultado final do processo de contabilizao.
Exemplo 2:
[Gatekeeper::Acct]
RadAcct=alternative;start,stop
SQLAcct=sufficient;stop
Neste segundo exemplo, feita uma tentativa de registro em um servidor RADIUS e, em
caso de falha, feito o registro em um banco de dados. Novamente, para mais detalhes
sobre a contabilizao no GnuGK aconselhvel consultar o seu manual.
Modos de operao
O gatekeeper pode operar de trs formas diferentes:

11 Modo direto: sinalizao e mdia so trocadas diretamente pelos terminais.
11 Modo roteamento: sinalizao trocada atravs do gatekeeper.
11 Modo proxy: sinalizao e mdia so trocadas atravs do gatekeeper.
O modo de operao do gatekeeper o controle sobre as informaes de uma chamada que

sero encaminhadas atravs do gatekeeper e quais sero encaminhadas diretamente entre
os terminais. O gatekeeper sempre responsvel pelas mensagens de registro de terminais
(RAS), entretanto, em termos de sinalizao e mdia, pode operar de 3 formas diferentes.
Modo direto
11 Padro de funcionamento do GnuGK.

11 (+) Gatekeeper no se torna um ponto de falha e/ou gargalo na rede.
11 (-) No pode haver contabilizao das chamadas porque o gatekeeper no participa
da inicializao e trmino das chamadas.
Tanto sinalizao quanto mdia so trocadas diretamente pelos terminais, sem passar pelo
gatekeeper. A figura seguinte mostra este modo de operao, onde se pode ver que as nicas
mensagens trocadas com o gatekeeper so as mensagens RAS, para registro dos terminais. J
.2
S
RA
25
25
.2
RA
Gatekeeper
H.225/H245
Call Signaling
Figura 3.8
Gatekeeper operando em modo
direto.
RTP Channels
Terminal 1
as mensagens H.225 de sinalizao e H.245 so trocadas diretamente pelos terminais.
Terminal 2
83
O modo direto o padro de funcionamento do GnuGK e tem como principal vantagem o

fato de que o gatekeeper no se torna um ponto de falha e/ou gargalo na rede caso existam
muitas chamadas. Porm, no pode haver contabilizao das chamadas porque o gatekeeper
no participa da inicializao e trmino das chamadas.
Modo roteamento
11 O gatekeeper participa de toda troca de sinalizao.
11 Mdia trocada diretamente entre os terminais.

11 (+) Possibilita o controle e a contabilizao de chamadas.
Sinalizao trocada atravs do gatekeeper, enquanto a mdia trocada diretamente entre
os terminais. Como se pode ver na prxima figura, agora as mensagens H.225 de sinalizao
e H.245 passam pelo gatekeeper; no GnuGK possvel indicar que s as mensagens H.225
de sinalizao passem pelo gatekeeper, enquanto o H.245 trocado diretamente pelos
terminais, como ser visto na sequncia.
.2
25
RA
Gatekeeper
H.225/H245
Call Signaling
Figura 3.9
Gatekeeper
operando em
modo roteamento.
RTP Channels
Terminal 1
Terminal 2
Este modo de operao tem a vantagem de possibilitar o controle e a contabilizao de

chamadas, e, como no modo direto, dificilmente o gatekeeper se tornar um gargalo na
rede, pois ele s recebe mensagens de sinalizao, enquanto a mdia (os dados que realmente ocupam banda) trocada diretamente pelos terminais.
Modo proxy
Tanto sinalizao quanto mdia so trocadas atravs do gatekeeper.
11 (+) Auxilia quando existem terminais com endereos NAT.
84
11 (+) Auxilia quando existem firewalls na rede. No necessrio liberar o acesso a todos
os terminais, mas apenas ao gatekeeper.
11 (+) Configurao de QoS; a poltica de QoS pode ser aplicada apenas ao endereo IP
do gatekeeper.
11 (-) Pode tornar-se um ponto de falha e gargalo na rede.
Tanto sinalizao quanto mdia so trocadas atravs do gatekeeper. Neste modo de operao, nenhum dado trocado diretamente entre os terminais, tudo passa pelo gatekeeper.
RA
.2
H
RA
25
25
RT
P
.2
l
ne
an
Ch
P
RT
Ch
an
ne
l
Gatekeeper
H.225/H245
Call Signaling
Terminal 1
Terminal 2
Este modo possui algumas vantagens:

11 Auxilia quando existem terminais com endereos NAT invisveis ao mundo;
11 Auxilia quando existem firewalls na rede. Em um terminal, no necessrio liberar o
acesso a todos os terminais, mas apenas ao gatekeeper, j que todas as mensagens e
mdias sero recebidas do gatekeeper;
11 Configurao de QoS. A poltica de QoS pode ser aplicada apenas ao endereo IP
do gatekeeper.
J a grande desvantagem do modo proxy que o gatekeeper pode tornar-se um ponto de
falha e gargalo na rede, j que todo o trfego de todas as chamadas passar por ele.
Configurando o GnuGK
O roteamento configurado na seo [RoutedMode]:
[RoutedMode]
GKRouted=0|1
H245Routed=0|1
AcceptNeighborCalls=0|1
Configurando o GnuGK:
11 Quando GKRouted=0 e H245Routed=0, est em modo direto.
11 Quando GKRouted=1, habilita modo roteamento:
22 Se H245Routed=0, faz roteamento apenas de mensagens H.225.
22 Se H245Routed=1, faz roteamento tambm de mensagens H.245.
AcceptNeighborCalls deve estar em 1 para que o gatekeeper reconhea outras zonas
H.323 (outros gatekeepers).
Para habilitar o modo proxy, deve-se configurar a seo [Proxy]:
[Proxy]
Enable=1
Na seo de roteamento deve estar configurado GKRouted=1.
Figura 3.10
Gatekeeper
operando em
modo proxy.
85
O modo de operao configurado no GnuGK em duas sees. O roteamento, que define

se o gatekeeper far roteamento das mensagens H.225 e H.245 configurado na seo
RoutedMode. Abaixo so exibidos os principais parmetros desta seo:
[RoutedMode]
GKRouted=1
H245Routed=1
CallSignalPort=0
H245PortRange=30000-30999
AcceptNeighborCalls=1
AcceptUnregisteredCalls=0
O parmetro GKRouted indica se o gatekeeper far o roteamento de algum tipo de mensagem ou no, enquanto H245Routed indica se ele far roteamento das mensagens H.245.
Assim, temos as seguintes opes de configurao:
11 Quando GKRouted=0 e H245Routed=0, est em modo direto (Direct Endpoint Call Signalling);
11 Quando GKRouted=1, habilita modo roteamento:
22 Se H245Routed=0, faz roteamento apenas das mensagens H.225 de sinalizao;
22 Se H245Routed=1, faz roteamento tambm de mensagens H.245.
Esta seo possui diversos outros parmetros:
CallSignalPort
Porta de sinalizao do gatekeeper (padro 1721). No utilizada a porta 1720 para ser possvel executar um terminal H.323 de testes no mesmo computador do gatekeeper. Pode ser
configurado com a opo 0 para deixar o gatekeeper escolher arbitrariamente uma porta.
H245PortRange
Portas para serem usadas para os canais de controle H.245. O padro 0, que deixa o
sistema operacional selecionar as portas.
AcceptNeighborCalls
Permite ou no receber ligaes de gatekeepers vizinhos. O padro 1: permitir.
AcceptUnregisteredCalls
Permite ou no chamadas de terminais no registrados no gatekeeper. O padro 0: no permitir.
86
Na seo RoutedMode so configurados os modos de operao direto e roteamento. Para

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

2. Verifique, via telnet (putty), se os clientes esto conectados (usando a porta de status);
3. Efetue ligaes entre os terminais da dupla. Utilize o IP do seu colega para discar.
4. O gatekeeper aceita a chamada quando somente um dos terminais est utilizando-o?
Verifique.
Como o GnuGK e o cliente de videoconferncia esto na mesma mquina, a opo

CallSignalPort=1720 NO deve estar configurada no GnuGK.
Ao modificar o gatekeeper no software de videoconferncia, ele deve ser reinicializado para
a configurao fazer efeito. Outra opo mudar o IP do gatekeeper para um IP errado,
clicar em apply, mudar o IP para o correto e clicar em apply novamente.
Atividade 2 Configurando GnuGK para conexo de clientes autorizados

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

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

5. Registrar os terminais da dupla ao gatekeeper e tentar fazer ligaes de um para o outro
utilizando os ramais (no mais os IPs como nas atividades anteriores).
3.1.Exemplo de autorizao de um ramal: 1000=sigip:143.54.110.28:1720
89
Atividade 3 Habilitando modo proxy

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

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

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

3. Todas as ligaes feitas utilizando o nmero zero como primeiro dgito sero encami-
nhadas para o DGK. O DGK, por sua vez, encaminhar a ligao para a dupla adequada;
4. Os gatekeepers das duplas conhecem apenas o DGK, que por sua vez conhece todos os
gatekeepers das duplas.

A figura abaixo ilustra a arquitetura de gatekeepers que ser utilizada e como sero feitas
as ligaes:
90
Chamada 2:
0222000
Gk dupla
11
DGK
Chamada 1:
2000 ou 0112000
Mquina 1
1000
Mquina 2
2000
22
Mquina 1
1000
Mquina 2
2000
Utilize o Wireshark para depurar possveis problemas durante a atividade.

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

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

5. Efetuar chamadas para clientes de outra dupla: Ex: Cliente 1000 da dupla 11 liga para
cliente 1000 da dupla 22 discando: 0221000.

Durante as atividades ocorreu alguma falha? Se sim, o Wireshark ajudou a identific-la?
Figura 3.11
Arquitetura
de gatekeepers
e estrutura
das ligaes.
Gk dupla
91
92
4
Proporcionar uma viso ampla do protocolo Session Initiation Protocol (SIP), bem
como dos mtodos de configurao de um servidor SIP.
entre SIP e H.323, servidor OpenSIPS (configuraes bsicas, plano de discagem

e autenticao de clientes).
Session Initiation Protocol (SIP)

Protocolo de sinalizao para inicializao, modificao e fechamento de sesses
conceitos
Introduo ao SIP (arquitetura, requisies e respostas, exemplos), comparao
interativas como:
11 Chamadas de voz (VoIP).
11 Videoconferncia.
11 Mensagens instantneas.
11 Jogos multi-usurio via internet.
Protocolo para incio de sesso, utilizado em conjunto com outros protocolos:
11 SDP para descrio da sesso.
11 SAP anncio de sesso.
11 RTP/RTCP transmisso de dados e controle da transmisso.
11 RTSP controle de fluxo em tempo real.
11 SCCP controle de conferncia.
Captulo 4 - Introduo ao SIP
objetivos
Introduo ao SIP
93
SIP
Aplicao
SDP
RTSP
RTP
Transporte
TCP
UDP
IP
Rede
Camada de enlace
RTP
Figura 4.1
Protocolo de
aplicao SIP.
Ethernet
SIP um protocolo que est na camada de aplicao. Alternativo ao H.323 que surgiu em
meados da dcada de 1990, quando a primeira verso do H.323 j estava se tornando um
padro. Inicialmente o SIP foi desenvolvido na Universidade de Columbia e, depois, submetido em 2002 como padro da Internet Engineering Task Force (IETF) RFC 3261.
SIP um padro de sinalizao emergente para o estabelecimento de chamadas e conferncias em tempo real em redes IP. Ele j o padro mais utilizado atualmente para chamadas
de voz sobre IP. J para chamadas de vdeo, o H.323 ainda domina, mas o SIP vem cada vez
ganhando mais espao neste nicho. Uma sesso SIP pode incluir diferentes tipos de dados,
como udio, vdeo, mensagens de texto, entre outros formatos. Podemos dizer que o protocolo SIP foi projetado com o intuito de estabelecer, modificar e manipular chamadas envolvendo um ou mais usurios numa rede IP de modo totalmente independente do contedo
de mdia da chamada.
O SIP um protocolo de aplicao que pode rodar sobre diversos protocolos e tipos de
redes, como UDP, TCP, redes ATM e Frame Relay, entre outros. Ele segue a linha dos protocolos baseados em texto na internet, como o SMTP (Simple Mail Transfer Protocol) utilizado
para correio eletrnico, e o HTTP para pginas web, utilizando mensagens de texto semelhantes s mensagens dos protocolos citados. importante observar que apesar do SIP
poder ser executado sobre UDP, todas as suas mensagens exigem respostas. Portanto, a
garantia de entrega deve, neste caso, ser controlada pelo nvel de aplicao.
As mensagens existentes no SIP so utilizadas para inicializao, finalizao e configurao
de chamadas. Ou seja, ele um protocolo para incio de sesso, e por isso utilizado em
conjunto com outros protocolos, como SDP (Session Description Protocol), SAP (Session
Announcement Protocol), RTP (Real-Time Transport Protocol) e RTCP (RTP Control Protocol) e
94
RTSP (Real-Time Streaming Protocol).
Arquitetura do SIP
Arquitetura cliente/servidor em que agentes de usurio (os terminais) so formados por
duas entidades:
11 User Agent Client (UAC): a parte cliente do agente, responsvel por iniciar as
requisies SIP.
11 User Agent Server (UAS): a parte servidor do agente, responsvel por receber e
responder as requisies SIP.
Um mesmo terminal pode ser UAC e UAS, dependendo da funo que est exercendo.
Alm dos agentes de usurio, o SIP possui trs tipos de servidores:

11 Servidor de redirecionamento: redireciona pedidos SIP (retornando com a
nova localizao).
11 Servidor de registro: aceita registros de entidades SIP.
11 Servidor de proxy: executa o roteamento de pedidos e respostas SIP.
Peer to Peer tambm possvel!
A arquitetura SIP tem por base uma estrutura fundamentada na arquitetura cliente-servidor.
Os terminais SIP so chamados de agentes de usurio. O agente de usurio dito inteligente, pois armazena e gerencia o estado da chamada. Tambm pode utilizar endereos de
correio eletrnico ou nmero telefnico (E.164) na execuo das chamadas. Os agentes de
usurio ainda podem aceitar e receber chamadas de outros agentes sem a necessidade de
adicionar outros componentes SIP.
Figura 4.2
Comunicao
peer to peer entre
componentes SIP.
Os agentes de usurio so formados por duas entidades:

11 UAC User Agent Client a entidade que realiza o papel de cliente no agente de usurio.
Responsvel pela inicializao dos pedidos de sesso (incio das chamadas) e envio de
requisies.
11 UAS User Agent Server a entidade que realiza o papel de servidor no agente de usurio.
responsvel pelo recebimento das requisies enviadas pelos UACs e pelas respostas
enviadas a estas requisies.
Alm dos agentes de usurios, o SIP especifica trs tipos de servidores:
11 SIP Proxy Server (servidores proxy): tipo de servidor intermedirio SIP, responsvel
pelas tarefas de receber as requisies e envi-las aos outros servidores. Seu objetivo
basicamente rotear as chamadas, ou seja, garantir que elas chegaro ao destino (ou
at uma entidade mais prxima do destino). Ele age tanto como um cliente quanto como
um servidor, roteando requisies e respostas. Eles tambm podem ser utilizados para
implementar polticas nas chamadas (verificar permisses dos usurios, por exemplo) e
podem atuar como conversores de mdias.
11 SIP Registrar (servidores de registro): servidor que recebe e processa mensagens de
registro (REGISTER). Prov um mecanismo de localizao de usurios, associando IPs a
endereos dos usurios (URIs identificadas no padro sip:usuario@dominio.com), com
estar associado ao mesmo endereo, ou seja, um mesmo usurio pode estar registrado
em diversas mquinas (IPs).
11 SIP Redirect Server (servidores de redirecionamento): o papel dos servidores de
redirecionamento SIP, como o prprio nome j diz, redirecionar os pedidos ao servidor
de registro. O servidor de redirecionamento SIP responde ao UAC, provendo as informaes de endereamento dos servidores e, ento, o cliente encaminha as requisies ao
endereo fornecido.
funcionamento anlogo ao de um servidor DNS. Vale observar que mais de um IP pode
95
A imagem seguinte ilustra a integrao entre todos os componentes da arquitetura SIP:
SIP Redirect
Server
1
12
<DIAL>
Location
Service
4
11
SIP Proxy
x1
x1
x2
x2
10
SIP Proxy
<RING>
SIP registrar
SIP Proxy
Request
Response
Na imagem, as mensagens com o prefixo x so independentes das outras e a troca delas

feita antes das demais, durante o registro dos terminais no servidor registrar. As mensagens
so iguais para os dois terminais:
11 O terminal envia uma mensagem de REGISTER para o servidor solicitando seu registro.
Esta mensagem contm a identificao deste terminal;
11 O servidor registrar responde informando que o registro foi completado com sucesso ou
insucesso (fornecendo, neste caso, o erro ocorrido).
Segue abaixo a descrio das demais etapas da imagem:
1. Um determinado terminal (User Agent) disca para outro terminal. o UAC deste terminal
que faz a requisio;

2. A requisio recebida por um SIP Proxy que consulta um servidor de redirecionamento
SIP para saber para onde esta requisio deve ser encaminhada;
3. O servidor de redirecionamento responde ao proxy;
4. O proxy ento contata outro proxy, cujo endereo foi informado pelo servidor de
redirecionamento;
5. O segundo proxy contata um servio de localizao para tentar encontrar o terminal destino;
96
6. O servio de localizao informa ao segundo proxy a localizao do terminal de destino;

7. O segundo proxy contata um terceiro proxy, que est mais prximo do destino;
8. O ltimo proxy da sequncia conhece o terminal destino e encaminha a ele a requisio;
9. O UAS do terminal destino responde requisio;
10. De 10 a 12, a resposta volta para o terminal de origem atravs dos proxies SIP. Note que
no preciso contatar servios de localizao ou de redirecionamento, pois o protocolo

SIP guarda informaes para permitir que as respostas sejam encaminhadas pelo mesmo
caminho percorrido pelas requisies.
Figura 4.3
Exemplo da
organizao dos
elementos SIP.
Mensagens e respostas SIP

11 INVITE
11 ACK
11 BYE
11 CANCEL
11 OPTIONS
11 REGISTER
Exemplos: BYE e CANCEL.
11 Ambas so mensagens enviadas com o intuito de finalizar a sesso.
11 BYE enviado aps a sesso j estar estabelecida.
11 CANCEL enviado para cancelar o estabelecimento da sesso (chamada ainda no
atendida quando o telefone est tocando, por exemplo).
Exemplo de uma requisio INVITE:
INVITE sip:aline@inf.ufrgs.br SIP/2.0

From: Marcos<sip:marcos@esr.rnp.br>;tag=1c41
To: sip:aline@inf.ufrgs.br
Call-Id: a84b4c76e66710
Cseq: 1 INVITE
Contact: Marcos<sip:marcos@143.54.12.10>
Content-Type: application/sdp
Content-Length: 304
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER,
SUBSCRIBE
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 08 Sep 2008 10:28:42 GMT
Via: SIP/2.0/UDP sip.ufrgs.br;branch=z9hG4bKnashd
sesso, especialmente em relao s mdias utilizadas.

Exemplo:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
Alm dos campos do exemplo anterior, o INVITE utiliza o protocolo SDP para descrever a
97
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
As requisies e possveis respostas do SIP esto definidas na RFC 3261, de 2002. A RFC
define 6 possveis requisies e 6 classes de respostas, que seguem um formato similar ao
protocolo http, onde as requisies so identificadas por palavras como REGISTER e INVITE,
e as respostas so identificadas por um conjunto de 3 nmeros e classificadas conforme o
primeiro nmero. As tabelas a seguir apresentam estas requisies e respostas com seus
devidos significados:
Requisitos (Cliente para servidor)
Respostas (Servidor para cliente)
INVITE
1xx
Iniciar chamada
Informacional
(telefone tocando, por ex.)
ACK
Confirmao
2xx
Sucesso
(a mais usada 200 OK)
BYE
Finalizar chamada
3xx
Redirecionamento
(tpica de servidores redirect)
CANCEL
OPTIONS
Cancelar requisio
pendente
4xx
Funcionalidades
5xx
(usurio no disponvel, codec incompatvel etc)
Suportadas
REGISTER
Registro com o servidor

de localizao
Falha na requisio
Falha no servidor
(servidor indisponvel, feature no encontrada no
servidor etc)
6xx
Falha global
(falha desconhecida, quando no nenhuma
das outras)
A seguir uma requisio INVITE para exemplificar o formato das requisies SIP:
INVITE sip:aline@inf.ufrgs.br SIP/2.0

From: Marcos<sip:marcos@esr.rnp.br>;tag=1c41
To: sip:aline@inf.ufrgs.br
98
Call-Id: a84b4c76e66710
Cseq: 1 INVITE
Contact: Marcos<sip:marcos@143.54.12.10>
Content-Type: application/sdp
Content-Length: 304
Accept-Language: en
Figura 4.4
Requisies da RFC
3261 (SIP).
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER,

SUBSCRIBE
Supported: sip-cc, sip-cc-01, timer, replaces
User-Agent: Pingtel/2.1.11 (WinNT)
Date: Thu, 08 Sep 2008 10:28:42 GMT
Via: SIP/2.0/UDP sip.ufrgs.br;branch=z9hG4bKnashd
No exemplo, o usurio de nome Marcos, identificado por sip:marcos@esr.rnp.br (na mquina
de IP 143.54.12.10) est fazendo uma chamada para Aline, identificada por aline@inf.ufrgs.br.
Estas informaes podem ser vistas nos campos From, To, Contact e no cabealho da
mensagem. Outro campo bastante importante o campo Via, que indica para onde a resposta a esta requisio deve ser enviada, no caso o domnio sip.ufrgs.br. O uso deste campo
permite que as respostas voltem facilmente para o originador da requisio.
Alm dos campos padro, as requisies INVITE podem utilizar o protocolo SDP para
descrever a sesso, com destaque para a descrio das mdias. O protocolo SDP tambm
baseado em mensagens de texto e possui uma sintaxe bastante simples com diversas
linhas no formato <atributo>=<valor>. Os atributos so formados por apenas uma letra, e os
valores variam conforme o atributo que est sendo especificado. Abaixo exibido exemplo
da descrio SDP de uma sesso:
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
Atributos exibidos no exemplo:
11 v: Verso do protocolo.
11 s: Nome da sesso.
11 i: Informaes sobre a sesso.
11 u: URI da descrio.
11 e: E-mail.
11 t: Tempo de atividade da sesso.
11 m: Nome da mdia e tipo de transporte; identifica as mdias possveis nesta sesso.
11 o: Originador da requisio.
99
Outros exemplos so o BYE e o CANCEL, mensagens enviadas para finalizar a sesso: BYE
enviado aps a sesso estar estabelecida, e CANCEL enviado para cancelar o estabelecimento
da sesso (por exemplo em uma chamada ainda no atendida quando o telefone est tocando).
Quanto s possveis respostas, temos como exemplos as mais utilizadas:
2xx Sucesso
11 200 - OK.
3xx Redirecionamento
11 300 - Mltiplas escolhas.
11 301 - Movido permanentemente.
11 302 - Movido temporariamente.
4xx Falha na requisio
11 400 - Bad request.
11 401 - No autorizado.
11 482 - Loop detectado.
11 486 - Ocupado neste local.
5xx Falha no servidor
11 500 - Erro interno no servidor.
6xx Falha global
11 600 - Ocupado em todos os locais.
Registro SIP
O processo de registro no SIP feito atravs da requisio REGISTER. A requisio bastante simples, sendo enviada de um cliente SIP para um servidor SIP registrar.
Terminal
SIP Registrar
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
Informa que o usurio

aluno@esr.br est na
mquina 143.54.10.12.
Vlido por 1 hora.
2
3
200 ok
No exemplo, (1) o terminal SIP envia a requisio de registro para o servidor localizado no
endereo sip:esr.rnp.br. Entre as informaes da requisio esto:
11 To: contm o endereo de quem est se registrando, no caso aluno@esr.rnp.br.
11 From: contm o endereo de quem est enviando a requisio. Normalmente igual ao
campo to, exceto quando a requisio de registro enviada por terceiros.
11 Contact: informa o endereo da mquina na qual o usurio pode ser encontrado.
11 Expires: durao do registro (em segundos). No exemplo, 1 hora.
100
Banco de dados
Figura 4.5
Requisio
REGISTER SIP.
(2) A requisio recebida pelo servidor registrar, que armazenar as informaes do novo
usurio registrado, normalmente em um banco de dados. (3) Efetuado o registro no lado do
servidor, ele responde para o cliente informando sucesso (cdigo 200).
Diagrama de uma chamada SIP

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

2. O proxy interpreta a requisio e a encaminha para a mquina de endereo 143.54.12.10,
que a mquina na qual o usurio aluno@esr.rnp.br foi registrado.

Aqui assumimos que o proxy j conhece o endereo do terminal destino B, que
poderia ser descoberto com uma consulta a um servidor de localizao.
3. Enquanto a requisio est sendo encaminhada para o terminal B, o proxy avisa ao ter-
minal A que est tentando prosseguir com a comunicao (TRYING);

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

5. Assim que o usurio no terminal B atende a ligao, o terminal envia uma resposta com
cdigo 200 (OK), que recebida pelo proxy e encaminhada para o terminal origem;
6. Ao receber a resposta, o terminal A passa a conhecer o endereo direto do terminal B, e
encaminha para ele uma requisio do tipo ACK para confirmar que a ligao foi estabelecida. Neste ponto os terminais j trocaram suas capacidades atravs do protocolo SDP
embutido nas mensagens INVITE e 200 (OK) e com isso j estabeleceram os parmetros da
transmisso, entre eles os codecs de udio e vdeo e as portas para trocar esses dados;
Figura 4.6
Troca de mensagens
SIP entre dois terminais e um proxy.
Comunicao
de dados
Terminal B
101
7. Durante a comunicao a troca de dados feita usando o protocolo RTP;

8. Em determinado momento o usurio do terminal A decide finalizar a ligao (colocando
o fone no gancho). Seu terminal envia uma requisio do tipo BYE diretamente para o
terminal B avisando que a ligao deve ser finalizada;
9. O terminal B recebe a requisio e envia uma resposta com o cdigo 200 (OK). A ligao
est finalizada.
Comparao SIP e H.323

Funcionalidades similares atravs de mecanismos diferentes:
11 SIP H.225 (RAS + Q.931)

11 SDP H.245
11 Utilizam o mesmo protocolo de transmisso de mdias: RTP/RTCP
11 SIP utiliza texto enquanto H.323 usa binrio (ASN.1)
Comparao geral:
11 SIP utilizado largamente em aplicaes de VoIP.
11 H.323 mais utilizado para vdeo.
11 Utilizao de SIP com vdeo (videoconferncias) tem crescido e tende a ser to usual
quanto H.323.
11 Normalmente os softwares e equipamentos baseados em H.323 tambm suportam
o padro SIP.
Exemplos:
11 Novas linhas de terminais dos principais fabricantes: Polycom, Cisco/Tandberg
e Radvision.
11 Um grande nmero de softwares utilizam SIP para vdeo.
11 Consulte a lista de exemplos no site Product showcase of SIP Conferencing solutions.
Assim como o H.323, o SIP um protocolo que pode ser utilizado para videoconferncias em
redes IP. Ele apresenta funcionalidades similares ao H.323, mas que so alcanadas atravs
de mecanismos ou protocolos diferentes.
A grande diferena entre os protocolos est em sua base: nos protocolos usados para a troca
de mensagens (registro, sinalizao etc.). Enquanto o H.323 utiliza os protocolos H.225 e
H.245, o SIP prov mensagens equivalentes s mensagens do H.225 e utiliza o SDP para prover
funcionalidades equivalentes s do H.245. Outra diferena importante no formato de codificao das mensagens: enquanto o H.323 utiliza uma codificao binria (ASN.1), o SIP utiliza
um modelo mais simples de mensagens textuais, com base em protocolos como o HTTP.
102
As entidades existentes na topologia de cada um dos protocolos tambm so diferentes,

mas possuem certa equivalncia em suas funcionalidades. Os terminais H.323 so simplesmente chamados de terminais, enquanto os terminais SIP so normalmente chamados de
agentes de usurios, e so formados por duas partes: UAS (servidor) e UAC (cliente).
No que se refere ao registro de usurios, o gatekeeper do H.323 equivalente ao servidor
SIP registrar. J para o redirecionamento de mensagens, o SIP utiliza proxies especficos ou
servidores de redirecionamento, enquanto no H.323 este controle feito pelo gatekeeper.
Alm disso, ambos os protocolos utilizam gateways para comunicao com redes externas.
O site Tech-invite
apresenta uma
descrio do SIP
baseada em exemplos,
mostrando diversas
requisies e respostas
de forma grfica.
Apesar das diferenas, os protocolos apresentam alguns pontos em comum: ambos

utilizam o protocolo de transmisso de mdia RTP e suas mensagens de controle podem
trafegar por UDP ou TCP.
A tabela abaixo resume os principais aspectos dos protocolos SIP e H.323:
Figura 4.7
Principais aspectos
SIP e H.323.
SIP
H.323
Codificao
Textual (HTML)
Binrio (ASN.1)
Topologia
Entidades: UA, servidores de

localizao, servidores de
registro, servidores proxy etc.
Entidades: gatekeeper,
Troca de capacidades
Via protocolo SDP
H.245
Roteamento de
chamadas
Topologia hierarquia (DNS)
Anexo G: comunicao entre

domnios administrativos
Protocolo de transporte
UDP e TCP
UDP e TCP
Registro
Registro
Gatekeeper
Autenticao
HTTP
H.235
Encriptao
Possui trs mtodos de

encriptao
H.235
gateway, terminais etc.
aplicao atual de cada um dos protocolos, o uso do SIP j est amplamente

w Quanto
difundido para uso em aplicaes VoIP, enquanto o H.323 o mais utilizado para videoconferncias. Apesar disso, a utilizao do SIP para videoconferncias tem crescido, e ele tende
a tornar-se to ou mais utilizado que o H.323. Um dos motivos para isso a tendncia no
mercado para que equipamentos baseados em H.323 passem a suportar tambm o padro
SIP. Diversas linhas de terminais dos principais fabricantes j suportam SIP (Polycom, Cisco/
Tandberg e Radvision), assim como um grande nmero de terminais em software.
OpenSIPS
11 Open SIP Server um software livre sob licena GPL.
11 Servidor SIP completo: registrar, location, proxy e redirect.

Algumas caractersticas:
11 Segue uma arquitetura modular buscando escalabilidade.
11 Flexibilidade de programao (linguagem de script).
11 Suporte autenticao, autorizao e contabilizao via Radius ou SGBD.
11 Integrao com SGBDs: MySQL, Postgres, entre outros.
Originalmente, o projeto OpenSIPS era chamado de OpenSER, mas a partir de 2008 este
projeto se ramificou em dois, formando os projetos OpenSIPS e Kamailio.
Entre as funcionalidades do OpenSIPS, ressalta-se a adaptao a sistemas pequenos com
recursos limitados e tambm a sistemas grandes. capaz de suportar milhares de chamadas por segundo, e graas sua arquitetura modular permite a criao de novas funcionalidades (mdulos e API) conforme a necessidade do cliente. Segundo o site do projeto, em
sistemas com 4GB de memria ele suporta 300 mil usurios on-line, e pode suportar at 5
O website Product
showcase of SIP
Conferencing solutions
mostra uma lista de
solues de conferncia que utilizam SIP.
mil chamadas por segundo quando em modo stateless.

103
Instalao OpenSIPS
As ltimas verses do OpenSIPS podem ser obtidas no site. A instalao varia conforme
a plataforma alvo. O OpenSIPS disponibiliza pacotes prontos para algumas plataformas:

11 OpenSUSE.
11 CentOS.
11 Debian (utilizada neste curso).
11 Fedora.
Para outras plataformas possvel baixar e compilar o cdigo-fonte.
Sendo uma aplicao de cdigo aberto, o OpenSIPS disponibiliza em sua pgina tanto
o cdigo-fonte da aplicao quanto alguns pacotes (binrios) para sistemas especficos.
Atualmente, so disponibilizados pacotes para as plataformas OpenSUSE, CentOS, Fedora e
Debian, sendo este ltimo utilizado neste curso.
A instalao do OpenSIPS possui algumas peculiaridades conforme a plataforma na qual est
sendo instalado. No consta no escopo deste curso a abordagem de todas as opes possveis, portanto a instalao ser feita de forma simples, utilizando pacotes j compilados. Este
curso se baseia no uso do OpenSIPS em uma mquina virtual com o sistema Linux, o mesmo
modelo adotado no captulo sobre GnuGK. Para instalar o OpenSIPS de forma prtica, basta
fazer download do pacote para Debian e instal-lo com o gerenciador de pacotes.
Aps a instalao do OpenSIPS, os arquivos mais importantes da aplicao estaro
instalados em:
11 Arquivo de configuraes iniciais: /etc/default/opensips
11 Arquivo de configuraes gerais: /etc/opensips/opensips.cfg
11 Arquivos binrios: /usr/sbin/
11 Mdulos: /usr/lib/opensips/modules/
11 Logs: /var/log/
O arquivo de configuraes iniciais chamado opensips contm algumas configuraes
bsicas necessrias para a inicializao do OpenSIPS, como o usurio e o grupo do sistema
operacional que sero utilizados e a quantidade de memria que ser alocada para a
aplicao. Este arquivo tambm contm uma opo chamada RUN_OPENSIPS que est
inicialmente com o valor no, com intuito de no permitir a execuo da aplicao antes que
ela seja configurada. Aps a configurao, basta modificar o valor desta opo para yes
que a execuo do OpenSIPS liberada.
J o arquivo opensips.cfg contm as configuraes do funcionamento do servidor Open-
104
SIPS. Este arquivo segue um formato de linguagem script, que permite que as funcionalidades do servidor sejam programadas. As configuraes do restante deste captulo sero
feitas neste arquivo. Os arquivos executveis da aplicao esto localizados no diretrio
/usr/sbin/ e os mdulos utilizados esto em /usr/lib/opensips/modules/.
Inicializao OpenSIPS
Existem diversas opes de inicializao do OpenSIPS, que podem ser verificadas
atravs do comando:
$ opensips h
Comando opensips:
11 [-f arquivo] especifica arquivo de configurao.

11 [-c] verifica se existem erros no arquivo de configurao.
11 [-d] nvel de debug; quanto maior o nmero de ds, maior ser o nvel de debug.
11 [-l protocolo:interface:porta] especifica as interfaces de rede que sero
utilizadas (protocolos UDP ou TCP).
Exemplo:
$ opensips l udp:192.168.1.100:5080 f /usr/local/etc/opensips/

opensips.cfg -d
O utilitrio opensipsctl um script utilizado para realizar operaes de manuteno no
OpenSIPS. Este utilitrio muito til para diversas tarefas:
11 Iniciar/parar a aplicao.
11 Obter listagem de usurios on-line.
11 Informaes estatsticas de uso do sistema.
O comando opensips deve ser usado pelo super usurio (root). Usurios normais normalmente no possuem acesso ao comando sem especificar o caminho completo da aplicao.
Ou seja, um usurio normal precisaria executar o comando /usr/sbin/opensips.
necessrio configurar o arquivo /etc/default/opensips antes de executar o OpenSIPS
pela primeira vez.
Para auxiliar a realizao de algumas tarefas, existe o utilitrio opensipsctl. Este script pode
executar diversas tarefas, entre elas iniciar e parar a aplicao, obter listagem de usurios
on-line e informaes estatsticas de uso do sistema. Alguns comandos possveis:
11 opensipsctl stop|start|restart
11 opensipsctl ul show exibe lista de usurios.
11 opensipsctl online exibe usurios on-line.
11 opensipsctl monitor monitora a aplicao atualizando as informaes periodicamente.
Para uma lista de todas as opes possveis basta executar o comando opensipsctl sem
nenhum parmetro adicional. Alm deste script, outra forma de inicializar o OpenSIPS
utilizando o script do sistema operacional para inicializar a aplicao durante o boot:
$ /etc/init.d/opensips <opo>
Opes possveis: start, stop, restart, force-reload, debug e status. Para v-las, basta exe-
Se o OpenSIPS j estiver em execuo, o comando opensipsctl start vai falhar, o que

normalmente acontece porque o sistema j iniciou a aplicao durante o boot. Portanto, primeiro pare a aplicao com /etc/init.d/opensips stop.
Com as configuraes padro instaladas com OpenSIPS, ele j pode ser executado de
forma funcional. Todos os clientes se registram automaticamente com o nome configurado
(no cliente) e sem validao nenhuma. J possvel tambm fazer ligaes de um cliente
para o outro informando o nome do usurio do outro cliente.
cutar o comando sem fornecer nenhuma opo.
105
Arquitetura modular OpenSIPS

A estrutura do OpenSIPS pode ser dividida em duas partes:
11 Ncleo: responde pelo funcionamento bsico e controle dos mdulos.

11 Mdulos: cada um adiciona funcionalidades especficas ao software, inclusive as
funcionalidades SIP.
Principais mdulos:
Funo proxy
11 Transaction (TM)
11 Stateless Replier (SL)
11 Record-Route e Route Mode (RR)
Funo registrar
11 Registrar
Funo location
11 Localizao de usurios (Usrloc)
11 Database API (MySQL, Postgres e DBtext)
Funes gerais
11 Contabilizao (ACC)
11 Autenticao (AUTH)
11 Autenticao com banco de dados (AUTH_DB)
Os mdulos so carregados atravs do arquivo de configuraes.
OpenSIPS adota uma arquitetura modular, onde o software composto por um ncleo bsico
ao qual podem ser conectados diversos mdulos para prover funcionalidades ao software.
11 Ncleo: responde pelo funcionamento bsico e controle dos mdulos. O ncleo responsvel pelas configuraes locais, como nvel de depurao, portas TCP e UDP utilizadas,
modo de operao etc;
11 Mdulos: existem diversos mdulos, sendo que cada um adiciona funcionalidades especficas ao software, inclusive as funcionalidades SIP.
Os mdulos so carregados atravs do arquivo de configuraes, onde possvel passar
parmetros para a sua inicializao. Ao carregar um mdulo, ele prover funes que
podem ser utilizadas na programao do arquivo de configuraes.
O OpenSIP disponibiliza diversos mdulos. Segue uma lista com uma breve descrio dos
mais importantes:
106
11 Mdulo TM: processamento de transaes SIP stateful (transaes stateful e stateless

sero explicadas posteriormente);
11 Mdulo SL (Stateless Replier): implementa a funo de proxy SIP stateless, ou seja,
capaz de responder a requisies SIP sem manter o estado da comunicao;
11 Mdulo RR (Record-Route e Route Mode): implementa as funes de controle do modo
de roteamento (Route);
11 Mdulo Registrar: implementa a lgica de processamento do mtodo REGISTER para
registro de usurios;
11 Mdulo USRLOC (User Location): mantm a tabela de localizao de usurios e prov

acesso a essa tabela para outros mdulos;
11 Mdulos DB_*: existem diversos mdulos com nome iniciado pelo prefixo DB_, o que
indica que so mdulos que permitem a interao do OpenSIPS com alguma base de
dados. H entre eles os mdulos DB_MYSQL, DB_POSTGRES e DB_TEXT, que proveem,
respectivamente, comunicao com o banco de dados MySQL, com o banco de dados
Postgres e com bancos de dados em formato texto;
11 Mdulo AUTH: implementa funes bsicas de autenticao;
11 Mdulo AUTH_DB: implementa funes de acesso a banco de dados para autenticao.
Configurao OpenSIPS
A estrutura do arquivo de configurao formada por arquivo texto padro composto
por 3 sees:
11 Configuraes globais: configuraes gerais do sistema, como o nvel de depurao,
controle sobre o log da aplicao, definio das interfaces de rede que sero utilizadas, entre outras.
11 Configuraes dos mdulos: carregamento dos mdulos e configuraes dos
seus parmetros.
11 Lgica de roteamento: script que define o modo de funcionamento do sistema. Toda
lgica de roteamento definida atravs de uma estrutura de configurao similar a
uma linguagem de programao (declarao e chamada de funes, clusulas condicionais if, else etc).
A seguir sero apresentadas essas 3 sees e discutidas algumas das configuraes
mais importantes.
Configuraes globais
Existem diversas configuraes possveis nesta seo. As mais utilizadas so:
11 debug: opes: nmero entre 0 e 9. Define o nvel de depurao, ou seja, a quantidade de
informaes exibida nos logs;
11 fork: opes: YES ou NO. Se YES, abre um processo para cada interface de rede e cada
protocolo (TCP e UDP). Se NO, roda tudo em processo nico;
11 log_stderror: opes: YES ou NO. Indica se os erros devem ser enviados para a sada de
erro padro do sistema (stderr) ou para o syslog. utilizada para depurao, pois facilita
a verificao dos erros;
11 log_facility: parmetro que indica o facility para o syslog (mecanismo de log do sistema
operacional). uma maneira de indicar a aplicao que gerou a mensagem de log;
11 listen: formato: <protocolo>:<IP>:<porta>. Indica o endereo IP/porta utilizado
para aguardar as requisies e o protocolo que ser permitido neste IP/porta. Ex:
listen=udp:143.54.12.10:5064;
11 alias: identificao do servidor local. A declarao de alias tem relao com a varivel
myself, que utilizada no script para identificar se uma mensagem foi enviada para este
servidor. Ex: alias=esr.rnp.br:5060.
w
A lista completa de
mdulos pode ser
encontrada no site do
OpenSIPS (verso 1.6.0)
em OpenSIPS
Resources
DocsModules16.
Depende dos mdulos AUTH e de banco de dados (MySQL, Postgres etc).
107
Algumas opes da seo de configuraes globais:
debug=9
# Nvel de depurao
fork=yes|no
# Proxy cria um processo para cada interface de rede ou gerencia tudo
num nico processo
log_stderror=Yes|no5
# Log de erros na sada stderr ou syslog
log_facility=LOG_LOCAL35
# Parmetro para syslog
listen=192.168.1.100:5060 # Interface de rede para esperar requisies

alias=lab.esr.rnp.br5
# Nome deste servidor SIP
A lista completa de parmetros da verso 1.6.0 pode ser encontrada em OpenSIPS

Resources DocsCoreFcn16.
Para rodar a aplicao em modo depurao, marque a opo fork=no e inicie o
OpenSIPS com o comando: /etc/init.d/opensips debug.
Configuraes dos mdulos

Esta seo define todos os mdulos que sero carregados e define os parmetros que sero
passados para configur-los. O carregamento dos mdulos feito de forma simples. A varivel mpath indica o diretrio onde esto os mdulos, que so carregados usando o comando
loadmodule, como no exemplo abaixo:
mpath=/usr/lib/opensips/modules/
loadmodule sl.so
loadmodule tm.so
loadmodule registrar.so
A configurao dos parmetros dos mdulos feita com o comando modparam, como nos
exemplos abaixo:
modparam(auth_db, db_url,
mysql://opensips:opensipsrw@localhost/opensips)
modparam(acc, repost_ack, 1)
modparam(registrar, max_contacts, 10)
O comando modparam recebe trs argumentos: o nome do mdulo, o nome da varivel e o
valor a ser atribudo varivel, respectivamente.
Lgica de roteamento
A lgica de roteamento define todo o tratamento que ser feito com as requisies recebidas
pelo OpenSIPS, seja qual for o tipo dessas requisies (INVITE, REGISTER, BYE, CANCEL etc).
O funcionamento do OpenSIPS se assemelha ao de um script que executado toda vez que
uma requisio SIP recebida. O ponto de partida do script o bloco denominado route{}, que
contm toda a lgica de roteamento (ou parte da lgica e chamadas para outros blocos, que
contm o restante da lgica). Sempre que uma requisio recebida, tem incio a execuo
sequencial dos comandos encontrados neste bloco. O processamento contnuo at o ponto
onde ocorre a deciso final sobre a requisio: at a requisio ser encaminhada ou ignorada,
por exemplo. O exemplo abaixo exemplifica de forma bastante simplificada o bloco route{}:
108
route {
if(is_method(OPTIONS)) {
# send reply for each options request
sl_send_reply(200, ok);
exit();
}
route(1);
}
route[1] {
# forward according to uri
forward();
}
No exemplo, o servidor responder a todas as requisies do tipo OPTIONS com uma mensagem 200/OK (definida no bloco if{}). Para as outras requisies, feita uma chamada a um
bloco secundrio de roteamento route[1], que apenas encaminhar a requisio.
Modos de operao OpenSIPS

Um proxy SIP pode operar de dois modos:
Modo Stateless
Oferece melhor escalabilidade, pois no armazena informaes de estado e requer
menos recursos, principalmente memria. O mdulo responsvel pelo modo stateless
o SL. Toda funo iniciada por sl_ indica que a comunicao ser feita sem manter
informaes de estado.
Modo Stateful
O mdulo responsvel pelo modo stateful o TM. Toda funo iniciada por t_ indica
que o processo ser tratado como stateful. A escolha entre o estado stateless ou stateful
importante, pois muda a forma com que algumas requisies so tratadas.
O modo stateless oferece melhor escalabilidade, pois no precisa armazenar tantas informaes de estado como no modo stateful, portanto, requer menos recursos (principalmente
iniciadas por sl_, ou seja, o uso de qualquer funo com prefixo sl_ indica que a comunicao ser feita sem manter informaes de estado. O mdulo responsvel pelas funes
stateful o TM, que fornece as funes com prefixo t_.
A escolha entre os estados stateless ou stateful importante, pois muda a forma com
que algumas requisies so tratadas.
memria). O mdulo responsvel pelas funes stateless o SL. Ele fornece todas as funes
109
A requisio CANCEL, por exemplo:

11 Em stateful, o script pode simplesmente chamar uma funo do mdulo TM (t_relay())
e ela saber como tratar a mensagem, pois o servidor guardou as informaes sobre
a requisio inicial, o INVITE.
11 Em stateless, deve aplicar ao CANCEL toda a mesma lgica de roteamento aplicada
para o INVITE, pois no manteve as informaes.
Alm disso, h algumas funcionalidades que necessitam do estado das transaes para funcionarem, como o mdulo de contabilizao (mdulo ACC). Associado aos mdulos stateless
e stateful, est o mdulo RR (Record-route), que possibilita a gravao da rota pela qual as
requisies passaram.
Essa rota guardada no cabealho das mensagens atravs de duas funes principais:
11 record_route( ): grava a rota nas requisies.

11 loose_route( ): limpa a rota nas respostas.
As imagens abaixo exemplificam as chamadas record_route( ) para gravar a rota de uma
requisio INVITE e as chamadas loose_route( ) para liberar as rotas quando feita a requisio
BYE (que est relacionada ao INVITE inicial). Como a rota foi gravada durante a requisio
INVITE, garantido que a requisio BYE passar pelo servidor SIP que gravou seu endereo
nesta rota.
record_route()
record_route()
INVITE
A
Rota: A
INVITE
Servidor
SIP S1
Rota: S1, A
INVITE
Servidor
SIP S2
B
Rota: S2, S1, A
Rota: S1, S2, B
Rota: S2, S1, A
loose_route()
BYE
Rota: A
110
loose_route()
BYE
Servidor
SIP S1
Rota: S1, S2, B
Rota: A, S1
BYE
Servidor
SIP S2
B
Rota: S2, S1, A
Rota: S2, S1, A
Antes de utilizar o script opensipsdbctl, o arquivo opensipsctlrc deve ser editado para
incluir as configuraes de acesso ao banco de dados. Este arquivo est localizado
em /etc/opensips/ e as variveis mais importantes que devem ser configuradas so:
DBENGINE, DBHOST, DBNAME, DBRWUSER e DBRWPW. Elas j possuem os valores
padro configurados, que sero os valores utilizados neste curso. A estrutura completa das tabelas necessrias para o funcionamento do OpenSIPS pode ser consultada no site do desenvolvedor.
Figura 4.8
Rota da requisio
INVITE.
Figura 4.9
Rota da requisio
BYE.
Integrao com banco de dados OpenSIPS

Indispensvel para implantao de um servidor OpenSIPS. Vrios mdulos fazem uso de
algum tipo de informao armazenada em banco de dados:

11 Registro de usurios (funo registrar).
11 Contabilizao.
11 Localizao de usurios.
11 Entre outros.
Mdulo carregado e configurado no arquivo de configuraes. Exemplo:
loadmodule mysql.so
modparam(auth_db|usrloc|acc, db_url,
A configurao das tabelas no banco de dados pode ser feita com o script opensipsdbctl:
$ opensipsdbctl create opensips

(cria o database opensips)
$ opensipsdbctl reinit opensips

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

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

(modificar a senha de um usurio cadastrado)
O uso de um banco de dados indispensvel para implantao de um servidor OpenSIPS,
mesmo que seja utilizado um banco mais simples, como em arquivos texto. Se nenhum
banco de dados for utilizado, as informaes de localizao dos usurios registrados sero
mantidas em memria, portanto em caso de falhas ou reinicializao do servidor, elas
acabam sendo perdidas. Diversos mdulos do OpenSIPS utilizam algum tipo de informao
armazenada em banco de dados, como por exemplo os mdulos de registro de usurios
O OpenSIPS fornece diversos mdulos para integrao com alguns bancos de dados,
entre eles:
11 DB_MYSQL: MySQL
11 DB_POSTGRES: PostgreSQL
11 DB_TEXT: Dbtext
Assim como os outros mdulos comentados, os mdulos de banco de dados so carregados
e configurados na seo de mdulos do arquivo de configuraes. O exemplo abaixo mostra
o carregamento do mdulo para MySQL e da atribuio de dois parmetros aos mdulos:
(servidor registrar), contabilizao de ligaes e localizao de usurios.
111
loadmodule mysql.so
modparam(auth_db|usrloc|acc, db_url,
modparam(usrloc, db_mode, 1)
No exemplo, a primeira linha carrega o mdulo enquanto as outras duas atribuem os parmetros. O primeiro parmetro atribudo aos mdulos AUTH_DB, USRLOC e ACC, enquanto
o segundo parmetro s atribudo ao mdulo USRLOC (pois s existe neste mdulo).
A configurao de db_url (que comum aos mdulos AUTH_DB, USRLOC, ACC e outros) diz
respeito localizao e a informaes de acesso ao banco de dados. O valor atribudo a esta
opo segue, na maioria dos casos, o formato: banco://usurio:senha@ip:porta/database.
No exemplo, est sendo indicado que ser utilizado o usurio opensips com senha opensipsrw para se conectar ao database opensips do banco de dados MySQL localizado na
mquina localhost. Este formato pode variar em casos como no uso do DB_TEXT, que segue
um formato como o do exemplo abaixo:
modparam(auth_db , db_url, dbtext:///var/dbtext/opensips)

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

(cria o database opensips)
$ opensipsdbctl reinit opensips
112
(destri e recria todo o database opensips)

Alm disso, algumas operaes sobre o banco de dados tambm podem ser feitas com o
script opensipsctl, como o gerenciamento de usurios cadastrados:

(cadastrar usurio)
(remover usurio)

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

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

return;
};
if (!t_relay()) { # s depois tenta encaminhar a requisio
sl_reply_error();
};
exit;
}
Plano de discagem OpenSIPS

Como implementado um plano de discagem? Para a criao de um plano de discagem
de if s e elses. Exemplo:
11 OpenSIPS recebe um nmero para o qual um terminal est discando.
11 O formato do nmero verificado.
11 O nmero reescrito em formato padro, para facilitar verificaes:
22 Cdigo do pas + cdigo de rea + nmero do terminal.
# Discagem Nacional
completo, equivalente ao visto no GnuGK, ser preciso definir uma estrutura composta
if (uri=~sip:0[1-9].*) { # sip:0 21 88889999@esr.rnp.br

113
strip(1);
# sip:21 88889999@esr.rnp.br
prefix(55);
# sip:55 21 88889999@esr.rnp.br
# Discagem Internacional
} else if (uri=~sip:00[1-9].*) { # sip:00 55 21 88889999@esr.rnp.br
strip(2);
# sip:55 21 88889999@esr.rnp.br
# Discagem local
} else if (uri=~sip:[2-9][0-9]{7}@.*) { # sip:88889999@esr.rnp.br
prefix(5521);
# sip:55 21 88889999@esr.rnp.br
} else { # qualquer endereo SIP invlido

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

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

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

A autenticao SIP feita por requisies do tipo REGISTER.
O servidor OpenSIPS trata estas requisies para liberar ou bloquear o acesso do

terminal que fez a requisio.
No OpenSIPS, a lgica de processamento do REGISTER envolve basicamente o uso das
seguintes funes:
11 www_authorize(dominio, tabela) do mdulo AUTH_DB
Valida as credenciais utilizadas para autenticao (usurio e senha enviados com
o REGISTER) de acordo com a RFC 2617. Parmetros:
<domnio>: domnio do servidor SIP.
<tabela>: tabela do banco de dados que contm as informaes das credenciais.
Caso a autorizao falhe, esta chamada feita para desafiar o terminal a tentar o
registro novamente. Parmetros:
<domnio>: domnio do servidor SIP.
<qop>: parmetro necessrio para o mecanismo de desafio-resposta, com valor 0 ou 1.
11 db_check_to() do mdulo URI
Valida o campo To: , que na requisio REGISTER contm o endereo do terminal que
est sendo registrado.
11 ww_challenge(dominio, qop) do mdulo AUTH
Funo antes chamada de check_to() no mdulo URI_DB.

115
11 save(tabela) do mdulo registrar

Chamada aps o registro ser feito com sucesso, salva a informao de registro na
tabela tabela.
Script de exemplo da autenticao de usurios:
if (!www_authorize(esr.rnp.br, subscriber)) {
# usurio no
autorizado
www_challenge(esr.rnp.br, 0);
exit;
}
# usurio foi autorizado
if (!db_check_to()) {
# campo To: invlido
sl_send_reply(403, Forbidden auth ID);

exit;
}
if (!save(location)) {
# no conseguiu graver informaes de
registro
sl_reply_error();
return;
}
exit;
No script, o primeiro passo uma tentativa de autenticao no domnio esr.rnp.br:
if (!www_authorize(esr.rnp.br, subscriber)) {
Em caso de falha, feito o desafio para o usurio fornecer novas credenciais:
www_challenge(esr.rnp.br, 0);
Caso a resposta para a autenticao seja positiva, feita a validao do campo To: da mensagem, que no REGISTER contm o endereo do terminal que est solicitando o registro:
if (!db_check_to()) {
Se o campo To: for invlido, enviado um aviso ao usurio informando que o ID de autenticao invlido:
sl_send_reply(403, Forbidden auth ID);

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

11 Remover usurios:
11 Modificar a senha de um usurio cadastrado:
Contabilizao OpenSIPS
O registro das chamadas permite contabilizar a utilizao do sistema.
Contabilizao utiliza o mdulo ACC:

11 Pode registrar eventos no sistema (Syslog), bancos de dados e RADIUS.
11 Utilizao do mdulo praticamente transparente no script: basta informar ao
mdulo que os dados devem ser registrados e ele se encarrega do resto.
# seta a flag que ser usada para indicar ao ACC que deve iniciar
contabilizao
modparam(acc, db_flag, 1)
setflag(1); # avisa o ACC para contabilizar o INVITE
} else if (method==BYE) {
setflag(1); # avisa o ACC para contabilizar o BYE
}
A gerao de registro das chamadas indispensvel para avaliar a utilizao do sistema. No
OpenSIPS, toda a contabilizao feita pelo mdulo ACC. Este mdulo permite o registro de
eventos no sistema (syslog), bancos de dados e RADIUS.
A utilizao do mdulo praticamente transparente no script: basta informar ao mdulo
que os dados devem ser registrados e ele se encarrega do resto. O mdulo permite contabilizar
sero gravadas. Mas h sempre um conjunto mnimo de informaes que so contabilizadas:
11 Nome do mtodo (INVITE, ACK, BYE, etc.).
11 Campos To, From e Call-Id do cabealho.
11 Cdigo e mensagem da resposta gerada.
11 Informaes de tempo de quando a transao foi finalizada.
informaes a qualquer momento e tambm permite a personalizao das informaes que
117
Para realizar a contabilizao, o script deve basicamente chamar a funo setflag(ID) no

momento adequado. O uso desta funo ser explicado com um script de exemplo abaixo:
loadmodule mysql.so # 1
loadmodule acc.so
# 1
modparam(acc, db_url, mysql://opensips:senha@localhost/

opensips)# 2
modparam(acc, db_flag, 1)
# 2
setflag(1); # 3
} else if (method==BYE) {
setflag(1); # 4
}
Os identificadores # ao longo do script mostram as quatro etapas:
1. Carregamento do mdulo do banco de dados MySQL e do mdulo de contabilizao ACC.
2. Definidos dois atributos no mdulo ACC:
2.1.O primeiro para que ele utilize o banco de dados MySQL para armazenar as informaes;
2.2.O segundo define que a flag de contabilizao ser a com valor 1. Esta flag utili-
zada posteriormente para habilitar a contabilizao.

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

4. O mesmo que o item anterior, mas agora habilita a contabilizao da requisio BYE.
Para uma contabilizao completa, aconselhvel monitorar pelo menos as requisies

INVITE, ACK e BYE. Esses trs mtodos consistem da estrutura de uma transao SIP: Incio =
INVITE, Estabelecimento = ACK e Fim = BYE.
Gerao de logs OpenSIPS

O log de eventos fundamental para o acompanhamento do funcionamento do sistema,
diagnstico e resoluo de problemas. O mdulo XLOG oferece recursos poderosos para
implementar o registro de eventos.
118
O registro de eventos fundamental para o acompanhamento do funcionamento do

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

11 Registra uma mensagem no sistema de log.
11 <nvel> opcional e indica a classe da mensagem: alerta, erro crtico etc.
Os valores so compatveis com o sistema syslog:

11 L_ALERT - log level 3
11 L_CRIT - log level 2
11 L_ERR - log level 1
11 L_WARN - log level 1
11 L_NOTICE - log level 2
11 L_INFO - log level 3
11 L_DBG - log level 4
As mensagens so armazenadas pelo sistema de log padro syslog em /var/log/. Algumas
configuraes de log j foram mostradas, como as duas configuraes globais abaixo:
log_stderror=no
# Log de erros na sada stderr
log_facility=LOG_LOCAL3
# Parmetro para syslog
Outro recurso interessante do XLOG a possibilidade de usar variveis de ambiente

(pseudo-variveis) junto da mensagem de texto. Existem diversas pseudo-variveis, como:
11 $dp Porta utilizada.
11 $dP Protocolo de transporte.
11 $du URI de destino.
11 $fu URI do campo From.
11 $fU Identificador de usurio da URI do campo From.
11 $rm Mtodo SIP.
11 $ru URI.
11 $tu URI do campo To.
11 $tU Identificador de usurio da URI do campo To.
11 $tf Hora/Dia.
11 $ua Dados do cliente SIP(UA).
Abaixo temos um script exemplificando o uso do mdulo XLOG:
loadmodule xlog.so
xlog(L_ALERT, Chegou um mtodo ($rm) para o usurio ($ru)
\n);
} else if (method==REGISTER) {
xlog(L_ALERT, Chegou um REGISTER de $fU ($ru) em $tf\n);
return;
}
A lista de pseudo-variveis do OpenSIPS pode ser localizada em OpenSIPS Resources.
return;
119
120
Atividade 1 Ligao SIP atravs do X-Lite
Nesta atividade ser utilizado o software X-Lite para realizar chamadas entre dois terminais.
O primeiro passo configurar o X-Lite, software que requer que o usurio configure uma
conta local (com informaes bsicas apenas, como seu nome) e um servidor SIP. Este servidor SIP ser fornecido pelo instrutor.
Configure o X-Lite e faa uma ligao para o colega de dupla. Para ligar basta utilizar o
Username do colega, conforme configurado no X-Lite.
Capture uma ligao completa entre seu terminal e o terminal do colega. Utilize um software
de sniffer de redes, como Wireshark, e responda as questes a seguir:
1. Desenhe as mensagens SIP (protocolos e portas) trocadas entre as duas mquinas
clientes e com o servidor fornecido pelo instrutor. No Wireshark, utilize o menu

Telephony -> VoIP Calls para ver o diagrama e apoiar o desenho.
2. O que mudou em relao s mensagens SIP obtidas na atividade durante a prtica inter-
mediria (ponto-a-ponto sem servidor)?
3. Acesse o menu Telephony -> VoIP Calls e tente escutar a conversa.
Atividade 2 Configurao e utilizao de um servidor SIP: OpenSIPS

Nesta atividade ser configurado um servidor OpenSIPS como o que foi utilizado pelo
instrutor na atividade anterior. Este servidor est instalado na mquina virtual que ser
fornecida pelo instrutor.
O OpenSIPS j est instalado nas mquinas virtuais. O arquivo de configuraes
padro est em: /etc/opensips/opensips.cfg.
As configuraes do OpenSIPS na mquina virtual j permitem que ele seja utilizado, ou
seja, nessa atividade no sero necessrias alteraes nas configuraes do servidor.
O intuito desta atividade que cada dupla passe a utilizar o seu servidor OpenSIPS e
aprenda os comandos mais importantes para gerenciar a aplicao.
OpenSIPS, logo a seguir, como apoio para a execuo dos passos):

1. Iniciar/Parar a aplicao.
2. Verificar a localizao do arquivo de configurao.
3. Monitorar a aplicao.
4. Configurar o OpenSIPS da dupla no X-Lite e efetuar ligaes entre os terminais da dupla.
Os membros da dupla devero realizar os seguintes passos (leia as Dicas para uso do
121
Dicas para uso do OpenSIPS

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

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

Na atividade anterior, o servidor OpenSIPS estava configurado de forma bastante bsica e
sem restries de acesso: qualquer terminal poderia utilizar o servidor. Nesta atividade ser
includa a validao bsica de usurios atravs de nome de usurio e senha.
Para o cadastro dos usurios utilizado um banco de dados (MySQL) que j est instalado
nas mquinas virtuais. A atividade ser habilitar a validao de usurios, incluir os usurios
no banco de dados e efetuar ligaes utilizando clientes X-Lite devidamente registrados e
autorizados no OpenSIPS.
A autenticao j est preparada no OpenSIPS. Para habilit-la, descomente as seguintes
linhas no arquivo /etc/opensips/opensips.cfg:
122
loadmodule db_mysql.so
loadmodule auth.so
loadmodule auth_db.so
V at a seo auth_db params e descomente as 4 chamadas modparam entre as linhas 151 e
155. No se esquea de descomentar tambm a quebra de linha do terceiro auth_db params.
No bloco de linhas 321 a 331, descomente os dois IFs para que a validao seja feita nas
mensagens de REGISTER.
Se voc utiliza o vi
ou vim para editar
o arquivo, pode pular
para a linha 321 com o
comando :321<enter>.
Voc tambm pode
buscar por palavras
usando: /<palavras
procuradas><enter>.
/etc/init.d/opensips stop
/etc/init.d/opensips start
Aps habilitar a autenticao na aplicao, necessrio utilizar o banco de dados para
cadastrar usurios. Faa o cadastro utilizando os comandos a seguir.
Incluir e remover usurios e alterar senhas:
opensipsctl add <username> <senha>

opensipsctl rm <username>
opensipsctl passwd <username> <nova_senha>
Verificar os clientes cadastrados:
opensipsctl db show subscriber

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

em videoconferncia.
conceitos
Unicast x multicast; Portas e protocolos usados em H.323 e SIP; Uso de firewalls;
Infraestrutura bsica de redes

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

11 Ponto-a-ponto
22 Unicast
11 Multiponto
22 Unicast
22 Multicast
22 Broadcast
Em redes de computadores importante distinguir conexes ponto-a-ponto de conexes
que envolvem mltiplos pontos (multiponto).
126
Ponto-a-ponto
Uma conexo ponto-a-ponto executada atravs de procedimentos de chamada do
terminal de origem para o terminal de destino por meio de um nmero IP (no caso de
redes locais e Internet) ou de identificao do equipamento (como um nmero ISDN). Esta
conexo pode ser realizada sem o auxlio de um elemento gerenciador, baseada apenas na
conexo direta entre os computadores.
Em videoconferncias, este o modelo mais simples de comunicao, onde dois pontos
esto conectados e trocam dados multimdia diretamente. Em redes IP este tipo de comunicao feita utilizando unicast, que trataremos na sequncia. A exibio dos dados para
o usurio simples neste caso, pois cada usurio recebe dados de apenas outro usurio,
portanto vdeo, udio e outros elementos podem ser exibidos sem dificuldade.
Conexo ponto-a-ponto
Figura 5.2
Conexo
ponto-a-ponto.
Terminal (origem)
Terminal (destino)
Multiponto
Uma conexo multiponto viabiliza a comunicao simultnea entre vrios participantes
distribudos (3 ou mais), independente de sua localizao geogrfica.
Em videoconferncias, normalmente os participantes esto conectados a uma unidade central
que gerencia e processa o fluxo de mdias (udio, vdeo e dados) gerado na videoconferncia.
O elemento centralizador em videoconferncias chamado MCU, a unidade de controle
multiponto. Este componente cuida do processamento dos fluxos de udio e vdeo de forma a
integrar todos os terminais de videoconferncia. Alm do uso de um elemento centralizador,
h tambm a opo de fazer mltiplas conexes ponto-a-ponto entre todos os participantes.
A exibio dos dados multimdia em videoconferncias com trs ou mais participantes
apresenta desafios maiores do que em videoconferncias ponto-a-ponto. Normalmente so
utilizadas duas formas de exibio: participante ativo ou presena contnua.
Conexo Multiponto
Gatekeeper
Terminal
Terminal
Terminal
Terminal
Participante ativo
Todos os terminais da videoconferncia visualizam a imagem do participante ativo naquele
momento. Quando outro participante se tornar ativo, sua imagem ser comutada e, assim,
ele passar a ser visualizado em todos os terminais da videoconferncia. O participante
ativo normalmente aquele que est falando no momento. A deteco do participante ativo
costuma ser feita pela MCU com base no nvel do sinal de udio de cada participante. Essa
modalidade tambm conhecida como modo comutado por voz (Voice Switched Mode) e
apresenta, em geral, uma boa qualidade de vdeo e udio, alm de permitir uma visualizao
completa do participante ativo. indicada em casos sem muita alternncia entre os participantes ativos, como em palestras e apresentaes.
Figura 5.3
Conexo
multiponto.
MCU
127
Figura 5.4
Videoconferncia
exibindo apenas o
participante ativo.
Presena contnua
Neste modo apresentada a imagem e o udio de todos os participantes ao mesmo tempo.
Essa configurao recomendada para situaes em que exista uma participao ativa
simultnea de vrios usurios na videoconferncia, como ocorre em reunies, por exemplo.
Com este formato de exibio perde-se um pouco na qualidade (imagens so exibidas em
tamanhos menores), mas ganha-se em contedo, j que possvel ver todos os participantes e no apenas um.
Aplicaes que envolvem udio e vdeo, como sistemas de videoconferncia, geram um
grande volume de dados na rede. O trfego gerado em uma rede depende da natureza da aplicao (udio, vdeo, imagens etc.) e do tipo de conexo entre as mquinas onde cada aplicao
est sendo executada. O tipo de conexo avalia o estabelecimento da conexo sob a tica da
transferncia de pacotes entre os terminais da rede: ponto-a-ponto ou multiponto. No caso
de multiponto, ainda temos: conexo por difuso (broadcast), em que um pacote endereado a todos os demais terminais da rede; e conexo por difuso seletiva (multicast), em que
um pacote endereado a um grupo pr-definido de terminais na rede. Para cada uma das
formas de conexo, h um tipo de trfego gerado na rede: unicast, broadcast e multicast.
128
Click here to add another

person to the conference
Figura 5.5
Videoconferncia
com presena
contnua.
Trfego unicast
O trfego unicast aquele gerado quando uma mquina envia pacotes para um nico
destino (ou host) na rede. Nesse caso, uma mquina servidora que atende a quatro clientes
deve gerar quatro diferentes fluxos para cada terminal, como mostra a figura. Esta forma de
trfego permite fcil comunicao tanto do servidor para o cliente quanto do cliente para o
servidor. Um exemplo prtico de trfego unicast o acesso a uma pgina web atravs de um
servidor HTTP. A cada acesso, estabelecida uma conexo entre o servidor HTTP e o cliente
que est fazendo o pedido.
Um problema do unicast a gerao de trfego excessivo na rede quando um nmero
elevado de solicitaes enviado ao servidor, uma vez que para cada pedido ser gerado
um fluxo de retorno. Quando se trata da transmisso de vdeo, o problema agravado, j que os
fluxos gerados contm grande volume de dados que so replicados para os respectivos clientes,
o que compromete significativamente o desempenho da rede. Apesar deste problema, o unicast
a forma de transmisso mais utilizada atualmente, mesmo para udio e vdeo. Um exemplo de
uso desse modelo o YouTube, alm de outros sites de vdeo sob demanda.
Trfego Unicast
4
3
Roteador
1
Rede
1
Terminal 2
Servidor
Terminal 4
Terminal 3
Trfego broadcast
Com trfego broadcast uma mquina gera contedo para todas as demais na rede, de forma
que todas as mquinas recebero a mesma informao enviada. Um endereo especfico
(o endereo de broadcast) utilizado, identificando que o pacote que contm a mensagem
deve ser endereado para todas as mquinas da rede.
No exemplo da Figura 5.7, a distribuio de pacotes feita a partir de uma estao terrestre
(servidor) que envia os dados para o satlite que, por sua vez, reenvia simultaneamente para
todos os terminais (broadcast). Desta forma, um nico fluxo sai do servidor e enviado para
todos os clientes. Este mtodo muitas vezes utilizado para videoconferncias em zonas
rurais ou em zonas com baixa infraestrutura de redes.
Figura 5.6
Transmisso
via unicast.
Terminal 1
129
Terminal 1
2
Servidor
Terminal 4
Terminal 2
Terminal 3
Figura 5.7
Transmisso via
broadcast.
Trfego multicast
O trfego multicast difere do broadcast porque, em vez de enviar pacotes para todos os ns
da rede, envia pacotes apenas para um grupo pr-definido de mquinas. utilizada uma
forma de endereamento especial para o envio dos pacotes, designando o endereo de um
grupo de ns (conhecido como grupo multicast) e no de todos os ns da rede.
Sua principal vantagem a economia de largura de banda, permitindo que um mesmo fluxo
seja transmitido para vrios ns. Ao contrrio do unicast, no so necessrios mltiplos
fluxos para atender mltiplos clientes; apenas um fluxo suficiente. Para tanto, so necessrias tcnicas eficientes para o encaminhamento dos pacotes na rede, implementadas
atravs de protocolos especficos para o roteamento desses pacotes. Este roteamento
feito pelos equipamentos intermedirios da rede (switches e roteadores), que devem estar
configurados para conhecer multicast e seus protocolos.
O funcionamento do trfego multicast pode ser comparado, por exemplo, com o de uma
estao de rdio. Em uma estao de rdio, o sinal transmitido em uma determinada
frequncia, independentemente do receptor. Cada ouvinte, na sua casa e a partir do seu
aparelho de recepo, encarregado de sintonizar o canal desejado. No trfego multicast,
os ns que recebem o fluxo so configurados para a recepo desse trfego, podendo ser
adicionados ou excludos atravs do uso de um protocolo especfico.
Terminal 1
Rede
Roteador A
(Querier)
Servidor
Terminal 2
Terminal 4
Terminal 3
Multiponto: unicast x multicast

Como j comentado, uma transmisso multiponto pode ser alcanada com qualquer uma
das formas de transmisso comentadas: unicast, multicast ou broadcast. Broadcast uma
opo que raramente ser utilizada em redes de computadores devido sobrecarga que
130
Figura 5.8
Transmisso via
multicast.
inclui na rede, apesar de ser uma tima escolha para satlite. Em redes de computadores, a
escolha deve ser feita entre unicast ou multicast. A figura abaixo ilustra a principal diferena
entre essas formas de transmisso: a carga que cada um implica na rede.
UNICAST
MULTICAST
FON
FON
ROTA
ROTA
ROTB
ROTC
ROTB
REC3
REC1
REC2
REC3
ROTF
ROTD
REC4
ROTC
REC5
ROTF
ROTD
REC6
REC1
REC2
REC4
REC5
REC6
Como com unicast necessrio um fluxo para cada receptor, ele obviamente gera mais
trfego na rede do que o multicast, que uma forma de transmisso muito mais eficiente
nesses casos, especialmente para transmisso de dados multimdia.
Apesar disso, o unicast ainda a forma de transmisso mais utilizada. O principal motivo
disso a falta de suporte ao multicast nos roteadores. Por apresentar uma complexidade
adicional em relao ao unicast e por no ser to utilizado, muitas vezes o multicast
negligenciado pelos administradores de redes na configurao de roteadores e switches.
Com isso, o uso do multicast acaba sendo possvel apenas dentro de instituies onde est
devidamente configurado, como o caso da rede da RNP.
Alm disso, em alguns casos o multicast no a forma mais adequada de transmisso, como
em sistemas de vdeo sob demanda, por exemplo. Nestes sistemas, os usurios podem fazer
a requisio de incio de transmisso no momento em que desejarem, e desejam ver o vdeo
desde o seu incio. Da mesma forma, os usurios tm a possibilidade de navegar para partes
especficas do vdeo, sem que as mudanas feitas por um usurio interfiram nos outros
usurios. Este , portanto, um cenrio para uso de mltiplas conexes unicast.
Em transmisses multicast, todos os usurios recebero os mesmos dados, ou seja, recebero o vdeo no mesmo instante. Se um usurio solicitar o recebimento de um vdeo algum
tempo aps o incio da transmisso, ele no poder ver o vdeo desde seu incio. Este o
caso de transmisses ao vivo, streamings e tambm de videoconferncias.
No intuito de facilitar o estudo e a utilizao do espao de endereamento, a IANA definiu
uma diviso lgica que designa cinco classes para o endereamento da rede IP Internet
verso 4. Essa diviso chamada de Classfull Addressing (endereamento de classes) e define
as seguintes classes de endereos: A, B, C, D e E conforme ilustrado na figura.
Figura 5.9
Comparao de
uma transmisso
em mltiplos fluxos
unicast ou um
fluxo multicast.
131
Classe A
0 1
0
7 8
31
Classe B
1.0.0.1 126.255.255.254
0
2
10
Classe C
128.1.0.1 191.255.255.254
0
3
110
31
Classe D
192.0.1.1 223.255.254.254
0
4
1110
31
Classe E
224.0.0.0 239.255.255.255
0
5
11110
15 16
31
23 24
31
240.0.0.0 254.255.255.254
A Classe D reservada para multicast. Entretanto, na hora de determinar o grupo multicast,

importante notar que, caso ele seja utilizado numa rede privada (IP de intranet), a recomendao da RFC 2365 sugere a utilizao dos endereos 239.192.0.0 / 14, ou seja, na faixa
de 239.192.0.0 at 239.195.255.255, faixa denominada IPv4 organization local scope.
Multicast
Como os pacotes enviados pelo transmissor chegam at o receptor R1 utilizando multicast?
Rede local: protocolo IGMP (Internet Group Management Protocol)
11 Criao e sada de grupos (mensagens join e leave)
Backbone: protocolos de roteamento multicast
11 PIM (Protocol Independent Multicast)
11 DVMRP (Distance Vector Multicast Routing Protocol)
11 MOSPF (Multicast Open Shortest Path First)
11 MBGP (Multicast BGP)
E se o backbone da rede no tiver multicast?
11 Mbone (multicast backbone): criao de tneis multicast sobre unicast.
11 Permite multicast ao longo de uma rede que no suporta multicast.
11 Tnel liga dois roteadores que suportam IP multicast atravs de um enlace
ponto-a-ponto unicast.
Em uma transmisso multicast, um dos principais aspectos que devem ser considerados
a forma como os pacotes enviados chegaro aos receptores interessados (e somente a
eles). No exemplo abaixo, como os pacotes enviados pelo transmissor (no topo) chegam
132
at o receptor R1?
Figura 5.10
Classes de endereamento IP.
Transmissor
Rt1
Rt2
Rt3
Protocolo IGMP
Rt6
Rt5
R1
Os principais responsveis por esta tarefa so o protocolo IGMP (na rede local) e os protocolos de roteamento multicast (no backbone). Internet Group Management Protocol (IGMP) o
protocolo que gerencia grupos multicast na rede local, incluindo a criao e sada de grupos
(mensagens de join e leave). Ele definido na RFC1112.
Os protocolos de roteamento multicast definem como feita a comunicao entre os
roteadores para construo da rvore-multicast que define as rotas dos pacotes multicast.
Diversos protocolos podem ser utilizados, entre eles:
11 PIM (Protocol Independent Multicast).
11 DVMRP (Distance Vector Multicast Routing Protocol).
11 MOSPF (Multicast Open Shortest Path First).
11 MBGP (Multicast BGP).
Portanto, antes de cogitar o uso do multicast em longa distncia, verifique se todos os roteadores do caminho suportam multicast. O multicast muitas vezes est disponvel apenas em
redes corporativas, o que impossibilita seu uso para comunicao entre diferentes empresas,
por exemplo, assim como no suportado na Internet. Uma alternativa para aproveitar as vantagens do multicast e contornar os problemas que ele apresenta o uso de tneis multicast.
Os tneis so utilizados para conectar duas redes multicast atravs de um canal unicast. Um
exemplo prtico da aplicao dos tneis o MBone (multicast backbone), que um backbone
virtual criado nos anos 90 para permitir o uso de IP multicast sobre a internet.
O MBone considerado uma rede virtual sobre a internet, composta de vrias ilhas com
capacidade de multicast, interligadas por conexes unicast. Cada ilha formada por uma
LAN ou grupo de LANs, que possuem um roteador especial chamado mrouter (multicast
router), implementado em hardware ou software.
Nos mrouters, os pacotes multicast so encapsulados em pacotes unicast normais e enviados
com destino a outro mrouter. Todos os roteadores no caminho aceitaro o pacote como um
pacote unicast comum. Ao chegar ao mrouter-destino, o cabealho unicast removido, restando assim o pacote multicast original. Esta tcnica chamada de tunelamento.
Figura 5.11
Caminho
percorrido pelos
pacotes multicast.
Rt4
133
A imagem abaixo exemplifica a conexo entre duas ilhas utilizando mrouters.
Transmissor
de G1
G1
192.168.2.2
Hub/
switch
Mrouter1.
Tnel com
192.168.4.2
G1
192.168.4.2
Hub/
switch
Mrouter2.
Tnel com
192.168.2.2
G1
Figura 5.12
Utilizao de
tneis multicast.
G1
Portas e protocolos dos padres H.323 e SIP

Para administrao de videoconferncias, muito importante ter conhecimento das portas
e protocolos utilizados para monitoramento das atividades, configurao de equipamentos
e, principalmente, importantes para configurao em redes protegidas por firewalls.
A figura a seguir mostra um resumo das portas utilizadas em videoconferncias H.323:

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

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

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

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

Consegue controlar a comunicao entre dois ns no nvel do protocolo de aplicao. Atua
como um proxy, fazendo toda a troca de informaes entre os dois fins. Possui regras muito
mais especficas e poderosas para permitir ou bloquear trfego. Alm das regras bsicas
existentes nos outros tipos de firewall, permite, por exemplo, limitar o acesso a arquivos
apenas de tipos determinados, personalizar regras de acordo com o usurio autenticado,
permitir que comandos sejam executados apenas por determinados usurios, entre outros.
o tipo de firewall mais sofisticado, porm isto os torna complexos, requerendo configuraes detalhadas das aplicaes que utilizam o firewall.
Mesmo que o firewall ou o NAT sejam configurados corretamente para passar todo o trfego
de vdeo desejado, ainda pode haver interferncia na videoconferncia. Isto ocorre porque
o firewall / NAT so basicamente computadores, e possuem um limite quanto capacidade
de trfego que podem processar. Se no so rpidos o bastante para lidar com o trfego
apresentado a eles, pacotes podero ser descartados e uma variao do atraso poder ser
introduzida nos pacotes que passarem por ele. Portanto, certifique-se de que o dispositivo
firewall ou NAT rpido o bastante para fazer o seu trabalho.
As solues para os problemas de videoconferncia com firewalls esto relacionadas ao tipo
do firewall utilizado. Em todos os casos, a maneira mais simples liberar o acesso em todas
as portas requeridas para a videoconferncia. Esta obviamente uma soluo no muito
segura, pois libera qualquer tipo de trfego para as portas abertas.
A soluo mais elegante a utilizao de um firewall mais inteligente, que trabalhe como
um Application Gateway, interpretando o trfego de rede SIP e H.323. Essas solues podem
detectar as solicitaes de sinalizao de videoconferncia e executar a ao apropriada
para permitir ao trfego atravessar o roteador ou o firewall. Alguns exemplos de dispositivos
que funcionam desta maneira so:
11 Radvision ECS Firewall Solution: opera juntamente com o gatekeeper ECS quando esse
ltimo reside na DMZ entre a rede IP local e a externa.
11 Software de firewall da Check Point: produtos habilitados para H.323.
11 Tandberg Border Controller: elemento de borda que pode ser agregado topologia da rede.
Videoconferncia via NAT
136
11 Network Address Translation (NAT) permite que vrios computadores compartilhem
uma nica conexo de IP, ou pode mapear IP + porta privada para IP + porta
externa e, ento, suportar mltiplos endereos de IP privados.
NAT um servio que existe com intuito de permitir que vrios computadores compartilhem
uma nica conexo de IP. utilizado geralmente para conectar diversos hosts de uma rede
local com redes externas (por exemplo internet) utilizando um ou mais IPs externos. Um
roteador habilitado para NAT pode mapear um conjunto IP + porta privada (rede local)
para IP + porta externa e, ento, suportar mltiplos endereos de IP privados.
A figura seguinte exemplifica uma conexo entre dois hosts utilizando NAT. O host A est em
uma rede privada que controlada por um NAT (site NAT), enquanto o host B est acessvel
com um IP pblico na internet.
Domnio de
endereo privado
Internet pblica
Site NAT
10.0.0.1
Origem: 10.0.0.1/2000
Destino: 192.9.200.1/80
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
Host A
Host B
Origem: 192.9.200.1
Destino: 10.0.0.1/2000
Origem: 192.9.200.1/80
Destino: 139.130.1.1/3000
A imagem mostra pacotes trocados em duas direes: de A para B e de B para A.

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

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

Um dos problemas do uso de NATs o tratamento de conexes iniciadas por um host que
est fora da NAT. Utilizando como exemplo a imagem do incio deste captulo, onde temos
o host A em uma rede privada com NAT e o host B conectado diretamente rede pblica,
o problema acontece quando a conexo inicial parte do host B. O host B tentar contatar o
host A utilizando o IP 139.130.1.1. Atravs deste IP os pacotes chegaro at o roteador com a
NAT, porm ele no saber para qual host da rede interna estes pacotes devem ser redirecionados. Se a conexo parte do host A, entretanto, no h problemas, pois a NAT cria sua
tabela e consegue tratar todos os pacotes posteriores.
Domnio de
endereo privado
Internet pblica
Site NAT
Origem: 10.0.0.1/2000
Destino: 192.9.200.1/80
Origem: 139.130.1.1/3000
Destino: 192.9.200.1/80
192.9.200.1
NAT Binding
10.0.0.1/2000
139.130.1.1/3000
Figura 5.20
Pacotes atravs
de NAT.
Host A
Host B
Origem: 192.9.200.1
Destino: 10.0.0.1/2000
Origem: 192.9.200.1/80
Destino: 139.130.1.1/3000
E como ficaria a situao se os dois hosts esto atrs de uma NAT? Neste caso nenhum dos
dois pode iniciar a comunicao. As solues sero tratadas na sequncia deste captulo.
Outro problema no uso de NATs que elas estabelecem o mapeamento de portas examinando o cabealho dos pacotes que so transmitidos. Isso funciona bem para a maioria das
aplicaes, porm apresenta problemas com protocolos que utilizam portas dinmicas e/ou
incluem a informao da porta utilizada na rea de dados do pacote (payload). E este justamente o caso dos padres de videoconferncia H.323 e SIP, onde as conexes RTP utilizam
portas dinmicas, que so definidas pelos protocolos durante o estabelecimento da sesso,
10.0.0.1
onde so trocadas mensagens que contm o valor da porta na rea de dados da mensagem.
139
O exemplo abaixo mostra uma mensagem INVITE do SIP, que contm dados tanto das portas
utilizadas quanto dos IPs na rea de dados da mensagem. Em uma mensagem como essa,
a NAT conseguiria apenas modificar IP e porta do cabealho, mas todos os valores de IP e
porta exibidos no exemplo permaneceriam iguais.
INVITE sip:206@192.168.0.30:10455 SIP/2.0

Via: SIP/2.0/UDP 192.168.0.24:5060;branch=z9hg4bkz9hg4bkf8e2c7ca
Via: SIP/2.0/UDP 192.168.0.24:5060
From: <sip215@192.168.0.154;tag=414d5646-ad-407469a8
To: <sip:206@192.168.0.154>
Contact: sip:215@192.168.0.24
Solues
Alternativas para a soluo do problema:
11 Protocolo H.460
22 Criado para firewall / NAT traversal com o padro H.323.
22 Utiliza um servidor que age como um proxy.
11 STUN (Session Traversal Utilities for NAT)
22 Servidor externo auxilia descoberta de IP pblico.
22 No pode ser utilizado com NAT simtrica.
11 TURN (Traversal Using Relays around NAT)
22 Utiliza um servidor que age como um proxy.
11 ICE (Interactive Connectivity Establishment)
22 STUN + TURN.
A seguir esto descritas as principais formas para permitir que videoconferncias atravessem firewalls e NATs: H.460, STUN, TURN e ICE.
Protocolo H.460
O H.460 uma srie de extenses ao padro H.323 estabelecida pela ITU para possibilitar
que videoconferncias H.323 atravessem firewalls e NATs. A implementao do H.460
inclui um servidor localizado na rede pblica (fora da NAT/firewall) que age como um proxy
para todo o trfego da videoconferncia. Os terminais se registram neste servidor e abrem
140
canais de comunicao direta com o servidor. Ou seja, os terminais no se comunicam diretamente, mas atravs do servidor H.460.
A grande vantagem desta abordagem que no necessrio criar regras especiais nos firewalls
e tambm no necessrio que o firewall entenda o protocolo H.323. Basta configurar o firewall
para que ele permita a comunicao com o servidor H.460 (um servidor confivel).
Este mtodo simples de ser implementado e utilizado, o que o torna bastante prtico para
ambientes com poucos terminais e videoconferncias rpidas. Ele se torna uma soluo problemtica especialmente quando existe um grande nmero de terminais fazendo ligaes ao
mesmo tempo (a largura de banda do servidor pode no ser suficiente).
No site No Jitter,
assista ao Video
Tunnels Through the
Firewall.
STUN
Session Traversal Utilities for NAT (STUN) um mecanismo definido na RFC 5389 que permite
que entidades atrs de NATs descubram seus endereos pblicos e com isso viabiliza videoconferncias entre elas. Seu funcionamento baseado em um modelo cliente-servidor, onde
o cliente (um terminal de videoconferncia) troca mensagens com um servidor (localizado na
rede pblica) para descobrir informaes como:
11 Seu IP pblico;
11 O tipo de NAT na qual o cliente se encontra;
11 O mapeamento que o NAT est utilizando para este cliente.
Alm disso, o protocolo tambm possibilita outras facilidades, como manter o mapeamento
do NAT sempre ativo, para que no ocorram falhas na comunicao.
O STUN foi inicialmente definido na RFC 3489, e costuma ser chamado de classic STUN.
Esta verso do protocolo prov todas as funcionalidades mencionadas, e pode ser utilizado
de forma independente de outros protocolos. Porm, foi descoberto que esta verso do
protocolo no adequada em muitos casos, pois h casos em que a soluo funciona e h
casos em que no funciona. E nos casos em que no funciona no h nada que possa ser
feito. Em funo desse e de outros problemas, o STUN foi novamente especificado na RFC
5389, onde passou a ser apenas uma ferramenta utilizada como parte de uma soluo de
NAT traversal completa (como o ICE, que ser descrito na sequncia).
O principal problema do STUN que no funciona com NAT simtrica, que um tipo de NAT
muito utilizado. O problema que a associao feita no NAT entre um terminal e o servidor
STUN no pode ser utilizada para conexo entre este terminal e outro, ou seja, no pode
ser utilizada para a videoconferncia. Isso ocorre porque o NAT simtrico cria diferentes
associaes para cada conexo, mesmo para duas conexes feitas com um s terminal
(que est atrs da NAT).
Por exemplo, as solues que utilizam um servidor externo apenas para tarefas como descoberta do IP pblico (ex. STUN): dessa forma, o terminal 1 descobre o IP externo e interno
do terminal 2 e os utiliza adequadamente.
NAT /
Firewall
NAT /
Firewall
Rede
interna
Rede
interna
Dados multimdia
Figura 5.21
Soluo com
servidor externo.
Servidor da
rede pblica
141
TURN
Traversal Using Relays around NAT (TURN) uma extenso do protocolo STUN, incluindo as
mensagens TURN, que so em grande parte mensagens no formato STUN. Este protocolo
definido na RFC 5766.
Assim como no STUN, o TURN utiliza um servidor em uma rea pblica para permitir que os
clientes faam conexes atravs de NATs. O TURN permite que um host atrs de um NAT
(o cliente) solicite que outro host (o servidor) funcione como um servidor de relay, de
redirecionamento de mensagens. O cliente pode ento utilizar o servidor para redirecionar
pacotes para outros clientes e controlar como este redirecionamento feito. Com o uso
deste servidor, mensagens podem ser trocadas bidirecionalmente entre dois clientes.
A desvantagem do uso do TURN que o uso de um servidor de redirecionamento pode
gerar problemas de atraso, jitter e outros problemas de rede e tambm necessita que o
servidor tenha uma grande largura de banda disponvel.
ICE
Interactive Connectivity Establishment (ICE) especificado na RFC 5245 e define uma tcnica
de NAT traversal para transmisses UDP estabelecidas em um modelo de oferta e resposta.
O modelo oferta e resposta feito basicamente com o uso do protocolo SDP, onde so
inseridos diversos IPs e portas, que so encaminhados para um cliente testar se possvel
estabelecer uma conexo com eles. Esses IPs so definidos com uso do STUN. Alm disso, o
ICE tambm utiliza o TURN quando necessrio.
Simplificadamente, o ICE uma soluo completa de NAT traversal que utiliza o STUN sempre
que possvel e o TURN quando necessrio (quando no possvel estabelecer uma conexo
direta entre os dois hosts e ento necessrio um servidor de relay). O ICE ainda no est
maduro, e no adotado largamente na indstria, criando um problema no seu uso.
Suporte a NAT nos softwares de videoconferncia

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

11 Latncia
11 Jitter
11 Skew
11 Largura da banda
11 Atraso
Para entender a qualidade de uma videoconferncia, necessrio analisar alguns fatores
que influenciam na sincronizao e apresentao das mdias. As principais medidas so:
latncia, jitter, skew e largura de banda. Alm destas medidas, importante ter conhecimento dos diversos fatores que causam atraso na transmisso.
Latncia
A latncia o tempo entre o incio de um evento e o momento que ele se torna perceptvel
11 Quais fatores influenciam na latncia?

11 Qual o grande incmodo da latncia?
11 Quais so os valores de latncia aceitveis em videoconferncias?
Latncias muito grandes podem dificultar a conversao atravs da rede, comprometendo o
dilogo e a interatividade necessria para aplicaes como sistemas de videoconferncia.
Supondo uma situao em que duas pessoas esto conversando por meio de um sistema
de videoconferncia do tipo desktop, com grande atraso na transmisso dos pacotes.
O interlocutor-origem envia uma pergunta para o interlocutor-destino. A grande latncia
da rede faz com que o interlocutor-destino custe a receber os pacotes que contm esta
mensagem. Enquanto isso, o interlocutor A, por no saber se o outro participante ouviu,
continua enviando mensagens. Aps alguns milissegundos, vem a resposta do interlocutor-destino sobre a primeira pergunta efetuada, entrelaando o dilogo e dificultando a
fluncia da conversa.
no destino.
143
Os principais fatores responsveis por aumentar a latncia nas redes de computadores

so o atraso de transmisso, de codificao e de empacotamento. Estes e outros atrasos
sero descritos mais adiante neste captulo. Em aplicaes convencionais como correio
eletrnico, por exemplo a latncia na transmisso passa despercebida pelos usurios do
servio. J em aplicaes multimdia como sistemas de videoconferncia a latncia pode
ser percebida e at mesmo comprometer todo o servio. Nesse caso, os pacotes devem ser
entregues num perodo de tempo especfico, para dar prosseguimento apresentao da
mdia. Sendo assim, dizemos que os requisitos de qualidade de servio em aplicaes multimdia so diferentes daqueles em aplicaes tradicionais.
Apesar de no ser uma tcnica muito precisa, o atraso pode ser medido filmando um relgio
em uma videoconferncia e ver quanto tempo ele demora a chegar ao destino. A imagem
seguinte exemplifica como isso feito.
Figura 5.23
Medio de atraso
em uma transmisso: 410 ms.
Nesta mquina est sendo filmado um relgio, em imagem transmitida para um sistema
central (similar a um MCU), e este sistema est enviando a imagem de volta para a mquina,
que a exibe na janela. Comparando os relgios temos:
11 Relgio no transmissor: 43:44,64.
11 Relgio no receptor: 43:44,23.00000.
Com isso, percebemos que a diferena entre os relgios de 410 ms, ou seja, a latncia desta
transmisso 410 ms no momento em que foi tirada a foto. E quais seriam os valores de
latncia aceitveis em videoconferncias? Pesquisas mostram que atrasos abaixo de 100 ms
so imperceptveis para o ser humano. Entre 100 ms e 200 ms so valores pouco percept-
veis e tolerveis, e acima disso o atraso comea a perturbar a comunicao.
144
Jitter
Jitter a variao da latncia. No exemplo uma rajada de pacotes: nem todos chegam ao
mesmo tempo (com mesma latncia).
# de pacotes
recebidos
Latncia
Jitter
Figura 5.24
Grfico de visualizao do jitter.
t
Utilizar somente a latncia no suficiente para definir a qualidade de transmisso, pois as
redes no conseguem garantir uma entrega constante de pacotes ao destino (com mesma
latncia). Dessa forma, os pacotes so entregues de forma varivel, isto , variando o tempo
gasto de um pacote para outro. Essa flutuao na latncia conhecida como jitter e pode
acarretar na descontinuidade na exibio da mdia. A principal estratgia para compensar o
jitter utilizar buffers para armazenar os pacotes que chegam e, ento, minimizar esse
efeito. O buffer cujo tamanho vai depender do jitter gera mais atraso na conversao,
porm inibe a descontinuidade na exibio da mdia, ou seja, evita que o receptor fique
algum tempo sem dados para exibir. Esse buffer vai servir como uma reserva para manter a
taxa de entrega constante ao interlocutor. Da a importncia de latncia e jitter baixos em
determinadas aplicaes sensveis a esses fatores, como a videoconferncia.
Alguns exemplos prticos produzidos pelo jitter elevado so aquelas quebras durante a produo do udio no cliente: podem ocorrer estouros (pops) ou sons rpidos demais (clicks)
durante a reproduo do udio.
Skew
Skew a diferena do tempo de chegada entre diferentes mdias que deveriam estar
11 Qual o skew aceitvel em uma videoconferncia?

11 Quando o skew muito grande, necessrio algum mecanismo para sincronizao
das mdias.
Mecanismo utilizado:
11 Transmissor inclui o timestamp nos dados de udio e vdeo.
11 O timestamp indica o momento de tempo no qual os dados foram capturados.
11 O receptor utiliza timestamps para exibir os dados no momento certo.
sincronizadas. Exemplo: udio e vdeo.
145
# de pacotes
recebidos
skew
vdeo
udio
t
Qual seria o skew aceitvel em uma videoconferncia?
11 < 20 ms: imperceptvel;
11 ~ 50 ms: percebe-se que h algo errado, mas no possvel saber qual mdia est adiantada e qual est atrasada;
11 > 50 ms: causa distrao da videoconferncia;
11 ~ 1 segundo: usurio mantm seu foco apenas no udio, deixando de prestar ateno
no vdeo.
Como vimos, apenas valores muito pequenos de skew podem ser ignorados (menos que 50 ms).
Para valores maiores, necessrio que haja algum mecanismo que sincronize as mdias
antes de sua exibio. O mecanismo utilizado baseia-se em timestamps, que so marcadores do instante no qual os dados foram capturados. O protocolo RTP (Real Time Transfer
Protocol) e RTCP (RTP Control Protocol), definidos na RFC 3550, possuem campos especficos
nos pacotes para incluso dessas informaes. Como funciona:
11 Transmissor inclui o timestamp nos dados de udio e vdeo: todos os pacotes levam essa
informao de tempo.
11 Timestamp indica o momento no qual os dados foram capturados no transmissor: um
buffer de udio e um de vdeo que foram capturados no mesmo instante possuem o
mesmo timestamp.
11 O receptor utiliza os timestamps para exibir os dados no momento certo: se o udio est
adiantado, por exemplo, ele deve esperar o vdeo para que possa ser exibido.
A figura a seguir mostra um exemplo de adaptao na rede, provavelmente atravs de mudana
146
de codec, pois foi constatado que a taxa de perdas estava muito grande para o receptor.
Figura 5.25
Grfico de visualizao do skew.
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
Perdas=10%
SEQ=6
SEQ=9
SEQ=7
Figura 5.26
RTP/RTCP e adaptao qualidade
da transmisso.
SEQ=8
SEQ=10
Perdas=10%
SEQ=9
RTCP monitora o QoS da sesso, e no tem nada a ver com o QoS da rede.
SEQ=1, tstamp=x
SEQ=10
Para
se adaptar ao jitter, basta o receptor utilizar a informao de timestamp no pacote,
como
ilustra
a figura a
seguir. Veja que os pacotes esto chegando distanciados aleatoriaSEQ=2,
tstamp=x+eq
20ms
mente, porm, o receptor sabe exatamente o momento de enviar os mesmos sada. Para
SEQ=SEQ=3,
tstamp=x+eq
40ms
isso,
vai necessitar
do buffer
de jitter.
SEQ=1, tstamp=x
A figura a seguir mostra o cabealho do RTP. O campo PT (Payload Type) indica o tipo de
codec utilizado. O campo Nmero de sequncia utilizado para o RTCP verificar a taxa
de perdas, pois os pacotes so numerados. O campo timestamp marca o momento da
captura do primeiro byte do pacote.
Figura 5.27
Uso do timestamp
no RTP e tempo
de chegada dos
pacotes para
adaptao ao jitter.
147
1
0
V=2
6
CC
2
1
PT
3
1
Nmero de seqncia
T imestamp
Synchronization Source (SSRC) identier

Contributing Source ( CSRC ) identiers
Largura de banda
A largura de banda um fator limitante para videoconferncias, especialmente devido
ao vdeo, que uma mdia que consome bastante banda. A banda pode ser um limitador
da qualidade do vdeo. Por exemplo, tendo apenas 512 kbps disponveis, o vdeo deve
ser comprimido o suficiente para que possa ser transmitido, ou pode-se definir a banda
necessria conforme a qualidade desejada.
11 Por exemplo: deseja-se uma transmisso com resoluo 720x480, 30 quadros por
segundo, com alta qualidade: necessria banda de 2 Mbps.
As necessidades variam muito:
11 100 kbps em videoconferncias simples via webcam.
11 1,5 Gbps em transmisses de vdeo HD no comprimido.
Aplicaes de videoconferncia so muito parecidas com aplicaes de voz em termos
de latncia e jitter entretanto, podem utilizar alta largura de banda. Para determinar
a largura de banda ideal para um sistema de videoconferncia, necessrio conhecer a
demanda requerida pelo sistema em funo da capacidade que a infraestrutura de rede
pode prover. Os requisitos de largura de banda de sistemas multimdia podem variar bastante, indo de 100 kbps a 1,5 Gbps (transmisso de vdeo HD no comprimido), por exemplo.
A largura de banda um fator limitante para a videoconferncia, sendo necessrio ajustar a
demanda da aplicao disponibilidade existente. Por exemplo: pode-se optar por vdeo de
qualidade mais baixa em favor de manter os requisitos de transmisso multimdia ou, ento,
considerar modificaes na infraestrutura da rede em prol de atingir a demanda requerida
por um vdeo de maior qualidade.
Valores de referncia
Resumindo o que foi visto, temos como valores de referncia para cada uma das medidas
descritas:
Latncia
11 Idealmente abaixo de 200 ms.

Jitter
11 O mais baixo possvel;
11 Aplicao deve utilizar buffer de dados para se adaptar ao jitter e evitar problemas na
exibio dos dados;
11 Quando maior o jitter, maior o buffer, ou seja, maior a latncia na exibio.
Skew
11 Abaixo de 50 ms;
11 Para valores maiores necessita de sistema de sincronismo no receptor.
148
Figura 5.28
Cabealho do RTP.
Largura de banda
11 Mnimo de 256 kbit/s para obter uma qualidade aceitvel em baixas resolues;
11 Boa qualidade em SD: 2 Mbit/s;
11 Qualidade mdia em HD: 4 Mbit/s.
Atraso na transmisso
O atraso total em uma transmisso o tempo entre a captura dos dados no transmissor e
sua exibio no receptor. Esse tempo envolve uma srie de fatores como, por exemplo: atraso
no meio fsico, atraso de processamento nos dispositivos intermedirios (como roteadores e
switches), ou atraso devido ao tempo de espera nas filas de transmisso desses dispositivos.
Na sequncia sero descritos os diversos fatores que podem causar atrasos, que so:
11 Time-sharing de processos na mquina;
11 Captura de udio e vdeo;
11 Codificao de udio e vdeo;
11 Empacotamento;
11 Transmisso fsica;
11 Equipamentos intermedirios (store and forward);
11 Insero e desinsero;
11 Fila dos roteadores;
11 Adaptao ao jitter, skew e pacotes fora de ordem.
Atraso de Time-sharing de processos na mquina

Em uma mquina com processamento fraco ou com muita demanda de processamento
dos processos em paralelo podem existir falhas na:

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

udio
11 Placas normalmente capturam diversas amostras a cada intervalo de tempo.

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

No empacotamento de udio, alguns codecs necessitam de um tempo fixo para pro-
cessar a codificao.
Para codificao em tempo real, necessrio que o codificador processe os dados mais
rapidamente do que eles esto sendo capturados. Por exemplo:
11 Vdeo com 30 quadros por segundo;
150
11 udio com 300 bytes de amostras a cada 25 ms.

A codificao de udio no requer tanto processamento quanto a codificao de vdeo, e
por isso a codificao de vdeo sempre tomada como parmetro de desempenho. Quando
se deseja codificao em tempo real, o desempenho do processador ser o limitador dos
parmetros da codificao, ou seja, se o processador no est conseguindo processar em
tempo real, normalmente so modificados parmetros da codificao (como resoluo, taxa
de quadros por segundo, entre outros) para reduzir a carga de processamento. Portanto,
quando a codificao em tempo real, o nico atraso que a codificao adiciona o atraso
inicial necessrio para a codificao dos primeiros blocos de dados.
O atraso de empacotamento na codificao este tempo necessrio em alguns codificadores para obter o primeiro conjunto de dados e codific-los. Na codificao de udio,
alguns codificadores necessitam de um tempo fixo para processar os dados e tambm utilizam um look-ahead, ou seja, verificam amostras no futuro para codificar os dados atuais.
Seguem dois exemplos.
G.723
11 Tempos de 30 ms mais look-ahead de 7,5 ms;
11 Atraso de empacotamento: 37,5 ms.
G.729
11 Tempos de 10 ms mais look-ahead de 5 ms;
11 Atraso de empacotamento: 15 ms.
Ou seja, o G.723, por exemplo, codifica grupos de amostras de 30 ms e utiliza 7,5 ms de
amostras no futuro para codificar cada grupo, totalizando um atraso de 37,5 ms.
Para o codec de udio G.723 obter os 37,5ms de udio para codificao, ele deve esperar
5 interrupes da placa de udio.

Empacotamento de vdeo:
11 Alguns algoritmos de predio de movimento utilizam quadros no futuro para
melhorar a codificao.
11 Para isso necessrio criar um buffer de quadros, que gera atraso.
Para codificao em tempo real, o codificador deve ser capaz de processar mais rpido
do que os dados so capturados.
8ms
8ms
INT
8ms
INT
8ms
INT
8ms
INT
INT
t1=40ms
30ms + 7,5ms
300 bytes
Figura 5.29
Atraso devido
captura (t1)
e codificao (t2).
t2
ES udio (24B)
t
Na codificao de vdeo, h algoritmos tais como os utilizados para predio de movimento

que tambm requerem quadros ainda no disponveis para codificar os dados atuais. Com
isso torna-se necessrio criar um buffer de quadros, que resulta em um atraso na codificao. Alm disso, dependendo da complexidade do codec, das opes escolhidas e do
desempenho da mquina, possvel que o codificador tenha algum atraso no incio da sua
execuo, o que tambm pode gerar certo atraso.
Encoder
151
Atraso no empacotamento
Tempo gasto para os dados serem empacotados antes de serem transmitidos. Atraso
para os codecs:
11 G.729 = 8 kbps.
11 G.711 = 64 kbps.
Pacotes de 1000 bytes (8000 bits):
11 G.729: 8000 bits por segundo = 1 pacote por segundo = 1s por pacote.
11 G.711: 64000 bits por segundo = 8 pacotes por segundo = 125ms por pacote.
O atraso de empacotamento refere-se ao tempo gasto para os dados serem empacotados
para serem transmitidos na rede. Por exemplo: em uma transmisso de voz a 64 kbps o
preenchimento de um pacote de dados com 1000 bytes (j includos os cabealhos UDP, RTP,
etc.) toma 125 ms. O clculo feito da seguinte maneira:
11 1000 bytes correspondem a 8000 bits ou 8 kbits;
11 Com a transmisso de 64 kbit/s, podem ser enviados 8 destes pacotes por segundo (64/8);
11 8 pacotes por segundo quer dizer que enviado um a cada 125 ms (1/8).
Analisando sob o ponto de vista dos codecs de udio:
11 G.729 = 8 kbps;
11 G.711 = 64 kbps.
Temos:
11 Pacotes de 1000 bytes:
22 G.729: atraso de 1s;
22 G.711: atraso de 125 ms.
11 Pacotes de 100 bytes:
22 G.729: atraso de 100ms;
22 G.711: atraso de 12,5 ms.
Atraso no meio fsico

Atraso gerado enquanto os pacotes trafegam no meio fsico, que varia conforme
o mtodo de transmisso utilizado e a distncia.
Velocidade de transmisso:
11 Par tranado e fibra tica:
152
22 2/3 da velocidade da luz (300.000 km/s) = 200.000 km/s

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

11 Gerado devido aos roteadores e switches por onde os pacotes trafegam.
11 Switches: podem ser cut-through, store and forward ou adaptive.

11 Roteadores: store and forward
22 Atraso gerado devido ao custo de insero e desinsero.
22 Tempo de insero ou desinsero = tamanho do quadro/taxa de transmisso.
Este tipo de atraso gerado devido aos equipamentos intermedirios pelos quais os dados
trafegam nas redes, mais especificamente os switches e roteadores. O atraso varia conforme o modo de funcionamento desses equipamentos. Switches operam em um dos trs
modos explicados abaixo, enquanto os roteadores utilizam o modo store and forward.
11 Cut-through: switch comea a encaminhar os pacotes antes mesmo de receb-los por
completo, o que diminui a latncia mas diminui a confiabilidade.
11 Store and forward: os pacotes so recebidos e armazenados pelo switch, ele verifica sua
integridade e s depois o encaminha.
11 Adaptive: opera normalmente como cut-through, mas se ocorrem muitas falhas em
determinada porta, ele passa a utilizar o mtodo store and forward para aquela porta.
entre os mtodos citados. Nestes equipamentos, os atrasos so chamados de atrasos de

insero (durante o store) ou atrasos de desinsero ( forward). Esses atrasos variam conforme o tamanho dos pacotes e a velocidade com a qual os equipamentos trabalham,
e podem ser calculados da seguinte maneira:
11 Atraso de insero ou desinsero = tamanho do quadro/taxa de transmisso.
Com isso, temos como exemplo o custo de insero de um pacote de 125 bytes para as
seguintes velocidades:
11 13 kbit/s:
(125 * 8) = pacotes de 1.000 bits
1.000 bits 13.000 bits/s 77 ms
11 2 Mbit/s:
(125 * 8) 2.000.000 = 0,5 ms
11 100 Mbit/s:
O mtodo store and forward ser o mtodo analisado, pois o que inclui o maior atraso
(125 * 8) 100.000.000 = 10 us
153
Atraso nas filas dos roteadores

Acontece em momentos de congestionamento nos roteadores. Cada pacote gera um
atraso de desinsero. Exemplo:

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

Como so resolvidos os problemas de jitter, skew e pacotes fora de ordem?
11 necessrio bufferizar os dados no receptor.

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

11 Time-sharing de processos na mquina;
154
11 Captura de udio e vdeo;

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

Objetivo de garantir que a videoconferncia vai atingir a qualidade pretendida, tendo a
banda necessria, minimizando atraso, jitter e perda de pacotes. Em videoconferncias,

a qualidade de servio pode ser buscada com ferramentas do H.323 e, principalmente,
com tcnicas de QoS nas redes.
O conceito de Quality of Service (QoS) significa garantir a qualidade do servio em foco,
no caso videoconferncias. Em videoconferncias H.323, a qualidade de servio pode ser
buscada com ferramentas do H.323 e/ou com a utilizao de tcnicas de QoS nas redes.
Ambas alternativas sero vistas em duas etapas:
11 QoS no H.323.
11 QoS na rede.
QoS no H.323
O gatekeeper H.323 prov algumas funcionalidades para melhoria da qualidade do
servio. O QoS um bloco adicional interligado ao gatekeeper e transmisso H.323.

Gatekeeper
11 Controle simples baseado em um pool de chamadas.
11 Controla o somatrio da demanda de banda de todas as chamadas.
11 Limita a largura de banda utilizada negando novas chamadas.
Problemas:
11 Gatekeepers conhecem apenas o trfego H.323 viso isolada.
11 Ignora a situao atual dos dispositivos de rede terminal pode solicitar 384 kbit/s
e utilizar 500 kbit/s.
11 Utiliza a banda solicitada pelos terminais, no a que realmente foi utilizada.
Uma forma de buscar a qualidade de servio em videoconferncias H.323 aliar as funcionalidades convencionais do sistema de videoconferncia s funcionalidades de QoS.
O gatekeeper H.323 o componente do sistema de videoconferncia que pode fornecer
O controle de admisso a principal funo do gatekeeper para buscar QoS. Esse controle
de admisso executado pelo gatekeeper fundamentado numa espcie de pool canal
coletivo das larguras de banda disponveis. Quando um terminal vai iniciar uma ligao, ele
solicita ao gatekeeper determinada largura de banda. O gatekeeper, ento, libera ou bloqueia esta nova chamada conforme as outras chamadas que esto em andamento. Supondo
que o gatekeeper est configurado para utilizar 2 Mbits/s e h duas videoconferncias de
800 kbit/s em andamento, apenas chamadas de menos de 400 kbit/s sero liberadas.
Entretanto, as decises feitas pelo gatekeeper a respeito da disponibilidade da largura de
banda podem no coincidir com a disponibilidade real da largura de banda na rede. possvel
que o gatekeeper esteja configurado para utilizar 2Mbit/s (por ser a capacidade mxima da
rede), mas a banda atualmente disponvel na rede de apenas 1 Mbit/s, devido a outros trfegos no H.323. Ou seja, o gatekeeper tem uma viso isolada da rede, considerando apenas
o trfego H.323.
alguma garantia de QoS.
155
Alm disso, os gatekeepers no podem controlar a quantidade de largura de banda realmente

consumida pelos terminais. Por exemplo: um terminal pode fazer um pedido para uma chamada
de 384 kbit/s e, ento, emitir 400 ou mais kbit/s de dados. Se esses dados no trafegarem via
gatekeeper, que a soluo mais frequente, o gatekeeper no ter conhecimento da quantidade
de dados realmente transmitida e poder haver uma sobrecarga de dados na rede.
Gatekeeper
Terminal H.323
Solicita 389 Kbps
Autoriza 389 Kbps
Sem
sca
liza
ps
i
nv
40
Kb
Sobrecarga
Figura 5.30
Gatekeeper sem
fiscalizar a banda
utilizada pelos
terminais.
QoS na rede
H duas arquiteturas de rede para QoS, que especificam como feita a classificao dos
dados e o seu gerenciamento para implementao de QoS. So elas:
11 DiffServ (Differentiated Services)
22 Classificao por pacotes.
11 IntServ (Integrated Services)
22 Classificao por fluxos.
11 DiffServ (Differentiated Services)
11 Classificao feita por pacotes.
11 Utiliza marcao DSCP (Differentiated Services Code Point).
22 6 bits no cabealho dos pacotes IP que permitem atribuir classes aos pacotes
11 Roteadores tratam os pacotes conforme seu tipo, atribuindo prioridade aos pacotes
conforme sua classe.
11 Classes so definidas pelas aplicaes ou pelos operadores da rede.
156
IntServ (Integrated Services):

11 Classificao feita por fluxos.
11 Aplicaes que precisam QoS devem fazer reserva de recursos na rede.
Para reservas utiliza os protocolos:
11 Flow Specs: descreve os objetivos da reserva.
11 RSVP: sinaliza as reservas ao longo das redes.
O controle do trfego de dados nos equipamentos intermedirios da rede (roteadores, principalmente) a forma mais garantida de se conseguir QoS em redes best-effort. Apesar de o
gatekeeper possuir certo controle para QoS, apenas com o tratamento de QoS diretamente
nos equipamentos das redes que possvel evitar problemas mais graves em transmisses
multimdia como pacotes descartados, jitter, atrasos em filas, entre outros.
A imagem abaixo mostra um esquema genrico do funcionamento de QoS na rede:
Classicao
Filas e escalonamento
Controle de admisso
e polticas de controle
Classificao
Separao dos pacotes em classes distintas, seja esta separao feita para os pacotes individualmente ou para fluxos de uma aplicao. Assim, cada classe pode ter um tratamento individualizado. Como ser visto, a classificao no DiffServ feita por pacotes e no IntServ por fluxos.
Filas e escalonamento
De acordo com a classe dos pacotes, eles normalmente so agrupados em diferentes filas
e tratados de forma diferenciada. Nas filas de prioridade, os pacotes de alta prioridade so
entregues primeiro; quando no existem pacotes de alta prioridade na fila, so entregues os
pacotes de mdia prioridade, e o mesmo vale para os pacotes de baixa prioridade.
Controle de admisso e polticas de controle

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

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

So trs as etapas desta atividade prtica. Todas devem ser executadas em dupla, onde um
membro da dupla executa o servidor e outro o cliente.
1. Criao de fluxo UDP unicast
Crie trs fluxos entre sua mquina e o servidor na mquina do colega. Um deles de
100kbit/s, depois outro de 1Mbit/s e depois outro de 10Mbit/s. A durao de cada fluxo deve
de medio de banda da rede, como o DU Meter.
2. Criao de fluxo UDP multicast
Crie um fluxo UDP multicast entre sua mquina e o servidor do colega. Utilize a velocidade
de 1Mbit/s. Confira atravs de um sniffer de redes, como o Wireshark, que o IP destino
realmente o grupo multicast configurado no software iperf/jperf.
ser pelo menos de 10 segundos. Verifique o grfico de uso da banda atravs de um software
161
Modifique o grupo multicast utilizado para evitar conflitos. Coloque um IP no

formato 239.1.1.x, com x sendo um valor aleatrio entre 1 e 254. Voc pode utilizar
o nmero da sua mquina, por exemplo.
3. Criao de fluxo TCP unicast
Crie um fluxo TCP unicast entre sua mquina e a do servidor do colega. Qual a banda obtida
na conexo? Explique.
No modo TCP no deve ser especificada a banda da transmisso (-b), pois o objetivo utilizar a maior banda possvel na rede.
Atividade 2 Identificar e analisar pacotes RTP e RTCP

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

Para o fluxo de udio da Atividade 2 (item 3), calcule:
1. Tempo mdio de insero (considere o tamanho do pacote visto na Atividade 2).
2. Atraso no meio fsico (considere 30m a distncia UTP entre sua mquina e o switch).
Use filtro parecido com rtp and ip.src == 192.168.0.100 and rtp.p_type==127,
mudando o IP para o IP correto do transmissor.
163
164
6
Permitir que o aluno compreenda e saiba analisar as caractersticas de sistemas
de videoconferncia multiponto e suas diferenas fundamentais para tomar uma
deciso bem fundamentada na hora da escolha.
conceitos
Videoconferncia multiponto, funcionamento e solues de Multipoint Control Units

(MCUs), multiponto com vdeo escalvel.
Videoconferncia multiponto
H basicamente trs modelos possveis:
11 Modelo centralizado.
11 Modelo descentralizado.
11 Modelo hbrido.
Como funciona a transmisso em um cenrio de videoconferncia com mais dois participantes?
Uma conferncia ponto-a-ponto envolve apenas dois pontos da rede. Em uma rede H.323,
pode ocorrer entre dois terminais ou entre um terminal e um gateway. J uma conferncia
que envolve mais que dois pontos chamada de conferncia multiponto.
Em videoconferncias multiponto, o modelo de transmisso adotado definido, principalmente, em funo do nmero de transmissores. Quando h apenas um transmissor,
o modelo mais apropriado diferente do modelo adequado para videoconferncias com
mltiplos transmissores.
Em uma aula remota, por exemplo, onde um professor est transmitindo seu udio e vdeo
para mltiplos alunos que no transmitem seus dados, temos o modelo com apenas um
transmissor. Neste caso, possvel utilizar multicast para transmisso dos dados do professor
de forma otimizada: ele s precisa enviar os dados uma vez para alcanar todos os alunos.
Seguindo o mesmo exemplo, se for necessrio que os alunos faam interaes com o
professor, enviando perguntas por udio e vdeo, passamos a ter um modelo com mltiplos
transmissores. Este modelo o que envolve maior complexidade em transmisses multiponto, sendo, portanto, o modelo em foco no restante deste captulo.
Em videoconferncias multiponto, h basicamente trs modelos de transmisso possveis: o
Captulo 6 - Videoconferncia multiponto
objetivos
Videoconferncia multiponto
modelo centralizado, o modelo descentralizado e o modelo hbrido.

165
Modelo centralizado
Em uma sesso de videoconferncia baseada neste modelo, cada participante estabelece
uma conexo com um componente central, chamado de Multipoint Control Unit (MCU). Cada
participante envia um fluxo de udio e um de vdeo para a MCU. A distribuio do fluxo de
udio, vdeo e dados para cada participante feita pela MCU, que mescla os vrios fluxos de
udio, seleciona um fluxo de vdeo ou compe um novo fluxo com mltiplos vdeos e
retransmite o resultado para todos os participantes. Essa composio de vdeos pode ser,
por exemplo, uma tela dividida em quatro partes iguais, cada uma exibindo o vdeo de um
dos participantes. O MCU gerencia a videoconferncia usando funes de controle H.245 e
o elemento mais importante em uma videoconferncia centralizada. Ele pode enviar o fluxo
de udio e vdeo atravs de unicast ou multicast.
MCU
Modelo descentralizado
No modelo descentralizado, no h um componente central para controlar a conferncia
como a MCU. Neste modelo so os prprios terminais que fazem o controle da comunicao
e do trfego de dados multimdia. Uma diferena importante justamente o tratamento dos
dados multimdia: enquanto no modelo centralizado a MCU faz o processamento de mdia,
no modelo descentralizado os fluxos so enviados e recebidos por todos os participantes
sobre uma base fim a fim, sendo que cada participante responsvel por sua prpria mesclagem de udio e seleo de vdeo. A transmisso dos dados multimdia entre os terminais
pode ser feita utilizando unicast ou multicast.
Unicast
Com unicast, cada terminal deve transmitir seu fluxo para cada um dos outros terminais,
assim como deve receber o fluxo de cada um dos terminais. Ou seja, para n terminais, cada
166
terminal deve enviar e receber n-1 fluxos. Este modelo apresenta um problema de escalabilidade quando a videoconferncia apresenta muitos terminais.
Figura 6.1
Videoconferncia
multiponto
centralizada.
Figura 6.2
Videoconferncia
multiponto
descentralizada
usando unicast.
Multicast
O uso de multicast reduz em parte o problema do modelo com unicast: agora cada terminal
envia apenas um fluxo, mas continua recebendo n-1 fluxos. Com isso reduzido o upload de
cada terminal, mas no reduzido o download.
Transmisso
multicast
Figura 6.3
Videoconferncia
multiponto
descentralizada
usando multicast.
Outra forma de visualizar a codificao escalvel vista na Figura 6.4 (Telepresence options,
Figura 6.4
Exemplo de
transmisso escalvel com quatro
camadas se adaptando a dispositivos
com diferentes
resolues.
Modelo hbrido
O modelo hbrido tenta mesclar o melhor dos dois modelos anteriores, mantendo a
consistncia dos dados atravs de um armazenamento centralizado que controla a conferncia, mas permitindo que os terminais tenham autonomia suficiente para fazer a transmisso de alguns dados de forma descentralizada.
setembro de 2012 Jeff Scherz Video Interoperability in Lync 2013).
167
Transmisso
multicast
Figura 6.5
Videoconferncia
multiponto hbrida.
MCU
Uma implementao hbrida pode: operar sobre uma rede multicast com cada usurio
utilizando sua prpria verso das ferramentas; distribuir o fluxo de mdia de acordo com o
modelo descentralizado, mas contendo algum mecanismo tal como um servidor na
conferncia para controlar documentos compartilhados, ou arquivar a mdia de sesses
que ocorreram. Portanto, o modelo hbrido tem a vantagem de prover armazenamento
centralizado para sesses de videoconferncia para cada participante da sesso, sem ter
que controlar cada instante da aplicao.
Um exemplo de videoconferncia baseada no modelo hbrido utilizar uma MCU para
manusear o udio, dados e controle de funes, mas distribuir o vdeo por multicast, com
objetivo de otimizar a largura de banda.
MCU
11 Gerencia conferncias multiponto, viabilizando a comunicao entre 3 ou mais
pontos simultaneamente.
11 Permite a criao de mltiplas salas virtuais de conferncia.
11 Pode transmitir os vdeos em unicast (para todos participantes) ou multicast.
11 Pode ser apenas um controlador de sinalizao (modelo hbrido) ou tambm controlar
toda a mdia (modelo centralizado).
Outras funcionalidades:
11 Realiza a transcodificao de velocidades (bitrate).
11 Servidor de streaming (suportado pela minoria das solues).
11 Sistema de gerenciamento via web com:
22 Controle sobre os participantes remotos.

22 Bloqueio de udio/vdeo remoto.
11 Mltiplos layouts de vdeo.
A MCU a unidade responsvel pelo gerenciamento de conferncias multiponto, viabilizando a comunicao entre trs ou mais pontos simultaneamente. Uma MCU normalmente
permite a criao de mltiplas salas virtuais de conferncia, podendo agir apenas como um
controlador de sinalizao (no modelo hbrido) ou tambm controlar toda a transmisso
multimdia (no modelo centralizado). Outras funcionalidades importantes da MCU:
11 Realizar a transcodificao de velocidades (variao no bitrate de codificao);
11 Servidor de streaming (suportado pela minoria das solues);
168
11 Sistema de gerenciamento via web com:

22 Controle sobre os participantes remotos;
22 Bloqueio de udio/vdeo remoto;
22 Mltiplos layouts de vdeo, conforme exemplo da figura seguinte.
Figura 6.6
Mltiplos layouts
de vdeo.
Dois modos de operao para controle de udio e vdeo:
Comutao por voz

11 Vdeo e udio de apenas um participante.
11 O participante ativo aquele que est falando no momento.
Mixagem de vdeo e udio
11 Chamada de presena contnua.
11 Mltiplos vdeos e mltiplos udios mixados.
Os vdeos so dispostos conforme o layout escolhido.
A recomendao H.323 especifica que a MCU composta por dois elementos bsicos: um
Multipoint Controller (MC), obrigatrio para conferncias multiponto, e unidades Multipoint
Processor (MP), opcionais. Apesar do MP ser opcional, uma MCU deve incluir pelo menos um
para suportar a realizao de conferncias centralizadas.
O Multipoint Controller (MC) tem como objetivo fazer o controle geral da conferncia, o que
envolve fazer ou receber chamadas dos terminais, negociar as capacidades dos terminais e
se comunicar com o MP quando for necessrio algum tratamento sobre os dados de udio
e/ou vdeo. O MC no est presente em uma rede H.323 de maneira independente, mas
Uma das funcionalidades mais importantes do MC a negociao de capacidades com cada

um dos terminais presentes conferncia, onde ele procura estabelecer capacidades comuns
de udio, vdeo ou dados. Isto feito enviando um conjunto comum de capacidades (capability
set) aos terminais conectados conferncia. Neste ponto, importante lembrar que cada
terminal tambm fornece sua tabela de capacidades no incio da chamada ao elemento que
contm o MC, que pode ainda rever tal conjunto de capacidades cada vez que um terminal
entra ou deixa a conferncia. Este conjunto de capacidades tambm pode ser crucial para a
determinao do tipo de conferncia (centralizada ou descentralizada) em questo.
Cada conferncia possui somente um MC que executa a funo de gerenciamento. Este MC
chamado MC ativo e, uma vez determinado, este status no modificado at o final da con-
sempre associado a uma entidade H.323.
ferncia ou seja, durante o curso de uma conferncia H.323, o controle de gerncia jamais
169
transferido de um MC para outro. Eventualmente, quando dois terminais H.323, que

possuem um MC cada, conectam-se atravs de uma chamada por exemplo, um terminal
com um MC chamando uma MCU , uma regra deve ser determinada a fim de estabelecer
o MC que se tornar o MC ativo.
A ordem de preferncia utilizada definida pela seguinte funo: MC terminal < MC gateway
< MC gatekeeper < MC MCU.
Nesse caso, o MC presente em uma MCU tem preferncia total na escolha do MC ativo. O MC
de um terminal s ser escolhido como MC ativo se nenhuma outra entidade estiver envolvida na chamada. Eventualmente, uma chamada para incio de uma conferncia pode ser
estabelecida entre duas entidades de um mesmo tipo que possuam um MC. Para resolver
este conflito, o protocolo H.245 utiliza um campo terminalType, que armazena um valor
inteiro calculado com base nas caractersticas de cada um dos elementos. Os valores para
este campo dependem do tipo de entidade, da presena ou no de MC e MP e, por fim, dos
tipos de mdia suportados pelo MP: dados; dados e udio; dados, udio e vdeo (completa).
Sendo assim, o MC da entidade que apresentar maior valor para terminalType assume o
controle da conferncia.
O Multipoint Processor (MP), a exemplo do MC, s existe associado a uma entidade H.323
tipicamente, uma MCU ou gateway. O MP se faz presente em uma conferncia apenas
quando se trata do modo centralizado ou, possivelmente, no modelo hbrido. O MP tem por
finalidade processar um ou mais fluxos de udio, vdeo ou dados, devolvendo o resultado
deste processamento aos participantes da conferncia. Caso o MP processe vdeo, o resultado desse processamento pode ser: (1) a mixagem dos vdeos de diversos participantes de
acordo com um layout escolhido; ou (2) a chamada comutao dos vdeos, onde apenas o
vdeo de um participante utilizado (o participante ativo).
No caso de vdeo comutado, somente o vdeo de um dos participantes exibido por vez.
A seleo do vdeo que ser exibido feita detectando-se o usurio ativo no momento, ou seja,
aquele com a posse da palavra. J os udios dos participantes so mixados e enviados para
todos, ou seja, apesar de ser exibida apenas uma imagem, possvel ouvir os outros participantes. Esta tcnica chamada de comutao de vdeo ativada por voz (voiceactivated video
switching). Se os participantes no so suficientemente disciplinados, aguardando sua vez de
falar, este tipo de comutao pode ser problemtica, pois o vdeo pode ser continuamente cha-
veado assim que um participante comea a falar, impossibilitando uma visualizao inteligvel.
Figura 6.7
Vdeo comutado
por voz.
No outro caso, vdeo mixado, os vdeos de diversos participantes so combinados em um

novo vdeo que codificado e enviado aos participantes. Tipicamente, o MP divide o vdeo
em vrias janelas distintas, cada uma com o vdeo em escala reduzida de um dos participantes. Normalmente, uma das janelas (normalmente maior que as outras) escolhida
para aplicar uma comutao baseada em voz, enquanto as demais se mantm inalteradas,
170
a menos que um dos participantes deixe a conferncia. Esse modo chamado de presena contnua. Alguns fabricantes oferecem layouts diferentes como diferencial (como no
exemplo visto anteriormente). O modo de presena contnua implica um elevado custo computacional para sua realizao, uma vez que o MP trabalha decodificando e recombinando
vdeo de vrios participantes, em vez de simplesmente retransmitir determinado vdeo,
como no modo de comutao por voz.
A situao do udio permanece como no modo por comutao: o fluxo de udio enviado
por cada um dos participantes combinado e o fluxo resultante enviado para todos. O MP
deve ter o cuidado de garantir que nenhum participante receba seu prprio udio misturado
com os demais; caso contrrio, haveria um desagradvel efeito de eco.
Figura 6.8
Vdeo com
presena contnua.
Click here to add another

person to the conference
Solues de MCUs
A escolha de uma soluo de MCU feita com base nos requisitos necessrios para as
videoconferncias. importante que suportem os principais protocolos atuais:

11 Protocolos de vdeo: H.261, H.263 / H.263+ / H.263++ / H.264.
11 Resolues de vdeo:
11 CIF, QCIF e 4CIF 720p e 1080p (alta definio).
11 Protocolo para compartilhamento de dados: T.120 e H.239.

Quanto visualizao, devem suportar:
11 Variados layouts de vdeo.
11 Layouts com suporte a um grande nmero de participantes.
22 Geralmente, o nmero de referncia 16.
11 Formato widescreen.
11 Possibilidade de preview das cmeras dos participantes.
11 Controle do udio e vdeo dos participantes remotos (habilitar/desabilitar).
11 Mensagem de texto na tela (close caption).
11 Protocolos de udio: G.711, G.722, G.722.1 e G.728.
171
Quanto segurana, devem suportar:
11 Configurao de direitos e privilgios para usurios.

11 Configurao de senha para conferncias.
11 Padro de encriptao ITU H.235 (pelo menos codificao AES).
Tipos de solues:
11 Baseadas em hardware.
22 No-modulares: solues fechadas, que no podem ser agrupadas a outros
mdulos posteriormente.
22 Baseadas em software (OpenMCU, por exemplo).
A escolha de uma soluo de MCU feita com base nos requisitos necessrios para as videoconferncias. Seguem abaixo alguns itens importantes que devem ser considerados para
a escolha de uma soluo de MCU. importante que a soluo que suporte os principais
protocolos atuais de vdeo (H.261, H.263 / H.263+ / H.263++, H.264) e os formatos (CIF, QCIF
e 4CIF) em 720p e 1080p, para alta definio. Suportem tambm os protocolos de udio
(G.711, G.722, G.722.1 e G.728) e protocolo para compartilhamento de dados (T.120, H.239).
Quanto visualizao, devem suportar variados layouts de vdeo, layouts com suporte a um
grande nmero de participantes onde geralmente, temos como referncia 16, suporte ao
formato wide screen com possibilidade de preview das cmeras dos participantes (atravs
de interface de gerenciamento web da MCU, por exemplo), deve permitir controlar o udio e
o vdeo dos participantes remotos podendo habilitar e desabilita-lo e at mesmo exibir mensagens de texto na tela (close caption). Quanto segurana, devem permitir a configurao
de direitos e privilgios para usurios, configurao de senha para conferncias e suporte
ao padro de encriptao ITU H.235 (pelo menos codificao AES).
As solues de MCU podem ser classificadas em dois tipos: as baseadas em software e as
baseadas em hardware. As solues em hardware constituem solues comerciais completas para o oferecimento do servio de videoconferncia. So solues caras e geralmente
utilizadas no meio profissional. Elas podem ser modulares, onde recursos (outros mdulos
MP, por exemplo) podem ser agregados conforme a necessidade, e no-modulares, que so
modelos mais fechados e no permitem expanso.
172
Figura 6.9
Equipamento MCU.
As solues baseadas em software so mais baratas, mas seu desempenho dependente

do hardware onde sero implantadas. Essa dependncia torna o servio suscetvel e frgil.
Porm, existem solues acessveis em cdigo aberto e que oferecem resultados satisfatrios em casos de conferncias experimentais, como por exemplo, a soluo OpenH323.
Solues de MCUs em hardware
11 Modelo modular.
11 Modelo no-modular:
22 Mesmos fabricantes dos modelos modulares.
22 A expanso s possvel atravs do cascateamento de MCUs, ou seja, no uma
soluo to boa quando a expanso adicionando mdulos.
22 Por serem uma caixa fechada, so modelos mais baratos que os modulares.
As solues de MCU em hardware, tanto os modelos modulares quanto os no-modulares,
so disponibilizadas por diversos fabricantes. Os principais fabricantes atualmente so:
Codian (que faz parte da Tandberg), Tandberg (que faz parte da Cisco), Polycom e Radvision.
As MCUs modulares utilizam um chassi onde os mdulos so colocados e interligados.
possvel, portanto, comprar a MCU bsica com apenas um mdulo e adicionar novos
mdulos (Multipoint Processors) conforme necessidades futuras. J os modelos no-modulares so caixas fechadas, onde a expanso s possvel atravs do cascateamento de
MCUs. No cascateamento, as mltiplas MCUs operam como se houvesse apenas uma MCU
na rede (cascateamento transparente ao usurio), mas ainda assim no uma soluo to
otimizada como a expanso por adio de mdulos. Por esse motivo os modelos modulares
costumam ser solues mais caras do que os modelos no modulares.
Figura 6.10
Exemplos de
MCUs modulares.
As imagens abaixo exemplificam MCUs em hardware, incluindo modelos modulares

e no-modulares:
Polycom
Tandberg
MPS 200
MPS 800
RMX 2000*
Radvision
MSE 8000*
SCOPIA 400
SCOPIA 1000
Codian
MGC 100
MGC 50
173
Polycom
MGC 25
Codian
Srie 4200
Radvision
Srie 4500 (HD)
Figura 6.11
Exemplos de MCUs
no-modulares.
SCOPIA 12/24
Modelos de MCU que suportam alta definio esto sendo demandados em funo do crescente nmero de terminais que suportam alta definio.
Lifesize
Polycom
Tandberg*
Lifesize Room
Srie HDX 9000
Tandberg Edge
Demonstrao de MCU RNP

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

11 Suporte a tecnologia UltimateHD da Polycom;
11 Salas de reunies virtuais sempre disponveis.
Figura 6.12
Exemplos de MCU.
Figura 6.13
MCU RMX 4000.
Solues de MCUs em software

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

Combina no mximo o vdeo de 4 participantes.
MCUs em software normalmente possuem limitaes similares no nmero mximo
de participantes. Assim, podem ser oferecidas diferentes verses do software, cada
uma com suporte a um diferente nmero de participantes (o que usado para determinar o preo de venda).
11 Suporta mltiplas salas de videoconferncia e conexes simultneas;
175
Alternativa ao MCU: vdeo escalvel

Permite codificar um vdeo em mltiplas camadas. Cada camada representa o vdeo com
determinadas configuraes de:

11 Resoluo.
11 Taxa de quadros por segundo.
11 Qualidade (medida PSNR).
11 Taxa de bits por segundo (bitrate).
11 Ou seja, o vdeo codificado apenas uma vez e pode ser transmitido e visualizado em
diversas configuraes/qualidades.
Comparao com MCU:
11 MCU precisa decodificar os dados, compor o novo vdeo e codific-lo.
11 Um roteador escalvel apenas faz a seleo e o encaminhamento dos pacotes ajustando o nmero de camadas de acordo com a capacidade do receptor.
Vantagens sobre o uso de MCU:
11 Minimiza o atraso.
11 Minimiza o processamento (feito apenas nos terminais).
11 Resulta em equipamentos mais baratos que MCUs.
11 Maior qualidade, visto que no faz transcodificao.
Desvantagens sobre o uso de MCU:
11 Necessita de um software codificador e decodificador escalvel nos terminais,
exigindo maior processamento.
11 Dificuldade de interoperar entre diferentes fabricantes, pois o Scalable Video Coding
(SVC) ainda pouco explorado.
Codificao de vdeo escalvel, simplificadamente, uma forma de codificar um vdeo
em diversas camadas cumulativas, onde as camadas inferiores possuem qualidade mais
baixa e servem como base para as camadas superiores, que adicionam qualidade ao vdeo.
Podemos ter, por exemplo, um vdeo codificado com 3 camadas, sendo elas:
11 Camada 0: resoluo 160x120 e 15 quadros por segundo: 128 kbit/s;
11 Camada 1: agrega camada 0 o diferencial para uma resoluo 320x240 e 30 quadros por
segundo: camada 1: 384kbit/s. Agregado camada 0 + 1 = 512 kbit/s;
11 Camada 2: agrega o diferencial para uma resoluo 640x480 e 30 quadros por segundo:
camada 2: 512kbit/s. Agregado camada 0 + 1 + 2 = 1024 kbit/s.
176
As trs camadas do exemplo formam um vdeo apenas, e no trs vdeos. Com codificao de vdeo tradicional, para obter essas trs diferentes configuraes dos vdeos, seria
necessrio codificar o vdeo trs vezes. Com codificao escalvel necessria apenas uma
codificao. A desvantagem, porm, est no maior custo de processamento e em uma compactao um pouco menor do que a obtida com uma codificao no escalvel (20% menos
eficiente, por exemplo). A imagem seguinte ilustra o processo de codificao escalvel.
Vdeo original
Alta resoluo,
qualidade alta
TV
Alta resoluo,
qualidade baixa
Codicao
escalvel
PC
Baixa resoluo
Codicao nica
celular
Figura 6.14
Codificao
escalvel em trs
camadas.
O padro mais atual para codificao de vdeo escalvel o H.264 SVC (Scalable Video
Coding). Com esta forma de codificao, possvel substituir a MCU por um elemento
chamado roteador escalvel, que apenas faz a seleo e o roteamento dos pacotes, um
processo muito mais simples e rpido que o processo feito pela MCU.
Codicao escalvel
MCU
Decodicar
Usurio 2
Usurio 1
Decodicar
Usurio 2
Usurio 1
Compor
Roteamento e
seleo das camadas
Usurio 3
Usurio 3
Como pode ser visto na figura anterior, o processamento feito pela MCU inclui: a decodificao de todos os vdeos que ela recebe (todos os participantes da videoconferncia); a
composio dos vdeos em um s vdeo; a codificao deste vdeo gerado. Todo este
processo bastante complexo computacionalmente, incluindo assim o atraso na transmisso. tambm devido a essa complexidade que as MCUs so dispositivos caros, j que
devem ter alto poder de processamento.
J o modelo com roteador escalvel passa uma maior complexidade para os terminais, minimizando o trabalho do roteador escalvel, substituindo a MCU. Dessa forma, o roteador j
recebe dos terminais os vdeos codificados de forma escalvel, e apenas seleciona as camadas
que sero retransmitidas aos destinatrios, de acordo com a capacidade de processamento e
banda de cada um. A decodificao e recodificao feitas pela MCU no so necessrias neste
Figura 6.15
Comparao do
roteador escalvel
com a MCU.
Codicar
cenrio, e a composio dos diversos vdeos feita apenas no receptor, antes da exibio.
177
Utilizando as 3 camadas de vdeo utilizadas como exemplo anteriormente, uma transmisso

escalvel pode se dar como no exemplo abaixo:
11 Os 4 participantes codificam seus vdeos de forma escalvel, com as 3 camadas citadas
no exemplo, transmitindo-as para o roteador escalvel (que faz o papel do MCU);
11 O layout escolhido pelos participantes de um vdeo com maior resoluo (comutado por
quem est falando no momento) e 3 vdeos com menor resoluo;
11 O roteador identifica que o participante A est falando, e por isso transmite as camadas
0 e 1 de seu vdeo (obtendo um vdeo com resoluo 320x240 e 30 quadros por
segundo a 512 kbit/s);
11 Para os outros 3 participantes, o roteador transmite apenas a camada 0 (vdeos com
resoluo 160x120 e 15 quadros por segundo a 128 kbit/s);
11 Com isso cada participante receber 3 vdeos com resoluo 160x120 e um vdeo com
resoluo 320x240, com banda total de 896 kbit/s (4x128kbit/s + 1x384kbit/s);
11 Eventualmente, se um dos participantes no tivesse banda suficiente, ele poderia receber
somente a camada 0 de todos os participantes, minimizando sua necessidade de banda.
possvel fazer diversas configuraes de camadas variando resoluo, quadros por
segundo e banda de cada camada de vdeo na codificao escalvel. Alm disso, tambm
possvel fazer adaptao da banda dos vdeos dinamicamente, ou seja, o total de 896 kbit/s
recebido por cada participante no exemplo anterior poderia ser reduzido pelo prprio roteador em troca da perda de qualidade dos vdeos.
Como podemos ver, existem algumas vantagens relacionadas utilizao de vdeo escalvel.
Resumidamente, as vantagens em relao MCU so:
11 O atraso reduzido (no necessrio perder tempo em transcodificao e mixagem);
11 O processamento reduzido, pois feito apenas nos terminais. O roteador s um encaminhador de pacotes que determina tambm o nmero de camadas para cada terminal;
11 Equipamentos mais baratos que MCUs.
Em termos de desvantagens, pode-se dizer que, como o modelo novo, no existe padronizao de sinalizao ainda, e a interoperabilidade entre diferentes fabricantes prejudicada.
Alm disso, aumenta a necessidade de processamento nos terminais.
Estudo de caso de vdeo escalvel: empresa Vidyo

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

Nesta atividade o instrutor demonstrar a utilizao do aplicativo People+Content para
compartilhar documentos com o terminal Polycom V500.
Inicialmente deve-se estabelecer uma chamada entre o Polycom V500 do instrutor e algum
aluno utilizando o Polycom PVX. Aps estabelecer a conexo, o aplicativo People+Content
(instalado em qualquer mquina do laboratrio) estabelece conexo com o Polycom V500,
entrando assim na conferncia.
181
182
7
Ao final do captulo o aluno deve possuir uma viso mais embasada dos elementos
necessrios para efetuar o projeto de todos os aspectos envolvidos em uma sala
de videoconferncia (ambiente fsico, udio e vdeo). Alm disso, deve entender os
conceitos bsicos de tica em videoconferncia.
conceitos
Projeto de salas de videoconferncia, levando em considerao o ambiente fsico

(iluminao, visibilidade, acstica, climatizao), ambiente de udio (tipos e
posicionamento dos microfones) e ambiente de vdeo (interferncias, acessrios),
tica em videoconferncia e estudo de cenrios.
Salas de videoconferncia
Diversos fatores em uma sala de videoconferncia influenciam na qualidade do servio
de videoconferncia. Eles podem ser separados em trs classes:

11 Ambiente fsico.
11 Ambiente de udio.
11 Ambiente de vdeo.
O ambiente onde uma videoconferncia realizada possui diversos fatores que influenciam
a qualidade do servio de videoconferncia. Esses fatores podem ser encaixados em trs
grupos: ambiente fsico, ambiente de udio e ambiente de vdeo. Quando determinados
adequadamente de acordo com a sala que ser usada para videoconferncia, esses fatores
podem definir o sucesso ou fracasso das videoconferncias. Entre os fatores esto iluminao, visibilidade, acstica, mobilirio ergonmico e decorao.
O projeto fsico da sala envolve a identificao destes elementos, a definio de suas
caractersticas e a disposio dos mesmos no espao fsico alocado. O projeto uma etapa
indispensvel para criao de uma sala de videoconferncia adequada, pois uma sala de
videoconferncia possui muitas diferenas em relao a uma sala tradicional, como, por
exemplo, se compararmos uma sala de aula tradicional com uma sala de aula adequada
para aulas remotas por videoconferncia.
Captulo 7 - Projeto de ambientes de videoconferncia
objetivos
Projeto de ambientes
de videoconferncia
183
Ambiente fsico
Os principais fatores que devem ser considerados na realizao de videoconferncia que
esto relacionados ao ambiente fsico so:

Iluminao
11 Influencia diretamente a qualidade das imagens. Recomendaes:
22 Evitar fontes externas de iluminao.
22 Utilizar fontes homogneas de luz.
22 Utilizar ambiente uniforme e pouco reflexivo.
Visibilidade
11 Procure minimizar obstculos e interferncias visuais.
11 Maximize a rea de exibio das imagens.
Acstica
11 Observe o tratamento acstico do ambiente para minimizar os rudos externos e
internos que possam interferir no bom andamento da videoconferncia.
11 Use cortina, carpete e isolamento acstico para evitar mveis muito retos que
reflitam o som.
Climatizao
11 O ar-condicionado deve ser escolhido levando em considerao os rudos por ele
gerados, na opo mais silenciosa possvel.
Iluminao
De nada adianta o avano tecnolgico das cmeras de vdeo nos ltimos anos, se a qualidade de iluminao proporcionada no ambiente no for adequada. Para alcanar um padro
de qualidade pelo menos aceitvel, necessrio tomar alguns cuidados em relao iluminao do ambiente. Destacamos algumas recomendaes:
11 Evitar fontes externas de iluminao: evite, sempre que possvel, salas com janelas, de
modo a neutralizar fontes externas de iluminao; no sendo possvel, deve-se utilizar
cortinas do tipo black-out, que eliminam essas fontes de luz;
11 Utilizar fontes homogneas de luz: a sala deve ser iluminada de forma homognea, utilizando-se, preferencialmente, lmpadas fluorescentes do tipo luz do dia. Para assegurar
a homogeneidade da iluminao, evite misturas de fontes de iluminao, como lmpadas
incandescentes e iluminao fluorescente;
11 Ter um ambiente uniforme pouco reflexivo: utilize mobilirio de cores claras para evitar
sombras no rosto dos participantes; as paredes devem ser lisas, de cores uniformes e
184
sem superfcies muito refletoras. As cores recomendadas so: cinza, azul e verde (claros),
creme ou branco-gelo, com acabamento em cores foscas;
11 aconselhvel que a intensidade luminosa em uma sala de videoconferncia esteja
situada na faixa de 700 a 1.100 luxes (valor um pouco acima do estabelecido pela norma
Lux
da ABNT para iluminao de escritrios).
Medida da intensidade
de luminosidade. A luminosidade de uma sala
pode ser verificada com
o uso de um luxmetro.
Figura 7.1
Exemplo de luminosidade em sala de
videoconferncia.
Visibilidade
A visibilidade uma caracterstica que leva em considerao a disposio do mobilirio
ergonmico na sala de videoconferncia. Por exemplo, para que todas as pessoas possam
ver as imagens sem obstruo, os monitores devem ser colocados em posies adequadas,
com o menor nmero de obstrues entre os participantes e eles. A posio adequada varia
muito conforme o propsito da videoconferncia (ensino distncia, reunies remotas etc.)
e conforme o formato da sala na qual ela est sendo realizada, mas os monitores normalmente so dispostos na altura da viso dos participantes.
Outro cuidado com o posicionamento da cmera, que deve ser colocada acima do monitor
principal, para que seu ngulo de viso possa focalizar, na sua totalidade, tanto os participantes
quanto a plateia. Entretanto, deve haver o cuidado de no colocar o monitor principal a uma
altura que, ao posicionar a cmera sobre ele, cause a impresso de que a imagem dos participantes esteja sendo capturada do alto, quando na realidade est sendo capturada de frente.
Resumindo, os monitores devem estar localizados num local onde todos os participantes
possam v-los sem obstrues; a cmera (ou cmeras) deve estar localizada neste mesmo
local, de forma a capturar os participantes e/ou palestrantes de frente, de forma que aparente
Cmera
Cmera
Figura 7.2
Exemplos de
posicionamento
dos monitores e
cmeras em uma
videoconferncia.
A figura a seguir mostra um exemplo do estdio do Inmetro-RS, utilizado para ministrar

aulas por videoconferncia. Pode-se observar o detalhe da janela de fundo, que uma
janela falsa. Com criatividade, uma TV de plasma e uma iluminao artificial, possvel
simular diversos ambientes diferentes, conforme a necessidade. A figura tambm mostra
um exemplo de ambiente mais rstico, porm com linhas suaves e onduladas. O ambiente
foi projetado para permitir diversas vises pela cmera.
que eles esto olhando para a cmera, quando na verdade esto olhando para os monitores.
185
Figura 7.3
Exemplo de estdio
no Inmetro/RS.
Acstica
A acstica da sala fundamental para a qualidade do udio, aspecto primordial para uma
videoconferncia. O nvel de pode deve ser medido atravs do auxlio de um decibelmetro,
Decibelmetro
procurando manter uma taxa que no influencie o andamento da conversao entre os
Sonmetro eletroacstico com escala de

leitura em decibis. Instrumento utilizado para
medio de decibis.
participantes da videoconferncia.
Alm de observar o nvel de rudo (que no uma atividade to trivial), pode-se lanar
mo dos seguintes aspectos: absoro e refletividade, nveis de rudo do ambiente, efeito
de reverberao (eco), tamanho da sala e sua geometria. Para diminuir os rudos, algumas
alternativas so:
11 Observar a composio dos elementos da sala, evitando o uso de materiais refletores
(vidro, gesso, madeira, cermica) que podem influenciar na acstica e, portanto, no
so recomendveis;
11 Evitar mveis muito retos, que refletem som;
11 Utilizar cortinas;
11 Utilizar carpete;
11 Isolar a sala acusticamente.
Recomenda-se que o nvel de rudo mximo admissvel em uma sala de videoconferncia no ultrapasse 50 dB-SPL (decibel). Essa medida deve ser tomada com o
ambiente vazio, todos os equipamentos ligados e com o auxlio de um medidor
(decibelmetro) posicionado no centro da sala. Vale lembrar que dB-SPL a medida
do som emitido (l-se: decibel Sound Pressure Level).
Climatizao
186
A climatizao da sala deve prover condies climticas e trmicas agradveis aos participantes da videoconferncia. Uma sala com climatizao apropriada fundamental tanto
para o conforto das pessoas quanto para o bom funcionamento dos equipamentos, pois um
local bem climatizado saudvel para as pessoas e prolonga a vida til dos equipamentos.
Para climatizao da sala utilizando aparelhos de ar-condicionado tambm muito importante considerar o nvel de rudo dos aparelhos utilizados, pois aparelhos muito barulhentos
podem prejudicar o andamento de uma videoconferncia, como foi visto no item Acstica.
Ambiente de udio
Qualidade do udio:
11 possvel realizar uma videoconferncia sem vdeo, mas sem udio invivel.
Microfones podem ser de diversos tipos:
11 Unidirecionais ou multidirecionais.
11 Com fio ou sem fio.
11 De mo, de mesa, de lapela ou headset.
11 Individuais ou de grupo.
Microfones com ou sem fio:
11 Com fio perde mobilidade, mas dispensa a preocupao com pilhas, sendo vlido
quando as pessoas esto em um ponto fixo, como uma mesa.
Microfones individuais (unidirecionais) ou de grupo (omnidirecionais).
A qualidade do udio um elemento primordial em uma videoconferncia. Quando uma
videoconferncia apresenta certas dificuldades (falhas) no vdeo, ainda assim possvel que
a conferncia continue em execuo apenas com udio. Se ocorrerem quaisquer falhas no
udio, porm, a conferncia torna-se invivel. Ou seja, falhas de udio incomodam e prejudicam muito mais uma conferncia do que falhas de vdeo, o que mostra a importncia em
manter uma qualidade de udio alta.
A escolha dos microfones que sero usados uma tarefa muito importante para buscar
qualidade no udio de uma videoconferncia. Existem diversos modelos disponveis, que
devem ser escolhidos conforme o formato da videoconferncia (aula, palestra, reunio etc.),
a quantidade de participantes, o ambiente de videoconferncia, entre outros fatores.
Tipos de microfones e suas caractersticas

Os microfones podem ser separados em diversas categorias. Podem ser individuais ou de
grupos, unidirecionais ou omnidirecionais, com fio ou sem fio, microfones de mo ou de
mesa, entre outros. Abaixo sero descritos os principais tipos de microfones, as suas caractersticas, vantagens e desvantagens.
So os microfones mais conhecidos e por isso so facilmente encontrados no mercado, com

modelos profissionais de alta qualidade at modelos mais simples, de menor custo. Exigem
que o interlocutor fique segurando o microfone na mo, o que inibe sua liberdade. Pode-se
tambm utilizar um suporte fixo para o microfone, o que prejudica a mobilidade do usurio.
Um problema comum que com o tempo o usurio de um microfone de mo esquece que
est com ele e comea a afast-lo ou aproxim-lo da boca, provocando alterao na intensidade do udio captado e causando incmodo para os ouvintes (podendo at impossibilitar
o entendimento do que est sendo dito).
Microfones de mo
187
Esto disponveis em modelos unidirecionais e ominidirecionais, com fio e sem fio. Normalmente so utilizados em salas de aula ou auditrios.
Figura 7.4
Microfone de mo
preso a um suporte.
Microfones tipo headset

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

Os microfones com fio so mais baratos e fceis de encontrar; no entanto, existem situaes
em que o interlocutor precisa movimentar-se, como por exemplo um palestrante em um
auditrio, ou quando se deseja passar o microfone para uma das pessoas da plateia. Nestas
suficiente ou do fio enroscar no mobilirio, por exemplo.
Apesar do microfone sem fio ser mais verstil, mais caro que o modelo correspondente
com fio e requer a utilizao de pilhas, que precisaro ser trocadas periodicamente. A autonomia das pilhas pode variar de 6 a 30 horas, dependendo do modelo. A conexo mesa de
som feita atravs de uma base receptora que possui uma antena para receber o sinal do
microfone sem fio. Quando for utilizado mais de um microfone sem fio, imprescindvel que
eles operem em canais de transmisso (faixa de frequncia) diferentes, para que um no
cause interferncia no outro. A maioria dos microfones sem fio vem ajustada de fbrica para
operar em determinados canais, sem possibilidade de ajuste posterior. Portanto, no ato da
compra necessrio verificar se os microfones funcionam em canais diferentes.
A figura a seguir mostra a comparao entre vantagens e desvantagens dos modelos de
microfones com e sem fio.
situaes um microfone sem fio elimina os problemas decorrentes do fio no ser comprido o
189
Com fio
Vantagens
11Mais baratos.
11Fceis de encontrar.
Sem fio
11Maior mobilidade.
11A maioria funciona

sem pilhas.
Desvantagens
11Mobilidade limitada.
11Fios enroscam no
mobilirio.
11Mais caros.
11Demandam troca de pilhas.
11Quando as pilhas enfraquecem podem ocorrer interferncias.

11Maior dificuldade de encontrar.
11Podem interferir com outros microfones sem fio (se funcionarem

na mesma frequncia).
Diretividade em microfones
Os microfones possuem diferentes ngulos de captao, e so classificados como:
11 Omnidirecionais: capturam sons vindos de todas as direes.
Figura 7.9
Comparao
entre modelos
de microfones.
11 Direcionais: capturam melhor sons vindos da frente e rejeitam sons emitidos nos
lados e atrs.
Os microfones omnidirecionais captam os sons em todas as direes e so indicados em
casos onde diversas pessoas vo compartilhar um mesmo microfone. No entanto deve-se
tomar cuidado com o posicionamento e o volume das caixas de som, pois existe a possibilidade de captar o som das caixas acsticas ou outros rudos da sala.
Para reduzir a captao de sons indesejados, deve-se utilizar microfones direcionais, que
possuem baixa sensibilidade para os sons vindos de trs. importante observar que h
diferentes sub-classificaes dos microfones unidirecionais, que podem ser cardioide,
super-cardioide e hiper-cardioide. Microfones dos dois ltimos tipos citados podem capturar um pouco do som ao lado e atrs do microfone, apesar de serem unidirecionais.
Durante o uso, os microfones nunca devem ser direcionados para as caixas acsticas, mesmo
que sejam unidirecionais, para que no ocorram microfonias ou reverberao. A figura abaixo
mostra o posicionamento ideal de um microfone em relao s caixas acsticas.
Caixa acstica
rea de sensibilidade do
microfone unidirecional
Cuidados gerais no uso dos microfones

Independentemente do tipo ou da quantidade de microfones, importante orientar as
pessoas no sentido de evitar conversas paralelas em ambientes de videoconferncia, pois
isso pode influenciar na qualidade do udio gerado.
Como vimos, ao abordar a acstica devemos evitar ao mximo rudos externos e internos.
As pessoas e os equipamentos utilizados (ar-condicionado, computadores, projetores,
componentes de iluminao) so as principais fontes geradoras de rudos internos. Esse fato
pode se agravar, caso haja mais de um microfone aberto ao mesmo tempo no ambiente,
190
Figura 7.10
Microfone com
rea de sensibilidade voltada
para as ondas
sonoras das caixas
acsticas localizadas atrs dele.
comprometendo a qualidade do udio da comunicao, e consequentemente podendo

perturbar os participantes. Um cuidado necessrio manter ligado apenas o microfone do
interlocutor ativo, o coordenador da sala responsvel pela concesso da palavra aos participantes e pela orientao quanto ao uso dos microfones. Quando um microfone no est
sendo utilizado, aconselhvel mant-lo desligado, evitando rudos desnecessrios.
Microfonia
Tambm chamada de realimentao de udio, causada quando um microfone est
capturando o udio de uma fonte emissora do som do prprio microfone. Como evitar:
11 Se no estiver falando, desligue o microfone.
11 Utilizar microfones direcionais colocados estrategicamente para no receber diretamente o udio das caixas acsticas.
Em geral, a realimentao provoca um rudo agudo (alta frequncia) que amplificado a
cada vez que o udio capturado pelo microfone emitido pelas caixas de som. A microfonia ocorre frequentemente em videoconferncias quando o microfone est muito
prximo dos alto-falantes que esto emitindo o som remoto. Existem cuidados que podem
evitar o problema:
11 Ajustar o posicionamento das caixas de som e dos microfones;
11 Adequar o volume do microfone para que seja capturada apenas a voz da pessoa que
est falando, evitando capturar outros rudos. O uso de microfones unidirecionais facilita
a reduo da captura de rudos;
11 Utilizao de microfones com cancelamento de eco. O cancelamento de eco pode
tambm ser feito pelo software/hardware utilizado para videoconferncia.
O cancelamento de eco um mecanismo capaz de detectar que os sons que esto sendo
capturados j foram capturados/transmitidos antes (chamados de eco), sendo capaz de
suprimir esses sons, isto , remov-los do sinal como se no tivessem sido capturados,
evitando a realimentao.
Caixas acsticas
11 Necessrias em ambientes com grupos de pessoas, devem ser posicionadas de prefe-
volume do som para evitar microfonias. Cuidados:

11 A orientao dos participantes fundamental:
22 Evitar conversas paralelas em ambientes de videoconferncia.
22 Manter microfone desligado quando no estiver falando e no apontar para a
caixa de som.
11 Adequar o ganho dos microfones para evitar microfonias e eco.
Os fones de ouvido so adequados para conferncias pequenas ou quando houver apenas
uma pessoa assistindo a conferncia em um determinado lugar. Em salas de videoconferncia
ou auditrios deve-se utilizar caixas acsticas, que requerem alguns cuidados quanto ao uso.
O volume das caixas acsticas deve ser ajustado para que o udio possua uma intensidade
de uma conversao. Se o som estiver muito baixo, as pessoas mais afastadas podero
no escutar corretamente; se estiver muito alto, alm do desconforto de quem estiver
rncia na frente da sala, no alto e direcionadas para o fundo da sala. Deve-se ajustar o
mais prximo, os microfones podero captar o som e causar microfonia ou realimentao.

191
Quando a sala for grande, pode ser necessrio utilizar mais caixas acsticas, para que a
intensidade do udio seja equilibrada entre as pessoas que esto sentadas mais frente e
as que esto mais no fundo.
Disposio das caixas acsticas na sala

Um aspecto que merece grande ateno o posicionamento das caixas acsticas. Elas devem
ser direcionadas da frente (onde est a tela de projeo) para o fundo da sala. Quando as
caixas acsticas so fixadas nas paredes ou no teto, garante-se uma melhoria na disperso
acstica, podendo inclusive usar menos potncia de udio do que se estivessem no cho.
Em ambientes em que os participantes tiverem acesso ao microfone, o cuidado deve ser
maior ainda para evitar que o microfone seja levado para posies onde as caixas de som
fiquem direcionadas para a frente dele.
Caixas
acsticas
Caixas
acsticas
Correto
Errado
Projetor
Figura 7.11
Exemplo de bom
posicionamento
das caixas
acsticas e direo
do microfone.
Ambiente de vdeo
Os cuidados relacionados ao ambiente de vdeo em uma conferncia so necessrios tanto
para a captura do vdeo (local) quanto para a exibio do(s) vdeo(s) remoto(s). A imagem
transmitida deve permitir aos participantes da videoconferncia observar as aes e reaes
dos participantes conectados remotamente. Quanto maior a qualidade das imagens, maior
o realismo e, portanto, mais a videoconferncia se aproximar de uma conferncia onde os
192
participantes interagem localmente.

Uma vez gerada a imagem, outro ponto importante a sua exibio. Neste aspecto,
importante observar o tamanho dos monitores (ou qualquer outro dispositivo que exibir
os vdeos) e seu posicionamento.
Figura 7.12
Dispositivos de
exibio de vdeo.
O tamanho correto da tela do monitor determinado pela distncia entre ele e os principais
participantes da videoconferncia. A regra geral que a altura do monitor seja equivalente
a 1/8 da distncia entre a tela e os espectadores. Normalmente pensa-se que quanto maior
o monitor melhor a qualidade e a experincia que ele trar videoconferncia. Isso muitas
vezes verdade, mas deve-se ter cuidado com o uso de monitores muito grandes muito prximos aos participantes, onde seu tamanho pode acabar prejudicando a videoconferncia.
Em relao ao posicionamento, os monitores devem estar em um local visvel a todos
participantes, sem obstrues entre eles. Normalmente as cmeras so posicionadas junto
aos monitores para que os participantes, ao olharem para os monitores, tambm estejam
olhando para as cmeras, evitando a situao onde o participante parece (nos pontos
remotos) no estar olhando para os participantes remotos, mas para outra posio qualquer (olhar disperso).
A qualidade da imagem tambm afetada pelo processo de codificao de vdeo. Alm das
caractersticas tcnicas que envolvem o processo, h cuidados que devem ser tomados no
ambiente de videoconferncia para auxiliar a codificao e maximizar a qualidade do vdeo.
Um desses cuidados eliminar interferncias de fundo de cena. Se um palestrante est
falando, o contedo mais importante da cena obviamente o palestrante, e no os objetos ao
fundo. Um fundo com poucos objetos, como uma simples parede lisa, auxilia a codificao do
vdeo e tambm evita disperso de ateno dos participantes que esto assistindo ao vdeo.
Outros cuidados so: evitar movimentos constantes ou bruscos, que tambm dificultam
a codificao de vdeo, e escolher adequadamente as roupas utilizadas, pois, assim como
podem distrair a audincia. Deve ser dada preferncia a roupas de cores slidas.
Projeto de sala
Fatores que devem ser considerados:
11 Natureza da sala e pblico-alvo.

11 Mobilirio e equipamentos.
11 Pblico-alvo.
11 Infraestrutura e layout.
O projeto de uma sala de videoconferncia na maioria dos aspectos um projeto arquitetnico, ou seja, uma tarefa destinada a arquitetos e engenheiros. A funo do profissional de
videoconferncia conhecer o que deve ser levado em conta nessa organizao estrutural
da sala e a disposio adequada dos equipamentos. Portanto, a funo desta seo no
um fundo com muitos objetos, h roupas que dificultam a codificao do vdeo e tambm
abordar todos os detalhes de como projetar uma sala de videoconferncia, mas sim citar
193
os aspectos mais importantes que devem ser considerados durante o projeto com intuito
de melhorar a qualidade da videoconferncia. Os principais fatores que devem ser considerados so: natureza da sala, pblico-alvo, mobilirio, equipamentos e layout.
Natureza da sala e pblico alvo

11 Dedicada x Multipropsito.
11 Aplicaes especiais.
Pblico-alvo:
11 Alunos x Profissionais.
11 Crianas x Adultos.
Conhecer se a sala vai ser dedicada ou no, bem como a utilizao dela por outras pessoas,
traz mais diretivas para a sua correta concepo. Em relao natureza da sala, deve-se
saber ser dedicada para videoconferncias ou se ser uma sala multipropsito. Uma sala
dedicada facilita o projeto, j que pode ser projetada especificamente para as necessidades
de uma videoconferncia. J uma sala multipropsito, ou seja, que ser utilizada para
outros fins alm de videoconferncias, traz maiores dificuldades para o projeto. Neste caso,
deve-se conhecer os requisitos tanto da videoconferncia quanto os do outro propsito
para o qual a sala utilizada e tentar concili-los. Em uma sala de aula que tambm ser utilizada para videoconferncias, por exemplo, deve-se projetar uma sala que acomode todos
os equipamentos de videoconferncia e tambm o mobilirio de uma sala de aula normal,
como classes, quadro, possivelmente computadores, entre outros.
Descrever a natureza da sala especialmente importante quando ela utilizada para
aplicaes especiais, onde pode haver outras exigncias que no esto relacionadas com a
videoconferncia explicitamente. Hoje em dia, a videoconferncia est sendo utilizada cada
vez mais em telemedicina, por exemplo. Nesse caso, equipamentos especficos para visualizao de exames mdicos tambm so requeridos e podem compor a sala. De certa forma,
a mesma relao acontece com o pblico-alvo, ou seja, conhecer o perfil das pessoas que
vo utilizar o sistema tambm pode significar maior qualidade no oferecimento do servio.
Pense na diferena entre uma sala projetada para reunies entre executivos e uma sala de
aula para crianas, por exemplo.
Mobilirio e equipamentos
Mobilirio:
11 Evitar utilizar mveis muito retos e reflexivos que prejudicam a acstica.
11 Cuidar para que os mveis no fiquem na frente dos participantes.

11 Utilizar mveis com cores slidas, pois facilitam a compresso de vdeo.
11 Manter o ambiente limpo, sem muitos objetos pequenos sobre os mveis, a fim
de facilitar a compresso de vdeo.
Equipamentos:
11 Monitores e cmeras de vdeo.
11 Microfones e caixas de som.
11 Cmeras de documentos.
O mobilirio de uma sala de videoconferncia inclui, principalmente, a definio e o posicionamento das cadeiras, mesas e equipamentos necessrios para a videoconferncia.
194
A escolha do mobilirio , em grande parte, apenas uma tarefa arquitetnica. Mas

importante observar os aspectos do mobilirio que influenciam as videoconferncias.
Recomenda-se evitar mveis muito lisos ou fabricados com materiais refletores, como vidro,
gesso, madeira, cermica, pois refletem o som e podem prejudicar a acstica da sala.
Figura 7.13
Tipos de cadeiras.
Cadeiras para plateia
Cadeira tpica para a
Destaque para
Cadeiras tpicas
em auditrio
mesa do conferencista
cadeira com apoio
para plateia
Figura 7.15
Posicionamento dos
equipamentos.
Figura 7.14
Tipos de mesas.
195
Sobre o posicionamento dos equipamentos, j foi comentada a importncia de se manter

os monitores junto s cmeras (para que os participantes estejam sempre olhando para as
cmeras) e de posicionar adequadamente microfones e caixas de som para evitar microfonias. Esses so os fatores mais importantes que devem ser observados em todos os
ambientes de videoconferncia, mas existem outros detalhes que variam conforme o propsito da videoconferncia e os equipamentos utilizados.
Figura 7.16
Exemplo de organizao do ambiente.
A quantidade de pessoas que participam da videoconferncia e o tamanho da sala so

fatores que influenciam na escolha do mobilirio e equipamentos que sero utilizados.
Em um cenrio hipottico de reunio onde 10 pessoas participam em uma mesma sala,
obviamente necessrio que a mesa e as cadeiras sejam suficientes para 10 pessoas, mas
tambm necessrio que os equipamentos escolhidos sejam adequados para essa quantidade de pessoas: a cmera (ou as cmeras) deve ser capaz de filmar todas as pessoas
(e possivelmente possibilitar o foco em cada uma delas), o microfone deve ser capaz de
capturar o som de todos (ou devem ser utilizados diversos microfones), e todos devem ser
capazes de visualizar o vdeo remoto, que influencia na escolha do posicionamento
e tamanho do telo/televiso.
Infraestrutura e layout
Infraestrutura:
11 Tomadas.
11 Pontos de rede wired/wireless.
11 Velocidade da conexo/qualidade da conexo.
11 Layout (disposio dos elementos no ambiente).
Em relao infraestrutura, as necessidades em uma sala para videoconferncia basicamente so: a necessidade de tomadas de energia adicionais bem localizadas (incluindo
tomadas sobressalentes, caso haja a necessidade de mover equipamentos); pontos de rede
adicionais, novamente considerando equipamentos que podem ser movidos e tambm a
ligao de equipamentos adicionais (como notebooks de participantes), ou ento a disponibilizao de redes sem fio e, principalmente, uma infraestrutura de rede com boa qualidade
e uma conexo de alta velocidade com os pontos remotos.
O aspecto mais importante a qualidade e velocidade da estrutura e conexo de rede
existente na sala. A qualidade da videoconferncia altamente dependente da qualidade da
rede de dados. De nada adianta a utilizao dos equipamentos mais avanados de videoconferncia se a rede de dados no suficientemente boa para trfego de dados de videoconferncia. Caractersticas desejadas:
11 Largura de banda um pouco acima da utilizada na videoconferncia (uma videoconferncia a
380 kbit/s no funcionar bem em uma rede com apenas 380 kbit/s; aconselhvel que a rede
seja pelo menos 20% mais veloz para acomodar as flutuaes comuns no trfego multimdia);
196
11 Baixa variao no atraso dos pacotes (jitter);

11 Estabilidade e confiabilidade, isto , uma rede que funcione sem interrupes;
11 Se possvel, que seja uma rede dedicada para a videoconferncia, evitando que picos
de trfegos concorrentes prejudiquem a qualidade da videoconferncia.
Preparao de uma videoconferncia

tarefa do administrador de videoconferncia:
11 Realizar toda a preparao necessria para a videoconferncia.

11 Instruir os participantes sobre como devem se comportar.
11 Gerar as orientaes para conduzir uma videoconferncia.
Quatro etapas so importantes na preparao da videoconferncia:
11 Pr-conferncia.
11 Agendamento.
11 Incio e trmino.
11 Gerenciamento.
Os procedimentos de operao de uma sala de videoconferncia so orientaes para a conduo do processo. importante para o profissional de videoconferncia passar esse tipo de
informao para seus clientes atravs de conversas ou manuais e contratos, caso necessrio.
A maioria das pessoas que no possuem experincia com videoconferncias (e muitas vezes
at mesmo pessoas j com experincia) tendem a se comportar de forma inadequada ao
participar de uma videoconferncia. Por vezes, os participantes esquecem que no esto
na mesma sala dos participantes remotos, e com isso no prestam ateno na forma como
falam ao microfone ou ao posicionamento diante da cmera. Por outro lado, os participantes podem acabar ignorando a presena dos participantes remotos, como por exemplo
no caso de alunos conversando paralelamente em sala de aula em que o professor esteja
em um ponto remoto.
Videoconferncias necessitam de cuidados especiais para que a comunicao ocorra de forma
efetiva. tarefa do administrador da videoconferncia instruir os participantes sobre como
devem se comportar e realizar toda a preparao para que a videoconferncia acontea de
Pr-conferncia
Etapa que antecede a videoconferncia, em que deve ser configurado e preparado o
sistema que ser utilizado. Durante essa etapa, determina-se os participantes envolvidos, seus pontos de acesso, o coordenador da sesso (caso exista) e informaes de
controle de acesso.
preciso identificar as condies para a realizao da videoconferncia, e prever a disponibilidade de banda de cada participante. Nessa etapa todas as informaes relativas
videoconferncia so definidas e descritas.
Etapa que antecede a videoconferncia, em que deve ser configurado e preparado o sistema
que ser utilizado. nessa etapa que todas as informaes relativas videoconferncia
so definidas e descritas, para que, a partir deste momento, a videoconferncia possa ser
facilmente agendada e realizada.
forma satisfatria.
197
Agendamento
Muito importante em videoconferncias para permitir que haja tempo suficiente para
preparao do ambiente de videoconferncia. possvel:

11 Definir data e horrio.
11 Prever a disponibilidade das localidades e dos equipamentos.
11 Definir a equipe de operao.
11 Usar sistemas de agendamento via web.
Assim como uma reunio, aula e atividades similares, uma videoconferncia precisa ser
agendada. O agendamento ainda mais importante em uma videoconferncia do que
em atividades presenciais, para que haja tempo suficiente para preparao do ambiente
de videoconferncia. Alm da definio de data e hora, no agendamento o usurio define
(ou toma conhecimento) das condies para a realizao da videoconferncia. Entre os
aspectos importantes no agendamento, esto:
11 Definir a equipe de operao, se necessria;
11 Prever a disponibilidade da localidade e dos equipamentos (equipamentos da prpria
sala de videoconferncia ou equipamentos externos, como a MCU).
comum o uso de sistemas de agendamento via web (internet ou intranet), sistemas que
atualmente j agrupam todas as tarefas necessrias para o agendamento, inclusive notificam os participantes sobre a videoconferncia.
Incio e trmino da videoconferncia

Incio da videoconferncia:
11 Marcada pela data e horrio definidos na pr-conferncia e aberta assim que a

conexo est estabelecida e o primeiro participante entra na sala.
Trmino da videoconferncia:
11 Demarcado pela sada do ltimo participante da sala (virtual ou real) ou ento
quando o tempo previsto se esgotar.
11 Quando um participante abandona uma sala, os demais participantes devem ser
notificados da sua sada.
O perodo entre o incio e o trmino da videoconferncia obviamente o perodo crtico
durante o qual ocorre a videoconferncia. A videoconferncia s ocorrer de forma devida
se os processos durante a pr-conferncia foram realizados de forma correta. O incio
da videoconferncia marcado pela data e horrio definidos, e ela aberta assim que a
conexo se estabelece e o primeiro participante entra na sala.
198
O trmino da videoconferncia demarcado pela sada do ltimo participante da sala

(virtual ou real) ou quando o tempo previsto se esgotar. Quando um participante abandona
uma sala, os demais participantes devem ser notificados da sua sada.
Gerenciamento
Tarefa do administrador da videoconferncia ou de um participante eleito como
coordenador/moderador. O moderador da sala virtual pode:
11 Autorizar novos participantes na sala.
11 Bloquear o udio de algum participante.
11 Mudar o layout de vdeo.
11 Excluir participantes.
O gerenciamento da videoconferncia feito pelo administrador ou por um participante
eleito como coordenador/moderador da sesso.
Etiqueta e boas prticas

Ao preparar um ambiente para uma videoconferncia importante adotar e evitar
alguns procedimentos de boas prticas.

Em ambiente de videoconferncia, adote:
11 Se voc moderador, chegue mais cedo para testar a configurao do sistema, evitando
perda de tempo durante o perodo destinado conferncia.
11 importante falar um de cada vez, para no interromper os outros e no mudar o
foco da tela.
11 Desative o microfone quando no estiver falando, para evitar mudanas de tela desnecessrias e impedir a captao de rudos indesejados.
11 Fale com voz alta e clara.
11 Espere o dobro do tempo habitual aps perguntas e comentrios, a fim de dar tempo
para que sua fala chegue aos alunos.
11 Repita comentrios, se necessrio.
11 Mantenha uma posio apropriada diante da cmera.
11 Mantenha o contato visual com a lente da cmera e, caso existam, com os participantes locais.
11 Lembre-se de que os participantes remotos esto lhe vendo e preste ateno em como
todos iro v-lo. Coloque os participantes dentro do campo de viso da cmera.
11 Vista roupas de preferncias de cores slidas ou padres escuros ou neutros.
11 Tenha em mente que sua audincia deve ter o foco em voc e no na sua roupa.
11 Prefira usar roupas, maquiagem e cabelos do modo mais simples possvel. No mximo
tenha em mos um p translcido para tirar o brilho do nariz e das tmporas. A melhor
opo por um visual natural e relaxado.
199
(b)
(a)
Figura 7.17
Adote fundos lisos,
para evitar distraes e colaborar
com a codificao.
Em aulas remotas, adote:

11 O professor deve dirigir-se aos participantes remotos pelo nome e lugar onde esto; para
tanto, indicado preparar uma lista e um mapa dos assentos.
11 Comece as aulas com uma introduo informal, falando com todos os alunos de modo a
iniciar o teste do udio deles e o seu prprio.
11 O professor precisa se posicionar para a cmera, buscando estar sempre bem iluminado e enquadrado, nunca caindo da tela nem cortando partes de seu corpo, exatamente como na televiso.
Em ambiente de videoconferncia, evite:
11 Uma vez que tudo esteja pronto, evite a distrao de fazer ajustes e perturbar os outros
com perguntas do tipo: Voc est me ouvindo?
11 Vozes que interrompem bruscamente so desagradveis.
11 Produzir barulho que possa perturbar a reunio (conversas paralelas, barulho com
dedos, canetas etc.), pois a cmera e os microfones so muito sensveis e capazes de
captar os sons mais sutis.
200
11 Diminuir o volume da voz no final da fala.

11 Comear a falar antes de ser focalizado pela cmera.
11 Erros gramaticais, grias e vcios de linguagem.
11 Usar jargo tcnico quando o assunto no for do escopo da reunio (plateia no especializada ou pblico leigo).
11 Falar sem uma preparao prvia.
11 Falar muito depressa ou muito devagar.
11 Movimentos rpidos e/ou largos que causem distoro na tela. Evite movimentao
desnecessria para preservar a qualidade da imagem.
11 Expresses faciais inadequadas. Use o zoom, mas no se aproxime demais da cmera.

11 Ficar esttico ou andar nervosamente de um lado para o outro.
11 Fumar, mascar chicletes, chupar balas, brincar com objetos (chaveiros, canetas).
11 Vestir-se inadequadamente.
11 Vestir roupas totalmente pretas, ou com listras finas, de cores berrantes ou com
estampas contrastantes. Evite o tweed, riscas ou outros padres muito pequenos.
11 Usar joias, colares ou braceletes grandes, pois podem bater no microfone e causar
rudos estranhos.
11 Distraes visuais como maquiagem inapropriada, fundos carregados, padres complicados ou cores fortes. Evite o vermelho, cores brilhantes ou saturadas.
11 Microfones de lapela no so indicados com suteres e camisetas.
Estudo de caso 1: Auditrio

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

Principal aparelho
de videoconferncia
Plpito
Projetor multimdia
Telefone/Fax
Degraus
202
Monitor de retorno
xado ao teto 38
Cmera
auxiliar
Monitor principal
xado ao teto 38
Figura 7.19
Exemplo da planta
de um auditrio para
videoconferncia.
Estudo de caso 2: Sala de reunio

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

O terceiro estudo de caso aborda uma sala de propsito geral, onde podem ser realizadas
videoconferncias para reunies, aulas e palestras, entre outros.
11 Natureza da sala: 20 a 35 pessoas (sala de aula/multipropsito).
11 Pblico-alvo: estudantes, profissionais etc.
11 Mobilirio: mesas e cadeiras apropriadas.
11 Equipamentos:
22 udio: dois ou vrios multidirecionais;
22 Vdeo: TV de 42 ou projetor;
204
22 Videoconferncia: hardware especfico compatvel com a conectividade disponvel;

22 Adicionais: cmera auxiliar, computador, cmera de documentos.
Figura 7.21
Esboo da planta
de uma sala
de reunies com
videoconferncia.
11 Layout: rea: ~ 54 m.
Figura 7.22
Sala de
videoconferncia de
propsito geral.
Tela eltrica de projeo
Quadro branco
TV 54
Tablado com 10 cm
Equipamento de
videoconferncia
PC
Projetor
multimdia
Cmera de documentos
Telefone/Fax
Cadeira com apoio

para escrita
Figura 7.23
Esboo da planta
de uma sala de
videoconferncia de
propsito geral.
Piso com elevao

de 0,5 cm
Cortina
Janela
Estudo de caso 4: Projeto da sala da ESR-RS

Este estudo de caso mostra o projeto de adaptao da sala de aula da ESR em Porto Alegre,
que originalmente era uma sala de aula padro da ESR e foi transformada em uma sala de
videoconferncia para transmisso das aulas ministradas nela para outras salas de aula da
Escola Superior de Redes de outros estados. Este trabalho foi realizado no mbito do projeto
Circulao
Parede ou
divisria acstica
Turmas Distribudas.
205
O projeto considerou diversos fatores, entre eles:

11 Adequao esttica geral;
11 Organizao do espao;
11 Ajuste cnico para vdeo;
11 Iluminao;
11 Acstica;
11 Planos de cmera/operao;
11 Sonorizao.
A sala de aula original possua diversas caractersticas prejudiciais videoconferncia, entre elas:
11 Sala branca de perfil frio;
11 rea de trabalho dos alunos sem otimizao de espao;
11 Paleta: branco, preto e creme;
11 Iluminao fria (lmpadas fluorescentes) e plana;
11 Grande janela esquerda com cortina blackout;
11 Painis de Eucatex com perfis aparentes (desalinhados);
11 P direito baixo.
Figura 7.24
Mesas e mquinas
dos alunos e janela
com cortina
blackout.
206
Figura 7.25
Entrada da sala de
aula mostrando um
pedao do quadro
branco e divisria.
A proposta geral de modificaes da sala tem como principais mudanas:

11 Inverte posio da sala (porta passa a ficar no fundo da sala);
11 Frente ganha pintura dgrad, em tons mais vivos;
11 Troca dos aparelhos de ar-condicionado por modelos mais silenciosos;
11 Parte do teto mantida branca, para reduzir a sensao de teto baixo;
11 Paredes e parte do teto com isolamento acstico.
recomendado deslocar os computadores para baixo da mesa e trocar para monitores
Figura 7.26
Proposta geral para
reforma da sala.
Na sequncia sero descritos separadamente os itens mais importantes do projeto.
Acstica
Antes:
11 reas reflexivas em todas as paredes.
11 Nenhum trabalho de correo acstica (mesmo cortina blackout tem perfil reflexivo).
11 Caractersticas de ambincia (soma de todos os sons nesse ambiente) so desfavorveis para o sistema.
11 Ar-condicionado com rudo excessivo.
maiores, de preferncia com ajuste de altura.
207
Depois:
11 Troca dos aparelhos de ar-condicionado.

11 Painis Sonare (Isover) passam a revestir as paredes, lateral direita e fundo.
11 Teto revestido com isolamento acstico e trmico (sobre o forro).
Resultados:
11 Reduo imediata da reflexo em duas paredes (supresso da reverberao).
11 Melhora da ambincia.
11 Melhorias no isolamento acstico e trmico.
11 Ganhos nos resultados acsticos (reduo da reflexo nas frequncias mais altas gera
som mais encorpado, com agudos mais limpos).
11 Melhorias estticas no ambiente.
Figura 7.27
Painis nas paredes
melhoram a acstica da sala.
Planos de cmera/operao
11 Ambiente de operao frente e esquerda, concentrando as mquinas necessrias
para o sistema de videoconferncia.
11 Telepresena televises posicionadas ao lado do professor ou no fundo da sala.
208
Cmera robotizada 1
11 Principal foco no apresentador e sua rea de trabalho.
11 Enquadramento tem bom acesso visualizao da rea frontal.
11 Fcil acesso visualizao do quadro branco e da lousa eletrnica.
11 Posicionamento permite bom alcance de zoom.
11 ngulo da cmera permite captar quadro branco sem incidncia de reflexos.
Figura 7.28
Ambiente de operao do sistema de
videoconferncia
e televises para
telepresena.
Figura 7.29
Primeira cmera
robotizada com foco
no professor e no
quadro branco.
Cmera robotizada 2
11 Posicionamento voltado aos alunos.
11 Foco secundrio no apresentador, podendo funcionar como cmera de apoio, quando

o apresentador est no meio da sala, por exemplo.
11 Fcil visualizao de todo o ambiente presencial (alunos).
11 Uso das 6 posies de preset permite fcil enquadramento de qualquer grupo de
alunos, pressionando uma nica tecla.
Figura 7.30
Segunda cmera
robotizada com
foco nos alunos.
Sonorizao
11 Combinao de microfones sem fio (headset e de mo).
11 Mesa de som.
11 Caixas acsticas:
22 Cobertura dos sinais de entrada.
A combinao de microfones sem fio (headset e de mo) com mesa de som e caixas acsticas, faz cobertura dos sinais de entrada e reproduo de sinais remotos aos participantes
presenciais. Microfone sem fio para o professor e de mo para os alunos.
Figura 7.31
Microfones e
posicionamento das
caixas acsticas.
22 Reproduo de sinais remotos aos participantes presenciais.
209
Imagens da sala nova

A viso frontal da sala pode ser vista a seguir.
Figura 7.32
Mobilirio (posicionamento dos
equipamentos).
A imagem a seguir mostra a viso do fundo, com as TVs, o novo ar-condicionado e o
posicionamento da cmera.
210
Figura 7.33
Viso do fundo
da sala.
Atividade 1 Anlise de cenrios e elaborao do projeto das salas
Esta atividade consiste na anlise de diferentes cenrios onde necessrio o uso de videoconferncia e na elaborao de projetos de salas que possam ser utilizadas nos ambientes
apresentados em cada cenrio. Sero apresentados 3 cenrios.
Cenrio 1
Uma empresa multinacional est implantando um sistema de videoconferncia para auxiliar
na tomada de decises entre gerentes e funcionrios de suas unidades. So realizadas
aproximadamente 10 reunies semanais entre os gerentes das 3 unidades e entre gerentes
com seus coordenadores. As reunies contam com aproximadamente 2 pessoas de cada
unidade, num mximo de 6 pessoas por reunio. Um dos requisitos da empresa efetuar a
integrao de documentos no digitais; outro requisito a possibilidade de enviar apresentaes de slides em formato digital.
Cenrio 2
Uma escola particular est instalando um servio indito para promover o compartilhamento de conhecimento. O convnio assinado pela escola com uma comunidade carente da
periferia prev uma sala de videoconferncia como meio de incluso digital. As crianas da
comunidade tero acesso a aulas, palestras e atividades de entretenimento com as crianas
da escola. A ideia compartilhar conhecimento e experincias entre crianas com idade
entre 6 e 9 anos.
Cenrio 3
Uma escola deseja reformar uma sala de aula convencional para abrigar equipamentos de
um sistema de videoconferncia. A sala possui um projetor multimdia, 50 cadeiras com
apoio, uma TV de 29 polegadas e janelas laterais, estando localizada no lado de maior circulao da escola. Possui cabeamento e ar-condicionado, j tendo sido utilizada para abrigar
um laboratrio de informtica. A escola atende ao ensino fundamental e deve disponibilizar
o servio de videoconferncia para todos os alunos, com agendamento prvio.
Cenrio 4
Um grande hospital-escola na rea de cirurgia tem como objetivo trocar informaes com
dois outros hospitais parceiros. Os trs hospitais possuem residncia mdica. Existem duas
11 Um mdico especialista transmitir sua cirurgia em alta definio para os outros hospitais (incluindo udio) para que mdicos e alunos remotos possam aprender sua tcnica.
Nesse caso, h a necessidade de interao com udio e vdeo em tempo real;
11 Possibilitar que um preceptor especialista em qualquer um dos hospitais possa orientar
um cirurgio residente remotamente; para isso ele deve ter acesso completo a trs
cmeras de alta definio no mnimo (videolaparoscpio, corpo do paciente e ambiente
da sala cirrgica). Alm disso, ele deve transmitir sua imagem. Os hospitais esto locali-
necessidades principais:
211
zados em diferentes estados do pas, embora ligados atravs de um backbone de redes

que permite velocidades de at 100Mbit/s.
Cenrio 5
Um grupo de mdicos localizados em diferentes reas com banda 3G (de aproximadamente
300 kbit/s) formou um grupo de trabalho sobre sua especialidade. Eles precisam se comunicar a partir de seus escritrios de forma simples, em reunies que consistem basicamente
da transmisso de vdeo e udio de todos, compartilhamento de bloco de notas e apresen-
tao de slides e vdeos.
212
8
Oferecer ao aluno uma viso ampla sobre os conceitos e tecnologias empregados
para streaming e gravao de videoconferncia.
conceitos
Streaming de vdeo versus download progressivo, solues de transmisso e

gravao de videoconferncia, banda na rede ocupada de acordo com o nmero
de usurios, necessidade de armazenamento de acordo com a qualidade da gravao.
Streaming de vdeo
11 Streaming uma forma de transmisso de dados multimdia, em que os clientes
realizam uma solicitao dos dados para um servidor de streaming, e os dados so

exibidos medida que so recebidos. Pode ser aplicado para transmisses ao vivo ou
para mdias gravadas.
Transmisses de televiso e rdio so exemplos de transmisses de mdia por
streaming broadcast.
A combinao do streaming com videoconferncia pode ser feita para:
11 Disponibilizar a videoconferncia para um maior nmero de pessoas.
11 Transmitir a videoconferncia aps ela ter acontecido, a partir de gravao.
11 Visualizar uma videoconferncia a partir do desktop utilizando players padro como
Windows Media, QuickTime ou navegador web.
11 Facilitar a gravao: um dispositivo (ou software) recebe a videoconferncia por
streaming e realiza a gravao.
A grande desvantagem do streaming em videoconferncias a interao, pois um participante por streaming no pode interagir ao vivo na videoconferncia, porque a entrega
das mdias ocorre em apenas uma via. possvel amenizar o problema permitindo a
participao desses clientes por salas de chat ou por e-mail, por exemplo.
Transmisses por streaming so normalmente associadas a transmisses ao vivo, onde no
h possibilidade de pausar o vdeo e continuar assistindo-o do ponto onde foi pausado.
Porm, tambm pode ser utilizado para transmisso de mdias j gravadas. Uma pausa
em uma transmisso por streaming faz com que o servidor pare de transmitir dados para
o cliente, o contrrio do que acontece com transmisses utilizando download progressivo,
conforme ser visto adiante.
Outra caracterstica importante do streaming que ele permite a adaptao da dinmica da
qualidade da transmisso conforme a capacidade dos clientes. Ou seja, se um cliente est
Captulo 8 - Transmisso via streaming
objetivos
Transmisso via streaming
recebendo vdeo com uma qualidade alta, por exemplo, e comea a acusar perda de dados
213
na transmisso, a prpria transmisso detecta essas perdas e faz com que a qualidade do
vdeo seja reduzida para evitar as perdas. Para isso, o servidor obviamente deve suportar a
adaptao dinmica da qualidade. Transmisses de televiso e rdio so exemplos de transmisses de mdia por streaming (e broadcast).
A combinao do streaming com videoconferncia pode ser realizada para diversos propsitos. O principal propsito disponibilizar a videoconferncia para um maior nmero de
pessoas. Transmisses por streaming so naturalmente mais escalveis do que os prprios
sistemas de videoconferncia, ou seja, mais otimizado que diversos clientes recebam a
videoconferncia por streaming do que permitir que se conectem diretamente ao sistema
de videoconferncia. Alm disso, transmisses por streaming utilizam protocolos padro,
e podem ser visualizadas em diversos aplicativos (players de vdeo), como Real, Windows
Media, QuickTime ou mesmo o navegador web.
O streaming tambm pode ser utilizado para transmitir a videoconferncia aps sua ocorrncia (a partir de uma gravao) ou at mesmo para facilitar a gravao: um dispositivo
recebe a videoconferncia por streaming e realiza a gravao.
Streaming pode aumentar a utilidade de uma videoconferncia, se a audincia da reunio
for maior que o nmero de conexes simultneas suportadas pelo sistema utilizado. Nesse
caso, participam interativamente apenas as pessoas principais da videoconferncia; os
demais podem acompanhar a reunio recebendo o fluxo de mdias em um player.
A grande desvantagem do streaming em videoconferncias em relao interao entre os
participantes. Um participante por streaming no pode interagir ao vivo na videoconferncia,
pois a entrega das mdias ocorre em apenas uma via (s recebe dados, sem enviar). possvel
amenizar este problema permitindo a participao dos clientes em salas de chat ou por e-mail.
Streaming x Download progressivo

Debate sobre vantagens e desvantagens de ambos:
11 Qual ocupa mais espao em disco?

11 Qual permite analisar novamente partes j assistidas?
11 Qual possui a melhor qualidade de udio e vdeo?
Streaming e download progressivo so duas formas utilizadas para transferncia de udio e vdeo.
O download progressivo uma forma de transmisso que se assemelha a um download
tradicional, porm os dados de udio e vdeo so transferidos progressivamente para o
computador, permitindo que se possa visualizar o contedo j recebido mesmo que ainda
no tenha recebido todos os dados.
Apesar de diferentes, o download progressivo e o streaming possuem muito em comum.
214
As particularidades das aplicaes do cliente tambm influenciam na diferenciao entre

streaming e download progressivo. Uma aplicao de streaming pode, por exemplo, armazenar o vdeo e permitir que o usurio navegue nos dados recebidos, o que conceitualmente
s pode ser feito com download progressivo.
A tabela a seguir compara os principais aspectos das duas tecnologias:
Figura 8.1
Principais aspectos
de streaming
e download
progressivo.
Streaming
Download
progressivo
Armazena vdeo temporariamente

no cliente
No*
Sim
Permite voltar para determinado

ponto do vdeo
No**
Pausa e interrompe a transmisso
Sim
No
Pode mudar a qualidade dinamicamente, se adaptando rede
Sim
No
Adequado para eventos ao vivo
Sim
No
Adequado para podcast
No
Sim
Permite multicast
Sim
No
(mas o software cliente pode

armazenar)
Sim
(solicita de novo o streaming ao

servidor via outro ponto do vdeo)
Tanto multicast quanto unicast podem ser utilizados para streaming de contedo multimdia. As diferenas entre eles j foram discutidas. Os principais aspectos que devem ser
considerados na escolha da tecnologia mais adequada esto na tabela seguinte.
Unicast
Multicast
Transmisso ao vivo
Transmisso sob demanda
Permite escalabilidade (banda requerida se

mantm com o nmero de usurios)
Solues para transmisso e gravao

Existem solues em hardware e em software. Solues em hardware costumam ser
especficas para videoconferncia. J solues baseadas em software so mais genricas, pois so solues para streaming e gravao de dados multimdia.
As solues em hardware incluem uma interface H.323/SIP para interagir diretamente com a
videoconferncia e outras interfaces para servir os dados por streaming. O dispositivo funciona
removendo o vdeo e o udio do pacote H.323/SIP, e os empacotando novamente no formato
streaming configurado, como QuickTime, Real ou Windows Media. Esses dados so enviados
aos usurios que solicitam uma transmisso streaming, utilizando unicast ou multicast.
Alguns dispositivos podem tambm gravar esses dados, podendo depois fornecer acesso sob
demanda ao contedo. Alm disso, alguns modelos suportam inclusive a transmisso e gravao
de mais de uma sesso de videoconferncia ao mesmo tempo. As solues em hardware so
referenciadas tambm como all-in-one devices ou VideoConference Recorder (VCR).
H diversos dispositivos em hardware disponveis no mercado para streaming e/ou gravao de videoconferncias. Abaixo so citados alguns modelos, mas o ideal conferir com
os fabricantes os ltimos lanamentos.
Figura 8.2
Principais aspectos
do unicast
e multicast.
Caracterstica
215
Modelos que suportam apenas transmisso de videoconferncia:

11 MCUs VCON VCB, Codian (sries 4200 e 4500);
11 Endpoints Polycom VSX, Tandberg 880 e 990 MXP (somente multicast).
Figura 8.3
Modelos em
hardware que
suportam apenas
transmisso de
videoconferncia.
Modelos que suportam transmisso e gravao:

11 Starbak VCG Creation / Starbak Encoder;
11 MCU Codian MSE8000;
11 Codian VCR srie 2200;
11 Tandberg Content Server.
Figura 8.4
Modelos em
hardware que
suportam transmisso e gravao
de videoconferncia.
H empresas que disponibilizam dispositivos de transmisso e gravao juntamente com um

conjunto mais completo de equipamentos, fornecendo uma soluo completa para videoconferncia. Um exemplo a famlia de produtos Integrated Network Video (INV) da Starbak.
O objetivo dos equipamentos integrar de forma fcil os diversos sistemas multimdia que
uma instituio pode ter: videoconferncia, streaming, televiso por IP, entre outros.
J as solues baseadas em software normalmente so mais genricas, voltadas para streaming
e gravao de dados multimdia em geral, podendo tambm ser utilizadas para os dados de
uma videoconferncia.
216
Solues baseadas em software

No lugar de um dispositivo de hardware dedicado, utilizada uma aplicao que pode
ser instalada em um computador desktop tradicional. O desempenho da aplicao fica,
obviamente, dependente do desempenho da mquina na qual est instalada.
Essas solues normalmente so compostas por dois softwares distintos utilizados
em conjunto:
11 Encoder: entidade que captura os dados, codifica e os envia para o servidor.
11 Servidor: responsvel pela distribuio e gravao dos dados que recebe do encoder.
Solues hbridas (soluo em software que recebe sinal de um HW de videoconferncia):
11 Necessidade de alguma forma de conexo do software videoconferncia.

22 A sada de A/V de um terminal de videoconferncia pode ser conectada a uma entrada
da mquina onde a soluo est instalada (como se fosse uma cmera de vdeo)
A visualizao do fluxo de mdias pelos usurios realizada atravs de um player padro
compatvel com o protocolo de streaming utilizado. Players como Windows Media Player e
VideoLAN (VLC) suportam e podem exibir diversos formatos de streaming. Alm do streaming,
na maioria dos softwares o contedo tambm pode ser gravado e disponibilizado para
acesso sob demanda.
Exemplos de solues baseadas em software:
11 Windows Media Server/Windows Media Encoder;
11 Helix Server/Real Producer;
11 Flash Server/Flash Encoder;
11 QuickTime;
11 VideoLAN (VLC);
11 xConference: comercializado com duas placas de captura e computador:
11 o cliente j recebe o computador com os recursos instalados e configurados.
Existem tambm solues hbridas, onde desejvel transmitir via software uma videoconferncia H.323 executada em hardware. Como est sendo utilizada uma mquina convencional para a instalao do software, normalmente no h uma interface H.323/SIP pronta
para receber os dados de uma videoconferncia e repass-los para a aplicao. Portanto,
necessrio fazer com que, de alguma forma, os dados de uma videoconferncia cheguem
at a aplicao para streaming e gravao.
Com a existncia de um dispositivo de videoconferncia, sua sada de udio e vdeo pode
ser conectada a uma entrada da mquina onde a soluo est instalada (a uma placa de
Figura 8.5
Integrao de
servidores de
streaming em uma
videoconferncia.
captura, por exemplo, como se fosse uma cmera de vdeo). Com isso possvel indicar ao
Encoder que obtenha os dados desta entrada e os envie para o servidor.
A imagem seguinte mostra um diagrama geral de funcionamento dos servidores de streaming
quando conectados a uma videoconferncia:
1. Conecta-se a sada auxiliar

do terminal na mquina
onde est o codicador
Codicador
2. O codicador congurado
para enviar os dados
codicados para o servidor
3. Usurios acessam a transmisso

atravs de uma URL
Usurio assistindo sesso

a partir de um player
Servidor
Endpoint
217
Conforme a imagem, o codificador conectado diretamente a um equipamento que est

participando da videoconferncia. Normalmente os equipamentos possuem uma sada
auxiliar que pode ser utilizada para conect-lo a uma mquina que possuam uma placa
de captura. Este codificador ento integrado ao servidor que disponibilizar o vdeo por
streaming para os clientes.
Requisitos principais para streaming e gravao

11 Streaming: processamento, memria e principalmente largura de banda.
11 Memria: quanto maior, maior a capacidade do servidor (mais usurios); atualmente

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

Possuem duas aplicaes como base do sistema:
11 Codificador.
11 Servidor.
Nos sistemas atuais temos:
11 Windows Media Services e Windows Media Encoder.
11 Helix Server e Real Producer (h uma verso open source: Helix DNA Server).
Figura 8.7
Exemplos de espao
requerido para o
armazenamento de
arquivos de mdia.
Taxa de transmisso
219
11 Flash Media Server e Flash Media Encoder (Red 5 um servidor de streaming open
source similar ao Flash Server).

11 QuickTime Streaming Server e QuickTime Broadcaster (o equivalente open source o
Darwin Streaming Server).
Com alguns sistemas possvel utilizar mltiplos servidores para melhorar o desempenho. Quanto visualizao do streaming, solues costumam prover um player padro:
11 Windows Media Player.
11 Real Player (para Helix).
11 Flash Player.
11 QuickTime.
11 VLC um player que suporta a maioria dos protocolos e formatos.
Sistemas de streaming normalmente tambm suportam serem servidores de vdeo sob
demanda (VOD). Neste caso, no necessrio um codificador, pois os vdeos que sero
disponibilizados so colocados em um diretrio e o servidor de streaming disponibiliza o
acesso a eles.
Servidores de streaming mais conhecidos:
11 Windows Media Services, da Microsoft;
11 Helix Server, da Real;
11 Flash Media Server, da Adobe;
11 QuickTime Streaming Server, da Apple.
Todas essas solues de streaming no so compostas por apenas um software, mas pelo
menos por dois para gerao do contedo e streaming, e um para visualizao. As duas aplicaes para gerao do contedo tm funes semelhantes em todas as solues. So elas:
11 Codificador: entidade que faz a captura (seja de uma cmera, de arquivos ou outra fonte)
e codificao dos dados. Chamado Encoder na maioria dos sistemas;
11 Servidor: recebe os dados do codificador e responsvel pela sua distribuio, ou seja, o
streaming dos dados.
Codificadores e servidores nas solues citadas:
11 Windows Media Services e Windows Media Encoder;
11 Helix Server e Real Producer;
11 Flash Media Server e Flash Media Encoder;
11 QuickTime Streaming Server e QuickTime Broadcaster.

Essas solues so comerciais (pagas). Mas importante citar que existem verses de
cdigo aberto e livres para as solues Helix e Flash.
A verso open source do Helix chamada Helix DNA Server (a verso comercial tambm
conhecida por Helix Universal Server). Ela possui menos funcionalidades e suporta menos formatos do que a verso comercial, mas ainda assim possui as diversas funcionalidades bsicas
necessrias para o streaming. Em relao ao Flash, h uma verso open source chamada Red5,
que no diretamente associada ao Flash Media Server, como o Helix. Red5 vinculado ao
Flash Server por utilizar protocolos e formatos semelhantes, como RTMP e FLV. J a aplicao
open source equivalente ao QuickTime chamada de Darwin Streaming Server. Desenvolvida
pela Apple, seu cdigo foi criado com base no QuickTime Streaming Server.
220
Outra observao importante sobre as solues que algumas so vinculadas a apenas um

sistema operacional, o que pode dificultar o seu uso. O Windows Media Services s pode ser
utilizado no Microsoft Windows Server 2003, enquanto o QuickTime Streaming Server s
pode ser usado no OS X Server. As verses open source, porm, costumam suportar mais
sistemas operacionais: o Darwin, por exemplo, pode ser executado em diversos sistemas
operacionais, incluindo Windows, Linux e Mac OS.
Com alguns sistemas possvel utilizar mltiplos servidores para melhorar o desempenho
quando se deseja atender muitos usurios. A imagem seguinte mostra um exemplo onde
so utilizados diversos servidores Windows Media Server e onde pode ser feito um balanceamento de carga entre eles.
Windows Media
Player
Network load balancing
Windows Media
Player
Internet
Windows Media
Encoder
Windows Media
server
Windows Media
server
Windows Media
Player
Windows Media
server
Windows Media
Player
Figura 8.8
Servidores Windows
Media Server
com balanceamento
de carga.
Player
A visualizao do streaming feita atravs de um player de mdia, que varia conforme a
soluo de streaming utilizada, ou, mais especificamente, de acordo com o protocolo e os
formatos/codecs utilizados. Diferentes sistemas utilizam diferentes protocolos e formatos,
mas todos possuem um player associado soluo:
11 Windows Media Server: Windows Media Player;
11 Helix Server: Real Player;
11 Flash Media Server: Flash Player (normalmente utilizado na web);
Windows Media
11 QuickTime Streaming Server: QuickTime.

221
Alm dos players associados s solues, podem ser utilizados players de mdia genricos,
desde que suportem os protocolos e formatos utilizados. Um exemplo o VideoLAN (VLC),
um player que suporta a maioria dos protocolos e formatos utilizados.
A tabela a seguir mostra uma comparao entre os containers, formatos de udio e vdeo e
protocolos utilizados em cada uma das solues citadas:
Flash
Helix
Windows
Apple
Container
FLV
Real Media file format,

ASF, 3GP, AVI
ASF
MOV
Vdeo
VP6, H.264
Theora, Real Video,

WMV, H.264
WMV
MPEG-4, H.264
udio
AAC, MP3
Vorbis, AAC, MP3
WMA, MP3
AAC
Protocolo
RTMP
RTSP
MMS
RTSP
Na tabela foram colocados apenas os itens mais significativos de cada sistema. H sistemas
como o Helix, principalmente, que suportam diversos formatos alm dos citados. Esta
tabela vlida para as verses pagas dos sistemas. A verso open source do Helix possui
suporte a menos formatos e containers, mas as verses open source do Flash e QuickTime
so bastante equivalentes com a tabela.
Alm do streaming e gravao, os servidores de streaming normalmente tambm suportam
vdeo sob demanda (VOD). Neste caso, no necessrio um codificador: os vdeos que sero
disponibilizados so colocados em um diretrio e o servidor de streaming disponibiliza o
acesso a eles, seja por streaming ou por download progressivo.
222
Figura 8.9
Comparao
entre os containers
(formato de
udio/vdeo).
w
Para uma comparao
detalhada dos sistemas
de streaming, visite na
Wikipedia a pgina com
os diversos formatos e
protocolos suportados
por cada soluo:
Comparison of
streaming media
systems.
Atividade 1 Utilizao do Windows Media Server
O servidor Windows Media Server (WMS) ser utilizado para fazer essa atividade prtica, em
que o instrutor vai configurar um ponto de publicao no WMS, que ser utilizado para os
alunos publicarem o contedo ao vivo gerado pelo codificador Windows Media.
Atividade 2 Transmisso de contedo com a sute Flash Media

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

Aps instalados os aplicativos necessrios, cada aluno dever executar os passos listados a
seguir. Depois sero dadas dicas para a correta execuo das atividades.
Efetue os testes a seguir:
11 Testar transmisso ao vivo, capturando da webcam e transmitindo;
11 Testar vdeo sob demanda (VOD);
11 Trabalhar em duplas: um aluno transmite e o outro recebe.
Explore o codificador:
11 Modificar as taxas de codificao de vdeo;
11 Incluir mais de uma qualidade (so suportados diversos fluxos);
11 Testar a gravao em arquivo.
vidor. Consulte as estatsticas quando os clientes se conectam.

Para acesso de outras mquinas e redes, observe as portas utilizadas e a liberao
via firewall.
Visualize o console de administrao, normalmente no mesmo grupo da instalao do ser-
223
224
9
Permitir ao aluno experimentar diversos aplicativos de webconferncia, reforando
os conceitos tericos estudados e comparando as diferentes solues.
conceitos
Conferncia web (webconferncia), modelos de servio de webconferncia, solues

proprietrias (Adobe Connect, Cisco WebEx, FuzeMeeting, Google hangout) e solues
de cdigo aberto (Mconf, Big Blue Button, OpenMeetings).
Conferncia Web (webconferncia)

Utiliza-se o navegador para efetuar a videoconferncia. Vantagens:
11 A grande vantagem a facilidade de uso.

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

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

Aluguel de salas de videoconferncia:
11 Aluga-se todo o ambiente, incluindo as salas onde os participantes estaro.

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

Diversas empresas possibilitam o aluguel de salas de videoconferncia como uma forma
de reduzir custos de outras empresas; a vantagem nesta modalidade de servio que a
companhia que necessita do servio no precisa adquirir equipamentos ou profissionais
especializados na tecnologia, negociando diretamente com empresas que j possuem a
estrutura pronta e oferecem suas salas. As pessoas devem se deslocar at essa sala, o que
pode ser bom em termos de foco, mas definitivamente exige mais tempo. Normalmente so
as solues mais caras, mas tambm as menos trabalhosas.
Outro modelo aproveitar o conceito de sala virtual utilizado em webconferncias. Uma vez
que no sistema de conferncia web as reunies so realizadas em computadores pessoais
de usurios sem necessidade de equipamentos ou softwares especficos para este fim,
possvel alugar apenas o servidor de webconferncia.
Muitas provedoras de servios oferecem esta possibilidade, entre elas a Adobe, com o
Adobe Connect, e a Cisco, com o Cisco WebEx. Os usurios normalmente pagam uma tarifa
mensal para acessar o servio, com valores variando conforme a qualidade do servio
(quantidade de usurios, qualidade de udio e vdeo etc.) e os servios adicionais aos quais
Aluguel de servidores de salas virtuais
se deseja ter acesso (gravao, armazenamento etc.).

227
Neste modelo, a aplicao cliente costuma ser de graa. Contratando o servio que disponibiliza o servidor, os usurios podem simplesmente acessar um determinado website e
atravs dele acessar as conferncias.
Instalao local (on-site)

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

H diversas solues, a maioria delas proprietrias, que buscam o mesmo conjunto de
funcionalidades, como:
11 Comunicao com udio e vdeo (cada vez se busca maior qualidade e adaptao
capacidade de rede do cliente).
11 Capacidade de suportar o maior nmero possvel de clientes.
11 Chat.
11 Quadro branco interativo.
11 Compartilhamento de desktop.
11 Apresentaes (formatos como PDF, PPT e outros).
11 Gravao.
11 Suporte a diversos sistemas operacionais.
Nesse captulo sero mostradas imagens dos aplicativos como referncia, para
dar uma ideia da soluo. Porm, sabemos que a interface com o usurio muda
medida que novas verses so lanadas. Recomenda-se o teste das solues nos
sites dos fabricantes para experimentar a verso mais recente.
Existem diversas solues de webconferncia, sendo a maioria delas solues proprietrias

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

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

pods, inclusive sua organizao na interface. A organizao dos pods na tela tambm pode
ser feita atravs de layouts, que sero descritos mais adiante. A verso 8 do Adobe Connect
introduziu diversas melhorias na interface, visando facilitar o uso da ferramenta. Os componentes foram reorganizados, como pode ser visto na imagem seguinte, e foram includas
novas funes como arrastar e soltar.
Figura 9.2
Interface do Adobe
Connect 8.
Papis (permisses) dos usurios

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

O Adobe Connect permite interao atravs de udio e vdeo. No possui um limite de
cmeras por sesso: o limite dado pela banda de rede. Suporta praticamente qualquer
modelo de webcam reconhecido pelo sistema e tambm outros tipos de cmeras (como
cmeras DV).
Para compartilhar udio e vdeo necessrio primeiro permitir que a aplicao tenha acesso
sua cmera e a seu microfone. O pod de vdeo possui um boto para isso. Assim que
pressionado, exibida a tela padro do Flash para que o usurio permita que o Flash acesse
seus dispositivos (ou apenas um deles). Permitindo o acesso, o vdeo do usurio passa a ser
transmitido para todos os participantes.
Figura 9.4
Pod utilizado para
habilitar vdeo
e udio.
Habilitar cmera e telefone

O udio, porm, s comea a ser transmitido quando o usurio habilitar outra opo. Fora
do pod de vdeo h o boto exibido na figura abaixo, que permite que o usurio habilite a
transmisso de seu udio quando estiver falando.
Flash Media Encoder
Fixar microfone
Uma das maiores crticas ao Adobe Connect sempre foi a qualidade mediana dos vdeos,
muito inferior aos sistemas de desktop e em hardware que suportam alta definio. Na
232
verso 8, porm, o Adobe Connect melhorou a qualidade de vdeo e udio, suportando

inicialmente resolues de at 640x480. Alm disso, foram includos outros detalhes
importantes, como a capacidade de visualizar o seu vdeo antes de inici-lo e a integrao
com sistemas que utilizam SIP.
Compartilhamento de documentos, tela e quadro branco

Tanto o compartilhamento de documentos, de tela (incluindo controle remoto) e quadro
branco so funcionalidades disponibilizadas no pod de compartilhamento. Este pod ocupa
grande parte da aplicao no layout padro, sendo o foco principal de muitas reunies.
Figura 9.5
Boto para habilitar
a transmisso
de udio.
Figura 9.6
Imagem do pod de
compartilhamento.
O compartilhamento de documentos suporta diversos formatos de arquivos, como PPT,

JPEG, PDF, PNG e inclusive vdeos (no formato FLV). O usurio seleciona os documentos que
deseja compartilhar e os envia para o servidor. O servidor converte os dados para o formato
adequado para exibio e distribui o contedo para os participantes da videoconferncia.
No caso de vdeos, os participantes podem v-los por download progressivo assim que o
documento estiver completo no servidor (upload completo).
Figura 9.7
Compartilhamento
de uma
apresentao.
A verso 8 do Adobe Connect inclui a possibilidade de arrastar e soltar (drag & drop) dos
arquivos do computador para compartilh-los na videoconferncia. Outra funcionalidade do
pod de compartilhamento o quadro branco, que funciona como uma lousa. O quadro
administradores e apresentadores podem usar essa funcionalidade. Ele possui ferramentas
bastante comuns em quadros brancos: desenhar linhas, formas geomtricas, setas,
modificar cores, entre outros.
colaborativo, ou seja, qualquer alterao feita vista por todos os participantes. Apenas
233
Figura 9.8
Imagem do
quadro branco que
pode ser editado
por todos.
Para compartilhar aplicaes que esto sendo utilizadas no computador do cliente,

possvel usar o compartilhamento de tela. Com ele, pode ser compartilhada uma aplicao
especfica ou toda a tela do computador, ou seja, os participantes passam a ver exatamente
o que o cliente est fazendo em seu computador. Com o compartilhamento, o usurio pode
ainda dar o controle de sua mquina para outro participante da sala, funcionalidade
chamada de controle remoto.
Bate-papo (chat)
Alm de interao por udio e vdeo, as videoconferncias no Adobe Connect podem
utilizar um pod de bate-papo (chat). Seu uso permite troca de mensagens de texto entre os
usurios. O chat por padro pblico, mas possvel mandar mensagens para um usurio
especfico (chat privado). Na verso 8, os chats pblico e privado so separados, facilitando
a organizao. Alm disso, inclui formataes de texto (mudar a cor, mudar o estilo etc.) e a
possibilidade de exportar o texto para RTF ou enviar por e-mail.
Figura 9.9
Pod para bate-papo
(chat).
234
Outros pods
O Adobe Connect possui ainda pods para outras funcionalidades alm das j citadas. Um
deles o pod para anotaes, que bastante simples e utilizado para, por exemplo, guardar
a pauta da reunio. Outro pod interessante o pod de pesquisa (votao), onde pode-se
incluir uma pergunta e diversas opes de respostas. Essa pesquisa ento apresentada a
todos os participantes e no fim pode-se ver o resultado da votao.
Figura 9.10
Pod para pesquisa
(votao).
Layouts
Os layouts so formas pr-configuradas de organizar os pods na tela. Eles podem ser
criados pelos administradores e so facilmente acessados dentro de uma videoconferncia,
utilizando a barra como a da figura seguinte.
Figura 9.11
Barra para mudana
de layouts.
Layouts so extremamente teis para mudar a configurao da sala conforme o andamento

da videoconferncia. Por exemplo: pode-se comear a videoconferncia com os pods de vdeo
e chat ocupando praticamente toda a tela, para que os participantes possam se apresentar e
dar incio sesso. Em seguida, muda-se para um layout onde vdeo e chat ocupam menos
espao, possibilitando que o pod de compartilhamento ocupe grande parte da tela para exibir
Figura 9.12
Layouts com foco
em: 1) vdeo e chat;
e 2) apresentaes.
uma apresentao. Exemplos desses dois layouts so exibidos nas figuras seguintes.
235
rea do apresentador
Administradores e apresentadores dispem ainda de uma rea de preparao do evento,
que consiste em uma regio da tela que no mostrada para os participantes, apenas visvel
para administradores e apresentadores. Assim, pode ser realizada comunicao sem interveno no ambiente comum a todos da reunio; qualquer pod pode ser usado nesta rea.
Um recurso particularmente interessante o pod de moderao de chat; com ele associado
ao chat da rea comum da sala, todas as entradas no chat sero direcionadas para um pod
especial, chamado Question & Answer, onde sero respondidas e s depois de moderadas
sero enviadas para a rea comum da sala. Na imagem seguinte est exibida a viso do
administrador, com a rea de preparao habilitada.
Figura 9.13
Imagem do Adobe
Connect exibindo a
rea exclusiva para
apresentadores.
Dispositivos mveis
Recentemente, a Adobe lanou clientes do Adobe Connect para os dispositivos mveis
com os sistemas iOS (iPhone e iPad) e Android (verso 2.2 e superiores). O cliente para iOS
foi lanado antes mesmo da verso 8 do Adobe Connect, enquanto o cliente Android foi
lanado com a verso 8. Ambos os clientes so gratuitos. Basta fazer download da aplicao
para participar de uma videoconferncia. Porm, so apenas visualizadores, ou seja, no

enviam nem udio nem vdeo, mas podem interagir por chat.
Funcionalidades administrativas
As funes administrativas do Adobe Connect so realizadas atravs de uma interface web
que configura o servidor Adobe Connect. Esse sistema web permite o gerenciamento dos
usurios, das salas de videoconferncia e dos arquivos armazenados no servidor (aqueles
que foram compartilhados em videoconferncias).
Outra funcionalidade importante que faz parte do gerenciamento do Adobe Connect a gravao das videoconferncias. O contedo fica disponvel no servidor e pode ser visualizado
236
posteriormente. Pode-se reproduzir a conferncia como se fosse um vdeo gravado, observando tudo o que aconteceu. Alm disso, o Adobe Connect armazena o estado da reunio:
ela pode ser fechada e aberta de novo mais tarde e voltar ao estado em que estava (inclusive com os arquivos que foram compartilhados no pod de compartilhamento).
A ferramenta permite executar tarefas de gerenciamento diretamente nas salas de videoconferncia pelos administradores. So tarefas como habilitar/desabilitar udio ou vdeo de
algum participante, mudar permisses dos usurios, mudar ou criar layouts, entre outros.
Atividade de demonstrao do Adobe Connect

O instrutor vai demonstrar a administrao de uma sala de webconferncia. Os alunos
devero se conectar e acompanhar a exibio do instrutor.
11 Nveis de permisso;
11 Pods (compartilhamento, vdeo, bate-papo, enquete);
11 rea do apresentador;
11 Layouts.
Cisco WebEx
WebEx inclui:
11 WebEx Meeting Center: soluo de webconferncia.

11 WebEx Training Center: voltado para e-learning.
11 WebEx Event Center: para eventos e seminrios.
11 MeetMeNow: aplicao mais simples para webconferncia entre at 15 indivduos.
11 Todas as solues so construdas sobre a mesma plataforma (MediaTone).
11 um dos principais sistemas de videoconferncia, assim como o Adobe Connect.
11 WebEx Meeting Center (desenvolvido em Java).
11 Suporte em vrios sistemas, como Windows, Mac, Solaris, Linux/Unix.
Principais caractersticas:
11 Compartilhamento de desktop.
11 Controle de computador remoto.
11 Quadro branco.
11 Chat e chat privado durante as reunies.
11 Gravao das videoconferncias.
11 Cliente para dispositivos mveis (iPad, iPhone, Android, Blackberry).

11 Oferecido apenas em forma de servio.
WebEx o nome de uma empresa adquirida pela Cisco em 2007 e tambm o nome dado
ao conjunto de solues de videoconferncia que esta empresa (e portanto, a Cisco) prov.
Porm, o nome WebEx normalmente associado soluo de webconferncia da Cisco,
visto que todas as solues so construdas sobre a mesma plataforma (chamada MediaTone), mas adaptadas para diferentes modelos de negcio.
Neste curso, a soluo que mais se encaixa o WebEx Meeting Center, a soluo de web-
11 Compartilhamento de documentos (PPT, PDF etc.)
conferncia que possui muitas similaridades com solues como o Adobe Connect, por
237
exemplo. Esta soluo de webconferncia ser referenciada apenas por WebEx no restante
desta sesso. Assim como o Adobe Connect, o WebEx um dos sistemas de webconferncia mais conhecidos atualmente. um sistema baseado na web, com integrao de data
e mdia em um navegador web padro. Ele comercializado apenas na forma de servio,
onde os servidores WebEx so hospedados pela Cisco e os usurios alugam o servio com
pagamentos mensais. O WebEx baseado na linguagem Java, que, assim como o Flash, j
est bastante difundido nos computadores atuais. As plataformas suportadas so vrias:
Windows, Mac, Solaris, Linux/Unix.
A imagem seguinte mostra como a interface do WebEx Meeting Center. direita, exibida
uma janela com as reas de participantes, chat, perguntas e respostas, vdeos e outros.
No centro, ocupando grande parte da aplicao, est a rea para funes de gerenciamento
(convidar participantes, por exemplo), quadro branco, compartilhamento de tela, e outras
tarefas que, quando utilizadas, so o foco principal da conferncia.
Figura 9.14
Interface do WebEx
Meeting Center.
O WebEx uma soluo muito parecida com o Adobe Connect, tendo, portanto, funcionalidades muito parecidas. Entre seus recursos esto:
11 Compartilhamento de desktop;
11 Controle de computador remoto;
22 Compartilhamento de udio e vdeo: a interface do WebEx Meeting Center permite at
6 vdeos ao mesmo tempo, com resoluo mxima de 640x360;
11 Quadro branco;
11 Chat e chat privado durante as reunies;
238
11 Gravao das videoconferncias;

11 Compartilhamento de documentos (PPT, PDF etc.): diferente do Adobe Connect: no converte e exibe na aplicao, apenas envia para um local comum e permite que os outros
participantes faam download dos arquivos no seu formato original.
Figura 9.15
Cliente para dispositivos mveis (iPad,
iPhone, Android,
Blackberry);
tela compartilhada
do WebEx no
iPhone.
Ao compartilhar um vdeo, o usurio transmite este vdeo para o servidor e depois os participantes podem acess-lo. No WebEx, cada participante precisa carregar o vdeo inteiro
para ento exibi-lo, enquanto no Adobe Connect pode ser utilizado download progressivo, o
usurio visualiza o vdeo medida que ele est sendo obtido.
J foi citado que o Adobe Connect guarda o estado da reunio, permitindo que ela seja
finalizada e acessada novamente mais tarde, voltando ao seu ltimo estado. J o WebEx no
guarda o estado da reunio: se ela acaba, perde-se o seu estado.
FuzeMeeting
Com foco no compartilhamento de documentos e suportando alta resoluo, tambm
possui comunicao por chat, vdeo e udio inclusive com integrao com o Skype.
Suportado em qualquer sistema:
11 Windows, Mac, Linux, Solaris.
11 Suporte para dispositivos mveis: iPad, iPhone, BlackBerry, Android.
Entre suas funcionalidades principais esto:
11 Compartilhamento de contedo em HD (imagens e vdeos).
11 Compartilhamento de desktop e controle remoto.
11 Executado no navegador em Flash.
11 Quadro branco e anotaes.
11 Gravao das videoconferncias para acesso posterior.
O FuzeMeeting outro sistema de webconferncia cuja principal diferencial ser voltado mais
para compartilhamento de documentos e desktop do que para videoconferncia propriamente (de certa forma semelhante ao GoToMeeting). Desenvolvida em Flash, a ferramenta
O FuzeMeeting ainda no possui interao por vdeo, mas possui comunicao por udio,
que pode ser feita pelo microfone do computador, por um telefone ou pelo Skype. Seu compartilhamento de documentos permite compartilhar imagens, apresentaes e vdeos em
alta resoluo e utilizar ferramentas de anotaes (inclusive quadro branco) e apontadores
para trabalhar sobre estes documentos. Outras funcionalidades so o compartilhamento
de desktop, controle remoto e gravao das conferncias para acesso posterior. A imagem
seguinte mostra a interface da ferramenta.
executada dentro do navegador, sem necessitar de plug-ins adicionais alm do Flash.
239
Figura 9.16
Interface do
FuzeMeeting compartilhando imagem
em alta definio.
Uma das vantagens do FuzeMeeting o suporte a diversos sistemas operacionais e dispositivos mveis. Os criadores da ferramenta dizem que ela permite compartilhamento de
qualquer coisa em sua tela, em alta resoluo e com qualquer pessoa, em qualquer lugar,
em qualquer dispositivo (with anyone, anywhere, on any device). Na prtica, pode ser
executado em Windows, Mac, Linux e Solaris e tambm possui aplicaes para iPad, iPhone,
BlackBerry e Android.
Figura 9.17
FuzeMeeting em
diversos sistemas
e dispositivos.
O FuzeMeeting vendido como servio, e seu valor atualizado deve ser consultado no site.
240
Figura 9.18
Verso do
FuzeMeeting com
interao por
udio e vdeo.
Google Hangout
11 Website: plus.google.com
11 Sistema proprietrio da google de uso livre

11 Utiliza codificao escalvel de vdeo
11 Facilmente integrado com todo o sistema google
Principais caractersticas:
11 Compartilhamento de desktop
11 Compartilhamento de youtube
11 Chat
11 Compartilhamento de documentos (google docs)
O Google Hangout o sistema de webconferncia do Google, sendo bastante integrado com
os outros sistemas dele, como Youtube e Google Docs. Apesar de ser um sistema proprietrio (no tem o cdigo aberto), seu uso livre, bastando ao usurio ter uma conta no Gmail.
Permite compartilhamento de desktop, chat e outras facilidades interessantes, tanto para
efetuar reunies de trabalho como para se divertir entre amigos.
Uma caracterstica interessante do Google Hangout que o seu vdeo codificado de forma
escalvel, resultando numa boa qualidade para a banda utilizada.
BigBlueButton (BBB)
Sistema de cdigo aberto (LGPL) que possui sistema de pods que permitem mover, redi-
mensionar, organizar layout, entre outras funcionalidades. Desenvolvido basicamente

em Flash e Java:
11 Cliente 100% Flash.
11 Servidor Java e Flash.
As resolues atualmente suportadas so de 320x240 e 640x480.
11 640x480, com baixo fps (entre 10 e 15).
A qualidade boa, mas no tima. Utiliza codificao Sorenson H.263, j estando em
andamento o suporte a H.264.
O Big Blue Button (BBB) uma das poucas solues de webconferncia de cdigo aberto.
Seu desenvolvimento teve incio em 2007, na Carleton University (Canad). Distribudo sob a
licena LGPL, o funcionamento do BBB semelhante ao do Adobe Connect, sendo desenvolvido basicamente em Flash e Java (utilizado no servidor apenas).
nizada em janelas internas (pods), cada uma com uma funcionalidade especfica. As janelas
podem ser movidas, redimensionadas e reorganizadas conforme o layout desejado. Apesar
de possuir diversas funcionalidades interessantes, que sero vistas na sequncia, o BBB ainda
no se iguala aos sistemas proprietrios em termos de recursos disponveis e de usabilidade,
embora possua uma boa base de desenvolvedores ativos e seu uso esteja crescendo ao redor
do mundo. Tudo indica que possivelmente se tornar uma alternativa boa e barata para os
sistemas proprietrios.
Sendo uma ferramenta de cdigo aberto, o BBB tem a vantagem de poder utilizar as
diversas bibliotecas e sistemas de cdigo aberto existentes. Ele construdo com base em
O cliente uma aplicao Flash que usa um navegador web. A interface da aplicao orga-
241
diversos outros sistemas de cdigo aberto, incluindo bibliotecas para codificao de udio e
vdeo, servidor e proxy HTTP, servidor RTMP e converso de documentos, entre outros.
Entre as funcionalidades do BBB esto:
11 Compartilhamento de apresentaes e documentos.
22 Suporta diversos formatos: PPT, PDF, PNG e JPEG, entre outros.
22 Possui mouse track: um apresentador pode utilizar o seu mouse para apontar pontos
de uma apresentao ou documento.
11 Compartilhamento de tela.
11 Quadro branco, que permite escrever sobre as apresentaes.
11 Break-out de salas, que permite separar os participantes de uma sala em outras salas.
11 Integrao VoIP com Asterisk ou FreeSWITCH.
11 Chat pblico e privado, incluindo traduo automtica (com a ferramenta Google Translate).
11 Suporte para mais de 20 idiomas, incluindo portugus.
Na prtica, tarefas como cadastrar e gerenciar usurios, criar salas novas, agendar reunies
e visualizar gravaes, por exemplo, no so diretamente na interface do BBB. Deve ser utilizada alguma interface que se comunique com a API do BBB, como, por exemplo, as integraes do BBB para Moodle, Joomla e Mconf (que veremos ainda neste captulo). De certa forma,
uma limitao do BBB, mas permite maior facilidade para integrao com outros sistemas.
Na verso 0.71 do BBB, o foco do desenvolvimento foi em melhorias no udio, especialmente na integrao com sistemas VoIP. J a verso 0.8 inclui mecanismos para gravao e
reproduo de gravaes, melhorias na qualidade do udio e na interface. A seguir imagem
da interface do cliente no BBB.
l
importante observar
que o BBB em si
oferece apenas a
interface para uma sala
de webconferncia e as
ferramentas dentro da
sala, como: interao
por udio, vdeo, chat,
compartilhamento de
tela e as outras
funcionalidades
citadas. No BBB, tarefas
de natureza administrativa devem ser
acessadas por uma API,
ou seja, no fornecida
interface para acesso a
tais funcionalidades.
Figura 9.19
Imagem do BBB em
teste com servidor
em Washington.
O BBB suporta atualmente as resolues 320x240 e 640x480 para vdeo. Esta ltima tem
baixa taxa de quadros por segundo (de 10 a 15). Apesar de ser uma medida subjetiva, o
sistema fornece boa qualidade de vdeo, embora no tima. A qualidade equivalente
atingida com o Adobe Connect. O sistema utiliza Speex para codificao de udio e Sorenson
H.263 para vdeo, sendo que existem planos para migrar o sistema para o codec H.264.
Como foi comentado, o servidor BBB desenvolvido em Java e Flash. Sua base em torno
da ferramenta Red5, um servidor de fluxos RTMP. O BBB suporta mltiplas salas de webconferncia e j foram realizados testes de carga onde 193 pessoas se conectaram ao mesmo
tempo em uma nica sala e 20 delas estavam com transmisso de vdeo habilitada. No
242
aconselhvel permitir a entrada de um nmero to grande de usurios, mas esse nmero

mostra a capacidade que o sistema tem de suportar dezenas de participantes simultneos.
Outra caracterstica importante do BBB a integrao com outros sistemas de cdigo aberto,
como sistemas para wikis, sistemas de gerenciamento de contedo multimdia, sistemas para
blogs etc. A seguir uma imagem com os sistemas que fornecem integrao com o BBB.
Figura 9.20
Integrao do
BBB com outros
sistemas de
cdigo aberto.
Dicas para instalar sua verso do BBB:

11 O BBB executado em Linux (possui pacotes para Ubuntu).
11 A forma mais fcil e recomendada utilizar a mquina virtual disponibilizada.
O BBB distribudo de trs formas: atravs do seu cdigo-fonte, atravs de pacotes
pr-compilados para Linux, e atravs de uma mquina virtual que j vem com o sistema
pronto para utilizao. A forma mais fcil e rpida de colocar um servidor BBB em funcionamento atravs de sua mquina virtual. Esta mquina virtual nada mais do que uma instalao do sistema Ubuntu, pr-configurado para instalar o BBB quando for executada. Os
procedimentos so simples e detalhes podem ser encontrados na documentao do BBB.
O download da mquina virtual pode ser realizado no site da Big Blue Button.
Para uso da mquina virtual importante:
11 Ter uma rede com DHCP habilitado; necessria uma mquina virtual aberta para
que o BBB seja configurado corretamente.
11 Garantir que a mquina virtual esteja com rede em modo bridged.
Se a conexo de rede no for configurada corretamente no modo automtico, alguns
comandos podem ajudar na configurao:
$ sudo dhclient
# configurar IP por DHCP
$ ifconfig
# descobrir IP configurado
$ sudo bbb-conf --setip <ip> # configurar IP descoberto

$ sudo bbb-conf --clean
# reiniciar BBB
$ sudo bbb-conf --check
# verificar configuraes do BBB
Neste curso ser utilizada uma mquina virtual preparada pelo instrutor com o BBB. Os
alunos devem utilizar o navegador para acessar o IP que ser fornecido, ao entrar no site,
basta inserir seu nome e entrar na conferncia. Nos fruns e listas de discusso para usurios e desenvolvedores na plataforma Big Blue Button do BBB, pode-se encontrar os planos
futuros da equipe de desenvolvimento.
Lista com os sistemas

que fornecem
integrao com o BBB
pode ser acessada na
pgina Integration do
site da Big Blue Button.
243
Entre as possveis funcionalidades que sero implementadas esto:

11 Cliente para dispositivos mveis como iPad, iPhone e dispositivos com Android;
11 Codificao com VP8/WebM/H.264 e, em funo disso, melhorar a qualidade do vdeo;
11 Interface do cliente em HTML5, eliminando o Flash inteira ou parcialmente.
Mconf
Mconf-Web:
11 Portal web que prov acesso ao sistema.

11 Prov salas virtuais, foruns de discussom, agendamento de eventos e outros;
11 Foi desenvolvido com baso na soluo de cdigo aberto Global Plaza, que possui um
formato de rede social para realizao de eventos virtuais.
BigBlueButton:
11 utilizado como o cliente para webconferncias;
11 Como o BigBlueButton um sistema de cdigo aberto, a equipe do Mconf tambm
colabora com o seu desenvolvimento.
Mconf-Mobile:
11 Cliente para dispositivos mveis;
11 Atualmente um cliente para dispositivos com Android;
11 Permite que os usurios participem de uma conferncia;
11 Possui praticamente todas as funcionalidades que existem no cliente desktop tradicional: compartilhamento de udio, vdeo, apresentaes e bate-papo.
O Mconf um sistema nacional de cdigo aberto, em desenvolvimento no grupo de pesquisa de Projetos em udio e Vdeo (PRAV) da Universidade Federal do Rio Grande do Sul
(UFRGS), que adiciona funcionalidades ao Big Blue Button para prover um sistema completo
de webconferncia. A figura seguinte mostra diagrama dos blocos que formam o Mconf.
Figura 9.21
Diagrama dos componentes do Mconf.
Os trs componentes principais do Mconf so: o portal web (Mconf-Web), o ncleo de

webconferncia BigBlueButton e o cliente para dispositivos mveis (Mconf-Mobile).
O Mconf-Web o portal de acesso ao sistema, uma aplicao em Ruby on Rails que prov
a criao de salas virtuais, fruns de discusso e agendamento de eventos. Este portal foi
desenvolvido com base na soluo de cdigo aberto chamada Global Plaza, que possui um
formato de rede social para realizao de eventos virtuais (eventos com webconferncia).
A imagem seguinte mostra a tela inicial do portal web.
244
Webconference
room
Agenda
Communities
Inbox
Recente
activity
Figura 9.22
Tela inicial do
Mconf-Web, o portal
web do Mconf.
O Big Blue Button utilizado como o cliente para webconferncias e por ser um sistema de
cdigo aberto, a equipe do Mconf tambm colabora com o seu desenvolvimento. O outro
bloco que forma o Mconf o cliente para aplicaes mveis. Atualmente, este componente
formado por um cliente para dispositivos Android. Esta uma aplicao nativa para Android
que permite que os usurios participem de uma conferncia com acesso a praticamente
todas as funcionalidades do cliente desktop tradicional: compartilhamento de udio, vdeo,

apresentaes e bate-papo. A figura seguinte mostra telas do cliente Android Mconf-Mobile.
Figura 9.23
Mconf-Mobile,
cliente Android
do Mconf.
Para saber mais sobre

o projeto Mconf-Web:
www.inf.ufrgs.br/prav
245
Duas funcionalidades principais adicionadas pelo Mconf:
11 Acesso federado
11 Escalabilidade
Acesso federado:
11 O portal web est integrado federao nacional CAFe.
11 Permite que qualquer membro da federao acesse o Mconf.
11 Utiliza o protocolo Shibboleth.
11 Aumenta a segurana para os usurios e evita a necessidade de criao de
mltiplas contas.
Escalabilidade:
11 Um servidor BBB recomendado para 80 usurios simultneos (mas depende
fortemente da mquina).
11 Para aumentar a capacidade existe o mdulo de escalabilidade.
11 Permite o uso de mltiplos servidores BBB em paralelo.
11 Com base em um mdulo de monitoramento (CPU, memria, banda de rede etc.), a
criao das salas escolhe dinamicamente um servidor na rede de servidores BBB do
Mconf (permite aumentar o nmero de salas de webconferncia simultneas).
O Mconf est integrado a um mdulo Shibboleth, que prov autenticao federada no
Shibboleth
portal web. Mconf e diversos outros servios podem utilizar um mesmo servidor para auten-
Protocolo internacional
para autenticao
federada. Permite que
usurios de diferentes
servios sejam autenticados em provedores de
identidade centralizados.
ticar os usurios. Para os usurios, a grande vantagem possuir um ponto de autenticao

nico para diversos servios, o que aumenta a segurana e evita a necessidade de criao
de contas em mltiplos servios. Atualmente o Mconf-Web um dos servios da federao
brasileira CAFe (Federated Academic Community). Em relao escalabilidade, o Mconf est
desenvolvendo ferramentas para permitir o uso de mltiplos servidores BigBlueButton e
para escalar os componentes dentro de um servidor.
Como foi comentado, um servidor BigBlueButton recomendado para sesses de 80 usurios
simultneos. Para aumentar essa capacidade, a soluo mais direta melhorar o hardware
no qual o servidor est instalado. Isto provavelmente aumentar a capacidade do BigBlueButton, mas no uma soluo escalvel, uma vez que se chegar a um limite na capacidade
do hardware, no importa o quo bom ele seja.
Outra soluo utilizar diversos servidores BigBlueButton em paralelo. Esta soluo
aumenta o nmero de salas possveis, mas no aumenta a capacidade de uma sala, j que
uma sala est (atualmente) vinculada a somente um servidor. Para incrementar esta soluo
e chegar soluo mais completa, deve-se permitir mltiplos servidores BigBlueButton em
246
paralelo e tambm permitir que uma sala seja espalhada por mltiplos servidores.
A soluo do Mconf para esse problema inclui um mdulo de monitoramento no Mconf, que
gera estatsticas (CPU, memria, banda de rede) dos servidores Big Blue Button e permite
acesso a elas no portal web. Com base nessas estatsticas, as salas sero criadas dinamicamente em diferentes servidores BigBlueButton localizados em regies geogrficas distintas.
Como j comentado, o Mconf um sistema de cdigo aberto. O cdigo e toda a documentao do projeto esto disponveis para acesso na web, alm de um servidor onde o sistema
pode ser utilizado gratuitamente.
OpenMeetings
Sua base similar do BBB, com diversos componentes comuns. desenvolvido em
Flash e Java.
11 Cliente 100% Flash.
11 Servidor Java e Flash.
Outra alternativa para webconferncias de cdigo aberto o OpenMeetings, que tem
diversas semelhanas com o BBB e algumas com o Adobe Connect.
O projeto do OpenMeetings foi iniciado em 2007 e seu desenvolvimento evoluiu at o ponto
em que est hoje, com cerca de 25 desenvolvedores ativos. distribudo sob a licena Eclipse
Public License 1.0. Sua base similar do BBB, e eles possuem diversos componentes
comuns. Assim como o BBB, desenvolvido basicamente em Flash e Java (utilizado no servidor apenas). O cliente, uma aplicao Flash, acessado por um navegador web. Seu servidor
baseado no Red5 (assim como o BBB), e ele desenvolvido utilizando um framework para
aplicaes web chamado OpenLaszlo. Em comparao com o BBB, ele possui mais funcionalidades, especialmente para tarefas de gerenciamento. Entre suas funcionalidades esto:
11 Quadro branco;
11 Compartilhamento de documentos de vrios formatos: PDF, DOC, ODP e PPT, entre outros.
So disponibilizados em uma pasta no servidor e tambm podem ser vistos na conferncia;
11 Gravao, reproduo e download das gravaes;
11 Compartilhamento de tela e controle remoto (necessita de uma aplicao adicional em Java);
11 Possui tarefas de gerenciamento como controle de usurios e agendamento;
11 Votaes com respostas sim e no;
11 Suporte para mais de 20 idiomas (incluindo portugus).
Abaixo so exibidas imagens da interface do OpenMeetings, a primeira dentro da webconfe-
Figura 9.24
Interface do
OpenMeetings
para agendamento.
rncia e a segunda na pgina de visualizao de gravaes.
247
Figura 9.25
Interface do
OpenMeetings
durante uma
webconferncia.
Figura 9.26
Interface do
OpenMeetings para
visualizao de
webconferncias
gravadas.
Entre as integraes que o OpenMeetings possui com outros sistemas de cdigo aberto esto:
11 Moodle: permite criar e agendar webconferncias;
11 Facebook: o OpenMeetings possibilita que o login no sistema seja feito atravs da conta
do usurio no Facebook;
11 Paypal: possibilita integrar a cobrana por servios de webconferncia no OpenMeetings;
11 Sugar CRM: ferramenta para relacionamento com clientes (Customer Relationship
Management);
11 StudIP: plataforma de ensino (de certa forma semelhante ao Moodle).
Como vimos, OpenMeetings possui diversas similaridades com o BBB. So ferramentas de
cdigo aberto, sendo importante verificar as diferenas entre os dois sistemas para decidir
aquele que melhor se adapta aos propsitos da pessoa ou instituio que busca um sistema
de webconferncia. Os dois sistemas possuem ambientes de demonstrao disponveis para
o pblico, ento indispensvel utiliz-los para fazer uma anlise mais detalhada. Os principais aspectos da comparao entre os sistemas so:
11 Qualidade de vdeo e udio bastante similar;
11 OpenMeetings tem funes administrativas j integradas na interface, enquanto o BBB
possui algumas dessas funcionalidades, mas fornece apenas a API para us-las, e no
uma aplicao com interface com o usurio. Ou seja, o BBB necessita de outro
22 software que implemente a interface, enquanto o OpenMeetings possui as ferramentas integradas na mesma interface;
248
11 BBB possui documentao mais completa e melhor elaborada;

11 Interface do BBB mais limpa e intuitiva;
11 BBB possui integrao com VoIP;
11 BBB, via grupo Mconf, possui aplicativo para dispositivos mveis.
Ao contrrio de outras ferramentas, o OpenMeetings no distribudo em uma mquina
virtual pronta para uso. Para instalao local, deve-se obter o pacote com o cdigo-fonte
da aplicao, que distribudo no website da ferramenta. Os pr-requisitos (bibliotecas)
necessrios devem ser instalados manualmente, depois preciso editar alguns documentos
do OpenMeetings e iniciar o servio. Os passos necessrios podem ser encontrados na wiki
Installation Open Meetings.
Outras solues
Os sistemas citados at agora so os mais conhecidos e utilizados para webconferncia, mas
existem diversas outras ferramentas. Entre os sistemas ainda no detalhados, selecionamos
alguns para exibir imagens e links com o intuito de facilitar a consulta dos interessados em
conhecer melhor outras alternativas. Os sistemas escolhidos foram:
11 Spreed (proprietrio);
11 Elluminate Live! (proprietrio);
11 WebHuddle (cdigo aberto).
11 Bluejeans (http://bluejeans.com) interopervel com H.323 e integrador de vrias tecnologias.
Spreed
O Spreed um sistema proprietrio de webconferncia. Fazendo cadastro no site possvel
utilizar uma verso gratuita, com vrias limitaes (limite de 3 participantes, pouco espao
de armazenamento de arquivos e outras). Possui verses pagas por $99 ao ano (20 participantes) e $299 ao ano (100 participantes). Apesar de ser pago, possui uma interface muito
Figura 9.27
Interface do Spreed
exibindo um vdeo
e o compartilhamento de uma
apresentao.
boa e bastante fcil de usar.
249
Figura 9.28
Interface do Spreed
com foco no chat
(exibido no centro).
Elluminate Live!
Sistema proprietrio da empresa Elluminate com foco em educao distncia. Utilizado
pelo Virtual Conference Centre, permite realizar teste na aplicao pela pgina Getting
Started Virtual Conference Centre (clique em Training Room).
Figura 9.29
Interface do
Elluminate compartilhando um vdeo e
um quadro branco.
250
Figura 9.30
Visualizando uma
gravao do uso
do Elluminate Live!
compartilhando
uma apresentao.
WebHuddle
Projetado para ser de fcil uso, apresenta diversas opes, incluindo integrao com
solues de sistemas de teleconferncia de outras empresas. Com o sistema WebHuddle,
possvel efetuar a gravao das apresentaes que podero ser reproduzidas futuramente
atravs de qualquer navegador web.
251
252
Para as atividades a seguir h um conjunto de funcionalidades comuns a todas as ferramentas (ou maioria delas) que devem ser exploradas.
1. Compartilhar documentos e verificar os formatos possveis (apresentaes, imagens,
documentos texto, quadro branco);

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

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

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

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

Acesse o Google Hangout e verifique as funcionalidades indicadas. Vale lembrar que, para
criar um hangout, o interlocutor deve pertencer aos crculos da pessoa.
253
254
10
Permitir ao aluno experimentar diversos aplicativos de videoconferncia em software,
reforando os conceitos tericos estudados e comparando as diferentes solues.
conceitos
Solues em software para videoconferncia: IVA, EVO, VSee e Citrix gotomeeting.
IVA
Realizao de aulas sncronas atravs das unidades da ESR, de forma que um professor
especialista dissemine seu conhecimento para diversas localidades, evitando custos com
viagens sem perder qualidade de aula.
O Sistema Interativo de udio e Vdeo (IVA) um sistema de videoconferncia desenvolvido
na Universidade Federal do Rio Grande do Sul (UFRGS), a partir de financiamento da Rede
Nacional de Ensino e Pesquisa (RNP) e da Financiadora de Estudos e Projetos (FINEP), em
parceria com o Inmetro. Na RNP, o projeto foi iniciado com o Grupo de Trabalho em Infraestrutura para Ensino a Distncia (GT-IEAD). O desenvolvimento principal do projeto aconteceu
entre 2007 e 2008, sendo que em 2009 e 2010 foram realizados os testes do prottipo e a
implantao da primeira verso para uso na ESR. O servio de aulas por videoconferncia na
ESR com uso do IVA teve incio em 2011.
O objetivo do sistema a realizao de aulas sncronas atravs das unidades da ESR.
O professor especialista pode ministrar sua aula presencial em sala chamada de telessala,
para alunos remotos localizados em outras salas, que so chamadas de polos.
importante frisar o foco do IVA na interatividade, pois a interao entre professor e alunos
remotos essencial para obter qualidade similar das aulas presenciais.
A imagem seguinte mostra a interao entre telessala e os polos remotos. O professor
fica na telessala com uma turma de alunos presenciais, enquanto nos polos esto alunos
remotos assistindo s aulas sincronamente. Um ouvinte remoto tambm pode se conectar e
assistir aula.
Captulo 10 - Videoconferncia em desktop
objetivos
Videoconferncia em desktop
255
Plo
RNP
Ouvinte
Telesala
Plo
Unindo alta qualidade de vdeo com o foco na interao, o IVA utiliza o conceito de telepresena, que recria, dentro das possibilidades tecnolgicas, condies de uma aula presencial
sncrona. Na telessala, os alunos presenciais enxergam os slides do professor normalmente
em um projetor. Nos polos, os alunos remotos tambm enxergam os slides do professor
atravs de um projetor. O professor enxerga os alunos presenciais na telessala, e tambm
Figura 10.1
Diagrama da
comunicao entre
telessala e polos
remotos atravs
do IVA.
enxerga os alunos remotos, porm em televises, onde a alta qualidade do vdeo permite
ver detalhes, como um aluno levantando a mo para fazer uma pergunta. Os alunos presenciais enxergam o professor, e os alunos remotos tambm enxergam o professor, porm
atravs de uma televiso.
Figura 10.2
Infraestrutura
das salas.
(a) Telessala
(b) Polo
Quando um aluno faz uma pergunta, o operador da entidade sute muda a imagem prin Administrao de Videoconferncia
cipal para transmitir o vdeo do polo onde o aluno est. Essa imagem transmitida a todos.
256
Neste formato, as interaes entre professor e alunos remotos so feitas olho no olho.
No momento em que um aluno remoto quer fazer uma pergunta, o seu sinal enviado para
todos os outros pontos remotos (incluindo a telessala), portanto todos enxergam tanto o
professor quanto o aluno fazendo a pergunta.
Figura 10.3
Aluno perguntando,
todos enxergam
professor e aluno.
O sistema IVA formando por trs entidades (softwares) principais. So eles o Moderador,
a Sute e o Apresentador. O Moderador e a Sute so as entidades centrais do sistema, que
formam uma sesso de videoconferncia IVA, enquanto o Apresentador o software utilizado nos pontos remotos e na telessala para captura e recepo de dados multimdia.
Utilizaremos a primeira letra maiscula quando nos referirmos aos softwares do IVA,
para evitar confuses (e.g. entidade Apresentador e a pessoa que tem papel de
apresentador na sesso).
O Moderador funciona como um gerente. Todas as outras entidades IVA se conectam a ele e
so gerenciadas por ele. Na prtica, ele utilizado para moderar mensagens de chat e
selecionar quais usurios so apresentadores e quais so apenas participantes. O Moderador pode se comunicar por chat com qualquer apresentador e tambm com a Sute. Alm
disso, o Moderador recebe o sinal da transmisso de udio e vdeo que est sendo transmitido pela Sute. Na imagem a seguir, pode-se ver no canto superior esquerdo a lista de
apresentadores. No canto inferior direito a lista de participantes. No centro, o chat pblico.
No canto superior esquerdo a imagem principal da transmisso do sistema, e logo abaixo
um chat privativo com o operador da Sute.
Figura 10.4
Imagem do
moderador IVA.
257
A sute o centralizador de mdias do IVA. Ela recebe os sinais de udio e vdeo de todos os
apresentadores e escolhe qual desses sinais ser enviado para todos os clientes. Este envio
feito utilizando multicast para otimizar a banda de transmisso necessria. Caso algum
ponto no tenha multicast, existe outra entidade que faz a converso de multicast para
unicast, servindo de forma independente cada um desses locais via unicast.
O software Sute possui 6 previews, que so reas de pr-visualizao de udio e vdeo.
O operador da Sute pode atribuir qualquer um dos apresentadores em um preview,
podendo assim visualizar o seu vdeo e escutar o seu udio. Aps colocar os apresentadores nos previews, o operador pode facilmente selecionar um deles para colocar no ar,
ou seja, enviar seus dados por multicast.
Conceito de telepresena interao:
11 Perguntas so feitas olho no olho.

11 Todas as salas remotas recebem o sinal de udio e vdeo do aluno que est perguntando.
11 Professor conversa diretamente com o aluno.
Conceito de telepresena:
11 Recria, dentro das possibilidades tecnolgicas, condies de uma aula presencial sncrona.
11 Professor enxerga alunos presenciais e polos remotos em televises.
11 Alunos presenciais enxergam slides do professor no projetor.
11 Alunos remotos enxergam slides do professor no projetor.
11 Alunos remotos enxergam a imagem do professor em uma televiso.
Outras funcionalidades importantes da Sute so a mixagem de udio e a telepresena.
A mixagem de udio permite que a Sute envie mais de um canal de udio simultaneamente,
facilitando a interao entre as salas remotas. Qualquer vdeo de Apresentador que est
em preview pode ser adicionado na mixagem, portanto, at 6 canais de udio podem ser
mixados para envio.
A telepresena permite que a Sute crie fluxos adicionais de envio de udio e vdeo. Qualquer
um dos previews pode ser colocado em telepresena, o que indica que ele ser transmitido
(tambm utilizando multicast) de forma independente do que est na transmisso principal
(no ar). Na prtica, temos um sinal de transmisso no ar, que o sinal dos slides do professor. Temos tambm diversos outros sinais de telepresena, um para a cmera de vdeo
do professor e um para a cmera de cada sala remota. Com isso todos os polos enxergam os
slides e o vdeo do professor, e o professor pode visualizar todas as salas remotas.
258
O IVA baseado em transmisso multicast. O maior problema de utilizar multicast que ele
no suportado em todas as redes. Na verdade, no suportado na grande maioria das
redes atuais. Pensando nisso, foi desenvolvida uma nova entidade IVA, chamada de Servidor
de Streaming. Esta entidade responsvel por permitir que todos os pontos que no
suportam multicast tenham acesso transmisso utilizando unicast.
Software Moderador
11 Entidade gerente da sesso IVA.

11 Utilizado para moderar mensagens de chat e selecionar os participantes que atuaro
como apresentadores.
Software Sute
11 Central de dados multimdia: controla distribuio de udio e vdeo.
11 Seleciona o sinal que est sendo transmitido para todas as salas e os sinais que esto
em telepresena.
Software Apresentador
11 Responsvel pela transmisso de udio e vdeo.
11 Captura vdeo do professor, dos slides e das salas remotas.
11 Exibe imagens nas televises e projetores.
A terceira das principais entidades do IVA chamada de Apresentador. Este software corresponde ao cliente da sesso IVA, o responsvel por capturar o vdeo e o udio de um participante e transmitir esses dados para a Sute, alm de receber da Sute e exibir o vdeo que
est no ar e o udio que est sendo mixado. Alm do uso de udio e vdeo, o Apresentador
tambm pode se comunicar com o Moderador atravs de chat (todas as mensagens de um
Apresentador so enviadas apenas para o Moderador, que pode decidir se elas devem ser
repassadas para todos ou no). Outra funcionalidade do Apresentador a captura de tela,
que utilizada para capturar slides, vdeos e qualquer outro material que o professor deseje
utilizar. Basta abrir o material no computador que est executando um Apresentador com
captura de tela que este material ser transmitido como vdeo para a Sute.
O mesmo software Apresentador pode ser executado em modo Visualizador, que um
Apresentador que no transmite udio nem vdeo, apenas recebe. Este Visualizador
Figura 10.5
Sute com 5 apresentadores em
preview e enviando
os slides do professor na transmisso principal.
utilizado para receber dados de um canal de telepresena. Na prtica na ESR, eles so

259
associados s televises para exibir um plo nas TVs da telessala, ou para exibir o vdeo do
professor nas TVs dos plos.
A imagem a seguir mostra a tela do Apresentador durante a sesso, quando est capturando, transmitindo e recebendo udio e vdeo. Na parte inferior esquerda da imagem
visto um vdeo que corresponde ao preview do vdeo capturado localmente (a cmera do
usurio local). Abaixo ao lado direito do preview fica a rea de chat e os botes de controle
de udio, vdeo, chat e outros. Atrs desses componentes e ocupando praticamente toda a
tela da aplicao est o vdeo recebido da Sute (o vdeo no ar). Nesse caso, o apresentador
remoto est mostrando algo no seu tablet. Vale lembrar que as reas sobrepostas imagem
recebida podem ser minimizadas.
Figura 10.6
Imagem do
apresentador
IVA durante
uma sesso.
Alm dos softwares citados do sistema IVA, tambm existe o software Chat, que funciona
de forma semelhante ao Apresentador, mas que utilizado apenas para comunicao via
chat (sem udio nem vdeo). O IVA foi desenvolvido com foco em educao a distncia, mas
tambm pode ser utilizado para outros fins, como em reunies remotas. Como foi visto,
na ESR os softwares que formam a base do IVA so instalados na telessala, enquanto os
polos necessitam apenas dos clientes (o software apresentador). Abaixo so descritos os
softwares utilizados na telessala e nos plos da ESR, que formam uma das organizaes
arquiteturais utilizando o IVA.
Softwares na telessala: a telessala o ponto central das aulas na ESR, portanto nela que
esto instalados os servidores IVA. H uma mquina para o Moderador e uma para a Sute.
Alm disso, h dois Apresentadores: um captura a cmera do professor, recebe o vdeo
no ar e projeta este vdeo no telo (normalmente o vdeo dos slides do professor); o outro
utilizado na mquina do professor, para capturar qualquer contedo que se deseje transmitir aos alunos: slides, vdeos, tela de aplicaes etc. Para que o professor veja os polos,
existem duas televises na sala, cada uma delas ligada a um Visualizador que recebe o vdeo
260
de uma das salas.

Eventualmente necessrio um software servidor de unicast, quando algum participante
estiver em uma rede que no suporta multicast. Na telessala necessrio pelo menos um
operador para controlar Moderador e Sute. Pode-se tambm utilizar dois operadores: um
tcnico para controlar a Sute e um operador que tenha conhecimento na disciplina sendo
ministrada para controlar o Moderador (possivelmente o monitor da aula).
Distribui o sinal
por multicast
Moderador
Sute
Captura imagem do professor

e projeta slides
Apresentador
Figura 10.7
Softwares IVA na
telessala da ESR.
Recebe o sinal
multicast encaminha
mltiplos em unicast
Visualizador
Visualizador
Sala remota 1
Sala remota 2
Servidor de
streaming
Captura slides, vdeos

e outros contedos
Apresentador
Softwares nos polos (pontos remotos): os pontos remotos contm apenas os softwares
clientes do IVA: o Apresentador e o Visualizador. O Apresentador utilizado para capturar o
vdeo e udio da sala e tambm para receber o vdeo no ar e projet-lo em um telo e
tambm tocar o udio da sesso. J o Visualizador ligado a uma televiso e sempre
mostrar o vdeo do professor.
Figura 10.8
Sistema de controle com sute,
moderador e
apresentador e
equipamentos de
udio e vdeo.
As imagens seguintes mostram telessala na ESR-RS com o IVA em uso.
261
Figura 10.9
Tela da sute com a
seguinte distribuio (esquerda
para a direita): vdeo
do professor na
telessala; tela do
professor transmitindo um vdeo; polo
ESR-RJ; polo UFRGS;
polo ESR-DF; polo
ESR-MT.
EVO
Enabling Virtual Organizations (EVO) utiliza como base o sistema de agentes MonALISA.
O sistema adapta-se automaticamente s configuraes e estado da rede. Possui monitoramento fim a fim:
11 Monitora tanto o computador cliente quanto a rede.
11 Permite deteco de problemas como uso elevado de CPU e perda de pacotes.
EVO um sistema de videoconferncia desenvolvido pelo Californian Institute of Technology
(Caltech), criado com o intuito principal de prover um servio para o trabalho com o Large
Hadron Collider (LHC), o acelerador de partculas da European Organization for Nuclear
Research (CERN), localizada na Sua. O EVO tambm foi disponibilizado para outros programas de ensino com foco em fsica (High Energy Physics).
A base do EVO desenvolvida sobre o sistema de agentes MonALISA, o que possibilita o
alcance global ao sistema e tambm o torna mais dinmico e autnomo. O EVO possui
funcionalidades para adaptao automtica s configuraes e estado da rede e monitoramento fim a fim, incluindo monitoramento do computador cliente e da rede, o que permite a
deteco de problemas como uso elevado de CPU e perda de pacotes.
262
A aplicao cliente do sistema chama-se Koala e desenvolvida em Java. O cliente tambm

utiliza o visualizador de vdeos (ViEVO), que tem como caractersticas principais:
11 Troca de mensagens instantneas, com escolha de estado (ocupado, ausente etc.);
11 Integrao com rede telefnica;
11 Uso de OpenGL no cliente, o que melhora o desempenho e permite um sistema 3D de
exibio de vdeos;
11 Criptografia de todos os dados trocados;
11 Suporte para mltiplas linguagens;
11 Compartilhamento de arquivos e tela;

11 Funes de quadro branco;
11 Gravao e reproduo das sesses;
11 Chat pblico e privado.
O EVO s pode ser utilizado por usurios cadastrados. Portanto, o primeiro passo para
utiliz-lo realizar o cadastro, que pode ser feito no website do EVO, clicando em Register.
Concludo o registro, basta fazer o download da aplicao e fazer login no sistema. Como
a aplicao em Java, ser realizado download do arquivo .jnlp, que ao ser executado
carrega a aplicao. O arquivo pode ser encontrado no website clicando em Start EVO.
A prxima figura exibe a tela inicial da aplicao juntamente com a caixa de dilogo utilizada
para login no sistema.
Figura 10.10
Tela inicial do
EVO e tela para
login no sistema.
Aps o login, exibida a tela inicial da aplicao, onde pode ser encontrada uma lista com
as reunies em andamento (pblicas ou privadas), a lista de amigos do usurio (parte inferior esquerda) e uma rea para chat (parte inferior direita). A imagem dessa tela pode
Figura 10.11
Tela com os canais
EVO, lista de amigos
e rea de chat.
ser vista abaixo.
263
A partir da lista de reunies (chamadas de salas ou canais) o usurio pode selecionar uma
delas para ingressar. Ao entrar em uma reunio, o sistema muda para a tela de reunies,
que contm as configuraes possveis para ela: habilitar/desabilitar udio e vdeo, gravar,
entre outras. Alm desta tela, udio e vdeo so exibidos em outra janela chamada ViEVO,
que usa OpenGL para mostrar os vdeos com efeitos grficos que facilitam a usabilidade da
aplicao. exibido um participante que est em foco no centro da tela e os outros na barra
abaixo do vdeo principal. O participante em foco pode ser quem est falando no momento
ou participante escolhido pelo usurio. A imagem seguinte mostra a tela de configuraes e
o ViEVO, respectivamente.
EVO possui o canal EVO TV aberto a todos os participantes, que pode ser usado
para testar sua conexo.
Figura 10.12
Tela de configuraes de canal no
EVO e tela do ViEVO
com vdeo dos
participantes.
VSee
11 Soluo gratuita para uso pessoal no comercial, especfica para Windows.
11 O usurio faz login no sistema e visualiza sua lista de contatos.

11 Dados de udio e vdeo so trocados por P2P entre os participantes, se possvel, utilizando apenas uma porta UDP.
11 Em caso de falhas, utiliza tunelamento HTTP ou SSL.
11 H tambm um servidor para autenticao e controle da comunicao. possvel
licenciar o servidor para instalao local.
O VSee uma ferramenta proprietria de videoconferncia especfica para Windows que
segue o formato de aplicativos para troca de mensagens instantneas, como MSN, Gtalk e
Skype. O usurio instala a aplicao, utiliza seu e-mail e senha para fazer login no sistema e
com isso tem acesso sua lista de contatos. A partir desse ponto ele pode escolher contatos
para se comunicar utilizando udio e vdeo, fazer reunies, compartilhar aplicaes e realizar outras atividades em sistemas de videoconferncia.
Apesar de ser uma soluo proprietria, o VSee livre para uso pessoal no comercial. Para
uso comercial, o produto oferece diferentes planos. Um plano inclui a instalao local do
servidor VSee, modelo semelhante compra do servidor Adobe Connect.
Diferenciais do VSee, segundo seus desenvolvedores:
11 Baixo uso de banda: utiliza menos banda do que outras solues como Skype, WebEx,
Polycom, Adobe e Cisco.
11 Funciona em qualquer tipo de rede, inclusive em redes wireless e 3G/EVDO. Adapta
transmisso automaticamente conforme a rede.
264
A troca de dados de udio e vdeo no VSee feita com P2P entre os participantes, sempre
que possvel. Para isso utilizada apenas uma porta UDP, o que reduz os problemas com
bloqueio em firewalls. Em caso de falha desse mtodo, utilizado tunelamento HTTP ou SSL.
Apesar disso existe um servidor VSee usado para autenticao e controle da comunicao
entre os clientes.
Principais caractersticas do VSee:
11 Facilidade de compartilhar aplicaes e desktop (one click sharing): utiliza-se a prpria
aplicao para abrir os arquivos e compartilhar aquela tela. O VSee cria uma barra de
botes no topo da aplicao compartilhada, que serve para utilizar ferramentas de
quadro branco, disponibilizar o controle remoto e cancelar compartilhamento.
11 Vdeo de alta resoluo;
11 Transferncia de arquivos simples por drag&drop;
11 Compartilhamento de vdeos;
11 Controle remoto de cmera;
11 Chat pblico e privado;
11 Utiliza criptografia AES de 256 bits;
11 Permite gravao local das videoconferncias.
Para utilizar o VSee, o primeiro passo fazer download do instalador no site da ferramenta.
Basta acessar o site do VSee e clicar em Try VSee Now.
Aps a instalao, deve ser feito o login no sistema ou ento criar uma nova conta, tarefas
Figura 10.13
Telas de login e
de criao de
conta no VSee.
Ao fazer login, exibida a lista de contatos do usurio e o seu vdeo, que j inicia habilitado
e pronto para transmisso.
realizadas atravs da mesma interface.
265
Figura 10.14
Lista de contatos e
vdeo do usurio.
A partir deste ponto utiliza-se a ferramenta clicando nos contatos ou nos cones na tela do
vdeo local, onde pode-se iniciar reunies, compartilhar arquivos e aplicaes, iniciar e parar
a gravao da videoconferncia, entre outras funes.
A prxima figura exibe imagens da aplicao em execuo com mltiplos vdeos, chat e
compartilhamento de aplicaes.
266
Figura 10.15
VSee com mltiplos
vdeos e janela
de chat.
Figura 10.16
Barra de ferramentas inserida
pelo VSee em
uma aplicao
compartilhada.
Citrix GoToMeeting
Uma das solues de videoconferncia da Citrix:
11 GoToMeeting: foco em reunies.

11 GoToWebinar: para seminrios e apresentaes.
11 GoToTraining: treinamentos e aulas remotas.
No 100% web, sendo necessrio instalar uma aplicao na mquina do usurio.
11 Basta acessar o website do GoToMeeting: a instalao automtica.
11 Possui as funcionalidades e facilidades de um sistema de webconferncia (HDFaces).
11 Ferramenta utilizada como base nas solues da Citrix para incluir transmisso de
vdeo em alta qualidade.
11 Suporta at 6 vdeos de 640x320p
11 ou 1 vdeo de 1920x960p
O Citrix GoToMeeting uma das solues de videoconferncia da empresa Citrix. Entre as
solues desta empresa destacam-se:
11 Sistema com foco em reunies, com suporte para at 15 participantes;
11 Apresentaes e seminrios, suportando at mil participantes;
11 Utilizado para treinamentos e aulas remotas, com suporte a at 200 participantes.
O GoToMeeting foi desenvolvido a princpio como um sistema para compartilhar a tela de
um computador com diversos outros computadores na internet. Ele utiliza os mecanismos
GoToMyPC e GoToAssist para este fim, fornecendo com eles um bom mecanismo de compartilhamento de desktop e controle remoto.
Ao longo dos anos, o sistema evoluiu para se tornar um sistema de videoconferncia
completo, sendo tambm expandido para gerar os sistemas GoToWebinar e GoToTraining.
A verso com compartilhamento de vdeo foi includa recentemente com a ferramenta
HDFaces, que ser comentada adiante.
O GoToMeeting oferecido apenas em forma de servio, por cerca de 50 dlares mensais.
suportam mais participantes, porm a um custo maior.
Assim como os sistemas de webconferncia citados, possui as funcionalidades bsicas
deste tipo de sistema:
11 udio e compartilhamento de tela.
11 Integrao com VoIP.
11 Controle de computador remoto.
11 Ferramentas de desenho.
11 Gravao de reunies.
11 Compartilhamento de aplicaes.
A capacidade neste plano de at 15 participantes. J os sistemas GoToWebinar e GoToTraining
11 Chat.
267
O GoToMeeting considerado um sistema web, pois possui as facilidades e caractersticas

de um sistema de webconferncia, embora necessite da instalao de um sistema prprio
na mquina do usurio. Essa instalao, porm, bastante simples, feita a partir do website
do GoToMeeting.
A imagem seguinte mostra a aplicao instalada para uso do GoToMeeting. esquerda, a
imagem do cone localizado na barra de notificaes do Windows para acesso aplicao.
direita, a imagem da aplicao em si, onde podemos ver a lista de usurios (no centro),
botes para configurar compartilhamento de desktop e controle remoto (no topo) e chat (na
parte inferior), entre outros. Os passos para a utilizao do GoToMeeting podem ser vistos
em Web Meeting | GoToMeeting.
w
Veja o tutorial das
funcionalidades do
GoToMeeting: How to
Use GoToMeeting - An
Informative Tutorial.
Figura 10.17
Imagem com o
cone de acesso
ao GoToMeeting
(esquerda) e janela
principal da aplicao (direita).
Uma novidade das solues da Citrix a ferramenta HDFaces, que servir como base comum
para as diversas solues da empresa e que visa a transmisso de vdeo em alta definio (HD).
O HDFaces suporta videoconferncias com uma resoluo mxima de 1920x960p, que pode
ser atingida atravs de apenas um vdeo, ou pode ser alcanada pela soma das resolues
de at 6 vdeos (6 vdeos de 640x320).
268
Figura 10.18
Demonstrao do
GoToMeeting com
o HDFaces.
Outras solues
Os sistemas citados at aqui foram escolhidos por serem os mais interessantes para os
propsitos deste curso. Mas existem outros, entre os quais:

11 Polycom PVX.
11 Isabel Videoconference.
11 Skype (com vdeo).
Alm dos sistemas que vimos, existem diversas outras solues, algumas com caractersticas semelhantes e outras muito diferentes, mas todas capazes de transmitir udio e vdeo
em tempo real.
Entre os sistemas no detalhados, selecionamos alguns para exibir imagens e links para
facilitar a consulta por parte dos interessados em conhecer melhor outras alternativas.
Polycom Telepresence m100

Sistema proprietrio que pode ser encontrado no website da Polycom. Possui uma verso
de avaliao (trial) com a limitao de permitir ligaes de no mximo 5 minutos (PVX) ou
30 dias (telepresence m100).
Isabel Videoconference
11 Open Source (GPL), com
11 cdigo-fonte em Morfeo-Forge: Isabel Project.

11 Sistema servidor distribudo em Live CD Ubuntu.
Isabel Videoconference uma soluo de videoconferncia com cdigo aberto (licena GPL),
desenvolvida pela Universidade Politcnica de Madrid. O sistema completo pode ser obtido
fazendo download do cdigo-fonte da aplicao ou atravs de um Live CD baseado na
distribuio Linux Ubuntu, em que o sistema distribudo. Com o Live CD, basta executar o
sistema operacional do CD, que j estar com o Isabel pr-instalado para ser executado.
Isabel utilizado por sistemas como o Global Plaza, que simplificadamente um servio
on-line que prov espaos para realizao de videoconferncias.
w Principais caractersticas do Isabel:
11 Cliente pode se conectar de duas formas: aplicao web no navegador ou pela aplicao desktop (apenas para Ubuntu 8.04 ou superior).
11 Bloco de notas.
11 Quadro branco.
11 Captura e compartilhamento de tela do computador.
11 Cliente SIP.
Skype (com vdeo)

O Skype muito conhecido para realizar comunicao por udio via VoIP, mas j pode
ser utilizado tambm para vdeo.

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

11 Efetue o download do VSee e clique em Try VSee Now.
11 Em dupla, explore todas as possibilidades da ferramenta, como compartilhamento de tela,
aplicaes (PPT e vdeos), compartilhamento do navegador, chat e gravao de vdeos.
11 Em grupo de at quatro alunos crie uma videoconferncia com mltiplos participantes.
271
272
Bibliografia
11 Adobe Systems Incorporated. Real Time Messaging Protocol Chunk Stream
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/
devnet/rtmp/pdf/rtmp_specification_1.0.pdf. 2009.
11 H.323 Plus Project (antigo Open H.323) http://www.h323plus.org/
11 HD changes the face of telepresence today
http://www.ivci.com/newsletter0207part2.html
11 High definition (HD) videoconferencing
http://www.tandbergusa.com/products/high_definition.jsp
11 Introduction to SIP
http://ftp.iptel.org/pub/ser/0.8.14/doc/html/sip_introduction.html
11 ITU-R. Methodology for the subjective assessment of the quality of television
picture. Junho de 2002. Rec. BT.500.
11 ITU-T. Subjective video quality assessment methods for multimedia
applications. Rec. p. 910, 1999.
11 KAMISETTY, Rao; BOJKOVIC, Zoran; MILOVANOVIC, Dragorad. Introduction
to Multimedia Communications: Applications, Middleware, Networking.
774 p. Wiley, 2006.
11 KEITH, Jack. Video Demystified: A Handbook for the Digital Engineer. 5th
Edition. Newnes. 976 p., 2007.
11 LOPES, Paulo. Telemedicina e Telesade. UNIFESP, agosto de 2000.
http://www.virtual.epm.br/material/tis/mat_apoio/telemed/telemed.pdf
11 Open H.323 Project http://www.openh323.org
11 Packetizer: videoconferencing http://www.packetizer.com/conf/
11 Referncia terminologia e padres de videoconferncia
http://www.c21video.com/standards.html
11 ROESLER, V.; CECAGNO, F.; DARONCO, Leonardo Crauss; DIXON, F. Mconf:
In: KARYDIS, Ioannis (Org.). Multimedia: a Multidisciplinary Approach to
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
an open source multiconference system for web and mobile devices.
273
11 ROSENBERG, J.; SCHULZRINNE, H.; CAMARILLO, G.; JOHNSTON, A.; PETERSON,

J.; SPARKS, R.; HANDLEY, M.; SCHOOLER, E. SIP: Session Initiation Protocol.
IETF: Internet Engineering Task Force. RFC 3261, junho de 2002.
11 SCHULZRINNE et al. RFC 3550 RTP: A Transport Protocol for Real-Time
Applications. Julho de 2003.
11 FIRESTONE, Scott; RAMALINGAM, Thiya; FRY, Steve. Voice and Video
Conferencing Fundamentals. Ciscopress.com. 2007.
11 STUN: Simple Traversal of UDP Through NATs
http://www.cin.ufpe.br/~mlmd/STUN.ppt
11 Telepresence Options Magazine
http://www.telepresenceoptions.com/magazine/
11 Videoconference archiving and streaming state of the art
http://www.terena.org/activities/tf-vvc/TF-VVC_Activity-G_vc-archiving-streaming_v0.3.pdf
11 V ideoconferncia (documento de referncia)
http://penta3.ufrgs.br/RNP/videoconferencia.pdf
11 Videoconferencing cookbook http://www.vide.net/cookbook/cookbook.en/
274
LIVRO DE APOIO AO CURSO
O livro de apoio ao curso Administrao de Videoconferncia

apresenta os protocolos utilizados para transmisso simultnea de udio, vdeo e dados. O aluno aprende a planejar,
instalar e gerenciar a infraestrutura necessria operao
de um sistema completo de videoconferncia. Atravs da
anlise das alternativas de implementao, ao final do curso estar apto a especificar a soluo de videoconferncia
mais adequada s necessidades de sua organizao; a administrar salas e montar o ambiente adequado para cada
situao; a operar o servio, fornecer suporte aos participantes e resolver os problemas mais comuns.
Este livro inclui os roteiros das atividades prticas e o contedo dos slides apresentados em sala de aula, apoiando
profissionais na disseminao deste conhecimento em
suas organizaes ou localidades de origem.

Administracao de Videoconferencia

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Administracao de Videoconferencia

Enviado por

Direitos autorais:

Formatos disponíveis

Administrao de

Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Equipe ESR (em ordem alfabtica)

Escola Superior de Redes

Rua Lauro Mller, 116 sala 1103

Dados Internacionais de Catalogao na Publicao (CIP)

3. Plano de numerao e gatekeeper

Arquitetura modular OpenSIPS 106

5. Redes de computadores e videoconferncia

7. Projeto de ambientes de videoconferncia

8. Transmisso via streaming

Modelos de servio de webconferncia227

10. Videoconferncia em desktop

Roteiro de Atividades 10271

Escola Superior de Redes

As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

Convenes utilizadas neste livro

Conceitos fundamentais e solues

Cenrios e aplicaes de videoconferncia, tipos de sistemas de videoconferncia, con-

Os sistemas de videoconferncia foram criados em meados da dcada de 1960. Para se ter

Captulo 1 - Conceitos fundamentais e solues

do modo como so atualmente conhecidos.

O primeiro sistema de videoconferncia data de 1964, ano em que a empresa americana

A partir da dcada de 1990, vrios aplicativos comearam a ganhar espao no mercado

Leia o artigo de Lori

Na sua 7 verso, o padro mais consolidado para videoconferncia.

Captulo 1 - Conceitos fundamentais e solues

relao ao termo webconferncia.

normalmente em locais diferentes, atravs de udio e vdeo.

Elementos de uma video/webconferncia

Captulo 1 - Conceitos fundamentais e solues

possibilita a transmisso dos dados e tambm a adaptao da transmisso conforme a rede

Equipamentos de udio e vdeo

No caso do vdeo, podem ser acrescentadas cmeras de vdeo auxiliares conectadas a

Sistemas dedicados (hardware)

Sistemas de mesa (desktop)

So normalmente compostos por um servidor, responsvel por coordenar as diversas

Captulo 1 - Conceitos fundamentais e solues

Os sistemas dedicados foram desenvolvidos principalmente para utilizao de grupos

Tandberg 990 MXP

Polycom VSX 7000s

de videoconferncia de grande porte, entre elas Polycom, Cisco, Tandberg e Sony.

O grande diferencial dos sistemas de mesa est no aproveitamento do computador, que

Captulo 1 - Conceitos fundamentais e solues

suportam SIP e H.323.

Cenrios: Ensino a Distncia (EAD)

zao adicional dos diversos pontos remotos participantes do evento.

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

Cenrios: reunies de trabalho

Captulo 1 - Conceitos fundamentais e solues

microfones, e para isso costumam ser utilizados microfones multidirecionais.

Operando desde 2006, a Rede Universitria de Telemedicina, um programa do Ministrio da

objetos fsicos. Valoriza e d maior impacto s apresentaes audiovisuais.

Captulo 1 - Conceitos fundamentais e solues

algumas dessas ferramentas de colaborao visual.

A seguir veremos outras abordagens para quadros interativos.

Um tablet um computador porttil (normalmente mais porttil e leve que um notebook)

Sistemas com alta definio

Razo de aspecto 4:3

Razo de aspecto 16:9

Widescreen (20% mais largo)

Captulo 1 - Conceitos fundamentais e solues