Colaboração visual: Implementando o trabalho cooperativo...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMÁTICA

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS DA COMPUTAÇÃO

Colaboração visual:Implementando o trabalho cooperativo com H.323

por

ALEXEI KORB

TI- CPGCC – UFRGS

Profa. Dra. Liane Margarida Rockenbach TaroucoOrientadora

Porto Alegre, Setembro de 2001.

2

Sumário

SUMÁRIO......................................................................................................................................................... 2

LISTA DE ABREVIATURAS ......................................................................................................................... 4

LISTA DE FIGURAS....................................................................................................................................... 6

RESUMO........................................................................................................................................................... 7

ABSTRACT....................................................................................................................................................... 8

1. INTRODUÇÃO .................................................................................................................................. 9

2. SISTEMAS DE TELECONFERÊNCIA: VISÃO GERAL. ......................................................... 11

2.1. BENEFÍCIOS .................................................................................................................................... 122.2. TELECONFERÊNCIA X COLABORAÇÃO VISUAL ............................................................................... 122.3. TRANSMISSÃO MULTIMÍDIA EM REDES DE PACOTES........................................................................ 14

2.3.1. Codecs de áudio ................................................................................................................... 142.3.2. Codecs de vídeo.................................................................................................................... 172.3.3. Transporte de sinais multimídia na Internet: RTP/RTCP .................................................... 19

3. O H.323 – SISTEMAS DE COMUNICAÇÃO MULTIMÍDIA BASEADO EM PACOTES .... 22

3.1. INTRODUÇÃO.................................................................................................................................. 223.2. DESCRIÇÃO DO SISTEMA................................................................................................................. 22

3.2.1. Terminais H.323................................................................................................................... 233.2.2. Gateways .............................................................................................................................. 253.2.3. Gatekeepers.......................................................................................................................... 273.2.4. MC e MP .............................................................................................................................. 293.2.5. MCU..................................................................................................................................... 30

4. PROCEDIMENTOS DE SINALIZAÇÃO DE CHAMADAS...................................................... 31

4.1. ESTABELECIMENTO DE CHAMADA.................................................................................................. 324.1.1. Estabelecimento de chamadas simples (sem registro com gatekeeper) ........................... 334.1.2. Ambos pontos registrados com o mesmo Gatekeeper ..................................................... 334.1.3. Pontos registrados com diferentes Gatekeepers............................................................... 39

4.2. COMUNICAÇÃO INICIAL E TROCA DE CAPACIDADES........................................................................ 404.3. COMUNICAÇÃO MULTIMÍDIA .......................................................................................................... 414.4. ENCERRAMENTO DA CHAMADA ...................................................................................................... 42

5. CONFERÊNCIAS MULTIPONTO................................................................................................ 45

5.1. CONFERÊNCIAS CENTRALIZADAS.................................................................................................... 455.2. CONFERÊNCIAS DESCENTRALIZADAS ............................................................................................. 465.3. CONFERENCIAS HÍBRIDAS .............................................................................................................. 47

3

6. PROCEDIMENTOS ADICIONAIS PARA O ESTABELECIMENTO DE CHAMADAS....... 49

6.1. SINALIZAÇÃO OPCIONAL USANDO A MENSAGEM LRQ.................................................................... 496.2. PROCEDIMENTO DE CONEXÃO RÁPIDA............................................................................................ 50

7. CONCLUSÃO................................................................................................................................... 52

8. BIBLIOGRAFIA .............................................................................................................................. 54

4

Lista de Abreviaturas

A/DACELPADPCMB-ISDNCIFCodecCSDNSCND/ADRQDCFDSLGSTNGCFGRJGRQIETFIPIRRISDNISOITU-TKbpsLANLD-CELPMANMbpsMCMCSMCUMHzMIPSMPMP-MLQNTSCPCMPSDNPSTNQCIFQoSRASRCFRRJ

Analógico/DigitalAlgebraic Codebook Excitation Linear PredictionAdaptive Differential Pulse-Code ModulationBroadband – Integraded Services Digital NetworkCommon Intermediate FormatCoder/DecoderCircuit Switched Data NetworkCircuit Switched NetworkDigital/AnalógicoDisengage RequestDisengage ConfirmDigital Subscriber LineGeneral Switched Telephone NetworkGatekeeper ConfirmationGatekeeper RejectGatekeeper RequestInternet Engineering Task ForceInternet ProtocolInformation Request ResponseIntegraded Services Digital NetworkInternational Standard OrganizationInternational Telecomunication Union – TelecommunicationKilobits per secondLocal Area NetworkLow-Delay Code Excited Linear PredictionMetropolitan Area NetworkMegabits per secondMultipoint ControllerMultipoint Communication ServiceMultipoint Control UnitMegahertsMillion Instructions Per SecondMultipoint ProcessorMultiPulse-Maximum Likelihood QuantizerNational Television Standards CommiteePulse-Code ModulationPacket Switched Data NetworkPublic Switched Telephone NetworkQuarter Commom Intermediate FormatQuality of ServiceRegistration, Admission and StatusRegistration ConfirmationRegistration Reject

5

RRQRTPRTCPTCPUDPUCFURQWAN

Registration RequestReal Time ProtocolReal Time Control ProtocolTransport Control ProtocolUser Data ProtocolUnregister ConfirmationUnregister Request Wide Área Network

6

Lista de Figuras

Figura 1 – Teleconferência multiponto através da WAN entre diversas pessoas localizadasremotamente nos pontos A, B eC............................................................................................................................................10Figura 2 – Colaboração visual através da WAN entre diversas pessoas localizadasremotamente nos portos A, B, C e D, empregando diversas formas de comunicação: áudio,vídeo dados...........................................................................................................................12Figura 3 – Transmissão de voz em redes digitais usando codecs para a redução da taxa debits.........................................................................................................................................14Figura 4 – Transmissão de vídeo em redes digitais usando codecs para a redução da taxa debits.........................................................................................................................................17Figura 5 – Representação de um terminal H.323..................................................................22Figura 6 – Configurações de um gateway.............................................................................25Figura 7 – ZonaH.323...........................................................................................................26Figura 8 - Localizações possíveis para o MC e MP..............................................................28Figura 9: Captura da de uma sessão H.323 mostrando a fase de estabelecimento deconexão. (usando o Lan Explorer v.3.6 da Sunrise Telecom)..............................................31Figura 10 – Estabelecimento de chamadas básico. Sem Gatgekeepers................................32Figura 11 – Descobrimento automático do gatekeeper.........................................................33Figura 12 – Fase de registro com o gatekeeper.....................................................................34Figura 13 – Estabelecimento de chamadas roteado..............................................................34Figura 14 – Estabelecimento de chamadas direto.................................................................35Figura 15 – Canal de controle no modo roteado pelo gatekeeper.........................................35Figura 16 – Dois pontos registrados pelo mesmo gatekeeper, no modo de sinalizaçãoroteado...................................................................................................................................37Figura 17 – Dois pontos registrados pelo mesmo gatekeeper,no modo de sinalização direto...............................................................................................................................................37Figura 18 – Dois pontos registrados em gatekeepers distintos,no modo de sinalizaçãoDireto/Roteado......................................................................................................................39Figura 19 – Encerramento de chamada iniciado pelo terminal.............................................42Figura 20 – Encerramento de chamada iniciado pelo gatekeeper.........................................43Figura 21 – Conferência no modo centralizado....................................................................44Figura 22 – Conferência no modo centralizado....................................................................45Figura 23 – Conferência Híbrida com áudio centralizado....................................................47Figura 24 – Conferência Híbrida com áudio centralizado....................................................47Figura 25 – Sinalização opcional usando a mensagem LRQ................................................49

7

Resumo

A informação e o conhecimento das pessoas tornaram-se o mais importante ativo dascompanhias no final do século XX e início do século XXI. Entretanto, somente através dacomunicação entre os indivíduos e do compartilhamento das informações e doconhecimento, as empresas poderão obter os verdadeiros benefícios deste ativo.

A Internet, possibilitou que as pessoas pudessem obter e trocar informações a partir dequalquer lugar do mundo e o melhoramento da infra-estrutura das redes que compõe aInternet oferecendo suporte a banda larga, permitem que informações multimídia sejamtransportados pela Internet com ótima qualidade.

A colaboração visual oferece uma maneira para que um grupo de pessoas possa trocar ecompartilhar informações multimídia através da Internet, mesmo que elas estejamseparadas por uma simples parede ou vários continentes, permitindo que estes grupos seencontrem em reuniões virtuais e trabalhem colaborativamente.

Este trabalho tem a intenção de mostrar o que é a colaboração visual, qual o cenário emque ela está inserida e como o protocolo H.323 implementa as funções necessárias parasistemas de colaboração visual que englobam principalmente a capacidade de troca desinais de áudio, vídeo e dados de modo síncrono e assíncrono.

São explicados os conceitos de teleconferência, videoconferência e colaboração visual,bem como são mostrados ao leitor os requerimentos para a transmissão de sinais de áudio evídeo através da Internet.

Em seguida, são discutidos os principais tópicos da recomendação H.323, ilustrandocomo o ITU-T se propôs a resolver os problemas de transmissão de sinais multimídia emredes de pacotes, para atingir a interoperabilidade entre equipamentos de diversosfabricantes. Os pontos abordados no trabalho envolvem também: os componentes H.323(gateways, gatekeepers, MC, MP e MCU), os procedimentos de estabelecimento dechamadas, canal de controle e canal RAS. O trabalho fala também sobre os modelos deconferências multiponto e alternativas de procedimentos para conexão rápida.

Palavras chaves: Multimídia, Internet, colaboração visual, recomendação H.323

8

Abstract

The information and people knowlegment, became the most important company´s activesin the end of XX century and the begining of the XXI century. However, just throughtcommunication between this individuals and throught information and knowlegmentsharing the companies will obtain the true benefits of this actives.

The Internet allows people obtain and exchange information to and from any place in theworld, and the improvement of the physical infrastructure that makes the Internet ready forbroadband applications, allows the transmition of multimedia signals trough the Internetwith nice quality.

The visual collaboration provides a means for groups of individuals exchange and sharemultimedia information through the Internet, even if they are separated by a single wall orseveral continents, allowing this individuals to have a virtual meeting and workcollaboratively one which other.

This text, intent to shows what visual collaboration is, in which environment visualcollaboration fits better and how the H.323 set of protocols implement the functions thatvisual collaboration systems needs. This needs embraces mainly the capacity of transmitaudio, video and data signals, synchronously and asynchronously.

In the paper, the concepts of teleconferencing, videoconferencing and visual collaborationare explained, as well as all the requirements for the transmission of audio and videosignals over the Internet.

Following, we start a discussion about the main issues covered in H.323 standard, showinghow the ITU-T has been proposed to solve the problems involved in the transmission ofmultimedia signals over packets networks, to reach the interoperability among devices fromdifferent vendors. This points includes: the H.323 components (gateways, gatekeepers, MC,MP e MCU), the procedures for call setup, control channel establishment and RAS channelestablishment. This paper also points the multipoint conferences models and the differentalternatives for the setup fase with faster procedures.

Key words: Multimedia, Internet, visual collaboration, H.323 recommendation

9

1. IntroduçãoNa era da informação, a simples posse deste ativo não significa mais sinônimo de poder

e tampouco serve para garantir o sucesso e o crescimento de qualquer organização. Naverdade é o compartilhamento da informação – o que chamo informação com inteligência –que vai determinar o sucesso ou não da organização. Para que isso aconteça soluçõesinovadoras para comunicação entre as pessoas são necessárias.

Na última década, o IP e a própria Internet, se tornaram a arquitetura predominante eonipresente em qualquer ambiente de TI. A Web ajudou a facilitar e disseminar estacomunicação, dando vida a Internet.

Soluções de colaboração visual permitem que pessoas que estejam separadas peladistância possam trabalhar colaborativamente juntas, adicionando inteligência àinformação, criando valor para sua organização. A colaboração visual é construída em cimade diversas ferramentas na qual estão incluídos: videoconferência, vídeo streamming,compartilhamento e transferência de informações e imagens, ferramentas de tomada dedecisão e muito mais.

Este novo tipo de aplicação possui diferentes requerimentos para atraso, variação noatraso, perda de pacotes, largura de banda, dessequencialização de pacotes edisponibilidade. Por exemplo, os sinais de voz, requerem jitter muito baixo, atrasounidirecional menor que 100 ms e largura de banda garantida na faixa de 8 Kbps e 64 Kbps,para uma boa interação humana, enquanto que para transferência de arquivos, perda depacotes é muito mais grave do que jitter ou atraso.

Para que a transmissão multimídia através da Internet seja possível, os sinais de vídeodevem ser comprimidos de modo que eles possam ser acomodados em uma largura debanda menor. O dispositivo que executa esta compressão (e descompressão) chama-secodec. Os primeiros sistemas desenvolvidos comercialmente empregavam tecnologiasproprietárias de modo que os sistemas de colaboração visual apenas funcionavam se oscodecs destes sistemas fossem do mesmo fabricante. Sistemas de fabricantes diferentes nãoconseguiam se comunicar. A interoperabilidade esperada por todos foi suprimida pela faltade protocolos e algorítmos de compressão padronizados.

O principal motivo que levou os diversos fabricantes a abandonar seus protocolosproprietários e adotar a dupla H.323/T.120 para comunicação multimídia em tempo realatravés da Internet foi sem dúvida a questão da interoperabilidade com produtos de outrosfabricantes. Além disso, a combinação deste conjunto de protocolos proporciona umaexperiência de comunicação mais enriquecedora, através da utilização de características eferramentas de colaboração e compartilhamento de recursos. Outra motivação significante éque sistemas construídos em cima do H.323 mantêm a compatibilidade com sistemas maisantigos que já possuem uma grande base instalada, tal como sistemas H.320.

10

O objetivo deste trabalho foi realizar um estudo profundo através da revisãobibliográfica, juntando idéias das recomendações do ITU-T, bem como de artigos e livrosde pessoas que participam ativamente do desenvolvimento de produtos baseados no H.323,para apresentar ao leitor uma visão geral do que é a recomendação H.323, quais são os seuscomponentes e que funções são executadas por cada componente do sistema H.323.

Nosso intuito também foi ilustrar as fases de comunicação de um sistema H.323, isto é,como acontecem os procedimentos para o estabelecimento de uma chamada, a troca desinais multimídia (áudio vídeo e dados), e finalmente o encerramento das chamadas. Otrabalho, entretanto, não enfoca os serviços suplementares oferecidos por entidades H.323,nem endereça questões específicas como segurança e QoS, por entendermos que estestópicos são complexos e merecem atenção especial em trabalhos específicos.

O texto está organizado da seguinte maneira:

Na sessão 2, o leitor é introduzido ao assunto Teleconferência, quais seus benefícios,quais as diferenças entre sistemas de teleconferências e vídeo conferências. Também éabordado a necessidade por novas formas de comunicação e finalmente explicado o que é acolaboração visual

As sessões 3 e 4 são o centro do trabalho. Nelas é apresentada o funcionamento geral deum sistema H.323. A sessão 3 descreve detalhadamente e individualmente cada entidadeque compõe um sistema H.323, suas características e requerimentos.

A sessão 4, descreve então, a interação entre os componentes H.323 para: estabeleceruma sessão ou conferência H.323, quais as fases para o estabelecimento de uma chamada,como são abertos os canais de mídia e como as chamadas devem ser encerradas.

A sessão 5 ilustra, como o H.323 trata as conferências multiponto e quais tipos deconferências multiponto existem em um sistema H.323. Aqui são abordadas as conferênciascentralizadas, descentralizadas e híbridas.

A última sessão descreve dois procedimentos adicionais definidos para oestabelecimento de chamadas, que visam otimizar o tempo de estabelecimento de chamadae troca de sinais multimídia, através da redução de etapas necessárias no processo deinicialização das chamadas.

11

2. Sistemas de Teleconferência: visão geral.A teleconferência é uma reunião entre duas ou mais pessoas que se encontram

separadas geograficamente, através da utilização de tecnologias de comunicação, quepermitem a conversação e opcionalmente a visualização dos participantes, de formabidirecional e em tempo-real, possibilitando a interação on-line dos participantes.

A introdução destes sistemas, primeiramente através da rede pública de telefonia e emseguida com sistemas H.320 usando a tecnologia ISDN, permitiu que reuniões pudessemser estabelecidas, sem a necessidade de agrupar os participantes fisicamente no mesmolocal. Portanto a videoconferência se destina principalmente ao encontro virtual de pessoas.

Sistemas de teleconferência podem ser classificados em três categorias segundoSchaphorst [SCH 99]: apenas áudio, audiográficas e com vídeo “full motion”.Videoconferências “full motion” podem ainda ser divididas em duas: interativas etransmissão broadcast.

De maneira simplificada um sistema de teleconferência é composto de terminais deteleconferência interconectados por uma rede de comunicação (LAN, MAN, WAN), quepermite a interação bidirecional entre os participantes da conferência, por isso a capacidadede comunicação multiponto têm grande importância nestes sistemas.

Figura 1 – Teleconferência multiponto através da WAN entre diversas pessoasLocalizadas remotamente nos pontos A, B e C.

12

2.1. Benefícios

Sistemas de teleconferência permitem a interação bidirecional em tempo real entre osparticipantes, aumentando a compreensão e a qualidade da discussão, ajudando osparticipantes a se sentirem mais próximos uns dos outros.

Podemos ainda listar diversos outros benefícios, também apontados na obra deSchaphorst [SCH 99]:

• Tomada de Decisões mais rápidas – Videoconferências podem ser estabelecidascom menor dificuldade que encontros in loco e pessoas separadas porkilômetros podem compartilhar idéias e informações.

• Decisões mais qualificadas – Como não existem custos adicionais porparticipante, as conferências podem incluir todas as pessoas responsáveis. Seviagens fossem necessárias, provavelmente isto não ocorreria, ou pelo menosseria muito mais difícil de acontecer.

• Aumento da produtividade - Funcionários altamente capacitados não podemficar perdendo tempo nos aeroportos. Com a videoconferência, se a reunião duraduas horas, os envolvidos irão gastar apenas duas horas do seu tempo.

• Redução dos custos de viagens – Muitos custos estão associados com as viagensoficiais, pois viagens envolvem passagens, hospedagem, alimentação,estacionamento e assim por diante. A videoconferência ajuda a eliminar estesgastos.

• Redução do cansaço – Viagens de negócios são, geralmente, cansativas,podendo resultar em fadiga e performance reduzida dos colaboradores. Estetambém é um grande benefício da videoconferência.

• Ajuda na construção de um time – Através de encontros freqüentes, juntandonas reuniões todos os envolvidos, é possível atingir decisões por consenso e nãodecisões verticais (impostas de cima para baixo), o que resulta em maior grau demotivação e energia para todos os membros da organização.

Outro ponto importante a ser ressaltado é a eliminação o risco, ou aumento dasegurança dos colaboradores. Funcionários de grande importância estratégica, sempre queviajam estão correndo risco. A videoconferência elimina ou pelo menos reduz a um graumínimo necessário, a exposição destes funcionários, a este tipo de risco.

2.2. Teleconferência x Colaboração Visual

Quando a Internet tornou-se realmente a maior rede do planeta e o maior depósito deinformações do mundo, novas formas de comunicação começaram a ser idealizadas etornaram-se necessárias. A utilização da Internet para a transmissão de informações eliminao gasto com a manutenção de linhas dedicadas, o que por si só já é um grande motivo paraa utilização da Internet como meio de comunicação de longa distância.

13

Além disso, novas tecnologias como cable modems e DSL, levam o acesso à Internetaté o usuário final – última milha – com bandas acima de 128 Kbps, conexão contínua epreços extremamente competitivos.

O surgimento de um grande número de tecnologias que visam garantir a segurança equalidade nas transmissões via Internet, a febre de tornar todas as aplicações baseadas naWeb, a possibilidade de transmissão de sinais de áudio e vídeo através da Internet,prepararam o caminho para que as pessoas agora passem a demandar comunicação visual –multimídia – e não se contentem apenas com a comunicação através da voz. Acomunicação visual começa a se tornar realidade e mais do que isso, uma necessidade.

Apoiando-se nos benefícios alcançados pela videoconferência e levando emconsideração todas estas inovações, surge a colaboração visual, que estende o conceito deencontros virtuais em várias dimensões.

A colaboração visual oferece uma maneira para que pessoas ou grupos de indivíduosque estejam separados pela distância possam trabalhar juntos, adicionando valor eaumentando os ativos de suas empresas, reduzindo o tempo e a distância que as separam. Acolaboração visual é construída em cima de diversas ferramentas, na qual estão incluídos:videoconferência, vídeo stream, compartilhamento e transferência de informações eimagens (colaboração em cima de dados) e muito mais.

Figura 2 – Colaboração visual através da WAN entre diversas pessoasLocalizadas remotamente nos portos A, B, C e D, empregando.

Diversas formas de comunicação: áudio, vídeo e dados.

14

2.3. Transmissão multimídia em redes de pacotes

Em sistemas de colaboração visual, os sinais de áudio, vídeo e dados – sinaismultimídia – são compartilhados interativamente por todos os participantes da sessão.Sinais de vídeo são extremamente grandes (pesados) e requerem a transmissão de grandesvolumes de informações de um lugar para outro. Para realizar esta tarefa mantendo aqualidade esperada, canais de comunicação de grande capacidade devem ser utilizados. Amatemática é simples, quanto maior a qualidade esperada, maior a largura de bandanecessária, maior o custo associado.

A utilização da Internet para aplicações desta natureza, substituindo o uso de canaisdedicados, ajuda a reduzir grande parte dos custos associados à conectividade necessária naimplementação de sistemas de tele/vídeo conferências. Entretanto, redes de pacotes, quenão possuem uma taxa de transferência estável, podem ocasionar congestionamentos ecomo conseqüências perdas de pacotes, atraso na entrega dos pacotes e jitter, causandodeterioração na qualidade dos sinais de áudio e vídeo principalmente.

Para que a transmissão multimídia em tempo real através da Internet seja possível, ossinais de áudio e vídeo devem ser comprimidos de modo que eles possam ser acomodadosem uma largura de banda bem menor. O dispositivo que executa esta compressão (edescompressão) chama-se codec.

Os primeiros sistemas desenvolvidos comercialmente empregavam tecnologiasproprietárias de modo que os sistemas de colaboração visual apenas funcionavam se oscodecs destes sistemas eram do mesmo fabricante. Sistemas de fabricantes diferentes nãoconseguiam se comunicar. A interoperabilidade esperada por todos foi suprimida pela faltade protocolos e algoritmos de compressão padronizados.

Para resolver o problema, o ITU-T definiu diversos codecs de modo a garantir ainteroperabilidade entre os fabricantes. Atualmente os produtos que desejarem se fazerpresentes no mercado deverão necessariamente se apoiar nestes padrões para a transmissãode áudio e/ou vídeo.

2.3.1. Codecs de áudio

Para transmissão de sinais de áudio na Internet, é necessário primeiramente digitalizarestes sinais de modo a transformar os sinais da voz humana - sinais analógicos – em dadosque possam ser transportados através da Internet.

Esta tarefa é executada na origem por um conversor Analógico-Digital (A/D), que tem atarefa de transformar os sinais analógicos produzidos pelo microfone em uma corrente dedados digitais que possam ser transmitidos em pacotes através da rede. No destino umconversor Digital-Analógico (D/A) transforma as amostras digitais de áudio em sinaisanalógicos que serão reproduzidos no alto-falante. Geralmente o sinal digitalizado possuiuma taxa de bits de 64 Kbps (uma amostra de oito bits a cada 125 µs)

15

Os codecs são compostos de codificadores (encoders) e decodificadores (decoders).O codificador tem a função de comprimir as amostras de dados digitais resultantes doconversor A/D removendo as informações redundantes, de forma a reduzir a quantidade deinformações a serem transmitidas na rede, diminuindo a largura de banda necessária para atransmissão destes sinais. Os decodificadores executam a operação inversa, recuperando asamostras digitais originais, a partir dos dados comprimidos enviados pelo codificador eenviando-os para o conversor D/A.

Figura 3 – Transmissão de voz em redes digitais usando codecsPara a redução da taxa de bits.

Quatro atributos estão relacionados com os encoders de voz escolhidos paratransmissão. Estes atributos vão determinar basicamente a qualidade de voz obtida narecepção e são descritos logo a seguir. A redução da taxa de bit, conseguida através dacompressão/descompressão realizada pelos encoders, implica em aumento do atraso eredução da qualidade dos sinais de áudio transmitidos.

Dois atrasos estão envolvidos na transmissão de voz sobre a Internet: o atraso doencoder e o atraso de transmissão. O primeiro está relacionado com o encoder utilizado, osegundo relacionado com o tipo de rede usada na transmissão dos sinais. Como sabemos, aInternet não foi projetada para o transporte em tempo real e não oferece qualidade deserviço para garantir limites máximos de atraso e jitter. Este atraso para transmissão emredes de pacotes não deve ser superior a 300 ms para uma interação humana aceitávelocorra.

Os atributos que caracterizam um encoder são:

• Taxa de bit – Para os sinais de vídeo, quanto maior a taxa de bits maior aqualidade. Assim, quanto menor for a taxa de bit utilizada pelo áudio melhorserá aproveitada a largura de banda disponível. Esta diminuição se dá peloaumento da compressão que implica em diminuição da qualidade.

• Qualidade – A qualidade dos codecs é medida pelo “mean option score”. Aidéia é não causar uma distorção muito grande que possa incomodar ou cansar

16

quem está ouvindo. Uma das maneiras de aumentar a qualidade é incluirdetectores de atividade de voz. Durante a inatividade o encoder é desligado eeste espaço de tempo é alocado para prover maior qualidade, entretanto autilização destes detectores de silêncio pode influenciar na performance ecomplexidade do codec.

• Complexidade – A complexidade é medida em MIPS (Milhões de Instruçõespor Segundo), que um codec (codificador e decodificador) necessita paraexecutar os algoritmos de compressão e descompressão. Quanto maior o númerode instruções por segundo necessárias para comprimir/descomprimir os sinais,maior a complexidade do codec.

• Atraso – O atraso introduzido pelo codec depende de alguns fatores comotamanho dos frames produzidos pelo codec. Mas também depende o tempo deprocessamento para codificar a fala.

Para algumas aplicações, alguns dos atributos são predeterminados enquanto que paraoutras aplicações escolhas podem ser feitas entre estes atributos. Por exemplo, o aumentoda qualidade da transmissão, está ligada ao aumento da taxa de bit ou complexidade.

Os principais encoders de voz padronizados pelo ITU-T estão rapidamente descritosabaixo:

• G.711 – Também conhecido como PCM, esta recomendação definida em 1977,codifica sinais de áudio em uma largura de banda de 3kHz, a uma taxa de 64Kbps. O padrão especifica dois modos para a codificação dos sinais: µ-law e A-law. A recomendação especifica define que a amostragem dos sinais deve serrealizada a uma taxa de 8000 amostras por segundo, e cada amostra codificadacom a precisão e 8 bits, produzindo a taxa de transmissão de 64 Kbps.

• G.721 – Definida em 1988, o G721 especifica que o áudio analógico de 3 kHzdeve ser codificado tomando como entrada os sinais PCM gerados pelo G.711,produzindo uma taxa de transferência de 32 Kbps. Os sinais gerados pelo G.721são levemente inferiores ao sinal gerado pelo G.711.

• G.722 – O único padrão presente para voz a 7 kHz é o G.722, usadoprincipalmente em tele e vídeo conferencia em sistemas H.320 com conexõessuperiores a 128 Kbps. O padrão torna possível a codificação para transmissãoem taxas de 48, 56 e 64 Kbps.

• G.723.1 – Especifica duas taxas de transferência de bits diferentes: 5,3 kbps e6,3 kbps, ambas obrigatórias. O encoder foi desenvolvido para atingir asmenores taxas de bit possíveis e trabalhar em conjunto com o padrão H.324. Ébaseado na estrutura geral do codificador MP-MLQ, usado para a versão de taxamais alta (6,3 Kbps). A versão com taxa mais baixa usa o modelo ACELP.

17

• G.726 – Este encoder utiliza o algoritmo ADPCM, para comprimir as amostrasde 8 bits do G.711, para amostras de 2, bit, 3 bit, 4 bit ou 5 bit, a uma taxa de16, 24, 32 ou 40 Kbps. É possível converter novamente as amostras G.726 paraamostras G.711.

• G.728 – Este utiliza o algoritmo LD-CELP, para comprimir blocos de 0.625 msde 5 amostras de 16 bit, em 10 amostras de 10 bit, produzindo uma taxa de 16Kbps.

• G.729 – Este encoder usa o algoritmo CS-ACELP para comprimir blocos de 10ms

2.3.2. Codecs de vídeo

Para poder apresentar aos usuários a imagem em tempo real dos participantes de umencontro virtual, os sistemas de colaboração visual possuem a necessidade de capturar,codificar e transportar sinais de vídeo. O ITU-T definiu dois padrões para acodificação/decodificação e transporte de sinais de vídeo nestes sistemas: H.261 e H.263.

Da mesma forma que os sinais de áudio, os sinais de vídeo devem ser digitalizadosantes de serem transmitidos através de uma rede digital, a menos que já tenham sidoproduzidos no formato digital.

O conceito aplicado para a codificação dos sinais de vídeo é muito parecido com oconceito mencionado para a parte de áudio, embora a demanda por banda seja bem maior.Além disso, os sinais de vídeo diferem dos sinais de voz porque quando se está falando,esta corrente de bits deve ser enviada e reproduzida exatamente na mesma seqüência.

Com sinais de vídeo a coisa é diferente, porque em uma imagem existem partes quemudam continuamente, como a boca da pessoa que está falando, mas existem outras partesque não mudam freqüentemente, como a imagem de fundo. Estas questões são levadas emconsideração quando os sinais são codificados, e entregues para transmissão.

As imagens de vídeo consistem em uma série de figuras seqüenciais que sãocapturadas a uma taxa chamada de taxa de frames. Estas figuras são chamadas de frames.Quanto maior for a taxa de frame melhor será a qualidade da imagem exibida, mas emcompensação maior será a largura de banda necessária. A taxa requerida pelo modeloNTSC adotado pelo sistema de TV norte americano, requer pelo menos uma largura debanda de 90 Mbps da rede. Esta mesma imagem possui uma taxa de frame de 30 frames porsegundo.

Quando os sinais são procedentes de uma fonte analógica eles devem serdigitalizados para serem transportados em uma rede IP. Assim, o sinal entra no quechamamos de sistema de captura. Este sistema é o responsável por digitalizar os sinais.Outra função executada pelo sistema de captura é transformar o modelo de cores utilizado

18

pela fonte do vídeo para um modelo aceitável pelo H.261 e/ou H.263. Além disso, estesistema redimensiona os frames de modo a torná-los compatíveis com os formatos aceitospelo H.261 e H.263 (CIF, QCIF, etc.).

Estes sinais ainda requerem largura de banda bastante alta, pois não foramcomprimidos. Neste momento o encoder codifica os sinais que são transmitidos na rede. Nachegada os sinais são decodificados e entregues para o sistema de exibição.

O sistema de exibição transforma o sistema de cores e formato dos frames para oformato necessário para exibição e exibe a imagem na tela do usuário.

Figura 4 – Transmissão de vídeo em redes digitais usando codecsPara a redução da taxa de bits.

Os codecs definidos pelo ITU-T são:

• H.261 – Especificado pelo ITU-T para baixo atraso, taxas de transferênciastambém baixas, todas múltiplas de 64 Kbps até 1.92 Mbps. Opera comresolução QCIF e CIF e uma taxa de frame de 29.97 MHz. Para maioresinformações consulte a recomendação H.261.

19

• H.263 (versão original) – Foi publicada em 1996, e evoluiu para a versãodois. Projetado para taxas muito pequenas iniciando em 10 Kbps, trabalhabem em taxas até 2 Mbps. Possui muitas funcionalidades do H.261, mas suaperformance é mais eficiente por que inclui melhoramentos em termos decompensação de movimentos, quantização e codificação. Além de QCIF eCIF, inclui Sub-CIF, 4CIF e 16CIF.

• H.263 versão 2 –Também conhecido como H.263+ foi especificado em 1998e inclui melhoramentos em relação à eficiência de compressão, flexibilidadede erros e escalabilidade de taxa de transferência para redes sem fio ebaseada em pacotes. Mantém a compatibilidade com a versão anterior, masalém das resoluções de frames do H.263, também inclui tamanhos de framescustomizáveis.

2.3.3. Transporte de sinais multimídia na Internet: RTP/RTCP

Como sabemos a Internet não foi desenvolvida para o transporte de sinais sensíveisao tempo. Quando este tipo de sinal é transmitido sobre a Internet, a comunicação ficasujeita a introdução de atrasos e variação no atraso (jitter). Dependendo da capacidade darede e da carga a qual a rede está submetida, o atraso e o jitter introduzidos prejudicam atransmissão do sinal, deteriorando a qualidade da comunicação.

Quando dados são transmitidos pela Internet usando o protocolo de transporte TCP,questões como controle de fluxo, controle de erros e controle de congestionamento, sãogerenciados por este protocolo. Assim, quando um pacote chega ao seu destino fora deordem, ou quando um pacote é perdido, seja por ruído na rede ou por congestionamento, oTCP, toma as devidas medidas para a correção do problema: reordena os pacotescolocando-os em sua ordem original e pede para que a origem retransmita as informaçõesperdidas ou que chegaram com erro ao destino. Outras funções como descarte de pacotesduplicados ou ajuste da taxa de transmissão, também são realizadas pelo TCP. Isto por queo TCP implementa um serviço de transporte seguro, com streams orientadas a conexão.

Entretanto, para aplicações de tempo real, que possuem um tempo mínimo de atrasopermitido, a estratégia de retransmissão dos dados perdidos não é adequada, pois não existetempo para isso. A saída para transmissão de sinais de áudio e vídeo na Internet é recairsobre o protocolo UDP que não oferece nenhuma das funcionalidades do TCP.

O UDP é um protocolo para o transporte de datagramas sobre o IP. Ele não possuimecanismos de controle de erros, controle de fluxo e re-ordenamento dos datagramas (oupacotes). Resumindo o UDP não garante que as mensagens irão chegar ao seu destino.

Se pensarmos em aplicações de áudio ou vídeo sobre a Internet, ondecongestionamentos podem ocorrer e os pacotes podem chegar fora de ordem, sentimos anecessidade de um mecanismo que possa prover funcionalidades para o re-ordenamento

20

dos pacotes e adequação do jitter introduzido pela rede. Este é o propósito do conjuntoRTP/RTCP (Real-time Transport Protocol e Real-time Transport Control Protocol).

O RTP foi projetado para funcionar em redes unicast e multicast, mas não provênenhum mecanismo que garantam qualidade de serviço ou reserva de recursos da rede,embora as informações carregadas por ele e pelo RTCP possam ser utilizadas ao nível deaplicação para melhorar a percepção da qualidade das transmissões.

O RTP também não garante a entrega dos pacotes – que continuam dependendo darede, que pode descartar, atrasar ou inverter a seqüência das mensagens como acontece comqualquer outro pacote IP. O RTP e o RTCP apenas permitem que a aplicação, no destino,possa implementar mecanismos para recuperar o jitter e dessequencilização introduzidos natransmissão, bufferizando e colocando os pacotes na ordem correta conforme eles chegam,ou ainda tomando medidas apropriadas para outras situações como por exemplo, mudandoa taxa de transmissão dos codecs, ou introduzindo um esquema de redundância pararecuperação de pacotes que são perdidos no meio do caminho. Os números de seqüênciacontidos nos pacotes RTP podem ainda ser utilizados para determinar a localizaçãoapropriada de um pacote, para aplicações de vídeo, por exemplo, sem a necessidade dereceber os pacotes na ordem correta ou ter de reordenar os mesmos antes de exibi-los natela.

Para a transmissão de sinais de áudio/vídeo através do RTP dois endereços detransportes são necessários: um para o transporte da stream de mídia propriamente dita eoutra para a troca de informações RTCP. Para o H.323 estes endereços são escolhidosaleatoriamente e dinamicamente, de modo que não existe uma porta especifica através daqual os sinais devem ser trocados. Isto está definido na recomendação H.225.0 (tabelas 1 e2 da recomendação H.225.0). Geralmente o que acontece é que são escolhidas uma portapar para troca dos sinais de áudio e a próxima porta ímpar é alocada para o RTCP.

Um dos principais motivos para esta distinção é que os usuários poderão escolherreceber ou enviar apenas um dos sinais. Esta separação também permite o tratamento comQoS distinto para cada uma das mídias. A sincronização dos sinais pode ser obtida, nodestino, através do campo timing do RTCP, para as duas sessões.

O RTCP é um protocolo que prove a transmissão periódica de pacotes de controle paratodos os participantes da sessão. Através deste feedback, os transmissores e receptorespodem ficar sabendo de uma série de situações da rede, como a situação da distribuição dosdados para todos os destinos, a qualidade de serviço da transmissão, para cada destino,entre outras funções. Tanto o RTP quanto o RTCP foram planejados para seremindependentes das camadas de transporte e de rede.

A utilização do RTP e RTCP para aplicações H.323 está descrito na recomendaçãoH.225.0, que torna obrigatório o uso destes protocolos para transmissão de áudio e vídeo,com o objetivo de minimizar o atraso introduzido pela rede. Na verdade, a recomendaçãoH.225.0 anexou de forma customizada para aplicações H.323 toda a definição do RTP emseus anexos.

21

Além disso, outros documentos devem ser utilizados para uma completa implementaçãodas aplicações. Estas especificações estão contidas nos anexos B e C do H.225.0 quedefinem a especificação de perfis e formato do payload respectivamente.

O anexo B descreve a especificação de perfis, para os tipos de codecs a serem utilizadose o seu mapeamento no payload. Também define extensões para que classes específicas deaplicações possam customizar o pacote RTP. O anexo C especifica o formato do payloadRTP a ser utilizado para sinais de áudio e vídeo.

Maiores informações sobre o RTP e o RTCP podem ser encontradas nas RFcs 1889 e1890. Seu uso apropriado para implementações H.323 está descrito nos anexos darecomendação H.225.0.

22

3. O H.323 – Sistemas de comunicação multimídiabaseado em pacotes

3.1. Introdução

A recomendação H.323 descreve terminais e outras entidades que provêem serviços decomunicação multimídia sobre redes de pacotes, sem garantia de Qualidade de Serviços.Estas entidades oferecem serviços de comunicação em tempo real. Nestes serviços estãoincluídos a transmissão de áudio, vídeo e dados.

Na verdade a recomendação é um guarda-chuva que determina os padrões a seremutilizados para sinalização, estabelecimento de sessões, controle de chamadas,gerenciamento de largura de banda, controle de admissão, codecs de áudio e vídeo etransferência de dados.

No H.323, o suporte para transmissão e manipulação de sinais de áudio é obrigatóriopara todas as entidades, enquanto que o suporte para vídeo e dados é opcional, mas sesuportado todas as entidades devem ser capazes de encontrar um modo de operação comumpara a troca destes sinais.

O que o H.323 realmente introduziu de novidade no mundo da comunicação visualforam os procedimentos de sinalização para estabelecimentos de chamadas, maneiras deescolher codecs comuns de áudio e vídeo e a capacidade de interoperação com terminais deoutras redes, como, por exemplo, terminais H.320 em redes ISDN e terminais H.310 emredes B-ISDN, uma vez que o conjunto de protocolos RTP/RTCP continua sendo utilizadocomo base para o transporte de dados isócronos em redes sem QoS, como já foi visto.

Embora o desenvolvimento inicial do H.323 estivesse focado exclusivamente para oestabelecimento de conferências em uma rede local, a sua ambição aumentou no momentoem que a Cisco e a Vocaltech se uniram para formar o Fórum de voz sobre IP (Voice overIP Forum), e escolheram o H.323 como protocolo padrão para a telefonia IP em ambienteWAN. O escopo foi aumentado e em fevereiro de 1998 foi a provada segunda versão doH.323, descrito neste trabalho: Sistemas de comunicação multimídia baseado em pacotes.

3.2. Descrição do sistema

Os elementos H.323 que a recomendação descreve são: terminais, gateways,gatekeepers, MCs e MCUs, que se comunicam através de streams de informações. Estasstreams podem ser streams de áudio, vídeo, dados, controle de comunicação e controle dechamadas.

23

Os sinais de áudio devem ser digitalizados e codificados, conforme descritoanteriormente, para redução da taxa de tráfego na rede e transportado através do protocoloRTP. O controle desta stream é realizado através do canal RTCP referente a stream. Damesma forma, os sinais de vídeo devem ser digitalizados e codificados como vistoanteriormente.

3.2.1. Terminais H.323

Terminais são entidades básicas definidas na recomendação H.323. Através dosterminais, usuários podem se comunicar verbal e visualmente e através da transferência ecompartilhamento de dados. Os terminais podem ser equipamentos de hardware ou umaplicativo em software, ou pode também ser um sistema completo para a troca de sinais deáudio, vídeo e dados. Pode ainda ser um simples telefone com capacidade para transmissãode sinais de áudio. A Figura abaixo ilustra os elementos presentes em um terminal, bemcomo as entidades que fazem parte do escopo da recomendação H.323.

T1524040-96

Video I/O equipment

Audio I/O equipment

User Data ApplicationsT.120, etc.

System ControlUser Interface

Video CodecH.261, H.263

Audio CodecG.711, G.722,G.723, G.728,

G.729

System Control

H.245 Control

Call ControlH.225.0

RAS ControlH.225.0

ReceivePathDelay

H.225.0Layer

Local AreaNetworkInterface

Scope of Rec. H.323

Figura 5 – Representação de um terminal H.323

O H.323 especifica os codecs de áudio (G.711, G.722, G.723, G.728, etc), codecs devídeo (H.261, H.263), canais para troca de dados (T.120, etc.), a unidade de controle dosistema e a camada H.225.0, que compõe um terminal H.323 e podem ser utilizados porcada um. Entretanto, a recomendação não define os dispositivos associados, isto é,dispositivos de áudio, vídeo, rede, aplicações e interfaces para o compartilhamento dedados.

24

Os terminais H.323 devem necessariamente oferecer suporte para áudio e por isto, devemimplementar pelo menos um codec de áudio, o G.711 nos modos A-law e µ-law, entretantoo G.711 não pode ser usado para canais de banda estreita (< 56 Kbps). Para estes casos osterminais devem usar o codec G.723.1 ou o G.729. Opcionalmente, os terminais poderãocodificar os sinais de áudio, segundo as recomendações G.722, G.728, G.729, MPEG-1 eG.723.1. A escolha de qual codec será utilizado durante a sessão, é feita logo após oestabelecimento da conexão através de mensagens de troca de capacidade. Estas mensagensestão definidas na recomendação H.245.

Um terminal H.323 deve ser capaz de operar de forma assimétrica, isto é, enviar áudio noformato G.711 e receber áudio no formato G.729. Os terminais poderão também enviarmais de dois canais de áudio ao mesmo tempo.

Os codecs de vídeo são opcionais, mas se suportados devem pelo menos codificar ossinais de vídeo segundo com a recomendação H.261 no modo QCIF. Além disso, osterminais poderão codificar e decodificar os sinais em outras formas de operação do H.261ou do H.263. Outros codecs de vídeo e formatos de imagem também poderão ser utilizados,mas apenas mediante negociação através do H.245 na fase de troca de capacidade. Parasinais de vídeo é permitido o modo de operação assimétrico em relação a taxa de bit devídeo, taxa de quadros e resoluções de imagem, permitindo que um terminal possa enviarimagens QCIF enquanto recebe imagens no formato CIF.

A troca e compartilhamento de dados, também são opcionais para terminais H.323. Arecomendação T.120 é utilizada para interoperabilidade com outros terminais H.323,H.324, H.320 ou H.310, embora aplicações não padronizadas possam ser utilizadas atravésde negociação, na fase de troca de capacidades.

As funções de sinalização de chamada (H.225.0), controle de chamada (H.245) efunções controle de registro, admissão e estado (RAS) junto ao gatekeeper, também devemestar presentes em um terminal

Os canais de controle de chamada H.245, são usados para carregar mensagens decontrole fim-a-fim, isto é, de um terminal até outro terminal. Isto inclui procedimentos paraa troca de capacidade, abertura e encerramento dos canais lógicos para troca de áudio,vídeo ou dados, mensagens de controle de fluxo entre várias outras mensagens adicionais.

Este canal é estabelecido entre dois terminais, um terminal e um MC, ou um terminal eum gatekeeper. Como as entidades H.323 (terminal, gateway, MCU ou gatekeeper), podemsuportar várias conexões simultâneas, um canal de controle para cada sessão deve seraberto, para controlar as informações e procedimentos referentes a esta sessão emespecífico.

Os canais de sinalização de chamadas utilizam as mensagens definidas narecomendação H.225.0, para estabelecer as conexões entre duas entidades H.323. Entidadespodem ser terminais, gateways, gatekeepers e MCUs. Este canal é independente dos canaisde controle H.245 e do canal RAS. O canal de sinalização H.225.0 é aberto antes do canal

25

H.245, para realizar as operações de sinalização estabelecimento e encerramento de sessõesH.323.

O canal de sinalização RAS usa mensagens H.225.0 para executar funções de registro(capacidade de saber que alguém está presente na rede ou pode ser contatado através de umcerto terminal), admissão (checar os direitos de acesso a recursos da rede) e também paramanter o estado atual dos recursos da zona (monitoramento da disponibilidade de recursosde rede). Em redes onde a figura do gatekeeper não está presente, o canal de sinalizaçãoRAS não é utilizado, uma vez que as mensagens RAS são trocadas apenas entre terminaise o gatekeeper.

A entidade mencionada como “Receive path delay” adicionam atraso as streams demídia para manter a sincronização, considerando o jitter na chegada dos pacotes. Asstreams podem ser propositalmente atrasadas nesta entidade, para manter a sincronizaçãocom outras streams de mídia, presentes na comunicação. O atraso introduzido nestaentidade deve ser aplicado apenas para streams que estejam chegando e nunca para ossinais que estão partindo do terminal. Os terminais receptores usam esta facilidade paraobter sincronia de lábio entre sinais de áudio e vídeo.

A camada H.225.0 está presente para manter e garantir a conformidade das mensagensenviadas e recebidas dos canais de sinalização e RAS com a recomendação H.225.0.

3.2.2. Gateways

Gateways são componentes opcionais em um sistema de conferência H.323. Elesprovêem muitos serviços, sendo que o mais comum é a tradução de formatos de sinais entreterminais H.323 e terminais de outros tipos. Isto é, ele deve prover a tradução apropriadaentre modos de transmissão de tecnologias diferentes, por exemplo, formatos detransmissão H.225.0 de/para H.221, e procedimentos de comunicação H.245 de/para H242.

O gateway também é responsável pelo estabelecimento de chamadas em ambos oslados, o lado da rede IP e o lado da SCN (rede de comunicação por circuitos). Traduçõesentre formatos de sinais de mídia (áudio, vídeo e dados), também pode ser realizado pelogateway.

Terminais H.323 podem conversar entre si em uma mesma rede, sem o envolvimentode um gateway. Entretanto quando um terminal H.323 desejar conversar com uma pessoaque possui apenas um telefone comum, conectado na rede pública de telefonia (PSTN) ouum terminal H.320 em linhas ISDN, isto deverá necessariamente passar por um gateway,que irá executar todas as traduções necessárias para que a comunicação aconteça. A suafunção é refletir as características de um terminal na rede IP para um terminal na SCN evice-e-versa.

A figura abaixo representa quatro formas que os gateways podem ter, conforme descritono H.323:

26

T1521240-96

SCN

Network

SCN

SCN

SCN

Gateway A

Gateway B

Gateway C

Gateway D

ConversionFunction

SCNTerminalFunction

H.323MCU

Function

ConversionFunction

SCNTerminalFunction

H.323TerminalFunction

ConversionFunction

SCNMCU

Function

H.323MCU

Function

ConversionFunction

SCNMCU

Function

H.323TerminalFunction

Figura 6 – Configurações de um gateway

Como ilustrado na figura 6, o Gateway pode executar funções de terminais H.323 ouMCU H323. Nestes casos ele irá parecer para todos os terminais ou MCUs H.323 da redeIP como se fosse apenas mais um terminal ou MCU H.323 desta rede e sua comunicaçãocom estes dispositivos ocorre através dos procedimentos H.323.

A função de conversão realiza todas as traduções necessárias para a interoperação dosterminais H.323 localizados no lado da rede IP com os terminais localizados na SCN. Estesterminais podem ser (H.310, H.320, H.321, H.322, H.324, V.70, GSTN ou terminaisISDN).

A função de terminal ou MCU na SCN é vista pelos outros terminais destas redes comose ele fosse apenas um outro terminal do mesmo tipo. Este tipo deve ser o mesmo doterminal que está participando da sessão e estão descritos nas seguintes recomendações:H.310, H.320, H.321, H.322, H.324, V.70, GSTN ou terminais ISDN.

O número de conexões simultâneas, conferências simultâneas e de terminais que podemse conectar ao gateway são deixados a critério de cada fabricante, mas se o gatewayimplementa também funções de MCU ele deve seguir rigorosamente as funções de gateway

27

separadamente das funções de MCU H.323. Da mesma forma, se ele implementar asfunções de MCU para a SCN deve seguir as respectivas recomendações.

3.2.3. Gatekeepers

O Gatekeeper é o mais importante e complexo componente de um sistema H.323,embora sua presença não seja obrigatória para a realização conferencias ou sessões H.323.

O gatekeeper introduz a noção de zona. Uma zona é a coleção de todos os terminais,gateways e MCUs, que estão sob o gerenciamento de um único gatekeeper. Uma zonainclui pelo menos um terminal e pode ou não incluir gateways e MCUs, mas contém um eapenas um gatekeeper. Ela é independente de tecnologia de rede pode ser composta demúltiplos segmentos de rede interconectados por roteador, switches ou outros dispositivos.

T1521220-96

T1

T2

GK

T3

GW

R R

T4 T5

MCU

Zone

Figura 7 – Zona H.323

A figura 7 ilustra uma zona com todos os componentes: Gatekeeper (GK), MCU,Gateway (GW), terminais (Tx). Como vimos estes dispositivos encontram-se separados emsegmentos de redes distintos conectados por dois roteadores (R).

O gatekeeper provê serviços de controle de chamadas para os terminais H.323presentes na zona. Ele é um componente logicamente separado dos terminais, gateways ouMCUs, embora a implementação possa coexistir com estes dispositivos, no mesmoequipamento.

O gatekeeper deve obrigatoriamente oferecer os seguintes serviços para os dispositivosH.323 presentes na sua zona:

• Tradução de endereços – Tradução de aliases, para endereços de rede. Isto deve serrealizado através de uma tabela de que é atualizada através das mensagens deregistro (RAS), embora outros métodos para a atualização desta tabela também sãopermitidos.

• Controle de admissão – O gatekeeper deve autorizar os terminais a utilizarem osrecursos da rede. Esta autorização pode estar baseada em largura de banda, sessõesprivadas, ou outros critérios. Outra opção é permitir que todas as chamadas sejamaceitas.

28

• Controle de largura de banda – O gerenciamento de largura de banda verifica ou nãose existe banda suficiente para um terminal utilizar, dentro de uma determinadasessão. A requisição pode ser aceita ou negada.

• Gerenciamento de zona – Todos os terminais que estiverem registrados com ogatekeeper, devem ser servidos por ele dentro da sua zona. O controle da zona érealizado pelo gatekeeper.

Além destes serviços o gatekeeper poderá oferecer funções adicionais:

• Sinalização de controle de chamada – Em conferências ponto-a-ponto, o gatekeeperpode escolher processar ele mesmo os sinais de controle de chamadas Q.931 entreos terminais, ou alternativamente ele poderá avisar aos terminais para que troquemestas mensagens diretamente um com o outro.

• Autorização de chamadas – O gatekeeper poderá rejeitar uma chamada de umterminal, em razão de falhas de conexão, acesso restrito a certos gateways outerminais e acesso restrito durante alguns intervalos de tempo, mas outros fatores ecritérios de decisão podem também ser utilizados.

• Gerenciamento de Largura de Banda – Controle do número de terminais H.323 quepodem ter acesso simultâneo à rede, se ele determinar que a largura de bandanecessária não está disponível. Esta função também está presente durante umachamada ativa, no caso do terminal requisitar mais banda.

• Gerenciamento de chamadas – O gatekeeper poderá manter uma lista das chamadasem andamento. Esta informação pode ser necessária para indicar que um certoterminal está ocupado para prover informações que serão utilizadas no controle delargura de banda.

Para prover conferências multiponto, que iniciam através de chamadas ponto-a-ponto,isto é, primeiro um terminal chama um outro terminal, para só depois convidarem outros aparticiparem da conferência, o gatekeeper pode escolher receber os controles de chamadasH.245, de ambos os terminais. Quando a conferência mudar para multiponto o gatekeeperpoderá redirecionar, o canal de controle para um MC. Note que o gatekeeper não precisaprocessar estas mensagens H.245, apenas rotea-las de um ponto ao outro.

Em redes que possuem gateways o gatekeeper deverá estar presente para realizar atradução de endereços E.164 para endereços de rede.

29

3.2.4. MC e MP

O controlador multiponto (MC) é responsável por funções de controle, paraconferências entre três ou mais pontos em uma conferência multiponto. O MC realiza atroca de capacidades com cada terminal que deseja participar da conferência.

Desta forma, o MC determina os modos de operação selecionados para a conferência,que pode ser comum para cada participante da conferência ou alternativamente diferente,para alguns terminais.

O MC pode estar localizado dentro de um gatekeeper, gateway, MCU ou terminal,como ilustrado na figura a seguir:

T1521250-96

MC

MC MC MP MC

MC

Gateway 1 MCU 1

LAN

MCU 2

Gatekeeper 1 Terminal 1 Terminal 2

NOTE – Gateway, Gatekeeper and MCU can be a single device.

Gatekeeper 2

Gateway 2 Gateway 3

Gatekeeper 3

MC MP

MC MP

Figura 8 – Localizações possíveis para o MC e MP

Entretanto, vale ressaltar que um MCU sempre possuirá um MC, que irá processartodos os canais de controle de todos os pontos finais envolvidos na sessão.

Em uma conferência, quando existirem mais de um terminal com capacidade de MC,estes terminais deverão utilizar a determinação master/slave (mestre/escravo), paradeterminar, qual será o MC ativo, que irá controlar a conferência.

O processador multiponto (MP) por sua vez recebe sinais de áudio, vídeo e dados, dosterminais participantes de uma conferencia centralizada ou híbrida, realiza a agregação oucomutação dos sinais e devolve o sinal processado para os terminais.

No processo de agregação o MP poderá atenuar ou eliminar alguns inputs dos sinais,para reduzir o ruído introduzido nestes sinais e assim devolver um sinal mais limpo para ospontos finais participantes da conferência. Para os sinais de dados, um MP deverá ser capazde atuar como um MCS não folha ou um MCS principal.

30

3.2.5. MCU

O MCU é um componente H.323 que provê a capacidade para suportar conferênciasmultiponto. O MCU deve necessariamente consistir de um MC e zero ou mais MPs.

Ele deve suportar conferências multiponto centralizadas através de um MC e daagregação de sinais de áudio, vídeo e dados. Conferências descentralizadas consistem deum MC e suporte para agregação de dados através de um MP que implementa as funçõesconforme a recomendação T.120. usando capacidades de áudio e vídeo descentralizadas.

Um gateway pode implementar um MCU no lado interno da rede. Um gatekeeperpoderá também conter um MCU em qualquer dos casos, as funções devem estar separadase não podem interferir uma na operação da outra.

31

4. Procedimentos de sinalização de chamadas

O H.323 define os procedimentos para o estabelecimento e controle de chamadas, masutiliza as mensagens definidas da recomendação H.225.0 e H.245 do ITU-Trespectivamente.

O H.323 não impõe nenhuma restrição em termos de sincronização, nos procedimentosde estabelecimento de chamadas. Isto significa que um ponto A pode iniciar a comunicaçãode estabelecimento de chamadas para um ponto B no mesmo instante em que o ponto Binicia o mesmo procedimento com o ponto A. Em uma situação como esta, a aplicaçãodeve saber como agir, como por exemplo, enviar um sinal de ocupado sempre que já existiruma mensagem de estabelecimento de chamadas em curso. Um terminal H.323 devesuportar as seguintes mensagens para o estabelecimento de chamadas:

• Setup• Alerting• Connect• Release Complete• Status Facitity

Outras mensagens definidas como: Call proceding, Status, Status Enquiry, sãoopcionais.

A figura 9, mostra a captura de uma sessão, na fase de estabelecimento de conexãoentre dois terminais H.323. Primeiramente, vimos duas mensagens que nada tem a ver coma sessão H.323. Logo em seguida inicia a comunicação entre dois terminais: o primeiropossui endereço IP igual a 143.54.1.121, enquanto que o segundo conhecido comotigresa.inf.ufrgs.br possui endereço IP igual a 143.54.41.165.

As três primeiras mensagens mostram as três fases de estabelecimento de conexão TCP(three way handshake). Logo em seguida, é iniciada a comunicação H.323, conformedescrita na sessão 4.1. Vimos nesta captura as mensagens Setup, Alerting e Connect.

32

Figura 9 – Captura da de uma sessão H.323 mostrando a fase de estabelecimento de conexão.

(usando o Lan Explorer v.3.6 da Sunrise Telecom)

4.1. Estabelecimento de Chamada

Esta fase utiliza as mensagens de controle definidas na recomendação H.225.0 do ITU-T. Entretanto, antes desta fase ser iniciada, toda a comunicação de registro e admissão como gatekeeper, quando existir um gatekeeper presente, bem como reserva de largura debanda devem ter sido realizadas previamente.

A primeira situação envolve a comunicação entre apenas dois terminais H.323. Osterminais devem ser capazes de enviar mensagens Alerting. Quando a comunicaçãoenvolver um gateway, este deverá enviar mensagens de Alerta (Alerting), logo que recebero sinal de chamando, da SCN. Se o terminal que está recebendo a chamada puder respondercom qualquer uma das mensagens: Connect, Call Proceeding ou Release Complete dentrode 4 segundos, a mensagem Alerting não é necessária.

33

4.1.1. Estabelecimento de chamadas simples (sem registro com gatekeeper)

Neste cenário, os dois pontos finais se comunicam diretamente como mostrado nafigura a seguir. O terminal (Endpoint 1) envia uma mensagem Setup para o Terminal 2. Seeste conseguir processar e responder dentro de 4 segunso então a mensagem Alerting não énecessária.

A mensagem Setup é direcionada para a porta 1720 do terminal 2, como definida noapendice D da recomendação H.225.0. O terminal poderá responder com Alerting, CallProceding e Connect. A mensagem Connect deve possuir em um de seus campos oendereço de transporte (porta), que deverá ser utilizado para o estabelecimento do canal decontrole H.245.

T1527150-97

Endpoint 1Setup (1)

Connect (4)

Call proceeding (2)

Alerting (3)

Call Signalling Messages

Endpoint 2

Figura 10 – Estabelecimento de chamadas básico. Sem Gatgekeepers

4.1.2. Ambos pontos registrados com o mesmo Gatekeeper

O próximo cenário ocorre quando um gatekeeper estiver envolvido na comunicação. Ogatekeeper executa as funções de tradução de endereço, gerenciamento de admissão egerenciamento de largura de banda. Diferentes situações podem ocorrer: os dois terminaisse registram com o mesmo gatekeeper, apenas o terminal chamador se registra com ogatekeeper, apenas o terminal chamado se registra com o gatekeeper. O gatekeeper poderáainda escolher entre proceder com o estabelecimento da conexão no modo roteado, oudireto.

Para entendermos melhor os procedimentos de sinalização vamos primeiramenteverificar como ocorre o registro de um terminal com um gatekeeper (canal RAS) e comoele, o gatekeeper, poderá conduzir a fase de estabelecimento de chamada e controle, apósos terminais terem se registrado com ele.

Para se conectar a um gatekeeper, primeiramente é necessário encontrá-lo na rede.Existem duas abordagens: a primeira é a configuração manual do gatekeeper. Este

34

procedimento está fora do escopo da recomendação. A segunda abordagem visa, encontraro gatekeeper automaticamente na rede e então efetuar o registro com ele.

Para localizar o gatekeeper, o terminal poderá enviar mensagens multicast para o grupo224.0.1.41, porta 1718 como definido na recomendação H.225.0. Outras formas tambémpodem ser utilizadas, como broadcast e endereçamento manual. Esta mensagem,Gatekeeper Request (GRQ), basicamente diz o seguinte: “Quem é o meu gatekeeper”. Umgatekeeper irá possivelmente responder com a mensagem Gatekeeper Confirmation (GCF),indicando “Eu posso ser seu gatekeeper!”. Esta mensagem deverá indicar o endereço detransporte (porta), onde deverão ser realizados os procedimentos de admissão nogatekeeper. Se o gatekeeper não puder aceitar a chamada responderá para o terminal com amensagem Gatekeeper Reject (GRJ). Como mostrado na figura 11.

T1521260-96

Endpoint Gatekeeper

GRQ

GCF/GRJ

Figura 11 – Descobrimento automático do gatekeeper

Se mais de um gatekeeper responder ao terminal, este poderá escolher aquele quemelhor lhe convier, através de procedimentos não descritos na recomendação, como porexemplo, se registrar com o gatekeeper que respondeu primeiro a sua requisição.

Após o descobrimento do gatekeeper, os pontos de conferência devem se registrar aogatekeeper para se juntar à zona. O processo de registro deverá acontecer antes que asmensagens de controle e estabelecimento de chamada sejam iniciadas.

Um terminal deverá enviar a mensagem Registration Request (RRQ), requisitandoautorização para se juntar a zona. Esta mensagem é enviada para o endereço e portaenviados pelo gatekeeper no processo de descobrimento do gatekeeper. O gatekeeperpoderá então responder com a confirmação do registro através da mensagem RegistrationConfirmation (RCF), ou rejeitar o registro através da mensagem Registration Reject (RRJ).

O gatekeeper poderá também, cancelar o registro do terminal, enviando uma mensagemUnregister Request (URQ), para o terminal. Então o terminal deverá responder com amensagem Unregister Confirmation (UCF). Este terminal deverá, procurar outrogatekeeper para se registrar antes de poder participar em uma nova conferência. Quando oregistro com o terminal é cancelado, ele passa a ser chamado de ponto não registrado(unregistered endpoint). Nesta situação, ele não faz parte da zona e não participará dasfunções realizadas pelo gatekeeper. Todo este processo está ilustrado na figura 12.

O canal RAS é utilizado também para troca de outras mensagens como: admissões,mudança na quantidade de largura de banda necessária, monitoramento do estado dachamada e desligamento com o gatekeeper.

35

T1524050-96

Endpoint Gatekeeper

RRQ

RCF or RRJ

URQ

UCF/URJ

URQ

UCF

Endpoint initiatedUnregister Request

Gatekeeper initiatedUnregister Request

Figura 12 – Fase de registro com o gatekeeper

Durante a fase de registro com o gatekeeper, ele poderá indicar que o processo deestabelecimento de chamadas deverá ocorrer de acordo com uma de duas possibilidades:estabelecimento de chamadas direto, onde um terminal deverá contatar diretamente o outropara efetuar os procedimentos de estabelecimento de chamada, ou estabelecimento dechamada roteado, onde as mensagens de estabelecimento de chamadas serão roteadasatravés do gatekeeper. Ambas formas utilizam as mesmas conexões com os mesmosobjetivos, entretanto seus fluxos são diferentes, conforme ilustrado nas figuras 13 e 14.

T1521280-96

1 2 3 4 5 6 78

Endpoint 1 Endpoint 2

Gatekeeper cloud

RAS Channel Messages

Call Signalling Channel Messages

1 ARQ2 ACF/ARJ3 Setup4 Setup5 ARQ6 ACF/ARJ7 Connect8 Connect

Figura 13 – Estabelecimento de chamadas roteado pelo gatekeeper

36

T1521290-96

1 2 4 5

6

3


Gatekeeper cloud



1 ARQ2 ACF/ARJ3 Setup4 ARQ5 ACF/ARJ6 Connect

Figura 14 – Estabelecimento de chamadas direto

Quando é utilizado o modelo de estabelecimento de chamadas, roteado, como ilustradona figura 13, existem duas maneiras para o estabelecimento do canal de controle H.245entre os terminais participantes da conferência.

No primeiro método canal de controle é estabelecido diretamente entre o terminais.Este método não foi completamente definido na versão 2 do H.323. O método definidonesta versão da recomendação H.323 foi o modo roteado. Este método permite que ogatekeeper possa redirecionar o canal de controle H.245 para um MC, quando umaconferência, rapidamente passar de ponto-a-ponto, para multiponto. Este procedimento estáilustrado a seguir:

T1521310-96

1 2 3 4 5 6 78 9 10

1 ARQ2 ACF/ARJ3 Setup4 Setup5 ARQ6 ACF/ARJ7 Connect8 Connect9 H.245 Channel10 H.245 Channel



H.245 Control Channel Messages


Gatekeeper cloud

Figura 15 – Canal de controle no modo roteado pelo gatekeeper

37

Uma vez entendido como os procedimentos de registro com o gatekeeper acontecemantes do estabelecimento dos sinais de chamada e canal de controle, bem como a maneiracomo eles podem ser realizados na presença de um gatekeeper (modo roteado ou mododireto), vamos agora retornar sobre o processo de estabelecimento de chamadas.

Para explicar como ocorre o processo de estabelecimento de chamada com umgatekeeper, vamos usar o caso onde os dois pontos se registram com o gatekeeper, no modode chamada roteado.

Neste caso, O ponto 1 inicia a fase de admissão enviando a mensagem AdmissionRequest (ARQ) (1), pedindo permissão para iniciar uma chamada. O gatekeeper responderácom uma das mensagens Admission Confirmation (ACF) (2) ou Admission Reject (ARJ)(2). Se o gatekeeper resolver aceitar a chamada, s sua mensagem ACF deverá conter o seupróprio endereço de transporte (porta), indicando onde o terminal deverá direcionar asmensagens de estabelecimento de chamada. No modo direto o gatekeeper deve indicar oendereço e porta do terminal chamado, para que a troca de mensagens de sinalização possaser realizada diretamente entre os dois pontos, sem a interferência (roteamento) dogatekeeper, ilustrado na figura 17.

Uma vez que o ponto 1 recebeu o endereço para onde deverá ser direcionado asmensagens de estabelecimento de chamada, ele inicia o processo enviando a mensagemSetup (3) para o próprio Gatekeeper, responsável por rotear esta mensagem para o terminal2. O gatekeeper reenvia a mensagem para o ponto 2 (4). Se o terminal 2 resolver aceitar achamada ele deverá se registrar com o gatekeeper através da troca de mensagens ARQ (6) eACF/ARJ (7).

O terminal 2 responde então com a mensagem Connect (9), para o gatekeeper, querepassa a mensagem para o terminal chamador (10). Este processo está ilustrado na figura16. O mesmo processo através de sinalização direta está ilustrado na figura 17. Lembramosainda, que apenas um dos terminais pode ter se registrado com o gatekeeper. Ou o terminalchamador ou o terminal chamado.

38

T1524060-96

Gatekeeper 1 Endpoint 2

ARQ (1)

ACF (2)

Setup (3)

Call Proceeding (5)

Alerting (8)

Connect (10)

Setup (4)

Call Proceeding (5)

ARQ (6)

ACF/ARJ (7)

Alerting (8)

Connect (9)

RAS Messages


Endpoint 1

Figura 16 – Dois pontos registrados pelo mesmo gatekeeper, no modo de sinalização roteado.

T1527160-97


ARQ (1)

ACF/ARJ (2)

Setup (3)

Call proceeding (4)

Gatekeeper 1

Alerting (7)

Connect (8)

ARQ (5)

ACF/ARJ (6)

RAS Messages


Figura 17 – Dois pontos registrados pelo mesmo gatekeeper,no modo de sinalização direto

39

4.1.3. Pontos registrados com diferentes Gatekeepers

Existem ainda outras situações onde o registro com o gatekeeper ocorre de formadiferente. Esta situação é comum quando uma empresa irá se comunicar com outra empresae ambas possuem uma zona H.323. A situação ilustra também, a possibilidade de umaempresa que possui uma zona H.323 utilizar serviços de outra empresa. Estes serviçospodem ser a conexão com a rede publica de telefonia (PSTN), através de um gatewayterceirizado com outra companhia.

Para explicar este cenário também usaremos o caso mais complexo onde os terminaisestão registrados com diferentes gatekeepers e ambos escolhem rotear o canal deestabelecimento de conexão.

Neste cenário, O terminal Chamador (Terminal 1), inicia os procedimentos de registrocom o gatekeeper 1 ARQ(1) / ACF(2).Na mensagem ACF (2), o gatekeeper deve indicar oendereço onde deverá ser estabelecido o canal para sinalização de chamadas, neste caso oseu próprio endereço. Lembramos que poderia ser o endereço, do gatekeeper 2 ou aindadiretamente o endereço do terminal 2. A versão 3 do H.323 irá aprofundar os estudos para adefinição de um protocolo para a comunicação Inter gatekeepers.

Como neste caso, o Gatekeeper irá rotear o canal de estabelecimento de chamadas, oterminal 1 envia a mensagem Setup (3) para o gatekeeper 1, que redirecionará esta chamadapara o endereço do terminal 2 (4).

Se o terminal 2 deseja aceitar a chamada, ele inicia os procedimentos de registro com oseu gatekeeper (6). Se o gatekeeper aceitar o registro ele deverá retornar na mensagem ACF(7), o endereço de transporte no qual deverá ser estabelecido o canal para sinalização. Nestecaso o seu próprio endereço. Neste momento o terminal 2 deve avisar ao gatekeeper 1 que oseu gatekeeper deseja rotear a chamada. Ele faz isso enviando a mensagem Facility (8), quecontém o endereço de transporte do gatekeeper 2.

O gatekeeper 1 envia então, a mensagem Release Complete (9), e reinicia o processo deestabelecimento de chamadas, através do gatekeeper 2, enviando a mensagem Setup (10),para ele. O gatekeeper 2 redireciona a mensagem para o terminal 2.

O terminal 2 se registra novamente com o gatekeeper (12,13) e envia a mensagemConnect (15), para o seu gatekeeper, que redireciona a mensagem para o gatekeeper doterminal 1 (16), que finalmente recebe a aviso que sua chamada foi completada (17).

Devemos notar que a mensagem Connect (15), enviada pelo terminal 2 contém o seuendereço de transporte para o estabelecimento do canal de controle H.245. A mensagemenviada pelo gatekeeper 2 (16), pode possuir ou o endereço do terminal 2, ou o endereço dogatekeeper 2, conforme sua escolha em estabelecer este canal no modo direto ou no modoroteado. A mensagem Connect (17) enviada pelo gatekeeper 1 ao terminal 1 pode possuir o

40

endereço de transporte enviado pelo gatekeeper 2 ou o seu próprio endereço conforme suaescolha em estabelecer o canal de controle H.245 no modo direto ou no modo roteado.

A troca de mensagens está mostrando o processo de estabelecimento de chamada, estáilustrada na figura a seguir:

T1524110-96

Endpoint 1 Gatekeeper 1 Gatekeeper 2 Endpoint 2

ARQ (6)

ARJ (7)

Facility (8)

Setup (4)

Call Proceeding (5)

Setup (10)

Call Proceeding (5)

Alerting (14)

Connect (16)

Setup (11)

Call Proceeding (5)

ARQ (12)

ACF/ARJ (13)

Alerting (14)

Connect (15)

RAS MessagesCall Signalling Messages

ARQ (1)

ACF (2)

Setup (3)

Call Proceeding (5)

Alerting (14)

Connect (17)

Release Complete (9)

Figura 18 – Dois pontos registrados em gatekeepers distintos,No modo de sinalização Direto/Roteado

4.2. Comunicação inicial e troca de capacidades

Após a conexão ter sido estabelecida, dá-se inicio a segunda fase, antes que aconferencia tenha inicio. Esta fase visa estabelecer o canal de controle H.245. Este canal éutilizado para a troca de capacidade e abertura dos canais de mídia.

41

A troca de capacidade é a primeira coisa a ser feita após a abertura do canal de controle.A primeira mensagem a ser enviada deverá ser necessariamente a mensagemterminalCapabilitySet. Após a escolha do modo de operação ter sido realizada, segue adeterminação de quem na conferência será o mestre e quem será o escravo. Estesprocedimentos existem em situações onde ambos terminais possuem capacidade de MC.

No caso destes dois procedimentos falharem, ele deve ser tentado novamente, duasvezes adicionais, antes dos terminais abandonarem esta fase e iniciarem a fase deencerramento da chamada como descrito na sessão 4.5.

4.3. Comunicação multimídia

Depois da determinação das capacidades de cada terminal e da determinação demestre/escravo, os procedimentos da recomendação H.245 devem ser seguidos para aabertura dos canais lógicos de transmissão de mídia (áudio, vídeo e dados).

Os canais de áudio e vídeo devem ser estabelecidos em endereços de transporte (portas)dinamicamente alocados e são identificados na mensagem OpenLogicaChannelAck. Oemissor deverá usar o canal identificado nesta mensagem para enviar os sinais de mídia,que devem ser transportados através de canais não confiáveis, como o protocolo UDP.

Os dados transportados nestes canais devem trafegar por canais distintos e sãounidirecionais exceto no caso do T.120.

Assim quando o terminal 1 desejar abrir um canal de mídia com o terminal 2 ele deveráenviar a mensagem OpenLogicalChannel, para o terminal 2 que conterá o número daquelecanal, os parâmetros para troca de mídia como, por exemplo, Áudio G.711. No caso deáudio e vídeo esta mensagem também deve conter o endereço (porta), onde o terminal 2deve enviar os relatórios (RTCP RR) do protocolo RTCP. Logo que receber esta mensagemo terminal 2 deverá enviar ao terminal 1 a mensagem OpenLogicaChannelAck, que devepossuir o endereço (porta) na qual o terminal 1 deve enviar os dados, bem como o endereço(porta) na qual o terminal 2 espera receber os relatórios RTCP (SR RTCP).

Após os canais de mídia terem sido estabelecidos a troca destes sinais pode ser iniciadapelos terminais envolvidos e a conferência é enfim estabelecida. Os sinais de áudio ouvídeo são enviados em pacotes RTP.

Os relatórios enviados nos pacotes RTCP permitem que o terminal 2 sincronize osdiversos streams de mídia, bem como possa medir a distância que o terminal 1 está. Osrelatórios RR enviados pelo terminal 2 permitem que o terminal 1 possa medir a qualidadede serviço da rede, podendo reduzir a taxa de transmissão, se necessário.

O H.323 estabelece que apenas um par de endereços de transporte (portas) RTP/RTCP,seja usado por sessão (sessão de áudio deve usar o mesmo endereço de transporte RTCPtanto para fluxos do terminal 1 para o terminal 2 quanto do terminal 2 para o terminal 1).

42

4.4. Encerramento da chamada

A chamada pode ser encerrada por qualquer um dos pontos finais envolvidos naconferência, entretanto o procedimento para encerramento de chamadas é diferente, paraconferências onde existe a presença de um gatekeeper e quando a figura do gatekeeper éinexistente.

Quando a chamada não envolve um gatekeeper, os seguintes procedimentos devem serexecutados:

1. O terminal que deseja encerrar a chamada deve encerrar a transmissão de vídeoe então encerrar todos os canais lógicos para vídeo;

2. Deve descontinuar a transmissão de dados e então encerrar com todos os canaislógicos para transmissão de dados;

3. Deve descontinuar a transmissão de áudio e então fechar todos os canais lógicospara a transmissão de áudio;

4. Ele deve transmitir a mensagem H.245 endSessionCommand, no canal decontrole H.245, indicando que ele deseja se desconectar desta chamada eencerrar o canal de controle H.245;

5. Deve esperar até receber a mensagem endSessionCommand, do outro terminal eentão fechar o canal de controle H.245;

6. Se o canal de controle de chamadas estiver aberto, a mensagem ReleaseComplete deve ser enviada e o canal deve ser fechado;

7. A chamada é encerrada.

Devemos notar que estes procedimentos são utilizados para encerrar uma chamada e não aconferência, que deve ser encerrada usando uma mensagem H.245 dropConference Nestecaso por terminais devem esperar até que o MC ativo termine com as chamadas comodescrito acima.

Em redes que contém um gatekeeper, este deve estar ciente da liberação da banda, para quepossa então utilizar esta banda em outras chamadas e conferências. Após executar os passosde 1 até 6, cada terminal deve enviar a mensagem H.225.0 Disengange Request (DRQ) (3),para o gatekeeper. O gatekeeper deverá responder com uma mensagem DisengangeConfirm (DCF) (4). Após enviar a mensagem DRQ, os terminais não devem enviar maisnenhuma mensagem IRR não solicitadas pelo gatekeeper. O procedimento está ilustrado nafigura a seguir:

43

T1524200-96

Gatekeeper 1 Endpoint 1 Endpoint 2 Gatekeeper 2

DRQ (3)

DCF (4)

EndSessionCommand (1)



DRQ (3)

DCF (4)

RAS messagesCall Signalling messagesH.245 messages

NOTE – Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper.

Figura 19 – Encerramento de chamada iniciado pelo terminal.

Existe ainda, a situação onde a chamada é encerrada pelo próprio gatekeeper. Neste caso ogatekeeper envia a mensagem DRQ para o terminal. O terminal deverá então seguir osprocedimentos de 1 até 6 e então responder ao gatekeeper com a mensagem DCF. O outroterminal após o recebimento da mensagem endSessionCommand deverá enviar umamensagem DRQ ao gatekeeper que deverá responder com a mensagem DCF.

Se a conferência for multiponto o gatekeeper deverá enviar a mensagem DRQ para todos osterminais envolvidos de modo a encerrar com a conferência inteira.A figura 20 ilustra oprocesso de encerramento de chamadas iniciado pelo gatekeeper.

44

T1524210-96

Gatekeeper 1 Endpoint 1 Endpoint 2 Gatekeeper 2

DRQ (3)

DCF (4)




DRQ (3)

DCF (4)

RAS messagesCall Signalling messages

H.245 messages

NOTE – Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper.

Figura 20 – Encerramento de chamada iniciado pelo gatekeeper

É interessante mencionarmos aqui que em muitas implementações reais muitos dosterminais não são tão “educados” e simplesmente terminam com a conferência em vez deencerrar com as chamadas.

45

5. Conferências multiponto5.1. Conferências centralizadas

O MCU é o componente responsável por oferecer suporte a conferências multiponto,entretanto todos os terminais devem possuir capacidade de realizar conferênciascentralizadas.

Neste modo de conferência cada terminal se comunica com o MC ou com o MCU demodo ponto-a-ponto, para o canal de controle H.245, e com o MP para os canais de áudio,vídeo e dados.

Nas conferências multiponto centralizadas, o MC executa as funções de controle H.245enquanto o MP executa as funções de agregação e comutação de vídeo, áudio e dados.Assim, o MP transmite o resultado da agregação de áudio, vídeo e dados de volta para osterminais participantes da conferência. O MP pode ter a capacidade de converter os sinais,em diferentes formatos e taxa de bit, permitindo que os terminais possam participar daconferência mesmo utilizando modos diferentes de comunicação.

O MCU poderá também usar multicast para realizar a distribuição dos sinaismultimídia, se os pontos finais forem suportarem este tipo de comunicação.

Figura 21 – Conferência no modo centralizado

46

5.2. Conferências Descentralizadas

Neste modo de operação os pontos finais participantes da conferência se comunicam com oMC mestre da conferência, estando ele localizado em um MCU, Gateway, Gatekeeper, outerminal, no modo ponto-a-ponto para o canal de controle H.245. Opcionalmente podem secomunicar no modo ponto-a-ponto para os canais de dados e mídia.

Entretanto, os terminais devem ter capacidade de transmitir via multicast os canais de áudioe vídeo (mídia), para todos os outros terminais participantes da conferência. O MC poderácontrolar quais terminais estão transmitindo sinais multimídia via multicast.

Os terminais devem então receber os canais de vídeo multicast e selecionar um deles paraexibir ao usuário. Os terminais recebem os sinais de áudio multicast e executam aagregação dos sinais para apresentar ao usuário um sinal de áudio composto e coerente, dasconversações que estão acontecendo na conferência.

Neste modo todos os sinais de controle são enviados e processados pelo MC. Assim, apartir de sinais recebidos de um terminal o MC envia as respostas apropriadas para osoutros participantes a fim de coordenar a conferência.

Figura 22 – Conferência no modo centralizado

47

5.3. Conferencias Híbridas

Existem duas possibilidades para a ocorrência deste tipo de conferência. Na primeira, ossinais de áudio são trocados de maneira centralizada, enquanto que os sinais de vídeo sãodistribuídos via multicast. Neste modo, os terminais devem se comunicar com o MC demaneira ponto-a-ponto para o estabelecimento e comunicação do canal de controle H.245 eopcionalmente com o MP, para os canais de dados. O MC pode controlar qual terminalestá enviando vídeo e quais terminais que estão recebendo vídeo. Os terminais que estãorecebendo vídeo devem selecionar um ou mais canais para exibir ao usuário. Os canais deáudio devem ser enviados para o MC por todos os terminais participantes da conferência.Ele realizará a agregação dos sinais de áudio e reenviará o sinal resultante para todos osterminais.

No segundo modo de operação de conferências Híbridas, os sinais de vídeo são trocados demaneira centralizada, enquanto os sinais de áudio são distribuídos via multicast. Nestemodo, os terminais devem se comunicar com o MC de maneira ponto-a-pontoestabelecimento e comunicação do canal de controle H.245 e opcionalmente com o MPpara os canais de dados. O MC pode controlar quais terminais estão enviando e recebendoáudio e os terminais que estão recebendo áudio devem executar a função de agregação paraapresentar o sinal de áudio composto ao usuário. Todos os terminais devem transmitir suasmensagens de vídeo para o MP, que realizará a agregação e conversão de formato dossinais de vídeo e reenviará o sinal resultante para todos os terminais de maneira ponto-a-ponto ou opcionalmente poderá enviar estes sinais via multicast para minimizar o consumode banda na rede.

As figuras 23 e 24 mostram estes dois modos de operação. A figura 23 ilustra o modo deconferência Híbrida com áudio centralizado, enquanto que a figura 24 ilustra o modo deconferência Híbrida com vídeo centralizado.

48

Figura 23 – Conferência Híbrida com áudio centralizado

Figura 24 – Conferência Híbrida com áudio centralizado

49

6. Procedimentos adicionais para o estabelecimento dechamadas6.1. Sinalização opcional usando a mensagem LRQ

A recomendação H.323 especifica ainda alguns modelos diferentes para oestabelecimento de chamadas, que devem ser utilizados em casos específicos. Vimos nasessão 4 como são os procedimentos normais para o estabelecimento de chamadas.Especialmente nos casos onde apenas o terminal chamado está registrado com umgatekeeper ou quando ambos terminais estão registrados com o gatekeeper, uma mensageminicial de Setup é inicialmente enviada pelo terminal chamador para o terminal chamado oupara o gatekeeper do terminal chamador.

Se o gatekeeper do terminal chamado quiser utilizar o modelo de chamada roteado pelogatekeeper ele retornará o seu próprio endereço de transporte na mensagem ARJ. Oterminal chamado usa a mensagem Facility para redirecionar a chamada para o seugatekeeper. Estes procedimentos assumem que o terminal chamador ou o gatekeeper noqual o terminal chamador está registrado, apenas sabem o endereço de transporte doterminal chamado e não do gatekeeper do terminal chamado, o que pode ser observado nafigura 18.

Se o gatekeeper do terminal chamador deseja utilizar o modo de chamada roteado, elepoderá enviar seu próprio endereço de transporte na mensagem LCF, o que permitirá oterminal chamador ou seu gatekeeper enviar diretamente a mensagem de Setup para ogatekeeper do terminal chamado, eliminando assim a necessidade de redirecionamento dechamada.

Um exemplo deste cenário é ilustrado a seguir. Neste cenário os dois pontos finais estãoregistrados com gatekeepers diferentes e ambos escolhem realizar a chamada pelo modoroteado.

Neste caso, o terminal 1 envia um uma mensagem ARQ (1) para o seu gatekeeper(gatekeeper 1). O gatekeeper 1 envia via multicast uma mensagem LRQ, a fim de localizaro terminal 2. O gatekeeper 2 responde com a mensagem LCF enviando o seu próprioendereço de transporte, onde a conexão deverá ser aberta. Assim, o gatekeeper 1 irá enviara mensagem de Setup (6) diretamente para o gatekeeper 2, que ira rotea-la até o terminal 2.(8). Neste ponto o terminal 2 inicia a fase de registro com o seu gatekeeperARQ(9)/ACF(10). O terminal 2 responderá então com a mensagem Connect (12) para o seugatekeeper que deverá conter o endereço de transporte no qual deverá ser estabelecido ocanal de controle de chamadas H.245.O gatekeeper 2 redireciona a mensagem Connect(13), para o gatekeeper 1, esta mensagem pode conter o seu próprio endereço ou o endereçodo terminal 2, dependendo se ele quiser estabelecer o canal de controle H.245 no modoroteado ou direto, respectivamente. O gatekeeper 1 envia então a mensagem Connect (14),para o terminal 1 contendo o seu próprio endereço de transporte ou o endereço de

50

transporte enviado pelo gatekeeper 2, dependendo se ele quiser estabelecer o canal decontrole H.245 no modo roteado ou direto, respectivamente.

T1604220-97

Alerting (11)

ACF (10)

Alerting (11)Alerting (11)

RAS Messages

Connect (14)


Connect (13)

Multicast RAS Messages

Setup (5)Setup (6)

ARQ (1)

Call Proceeding (7)

Call Proceeding (7)

Call Proceeding (7)

ACF (4)

ARQ (9)

Endpoint 1 Endpoint 2Gatekeeper 1 Gatekeeper 2

LCF (3)

LRQ (2)

Setup (8)

Connect (12)

Figura 25 – Sinalização opcional usando a mensagem LRQ

6.2. Procedimento de conexão rápida

O H.323 v.2 resolveu um dos principais problemas contidos na primeira versão darecomendação, a possibilidade de se estabelecer rapidamente uma conexão. Mas na verdadeo que isto quer dizer e qual a sua vantagem em relação aos métodos descritosanteriormente?

O problema existente com os procedimentos descritos anteriormente é o tempo necessáriopara o estabelecimento da conexão, antes que se possa trocar sinais de mídia. Isto envolve atroca das seguintes mensagens:

• Atraso de ida e volta da seqüência ARQ/ACF;

51

• Atraso de ida e volta da seqüência Setup – Connect;• Atraso de ida e volta para as mensagens de troca de capacidades H.245;• Atraso de ida e volta para as mensagens de determinação master/slave H.245;• Atraso de ida e volta para as mensagens abertura de conexão para cada canal de

mídia aberto

Além disso, não podemos esquecer que as mensagens H.225.0 e H.245 devem serprimeiramente estabelecidas através do protocolo TCP, isto requer o estabelecimento daconexão TCP o que implica um atraso adicional para o estabelecimento da cada uma dasconexões H.225.0 e H.245.

O H.323 v.2 incluiu um método chamado de procedimento de conexão rápida quepermite que conexões unidirecional e bidirecional, imediatamente após a mensagem deSetup e permitir comunicação de áudio imediatamente após a mensagem Connect serrecebida, melhorando o tempo de estabelecimento de conexões diminuindo o atrasoenvolvido.

Um terminal que decide usar o procedimento de conexão rápida deve incluir oparâmetro fastStart na mensagem Setup. Este parâmetro deverá incluir uma descrição detodos os canais de mídia que o terminal está preparado para receber e todos os canais demídia que o terminal está preparado para enviar. Isto inclui os codecs utilizados, o endereçode transporte (portas) a serem utilizadas para cada conexão, etc.

Se o terminal chamado não implementa os procedimentos necessários para esteprocedimento, ou não desejar realizar a conexão através deste método, ele não retornará oparâmetro fastConnect nas mensagens Q.931-H.225.0 subseqüentes. Neste caso osprocedimentos normais descritos na recomendação H.245, devem ser utilizadas, para trocade capacidades, abertura de canais de mídia, etc.

Este novo procedimento de conexão, permite que a rede possa enviar qualquer tipo demídia, para os endereços mencionados pelo terminal chamador antes que o terminal 2 tenharesolvido aceitar a chamada. Assim mensagens como “A rede está congestionada, porfavor, tente chamar mais tarde”, podem ser enviadas pelos dispositivos intermediários darede ao terminal chamador, coisa que não pode ser realizado através dos procedimentosnormais de estabelecimento de chamada.

52

7. ConclusãoO trabalho mostra que novas formas de comunicação são requeridas nestes novos

tempos, onde a Internet já é parte integrante do dia-a-dia de qualquer organizaçãoestruturada. Isto por que, a comunicação entre as pessoas continua sendo a principalmaneira para a criação de ativos para as empresas.

Entretanto, cada vez mais as pessoas não têm tempo para se encontrarem e secomunicarem adequadamente, devido ao grande acúmulo de tarefas e compromissos aosquais os indivíduos estão sujeitos.

Assim sendo, a colaboração visual oferece uma maneira inovadora para que grupo depessoas possam trocar e compartilhar informações multimídia através da Internet, mesmoque estejam separadas por uma simples parede ou vários continentes, permitindo que estesgrupos se encontrem em reuniões virtuais e trabalhem colaborativamente.

Para que a estes sinais possam ser transmitidos através da Internet eles devem sertrabalhados de forma a reduzir a quantidade de informações a serem transmitidas, uma vezque sinais de vídeo são extremamanete pesados (grandes), para serem transferidos na suaforma original.

Neste sentido o ITU-T desenvolveu a recomendação H.323, descrita neste trabalho. OH.323 define as entidades que devem compor um sistema H.323, bem como todos osprocedimentos e mensagens necessários para o estabelecimento de chamadas, troca desinais, encerramento de chamadas e controle das transmissões. Vimos que talvez a maiorcontribuição do H.323 foi justamente definir estes procedimentos para o estabelecimento dechamadas e controle dos canais de transmissão, pois os sinais multimídia isócronoscontinuam sendo enviados através do RTP/RTCP.

Não podemos esquecer de mencionar que o desenvolvimento do H.323 fez com que osfabricantes abandonassem seus protocolos proprietários e passassem a adotar a duplaH.323/T.120 para comunicação multimídia em tempo real através da Internet. Além disso,outra grande conquista do H.323 é que estes sistemas mantêm a compatibilidade comsistemas mais antigos que já possuem uma grande base instalada, tal como sistemas H.320,o que representa economia de grande quantidade de dinheiro.

O trabalho mostrou também que deficiências encontradas na versão 1 do H.323 foramcorrigidas na versão 2 da recomendação que agora endereça a comunicação Multimídia emredes de larga escala (WAN), tais como a Internet, introduzindo maneiras para a otimizaçãono processo de estabelecimento de conexões.

Para encerrar, recomendamos que as corporações que optarem por desenvolver soluçõespara a comunicação e colaboração visual deverão se preocupar em escolher uma soluçãopadronizada, que não limite as suas opções, a produtos desenvolvidos por somente um

53

fabricante, e além disso permita que a comunicação possa ser estabelecida através daInternet.

54

8. Bibliografia [CIS 01] Cisco Systems White Paper. Designing Service Provider Core Networks to

Deliver Real-Time Services.

[CIS 97] Cisco Systems White Paper. Quality of Service (QoS) Networking.

[COM 95] Commer, Douglas E. Internetworking with TCP/IP volume I: Principles,Protocols and Architetures . New Jersey: Prentice Hall, 1995.

[DAV 99] Davis, Andrew W. Integrated Collaboration: Driving Business Efficiency tothe Next Millenium. [http://www.picturetel.com/pdf/intw01.pdf]

[HER 00] Hersent, Oliver, Gurle, David e Petit, Jean-Pierre. IP Telephony: Packet basedmultimedia communications systems. Addison Wesley Inc.

[HYP] http://www.hypernews.org/HyperNews/get/www/collaboration.html

[IET 98] Request for Comments: 2474. Definition of the Differentiated Services Field(DS Field) in the IPv4 and IPv6 Headers. Dezembro de 1998.

[IET 98] Request for Comments: 2474. An Architecture for DifferentiatedServices.1998.

[IET 98] Request for Comments: 1889. RTP: A Transport Protocol for Real-TimeApplications. January 1996.

[IET 98] Request for Comments: 1890. RTP Profile for Audio and Video Conferenceswith Minimal Control. January 1996.

[ITU 98] ITU-T Rec. H.323. Series H : Audiovisual and Multimedia Systems.Infrastructure of audiovisual services – Systems and terminal equipment foraudiovisual services. Packet-based multimedia communications systems. 1998.

[ITU 98] ITU-T Rec. H.225.0. Series H : Transmission of non-telephone signals - Callsignalling protocols and media stream packetization for packet basedmultimedia communication systems. 1996.

[ITU 98] ITU-T Rec. H.225.0. Series H : Audiovisual and multimedia systems –Infrastructureof audiovisual services – Communication procedures. 1997.

[KUM 00] Kumar, Vinet, Korpi, Markku e Sengodan, Senthil. IP Telephony withH.323:architetures for unified networks and integrated services. New York,NY. John Winley & Sons Inc.

55

[MCD 94] Mcdysan, David E., Spohn, Darren L. ATM: Theory and Application. NewYork: McGraw-Hill, 1994.

[MCD 98] Mcdysan, David E.. SPOHN, Darren L. Hands-On ATM. New York :McGraw-Hill, 1998.

[MIN 97] Minoli, Dan, Golway, Tom, com Smith, Norris. Planning and ManagingATM Networks. Grenwich: Manning Publications Company, 1997.

[ONU 95] Onuural, Raif O. Asynchronous Transfer Mode Networks: PerformanceIssues 2 edition. Artech House, 1995.

[SCH 99] Schaphorst, Richard. Videconferencing and Videotelephony technologyand standards. 2º edition. Norwood: Artech House, 1999..64

[STA 95a] Stallings, Wiliam. Handbook of Computer-Communications Standards:The Open System Interconection (OSI) Model and OSI related Standards. Volume 1, 2 rd edition. Mcmillan Publishing Company, 1995.

[STA 95b] Stallings, Wiliam. ISDN and Broadband ISDN with Frame Relay andATM. 3 rd edition. Prentice Hall, 1995.

[STA 97] Stallings, Wiliam. Local e Metropolitan Area Networks. 5 rd edition.Prentice Hall, 1997.

[TAN 96] Tanenbaum, Andrew S. Computer Netwoks. 3 rd edition. New Jersey:Prentice Hall, 1996.

[VTE] http://www.vtel.com/industry/education/profiles.htm. Pacific BellVideoconferencing for learning: Introductionhttp://www.kn.pacbell.com/wired/vidconf/intro.html.

http://www.vtel.com/industry/education/profiles.htm

Colaboração visual: Implementando o trabalho cooperativo...

Documents

Transcript of Colaboração visual: Implementando o trabalho cooperativo...