Redes Multimídia -...

Redes Multimídia

transparências baseadas no livro“Computer Networking: A Top-Down Approach Featuring the Internet”

James Kurose e Keith Rosshttp://occawlonline.pearsoned.com/bookbind/pubbooks/kurose-ross1/

Capítulo 6: Redes Multimídia

Objetivos do Capítulo:❒ entender os requisitos de

serviço para redes com multimídia

❍ atraso❍ taxa de transmissão❍ perda

❒ aprender como aproveitar o máximo do serviço de melhor esforço da Internet

❒ Aprender como a Internet poderá evoluir para um melhor desempenho dos serviços multimídia

Resumo do capítulo:❒ aplicações de rede com

multimídia ❒ aúdio e vídeo de tempo contínuo

armazenados ❍ RTSP

❒ aplicações interativas de tempo-real

❍ Exemplo: telefonia na Internet❒ RTP❒ H.323 e SIP❒ além do melhor esforço

❍ programando e verificando❍ serviços integrados ❍ serviços diferenciados

Multimídia em Redes Características Fundamentais:❒ Tipicamente sensíveis ao

atraso.❒ Mas tolerante a perdas:

perdas esparsas causam pequenas falhas que podem passas desapercebidas.

❒ Antítese de dados (programas , informações bancárias, etc.), que não toleram falhas mas aceitam atrasos sem problemas.

❒ Multimídia também é chamada de “mídia de tempo contínuo”

Classes de aplicações MM:❒ Aúdio e vídeo de tempo

contínuo armazenados ❒ Audío e vídeo de tempo

contínuo ao vivo❒ Vídeo interativo em tempo-

real

Multimídia em redes (2)

Aplicações MM com aúdio e vídeo armazenadosClientes solicitam arquivos com aúdio e vídeo de servidores, recebem a informação pela rede e a apresentam❒ Interativo: o usuário pode controlar a operação (similar a um VCR: pause, resume, fastforward, rewind, etc.)❒ Atraso: a partir do pedido do cliente até o início da apresentação pode ser de 1 a 10 segundos

Tempo-real unidirecional:❒ similar à TV convencional, mas a

transferência de informação é feita pela Internet

❒ Não interativo, apenas escutar e ver

Tempo-Real Interativo:❒ Conferência de aúdio ou de vídeo❒ Mais exigente nos requisitos de

atraso que o tempo real unidirecional por causa da necessidade de interatividade em tempo real

❒ Vídeo: < 150 ms aceitável ❒ Aúdio: < 150 ms bom, <400 ms

aceitável

Multimídia em redes (3): desafios

❒ Arquitetura TCP/UDP/IP fornece melhor esforço, não garantias sobre o atraso ou sobre a variação de atraso.

❍ Aplicações de tempo contínuo com atrasos inicias de 5-10 segundos são comuns hoje me dia, mas o desempenho deteriora se os enlaces estão congestionados (transoceânicos)

❍ Aplicações Interativas e,m tempo real têm requisitos rígidos para atraso de pacotes e variação de atraso (jitter).

❍ Jitter é a variabilidade do atraso de pacotes dentro do mesmo feixe de pacotes.

❒ Projeto de aplicações multimídia seria fácil se houvesse várias classes de serviço.

❍ Mas na Internet pública todos os pacotes recebem igual tratamento.

❍ Pacotes contendo aúdio e vídelo interativo de tempo real permanecem nas filas, como todos os outros.

❒ Esforços vêm sendo desenvolvidos para prover serviços diferenciados.

Multimídia em redes (4): aproveitando ao máximo o “melhor esforço”

Para reduzir o impacto do serviço de melhor esforço da Internet, nós podemos:

❒ Usar UDP para evitar o TCP e sua fase de partida lenta…

❒ Armazenar o conteúdo no cliente e controlar a apresentação para remediar o jiter

❒ Podemos acrescentar marcas de tempo nos pacotes para que o receptor saiba quando reproduzí-los.

❒ Adaptar o nível de compressão à taxa de transmissão disponível

❒ Nós podemos transmitir pacotes redundantes para atenuar os efeitos das perdas de pacotes.

Nós discutiremos todos esses “truques”.

Como a Internet deveria evoluir para suportar melhor as aplicações multimídia?

Filosofia de serviços Integrados:❒ Mudar os protocolos da

Internet de forma que as aplicações possam reservar uma banda de transmissão fim-a-fim

❍ Necessita de um novo protocolo que reserva banda de transmissão

❍ Deve modificar as regras de escalonamento nos roteadores para poder honrar às reservas

❍ Aplicação deve fornecer à rede uma descrição do seu tráfego e deve posteriormente respeitar esta descrição.

❒ Exige um novo e complexo software nos hosts e nos roteadores

Filosofia de serviços Diferenciados Exige menos mudanças na infra-estrutura da Internet, embora forneça serviços de primeira e de segunda classe.❒Datagramas são marcados.❒Usuários pagam mais para enviar e receber pacotes de primeira classe.❒ISPs pagam mais aos provedores debackbone para enviar e receber pacotes de primeira classe.

Filosofia Laissez-faire ❒ Não há reservas, nem

marcações de datagramas ❒ Quando a demanda aumenta,

mais banda de transmissão deve ser provida

❒ Coloque armazenadores de conteúdo nas bordas da rede:

❍ ISPs e provedores debackbone acrescentamcaches

❍ Provedores de conteúdo armazenam conteúdo em nós CDN

❍ P2P: escolhe o parceiro mais próximo com o conteúdo desejado

Redes privadas virtuais (VPNs)❒ Reserva blocos permanentes

de banda de transmissão para empresas.

❒ Roteadores distinguem o tráfego de cada VPN usando endereços IP

❒ Roteadores usam esquemas de escalonamento especiais para fornecerem a banda de transmissão reservada.

Como a Internet deveria evoluir para suportar melhor as aplicações multimídia?

Aúdio e Vídeo Armazenados Mídia de tempo contínuo armazenada:❒Arquivos de Aúdio e de Vídeo são armazenados em servidores ❒Usuários solicitam os arquivos de aúdio e de vídeo por demanda.❒Aúdio/vídeo são aprsentandos, digamos, 10 s após o pedido.❒Interatividade (pausa, deslocamento da apresentação) é permitido.

Transdutor de Mídia (player):❍ remove jitter❍ descomprime❍ correção de erros ❍ interface gráfica de

usuário com controles para interatividade

❒ Plug-ins podem ser usados para embutir o transdutor de mídia na janela de umbrowser.

Informações de tempo contínuo em servidores Web (1)

❒ Os arquivos de aúdio e de vídeo são armazenados em servidores Web

abordagem ingênua❒ browser pede o arquivo com

uma mensagem HTTP do tipo pedido

❒ Servidor Web envia o arquivo na mensagem HTTP do tipo resposta

❒ O cabeçalho “content-type” indica uma codificação apropriada para aúdio e vídeo

❒ browser dispara o transdutor de mídia e passa o arquivo para ele

❒ transdutor de mídia apresenta o arquivo

• Maior problema: o transdutorde mídia interage com o servidorWEB através do Web browser que atua como intermediário.

cliente servidor

Alternativa: estabelecer conexão entre o servidor e o transdutor

❒ browser Web solicita e recebe um meta arquivo (um arquivo descrevendo o objeto) ao invés de receber o próprio arquivo;

❒ O cabeçalho “Content-type” indica uma específica aplicação de aúdio e vídeo

❒ Browser dispare o transdutor de mídia e passa o meta arquivo para ele

❒ Transdutor estabelece uma conexão TCP com o servidor e envia a ele a mensagem HTTP do tipo pedido.

Algumas preocupações:❒ O transdutor de mídia se

comunica usando HTTP, que não foi projetado mparasuportar comandos de controle de apesentação

❒ Pode desejar enviar o aúdioe o vídeo sobre UDP

Informações de tempo contínuo em servidores Web (2)

(1) pedido/resposta HTTPpor um meta arquivo

(3) arquivo solicitado é enviadousando o HTTP

(2) meta arquivo

transdutor de mídia

Obtendo o vídeo de um servidor dedicado

❒ Esta arquitetura permite o uso de outros protocolos (além do HTTP) entre o servidor e o transdutor de mídia

❒ Pode também usar UDP ao invés do TCP

(1) HTTP pedido/respostapara o arquivo descritor

da apresentação

(2) arquivodescritor

(3) arquivo de aúdioe vídeo pedido e

enviado

cliente servidores

transdutor de mídia

servidorde vídeo

Opções ao utilizar um servidor de vídeo

❒ Enviar a uma taxa constante sobre UDP. Para reduzir os efeitos do jitter, armazenar e exibir com uma atraso entre 1 e 10s. Taxa de transmissão = d, igual à taxa de codificação. Taxa de enchimento x(t) é igual a d, ecxeto quando há perdas.

❒ Use TCP, e envie na máxima taxa possível sobre TCP; TCP retransmite quando um erro é encontrado; x(t) agora flutua, e pode tornar-se muito maior que d. Decodificador deve usar um buffer muito maior para compensar a taxa de entrega do TCP.

buffercliente

área comvídeo

taxa de chegada= x(t)

da rede

taxa de leitura= d

decodificaçãoe apresentação

Real Time Streaming Protocol: RTSP

HTTP❒ Projetistas do HTTP tinham

mídias fixas em mente: HTML, imagens, applets, etc.

❒ HTTP não pretende tratar mídia contínua armazenada (isto é, aúdio, vídeo, apresentações SMIL, etc.)

RTSP: RFC 2326❒ Protocolo de aplicação do

tipo cliente-servidor.❒ Permite ao usuário

controlar apresentações de mídia contínua: voltar ao início, avançar, pausa, continuar, seleção de trilha, etc…

O que ele não faz:❒ não define como o aúdio e o

vídeo é encapsulado para transmissão sobre a rede

❒ não restringe como a mídia contínua é transportada: pode usar UDP ou TCP

❒ não especifica como o receptor armazena o aúdio e o vídeo

RealNetworks❒ Servidor e transdutor usam

RTSP para enviar informações de controle de um para o outro

RTSP: controle for a da bandaFTP usa um canal de controle

“fora-da-banda”:❒ Um arquivo é transferido

sobre um canal.❒ Informação de controle

(mudanças de diretório, remoção de arquivos, trocas de nomes, etc.) é enviada sobre uma conexão TCP separada.

❒ Os canais “dentro-da-banda”e “fora-da-banda”usam diferentes números de portas.

Mensagens RTSP també são enviadas “for a-da-banda”:

❒ As mensagens de controle RTSP usam diferentes números de portas em relação ao fluxo de dados de mídia contínua, e, portanto, são enviados“fora-da-banda”.

❒ O fluxo de dados de mídia contínua cuja estrutura de pacotes não é definida pelo RTSP, é considerada “dentro-da-banda”.

❒ Se as mensagens do RTSP devessem usar os mesmos números de portas do fluxo de mídia contínua, então as mensagens RTSP seriam consideradas como “intercaladas” com o fluxo de mídia contínua.

Iniciação do RTSP e controles de entrega❒ Cliente obtém uma descrição da

apresentação multimídia, que pode consistir de vários fluxos de dados.

❒ O browser chama o transdutor de mídia (aplicação auxiliar) com base no tipo de conteúdo da descrição da apresentação.

❒ A descrição da apresentação inclui referências aos fluxos de mídia usando o método rtsp://

❒ Transdutor envia o comando RTSP SETUP; servidor envia a resposta RTSP SETUP.

❒ Transdutor envia o comando RTSP PLAY; servidor envia a resposta RTSP PLAY.

❒ O servidor de mídia descarrega o fluxo de mídia.

❒ Transdutor envia o comando RTSP PAUSE; o servidor envia a resposta RTSP PAUSE.

❒ Transdutor envia o comando RTSP TEARDOWN; servidor envia a resposta RTSP TEARDOWN.

HTTP GET

SETUP

PLAY

media stream

PAUSE

TEARDOWN

mediaplayer

Webserver

mediaserver

Webbrowser

client server

presentation desc.

Transdutorde mídia

Servidorde mídia

cliente servidor

descr. apresent.

fluxo de mídia

Exemplo de Meta-arquivo

<title>Twister</title> <session>

<group language=en lipsync> <switch>

<track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi">

<track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi">

</switch> <track type="video/jpeg"

src="rtsp://video.example.com/twister/video"> </group>

</session>

Sessão RTSP

❒ Cada sessão RTSP tem um identificador de sessão, que é escolhido pelo servidor.

❒ O cliente inicia a sessão com o comando SETUP, e o servidor responde ao comando com um identificador.

❒ O cliente repete o identificador de sessão em cada comando, até que o cliente encera a sessão com o comando TEARDOWN.

❒ O número de porta do RTSP é 554.

❒ RTSP pode ser usado sobre UDP ou TCP. Cada mensagem RTSP pode ser enviada numa conexão TCP separada.

RTSP: exemplo de mensagens C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0

Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231

S: 200 3 OK

RTSP: cache de dados

❒ O cache de mensagens de resposta RTSP faz pouco sentido.

❒ Mas é desejável armazenar fluxos de mídia contínua próximos ao cliente.

❒ Muito do controle de cache do HTTP/1.1 foi adotado pelo RTSP.

❍ Cabeçalhos e controle decache podem ser acrescentados às mensagens RTSP SETUP, sejam comandos ou respostas:

• If-modified-since: , Expires: , Via: , Cache-Control:

❒ O servidor de cache pode manter somente segmentos de um dado fluxo de mídia.

❍ O servidor de cache pode começar a servir um cliente com dados do seu cache local, e então conectar o servidor para obter material complementar, se possível sem introduzir pausas indevidas no cliente.

❒ Quando o servidor original está enviando um fluxo de dados de mídia contínua para um cliente e este fluxo passa por um servidor de cache, o servidor pode usar o TCP para obter os dados; mas o servidor intermediário ainda envia as mensagens de controle RSTP para o servidor original.

Aplicações interativas em tempo-real

❒ telefone PC-a-PC❒ PC-a-telefone

❍ Dialpad❍ Net2phone

❒ videoconferência❒ Webcams

❒ Vamos agora examinar um produto do tipo telefone PC-a-PC da Internet em detalhes

Telefonia Internet sobre melhor-esforço (1)

Melhor esforço❒ atraso de pacotes, perdas e

variação de atraso (jitter)Exemplo de telefone Internet❒ agora vamos examinar como

atrasos de pacotes, perdas e jitter são muitas vezes tratados num exemplo de telefonia IP.

❒ As aplicações de telefonia na Internet geram pacotes durante momentos de atividade da voz

❒ taxa de bits é 64 kbps nos intervalos de atividade

❒ durante os intervalos de atividade a aplicação produz um bloco de 160 bytes a cada 20 ms (8 kbytes/s * 20 ms)

❒ cabeçalho é acrescentado ao bloco; então bloco mais cabeçalho sáo encapsulados num pacote UDP e enviados

❒ alguns pacotes podem ser perdidos e o atraso de pacote irá flutuar.

❒ receptor deve determinar quando reproduzir um bloco e determinar o que fazer com um bloco faltante

Telefonia Internet (2)perda de pacotes❒ O segmento UDP é

encapsulado num datagrama IP❒ datagrama pode ser

descartado por falta de espaço num roteador

❒ TCP pode eliminar perdas, mas❍ retransmissões aumentam o

atraso❍ O controle de congestio-

namento do TCP limita a taxa de transmissão

❒ Pacotes redundantes podem ajudar

atraso fim-a-fimacúmulo dos atrasos de trans-

missão, propagação, proces-samento e atrasos de filas

❒ mais que 400 ms de atraso fim-a-fim compromete a interatividade; quanto menor o atraso melhor

variação de atraso❒ considere dois pacotes

consecutivos num intervalo de atividade

❒ espaçamento inicial é de 20 ms, mas o espaçamento no receptor pode ser maior ou menor que 20 ms

removendo o jitter❒ número de seqüência❒ marcas de tempo❒ atrasando a reprodução

Telefonia Internet (3): atraso de reprodução fixo

❒ Receptor tenta reproduzir cada bloco exatamente q ms depois que o bloco é gerado.

❍ Se o bloco tem marca de tempo t, receptor usa o bloco no instante t+q .

❍ Se o bloco chega após o instante t+q, receptor o descarta.

❒ Números de seqüência não são necessários.

❒ Estratégia permite pacotes pedidos.

❒ Escolha do valor de q:❍ q grande: menos perda de

pacotes❍ q pequeno: melhor controle

da interatividade

Telefonia Internet (4): atraso de reprodução fixo

❒ Transmissor gera pacotes a cada 20 ms durante os intervalos de atividade.

❒ Primeiro pacote é recebido no instante r❒ Primeira programação de reprodução: começa em p❒ Segunda programação de reprodução: começa em p’

packets

time

packetsgenerated

packetsreceived

loss

r

p p'

playout schedulep - r

playout schedulep' - r

pacotesgerados

pacotesrecebidos

perda

progr. reproduçãop - r

progr. reproduçãop’ - r

tempo

pacotes

Atraso de reprodução adaptativo (1)

pacote ésimo- oreceber após rede na atraso do estimativapacote ésimo- o para rede da atraso

receptor no oreproduzid é pacote o qual no instantereceptor pelo recebido é pacote o qual no instante

pacote ésimo do tempode marca

iditripir

it

i

ii

i

i

i

==−

==

−=

• Estima o atraso da rede e ajusta o atraso de reprodução no início de cada intervalo de atividade.

• Intervalos de silêncio são aumentados e diminuídos.

• Blocos ainda são gerados a cada 20 ms nos intervalos de atividade.

Estimativa dinâmica do atraso médio no reeptor:

)()1( 1 iiii trudud −+−= −

onde u é uma constante fixa (ex., u = 0,01).

É também usual estimar a variância média do atraso, vi :

||)1( 1 iiiii dtruvuv −−+−= −

As estimativas de di e vi são calculadas para cada pacote recebido, embora elas sejam usadas apenas no início de um intervalo de atividade.

Para o primeiro pacotes de um intervalo de atividade, o instante de reprodução é:

iiii Kvdtp ++=

onde K é uma constante positiva. Para este mesmo pacote, o atraso dereprodução é:

iii tpq −=

Para o pacote j no mesmo intervalo de atividade, o pacote deve serreproduzido em:

ijj qtp +=


Como saber se um pacote é o primeiro de um intervalo de atividade:❒ Se nunca houvesse perdas o receptor poderia simplesmente olhar

nas marcas de tempo sucessivas.❍ Se a diferença de marcas de tempo sucessivas for maior

que 20 ms, então temos o início de um intervalo de atividade.

❒ Mas porque as perdas são possíveis, o receptor deve olhar tanto as marcas de tempo como os números de seqüência dos pacotes.

❍ Se a diferença de marcas de tempo sucessivas for maior que 20 ms e não há pulos nos números de seqüência então tem-se o início de um intervalo de atividade.


Recuperação de perdas de pacotes (1)

❒ Perdas: pacote nunca chega ou chega depois do seu tempo de reprodução programado

correção de erro de envio (FEC): esquema simples

❒ para cada grupo de n blocos cria um bloco redundante realizando uma operação OU exclusivo entre os n blocos originais

❒ envia os n+1 blocos, aumentando a banda passante por um fator de 1/n.

❒ pode reconstruir os n blocos originais se houver no máximo um bloco perdido nos n+1 blocos enviados

❒ Atraso de reprodução precisa ser definido para receber todos os n+1 pacotes

❒ Compromisso: ❍ aumentar n, menor

disperdício de banda❍ aumentar n, maior atraso

de reprodução❍ aumentar n, maior a

probabilidade que dois ou mais blocos sejam perdidos

2o, esquema FEC• enviar um fluxo demenor qualidade como“carona”• envia fluxo de aúdiode menor resolução comoa informação redundante• por exemplo, um fluxoPCM nominal a 64 kbpse um fluxo GSM redun-dante a 13 kbps.• Transmissor cria pacote tomando o blocon do fluxo nominal eanexando a ele o bloco(n-1) do fluxo redun-dante

• Sempre que ocorre perda não-consecutiva, o receptor pode esconder a perda.• Apenas dois pacotes precisam ser recebidos antesdo início da reprodução• Pode também anexar os blocos (n-1) e (n-2) do fluxode baixa qualidade


Fluxo original

Redundância

Perda de Pacote

Fluxo reconstruído

Intercalação❒ blocos são quebrados em

unidades menores❒ por exemplo, 4 blocos de

5 ms cada❒ intercalar os blocos como

mostrado no diagrama❒ pacote agora contém

unidades menores de diferentes blocos ❒ Remontar os blocos no

receptor❒ Se o pacote é perdido,

ainda resta mais de cada bloco

Recuperação de perdas de pacotes (3)Fluxo original

Fluxo intercalado

Perda de pacote

Fluxo reconstruído

Recuperação pelo receptor de fluxos de aúdio danificados

❒ produzir uma substituição para um pacote perdido que seja similar ao pacote original

❒ pode produzir bons resultados para baixas taxas de perdas e pacotes pequenos (4-40 ms)

❒ estratégia mais simples: repetiçãon

❒ estratégia mais complexa: interpolação


Real-Time Protocol (RTP)❒ RTP especifica uma

estrutura de pacotes que transportam dados de aúdio e vídeo: RFC 1889.

❒ pacote RTP oferece ❍ identificação do tipo de

carga❍ numeração da seqüência de

pacotes❍ marcas de tempo

❒ RTP roda nos sistemas terminais.

❒ os pacotes RTP são encapsulados em segmentos UDP

❒ Interoperabilidade: se duas aplicações de telefonia IP usam RTP, então elas podem ser capazes de trabalhar juntas

RTP roda em cima do UDP

As bibliotecas do RTP fornecem uma interface de camada de transporte que extendem o UDP:

• número de portas, endereços IP• verificação de erros dentro dos segmentos• identificação do tipo de carga • numeração da seqüência de pacotes• marcas de tempo Aplicação

Enlace

Física

camada detransporte

RTP: Exemplo

❒ Considere enviar 64 kbpsde voz codificada em PCM sobre RTP.

❒ A aplicação reúne dados codificados em blocos, por exemplo, a cada 20 ms = 160 bytes por bloco.

❒ O bloco de aúdio, junto com o cabeçalho RTP forma o pacote RTP, que é encapsulado num segmento UDP.

❒ O cabeçalho RTP indica o tipo de codificação de aúdio em cada pacote, os transmissores podem mudar a codificação durante a conferência. O cabeçalho RTP também contém os números de seqüência e marcas de tempo.

RTP e QoS

❒ RTP não fornece nenhum mecanismo para assegurar a entrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidade de serviço.

❒ O encapsulamento RTP é visto apenas nos sistemas finais --ele não é percebido pelos roteadores intermediários.

❍ Roteadores fornecem o serviço de melhor-esforço tradicional da Internet. Eles não fazem nenhum esforço especial para assegurar que os pacotes RTP cheguem no destino no momento correto.

❒ A fim de fornecer QoSpara uma aplicação, a Internet deve prover um mecanismo, tal como o RSVP, para que a aplicação possa reservar recursos da rede.

Fluxos RTP❒ RTP permite atribuir a

cada fonte (por exemplo, uma câmara ou um microfone) o seu próprio fluxo de pacotes RTP independente.

❍ Por exemplo, para uma videoconferência entre dois participantes, quatro fluxos RTP poderiam ser abertos: dois fluxos para transmitir o aúdio (um em cada direção) e dois fluxos para o vídeo (novamente, um em cada direção).

❒ Contudo, algumas técnicas de codificação populares, incluindo MPEG1 e MPEG2 --reúnem o aúdio e o vídeo num único fluxo durante o processo de codificação. Quando o aúdio e o vídeo são reunidos pelo codificador, então apenas um fluxo RTP é gerado em cada direção.

❒ Para uma sessão multicast do tipo muitos-para-muitos, todos os transmissores e receptores tipicamente enviam seus fluxos RTP na mesma árvore de multicast com o mesmo endereço de multicast.

Cabeçalho RTP

Tipo de Carga (7 bits): Usado para indicar o tipo de codificação queestá sendo usado no momento.

Se um transmissor muda o tipo de codificação durante uma conferência,o transmissor informa o receptor através deste campo de tipo de carga.

•Tipo de carga 0: PCM mu-law, 64 Kbps•Tipo de carga 3, GSM, 13 Kbps•Tipo de carga 7, LPC, 2.4 Kbps•Tipo de carga 26, Motion JPEG•Tipo de carga 31. H.261•Tipo de carga 33, MPEG2 video

Número de Seqüência (16 bits): O número de seqüência é incrementadode um a cada pacote RTP enviado; pode ser usado para detectar perdasde pacotes e para recuperar a seqüência de pacotes.

Tipo de CargaNúmero de Seqüência Marca de tempo

Identificadorsincronismo fonte

campos de miscelânias

Cabeçalho RTP

❒ Campo de marca de tempod (32 bytes). Reflete o instante de amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada do relógio de amostragem no transmissor.

❍ Como exemplo, para aúdio o relógio de marca de tempo incrementa de um a cada intervalo de amostragem (por exemplo, cada 125 us para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio geram blocos contendo 160 amostras codificadas, então a marca de tempo do RTPaumenta de 160 para cada pacote RTP quando a fonte está ativa. Orelógio de marca de tempo continua a aumentar numa taxa constante mesmo quando a fonte está inativa.

❒ campo SSRC (identificador de sincronismo fonte) (32 bits).Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deveter um SSRC distinto.

Cabeçalho RTP (2)

Real-Time Control Protocol (RTCP)

❒ Trabalha em conjunto com o RTP.

❒ Cada participante de uma sessão RTP transmite periodicamente pacotes de controle RTCP para todos os outros participantes. Cada pacote RTCP contém relatórios do transmissor e/ou do receptor que são úteis para a aplicação.

❒ As estatísticas incluem o número de pacotes enviados, número de pacotes perdidos, variação de atraso entre chegadas, etc.

❒ Esta informação de realimentação para a aplicação pode ser usada para controle do desempenho e para fins de diagnóstico.

❍ O transmissor pode mudar suas transmissões com base nestas informações de realimentação.

RTCP - Continuação

- Para uma sessão RTP existe tipicamente um único endereço de multicasttodos os pacotes RTP e RTCP pertencentes à sessão usam este endereço demulticast.

- Os pacotes RTP e RTCP são distintos um dos outros pelo uso de númerosde portas diferentes.

- Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando onúmero de participantes da conferência aumenta.

Pacotes RTCP

Pacotes de relatório do receptor:

❒ fração de pacotes perdidos, último número de seqüência, variância média do atraso entre chegadas.

Pacotes de relatório do transmissor:

❒ SSRC do fluxo RTP, o tempo corrente, o número de pacotes enviados e o número de bytes enviados.

Pacotes de descrição da fonte:

❒ endereço de e-mail do transmissor, o nome do transmissor, o SSRC do fluxo RTP associado. Esses pacotes fornecem um mapeamento entre o SSRC e o nome do usuário ou do host.

Sincronização de Fluxos

❒ RTCP pode ser usado para sincronizar diferentes fluxos de mídia numa sessão RTP.

❒ Considere uma aplicação de videoconferência para a qual cada transmissor gera um fluxo RTP para aúdio e um para vídeo.

❒ As marcas de tempo nestes pacotes são vinculadas aos relógios de amostragem de vídeo e de aúdio, mas não são vinculadas a um relógio de tempo real (isto é, a um relógio de parede).

❒ Cada pacote relatório-do-transmissor RTCP contém para o último pacote gerado no fluxo RTP associado, a marca de tempo do pacote RTP e o instante de tempo real no qual o pacote foi criado. Desta forma o pacote RTCP relatório-do-transmissor associa o relógio de amostragem com o relógio de tempo real.

❒ Receptores podem uar esta associação para sincronizar a reprodução de aúdio e de vídeo.

Controle de Banda do RTCP

❒ O RTCP procura limitar seu tráfego a 5% da banda passante da sessão.

❒ Por exemplo, suponha que existe um transmissor enviando vídeo com uma taxa de 2 Mbps. Então o RTCP procura limitar seu tráfego a 100 Kbps.

❒ O protocolo dá 75% desta taxa, ou 75 kbps, para os receptores; ele dá os 25% restantes da taxa, isto é, 25 kbps, para o transmissor.

❒ Os 75 kbps dedicados aos receptores são divididos de forma igual entre todos os receptores. Assim, se existem R receptores, cada receptor consegue enviar tráfego RTCP a uma taxa de 75/R kbps e o transmissor envia tráfego RTCP a uma taxa de 25 kbps.

❒ Um participante (um transmissor ou receptor) determina o período de transmissão de pacotes RTCP dinamicamente calculando o tamanho médio do pacote (durante toda a sessão) e dividindo o tamanho médio do pacote RTCP pela sua taxa alocada.

H.323❒ Visão geral❒ Terminal H.323❒ Codificação H. 323❒ Gatekeeper❒ Gateway❒ Codecs de Aúdio❒ Codecs de Vídeo

Visão Geral (1)❒ Base para conferência de

aúdio e de vídeo através de redes IP.

❒ Objetiva comunicação de tempo real (ao invés de por demanda)

❒ Recomendação quarda-chuva do ITU-T.

❒ Escopo largo:❍ equipamentos isolados

(ex., telefones Web)❍ aplicações em PCs❍ conferências ponto-a-

ponto e multiponto

❒ A especificação H.323 inclui:❍ Como os equipamentos

terminais fazem e recebem chamadas.

❍ Como os equipamentos terminais negociam codificações comuns de aúdioe vídeo.

❍ Como os blocos de aúdio e vídeo são encapsulados e enviados para a rede.

❍ Como o aúdio e o vídeo são sincronizados entre si.

❍ Como os equipamentos terminais se comunicam com seus respectivos gatekeepers.

❍ Como os telefones IP e os telefones PSTN/ISDN convencionais se comunicam.

❒ Chamadas telefônicas❒ Chamadas de vídeo❒ Conferências❒ Quadros brancos

Todos os terminaissuportando H.323

Internet

Telefone "Ethernet"

MS NetmeetingNetSpeak WebPhone

Visão Geral (2)

H.323 SS7, Inband

Internet PSTNGateway

Gatekeeper

Visão Geral (3)

Terminais H.323 Devem Suportar:

❒ G.711 - padrão do ITU para compressão de voz

❒ RTP - protocolo paraencapsular blocos de dados de mídia em pacotes

❒ H.245 - Protocolo de controle “fora-da-banda” para controlar a mídia entre os terminais H.323.

❒ Q.931 - Um protocolo de sinalização para estabelecer e encerrar chamadas.

❒ RAS(Registration/Admission/Status) protocolo de canal -Protocolo para comunicação com o gatekeeper (se umgatekeeper está presente)

Terminal H.323

Codificação H.323

Aúdio:❒ Terminais H.323 devem

suportar o padrão G.711 para compressão de voz e transmissão a 56/64 kbps.

❒ H.323 está considerando exigir a codificação G.723 = G.723.1, que opera a 5.3/6.3kbps.

❒ Opcionais: G.722, G.728, G.729

Vídeo❒ Capacidade de vídeo para um

terminal H.323 são opcionais.❒ Qualquer terminal H.323 com

capacidade de vídeo deve suportar o formato QCIF H.261 (176x144 pixels).

❒ O suporte a outros esquemas da recomendação H.261 é opcional: CIF, 4CIF e 16CIF.

❒ H.261 é usado com canais de comunicação cuja taxa de transmissão é múltipla de 64kbps.

Gerando fluxo de pacotes de aúdio no H.323

Fonte deAúdio

Codificação:ex., G.711 ou G.723.1

encapsulamentode pacote RTP

portaUDP

Internet ouGatekeeper

Canal de Controle H.245

❒ O fluxo H.323 pode conter múltiplos canais para diferentes tipos de mídia.

❒ Um canal de controle H.245 por sessão H.323.

❒ O canal de controle H.245 é um canal confiável (TCP) que transporta mensagens de controle.

❒ Principais tarefas:❍ Abrir e fechar canais

de mídia.❍ Troca de informações

de capacidades: antes de enviar dados os terminais devem concordar sobre o algoritmo de codificação

❒ Nota: H.245 para conferência multimedia é análogo ao RTSP para mídia contínua armazenada

Fluxos de Informação

TerminalH.323

Canal de Mídia1

Canal de Controlede Mídia

Canal de Mídia2

Canal de Controlede Chamada

H.323GatekeeperCanal RAS

TCP

UDP

TerminalH.323

Canal de sinali-zação de Chamada

Gatekeeper 1/2

• O gatekeeper é opcional. Pode oferecer aos terminais:• translação de endereços para endereços IP• gerenciamento de banda-passante: pode limitar o total de banda-passante consumida pelas conferências de tempo real

• Opcionalmente, as chamadas H.323 podem ser roteadas através do gatekeeper. Conveniente para bilhetagem.• Protocolo RAS (sobre TCP) para comunicação entre terminal-gatekeeper.

term

inai

s H.3

23

Gatekeeper

Roteador

Internet

LAN = “Zona”

RAS

Gatekeeper 2/2

❒ Terminal H.323 deve se registrar com ogatekeeper na sua zona.

❍ Quando a aplicação H.323 é chamada no terminal, o terminal usa o RAS para enviar seu endereço IP e apelido (alias) fornecido pelo usuário ao gatekeeper.

❒ Se o gatekeeper está presente numa zona, cada terminal da zona devecontacta-lo para pedir permissão para realizar uma chamada.

❒ Uma vez que ele obtém a permissão, o terminal pode enviar ao gatekeeper um endereço de e-mail, um nome de referência (alias) ou uma extensão de telefone. Ogatekeeper translada o nome de referência num endereço IP.

❍ Se necessário, ogatekeeper poderá consultar outrosgatekeepers em outras zonas para resolver um endereço IP. O processo varia entre os fornecedores.

Gateway

Term

inai

s H.3

23

Gatekeeper

Router Internet

LAN = “Zona”

RAS

Gateway

PSTN

• Ponte entre a zona IP e as redes PSTN (ou ISDN).• Terminais se comunicam com gateways usando H.245 e Q.931

Codecs de Aúdio

Codec Bandwidth[kbit/s]

MOS Complexidade[MIPS]

Packetização(tamanho)

[ms]

G.711 64 4.5 - -

G.721 (ADPCM) 32 4.4 6.5 -

GSM 13 3.8 4 20

G.729 8 4.1 15 10

G.723 6.4/5.3 4.0 20 30

Qualidade comercial

interlocutor reconhecível

intelegível

problemas de inteleg.

5

4

3

2

1

MOS (Mean Opinion Score)

MOS (Mean Opinion Score)

Codecs de Vídeo

• H.261 (p x 64 kbit/s)– Vídeo sobre ISDN– Resoluções : QCIF, CIF

• H.263 (< 64 kbit/s)– Comunicação de baixa taxa

de bits– Resoluções: SQCIF, QCIF,

CIF,4CIF, 16CIF (128 x 96)(176 x 144)(352 x 288)(704 x 576)(1408 x 1152)

SQCIFQCIF CIF 4CIF16CIF

Oferecendo QOS em Redes IP❒ Os grupos do IETF estão trabalhando em propostas para

fornecer melhor controle de QOS em redes IP, isto é, para superar o serviço de melhor esforço e prover alguma garantia de QOS

❒ Trabalho em Progresso inclui RSVP, Serviços Diferenciados, e Serviços Integrados

❒ Modelo simples para estudos de compartilhamento e de congestão:

Enlace de 1,5 Mbps

Fila de interfacede saída de R1

Princípios para Garantias de QOS

❒ Considere uma aplicação de telefonia a 1Mbps e uma aplicação FTP compartilhando um enlace de 1.5 Mbps.

❍ rajadas de tráfego FTP podem congestionar o roteador e fazer com que pacotes de aúdio sejam perdidos.

❍ deseja-se dar prioridade ao aúdio sobre o FTP❒ PRINCÍPIO 1: Marcação dos pacotes é necessária para o

roteador distingüir entre diferentes classes; assim como novas regras de roteamento para tratar os pacotes de forma diferenciada

Princípios para Garantia de QOS (mais)

❒ Aplicações mal-comportadas (aúdio envia pacotes numa taxa superior a 1Mbps anteriormente assumida);

❒ PRINCÍPIO 2: fornecer proteção (isolação) para uma classe em relação às demais

❒ Exige mecanismos de policiamento para assegurar que as fontes aderem aos seus requisitos de banda passante. Marcação e policiamento precisam ser feitos nas bordas da rede:

marcação de pacotes e policiamento

❒ Alternativa à marcação e policiamento: alocar uma porção da taxa de transmissão a cada fluxo de aplicação; pode produzir um uso ineficiente da banda se um dos fluxos não usa toda a sua alocação

❒ PRINCÍPIO 3: Embora fornecendo isolação, é necessário usar os recursos da forma mais eficiente possível


marcação de pacotes

enlace lógico de 1 Mbps

enlace lógico de 0,5 Mbps

❒ Não deve ser aceito tráfego além da capacidade do enlace ❒ PRINCÍPIO 4: Necessita de um Processo de Admissão de

Chamada; a aplicação declara a necessidade do seu fluxo, a rede pode bloquear a chamada se a necessidade não pode ser satisfeita


Resumo

QoS para aplicações em redescl

assi

fica

ção

de p

acot

es

Isol

ação

: pro

gram

ação

e po

licia

men

to

alta

efi

ciên

cia

de u

tiliz

ação

Adm

issã

o de

cha

mad

as

Mecanismos de Escalonamento e Policiamento

❒ Escalonamento: a escolha do próximo pacote para transmissão num enlace pode ser feita de acordo com várias regras;

❒ FIFO: em ordem de chegada na fila; pacotes que chegam para um buffer cheio são ou descartados, ou uma política de descarte é usada para determinar qual pacote descartar entre aquele que chega e aqueles que já estão na fila

chegadas partidas

enlace(servidor)

fila(área de espera)

Disciplinas de Escalonamento❒ Filas com Prioridade: classes tem diferentes prioridades;

classes podem depender de marcação explícita ou de outras informações no cabeçalho, tais como, o endereço de origem ou de destino, número de portas, etc.

❒ Transmite um pacote da prioridade mais alta que esteja presente na fila

❒ Versão preemptive e não-preemptive

chegadas

classificação

fila de baixa prioridade(área de espera)

fila de alta prioridade(área de espera)

partidas

partidas

chegadas

pacotesno

servidor

tempo

tempoenlace(servidor)

Disciplinas de Escalonamento (mais)

❒ Round Robin: percorre as classes presentes na fila, servindo um pacote de cada classe que tem pelo menos um representante na fila

chegadas

pacote em serviço

partidas

tempo

tempo

❒ Weighted Fair Queuing (fila justa ponderada): é uma forma generalizada de Round Robin na qual se tenta prover a cada classe com um volume diferenciado de serviço num dado período de tempo

Disciplinas de Escalonamento (mais)

classificadorde chegadas

partidas

enlace

Mecanismos de Policiamento

❒ Três critérios: ❍ (Longo prazo) Taxa Média (100 pacotes por segundo ou 6000

pacotes por minuto??), o aspecto crucial é o tamanho do intervalo

❍ Taxa de Pico: ex. 6000 pacotes por minuto na média e 1500 pacotes por segundo de pico

❍ (Max.) Tamanho da Rajada: Máximo número de pacotes enviado consecutivamente, isto é, num curto período de tempo

❒ Mecanismo Token Bucket (balde de permissões), oferece um meio de limitar a entrada dentro de um tamanho de rajada e uma taxa média especificados.


pacotes esperatoken para a

rede

balde pode conter até b tokens

r tokens/seg

❒ Balde pode armazenar b tokens; tokens são gerados numa taxa de r token/seg exceto se o balde está cheio.

❒ Num intervalo de tempo t, o número de pacotes que são admitidos é menor ou igual a (r t + b).

❒ Token bucket e WFQ podem ser combinados para prover um limitesuperior ao atraso.


Serviços Integrados

❒ Uma arquitetura para prover garantias de QOS em redes IP para sessões individuais de aplicações

❒ Confia em reserva de recursos, e os roteadores necessitam manter informação de estado ( Circuito Virtual??), mantendo um registro dos recursos alocados e respondendo a novos pedidos de conexões de acordo com o estadoda rede

Admissão de Chamadas

❒ A sessão deve primeiramente declarar seus requisitos de e caracterizar o tráfego que ela enviará através da rede

❒ R-spec: define a QOS sendo solicitada❒ T-spec: define as características de tráfego❒ É necessário um protocolo de sinalização para transportar a

R-spec e a T-spec aos roteadores onde a reserva deve ser pedida; RSVP é o melhor candidato para este papel de protocolo de sinalização

Admissão de Chamadas

❒ Admissão de Chamadas: roteadores aceitarão as chamadas com base nas suas R-spec e T-spec e com base nos recursos correntemente alocados nos roteadores para outras chamadas.

1. Pedido: especifica - tráfego (Tspec) - garantia (Rspec)

2. Elemento considera- recursos não reservados- recursos solicitados

3. Resposta: o pedido podeou não ser atendido

Serviços Integrados: Classes

❒ QOS Garantido: esta classe é oferecida com controles estritos dos atrasos de filas nos roteadores; projetada para aplicações de tempo real críticas que são muito sensíveis ao atraso médio fim-a-fim e a sua variância

❒ Carga Controlada: esta classe fornece um QOS que aproxima bem aquele fornecido por umroteador não carregado; projetada para as aplicações IP de hoje que se comportam bem quando a rede não está carregada

Serviços Diferenciados

❒ Planejado para resolver as seguintes dificuldades que se encontram nos esquemas com Intserv e RSVP;

❒ Escalabilidade: manter informações dede estado nos roteadores em redes de alta velocidade é difícil devido ao grande número de fluxos simultâneos

❒ Modelos de Serviços Flexíveiss: Intserv tem apenas duas classes, deseja-se prover mais classes de serviços com diferentes méritos qualitativos; deseja-se manter uma distinção “relativa” entre as classes (Platina, Ouro, Prata, …)

❒ Sinalização mais Simples: (que o RSVP) muitas aplicações e usuários podem desejar apenas especificar um serviço de forma mais qualitativa

Serviços Diferenciados

❒ Abordagem: ❍ Apenas funções simples no interior da rede, e funções

relativamente complexas nos roteadores de borda (ou nos hosts)

❍ Não define classes de serviço, ao invés disso fornece componentes funcionais com os quais as classes de serviço podem ser construídas

Funções de Borda

❒ Num computador com funções de DS (serviços diferenciados) ou no primeiro roteador com funções de DS

❒ Classificação: o nó de borda marca os pacotes de acordo com regras de classificação a serem especificadas (manualmente pelo administrador ou por algum protocolo de sinalização)

❒ Condicionamento de Tráfego: o nó de borda pode atrasar e então enviar ou pode descartar

roteador de borda: classificaçãocondicionamentoroteador central:

envio

Funções do Núcleo Central

❒ Envio: de acordo com “Per-Hop-Behavior” (comportamento por salto) ou PHB especificado para aquela classe em particular; este PHB baseia-se estritiamente na marcação de classe (nenhum outro campo do cabeçalho pode ser usado para influenciar o PHB)

❒ GRANDE VANTAGEM:Não há necessidade de manter informação de estado

nos roteadores!

Classificação e Condicionamento

❒ Pacote é marcado no campo Tipo de Serviço (TOS) no IPv4, e Classe de Trafégo no IPv6

❒ 6 bits são usados para o Ponto de Código de Serviços Diferenciados (DSCP) - (Differentiated Service Code Point) e determinam o PHB que o pacote receberá

❒ 2 bits são atuamente reservados

❒ Pode ser desejável limitar a taxa de injeção de tráfego em alguma classe; usuário declara o perfil de tráfego (ex., taxa e tamanho das rajadas); tráfego é medido e ajustado se não estiver de acrodo com o seu perfil

Classificação e Condicionamento

pacotesclassificador marcador ajuste

corte

enviar

descartar

medidor

Envio (PHB)

❒ PHB resulta num comportamento observacio-nalmente diferente (mensurável) para o desempenho do envio de pacotes

❒ PHB não especifica quais mecanismos usar para assegurar um comportamento do desempenho conforme o exigido pelo PHB

❒ Exemplos: ❍ Classe A obtém x% da taxa de transmissão do enlace de

saída considerando intervalos de tempo de uma certa extensão

❍ pacotes de classe A partem primeiro, antes dos pacotes de classe B

Envio (PHB)

❒ PHBs que estão sendo estudados:❍ Envio Expresso: taxa de partida dos pacotes de uma dada

classe iguala ou excede uma taxa especificada (enlace lógico com uma taxa mínima garantida)

❍ Envio Assegurado: 4 classes, cada uma garantida com um mínimo de taxa de transmissão e armazenamento; cada uma com três particionamentos para preferência de descarte dos pacotes

Problemas com os Serviços Diferenciados

❒ AF e EF não estão padronizados ainda… pesquisa em andamento

❒ “Linhas dedicadas virtuais” e serviços “Olímpicos” estão sendo discutidos

❒ Impacto de atravessar múltiplos sistemas autônomos e roteadores que não estão preparados para operar com as funções de serviços diferenciados

Redes Multimídia -...

Documents

Transcript of Redes Multimídia -...