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.