A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os requisitos de serviço multimídia em redes ü atraso ü largura.

Apresentações semelhantes


Apresentação em tema: "6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os requisitos de serviço multimídia em redes ü atraso ü largura."— Transcrição da apresentação:

1 6: Multimídia em Redes6a-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

2 6: Multimídia em Redes6a-2 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

3 6: Multimídia em Redes6a-3 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

4 6: Multimídia em Redes6a-4 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.

5 6: Multimídia em Redes6a-5 Multimídia em redes (4): extraindo o máximo do melhor esforço De 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.

6 6: Multimídia em Redes6a-6 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.

7 6: Multimídia em Redes6a-7 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.

8 6: Multimídia em Redes6a-8 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.

9 6: Multimídia em Redes6a-9 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.

10 6: Multimídia em Redes6a-10 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

11 6: Multimídia em Redes6a-11 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

12 6: Multimídia em Redes6a-12 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.

13 6: Multimídia em Redes6a-13 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.

14 6: Multimídia em Redes6a-14 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.

15 6: Multimídia em Redes6a-15 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.

16 6: Multimídia em Redes6a-16 Exemplo de Meta arquivo Twister

17 6: Multimídia em Redes6a-17 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.

18 6: Multimídia em Redes6a-18 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/ 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: OK

19 6: Multimídia em Redes6a-19 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.

20 6: Multimídia em Redes6a-20 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

21 6: Multimídia em Redes6a-21 Telefone Internet sobre melhor esforço (1) Melhor esforço Ø atraso, perda e jitter Exemplo 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

22 6: Multimídia em Redes6a-22 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

23 6: Multimídia em Redes6a-23 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

24 6: Multimídia em Redes6a-24 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´

25 6: Multimídia em Redes6a-25 Atraso de reprodução adaptativo (1) 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: onde u é uma constante (ex., u =.01).

26 6: Multimídia em Redes6a-26 Atraso de reprodução adaptativo (2) Também é útil estimar o desvio médio do atraso, v i : As estimativas d i e v i 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 é: onde K é um constante positiva. Para este mesmo pacote, o atraso de reprodução é: Para o pacote j do mesmo surto de tempo, reprodução ocorre no instante

27 6: Multimídia em Redes6a-27 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.

28 6: Multimídia em Redes6a-28 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

29 6: Multimídia em Redes6a-29 Recuperação da perda de pacotes (2) 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

30 6: Multimídia em Redes6a-30 Recuperação da perda de pacotes (3) 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

31 6: Multimídia em Redes6a-31 Recuperação da perda de pacotes (4) 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

32 6: Multimídia em Redes6a-32 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 Ø 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

33 6: Multimídia em Redes6a-33 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

34 6: Multimídia em Redes6a-34 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.

35 6: Multimídia em Redes6a-35 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.

36 6: Multimídia em Redes6a-36 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.

37 6: Multimídia em Redes6a-37 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.

38 6: Multimídia em Redes6a-38 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.

39 6: Multimídia em Redes6a-39 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.

40 6: Multimídia em Redes6a-40 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.

41 6: Multimídia em Redes6a-41 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 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.

42 6: Multimídia em Redes6a-42 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.

43 6: Multimídia em Redes6a-43 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.

44 6: Multimídia em Redes6a-44 H.323 Ø Visão geral Ø Terminal H.323 Ø Codificação H. 323 Ø Gatekeeper Ø Gateway Ø Codecs de áudio Ø Codecs de Vídeo

45 6: Multimídia em Redes6a-45 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.

46 6: Multimídia em Redes6a-46 Visão Geral (2) Ø Chamadas telefônicas Ø Chamadas de vídeo Ø Conferências Ø Quadros branco Todos os terminais dão suporte ao H.323

47 6: Multimídia em Redes6a-47 Visão Geral (3) H.323SS7, Dentro da faixa

48 6: Multimídia em Redes6a-48 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)

49 6: Multimídia em Redes6a-49 Terminal H.323

50 6: Multimídia em Redes6a-50 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.

51 6: Multimídia em Redes6a-51 Geração de fluxo de pacotes de áudio no H.323 Fonte de Áudio Codificação: ex., G.711 ou G encapsulamento de pacote RTP Socket UDP Internet ou Gatekeeper

52 6: Multimídia em Redes6a-52 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

53 6: Multimídia em Redes6a-53 Fluxos de informação

54 6: Multimídia em Redes6a-54 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.323 terminals Gatekeeper Router Internet LAN = Zone RAS

55 6: Multimídia em Redes6a-55 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 , 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.

56 6: Multimídia em Redes6a-56 Gateway H.323 terminals 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

57 6: Multimídia em Redes6a-57 Codecs de áudio MOS (Mean Opinion Score)

58 6: Multimídia em Redes6a-58 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) SQCIF QCIF CIF 4CIF 16CIF


Carregar ppt "6: Multimídia em Redes6a-1 Capítulo 6: Multimídia em Redes Objetivos do capítulo: Ø entender os requisitos de serviço multimídia em redes ü atraso ü largura."

Apresentações semelhantes


Anúncios Google