Administração de Videoconferência

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(cria o database opensips)
$ opensipsdbctl reinit opensips

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

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

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

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

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

(cria o database opensips)
$ opensipsdbctl reinit opensips

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

(cadastrar usurio)
(remover usurio)
112

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Para administrao de videoconferncias, muito importante ter conhecimento das portas e protocolos utilizados para monitoramento das atividades, configurao de equipamentos e, principalmente, importantes para configurao em redes protegidas por firewalls. A figura a seguir mostra um resumo das portas utilizadas em videoconferncias H.323: Porta 80 1503 1718 1719 1720 1731 1024-65535 1024-65535 1024-65535
Requerido Opcional Opcional Requerido Requerido Requerido Requerido Requerido Requerido Requerido Requerido
Protocolo TCP esttico TCP esttico UDP esttico UDP esttico TCP esttico TCP esttico TCP dinmico UDP dinmico UDP dinmico UDP dinmico
Descrio Interface HTTP T.120 Descoberta de gatekeeper Gatekeeper RAS H.323 Call Setup Audio Call Control H.245 RTP (vdeo) RTP (udio) RTCP
Clientes
MCU X
GK
X X X X X X X X X X X X X X X X X
Figura 5.13 Portas e protocolos uti

Idioma

Administração de Videoconferência

Enviado por

Dados do documento

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Administração de Videoconferência

Enviado por

Direitos autorais:

Administrao de

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Graciela M. L. Martins Leonardo Daronco Valter Roesler

Rio de Janeiro Escola Superior de Redes 2013

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Equipe ESR (em ordem alfabtica)

Escola Superior de Redes

3. Plano de numerao e gatekeeper

5. Redes de computadores e videoconferncia

7. Projeto de ambientes de videoconferncia

8. Transmisso via streaming

10. V ideoconferncia em desktop

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

Escola Superior de Redes

Convenes utilizadas neste livro

Figura 1.1 Picture phone AT&T 1964.

Captulo 1 - Conceitos fundamentais e solues

Figura 1.2 Servio da Bell System.

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

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

Elementos de uma video/webconferncia

Transmisso Codicao Vdeo Decodicao

Captulo 1 - Conceitos fundamentais e solues

Equipamentos de udio e vdeo

Sistemas dedicados (hardware)

Sistemas de mesa (desktop)

Tandberg 990 MXP

Polycom VSX 7000s

Figura 1.5 Estrutura de videoconferncia de mesa.

Figura 1.6 Exemplos de sistema de videoconferncia de mesa.

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

Captulo 1 - Conceitos fundamentais e solues

Figura 1.7 Exemplos de sistemas de webconferncia.

Cenrios: Ensino a Distncia (EAD)

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

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

Cenrios: reunies de trabalho

Figura 1.11 Exemplo de sala de telepresena (Cisco).

Captulo 1 - Conceitos fundamentais e solues

Figura 1.13 Cmera de documentos.

StarBoard Hitachi Entrada RGB, sada USB

Figura 1.14 Exemplos de quadro interativo.

A seguir veremos outras abordagens para quadros interativos.

Figura 1.15 Tablet.

Sistemas com alta definio

Razo de aspecto 4:3

Razo de aspecto 16:9

Figura 1.16 Exemplos de Standard Definition e High Definition.

Widescreen (20% mais largo)

Captulo 1 - Conceitos fundamentais e solues

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

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

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

Cmera Tandberg Precision HD

Polycom HDX Series

Monitor 16:9 Video 4:3

Monitor 4:3 Video 16:9

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

Figura 1.20 Tcnica de redimensionamento de vdeo.

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

Captulo 1 - Conceitos fundamentais e solues

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

Imagem local e remota

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

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