Redes Multimídia. Professor: Renê Furtado Felix Redes II - UNIP 1

Transcrição

1 Redes Multimídia Professor: Renê Furtado Felix Redes II - UNIP 1

2 As exigências de funcionamento das aplicações multimídia divergem significamente daquelas tradicionais aplicações elásticas como: , navegação na WEB, login remoto e download. Redes II - UNIP 2

3 As aplicações multimídias são: Fluxo de áudio/vídeo armazenado. Fluxo de áudio/vídeo ao vivo. Fluxo de áudio/vídeo interativo de tempo real. Redes II - UNIP 3

4 Características: Fluxo de áudio/vídeo armazenados: clientes requisitam áudio/vídeo comprimidos que estão armazenados em servidores. Mídia Armazenada. Fluxo Continuo: (streaming). Reprodução Continua: buffer. Redes II - UNIP 4

5 Características: Áudio e Vídeo de Fluxo Continuo ao Vivo. Aplicações são conhecidas como um rádio da Internet e IPTV. Não pode adiantar o programa que está recebendo. Técnicas de multicasting IP (ALGORITMOS DE MULTICASTING). Redes II - UNIP 5

6 P2P CDN Redes de Distribuição de Conteúdo Redes II - UNIP 6

7 Características: Áudio e Vídeo Interativos em Tempo Real. Frequentemente denominado telefone por internet. Facilita Detectores de presença, comunicação em grupos, integração telefone/web, filtragem de chamadas e outros mais. (não suportados por comutação por circuito) Redes II - UNIP 7

8 Características: Áudio e Vídeo Interativos em Tempo Real. No caso da voz, atrasos menores do que 150 milissegundos não são percebidos pelo ouvido humano, atrasos entre 150 e 400 milissegundos são aceitos e atrasos que excedem 400 milissegundos podem resultar em conversas frustrantes, ininteligíveis. Redes II - UNIP 8

9 Obstáculos para a Multimídia na Internet de Hoje O protocolo IP provê um serviço de melhor esforço a todos os datagramas que transporta. Nenhuma garantia contra atraso às aplicações requisitantes. Atrasos de 5 a 10 segundos na interatividade com o usuário agora é comum na internet. Redes II - UNIP 9

10 Obstáculos para a Multimídia na Internet de Hoje Voz e vídeo interativos em tempo real impõem rígidas limitações de atraso de pacote e a variação de atraso de pacote. Redes II - UNIP 10

11 Obstáculos para a Multimídia na Internet de Hoje Artimanhas para melhorar a qualidade de uma aplicação. Por exemplo: podemos enviar áudio e vídeo sobre UDP e, assim evitar a baixa vazão do TCP quando este entra em fase de partida lenta. Podemos retardar a reprodução no receptor em 100 milissegundos ou mais para reduzir os efeitos da variação de atraso induzida pela rede. Podemos colocar marca de tempo nos pacotes no remetente, de modo que o receptor saiba quando eles devem ser reproduzidos. Redes II - UNIP 11

12 Compressão de áudio e vídeo Antes que áudio e vídeo possam ser transmitidos por uma rede de computadores, eles devem ser digitalizados e comprimidos. Importância da compressão de áudio e vídeo? Exemplo: Sem compressão, uma única imagem constituída de (com cada pixel codificado em 24 bits 8 bits para cada uma das cores vermelha, verde e azul), exige 3 Mbytes de armazenamento. Redes II - UNIP 12

13 Compressão de áudio e vídeo Levaria 7 minutos para enviar essa imagem por um enlace de 64 kbps. Se a imagem for comprimida na modesta razão de compressão de 10:1, a necessidade de armazenamento será reduzida para 300 kbytes e o tempo de transmissão também diminuirá por um fator de 10. Redes II - UNIP 13

14 Compressão de áudio na Internet O sinal analógico de áudio é primeiramente amostrado a alguma taxa fixa, por exemplo, amostras por segundo. O valor de cada amostra é um número real arbitrário. Cada uma das amostras é então arredondada para um valor entre um número finito de valores. Essa operação é denominada quantização. Cada um dos valores de quantização é representado por um número fixo de bits. Ex: Se houver 256 valores de quantização, então cada valor, cada amostra será representada por 1 byte. Redes II - UNIP 14

15 Compressão de áudio na Internet Cada uma das amostras é convertida à sua representação por bits. As representações por bits de todas as amostras são, então, concatenadas em conjunto para formar a representação digitalizada do sinal. A técnica básica de codificação citada à cima é denominada modulação por codificação de pulso (pulse code Modulation PCM). Codificação de voz frequentemente usa PCM. Com uma taxa de amostragem de amostras por segundos e 8 bits por amostra, o que dá uma taxa de 64 kbps. O disco compacto de áudio (CD) também usa PCM. Redes II - UNIP 15

16 Compressão de áudio na Internet Com taxa de amostragem de amostras por segundos e 16 bits por amostras, isso dá uma taxa de 705,6 kbps para mono e 1,411 Mpbs para estéreo. Voz e musicas codificado por PCM raramente são usados na internet, uma taxa de 1,411 para musicas estéreo e 64 Kbps para voz ultrapassam a taxa de acesso de um modem discado. Entre as técnicas populares para internet utilizadas para voz estão: GSM (13kbps), G.729 (8kbps) e G (6,4 e 5,3 kbps) e um grande número de técnicas proprietárias. Redes II - UNIP 16

17 Compressão de áudio na Internet Uma técnica de compressão popular para musica estéreo com qualidade próxima à do CD é a MPG 1 da camada 3, mais conhecida como MP3. Comprime a taxa de 96 kbps, 128 kbps ou 112 kbps e causam pouquíssima degradação de som. Pode ser fragmentado, e cada pedaço ainda é reproduzível. Esse formato permite que arquivos de musica mp3 sejam transmitidos pela Internet em fluxo continuo. Redes II - UNIP 17

18 Compressão de vídeo na Internet Um vídeo é uma sequencia de imagens que normalmente são apresentadas a uma taxa constante: Ex: 24 ou 30 imagens por segundo. Uma imagem não comprimida, codificada digitalmente, é constituída de um conjunto de pixels, e cada pixel é codificado por um numero de bits para representar luminância e cor. Redes II - UNIP 18

19 Compressão de vídeo na Internet Há dois tipos de redundância em vídeo, ambos podem ser explorados para compressão. Redundância espacial : é a redundância dentro de uma dada imagem. Ex: imagem cuja maior parte é constituída de espaços em branco pode ser comprimida eficientemente. Redundância temporal: reflete a repetição de imagens subsequentes. Redes II - UNIP 19

20 Compressão de vídeo na Internet Os padrões de compressão MPEG estão entre as técnicas de compressão mais populares. Entre essas técnicas estão: MPEG 1 para vídeo com qualidade de CD-ROM (1,5 Mbps), a MPEG 2 para vídeo DVD de alta qualidade (3 a 6 Mbps) e a MPEG 4 para compressão de vídeos orientada para objeto. O padrão MPEG tem muito do padrão JPEG para compressão de imagens. Outros padrões populares: H.261 para vídeo, QUICKTIME da Apple e o Real Networks. Redes II - UNIP 20

21 Áudio e Vídeo de fluxo contínuo armazenados Servidores Web ou servidores de fluxo continuo especiais configurados para a aplicação de áudio e vídeo de fluxo continuo. A maior parte do trafego de fluxo utilizam o protocolo TCP (firewalls são muitas vezes configurados para bloquear o UDP). O RTSP (REAL-time streaming protocol protocolo de fluxo contínuo em tempo real) é um protocolo de domínio publico que provê interatividade com o usuário. Redes II - UNIP 21

22 Áudio e Vídeo de fluxo contínuo armazenados Transdutor Os usuário quase sempre requisitam reprodução de áudio e vídeo de fluxo contínuo por meio de um cliente Web, reproduzem e controlam o áudio/vídeo usando um transdutor, como o Windows Media Player. Redes II - UNIP 22

23 Áudio e Vídeo de fluxo contínuo armazenados O transdutor desempenha diversas funções, entre elas: Descompressão: Áudio e vídeo quase sempre são comprimidos ele deve descomprimir áudio e vídeo enquanto são reproduzidos. Eliminação de variação de atraso: A variação de atraso do pacote é a variabilidade dos atrasos origem-destino dos pacotes dentro da mesma corrente de pacotes. Uma vez que o áudio e vídeo têm de ser reproduzidos à mesma taxa em que foram gravados, o receptor colocará os pacotes recebidos em um buffer durante um curto período de tempo para eliminar essa variação. Redes II - UNIP 23

24 Acesso a áudio e vídeo por meio de um servidor Web A entrega de áudio e vídeo a partir de um servidor Web. Ele é um objeto comum dentro do sistema de arquivos de servidor, exatamente como os arquivos HTML e JPEG. Quando um usuário quer ouvir o arquivo de áudio, o hospedeiro do usuário estabelece uma conexão TCP com o servidor Web e envia uma requisição HTTP para o objeto. Ao receber a requisição, o servidor Web encapsula o arquivo de áudio em uma mensagem de resposta HTTP e devolve a mensagem de resposta para a conexão TCP. Redes II - UNIP 24

25 Acesso a áudio e vídeo por meio de um servidor Web A funcionalidade do lado do cliente é separada em duas partes: A tarefa do navegador é requisitar um metarquivo que fornece informações (por exemplo, uma url e o tipo de codificação, para que o transdutor adequado possa ser identificado) sobre o arquivo multimídia que deverá ser transmitido sobre HTTP. Este metarquivo é então enviado ao servidor HTTP e encaminhado ao transdutor através de HTTP. Redes II - UNIP 25

26 Acesso a áudio e vídeo por meio de um servidor Web Redes II - UNIP 26

27 Acesso a áudio e vídeo por meio de um servidor Web 1. O usuário clica sobre um hiperlink de um áudio/vídeo. O hiperlink não aponta diretamente para o arquivo de áudio/vídeo, mas para um metarquivo. O metarquivo contém o URL do arquivo de áudio/vídeo. A mensagem de resposta HTTP que encapsula o metarquivo contém uma linha no cabeçalho de tipo de conteúdo que indica a aplicação de áudio/vídeo especifico. 2. O browser cliente examina a linha de cabeçalho de tipo de conteúdo da mensagem de resposta, lança o transdutor associado e passa todo o corpo da mensagem de resposta (isto é, o metarquivo) para o transdutor. 3. O transdutor estabelece uma conexão TCP diretamente com o servidor HTTP e envia uma mensagem de requisição HTTP do arquivo de áudio/vídeo para a conexão TCP. O arquivo de áudio/vídeo é enviado ao transdutor dentro de uma mensagem de resposta HTTP. O transdutor exibe o arquivo de áudio/vídeo de fluxo continuo. Redes II - UNIP 27

28 Envio de multimídia de um servidor de fluxo continuo a uma aplicação auxiliar Como servidor de fluxo continuo pode ser proprietário, tal como os comercializados pela Real Networks e pela Microsoft, ou pode ser de domínio publico. Com um servidor de fluxo continuo, áudio e vídeo podem ser enviados por UDP (e não por TCP) usando protocolo da camada de rede que podem ser mais bem configurados para áudio/vídeo de fluxo continuo do que o HTTP. Redes II - UNIP 28

29 Envio de multimídia de um servidor de fluxo continuo a uma aplicação auxiliar Essa arquitetura requer dois servidores. Redes II - UNIP 29

30 Envio de multimídia de um servidor de fluxo continuo a uma aplicação auxiliar Nesta arquitetura há muitas opções para a entrega de áudio/vídeo do servidor de fluxo continuo ao transdutor. O áudio/vídeo é enviado por UDP e uma taxa constante igual à taxa de reprodução do receptor (que é a taxa codificada para o áudio/vídeo). É igual a primeira opção, mas o transdutor atrasa a reprodução de 2 a 5 segundos para eliminar a variação de atraso induzida pela rede. Redes II - UNIP 30

31 RTSP (Protocolo de fluxo contínuo em tempo real) Usuário que querem controlar a reprodução de mídia de taxa constante fazendo pausa na reprodução, reposicionando a reprodução em um ponto do tempo futuro ou passado, avançando ou atrasando a reprodução em modo rápido e assim por diante. Essa funcionalidade é semelhante a que um aparelho DVD oferece ao usuário quando assisti um DVD. Para permitir que um usuário controle a reprodução, o transdutor e o servidor precisam de um protocolo para trocar informações de controle de reprodução. O RTSP é este protocolo. Redes II - UNIP 31

32 RTSP (Protocolo de fluxo contínuo em tempo real) Mas o que ele não faz: O RTSP não define esquemas de compressão para áudio e vídeo. O RTSP não define como áudio e vídeo são encapsulado em pacotes para transmissão por uma rede. O RTSP não restringe o modo como a mídia de fluxo continuo é transportada, ela pode ser transportada por UDP ou TCP. O RTSP não restringe o modo como o transdutor armazena o áudio/vídeo. O áudio/vídeo pode ser reproduzido logo que começa a chegar ao cliente, após um atraso de alguns segundos, ou pode ser descarregado integralmente antes de ser reproduzido. O protocolo RTSP é semelhante ao protocolo FTP que usa uma porta para conexão e outra para transferência de arquivo. Redes II - UNIP 32

33 RTSP (Protocolo de fluxo contínuo em tempo real) O que o RTSP faz? O RTSP permite que um transdutor controle a transmissão de uma corrente de mídia. O RTSP é um protocolo fora da banda. As mensagens são enviadas fora da banda, ao passo que a corrente de mídia é considerada dentro da banda. Mensagens RTSP usam o número de porta 544, a corrente de mídia usa um numero diferente, as mensagens podem ser enviadas por TCP ou UDP. Redes II - UNIP 33

34 RTSP (Protocolo de fluxo contínuo em tempo real) Redes II - UNIP 34

35 RTSP (Protocolo de fluxo contínuo em tempo real) 1. O browser Web primeiramente solicita um arquivo de descrição da apresentação a um servidor Web. 2. O servidor Web encapsula o arquivo de descrição da apresentação em uma mensagem de resposta HTTP e envia a mensagem ao browser. 3. Quando recebe a mensagem de resposta HTTP, o browser invoca um transdutor (isto é, uma aplicação auxiliar) com base no campo de tipo conteúdo da mensagem. 4. Usando o método URL rtsp://, o transdutor e o servidor enviam um ao outro uma serie de mensagens RTSP. 5. O transdutor envia uma requisição RTSP SETUP e o servidor responde com uma mensagem RTSP OK. 6. O transdutor envia uma requisição RTSP PLAY, digamos, para áudio de baixa fidelidade e o servidor responde com uma mensagem RTSP OK. 7. Neste ponto o servidor de fluxo continuo bombardeia o áudio de baixa fidelidade para dentro de seu próprio canal dentro da banda. 8. Mais tarde, o transdutor envia uma requisição RTSP PAUSE e o servidor com uma mensagem RTSP OK. Redes II - UNIP 35

36 RTSP (Protocolo de fluxo contínuo em tempo real) Quando o usuário termina, o transdutor envia uma requisição RTSP TEARDOWN e o servidor confirma com uma resposta RTSP OK. <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> Redes II - UNIP 36

37 RTSP (Protocolo de fluxo contínuo em tempo real) Vamos examinar rapidamente RTPS propriamente dito. Segue um exemplo de uma sessão RTPS entre um cliente (C:) e um remente (S:). 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 Todas as respostas de requisições e respostas são em texto ASCII, o cliente emprega métodos padronizados (SETUP, PLAY, PAUSE, e assim por diante) e o servidor responde com códigos padronizados de resposta. Importante, o servidor RTSP monitora o estado do cliente para cada sessão RTSP em curso. Esse protocolo foi adotado pela Real Network. Redes II - UNIP 37

38 Protocolo IP Fazendo o melhor possível com o serviço de melhor esforço O protocolo da camada de rede IP, presta um serviço de melhor esforço, mas nada promete quanto a dimensão do atraso fim a fim para pacote individual ou quanto a dimensão da variação do atraso ou da perda de pacotes dentro da corrente de pacotes. A falta de garantias quanto ao atraso e a variação do atraso propõe desafios significativos ao projeto de aplicação de multimídia em tempo real, telefone por Internet e videoconferência em tempo real, pois são muito sensíveis ao atraso, à variação do atraso e à perda de pacotes. Redes II - UNIP 38

39 As limitações de um serviço de melhor esforço Para explorar este assunto usaremos exemplos de uma aplicação de telefone para Internet. Similar a uma aplicação de conferencia em vídeo de tempo real. O alto falante de telefone para internet gera um sinal de áudio que é formado por períodos alternados de falas e silêncios. Para conservar a banda, nossa aplicação de telefone para a internet gera pacotes apenas durante os períodos de fala. Durante o período de fala, o transmissor gera bytes em uma velocidade de bytes por segundo, e a cada 20 mseg o transmissor reúne os bytes em blocos. Assim o numero de bytes em blocos é (20 mseg)*(8.000 bytes/seg) = 160 bytes. Redes II - UNIP 39

40 As limitações de um serviço de melhor esforço Um cabeçalho especial é anexado a cada bloco. O bloco e seu cabeçalho são encapsulado em um segmento UDP, através da interface socket. Dessa forma, durante um período de fala, um segmento UDP é enviado a cada 20 mseg. Se cada pacote chega ao receptor e tem um pequeno atraso fim a fim constante, então pacotes chegam ao receptor periodicamente a cada 20 mseg durante um período de fala. Nessas condições ideais, o receptor pode reproduzir novamente cada bloco assim que chegarem. Redes II - UNIP 40

41 As limitações de um serviço de melhor esforço Mas infelizmente alguns pacotes podem ser perdidos e a maioria dos pacotes não terá o mesmo atraso fim a fim, mesmo em uma internet pouco congestionada. Por este motivo o receptor precisa ter mais cuidado para determinar (1) quando for o momento de reproduzir um bloco, e (2) o que fazer com um bloco perdido. Redes II - UNIP 41

42 As limitações de um serviço de melhor esforço Perda de Pacotes O segmento UDP é encapsulado em um datagrama IP. Enquanto ele vagueia pela rede, ele passa por buffers, isto é, filas nos roteadores, para poder alcançar os enlaces de saída. É possível que um ou mais dos buffers na rota entre o remente e o destinatário estejam lotados e não possam aceitar o datagrama IP. O datagrama será descartado e nunca chegará à aplicação receptora. Poderíamos resolver este problema usando o protocolo TCP, porem o mecanismo de retransmissão são inaceitáveis para aplicação interativas de áudio em tempo real. Pois aumenta o atraso fim a fim. Além disso, o controle de congestionamento TCP reduz a taxa de transmissão após a perda de pacotes, causando um forte impacto sobre a inteligibilidade da voz no receptor. Taxa de perdas entre 1 a 20% são toleráveis em telefonia IP. Redes II - UNIP 42

43 As limitações de um serviço de melhor esforço Atraso Fim a Fim Atraso fim a fim é o acúmulo de atrasos de processamento, de transmissão e de formação de filas nos roteadores, atrasos de propagação nos enlaces e atrasos de processamento em sistemas finais. Para aplicações altamente interativas, como o telefone por internet, atrasos fim a fim menores do que 150 milissegundos não são percebidos pelo ouvido humano. Atrasos entre 150 a 400 milissegundos podem ser aceitáveis, mas não são o ideal, e atrasos que excedem 400 milissegundos podem atrapalhar seriamente a interatividade em conversações por voz. Redes II - UNIP 43

44 As limitações de um serviço de melhor esforço Variação de Atraso Um componente crucial do atraso fim a fim são os atrasos aleatórios de fila nos roteadores. Por causa desses atrasos variáveis dentro da rede, o tempo decorrido entre o momento em que um pacote é gerado na fonte e o momento em que é recebido no destinatário pode variar de pacote para pacote. Este fenômeno é denominado variação de atraso. Felizmente, a variação de atraso frequentemente pode ser eliminado com a utilização de: números de sequencia, marcas de tempo e atraso de reprodução. Redes II - UNIP 44

45 Eliminação da variação de atraso no receptor para áudio Para uma aplicação de voz como telefone por internet ou áudio sob demanda, o receptor deve tentar prover reprodução sincronizada de porções de voz na presença de variação de atraso aleatório. Combinam-se três mecanismos: Preceder cada porção com um numero de sequencia: O remetente aumenta em um o número de sequência para cada um dos pacotes que gera. Preceder cada porção com uma marca de tempo: O remetente marca cada porção com o instante em que ela foi gerada. Atrasar a reprodução de porções no receptor: O atraso da reprodução das porções de áudio recebidas deve ser suficientemente longo para que a maioria dos pacotes seja recebido antes de seus tempos de reprodução programados. O atraso da reprodução pode ser fixado para todo o período de duração da sessão de áudio ou pode variar adaptativamente durante o período útil da sessão. Redes II - UNIP 45

46 Eliminação da variação de atraso no receptor para áudio Atraso de reprodução fixo Com a estratégia do atraso fixo, o receptor tenta reproduzir cada porção exatamente q milissegundos após a porção ter sido gerada. Assim se a marca de tempo de uma porção for t, o receptor reproduz a porção no tempo t+q. Em termos gerais, se grande variações no atraso fim a fim forem características, será preferível usar um q grande; por outro lado, se o atraso for pequeno e as variações no atraso também forem pequenas, será preferível usar um q pequeno, talvez menor do que 150 milissegundos. Redes II - UNIP 46

47 Eliminação da variação de atraso no receptor para áudio Redes II - UNIP 47

48 Atraso de reprodução adaptativo A maneira natural de tratar esse compromisso é estimar o atraso de rede e a variância de atraso de rede e ajustar o atraso de reprodução de acordo como resultado, no inicio de cada rajada de voz. Esse ajuste adaptativo de atrasos de reprodução no inicio das rajadas de voz fará com que os períodos de silêncio no receptor sejam comprimidos e alongados; contudo, compressão e alongamento de silêncio em pequenas quantidades não são percebidos durante a fala. Redes II - UNIP 48

49 Atraso de reprodução adaptativo Tomamos como base, descrevemos agora um algoritmo genérico que o receptor pode usar para ajustar seus atrasos de reprodução adaptativamente: Redes II - UNIP 49

50 Atraso de reprodução adaptativo O atraso de rede fim a fim do i-ésimo pacote é r i - t i, devido a variação de atraso da rede, esse atraso variará de pacote a pacote. Seja d i a estimativa do atraso de rede médio para a recepção do i-ésimo pacote. Essa estimativa é obtida das marcas de tempo como segue: d i = (1 u) d i-1 + u (r i t i ), onde u é uma constante fixa (por exemplo, u=0,01). Assim, d1 é uma média ajustada dos atrasos de rede observados r 1 t 1,..., r i - t i. A estimativa atribui maior peso aos atrasos de rede verificados mais recentemente do que aos atrasos de rede ocorridos no passado distante. Esse modelo de estimativa não deve ser tão fora do comum; uma ideia semelhante é usada para estimar os tempos de viagem de ida e volta no TCP. Redes II - UNIP 50

51 Áudio e Vídeo de Fluxo Continuo Armazenados Aplicações de fluxo contínuo de áudio/vídeo armazenados também usam, tipicamente, números de sequencia, marca de tempo e atraso de reprodução para aliviar ou até eliminar os efeitos de variação de atraso da rede. Há uma importante diferença entre áudio/vídeo interativo em tempo real e fluxo continuo de áudio/vídeo armazenado. Especificamente, fluxo continuo de áudio/vídeo pode tolerar atrasos significativamente maiores. De fato, quando um usuário requisita um clipe de áudio/vídeo, é provável que ele ache aceitável esperar 5 segundos ou mais antes que a reprodução se inicie. Redes II - UNIP 51

52 Recuperação de Perdas de Pacotes Como preservar uma qualidade aceitável de áudio na presença da perda de pacotes. Esses esquemas são denominados esquemas de recuperação de perdas. Definimos aqui a perda de pacotes em um sentido amplo: Um pacote será considerado se nunca chegar ao receptor ou se chegar após o tempo de reprodução programado. Redes II - UNIP 52

53 Recuperação de Perdas de Pacotes Devido a essas considerações, aplicações de telefone por Internet frequentemente usam algum tipo de esquema de prevenção de perda. Dois desses esquemas são: a FEC e a INTERCALAÇÂO. Redes II - UNIP 53

54 Recuperação de Perdas de Pacotes FEC (Correção de erros de repasse) Basicamente a FEC (Forward Error Correction) adiciona informações redundantes à corrente de pacotes original. Ao custo de aumentar marginalmente a taxa de transmissão do áudio da corrente. A informação redundante pode ser usada para reconstruir aproximações ou versões exatas de alguns pacotes perdidos. Dois mecanismos da FEC: Redes II - UNIP 54

55 Recuperação de Perdas de Pacotes FEC (Correção de erros de repasse) O primeiro mecanismo envia uma porção redundante codificada após cada n porções. A porção redundante é obtida por XOR das n porções originais. Desse modo, se qualquer pacote do grupo n + 1 pacotes for perdido, o receptor poderá reconstruir integralmente o pacote perdido. Mas se dois pacotes forem perdidos? Mantendo n + 1 (o tamanho do grupo) pequeno, uma grande fração dos pacotes perdidos pode ser recuperada, quando a perda não for excessiva. Redes II - UNIP 55

56 Recuperação de Perdas de Pacotes FEC (Correção de erros de repasse) Basicamente a FEC (Forward Error Correction) adiciona informações redundantes à corrente de pacotes original. Ao custo de aumentar marginalmente a taxa de transmissão do áudio da corrente. A informação redundante pode ser usada para reconstruir aproximações ou versões exatas de alguns pacotes perdidos. Dois mecanismos da FEC: Redes II - UNIP 56

57 Recuperação de Perdas de Pacotes O segundo mecanismo é enviar uma corrente de áudio de resolução mais baixa como informação redundante. (A corrente nominal poderia ser uma codificação PCM de 64 kbps e a corrente de qualidade mais baixa, uma codificação GSM de 13 kbps). Redes II - UNIP 57

58 Intercalação Redes MultiMídia Recuperação de Perdas de Pacotes Como uma alternativa à transmissão redundante. Uma aplicação telefone por internet pode enviar áudio intercalado. Redes II - UNIP 58

59 Recuperação de Perdas de Pacotes Reparação de correntes de áudio danificadas realizada no receptor Esquema de recuperação baseadas no receptor tentam produzir um substituto para um pacote perdido semelhante ao original. Isso é possível desde que os sinais de áudio, em especial os de voz, exibam grandes índices de semelhança entre si dentro de períodos de tempo reduzidos. Essas técnicas funcionam para taxas de perda relativamente pequenas (menos de 15 por cento) e para pacotes pequenos (4 40 milissegundos). De (5 100 milissegundos) essa técnica causa pane. Redes II - UNIP 59

60 Distribuição de Multimídia: redes de distribuição de conteúdo Filosofia da CDN: Se o cliente não pode vir até o conteúdo (porque o caminho de melhor esforço do cliente ao servidor não pode suportar vídeo de fluxo continuo), então o conteúdo deve ser levado até o cliente. Redes II - UNIP 60

61 - CDN Distribuição de Multimídia: redes de distribuição de conteúdo Para as CDN s os clientes pagantes não são mais as ISPs, mas as provedoras de conteúdo. Uma provedora de conteúdo que tenha um vídeo para distribuir (tal como a CNN) paga a uma empresa CDN (como a Akamai) para levar seu vídeo até os usuários requisitantes com os menores atrasos possíveis. Redes II - UNIP 61

62 - CDN Distribuição de Multimídia: redes de distribuição de conteúdo Uma empresa CDN provê seu serviço de distribuição de conteúdo da seguinte maneira: A empresa CDN instala centenas de servidores CDN por toda a internet. Em geral a empresa instala seus servidores CDN em uma central de dados, que muitas vezes estão em ISPs de nível mais baixo. Próximo a redes de acesso ISP e aos clientes. A CDN duplica o conteúdo de seu cliente nos servidores CDN. Sempre que seu cliente atualiza seu conteúdo, a CDN redistribui o conteúdo aos servidores CDN. A empresa CDN provê um mecanismo que entrega, a um cliente Web que tenha requisitado, conteúdo pelo servidor CDN que melhor possa atendê-lo. Esse servidor pode ser o que estiver mais próximo do cliente (talvez no mesmo ISP) ou pode ser um servidor CDN cujo caminho até o cliente esta livre de congestionamento. Redes II - UNIP 62

63 - CDN Distribuição de Multimídia: redes de distribuição de conteúdo Redes II - UNIP 63

64 Protocolos para aplicações interativas em tempo real Protocolo de tempo rela (RTP) O lado do remente de uma aplicação de multimídia anexa campos de cabeçalho às porções de áudio/vídeo antes de passa-las à camada de transporte. Esses campos de cabeçalho contêm: Número de sequência e marcas de tempo. O RTP pode transportar formatos comuns como PCM, GSM E MP3 para som e MPEG e H.263 para vídeo. Também é complementar a outros importantes protocolos interativos de tempo real, entre eles SIP e H.323. Redes II - UNIP 64

65 Protocolos para aplicações interativas em tempo real O básico do RTP. O RTP comumente roda UDP. O lado receptor extrai o pacote RTP do segmento UDP, em seguida extrai a porção de mídia do pacote RTP e então passa a porção para o transdutor para decodificação e apresentação. Redes II - UNIP 65

66 Protocolos para aplicações interativas em tempo real O básico do RTP. Como exemplo: considere a utilização do RTP para transportar voz. Suponha que a fonte de voz esteja codificada (isto é, amostrada, quantizada e digitalizada) em PCM a 64 kbps. Suponha também que a aplicação colete os dados codificados em porções de 20 milissegundos, isto é, 160 bytes por porção. O lado remetente precede cada porção dos dados de áudio com um cabeçalho RTP que contém o tipo de codificação de áudio, um número de sequência e uma marca de tempo. Redes II - UNIP 66

67 Protocolos para aplicações interativas em tempo real O básico do RTP. Como exemplo: considere a utilização do RTP para transportar voz. O tamanho do cabeçalho RTP é normalmente 12 bytes. A porção de áudio, juntamente com o cabeçalho RTP, forma o pacote RTP. O pacote RTP é, então enviado para dentro do socket de interface UDP. No lado receptor, a aplicação recebe o pacote RTP da interface do seu socket. A aplicação extrai a porção de áudio do pacote RTP e usa os campos de cabeçalho do pacote RTP para decodificar e reproduzir adequadamente a porção de áudio. Redes II - UNIP 67

68 Protocolos para aplicações interativas em tempo real O básico do RTP. Como exemplo: considere a utilização do RTP para transportar voz. Enfatizamos que o RTP não fornece nenhum mecanismo que assegure a entrega de dados a tempo nem fornece outras garantias de qualidade de serviço (QoS). O RTP permite que seja atribuída a cada fonte (uma câmera ou microfone) sua própria corrente independente de pacotes RTP. Por exemplo, uma videoconferência entre dois participantes, quatro correntes RTP pode ser aberta: duas correntes para transmitir o áudio (uma em cada direção) e duas correntes para transmitir o vídeo (uma em cada direção). Algumas aplicações conjugam áudio e vídeo pelo codificador, somente uma corrente RTP é formada. Redes II - UNIP 68

69 Campos de Cabeçalho do Pacote RTP Tipo de Carga Útil Número de Sequencia Marca de Tempo Identificador de Sincronização da Fonte Campos variados O campo do número de sequencia tem 16 bits de comprimento, ele é incrementado de uma unidade a cada pacote RTP enviado e pode ser usado pelo receptador. O campo de marca de tempo tem 32 bits de comprimento, ele reflete o instante da amostragem do primeiro byte no pacote RTP. O campo identificador de sincronização da fonte (SSRC), ele tem 32 bits de comprimento e identifica a fonte da corrente RTP, cada sessão RTP tem um SSRC distinto. Redes II - UNIP 69

70 Protocolos para aplicações interativas em tempo real Protocolo de controle RTP (RTCP) RTCP, um protocolo que uma aplicação multimídia pode usar juntamente com o RTP. O RTCP monitora a entrega dos dados e a qualidade de serviços fim a fim. Tanto o RTP quanto o RTCP são protocolos cliente/servidor que negociam um conjunto apropriado de parâmetros para entrega de acordo com o meio físico. Redes II - UNIP 70

71 SIP Redes MultiMídia Protocolos para aplicações interativas em tempo real O SIP é um protocolo simples que faz o seguinte: Provê mecanismo para estabelecer chamadas entre dois interlocutores por uma rede IP. Permite que quem chama avise ao que é chamado que quer iniciar uma chamada. Permite que os participantes concordem com a codificação da mídia. É também que encerrem as chamadas. Provê mecanismos que permitam a quem chama determinar o endereço IP corrente de quem é chamado. Os usuários não tem um endereço IP único, fixo, porque receber endereços dinamicamente (usando DHCP) e porque podem ter vários equipamentos IP, cada um com um endereço IP diferente. Provê mecanismos para gerenciamento de chamadas, tais como adicionar novas correntes de mídia, mudar a codificação, convidar outros participantes, tudo durante a chamada, e ainda transferir e segurar chamadas. Redes II - UNIP 71

72 - SIP Protocolos para aplicações interativas em tempo real Estabelecendo uma chamada para um endereço IP conhecido Redes II - UNIP 72

73 Protocolos para aplicações interativas em tempo real SIP O que aprendemos nesse exemplo simples: O SIP é um protocolo fora de banda, às mensagens SIP são enviadas e recebidas em portas diferentes das utilizadas para enviar e receber dados da mídia. Em segundo lugar, as próprias mensagens SIP podem ser lidas em ASCII e são parecidas com mensagens HTTP. Em terceiro lugar, o SIP requer que todas as mensagens sejam reconhecidas, portanto, ele pode executar sobre UDP e TCP. Redes II - UNIP 73

74 Protocolos para aplicações interativas em tempo real SIP Endereço SIP Alguns endereços SIP são parecidos com endereços de a infraestrutura SIP então rotearia a mensagem ao dispositivo IP que Bob está usando no momento em questão. Uma característica interessante de endereços SIP é que eles podem ser incluídos em páginas Web. Redes II - UNIP 74

75 Protocolos para aplicações interativas em tempo real SIP Mensagens SIP Alice que iniciar uma chamada telefônica IP com Bob e, desta vez, ela conhece somente o endereço SIP de Bob, bob@domain.com, e não conhece o numero IP do dispositivo que Bob está corretamente usando. A mensagem seria algo como: Redes II - UNIP 75

76 Protocolos para aplicações interativas em tempo real SIP Na linha INVITE inclui a versão SIP, assim como uma requisição HTTP. Sempre que uma mensagem SIP passa por um dispositivo SIP, ele anexa um cabeçalho Via que indica o IP do dispositivo. Inclui cabeçalho de FROM e TO. Inclui CALL ID, identificador de chamadas, que identifica a chamada exclusivamente (semelhante mensagem ID no ), indica em bytes o comprimento da mensagem. E finalmente um carriage return e um life feed Redes II - UNIP 76

77 Protocolos para aplicações interativas em tempo real H.323 Como alternativa ao SIP, o H.323 é um padrão popular para audioconferência e videoconferência entre sistemas finais na internet. O padrão abrange a maneira como sistemas finais ligados à internet se comunicavam com telefones ligados às redes normais de telefonia de comutação de circuito. O gatekeeper H.323 é um dispositivo semelhante a uma entidade registradora SIP. Redes II - UNIP 77

78 H.323 Protocolos para aplicações interativas em tempo real O padrão H.323 é uma especificação guarda chuva que inclui as seguintes especificações: Uma especificação para o modo como o terminais negociam codificações comuns de áudio/vídeo. Como o H.323 suporta uma variedade de padrões de codificação de áudio/vídeo, é preciso um protocolo para permitir que os terminais comunicantes cheguem a um acordo quando a uma codificação comum. Uma especificação para o modo como porções de áudio e vídeo são encapsulados e enviados à rede. Em particular, para essa finalidade o H.323 impõe o RTP. Uma especificação para o modo como terminais se comunicam com seus respectivos gatekeeper. Uma especificação para o modo como telefones por internet se comunicam por meio do gateway com os telefones comuns na PSTN. Redes II - UNIP 78

79 H.323 Redes II - UNIP 79

80 H.323 Protocolos para aplicações interativas em tempo real No mínimo, cada terminal H.323 tem de suportar o padrão de compressão de voz G.711, ele usa PCM para gerar voz digitalizada a 56 kbps ou 64 kbps. Se ele suportar vídeo, então ele deverá (no mínimo) suportar o padrão de vídeo QCIF H.261 (176 x 144 pixels). O H.323 é um padrão guarda-chuva abrangente que, além dos padrões e protocolos, impõe um protocolo de controle H.245, um canal de sinalização Q.931 e um protocolo RAS para registro no gatekeeper. Redes II - UNIP 80

81 H.323 Protocolos para aplicações interativas em tempo real Concluindo com as diferenças entre H.323 e SIP. O H.323 é um conjunto de protocolos completo, integrado verticalmente, para conferencia multimídia, sinalização, registro, controle de admissão, transporte e codecs. O SIP, por outro lado, aborda apenas inicialização e gerenciamento de sessão e é um componente separado. O SIP trabalha com RTP, mas não o impõe. Trabalha com codecs de voz G.711 e codecs de vídeo QCIF H.261, mas não os impõe. Pode ser combinado com outros protocolos e serviços. O H.323 vem da ITU (telefonia), enquanto o SIP vem da IETF e toma emprestado muitos conceitos da Web, o DNS e do da Internet. O H.323, como é um padrão guarda chuva, é grande e complexo. O SIP usa o principio da simplicidade. Redes II - UNIP 81

82 Bibliografia Redes II - UNIP 82