Qos para videoconferência

Alexei Korb
Liane Tarouco
Leandro Marcio Bertholdo
UFRGS
Tópicos da apresentação

 A experiência do GTRH & UFRGS

 O funcionamento do MCU
 Análise do protocolo
 Estratégia de QoS adotada
Experiências de EAD

 GTRH
– Segurança de redes de computadores
– Gerência de Redes
– Simpósio Evolução da Internet (COMDEX
2001)
 UFRGS
– Pós-graduação Informática na Eucação
Cenário
Recursos utilizados

 MCU
– Meeting Point da CuSeeMe
– CISCO 3510
 Cliente
– Netmeeting
– CuSeeMePro (versão > 4.1)
– Polycom
 Sistema de videoconferência

 Servidor de
videoconferência
– ITU H.323
– Vídeo sobre
pacotes
 Clientes
– Netmeeting
– CuSeeMe
– outros
 Videoconferência na
Internet
 CuSeeMe
 Mbone
 H.323
Experiências de ensino à
distância
 Diversas áreas tem implantado
atividades de ensino à distância
 São utilizados serviços básicos da
Internet
– correio eletrônico
– WWW
– chat
Componentes da solução

 Terminais
 Gateways
 Gatekeepers
 Unidades de Controle Multiponto
(MCU - Multipoint Control Unit)
 Terminais

 São entidades da H 323 nas extremidades de

uma rede de transmissão de multimídia, as
quais comunicam-se em duplo sentido e em
tempo real com outros terminais H 323 através
da transmissão e recepção de sinais de
controle, áudio, vídeo e dados (isoladamente
ou em conjunto).
Gatekeeper

 Controle de acesso
 Gerenciamento de largura de banda
 Localização de Gateways
 Integrante do software MCU
Gatekeeper
 provê serviços de controle de chamadas para os
terminais H.323 presentes na zona Controle de acesso
 Controle de acesso (Autorização de chamadas)
 Tradução de endereços
 Gerenciamento de largura de banda
 Localização de Gateways
 Gerenciamento de zona
 Sinalização de controle de chamada (no modo de
conferência roteado)
 Gerenciamento de chamadas
 Implementação de função deve estar separado de outras
funções (tal como MCU)
MCU

 Estabelecer uma conferência

multiponto com um ou mais
terminais e Gateways
 Elemento essencial para o
estabelecimento de uma
videoconferência entre mais de 2
estações (comunicação multiponto)
H.323 componentes
Terminais H.323
Escopo da norma H.323

CODEC de áudio
Eqto de entrada de áudio G.711, G.722, Receive
(microfone, vídeo cassete) G.723, G.728, G.729
Path
Eqto de entrada de vídeo
Câmera de vídeo, vídeo CODEC de vídeo Delay
cassete) H.261, H.263

Aplicações de dados Camada Interface

(T.120, etc)
H.225.0 LAN
Controle do sistema

Controle H.245

Controle de
chamada
Controle do sistema H.225.0

Controle RAS
H.225.0
MCU usado na UFRGS

 O servidor de videoconferência
– software MeetingPoint da CuSeeMe
Networks, que provê a função de MCU
(Multipoint Control Unit)
– ambiente LINUX
– hardware PC 750 MHz com 128 Mbytes
de memória e 18 Giga bytes de disco
 http://mcu.ufrgs.br/mpcs
Instalação do MCU

 Servidor instalado no CPD/UFRGS

– ponto de maior conectividade da rede
– no-break
– operação e acesso 24 horas por dia
H.323 Gatekeeper
 Tradução de endereços
– H.323 Alias para endereços IP com base
em registro de terminais
– Possibilidade de nomes “email-like”
– Possibilidade de nomes “phone number
like”
 Controle de Admissão
– Permissão para completar a chamada
– Pode impor limites de banda
– Método para controlar o tráfego da LAN
19
Funções Gatekeeper

 Gerenciamento do gateway
– H.320, H.324, POTS, etc.
 Sinalização de chamadas
– Pode rotear chamadas para prover
serviços suplementares ou prover
funcionalidade Multipoint Controller
 Gerenciamento/Relatórios/Registros de
chamadas
20
 H.323 Protocol Stack
Control Data Audio Video A/V Cntl Control

Gatekeeper
G.7xx H.26x
Reg,
H.235 Adm,
H.225. 0 / H.245 RTCP Status
T.120 (Opcional p/
Q931
Criptografia)
H.225. 0
/ RAS
RTP

TCP UDP

IP
21
Call Setup

A Call Setup Example

 a point to point call
 3rd terminal invited into call (Ad hoc multipoint)
 One Gatekeeper using the Direct Call Model

 O gatekeeper é usado para todos serviços que não dependem

do terminal:
– Conhecimento de quem está on-line e pode ser chamado
– Designar acesso a recursos de rede
– Monitorar a disponibilidade dos recursos de rede, gateways e
terminais

22
 Call Connection
GK

(5) ARQ
May I answer?
(6) ACF
Yes
(4) SETUP (Create)

PictureTel

(7) ALERTING
(8) CONNECT (User answers)
Bob
Bill
23
Call Connection – localização e registro com
o gatekeeper
Descoberta automática
GK
1) O endereço IP do GK pode Porta 1718 (multicast) grupo 224.0.1.41
ser configurado manualmen- Porta 1719 (unicast)
te ou ser descoberto
automaticamente (3) RRQ
(1) GRQ (multicast)
Quem é meu
Registro com GK?
o GK
(2)
(4) GCF
RCF
Você está
Eu registrado
posso ser seu
comigo.
GK.

PictureTel

Mensagem contém o endereço

de transporte para estabelecimento
da chamada
Bob
Bill
24
 Bill invites Ross
GK (13) ARQ
May I
(10) ARQ
Join?
Invite
(11) ACF (14) ACF
Ross
Resolved Ross’s Yes
IP Address
(12) SETUP (Invite)
PictureTel

(15) ALERTING
(16) CONNECT
(17) H.245 CONNECTION Ross

25
 Call Connection – Estabelecimento da
Chamada

GK
(8) ARQ (5) ARQ
May I Can I make
Join? a call?
(6) ACF
(9) ACF
Yes – Resolved
Yes
Biil´s IP address

(7) SETUP (Invite)

PictureTel

(10) ALERTING
(11) ALERTING
Bob
Bill
(12) H.245 CONNECTION 26
QoS nos canais RAS, H.225.0 e H.245
Caso qualquer uma destas
operações falhar o Sist.
Pode ficar indisponível .

 RAS – Usado para: Soluções possíveis:

– Localização e registro com GK; -Usar unicast com TTL baixo
-Usar ARQ pré concedido
– Negociação de largura de banda, e; -Designar prioridades
– Desligamento do GK. (QoS), para usuários
prioritários

 H.225.0 – Usado para: Deve ser garantido Delay

mínimo para o
– Estabelecer e encerrar conexões estabelecimento da
chamada.

 H.245.0 – Usado para: Deve ser garantido Delay

– Estabelecer a troca de capacidades mínimo para o
estabelecimento da
chamada.
 Medições realizadas
 Comunicações T.120 entre Terminais (Netmeeting), iniciam
antes da abertura de canais lógicos. (recomendação determina
que seja depois), estamos investigando o motivo;
Exemplo clique aqui !

 O modelo de conferência centralizado (tightly coupled) ocupa

muitos recursos do MCU, pode ser uma causa das falhas de
comunicação, pois todos mantém canais H.245, ativos com o
MCU durante todo o tempo de comunicação;
Abaixo é mostrado um fragmento de um log do MCU Meetingpoint
Event> Mon Nov 26 17:15:54 2001 Pkts in 25655 Pkts
Event> client Leandro Bertholdo - T.120 session closed
Event> Mon Nov 26 17:16:54 2001 Pkts in 27438 Pkts
Event> Mon Nov 26 17:17:55 2001 Pkts in 1695 Pkts
Event> client Alexei Korb timeout -- holding down
Event> Mon Nov 26 17:18:55 2001 Pkts in 3324 Pkts
Event> client Alexei Korb - T.120 session closed due to insufficient bandwidth
Event> Mon Nov 26 17:19:56 2001 Pkts in 4708
Event> Mon Nov 26 17:20:56 2001 Pkts in 5850
Event> client Liane Tarouco - T.120 session closed due to insufficient bandwidth
Event> Mon Nov 26 17:21:57 2001 Pkts in 7114
Event> Mon Nov 26 17:22:58 2001 Pkts in 8182
A troca de
dados
T.120
começa
aqui

O canal foi
estabelecido
aqui
 Medições realizadas
 Comunicações T.120 entre Terminais (Netmeeting), iniciam
antes da abertura de canais lógicos. (recomendação determina
que seja depois), estamos investigando o motivo;
Exemplo clique aqui !

 O modelo de conferência centralizado (tightly coupled) ocupa

muitos recursos do MCU, pode ser uma causa das falhas de
comunicação, pois todos mantém canais H.245, ativos com o
MCU durante todo o tempo de comunicação;
Abaixo é mostrado um fragmento de um log do MCU Meetingpoint
Event> Mon Nov 26 17:15:54 2001 Pkts in 25655 Pkts
Event> client Leandro Bertholdo - T.120 session closed
Event> Mon Nov 26 17:16:54 2001 Pkts in 27438 Pkts
Event> Mon Nov 26 17:17:55 2001 Pkts in 1695 Pkts
Event> client Alexei Korb timeout -- holding down
Event> Mon Nov 26 17:18:55 2001 Pkts in 3324 Pkts
Event> client Alexei Korb - T.120 session closed due to insufficient bandwidth
Event> Mon Nov 26 17:19:56 2001 Pkts in 4708
Event> Mon Nov 26 17:20:56 2001 Pkts in 5850
Event> client Liane Tarouco - T.120 session closed due to insufficient bandwidth
Event> Mon Nov 26 17:21:57 2001 Pkts in 7114
Event> Mon Nov 26 17:22:58 2001 Pkts in 8182
 Medições realizadas
Problema:

–A captura não apresenta o horário em que o pacote foi capturado.

Fica muito difícil encontrar o que está acontecendo em cada pacote
enviado pelo MCU exatamente no momento de encerramento da
conexão.
–Seria interessante um analisador de protocolos on-line para
descobrirmos exatamente o que está acontecendo;
–A documentação de algus produtos ainda é carente de informações
detalhadas e precisas, pois como o padrão está evoluindo
constantemente.
Possíveis candidatos para tratamento diferenciado (QoS)
–Canal RAS.
–Sinalização H.225.0
–Troca de Capacidades
–Canais de mídias (Classificar de níveis de serviços diferenciados
dependendo da aplicação de usuário).
Software cliente

 Netmeeting (Microsoft)
 CuSeeMe (CuSeeMe Networks Inc)
Sistemas adicionais usados

 Learning Space
– controle de acesso dos alunos ao ambiente
de ensino-aprendizagem
– gerenciamento de comunicação
 Equitext
– desenvolvimento próprio
– co-autoria via WWW
 Servidor Real (broadcast)
– Diversas velocidades (20Kbps a 250 Kbps)
Transmissão via Real

 Várias velocidades possíveis

 Plugin e navegador
 Ajustável ao usuário
– Modem
– rede TV cabo
– Intranets
Formas de apoio a interação

 Síncrona
– Chat
– Videoconferência
 Assíncrona
– Email
– Forum
– Editor colaborativo de texto
– Editor colaborativo de mapa conceitual
  T.120

Reprojetor Câmara
documento
s

Whiteboard
impressora
RDSI RDSI
Desktop Video T.120
+ Whiteboard
+ Compart.
DDD LAN
Aplic.
PictureTel PictureTel PictureTel

Audio
+ Compartilhamento de
Aplicações
 T.120 protocol stack

T.126 T.127 T.130

Overhead Proj

Reservations
App Sharing
File Transfer
Whiteboard

A/V Control
Documents

Switching
Photos
TERMINAL

Application Protocols
T.126 - Still Image, T.127 - File Transfer
T.130 - A/V Control, T.SHARE, T.RES
T.124 - Generic Conference Control
T.122 / T.125 - Multipoint Comm. Service
MCU

T.123 - Transport Stacks

Voice/
ISDN POTS LAN ATM
Data
T.120

 O padrão T.120 contém uma série de

protocolos de comunicação e aplicação,
e serviços que dão suporte para
comunicação de dados multiponto em
tempo-real.
 Aplicações colaborativas, tais como
conferências de dados, aplicações
multiusuários e jogos para multi-
jogadores
T.120
 Entrega de dados multiponto
 Interoperabilidade e independência de plataforma
 Entrega de dados confiável
 Entrega habilitada para multicast
 Transparência de rede e independência de rede
 Independência de aplicação
 Co-existência com outros padrões
 Extendabilidade
Série T.120

 T.120: Protocolos de dados para

conferência multimídia: provê uma
sinopse da série T.120 (1996)
 T.121 : Padrão de aplicação genérico:
provê um guia para desenvolvimento de
protocolos de aplicação T.120 (1996).
Série T.120
 T.122: Descrição do Serviço de
Comunicação Multiponto (MCS):
descreve os serviços multiponto
disponíveis para fabricantes (1993)
 T.123 Pilhas de protocolos para
aplicações de teleconferências
audiográficas e audiovisuais:
especifica protocolos de transporte
para vários tipos de redes incluindo
POST, ISDN e LANs (1994)..
Série T.120
 T.122: Descrição do Serviço de
Comunicação Multiponto (MCS):
descreve os serviços multiponto
disponíveis para fabricantes (1993)
 T.123 Pilhas de protocolos para
aplicações de teleconferências
audiográficas e audiovisuais:
especifica protocolos de transporte
para vários tipos de redes incluindo
POST, ISDN e LANs (1994)..
Série T.120

 T.124: Controle de conferência

genérico: define as reservas de suporte
de protocolos de aplicação e serviços
de controle de conferência básicos para
conferências multiponto (1995).
Série T.120

 T.124: Controle de conferência

genérico: define as reservas de suporte
de protocolos de aplicação e serviços
de controle de conferência básicos para
conferências multiponto (1995).
T.124
Série T.120

 T.125 : Especificação de protocolo de

serviço de comunicação multiponto:
especifica o protocolo de transmissão
de dados para serviços multiponto
(1994).
Série T.120

 T.126: Protocolo para tratamento e

anotação de imagem não animada:
define compartilhamento de dados
colaborativamente, incluíndo quadro
branco, compartilhamento de imagem,
apresentação de imagem gráfica e
intercâmbio de imagem em coferência
multiponto (1995).
Série T.120

 T.127: Protocolo de transferência de

arquivo binário multiponto (1995):
define um método de troca de arquivos
em uma conferência multiponto (1995).
 Série T.120

 T.128: Protocolo de compartilhamento de

aplicações multiponto: define como
participantes, em uma conferência T.120 podem
compartilhar aplicações locais, de forma que
participantes de outra conferência possam ver a
imagem da aplicação compartilhada, e usar o
mouse e o teclado para controlar essa aplicação
como se ela estivesse rodando localmente.
Série T.120

 T.134: Entidade de aplicação de textos

de chat: uma definição da T.121 para
protocolo de textos de chat.
Série T.120

 T.135: Sistema de uso para reserva de

transações com uma conferência T.120:
define os protocolos reservados para
conferência em um ambiente T.120,
tipicamente entre uma aplicação cliente
e um sistema de agenda que reserva
unidades de controle de recursos
multiponto (MCUs ou "bridges").
 Portas usadas
Para o NetMeeting (ou outro cliente H.323)
 TCP Port 7648: CU-SeeMe connections to the MPCS.

 UDP Port 7648: sending/receiving CU-SeeMe Video Chat streams.

 UDP Port 24032: sending/receiving RTP audio and video streams
for CU-SeeMe.
 TCP Port 1503: T.120 Client connections.
 TCP Port 1720: H.323 call signaling.
 UDP Port 56800: sending/receiving RTP video streams for clients
that support RTP on separate ports.
 UDP Port 1424: routing H.323 audio streams to third-party streaming
applications.
 UDP Port 1414: routing H.323 video streams to third-party streaming
applications.
 UDP Ports 40000-50000
 QoS

 Quality of Service ou Qualidade de

Serviço - a qualidade necessária para
satisfazer o usuário daquela aplicação
 Aplicações necessitam QoS diferentes:
– telefonia
– videoconferência
– download de arquivos
– TV.
Testes e experiências realizadas

 UFRGS
– VoIP
 Rede TCHÊ
– Videoconferências
 RNP
– COMDEX 2001
– GRID
UFRGS - VOIP
 Topologia
UFRGS - VOIP

 Problemas enfrentados
– Delay
– Fragmentação e Interliving
– Chamadas não completadas
– Sem tom de discar
– Desconexão
– Cortes na voz
UFRGS - VOIP

 Testes Realizados
– CQ (Custom Queueing)
– PQ (Priority Queueing)
– LLQ (Low Latency Queueing)
– IP RTP Priority
 Solução com melhores resultados
– Multilink PPP com LLQ
TCHÊ - Videoconferências
TCHÊ - Videoconferências

 Problemas enfrentados
– Alto descarte de pacotes (> 30%) no
tráfego normal
– Mesmo com sobra de 2X a banda
necessária, o tráfego em rajada do canal
torna impossível transmissões de vídeo
não buferizadas.
– Equipamentos IBM
Tchê

 Utilizada a implementação da IBM de

DiffServ em conjunto com RSVP
 LLQ foi utilizado visando manter a
compatibilidade com Cisco.
 Definido o serviço HVIDEO (Expedited
Forwarding) para video originados no
MCU e Real Server
Tchê

 Definido o serviço CACHE (Assured

Forwarding) para tráfego controlado, ou
seja, que faz uso da estrutura de
caches existente.
 Reserva de banda de 19% ou 300Kbps
para o serviço HVIDEO
 Reserva de 15% da banda para o
serviço CACHE
RNP
COMDEX
COMDEX

 Solução: Serviços Diferenciados com

reserva de Banda (DiffServ + RSVP)
 Necessidade de padronização em
enlaces PPP e redes ATM
 Melia->RS (RNP): Ciscos com LLQ
 Porto Alegre -> Interior: IBMs com LLQ
Configuração do QoS

 Estratégia de Filas: LLQ(Low Latency

Queuing
 Tipo de Serviço: EF (Expedited
Forwarding)
 Reserva de banda: Variável,
configurada de forma independente em
cada segmento
GRID

 Framework utilizado para

videoconferência mundial de alta
definição, permitindo interagir com
outros participantes.
 Experiência pioneira com Brasil,
Canadá, Alemanha, Estados Unidos,
Itália, China e Japão
 Utiliza IP Multicast
GRID

 Necessidade de requisitos de alta

velocidade (audio e vídeo digital de alta
qualidade)
 Recursos alocados
– ATM pvc 10Mbps RJ-RS
– PVC exclusivo para essa transmissão
GRID

 Resultados
– Todos os recursos de banda foram
utilizados
– Ótima qualidade de transmissão e
recepção
Conclusões

 Os IBMs demonstraram ser mais

estáveis que a solução da Cisco
quando agregando outros serviços
(IPV6, BGP, Multicast, QoS e RSVP)
 A simples utilização de priorização
através de QoS não garante uma
videoconferência estável mesmo com
taxas até 3X superior a da
vídeoconferência
Conclusões

 A Reserva de Banda é indispensável,

seja através de VCs ou RSVP
 A solução Diffserv & RSVP se mostrou
totalmente adequada para atividades
como VoIP e Videoconferências
buferizadas ou em tempo real.
 O RSVP tem o inconveniente de
necessitar reconfigurar a reserva
desejada em todos os trechos.