6. Conceitos do Controle de Áudio e Vídeo 

6.1. Modelo de Conferência AVC

A arquitetura do controle de áudio e vídeo é construída a partir de uma coleção de elementos, a fim de prover uma nomenclatura não-ambígua para  o controle de uma conferência. A seguir, veremos os elementos do modelo.

A conexão lógica entre dois nós adjacentes que é usada para transportar a informação real time de modo bi-direcional entre esses nós, é chamada link real time. A informação em tempo real transportada num link desse tipo pode incluir qualquer combinação de streams real time de vídeo, áudio ou dados. Tipicamente esses links possuem um canal de controle associado, onde trafegam informações de capacidade de troca e de configuração do link. Esse canal não é considerado parte do link real time, pois não transporta dados em tempo real. De maneira similar, o canal de dados do T.120 não transporta dados em tempo real e por isso também não faz parte do link.

Cada extremidade do link está conectada a uma porta de comunicação . Elementos de rede que exercem a função de ponte precisam de múltiplas portas de comunicação; por sua vez o terminal normalmente possui uma única porta. Em algumas redes (como LANs) uma mesma porta pode ser compartilhada entre vários links de tempo real.

Figura 4 - Link real time com suporte a comunicação bi-direcional entre nós adjacentes

É permitida a existência de vários links real time entre nós adjacentes, desde que hajam múltiplas conexões físicas independentes entre eles. Se vários conexões entre dois nós são gerenciadas como uma única entidade, nesta recomendação elas são consideradas como um único link real time. Por exemplo, múltiplas conexões ISDN podem ser gerenciadas como uma única entidade usando a H.221.

Para definir o mecanismo para reportar a capacidade de um link real time, é necessário que o link e seus nós associados sejam identificados univocamente. Um link real time é identificado pelas sua extremidades (usando o identificador de usuário do GCC dos seus respectivos nós) e, opcionalmente, um número local único para distinguir múltiplos links real time entre o mesmo par de nós. Em muitos casos a hierarquia AVC espelha a T.120; em tais situações, o GCC Conference Roster provê diretamente o identificador de usuário GCC do nó adjacente mais alto na hierarquia T.120; devem existir informações suficientes (como telefone) na lista da conferência para permitir que o identificador do usuário seja associado com um site físico específico.

Em um ambiente não-orientado a conexão, a interpretação dada ao link real time é diferente. Nesse caso, considera-se que tal link existe entre qualquer par de nós conectados por um mesmo canal de controle multimídia. Por exemplo, em um ambiente H.323, considera-se que existe um link real time entre as extremidades e os controladores multiponto, com esse último sendo o nó mais alto do link.

Com o propósito de reportar a capacidade do link, o status de cada nó na extremidade do link é determinado por sua posição na hierarquia T.120. O nó mais baixo é chamado de lower node e é subordinado ao nó da outra extremidade do link real time (higher node). Se existir um link real time entre nós que não estão diretamente conectados na hierarquia T.120, então o nó mais baixo deve ser o nó identificador de usuário de menor valor numérico.

Um link real time pode ser dividido em vários canais lógicos. Um canal lógico é usado para transportar um único fluxo unidirecional de uma mídia específica.  Cada fluxo de informação requer o seu próprio canal lógico.

O número de canais lógicos dentro de um link real time e as características de transmissão desses canais podem variar dinamicamente no curso da conferência. Não é necessário haver simetria dentro de um link real time, assim, o número de canais por tipo de mídia pode diferir.

Figura 5 - Link Real Time

Figura 6 - Comunicações full duplex de áudio e vídeo

Um stream é um fluxo unidirecional de informações em tempo real que sai de uma origem específica e atinge um ou mais destinos. A origem pode ser tanto um dispositivo físico (como uma câmera ou um microfone) ou qualquer outra entidade introduzida na conferência (como um sinal “off-air”). O destino do stream é chamado sink.

A infraestrutura AVC é o conjunto de recursos usados para prover a característica de tempo real em uma conferência. Ela compreende os links real time e os recursos para processamento real time dentro dos nós. Dispositivos controláveis como câmeras e videocassetes, capazes de serem origem ou destino de um stream, não são considerados parte da infraestrutura AVC.

6.2. Sessões de Comunição AVC

Por default, todos os terminais participantes de uma conferência AVC gerenciada interagem entre si dentro de uma única sessão de comunicação AVC. Entretanto, em alguns casos, pode ser necessário separar comunicações áudio-visuais autônomas dentro da mesma conferência. Por exemplo, em um encontro comercial, pode ser necessária uma conversação privada, enquanto uma reunião pode consistir de vários grupos de discussão cujos participantes entram de acordo com seus interesses no assunto da conversação. O AVC suporta tais operações permitindo que múltiplas sessões de comunicação AVC sejam estabelecidas dentro de uma conferência. Essas sessões são anunciadas usando-se o mecanismo de Aplication Roster da T.124 e podem ser associadas a sessões de protocolo de aplicação de dados que são estabelecidas separadamente usando a T.124.

6.2.1. Interação entre Sessões e Serviços AVC

Todos os serviços AVC são providos no contexto de uma sessão. Quando um nó entra em uma sessão AVC ele é automaticamente subscrito (e pode fazer uso) nos serviços ativos dentro daquela sessão. Serviços inativos podem ser subscritos explicitamente. A interpretação à subscrição de um nó em um serviço é específica do serviço. Quando um nó sai da sessão, ele é automaticamente removido de todos os serviços daquela sessão.

6.3. Papéis em Conferências

O AVC define vários papéis que podem ser usados para fazer o acordo entre participantes de conferências particulares e privilégios e status adicionais para o uso de serviços AVC. Todos esses papéis são associados a um conjunto de regras que suportam o seu uso no que foi especificado. Os serviços AVC ‘sabem’ quais os papéis ativos dentro de uma sessão e adaptam seu comportamento para acomodar os privilégios e necessidades deles. O AVC permite que papéis sejam pré-atribuídos e mantidos por nós em estado inativo até que eles sejam necessários, alternativamente eles podem ser adquiridos de forma dinâmica. Papéis só podem ser mantidos por terminais AVC e nós convencionais.

O AVC suporta  o estabelecimento de sessões separadas de áudio e vídeo dentro de  uma conferência. Essas sessões formam sub-conferências e, como tal, podem usar vários papéis AVC independentemente.

6.3.1. Papel de Presidente

Permite que um nó exerça o papel de presidente (chair role) de uma sessão AVC. O presidente é um participante da sessão e tem a responsabilidade de gerenciar os procedimentos de controle dentro dela. Quando são permitidas múltiplas sessões, cada uma deve ter o seu presidente. O presidente da sessão primária deve aliar-se ao condutor GCC (GCC Conductor) durante a sincronização do AVC com a sessão de dados.

6.3.2. Papel de Apresentador

O papel de apresentador existe para permitir que um nó torne-se o foco de uma sessão AVC, mandando em Broadcast seus streams real time para os outros participantes.

Cada serviço AVC é informado do papel e adapta seu comportamento para atender os requisitos do apresentador. Quando múltiplas sessões são permitidas, cada sessão pode ter seus próprios apresentadores. Quando são designados vários apresentadores, eles devem estar associados em um grupo AVC. Cada membro do grupo pode possuir um número de seqüência, a fim de ordenar os apresentadores.

6.3.3. Papel Público

O papel público pode ser pré-designado pelo concentrador ou registrado quando um terminal entra na conferência. Esse papel é designado para um nó registrado como anônimo na conferência. Um nó público é primariamente um visualizador.  Tipicamente, membros públicos não  são capazes de participar interativamente da conferência, a menos que obtenham permissão explícita através do uso do serviço de controle.

6.3.4. Papel de Concentrador 

O concentrador de uma conferência AVC controlada é o concentrador GCC. Conferências são unidas usando-se primitivas GCC que explicitamente fazem provisão para parâmetros AVC.

6.4. Grupos AVC

O AVC tem a habilidade de associar participantes em grupos. O propósito do grupo pode ser especificado explicitamente ou ser determinado pelo framework em uso. Um grupo pode ser usado para gerenciar a comunicação entre membros do grupo que também estão participando, simultaneamente, da conferência principal. Um exemplo de onde isso pode ser usado é uma sessão privada de quadro branco dentro de uma conferência que requer suporte de áudio. Grupos podem ser usados como um contexto para serviços e papéis dentro do framework de conferência selecionado.

6.5. Modelos de Conferência e Frameworks

Os protocolos T.130 são projetados para dar suporte ao gerenciamento de diversos tipos de cenários de teleconferências. Para facilitar isso, o AVC define vário modelos de conferência padrões, cada um projetado para ser usado em um tipo particular de ambiente de encontro. Quando  a conferência é criada, o concentrador deve selecionar um modelo de conferência apropriado ao cenário desejado. Os requisitos desse modelo são, então, expressos através da definição de um framework para a conferência – um conjunto de parâmetros os quais efetivamente definem um conjunto de regras sob as quais a conferência opera. Elas incluem o regime de gerência, modo de inicialização, número máximo de participantes de cada tipo de nó, número e tipos de sessões, os papéis que os nós podem exercer dentro de uma determinada sessão, etc. O framework permite que o concentrador modele muito precisamente os requisitos de uma conferência do mundo real como um evento de teleconferência, se necessário. Os controles de acesso de cada participante (com um dado papel) de uma sessão de conferência AVC também podem ser definidos pelo concentrador. Grupos de nós podem ser associados com o objetivo de controle. Um grupo ordenado pode ser definido para prover, por exemplo, uma seqüência de apresentadores que falam em círculos; a cada membro do grupo é dada uma posição na seqüência.

Frameworks de conferência para modelos de conferência padrões são especificados na T.132. O framework também pode ser usado para especificar modelos de conferência não-padronizados – o concentrador de conferência simplesmente seleciona o conjunto apropriado de parâmetros do framework.O framework de conferência é uma parte opcional na criação de uma conferência AVC; na sua ausência, a configuração AVC será baseada nas capacidades de negociação e nas opções dos participantes invocados.

A filosofia do framework de conferência permite que o concentrador de conferência estabeleça cenários potencialmente complexos, sem expor os participantes à complexidade de configurar ou usar serviços associados. O modelos de conferência padrões simplificam a tarefa do concentrador para cenários comumente solicitados.

O AVC define três classificações gerais de modelo: encontros (meetings), conferências (conferences) e reuniões (gatherings). Eles visam modelar os aspectos do controle de áudio e vídeo da conferência.

6.5.1. Encontros AVC

A classe de encontros é caracterizada pelo fato de que todos os terminais participantes se comportam como nós convencionais e participam como pares na conferência AVC. São definidos dois modelos de encontros:

6.5.1.1. Modelo de Encontro Convencional

O modelo de encontro convencional é fornecido para suportar os requisitos típicos de uma teleconferência onde os participantes se comunicam primariamente em uma única sessão, com o uso ocasional de outras sessões para descongestionar. Um encontro convencional pode ser tanto informal quanto formal e é permitido o uso do papel de apresentador.

Esse modelo tem uma sessão primária através da qual são permitida sessões públicas e privadas, usadas para descongestionar. Dentro de tais sessões só estão disponíveis aos participantes as funções básicas de áudio e vídeo e o uso de papéis é proibido. Participantes não podem transferir diretamente entre tais sessões; eles apenas podem fazer transferências entre a sessão primária e uma sessão usada para descongestionar.

6.5.1.2. Modelo de Salas de Encontro Virtuais

Neste modelo, o concentrador é capaz de estabelecer várias sessões paralelas separadas dentro do contexto de uma única conferência, cada sessão provendo uma sala virtual separada dentro do espaço da conferência. Todas as sessões têm o mesmo status e podem ser públicas ou privadas. Não existe restrição de transferências entre sessões, além das associadas às sessões privadas.

6.5.2. Conferências AVC

Essa classe difere da anterior por suportar também nós públicos. Isso permite duas classes diferentes de participação: nós convencionais agindo como pares (como na classe de encontros) e nós anônimos agindo como membros do público.

6.5.2.1. Conferência Convencional

Esse modelo provê suporte para conferências AVC nas quais um público está presente. Um membro público é tipicamente capaz de ver e ouvir os procedimentos, mas não pode interagir, exceto através do serviço de controle. Nós convencionais possuem o mesmo nível de funcionalidade disponível em encontros AVC, com permissão para sessões adicionais para os grupos. Membros públicos podem escolher de qual sessão participar.

6.5.2.2. Conferência com Broadcast

Essa é uma conferência onde um ou mais nós convencionais (ou nó servidor) mandam mensagens em Broadcast a um público, mas não existe interação entre eles. Toda a comunicação ocorre dentro de uma única sessão.

6.5.3. Reuniões

Tipo de conferência projetada para ser informal, com o mínimo de restrições aos participantes, os quais são livres para estabelecer , entrar ou abandonar uma sessão. Pode ser usada para suportar cenários de conferência fracamente acoplados. Esse modelo não suporta os papéis de presidente e apresentador.

6.5.4. Criação e Configuração de Conferência

Deve-se considerar que o modelo convencional de encontro será o modo operacional default na ausência de qualquer outra informação.

O concentrador pode especificar outros modelos de conferência os quais irão, na inicialização, ativar um framework pré-definido e gerenciar o regime. Esse framework pode influenciar o modo dos serviços dentro daquela conferência. O concentrador tem a habilidade de se aprofundar na modelagem da conferência se for necessário, pela pré-definição de grupos e de papéis dentro de um dado framework. Essa habilidade permite projetos customizados e pré-configuração de cenários de conferências muito específicos. O concentrador pode também ‘amarrar’ a configuração de um modelo fixo de conferência durante a sua duração. Permitindo, alternativamente, que o presidente tenha os privilégios do concentrador  será possível fazer ajustes dinamicamente.

6.5.5. Uso de Papéis e Grupos dentro de um Modelo de Conferência

A tabela 1 mostra as regras básicas no que diz respeito a papéis e grupos para cada modelo de conferência padrão. Onde:

P = o papel ou função deve ser pré-designado(a) pelo concentrador.

D = o papel ou função deve ser designado(a) dinamicamente durante a conferência.

Tabela 1- Papéis permitidos dentro de modelos de conferência

6.5.6. Implementação de Terminais ‘Leves’

Terminais áudio-visuais simples que precisam de controle de áudio e/ou vídeo, mas não precisam de outras aplicações de dados (como quadro branco, compartilhamento ou transferência de arquivos), podem ser capazes de implementar a T.130 com um sub-conjunto de funcionalidades da infraestrutura T.120. Ainda está sendo estudado um perfil T.120 leve, identificando os componentes T.122/5 e T.124 necessários para suportar a T.130 nesses terminais.

Além disso, terminais não-T.120 ainda serão capazes de tirar benefícios da funcionalidade AVC quando outro nó (elemento de rede) for capaz de servir de proxy em seu favor. O proxy também pode ser usado para suportar terminais apenas de recepção.

A definição de um protocolo de proxy para permitir que terminais T.120 acessem as funcionalidades da T.130 ainda está em estudo. No entanto, o problema de saber para onde mandar o controle e as indicações destinadas a terminais desse tipo, é resolvido pela T.120.  O proxy usa os mecanismos GCC para obter o identificador de usuário para o terminal e MCSs podem, então, rotear informações de controle e gerência direcionadas a ele, independentemente da topologia.