Capítulo 6: Redes Multimídia
Objetivos do Capítulo:U entender os requisitos de
serviço para redes com multimídia
Patraso
Ptaxa de transmissão
Pperda
U aprender como aproveitar
o máximo do serviço de melhor esforço da Internet
U Aprender como a
Internet poderá evoluir para um melhor desempenho dos serviços multimídia
Resumo do capítulo:
U aplicações de rede com
multimídia
U aúdio e vídeo de tempo contínuo
armazenados PRTSP
U aplicações interativas de
tempo-real
PExemplo: telefonia na Internet
U RTP U H.323 e SIP U além do melhor esforço
Pprogramando e verificando Pserviços integrados Pserviços diferenciados
Multimídia em Redes
Características Fundamentais: U Tipicamente sensíveis ao atraso.U Mas tolerante a perdas:
perdas esparsas causam pequenas falhas que podem passas desapercebidas.
U Antítese de dados
(programas , informações bancárias, etc.), que não toleram falhas mas aceitam atrasos sem problemas.
U Multimídia também é
chamada de “mídia de tempo contínuo”
Classes de aplicações MM:
U Aúdio e vídeo de tempo
contínuo armazenados
U Audío e vídeo de tempo
contínuo ao vivo
U Vídeo interativo em
tempo-real
Multimídia em redes (2)
Aplicações MM com aúdio e vídeo armazenados
Clientes solicitam arquivos com aúdio e vídeo de servidores, recebem a informação pela rede e a apresentam
UInterativo: o usuário pode
controlar a operação (similar a um VCR: pause, resume, fast forward, rewind, etc.)
UAtraso: a partir do pedido do
cliente até o início da apresentação pode ser de 1 a 10 segundos
Tempo-real unidirecional:
U similar à TV convencional, mas a
transferência de informação é feita pela Internet
U Não interativo, apenas escutar e
ver
Tempo-Real Interativo:
U Conferência de aúdio ou de vídeo U Mais exigente nos requisitos de
atraso que o tempo real unidirecional por causa da necessidade de interatividade em tempo real
U Vídeo: < 150 ms aceitável U Aúdio: < 150 ms bom, <400 ms
aceitável
Multimídia em redes (3): desafios
U Arquitetura TCP/UDP/IPfornece melhor esforço, não garantias sobre o atraso ou sobre a variação de atraso.
PAplicações de tempo contínuo
com atrasos inicias de 5-10 segundos são comuns hoje me dia, mas o desempenho deteriora se os enlaces estão congestionados (transoceânicos)
PAplicações Interativas e,m
tempo real têm requisitos rígidos para atraso de pacotes e variação de atraso (jitter).
PJitter é a variabilidade do
atraso de pacotes dentro do mesmo feixe de pacotes.
U Projeto de aplicações
multimídia seria fácil se houvesse várias classes de serviço.
PMas na Internet pública
todos os pacotes recebem igual tratamento.
PPacotes contendo aúdio e
vídelo interativo de tempo real permanecem nas filas, como todos os outros.
U Esforços vêm sendo
desenvolvidos para prover serviços diferenciados.
Multimídia em redes (4):
aproveitando ao máximo o “melhor esforço”
Para reduzir o impacto do serviçode melhor esforço da Internet, nós podemos:
U Usar UDP para evitar o TCP e
sua fase de partida lenta…
U Armazenar o conteúdo no
cliente e controlar a apresentação para remediar o jiter
U Podemos acrescentar marcas
de tempo nos pacotes para que o receptor saiba quando reproduzí-los.
U Adaptar o nível de
compressão à taxa de transmissão disponível
U Nós podemos transmitir
pacotes redundantes para atenuar os efeitos das perdas de pacotes. ÎNós discutiremos todos
esses “truques”.
Como a Internet deveria evoluir para
suportar melhor as aplicações multimídia?
Filosofia de serviços Integrados:U Mudar os protocolos da
Internet de forma que as aplicações possam reservar uma banda de transmissão fim-a-fim
PNecessita de um novo protocolo
que reserva banda de transmissão
PDeve modificar as regras de
escalonamento nos roteadores para poder honrar às reservas
PAplicação deve fornecer à rede
uma descrição do seu tráfego e deve posteriormente respeitar esta descrição.
U Exige um novo e complexo
software nos hosts e nos
Filosofia de serviços Diferenciados
Exige menos mudanças na infra-estrutura da Internet, embora forneça serviços de primeira e de segunda classe.
UDatagramas são marcados. UUsuários pagam mais para enviar e
receber pacotes de primeira classe.
UISPs pagam mais aos provedores de
backbone para enviar e receber pacotes de primeira classe.
Filosofia Laissez-faire
U Não há reservas, nem
marcações de datagramas
U Quando a demanda aumenta,
mais banda de transmissão deve ser provida
U Coloque armazenadores de
conteúdo nas bordas da rede:
PISPs e provedores de backbone acrescentam caches PProvedores de conteúdo armazenam conteúdo em nós CDN
PP2P: escolhe o parceiro mais
próximo com o conteúdo desejado
Redes privadas virtuais (VPNs)
U Reserva blocos permanentes
de banda de transmissão para empresas.
U Roteadores distinguem o
tráfego de cada VPN usando endereços IP
U Roteadores usam esquemas
de escalonamento especiais para fornecerem a banda de transmissão reservada.
Como a Internet deveria evoluir para
suportar melhor as aplicações multimídia?
Aúdio e Vídeo Armazenados
Mídia de tempo contínuo armazenada:
UArquivos de Aúdio e de
Vídeo são armazenados em servidores
UUsuários solicitam os
arquivos de aúdio e de vídeo por demanda. UAúdio/vídeo são aprsentandos, digamos, 10 s após o pedido. UInteratividade (pausa, deslocamento da apresentação) é permitido.
Transdutor de Mídia (player): Premove jitter Pdescomprime Pcorreção de erros Pinterface gráfica de
usuário com controles para interatividade
U Plug-ins podem ser usados
para embutir o transdutor de mídia na janela de um browser.
Informações de tempo contínuo em
servidores Web (1)
U Os arquivos de aúdio e devídeo são armazenados em servidores Web
abordagem ingênua
U browser pede o arquivo com
uma mensagem HTTP do tipo pedido
U Servidor Web envia o arquivo
na mensagem HTTP do tipo resposta
U O cabeçalho “content-type”
indica uma codificação apropriada para aúdio e vídeo
U browser dispara o transdutor
de mídia e passa o arquivo para ele
U transdutor de mídia apresenta
o arquivo
• Maior problema: o transdutor de mídia interage com o servidor WEB através do Web browser que atua como intermediário.
cliente servidor
Alternativa: estabelecer conexão entre o servidor e o transdutor
U browser Web solicita e recebe
um meta arquivo
(um arquivo descrevendo o objeto) ao invés de receber o próprio arquivo;
U O cabeçalho “Content-type”
indica uma específica aplicação de aúdio e vídeo
U Browser dispare o transdutor
de mídia e passa o meta arquivo para ele
U Transdutor estabelece uma
conexão TCP com o servidor e envia a ele a mensagem HTTP do tipo pedido.
Algumas preocupações:
U O transdutor de mídia se
comunica usando HTTP, que não foi projetado mpara suportar comandos de controle de apesentação
U Pode desejar enviar o aúdio
e o vídeo sobre UDP
Informações de tempo contínuo em
servidores Web (2)
(1) pedido/resposta HTTP por um meta arquivo
(3) arquivo solicitado é enviado usando o HTTP (2) meta arquivo
transdutor de mídia
Obtendo o vídeo de um servidor
dedicado
U Esta arquitetura permite o
uso de outros protocolos (além do HTTP) entre o servidor e o transdutor de mídia
U Pode também usar UDP ao
invés do TCP
(1) HTTP pedido/resposta para o arquivo descritor da apresentação (2) arquivo descritor (3) arquivo de aúdio e vídeo pedido e enviado cliente servidores transdutor de mídia servidor de vídeo
Opções ao utilizar um servidor de vídeo
U Enviar a uma taxa constante sobre
UDP. Para reduzir os efeitos do jitter, armazenar e exibir com uma atraso entre 1 e 10s. Taxa de transmissão = d, igual à taxa de codificação. Taxa de enchimento x(t) é igual a d, ecxeto quando há perdas.
U Use TCP, e envie na máxima taxa
possível sobre TCP; TCP retransmite quando um erro é encontrado; x(t) agora flutua, e pode tornar-se muito maior que d. Decodificador deve usar um buffer muito maior para compensar a taxa de entrega do TCP. buffer cliente área com vídeo taxa de chegada = x(t) da rede taxa de leitura = d decodificação e apresentação
Real Time Streaming Protocol: RTSP
HTTPU Projetistas do HTTP tinham
mídias fixas em mente: HTML, imagens, applets, etc.
U HTTP não pretende tratar
mídia contínua armazenada (isto é, aúdio, vídeo, apresentações SMIL, etc.)
RTSP: RFC 2326
U Protocolo de aplicação do
tipo cliente-servidor.
U Permite ao usuário
controlar apresentações de mídia contínua: voltar ao início, avançar, pausa, continuar, seleção de trilha, etc…
O que ele não faz:
U não define como o aúdio e o
vídeo é encapsulado para transmissão sobre a rede
U não restringe como a mídia
contínua é transportada: pode usar UDP ou TCP
U não especifica como o
receptor armazena o aúdio e o vídeo
RealNetworks
U Servidor e transdutor usam
RTSP para enviar informações de controle de um para o outro
RTSP: controle for a da banda
FTP usa um canal de controle “fora-da-banda”: U Um arquivo é transferido sobre um canal. U Informação de controle (mudanças de diretório, remoção de arquivos, trocas de nomes, etc.) é enviada sobre uma conexão TCP separada.
U Os canais
“dentro-da-banda”e “fora-da-banda”usam diferentes números de portas.
Mensagens RTSP també são enviadas “for a-da-banda”:
U As mensagens de controle RTSP
usam diferentes números de portas em relação ao fluxo de dados de mídia contínua, e, portanto, são enviados “fora-da-banda”.
U O fluxo de dados de mídia
contínua cuja estrutura de pacotes não é definida pelo RTSP, é considerada “dentro-da-banda”.
U Se as mensagens do RTSP
devessem usar os mesmos números de portas do fluxo de mídia contínua, então as mensagens RTSP seriam consideradas como “intercaladas” com o fluxo de mídia contínua.
Iniciação do RTSP e controles de entrega
U Cliente obtém uma descrição da
apresentação multimídia, que pode consistir de vários fluxos de dados.
U O browser chama o transdutor de mídia
(aplicação auxiliar) com base no tipo de conteúdo da descrição da apresentação.
U A descrição da apresentação inclui
referências aos fluxos de mídia usando o método rtsp://
U Transdutor envia o comando RTSP
SETUP; servidor envia a resposta RTSP SETUP.
U Transdutor envia o comando RTSP PLAY;
servidor envia a resposta RTSP PLAY.
U O servidor de mídia descarrega o fluxo de
mídia.
U Transdutor envia o comando RTSP PAUSE;
o servidor envia a resposta RTSP PAUSE.
U Transdutor envia o comando RTSP
TEARDOWN; servidor envia a resposta RTSP TEARDOWN. HTTP GET SETUP PLAY media stream PAUSE TEARDOWN media player Web server media server Web browser client server presentation desc. Transdutor
de mídia Servidorde mídia
cliente servidor descr. apresent. fluxo de mídia
Exemplo de Meta-arquivo
<title>Twister</title> <session><group language=en lipsync>
<switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>
Sessão RTSP
U Cada sessão RTSP tem umidentificador de sessão, que é escolhido pelo servidor.
U O cliente inicia a sessão com o
comando SETUP, e o servidor responde ao comando com um identificador.
U O cliente repete o
identificador de sessão em cada comando, até que o cliente encera a sessão com o comando TEARDOWN.
U O número de porta do RTSP é
554.
U RTSP pode ser usado sobre
UDP ou TCP. Cada mensagem RTSP pode ser enviada numa conexão TCP separada.
RTSP: exemplo de mensagens
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0-C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231
RTSP: cache de dados
U O cache de mensagens deresposta RTSP faz pouco sentido.
U Mas é desejável armazenar
fluxos de mídia contínua próximos ao cliente.
U Muito do controle de cache do
HTTP/1.1 foi adotado pelo RTSP.
PCabeçalhos e controle de
cache podem ser acrescentados às mensagens RTSP SETUP, sejam comandos ou respostas:
• If-modified-since: , Expires: , Via: , Cache-Control:
U O servidor de cache pode manter
somente segmentos de um dado fluxo de mídia.
PO servidor de cache pode
começar a servir um cliente com dados do seu cache local, e então conectar o servidor para obter material complementar, se possível sem introduzir pausas indevidas no cliente.
U Quando o servidor original está
enviando um fluxo de dados de mídia contínua para um cliente e este fluxo passa por um servidor de cache, o servidor pode usar o TCP para obter os dados; mas o servidor intermediário ainda envia as mensagens de controle RSTP para o servidor original.
Aplicações interativas em
tempo-real
U telefone PC-a-PC U PC-a-telefone PDialpad PNet2phone U videoconferência U WebcamsU Vamos agora examinar um
produto do tipo telefone PC-a-PC da Internet em detalhes
Telefonia Internet sobre
melhor-esforço (1)
Melhor esforço
U atraso de pacotes, perdas e
variação de atraso (jitter) Exemplo de telefone Internet
U agora vamos examinar como
atrasos de pacotes, perdas e jitter são muitas vezes tratados num exemplo de telefonia IP.
U As aplicações de telefonia
na Internet geram pacotes durante momentos de atividade da voz
U taxa de bits é 64 kbps nos
intervalos de atividade U durante os intervalos de atividade a aplicação produz um bloco de 160 bytes a cada 20 ms (8 kbytes/s * 20 ms) U cabeçalho é acrescentado
ao bloco; então bloco mais cabeçalho sáo encapsulados num pacote UDP e enviados
U alguns pacotes podem ser
perdidos e o atraso de pacote irá flutuar.
U receptor deve determinar
quando reproduzir um bloco e determinar o que fazer com um bloco faltante
Telefonia Internet (2)
perda de pacotes
U O segmento UDP é
encapsulado num datagrama IP
U datagrama pode ser
descartado por falta de espaço num roteador
U TCP pode eliminar perdas, mas
Pretransmissões aumentam o
atraso
PO controle de
congestio-namento do TCP limita a taxa de transmissão
U Pacotes redundantes podem
ajudar
atraso fim-a-fim
acúmulo dos atrasos de trans-missão, propagação, proces-samento e atrasos de filas
U mais que 400 ms de atraso
fim-a-fim compromete a interatividade; quanto menor o atraso melhor variação de atraso
U considere dois pacotes
consecutivos num intervalo de atividade
U espaçamento inicial é de
20 ms, mas o espaçamento no receptor pode ser maior ou menor que 20 ms removendo o jitter
U número de seqüência U marcas de tempo U atrasando a reprodução
Telefonia Internet (3): atraso de
reprodução fixo
U Receptor tenta reproduzir
cada bloco exatamente q ms depois que o bloco é gerado.
PSe o bloco tem marca de
tempo t, receptor usa o bloco no instante t+q .
PSe o bloco chega após o
instante t+q, receptor o descarta.
U Números de seqüência não
são necessários.
U Estratégia permite pacotes
pedidos.
U Escolha do valor de q:
Pq grande: menos perda de
pacotes
Pq pequeno: melhor controle
da interatividade
Telefonia Internet (4): atraso de
reprodução fixo
U Transmissor gera pacotes a cada 20 ms durante os intervalos de
atividade.
U Primeiro pacote é recebido no instante r U Primeira programação de reprodução: começa em p U Segunda programação de reprodução: começa em p’
packets time packets generated packets received loss r p p' playout schedule p - r playout schedule p' - r pacotes gerados pacotes recebidos perda progr. reprodução p - r progr. reprodução p’ - r tempo pacotes
Atraso de reprodução adaptativo (1)
pacote ésimo -o receber após rede na atraso do estimativa pacote ésimo -o para rede da atraso receptor no o reproduzid é pacote o qual no instante receptor pelo recebido é pacote o qual no instante pacote ésimo do tempo de marca i d i t r i p i r i t i i i i i i = = − = = − =•Estima o atraso da rede e ajusta o atraso de reprodução no início de cada intervalo de atividade.
• Intervalos de silêncio são aumentados e diminuídos.
• Blocos ainda são gerados a cada 20 ms nos intervalos de atividade.
Estimativa dinâmica do atraso médio no reeptor: ) ( ) 1 ( i1 i i i ud ur t d= − −+ − ondeu é uma constante fixa (ex., u = 0,01).
É também usual estimar a variância média do atraso, vi :
|
|
)
1
(
i1 i i i iu
v
u
r
t
d
v
=
−
−+
−
−
As estimativas de die visão calculadas para cada pacote recebido, embora elas
sejam usadas apenas no início de um intervalo de atividade.
Para o primeiro pacotes de um intervalo de atividade, o instante de reprodução é: i i i i
t
d
Kv
p
=
+
+
onde K é uma constante positiva. Para este mesmo pacote, o atraso de reprodução é:
i i
i
p
t
q
=
−
Para o pacote j no mesmo intervalo de atividade, o pacote deve ser reproduzido em:
i j
j
t
q
p
=
+
Atraso de reprodução adaptativo (2)
Como saber se um pacote é o primeiro de um intervalo de atividade:
U Se nunca houvesse perdas o receptor poderia simplesmente olhar
nas marcas de tempo sucessivas.
PSe a diferença de marcas de tempo sucessivas for maior que 20 ms, então temos o início de um intervalo de atividade.
U Mas porque as perdas são possíveis, o receptor deve olhar
tanto as marcas de tempo como os números de seqüência dos pacotes.
PSe a diferença de marcas de tempo sucessivas for maior que 20 ms e não há pulos nos números de seqüência então tem-se o início de um intervalo de atividade.
Atraso de reprodução adaptativo (3)
Recuperação de perdas de pacotes (1)
U Perdas: pacote nunca chega ou
chega depois do seu tempo de reprodução programado
correção de erro de envio (FEC): esquema simples
U para cada grupo de n blocos
cria um bloco redundante realizando uma operação OU exclusivo entre os n blocos originais
U envia os n+1 blocos, aumentando
a banda passante por um fator de 1/n.
U pode reconstruir os n blocos
originais se houver no máximo um bloco perdido nos n+1 blocos enviados
U Atraso de reprodução
precisa ser definido para receber todos os n+1 pacotes
U Compromisso:
Paumentar n, menor
disperdício de banda
Paumentar n, maior atraso
de reprodução
Paumentar n, maior a
probabilidade que dois ou mais blocos sejam perdidos
2o, esquema FEC
• enviar um fluxo de menor qualidade como “carona” • envia fluxo de aúdio de menor resolução como a informação redundante • por exemplo, um fluxo PCM nominal a 64 kbps e um fluxo GSM redun-dante a 13 kbps. • Transmissor cria pacote tomando o bloco n do fluxo nominal e anexando a ele o bloco (n-1) do fluxo redun-dante
• Sempre que ocorre perda não-consecutiva, o receptor pode esconder a perda.
• Apenas dois pacotes precisam ser recebidos antes do início da reprodução
• Pode também anexar os blocos (n-1) e (n-2) do fluxo
Recuperação de perdas de pacotes (2)
Fluxo original
Redundância
Perda de Pacote
Fluxo reconstruído
Intercalação
U blocos são quebrados em
unidades menores
U por exemplo, 4 blocos de
5 ms cada
U intercalar os blocos como
mostrado no diagrama
U pacote agora contém
unidades menores de
diferentes blocos U Remontar os blocos no
receptor
U Se o pacote é perdido,
ainda resta mais de cada bloco
Recuperação de perdas de pacotes (3)
Fluxo original
Fluxo intercalado
Perda de pacote
Recuperação pelo receptor de fluxos de aúdio danificados
U produzir uma substituição
para um pacote perdido que seja similar ao pacote original
U pode produzir bons
resultados para baixas taxas de perdas e pacotes pequenos (4-40 ms)
U estratégia mais simples:
repetiçãon
U estratégia mais complexa:
interpolação
Recuperação de perdas de pacotes (4)
Real-Time Protocol (RTP)
U RTP especifica uma
estrutura de pacotes que transportam dados de aúdio e vídeo: RFC 1889. U pacote RTP oferece Pidentificação do tipo de carga Pnumeração da seqüência de pacotes Pmarcas de tempo
U RTP roda nos sistemas
terminais. U os pacotes RTP são encapsulados em segmentos UDP U Interoperabilidade: se duas aplicações de telefonia IP usam RTP, então elas podem ser capazes de trabalhar juntas
RTP roda em cima do UDP
As bibliotecas do RTP fornecem uma interface de
camada de transporte que extendem o UDP:
• número de portas, endereços IP
• verificação de erros dentro dos segmentos
• identificação do tipo de carga
• numeração da seqüência de pacotes
• marcas de tempo
AplicaçãoEnlace Física camada de transporte
RTP: Exemplo
U Considere enviar 64 kbps de voz codificada em PCM sobre RTP.U A aplicação reúne dados
codificados em blocos, por exemplo, a cada 20 ms = 160 bytes por bloco.
U O bloco de aúdio, junto com
o cabeçalho RTP forma o pacote RTP, que é encapsulado num segmento UDP.
U O cabeçalho RTP indica o
tipo de codificação de aúdio em cada pacote, os transmissores podem mudar a codificação durante a conferência. O cabeçalho RTP também contém os números de seqüência e marcas de tempo.
RTP e QoS
U RTP não fornece nenhummecanismo para assegurar a entrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidade de serviço.
U O encapsulamento RTP é visto
apenas nos sistemas finais --ele não é percebido pelos roteadores intermediários.
PRoteadores fornecem o
serviço de melhor-esforço tradicional da Internet. Eles não fazem nenhum esforço especial para assegurar que os pacotes RTP cheguem no destino no momento correto.
U A fim de fornecer QoS
para uma aplicação, a Internet deve prover um mecanismo, tal como o RSVP, para que a aplicação possa reservar recursos da rede.
Fluxos RTP
U RTP permite atribuir a
cada fonte (por exemplo, uma câmara ou um microfone) o seu próprio fluxo de pacotes RTP independente.
PPor exemplo, para uma
videoconferência entre dois participantes, quatro fluxos RTP poderiam ser abertos: dois fluxos para transmitir o aúdio (um em cada direção) e dois fluxos para o vídeo (novamente, um em cada direção).
U Contudo, algumas técnicas de
codificação populares, incluindo MPEG1 e MPEG2 --reúnem o aúdio e o vídeo num único fluxo durante o processo de codificação. Quando o aúdio e o vídeo são reunidos pelo codificador, então apenas um fluxo RTP é gerado em cada direção.
U Para uma sessão multicast do
tipo muitos-para-muitos, todos os transmissores e receptores tipicamente enviam seus fluxos RTP na mesma árvore de multicast com o mesmo endereço de multicast.
Cabeçalho RTP
Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que
está sendo usado no momento.
Se um transmissor muda o tipo de codificação durante uma conferência, o transmissor informa o receptor através deste campo de tipo de carga.
•Tipo de carga 0: PCM mu-law, 64 Kbps •Tipo de carga 3, GSM, 13 Kbps •Tipo de carga 7, LPC, 2.4 Kbps •Tipo de carga 26, Motion JPEG •Tipo de carga 31. H.261 •Tipo de carga 33, MPEG2 video
Número de Seqüência (16 bits): O número de seqüência é incrementado
de um a cada pacote RTP enviado; pode ser usado para detectar perdas de pacotes e para recuperar a seqüência de pacotes.
Tipo de Carga Número de Seqüência Marca de tempo sincronismo fonteIdentificador campos de miscelânias
Cabeçalho RTP
U Campo de marca de tempod (32 bytes). Reflete o instante de
amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada do relógio de amostragem no transmissor.
PComo exemplo, para aúdio o relógio de marca de tempo incrementa de
um a cada intervalo de amostragem (por exemplo, cada 125 us para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio geram blocos contendo 160 amostras codificadas, então a marca de tempo do RTP aumenta de 160 para cada pacote RTP quando a fonte está ativa. O relógio de marca de tempo continua a aumentar numa taxa constante mesmo quando a fonte está inativa.
U campo SSRC (identificador de sincronismo fonte) (32 bits).
Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter um SSRC distinto.
Cabeçalho RTP (2)
Real-Time Control Protocol (RTCP)
U Trabalha em conjunto com
o RTP.
U Cada participante de uma
sessão RTP transmite periodicamente pacotes de controle RTCP para todos os outros participantes. Cada pacote RTCP contém relatórios do transmissor e/ou do receptor que são úteis para a aplicação.
U As estatísticas incluem o
número de pacotes enviados, número de pacotes perdidos, variação de atraso entre chegadas, etc.
U Esta informação de
realimentação para a aplicação pode ser usada para controle do desempenho e para fins de diagnóstico.
PO transmissor pode mudar
suas transmissões com base nestas informações de realimentação.
RTCP - Continuação
- Para uma sessão RTP existe tipicamente um único endereço de multicast todos os pacotes RTP e RTCP pertencentes à sessão usam este endereço de multicast.
- Os pacotes RTP e RTCP são distintos um dos outros pelo uso de números de portas diferentes.
- Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o número de participantes da conferência aumenta.
Pacotes RTCP
Pacotes de relatório doreceptor:
U fração de pacotes
perdidos, último número de seqüência, variância média do atraso entre chegadas. Pacotes de relatório do
transmissor:
U SSRC do fluxo RTP, o
tempo corrente, o número de pacotes enviados e o número de bytes enviados.
Pacotes de descrição da fonte:
U endereço de e-mail do
transmissor, o nome do transmissor, o SSRC do fluxo RTP associado. Esses pacotes fornecem um mapeamento entre o SSRC e o nome do usuário ou do host.
Sincronização de Fluxos
U RTCP pode ser usado para
sincronizar diferentes fluxos de mídia numa sessão RTP.
U Considere uma aplicação de
videoconferência para a qual cada transmissor gera um fluxo RTP para aúdio e um para vídeo.
U As marcas de tempo nestes
pacotes são vinculadas aos relógios de amostragem de vídeo e de aúdio, mas não são vinculadas a um relógio de tempo real (isto é, a um
U Cada pacote
relatório-do-transmissor RTCP contém para o último pacote gerado no fluxo RTP associado, a marca de tempo do pacote RTP e o instante de tempo real no qual o pacote foi criado. Desta forma o pacote RTCP relatório-do-transmissor associa o relógio de amostragem com o relógio de tempo real.
U Receptores podem uar esta
associação para sincronizar a reprodução de aúdio e de
Controle de Banda do RTCP
U O RTCP procura limitar seutráfego a 5% da banda passante da sessão.
U Por exemplo, suponha que
existe um transmissor enviando vídeo com uma taxa de 2 Mbps. Então o RTCP procura limitar seu tráfego a 100 Kbps.
U O protocolo dá 75% desta
taxa, ou 75 kbps, para os receptores; ele dá os 25% restantes da taxa, isto é, 25 kbps, para o transmissor.
U Os 75 kbps dedicados aos
receptores são divididos de forma igual entre todos os receptores. Assim, se existem R receptores, cada receptor consegue enviar tráfego RTCP a uma taxa de 75/R kbps e o transmissor envia tráfego RTCP a uma taxa de 25 kbps. U Um participante (um transmissor ou receptor) determina o período de transmissão de pacotes RTCP dinamicamente calculando o tamanho médio do pacote (durante toda a sessão) e dividindo o tamanho médio do pacote RTCP pela sua taxa alocada.
H.323
U Visão geral U Terminal H.323 U Codificação H. 323 U Gatekeeper U Gateway U Codecs de Aúdio U Codecs de VídeoVisão Geral (1)
U Base para conferência de
aúdio e de vídeo através de redes IP.
U Objetiva comunicação de
tempo real (ao invés de por demanda)
U Recomendação
quarda-chuva do ITU-T.
U Escopo largo:
Pequipamentos isolados (ex., telefones Web) Paplicações em PCs Pconferências
ponto-a-ponto e multiponto-a-ponto
U A especificação H.323 inclui:
PComo os equipamentos
terminais fazem e recebem chamadas.
PComo os equipamentos
terminais negociam codificações comuns de aúdio e vídeo.
PComo os blocos de aúdio e
vídeo são encapsulados e enviados para a rede.
PComo o aúdio e o vídeo são
sincronizados entre si.
PComo os equipamentos
terminais se comunicam com seus respectivos gatekeepers.
PComo os telefones IP e os telefones PSTN/ISDN convencionais se comunicam. U Chamadas telefônicas U Chamadas de vídeo U Conferências U Quadros brancos Todos os terminais suportando H.323
Internet
Telefone "Ethernet" MS Netmeeting NetSpeak WebPhoneVisão Geral (2)
H.323 SS7, InbandInternet
PSTN
Gateway GatekeeperVisão Geral (3)
Terminais H.323 Devem Suportar:
U G.711 - padrão do ITU
para compressão de voz
U RTP - protocolo para
encapsular blocos de dados de mídia em pacotes
U H.245 - Protocolo de
controle “fora-da-banda” para controlar a mídia entre os terminais H.323. U Q.931 - Um protocolo de sinalização para estabelecer e encerrar chamadas. U RAS (Registration/Admission/S tatus) protocolo de canal -Protocolo para comunicação com o gatekeeper (se um gatekeeper está presente)
Terminal H.323
Codificação H.323
Aúdio:
U Terminais H.323 devem
suportar o padrão G.711 para compressão de voz e transmissão a 56/64 kbps. U H.323 está considerando exigir a codificação G.723 = G.723.1, que opera a 5.3/6.3 kbps. U Opcionais: G.722, G.728, G.729 Vídeo
U Capacidade de vídeo para um
terminal H.323 são opcionais.
U Qualquer terminal H.323 com
capacidade de vídeo deve suportar o formato QCIF H.261 (176x144 pixels).
U O suporte a outros esquemas
da recomendação H.261 é opcional: CIF, 4CIF e 16CIF.
U H.261 é usado com canais de
comunicação cuja taxa de transmissão é múltipla de 64 kbps.
Gerando fluxo de pacotes de aúdio no
H.323
Fonte de Aúdio Codificação: ex., G.711 ou G.723.1 encapsulamento de pacote RTP portaUDP Internet ouGatekeeper
Canal de Controle H.245
U O fluxo H.323 pode conter
múltiplos canais para diferentes tipos de mídia.
U Um canal de controle H.245
por sessão H.323.
U O canal de controle H.245
é um canal confiável (TCP) que transporta mensagens de controle.
U Principais tarefas:
PAbrir e fechar canais de mídia. PTroca de informações de capacidades: antes de enviar dados os terminais devem concordar sobre o algoritmo de codificação U Nota: H.245 para conferência multimedia é análogo ao RTSP para mídia contínua armazenada
Fluxos de Informação
Terminal H.323 Canal de Mídia 1 Canal de Controle de Mídia Canal de Mídia 2 Canal de Controle de Chamada H.323 Gatekeeper Canal RAS TCP UDP Terminal H.323 Canal de sinali-zação de ChamadaGatekeeper 1/2
•O gatekeeper é opcional. Pode oferecer aos terminais: • translação de endereços para endereços IP
• gerenciamento de banda-passante: pode limitar o total de banda-passante consumida pelas conferências de tempo real
• Opcionalmente, as chamadas H.323 podem ser roteadas através do gatekeeper.
te rm inais H .323 Gatekeeper Rotea dor Internet LAN = “Zona” RAS
Gatekeeper 2/2
U Terminal H.323 deve se
registrar com o gatekeeper na sua zona.
PQuando a aplicação H.323 é chamada no terminal, o terminal usa o RAS para enviar seu endereço IP e apelido (alias) fornecido pelo usuário ao gatekeeper.
U Se o gatekeeper está
presente numa zona, cada terminal da zona deve contacta-lo para pedir permissão para realizar uma chamada.
U Uma vez que ele obtém a
permissão, o terminal pode enviar ao gatekeeper um endereço de e-mail, um nome de referência (alias) ou uma extensão de telefone. O gatekeeper translada o nome de referência num endereço IP.
PSe necessário, o gatekeeper poderá consultar outros gatekeepers em outras zonas para resolver um endereço IP. O processo varia entre os fornecedores.
Gateway
T erm inais H.323 Gatekeeper Router Internet LAN = “Zona” RAS Gateway PSTN• Ponte entre a zona IP e as redes PSTN (ou ISDN). • Terminais se comunicam com gateways usando H.245 e Q.931
Codecs de Aúdio
Codec Bandwidth
[kbit/s] MOS Complexidade[MIPS] Packetização(tamanho) [ms] G.711 64 4.5 - -G.721 (ADPCM) 32 4.4 6.5 -GSM 13 3.8 4 20 G.729 8 4.1 15 10 G.723 6.4/5.3 4.0 20 30 Qualidade comercial interlocutor reconhecível intelegível problemas de inteleg. 5 4 3 2 1
MOS (Mean Opinion Score) MOS (Mean Opinion Score)