Upload
internet
View
110
Download
0
Embed Size (px)
Citation preview
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.323Escopo da norma H.323
Eqto de entrada de vídeoCâmera de vídeo, vídeo
cassete)
Aplicações de dados (T.120, etc)
Eqto de entrada de áudio(microfone, vídeo cassete)
Controle do sistema
CODEC de áudioG.711, G.722,
G.723, G.728, G.729
CODEC de vídeoH.261, H.263
Receive
Path
Delay
Camada
H.225.0
Interface
LAN
Controle do sistema
Controle H.245
Controle dechamadaH.225.0
Controle RASH.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
19
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
20
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
21
H.323 Protocol Stack
TCP UDP
IP
H.225. 0 / Q931
Control Data
T.120
H.245
G.7xx H.26x
RTP
RTCP
Gatekeeper
Reg,Adm,Status
H.225. 0 / RAS
Audio Video A/V Cntl Control
H.235(Opcional p/Criptografia)
22
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
23
Call Connection
PictureTel
PictureTel
PictureTel
(4) SETUP (Create)
Bill Bob
GK
(5) ARQMay I answer?
(6) ACFYes
(7) ALERTING
(8) CONNECT (User answers)
24
Mensagem contém o endereçode transporte para estabelecimento da chamada
Call Connection – localização e registro com o gatekeeper
PictureTel
PictureTel
PictureTel
Bill Bob
GK
(1) GRQ (multicast)Quem é meu GK?
(2) GCFEu posso ser seu GK.
1) O endereço IP do GK podeser configurado manualmen-te ou ser descoberto automaticamente
Descoberta automática
Porta 1718 (multicast) grupo 224.0.1.41Porta 1719 (unicast)
(4) RCFVocê está registrado comigo.
(3) RRQ Registro com o GK
25
Bill invites Ross
PictureTel
PictureTel
PictureTel
Ross
GK
(10) ARQInviteRoss (11) ACF
Resolved Ross’sIP Address
(12) SETUP (Invite)
(13) ARQMay IJoin?
(14) ACFYes
(15) ALERTING(16) CONNECT
(17) H.245 CONNECTION
26
Call Connection – Estabelecimento da Chamada
PictureTel
PictureTel
PictureTel
Bill Bob
GK(8) ARQMay IJoin?
(9) ACF Yes
(7) SETUP (Invite)
(5) ARQCan I make a call?
(10) ALERTING
(12) H.245 CONNECTION
(6) ACFYes – Resolved Biil´s IP address
(11) ALERTING
QoS nos canais RAS, H.225.0 e H.245
RAS – Usado para:– Localização e registro com GK;– Negociação de largura de banda, e;– Desligamento do GK.
H.225.0 – Usado para: – Estabelecer e encerrar conexões
H.245.0 – Usado para: – Estabelecer a troca de capacidades
Caso qualquer uma destas operações falhar o Sist. Pode ficar indisponível .
Soluções possíveis:-Usar unicast com TTL baixo-Usar ARQ pré concedido-Designar prioridades (QoS), para usuários prioritários
Deve ser garantido Delay mínimo para o
estabelecimento da chamada.
Deve ser garantido Delay 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 closedEvent> 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 downEvent> Mon Nov 26 17:18:55 2001 Pkts in 3324 Pkts Event> client Alexei Korb - T.120 session closed due to insufficient bandwidthEvent> 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 bandwidthEvent> 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 closedEvent> 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 downEvent> Mon Nov 26 17:18:55 2001 Pkts in 3324 Pkts Event> client Alexei Korb - T.120 session closed due to insufficient bandwidthEvent> 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 bandwidthEvent> Mon Nov 26 17:21:57 2001 Pkts in 7114 Event> Mon Nov 26 17:22:58 2001 Pkts in 8182
Medições realizadasProblema:
–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 T.120
Whiteboard
impressora
Reprojetor
T.120
Câmaradocumento
s
Audio+ Compartilhamento de
Aplicações
PictureTel
PictureTel
Desktop Video+ Whiteboard+ Compart.
Aplic. PictureTel PictureTel PictureTel
LANDDD
RDSI RDSI
T.120 protocol stackT.120 protocol stack
Whi
tebo
ard
Ove
rhea
d P
roj
Pho
tos
Doc
umen
ts
File
Tra
nsfe
r
App
Sha
ring
Res
erva
tions
A/V
Con
trol
Application Protocols T.126 - Still Image, T.127 - File TransferT.130 - A/V Control, T.SHARE, T.RES
T.124 - Generic Conference Control
T.123 - Transport Stacks
ISDN POTSVoice/Data
LAN ATM
MC
U T.122 / T.125 - Multipoint Comm. Service
T.126 T.127
TE
RM
INA
L
Sw
itchi
ng
T.130
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
RNPCOMDEX
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.