Grupo de Trabalho RNP:

Aplicações educacionais em
rede

Liane Tarouco
UFRGS
Participantes
 Liane Tarouco
 Lisandro Z Granville
 Marie-Cristine M G Fabre
 Fabricio Tamusiunas
Aplicações educacionais em rede
 Learningware
– Ambientes de suporte à educação apoiada em
tecnologia de informação e comunicação
– Colaboração interativa
• videoconferência
• compartilhamento de dados
• compartilhamento de aplicações
Videoconferência
 Dificuldades para implantar uma infra-estrutura
– Conviver com problemas
• operacionais
• ambientais
• falta de QoS
 Videoconferência na Internet
Experiências anteriores
 CuSeeMe

– versão grátis limitada

– servidor e cliente comercial estáveis
 Mbone

– configuração túneis
– protocolos multicast
 H.323

 SIP
Recursos utilizados
 MCU
– Meeting Point da CuSeeMe
– CISCO 3510
 Cliente
– Netmeeting
– CuSeeMePro (versão > 4.1)
– Polycom
H.323 componentes
 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).
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
Controle H.245
 Controle H.245 : esta função provê ao terminal a habilidade de
enviar mensagens para negociar o uso e a capacidade do
canal.
 Mensagens H.245 encontram-se dentro de quatro categorias:
– Request
– Response
– Command
– Indication.
RAS
 Controle RAS (Registration, Admission and Status):
provê controle de mensagens de sinalização para
– registro,
– admissão,
– troca de banda,
– pedido de informação sobre a situação atual e
– desvinculação com o gatekeeper.
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

12
Instalação do MCU

 Fatores na rede que impactam

 Otimização da topologia para videoconferência
– Conexão direta ao switch
– Fast Ethernet
– Ponto de maior conectividade da rede
 H.323 Pilha de protocolos

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
14
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
– Negociação de largura de banda e; -Usar ARQ pré concedido
– Desligamento do GK. -Designar prioridades
(QoS), para usuários
prioritários
 H.225.0 – Usado para:
– Estabelecer e encerrar conexões Deve ser garantido Delay
mínimo para o
estabelecimento da
 H.245.0 – Usado para: chamada.
– Estabelecer a troca de capacidades
Deve ser garantido Delay
mínimo para o
estabelecimento da
chamada.
Estabelecimento de conexão
 Captura de tráfego
 Arquivos provenientes de uma captura feita pelo Observer, na
videoconferência entre dois computadores utilizando
Netmeeting, capturando apenas pacotes dos protocolos H.323
e T.120
– Videoconferência simples CAP TXT
– Videoconferência com compartilhamento de aplicação CAP
TXT
– Videoconferência com quadro branco CAP TXT
– Videoconferência com chat CAP TXT
– Videoconferência com transferência de arquivo CAP TXT
 Medições realizadas
 Comunicações T.120 entre Terminais (Netmeeting), iniciam antes da abertura de
canais lógicos.
 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;
 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
 Resultados preliminares
Dificuldades encontradas na captura e análise do tráfego:
–A captura não apresenta o horário em que o pacote foi capturado.
–Analisador de protocolos on-line para descobrir exatamente o que
está acontecendo;
–A documentação de alguns produtos ainda é carente de
informações detalhadas e precisas.
Fatores críticos de sucesso
 Capacidade das estações cliente e da conexão
 Processos consumidores de CPU e de banda:
– compartilhamento de aplicações
– otimização na videoconferência
• slides
• ambiente
– vídeo
– som
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 - pilha de protocolos

T.126T.123
T.122 DescriçãoPilhas
T.127 dodeT.130
protocolos
Serviço de para aplicações
de teleconferências
T.124 Controle Comunicação genérico: audiográficas
Multiponto e
(MCS): descreve

Overhead Proj
de conferência

Reservations
App Sharing
File Transfer
Whiteboard

A/V Control
Documents

Switching
deaudiovisuais:
os serviços multipontoespecifica protocolos
disponíveis para de

Photos
define as reservas suporte de protocolos
transporte
fabricantes.
de aplicação e serviços de controleparade vários tipos de redes
T.125para
conferência básicos : Especificação
conferências de protocolo de serviço
multiponto de comunicação
Application multiponto: especifica o
TERMINAL

Protocols
protocolo
T.126 de transmissão
- Still Image, T.127 - File de dados para serviços
Transfer
T.130 - A/V Control, T.SHARE, T.RES
multiponto
T.124 - Generic Conference Control
T.135: Sistema
T.128: Protocolo
T.126 de deuso parapara
reserva
compartilhamento
Protocolo dede transações
tratamentoaplicações
e anotação de
T.122 / T.125 - Multipoint Comm. Service
MCU

commultiponto:
uma imagem definenão
conferência como participantes,
T.120:
animada: define em
define uma
os compartilhamento
protocolos
conferência T.120 podem T.123 compartilhar
- Transport aplicações
Stacks
reservados depara
dadosconferência em um
colaborativamente, ambiente
incluindo quadro
locais, de forma que participantes Voice/ de outra conferência
T.120, tipicamente
possambranco,
ISDN entre uma
compartilhamento
ver a imagem POTSda aplicação aplicação cliente
de imagem,
LAN
Data compartilhada, e eapresen-
ATM
umusar
sistema
o mousede eagenda
tação de imagem
o teclado que
parareserva
gráfica
controlareunidades
intercâmbiode de
essa aplicação
controle
como se de recursos
ela
imagem em multiponto
estivesse rodando
conferência (MCUs
localmente. ou "bridges"). .
multiponto
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
 O que caracteriza qualidade no ponto de vista do
usuário ?
 Medidas usuais
– Bandwidth - Representa a velocidade do meio
– Delay - Atraso médio
– Jitter - Variação do delay
QoS
 Aplicações podem ser classificadas como:
– Elásticas
– Tolerantes de Tempo Real
– Intolerantes de Tempo Real.
MOS
 Perceptual Speech Quality Measurement (PSQM)
 ITU P800
 Mean Opinion Scores (MOS)
 MOS - Mean Opinion Scores
 1 1Ruim:
 ininteligível,
Ruim: ininteligível, o usuárioonão
usuário
entende anão entende
mensagem a
decodificada. Possui
interrupções horríveis devido às degradações

mensagem decodificada. Possui interrupções
2 Pobre: o sinal possui interrupções devido às degradações e o usuário tem que
horríveis devido
fazer um esforço às degradações
considerável para entender alguns trechos.
  2 3Pobre:
Moderado: o asinal possui
qualidade da voz interrupções devido
é ruim, o usuário sente às com as
incomodado
degradações
degradações, porém e onãousuário tem que
tem interrupções fazer
e ainda umentender
consegue esforço a
mensagem. (requer esforço moderado)

considerável para entender alguns trechos.
4 Bom: a voz é agradável de se ouvir, ou seja, percebe degradações mas não
 3 Moderado: a qualidade
se incomoda com da mínimas.
elas, pois são voz é ruim, o usuário
(nenhum sente é
esforço apreciável
incomodado
requerido) com as degrada-ções, porém não tem interrupções e
ainda consegue
5 Excelente: entender
o usuário a mensagem.
não consegue (requer
diferenciar o trechoesforço
original com o
4 corrompido,
Bom: a voz
 moderado). é agradável
ou seja, não percebededegradações
se ouvir, ou no seja, percebeesforço é
sinal. (nenhum
requerido)
degradações mas não se incomoda com elas, pois são
5 Excelente:
 mínimas. o usuário
(nenhum esforçonãoapreciável
consegueédiferenciar
requerido)o trecho
original com o corrompido, ou seja, não percebe degradações
no sinal. (nenhum esforço é requerido)
Testes e experiências realizadas
 UFRGS
– Ponto a ponto
– Multiponto
– VoIP
 Rede TCHÊ
– Videoconferências
 RNP
– COMDEX 2001
– GRID
UFRGS - ESPIE e GTRH
 Multiponto
 MCU
 Pontos remotos
– congestionamento
– capacidade PC
 Muitos problemas
Monitoração
 MRTG
 RRDTool
 Ethload (real time)
 Lan analyzer
 Observer
 Log MCU
Conexão SP-POA
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 2 vezes 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ê
 Servico de
Definido o serviço CACHE (Assured alta prioridade
Forwarding)
e comque
para tráfego controlado, ou seja, necessidade
faz uso dade
baixo delay (High Video):
estrutura de caches existente.

•marcacao
Reserva de banda de 19% ou 300Kbps de pacotes,
para o
serviço HVIDEO •política de QoS e
•reserva de banda
 Reserva de 15% da banda para o serviço CACHE
RNP/GTRH
COMDEX
COMDEX

 Solução: Serviços Diferenciados com reserva de

Banda (DiffServ + RSVP)
 Necessidade de padronização em enlaces PPP e
redes ATM
 Meliá->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é 3vezes 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.
QoS
 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).
Coordenador local de apoio a
videoconferência
 Uma especificação de conhecimentos necessário
para a pessoa que assumir a função de coordenador
local de apoio à videoconferência foi especificado
pelo grupo Internet Commons
 Processo de certificação
Internet2 Commons Site
Coordinator Certification
 Ability and willingness to support your entire
campus; not just your individual unit.
 Knowledge of your campus network and who to call
to discuss network problems.
 Ability to train campus users, using materials from a
variety of sources.
 Ability to work supportively with beginner users and
to take ownership of problems until they are
resolved.
Internet2 Commons Site
Coordinator Certification
 Understanding of environmental factors and how
to deal with them:
 lighting
 visual clutter
 room acoustics
 extraneous noise
 camera and microphone placement
Internet2 Commons Site
Coordinator Certification
 Understanding of audio basics
 Understanding of video basics
 Understanding of videoconferencing basics:
 Understanding of data collaboration, and its
relationship to videoconferencing, and the
commonly used methods.
 Understanding of expected quality and
performance, when using Internet2
Internet2 Commons Site
Coordinator Certification
 Understanding of common applications of
videoconferencing.
 Understanding of the ViDe Cookbook.
 Understanding and experience with PC-based
systems
 Understanding and experience with room-based and
standalone systems.
 Understanding of video address books, in PC and
standalone systems, and how they relate to
Gatekeeper aliases.
Internet2 Commons Site
Coordinator Certification
 Understanding of how to arrange and conduct a
multipoint videoconference.
 Understanding of the main H.323 protocols and sub-
protocols and their various versions.
 Understanding of what types and brands of
equipment work well and which do not.
 How to set up and debug and operate the most
common brands:
Internet2 Commons Site
Coordinator Certification
 Understanding of typical equipment costs and where
to buy it.
 How to debug problems
 Videoconferencing etiquete
 Videoconferencing etiquette
 H.320 vs. H.323
Internet2 Commons Site
Coordinator Certification
 The Internet2 Commons Mission and Goals
 Where to go for higher-level help
 User directories
Planejamento geral da
atividade proposta
 A atividade ora proposta consiste em projetar e
implementar uma atividade de capacitação de
recursos humanos para o uso de
videoconferência via Internet alinhada com a
proposta que está sendo desenvolvida no âmbito
da Internet2 (Internet2 Commons).
Planejamento geral da
atividade proposta
 A atividade visa criar condições para que usuários da
RNP que tenham potencial interesse e necessidade
de utilização de videoconferência possam
desenvolver suas atividades com menor grau de
dificuldade.

 Esta atividade visa ampliar e potencializar os

resultados do projeto piloto de videoconferência
iniciado pela RNP em 2001.
Diagnóstico e Alternativas
 Esta atividade consiste na realização de estudo sobre
soluções tecnológicas e no levantamento de cenários para
o desenvolvimento da atividade de videoconferência.
 Documento que funcionará como termo de referência para
os trabalhos incorporando
– considerações de produtos (hardware e software
utilizados),
– conhecimentos teóricos que explicam o funcionamento
destes produtos (protocolos, noções de comunicação
de dados etc...) ,
– objetivos e formas de utilização de videoconferência,
pré-requisitos,
– aplicações,
– etc
Atividades
 A1 - Projeto e elaboração do Documento de Diagnóstico e
Alternativas
 A2 - Relatório parcial para apresentação e discussão do tema
no Workshop RNP2.
 A3 - Desenvolvimento do material instrucional para o programa
de certificação de coordenador local de videoconferência
consistindo de:
 Textos de referência
 Material para apresentações: slides, animações, material
multimidia interativo
 A4 - Capacitação de instrutores para replicação do programa de
certificação em diversos locais do país.
 A5 - Relatório final
Resultados preliminares
 Relatório
– Http://penta3.ufrgs.br/RNP/
 Vídeo do research channel legendado
– sincronização usando SMIL
– http://www.pgie.ufrgs.br/videoconferência
Próximos resultados
 Material instrucional de apoio para o plano de
capacitação de recursos humanos baseado no
documento de referência
 Exemplos
– Animações
• Hub, switch
• Unicast, multicast
– WBT Videoconferência - Guia prático
• http://www.pgie.ufrgs.br/videoconferencia