Transcript Part I: Introduction

Capítulo 6: Multimídia em Redes
Objetivos do capítulo:
Resumo do Capítulo:
 entender os requisitos de  aplicações multimídia em rede
serviço multimídia em
 streams de áudio e vídeo
redes
armazenados



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

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
6a-1
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
6a-2
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
6a-3
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
6a-4
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
6a-5
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 infraestrutura 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
6a-6
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
6a-7
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
6a-8
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
6a-9
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 6a-10
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 6a-11
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 6a-12
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 6a-13
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 6a-14
O RTSP inicia e controla a entrega
Web
browser
HTTP GET
presentation desc.
Web
server
SETUP

PLAY

media
player
media stream
media
server
PAUSE

TEARDOWN
client


server
O cliente obtém uma descrição da
apresentação multimídia, que pode
consistir de diversos fluxos de
mídia.
O browser chama o apresentador
da mídia (aplicação de suporte)
baseado no tipo do conteúdo da
descrição da apresentação.



A descrição da apresentação inclui
referências aos fluxos de mídia,
usando o método URL rtsp://
O apresentador enviar um pedido
RTSP SETUP; o servidor envia uma
resposta RTSP SETUP.
O apresentador envia um pedido
RTSP PLAY; o servidor envia uma
resposta RTSP PLAY.
O servidor de Mídia “bombeia” o
fluxo da mídia.
O apresentador envia um pedido
RTSP PAUSE; o servidor envia
uma resposta RTSP PAUSE.
O apresentador envia um pedido
RTSP TEARDOWN; o servidor
envia uma resposta RTSP
TEARDOWN.
6: Multimídia em Redes 6a-15
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>
6: Multimídia em Redes 6a-16
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 6a-17
RTSP: exemplo de diálogo
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
6: Multimídia em Redes 6a-18
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: , CacheControl:
 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 6a-19
Aplicações interativas de
tempo real
 Telefone PC-2-PC
 PC-2-telefone


Dialpad
Net2phone
 Vamos estudar em detalhes
um exemplo de telefone
Internet PC-2-PC
 videoconferência
 Webcams
6: Multimídia em Redes 6a-20
Telefone Internet sobre melhor
esforço (1)
Melhor esforço
 atraso, perda e jitter
Exemplo de telefone Internet
 Vamos examinar como
atraso, perda e jitter são
freqüentemente tratados
no contexto de um exemplo
de telefone IP.
 As aplicações de telefone
Internet geram pacotes
durante os surtos de voz
 A taxa de transmissão é de
64 kbps durante um surto
de voz
 Durante um surto de voz, a
cada 20 mseg a aplicação gera
um pedaço de 160 bytes =
8 kbytes/seg * 20 mseg
 Cabeçalho é adicionado ao
pedaço; então o
pedaço+cabeçalho é
encapsulado num pacote UDP e
transmitido
 Alguns pacotes podem se
perder e o atraso do pacote
irá flutuar.
 O receptor deverá determinar
quando tocar o pedaço e
determinar o que fazer se um
pedaço não estiver disponível
6: Multimídia em Redes 6a-21
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 6a-22
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á.
 Compromissos para q:


q longo: menos perda de
pacotes
q pequeno: melhor
experiência interativa
 Não são necessários
números de seqüência.
 A estratégia acomoda
pacotes perdidos.
6: Multimídia em Redes 6a-23
Telefone Internet (4): atraso de
apresentação fixo
 Transmissor gera pacotes a cada 20 mseg durante o surto de voz.
 O primeiro pacote é recebido no instante r
 A primeira reprodução é programada para iniciar no instante p
 A segunda reprodução é programada para iniciar no instante p´
packets
loss
packets
generated
packets
received
playout schedule
p-r
playout schedule
p' - r
time
r
p
p'
6: Multimídia em Redes 6a-24
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.
ti  carimbode tempodo i - ésimo pacot e
ri  inst ant eem que o pacot ei é recebido pelo recept or
pi  inst ant eem que o pacot ei é reproduzido no recept or
ri  ti  atrasoda rede para o i - ésimo pacot e
d i  estimat ivado atrasomédio da rede após receber o i - ésimo pacot e
Estimativa dinâmica do atraso médio no receptor:
di  (1  u)di 1  u(ri  ti )
onde u é uma constante (ex., u = .01).
6: Multimídia em Redes 6a-25
Atraso de reprodução adaptativo (2)
Também é útil estimar o desvio médio do atraso, vi :
vi  (1  u)vi 1  u | ri  ti  di |
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 é:
pi  ti  di  Kvi
onde K é um constante positiva. Para este mesmo pacote, o atraso de reprodução é:
qi  pi  ti
Para o pacote j do mesmo surto de tempo, reprodução ocorre no instante
p j  t j  qi
6: Multimídia em Redes 6a-26
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 6a-27
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 6a-28
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 6a-29
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 6a-30
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 6a-31
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 6a-32
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 6a-33
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 6a-34
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.

 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.
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.
6: Multimídia em Redes 6a-35
Fluxos RTP
 RTP permite que seja
atribuída a cada fonte (ex.
uma câmera ou um
microfone) um fluxo RTP
independente de pacotes.

Por exemplo, para uma
videoconferência entre
dois participantes, quatro
fluxos RTP poderiam sera
abertos: dois fluxos para
transmitir o áudio (um em
cada direção) e dois fluxos
para o vídeo (também um
em cada direção).
 No entanto, algumas técnicas
de codificação populares –
incluindo MPEG1 e MPEG2 –
juntam o áudio e o vídeo num
único fluxo durante o processo
de codificação. Quando o
áudio e o vídeo são agrupados
pelo codificador, então apenas
um fluxo RTP é gerado em
cada direção.
 Para uma sessão multicast
muitos-para-muitos, todos os
transmissores e fontes
tipicamente enviam seus
fluxos RTP na mesma árvore
multicast com o mesmo
endereço multicast.
6: Multimídia em Redes 6a-36
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 6a-37
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
6a-38
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 6a-39
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 6a-40
Pacotes RTCP
Pacotes de relato do receptor:
 Fração dos pacotes
perdidos, último número de
seqüência, jitter entre
chegadas médio.
Pacotes de relato do
transmissor:
 SSRC do fluxo RTP, tempo
atual, número de pacotes
enviados e número de bytes
enviados.
Pacotes de descrição da
origem:
 Endereço de e-mail do
transmissor, nome do
transmissor, o SSRC do
fluxo RTP associado. Os
pacotes provêm um
mapeamento entre o SSRC
e o nome do usuário/host.
6: Multimídia em Redes 6a-41
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 6a-42
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 6a-43
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 6a-44
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 guardachuva do ITU.
 Escopo abrangente:



dispositivos stand-alone
(ex., Telefones Web)
aplicações em PCs
conferências ponto-aponto 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 6a-45
Visão Geral (2)
 Chamadas
Internet
"Ethernet" phone
telefônicas
 Chamadas de vídeo
 Conferências
 Quadros branco
MS Netmeeting
NetSpeak WebPhone
Todos os terminais dão suporte ao H.323
6: Multimídia em Redes 6a-46
Visão Geral (3)
Gatekeeper
Internet
PSTN
Gatew ay
H.323
SS7, Dentro da faixa
6: Multimídia em Redes 6a-47
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 6a-48
Terminal H.323
6: Multimídia em Redes 6a-49
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 6a-50
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 6a-51
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 6a-52
Fluxos de informação
Call Control
Channel
Call Signaling
Channel
Media Control
Channel
H.323
Terminal
H.323
Terminal
RAS Channel
H.323
Gatekeeper
Media Channel
1
Media Channel
2
TCP
UDP
6: Multimídia em Redes 6a-53
H.323 terminals
Gatekeeper 1/2
Router
RAS
Gatekeeper
LAN = “Zone”
• O gatekeeper é opcional. Provê
para os terminais:
• tradução de endereços para
endereços IP
Internet
• 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 terminalgatekeeper.
6: Multimídia em Redes 6a-54
Gatekeeper 2/2
 Um terminal H.323 deve se
registrar com o gatekeeper
da sua zona.
 Quando a aplicação
H.323 é executada no
terminal, o terminal usa
o RAS para enviar o seu
endereço IP e apelido
(fornecido pelo usuário)
ao gatekeeper.
 Se o gatekeeper estiver
presente numa zona, cada
terminal da zona deve
contactar o gatekeeper
para pedir permissão para
fazer a chamada.
 Assim que tiver recebido a
permissão, o terminal pode
enviar ao gatekeeper um
endereço de e-mail, apelido
ou ramal telefônico. O
gatekeeper traduz o
apelido para um endereço
IP.
 Caso necessário, um
gatekeeper consultará
outros gatekeepers em
outras zonas para
resolver o endereço IP.
Procedimento varia de
acordo com o vendedor.
6: Multimídia em Redes 6a-55
Gateway
PSTN
H.323 terminals
Gateway
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 6a-56
Codecs de áudio
Codec
Largura
MOS
Complexidade
[MIPS]
Paquetização
(tamanho do
quadro)
[ms]
de Banda
[kbit/s]
G.711
64
4.5
-
-
G.721 (ADPCM)
32
4.4
6.5
-
GSM
13
3.8
4
20
G.729
8
4.1
15
10
G.723
6.4/5.3
4.0
20
30
MOS (Mean Opinion Score)
5
Toll quality
4
recognize speaker
3
intelligible
2
intelligibility prob.
1
6: Multimídia em Redes 6a-57
MOS (Mean Opinion Score)
Codecs de vídeo
• H.261 (p x 64 kbit/s)
– Vídeo sobre RDSI
– Resoluções: QCIF, CIF
• H.263 (< 64 kbit/s)
– Comunicação em baixa taxa
– Resoluções: SQCIF, QCIF,
CIF,4CIF, 16CIF
SQCIF
QCIF
CIF
4CIF
16CIF
(128 x 96)
(176 x 144)
(352 x 288)
(704 x 576)
(1408 x 1152)
6: Multimídia em Redes 6a-58