6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os...

6: Multimídia em Redes 6a-1

Capítulo 6: Multimídia em Redes

Objetivos do capítulo: entender os requisitos

de serviço multimídia em redes

atraso largura de banda perda

aprender como extrair o máximo do serviço Internet de melhor esforço

aprender como a Internet pode evoluir para dar um melhor suporte a multimídia

Resumo do Capítulo: aplicações multimídia em rede streams de áudio e vídeo

armazenados RTSP

aplicações de tempo real interativas

Exemplo do telefone Internet RTP H.323 e SIP além do melhor esforço

escalonamento e policiamento serviços integrados serviços diferenciados


Multimídia em Redes

Características fundamentais: Tipicamente é sensível a

atrasos. Mas é tolerante a perdas:

perdas raras causam pequenos distúrbios que podem ser compensados.

Antítese da transmissão de dados (programas, trans. Bancárias, etc.), que são intolerantes a perdas mas toleram atrasos.

Multimídia também é chamada de “mídia contínua”

Classes de aplicações MM: Streaming de áudio e

vídeo armazenados Streaming de áudio e

vídeo ao vivo Vídeo interativo de

tempo real


Multimídia em redes (2)

Streaming MM armazenado Os clientes solicitam

arquivos de áudio/vídeo de servidores e efetuam o pipeline da recepção através da rede e apresentação

Interativo: usuário pode controlar a operação (semelhante ao VCR: pausa, retomada, avanço rápido, retorno, etc.)

Atraso: desde o pedido do cliente até que a apresentação tenha início pode variar de 1 a 10 segundos

Tempo real Unidirecional: semelhante às estações de TV

e rádio convencionais, mas com distribuição através da Internet

Não interativa, apenas escuta e vê

Tempo real Interativo: Tele ou vídeo conferência Requisitos de atraso mais

exigentes do que para Streaming & Unidirecional por causa da natureza de tempo real

Vídeo: < 150 mseg é aceitável Áudio: < 150 mseg é bom,

<400 mseg é aceitável


Multimídia em redes (3): desafios

A pilha TCP/UDP/IP provê melhor esforço, sem garantias de atraso ou variação do atraso

Apl. streaming com atraso inicial de 5-10 segundos são comuns hoje, mas o desempenho se deteriora se os enlaces estiverem congestionados (transoceânicos)

Apl. interativas de tempo real possuem requisitos rígidos para atraso dos pacotes e jitter.

Jitter é a variabilidade dos atrasos dos pacotes dentro do mesmo fluxo de pacotes.

O projeto de apls. MM seriam facilitados se houvesse serviços de 1a. e 2a. classe.

Mas, na Internet pública, todos os pacotes recebem o mesmo serviço.

Os pacotes que contêm áudio e vídeo interativos esperam nas filas, como os demais.

Houve e continua a haver esforços para prover um serviço diferenciado.


Multimídia em redes (4): extraindo o máximo do melhor

esforçoDe modo a minimizar o

impacto do “melhor esforço” na Internet, nós podemos:

Usar UDP para evitar o TCP e sua fase de início lento...

Armazenar o conteúdo no cliente e controlar a reprodução de modo a compensar o jitter

Podemos carimbar o tempo nos pacotes de modo que o receptor saiba quando os pacotes devem ser reproduzidos.

Adaptar o nível de compressão de acordo com a largura de banda disponível.

Enviar pacotes redundantes para minimizar os efeitos da perda de pacotes.

Discutiremos todos estes “truques”.


Como a Internet deveria evoluir para suportar melhor a MM?

Filosofia de serviços integrados: Modifica os protocolos Internet

de modo que as aplicações possam reservar banda fim a fim

Necessita implantar protocolo que reserve largura de banda

Deve modificar políticas de escalonamento nos roteadores para honrar as reservas.

As aplicações devem fornecer à rede uma descrição do seu tráfego e deve obedecer à sua descrição.

Requer software novo e complexo em hosts & roteadores

Filosofia de serviços diferenciados:

Menos mudanças na infra-estrutura da Internet, mas provendo serviços de 1a. e 2a. classes.

Os datagramas são marcados.

O usuário paga mais para enviar/receber pacotes de 1a. classe.

Os ISPs pagam mais aos backbones para enviar/receber pacotes de 1a. classe.


Como a Internet deveria evoluir para suportar melhor a MM? (cont.)

Filosofia do “deixa estar”: Sem reservas e sem

marcação dos datagramas À medida que aumenta a

demanda, provê mais banda

Coloca o conteúdo armazenado na periferia da rede:

ISPs & backbones adicionam caches

Provedores de conteúdo colocam seus conteúdos em nós da CDN

P2P: escolhe um parceiro próximo que contenha o conteúdo desejado

Redes privativas virtuais (VPNs)

Reserva blocos permanentes de banda para empresas

Roteadores distinguem o tráfego VPN a partir dos endereços IP

Roteadores usam políticas de escalonamento especiais para prover banda reservada.


Streams de Áudio & Vídeo Armazenados

Streaming mídia armazenada: Arquivo de áudio/vídeo é

armazenado num servidor Usuários solicitam arquivo

de áudio/vídeo sob demanda.

O áudio/vídeo é apresentado dentro de cerca de 10 s após a solicitação.

É permitida interatividade (pausa, reposicionamento, etc.)

Tocador/Reprodutor de mídia:

remove o jitter efetua a descompressão correção de erro interface gráfica com

controles de interatividade

Podem ser usados “plug-ins” para embutir o reprodutor na janela do browser.


Streaming a partir de um servidor Web (1)

Arquivos de áudio e vídeo armazenados em servidores Web

abordagem simplista o browser solicita o arquivo

com uma mensagem de pedido HTTP

servidor Web envia arquivo numa mensagem de resposta HTTP

linha de tipo de conteúdo do cabeçalho indica a codificação de áudio/vídeo

o browser inicia o reprodutor de mídia e lhe passa o arquivo

o reprodutor de mídia reproduz/apresenta o arquivo

Desvantagem principal: o reprodutor de mídia interage com o servidor através de um web browser intermediário.


Streaming a partir de um servidor Web (2)

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

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

cabeçalho de tipo de conteúdo identifica a aplicação específica de áudio/vídeo

o browser inicia o reprodutor de mídia e lhe passa o meta arquivo

o reprodutor de mída estabelece uma conexão TCP com o servidor e envia pedido HTTP

Algumas preocupações: Tocador de mídia

comunica através do HTTP que não foi projetado com comandos de pausa, avanço e retorno

Pode querer transmitir sobre UDP


Streaming a partir de um servidor de streams

Esta arquitetura permite o uso de procolos não-HTTP entre o servidor e o reprodutor de mída

Também pode usar UDP ao invés do TCP


Opções ao utilizar um servidor de streams

Transmite em taxa constante sobre o UDP. Para minimizar os efeitos do jitter, o buffer armazena e retarda a reprodução por 1-10 s. Taxa de transmissão = d, a taxa de codificação. A taxa de preenchimento x(t) é igual a d exceto quando houver perdas.

Use TCP e envie na maior taxa possível com o TCP; o TCP retransmite quando encontrar algum erro; x(t) irá flutuar e será bem maior do que d. O reprodutor pode usar um buffer maior para amaciar a taxa de entrega do TCP.


Real Time Streaming Protocol: RTSP

HTTP Os projetistas do HTTP

tinham em mente mídia estática: HTML, imagens, applets, etc.

HTTP não tinha como alvo mídia contínua armazenada (i.e., áudio, vídeo, apresentações SMIL, etc.)

RTSP: RFC 2326 Protocolo cliente-servidor

da camada de aplicações.

O usuário pode controlar a apresentação: retorno, avanço rápido, pausa, retomada, reposicionamento, etc.

O que ele não faz: Não define como o

áudio/vídeo é encapsulado para ser transmitido pela rede

Não restringe como a mídia tipo stream é transportada; pode ser transportada sobre UDP ou TCP

Não especifica como o apresentador da mídia bufferiza o áudio/vídeo

RealNetworks Tanto o servidor como o

apresentador usam RTSP para enviar informações de controle entre eles.


RTSP: controle fora da faixa

FTP usa um canal de controle “fora da faixa”:

Um arquivo é transferido sobre um canal.

A informação de controle (mudança de diretório, remoção de arquivo, renomeação de arquivo, etc.) é enviado numa conexão TCP à parte.

Os canais “fora da faixa” e “dentro da faixa” utilizam diferentes números de portas.

As mensagens RTSP também são enviadas fora da faixa:

As mensagens de controle RTSP usam números de porta diferentes do fluxo da mídia, e são, portanto, enviadas fora da faixa.

O fluxo de mídia, cuja estrutura de pacote não for definida pelo RTSP é considerado “dentro da faixa”.

Se as mensagens RTSP utilizassem os mesmos números de portas que o fluxo de mídia, então as mensagens RTSP estariam “intercaladas” com o fluxo da mídia.


O RTSP inicia e controla a entrega

O cliente obtém uma descrição da apresentação multimídia, que pode consistir de diversos fluxos de mídia.

O browser chama o apresentador da mídia (aplicação de suporte) baseado no tipo do 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 URL rtsp://

O apresentador enviar um pedido RTSP SETUP; o servidor envia uma resposta RTSP SETUP.

O apresentador envia um pedido RTSP PLAY; o servidor envia uma resposta RTSP PLAY.

O servidor de Mídia “bombeia” o fluxo da mídia.

O apresentador envia um pedido RTSP PAUSE; o servidor envia uma resposta RTSP PAUSE.

O apresentador envia um pedido RTSP TEARDOWN; o servidor envia uma resposta RTSP TEARDOWN.

H TTP G E T

S E TU P

P LA Y

m edia stream

P A U S E

TE A R D O W N

mediaplayer

W ebserver

mediaserver

W ebbrow ser

client server

presenta tion desc.


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 RTSP possui um identificador de sessão que é escolhido pelo servidor.

O cliente inicia uma sessão com o pedido de SETUP, e o servidor responde ao pedido com um identificador.

O cliente repete o identificador da sessão para cada pedido, até que o cliente feche a sessão com o pedido de TEARDOWN.

O número da porta RTSP é 554.

RTSP pode ser enviado sobre UDP ou TCP. Cada mensagem RTSP pode ser enviada por uma conexão TCP diferente.


RTSP: exemplo de diálogo 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 streams

Fazer o cache de mensagens de resposta RTSP não faz muito sentido.

Mas é desejável fazer o cache os fluxos de mídia próximo dos clientes.

Boa parte do controle de cache do HTTP/1.1 foi adotado pelo RTSP.

Cabeçalhos de controle de cache podem ser colocados nos pedidos e respostas RTSP SETUP:

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

Cache intermediário (Proxy) pode conter apenas segmentos de um dado fluxo de mídia.

Cache proxy pode começar a servir um cliente a partir do seu cache local, e depois ter que conectar ao servidor origem e completar o material que não estiver disponível, de preferência sem introduzir lacunas para o cliente.

Quando o servidor da origem estiver enviando o stream para um cliente, e o stream passar por um proxy, o proxy pode utilizar o TCP para obter o stream; mas o proxy ainda enviará mensagens de controle RTSP para o servidor origem.


Aplicações interativas de tempo real

Telefone PC-2-PC PC-2-telefone

Dialpad Net2phone

videoconferência Webcams

Vamos estudar em detalhes um exemplo de telefone Internet PC-2-PC


Telefone Internet sobre melhor esforço (1)

Melhor esforço atraso, perda e jitterExemplo de telefone

Internet Vamos examinar como

atraso, perda e jitter são freqüentemente tratados no contexto de um exemplo de telefone IP.

As aplicações de telefone Internet geram pacotes durante os surtos de voz

A taxa de transmissão é de 64 kbps durante um surto de voz

Durante um surto de voz, a cada 20 mseg a aplicação gera um pedaço de 160 bytes =8 kbytes/seg * 20 mseg

Cabeçalho é adicionado ao pedaço; então o pedaço+cabeçalho é encapsulado num pacote UDP e transmitido

Alguns pacotes podem se perder e o atraso do pacote irá flutuar.

O receptor deverá determinar quando tocar o pedaço e determinar o que fazer se um pedaço não estiver disponível


Telefone Internet (2)

Perda de pacotes O segmento UDP é

encapsulado em um datagrama IP

datagramas podem transbordar a fila de um roteador

TCP pode eliminar perdas, mas

retransmissões adicionam atrasso

O controle de congestionamento doTCP limita a taxa de transmissão

Pacotes redundantes podem ajudar

Atraso fim a fim Acúmulo de atrasos de

transmissão, propagação e enfileiramento.

Mais do que 400 mseg de atraso fim a fim podem prejudicar seriamente a interatividade; quanto menor, melhor

jitter considere dois pacotes

consecutivos num surto de voz

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

remoção de jitter Números de seqüência Carimbos de tempo Retardar a reprodução


Telefone Internet (3): atraso de apresentação fixo

O receptor tenta reproduzir cada pedaço exatamente q msegs após a geração do pedaço.

Se o pedaço contiver um carimbo de tempo t, o receptor reproduzirá o pedaço no instante t+q .

Se o pedaço chegar após o instante t+q, o receptor o descartará.

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

A estratégia acomoda pacotes perdidos.

Compromissos para q: q longo: menos perda de

pacotes q pequeno: melhor

experiência interativa


Telefone Internet (4): atraso de apresentação fixo

Transmissor gera pacotes a cada 20 mseg durante o surto de voz. O primeiro pacote é recebido no instante r A primeira reprodução é programada para iniciar no instante p A segunda reprodução é programada para iniciar no instante p´

packets

tim e

packetsgenerated

packetsreceived

loss

r

p p '

playout schedulep - r

playout schedulep' - r


Atraso de reprodução adaptativo (1)

pacote ésimo- oreceber após rede da médio atraso do estimativa

pacote ésimo- o para rede da atraso

receptor no oreproduzid é pacote o que em instante

receptor pelo recebido é pacote o que em instante

pacote ésimo- do tempode carimbo

id

itr

ip

ir

it

i

ii

i

i

i

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

• Períodos de silêncio são comprimidos e alongados.

• Os pedaços ainda são reproduzidos a vada 20 mseg durante um surto de voz.

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

)()1( 1 iiii trudud

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


Atraso de reprodução adaptativo (2)

Também é útil estimar o desvio médio do atraso, vi :

||)1( 1 iiiii dtruvuv

As estimativas di e vi são calculadas para cada pacote recebido, apesar de serem usados apenas no início de um surto de voz.

Para o primeiro pacote de um surto de voz, o tempo de apresentação é:

iiii Kvdtp

onde K é um constante positiva. Para este mesmo pacote, o atraso de reprodução é:

iii tpq

Para o pacote j do mesmo surto de tempo, reprodução ocorre no instante

ijj qtp


Reprodução adaptativa (3)

Como determinar se um pacote é o primeiro de um surto de voz: Se nunca houvesse perdas, o receptor poderia simplesmente

olhar os carimbos de tempo sucessivos. Diferença entre carimbos sucessivos > 20 mseg,

início do surto de voz. Mas, dado que perdas são possíveis, o receptor deve

olhar tanto para os carimbos de tempo quanto para os números de seqüência. Diferença entre carimbos sucessivos > 20 mseg e

números de seqüência sem falhas, início do surto de voz.


Recuperação da perda de pacotes (1)

Perda: pacote nunca chega ou chega mais tarde do que o tempo previsto de reprodução

forward error correction (FEC): esquema simples

para cada grupo de n pedaços criar um pedaço redundante efetuando o OU-exclusivo dos n pedaços originais

transmite n+1 pedaços, aumentando a largura de banda por um fator de 1/n.

pode reconstruir os n pedaços originais se houver no máximo um pedaço perdido dentre os n+1 pedaços.

Atraso de reprodução deve ser fixado para o instante de recepção de todos os n+1 pacotes

Compromissos: aumento de n, menos

desperdício de banda aumento de n, atraso de

reprodução mais longo aumento de n, maior

probabilidade de que 2 ou mais pedaços sejam perdidos



2o. Esquema de FEC• transmissão de “carona” de um fluxo de menor qualidade•envie fluxo de áudio de baixa resolução como informação redundante•por exemplo, fluxo nominal PCM a 64 kbps e fluxo redundante GSM a 13 kbps.• Transmissor cria pacote tomando o n-ésimo pedaço do fluxo nominal e adicionando a ele o (n-1)-ésimo pedaço do fluxo redundante.

• Sempre que houver uma perda não consecutiva, o receptor poderá recuperar a perda.• Apenas dois pacotes precisam ser recebidos antes da reprodução• Pode também adicionar o (n-1)-ésimo e o (n-2)-ésimo pedaço de baixa taxa de transmissão



Intercalamento os pedaços são

quebrados em unidades menores

por exemplo, quatro unidades de 5 mseg por pedaço

intercala os pedaços como mostrado no diagrama

pacote agora contém pequenas unidades de pedaços diferentes

Remonta os pedaços no receptor

se o pacote é perdido, ainda temos muito de cada pedaço



Reparação baseada no receptor de fluxos de áudio danificados

produz um substituto para o pacote perdido que é semelhante ao original

pode prover bom desempenho para taxas de perda baixas e pequenos pacotes (4-40 mseg)

mais simples: repetição mais complicado:

interpolação


Protocolo de Tempo Real (RTP)

RTP = Real Time Protocol RTP especifica uma

estrutura de pacote para pacotes que transportam dados de áudio e de vídeo: RFC 1889.

Pacote RTP provê Identificação do tipo da

carga Numeração da

seqüência de pacotes Carimbo de tempo

RTP roda nos sistemas terminais.

Pacotes RTP são encapsulados em segmentos UDP

Interoperabilidade: Se duas aplicações de telefone Internet rodarem RTP então elas poderão trabalhar em conjunto


RTP roda sobre UDP

Bibliotecas RTP provêm uma interface da camada de transporte que estende o UDP:

• números de portas, endereços IP• verificação de erro através de segmentos• identificação do tipo da carga• numeração da seqüência de pacotes• carimbo de tempo


Exemplo RTP

Considere o envio de voz codificada em PCM de 64 kbps sobre RTP.

Aplicação coleta os dados codificados em pedaços, ex., a cada 20 mseg = 160 bytes num pedaço.

O pedaço de áudio junto com o cabeçalho RTP formam um pacote RTP, que é encapsulado num segmento UDP.

O cabeçalho RTP indica o tipo da codificação de áudio em cada pacote: os transmissores podem mudar a codificação durante a conferência. O cabeçalho RTP também contém números de seqüência e carimbos de tempo.


RTP e QoS

RTP não provê nenhum mecanismo para garantir a entrega em tempo dos dados nem nenhuma outra garantia de qualidade de serviço.

O encapsulamento RTP é visto apenas nos sistemas terminais – não é visto por roteadores intermediários.

Roteadores provendo o serviço tradicional Internet de melhor esforço não faz nenhum esforço adicional para garantir que os pacotes RTP cheguem ao destino em tempo.

De modo a prover QoS a uma aplicação, a Internet deve prover um mecanismo, como o RSVP, para que a aplicação reserve recursos da rede.


Fluxos RTP

RTP permite que seja atribuída a cada fonte (ex. uma câmera ou um microfone) um fluxo RTP independente de pacotes.

Por exemplo, para uma videoconferência entre dois participantes, quatro fluxos RTP poderiam sera abertos: dois fluxos para transmitir o áudio (um em cada direção) e dois fluxos para o vídeo (também um em cada direção).

No entanto, algumas técnicas de codificação populares – incluindo MPEG1 e MPEG2 – juntam o áudio e o vídeo num único fluxo durante o processo de codificação. Quando o áudio e o vídeo são agrupados pelo codificador, então apenas um fluxo RTP é gerado em cada direção.

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


Cabeçalho RTP

Tipo da carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado.

Se o transmissor modificar a codificação no meio de uma conferência, o transmissor informará o receptor através do campo do 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, vídeo MPEG2

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


Cabeçalho RTP (2)

Campo de carimbo de tempo (32 bytes). Reflete o instante de amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar os carimbos de tempo para remover o jitter dos pacotes e prover uma reprodução síncrona. O carimbo de tempo é derivado a partir de um relógio de amostragem no transmissor.

Como um exemplo, para áudio o relógio de carimbo de tempo incrementa de um para cada período de amostragem (por exemplo, a cada 125 seg para um relógio de amostragem de 8kHz); se a aplicação de áudio gerar pedaços de 160 amostras codificadas, então o carimbo de tempo aumenta de 160 para cada pacote RTP quando a fonte estiver ativa. O relógio de carimbo de tempo continua a aumentar a uma taxa constante mesmo quando a fonte estiver inativa.

Campo de SSRC (32 bits). Identifica a fonte de um fluxo RTP. Cada fluxo numa sessão RTP deve possuir um SSRC distinto.


Protocolo de Controle de Tempo Real (RTCP)

Real-Time Control Protocol Trabalha em conjunto com o

RTP. Cada participante numa

sessão RTP periodicamente transmite pacotes de controle RTCP para todos os demais participantes. Cada pacote RTCP contém relatos do transmissor e/ou receptor que relatam estatísticas úteis para as aplicações.

Estas estatísticas incluem o número de pacotes enviados, o número de pacotes perdidos, jitter entre chegadas, etc.

Esta realimentação de informação para as aplicações pode ser usada para controlar o desempenho e para finalidades de diagnóstico.

O transmissor pode modificar as suas transmissões baseadas na realimentação.


RTCP - Continuação

- Para uma sessão RTP há tipicamente um único endereço multicast; todos os pacotes RTP e RTCP pertencentes à sessão usam o endereço multicast.

- Pacotes RTP e RTCP são diferenciados uns dos outros através do uso de números de portas distintos.

- Para limitar o tráfego, cada participante reduz o seu tráfego RTCP à medida que cresce o número de participantes da conferência.


Pacotes RTCP

Pacotes de relato do receptor:

Fração dos pacotes perdidos, último número de seqüência, jitter entre chegadas médio.

Pacotes de relato do transmissor:

SSRC do fluxo RTP, tempo atual, número de pacotes enviados e número de bytes enviados.

Pacotes de descrição da origem:

Endereço de e-mail do transmissor, nome do transmissor, o SSRC do fluxo RTP associado. Os pacotes provêm um mapeamento entre o SSRC e o nome do usuário/host.


Sincronização de Fluxos

O RTCP pode ser usado para sincronizar diferentes fluxos de mídia dentro de uma sessão RTP.

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

Os carimbos de tempo nestes pacotes RTP estão vinculados aos relógios de amostragem de vídeo e de áudio, e não estão vinculadas ao relógio de tempo real.

Cada pacote de relato do transmissor contém, para o pacote gerado mais recentemente no fluxo RTP associado, o carimbo de tempo do pacote RTP e o relógio de tempo real no instante em que o pacote foi criado. Portanto os pacotes de relato do transmissor associam o relógio de amostragem ao relógio de tempo real.

Os receptores pode usar esta associação para sincronizar a reprodução de áudio e de vídeo.


Escalonamento da Largura de Banda do RTCP

O RTCP tenta limitar o seu tráfego a 5% da largura de banda da sessão.

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

O protocolo atribui 75% desta taxa, ou 75 kbps, para os receptores; e atribui os restantes 25% da taxa, ou 25 kbps, para o transmissor.

Os 75 kbps dedicados aos receptores é igualmente compartilhada entre os receptores. Portanto, se houver R receptores, então cada receptor pode transmitir tráfego RTCP a uma taxa de 75/R kbps e o transmissor pode transmitir tráfego RTCP a uma taxa de 25 kbps.

Um participante (um transmissor ou receptor) determina o período de transmissão dos pacotes RTCP através do cálculo dinâmico do tamanho médio de um pacote RTCP (ao longo de 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 áudio Codecs de Vídeo


Visão Geral (1) Base para conferências

de áudio e de vídeo através de redes IP.

Visa a comunicação de tempo real (ao invés da sob demanda)

Recomendação guarda-chuva do ITU.

Escopo abrangente: dispositivos stand-alone

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

ponto e multiponto

A especificação H.323 inclui:

Como os pontos terminais fazem e recebem chamadas.

Como os pontos terminais negociam codificações comuns de áudio/vídeo.

Como os pedaços de áudio e vídeo são encapsulados e enviados através da rede.

Como o áudio e o vídeo são sincronizados (lipsync).

Como os pontos terminais se comunicam com seus respectivos gatekeepers.

Como os telefones Internet se os telefones PSTN/RDSO se comunicam.


Visão Geral (2)

Chamadas telefônicas

Chamadas de vídeo

Conferências Quadros branco

Todos os terminais dão suporte ao H.323

Internet

"Ethernet" phone

MS NetmeetingNetSpeak WebPhone


Visão Geral (3)

H.323 SS7, Dentro da faixa

Internet PSTNGateway

Gatekeeper


Os Pontos Terminais H.323 Devem dar Suporte a:

G.711 – padrão ITU para compressão de voz

RTP - protocolo para o encapsulamento de pedaços de mídia em pacotes

H.245 – protocolo de controle “Fora da faixa” para controle da mídia entre pontos terminais H.323

Q.931 – Protocolo de sinalização para o estabelecimento e terminação de chamadas.

RAS (Registro/Admissão/Status) Protocolo para a comunicação com um gatekeeper (se o gatekeeper estiver presente)


Terminal H.323


Codificação H.323

Áudio: Pontos terminais H.323

devem dar suporte ao padrão G.711 para compressão de voz. G.711 transmite voz a 56/64 kbps.

H.323 está considerando solicitar o G.723 = G.723.1, que opera a 5.3/6.3 kbps.

Opcional: G.722, G.728, G.729

Vídeo Capacitações de vídeo

para um ponto terminal H.323 são opcionais.

Todo terminal H.323 habilitado para vídeo deve dar suporte ao QCIF H.261 (176x144 pixels).

Opcionalmente pode dar suporte a outros esquemas H.261: CIF, 4CIF e 16CIF.

H.261 é usado com canais de comunicação que são múltiplos de 64 kbps.


Geração de fluxo de pacotes de áudio no H.323

Fonte deÁudio

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

encapsulamento de pacote RTP

SocketUDP

Internet ouGatekeeper


Canal de Controle H.245

Fluxo H.323 pode conter múltiplos canais para tipos diferentes 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.

Princípios das tarefas: Abrir e fechar canais

de mídia. Capacitação do

diálogo: antes de transmitir, os terminais entram em acordo sobre o algoritmo de codificação

Nota: o uso do H.245 para conferência multimídia é análogo ao RTSP para mídia em streams


Fluxos de informação

H.323Terminal

H.323Terminal

Media Channel1

Media ControlChannel

Media Channel2

Call SignalingChannel

Call ControlChannel

TCP

UDP


Gatekeeper 1/2

• O gatekeeper é opcional. Provê para os terminais:

• tradução de endereços para endereços IP

• gerenciamento de largura de banda: pode limitar a largura de banda consumida por conferências de tempo real

• Opcionalmente, chamadas H.323 podem ser roteadas através do gatekeeper. Útil para tarifação.

• Protocolo RAS (sobre TCP) para comunicação terminal-gatekeeper.

H.3

23 te

rmin

als

Gatekeeper

Router

Internet

LAN = “Zone”

RAS


Gatekeeper 2/2

Um terminal H.323 deve se registrar com o gatekeeper da sua zona. Quando a aplicação

H.323 é executada no terminal, o terminal usa o RAS para enviar o seu endereço IP e apelido (fornecido pelo usuário) ao gatekeeper.

Se o gatekeeper estiver presente numa zona, cada terminal da zona deve contactar o gatekeeper para pedir permissão para fazer a chamada.

Assim que tiver recebido a permissão, o terminal pode enviar ao gatekeeper um endereço de e-mail, apelido ou ramal telefônico. O gatekeeper traduz o apelido para um endereço IP. Caso necessário, um

gatekeeper consultará outros gatekeepers em outras zonas para resolver o endereço IP. Procedimento varia de acordo com o vendedor.


Gateway

H.3

23 te

rmin

als

Gatekeeper

Router Internet

LAN = “Zone”

RAS

Gateway

PSTN

• Ponte entre a Zona IP e a rede telefônica comutada (ou RDSI).• Os terminais se comunicam com os gateways usando H.245 e Q.931


Codecs de áudio

Codec Largura

de Banda [kbit/s]

MOS Complexidade [MIPS]

Paquetização (tamanho do

quadro) [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

MOS (Mean Opinion Score)


Codecs de vídeo

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

• H.263 (< 64 kbit/s)– Comunicação em baixa taxa– 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

6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os...

Documents

Transcript of 6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os...