Capítulo 6: Multimídia em Redes

Apresentação em tema: "Capítulo 6: Multimídia em Redes"— Transcrição da apresentação:

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

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

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

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

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: Multimídia em Redes

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

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

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

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

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

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

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

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

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

15 O RTSP inicia e controla a entrega
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. 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. 6: Multimídia em Redes

16 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"> 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> 6: Multimídia em Redes

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

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 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 S: OK 6: Multimídia em Redes

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

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

21 Telefone Internet sobre melhor esforço (1)
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 6: Multimídia em Redes

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

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

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

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

26 Atraso de reprodução adaptativo (2)
Também é útil estimar o desvio médio do atraso, vi : 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 é: 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 6: Multimídia em Redes

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

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

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

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

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

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

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

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

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

36 Fluxos RTP 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. 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). 6: Multimídia em Redes

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

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

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

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

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

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

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

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

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

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

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

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

49 Terminal H.323 6: Multimídia em Redes

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

51 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 Socket UDP Internet ou Gatekeeper 6: Multimídia em Redes

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

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

54 Gatekeeper 1/2 O gatekeeper é opcional. Provê para os terminais:
H.323 terminals Gatekeeper Router Internet LAN = “Zone” RAS 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. 6: Multimídia em Redes

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

56 Gateway PSTN LAN = “Zone”
H.323 terminals Router Internet RAS Gatekeeper LAN = “Zone” 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 6: Multimídia em Redes

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

58 Codecs de vídeo H.261 (p x 64 kbit/s) H.263 (< 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 6: Multimídia em Redes