Capítulo 6: Redes Multimídia
Objetivos do Capítulo:
 entender os requisitos de
serviço para redes com
multimídia



atraso
taxa de transmissão
perda
 aprender como aproveitar
o máximo do serviço de
melhor esforço da
Internet
 Aprender como a
Internet poderá evoluir
para um melhor
desempenho dos serviços
multimídia
Resumo do capítulo:
 aplicações de rede com
multimídia
 aúdio e vídeo de tempo contínuo
armazenados

RTSP
 aplicações interativas de tempo-
real

Exemplo: telefonia na Internet
 RTP
 H.323 e SIP
 além do melhor esforço



programando e verificando
serviços integrados
serviços diferenciados
Multimídia em Redes
Características Fundamentais:
 Tipicamente sensíveis ao
atraso.
 Mas tolerante a perdas:
perdas esparsas causam
pequenas falhas que podem
passas desapercebidas.
 Antítese de dados
(programas , informações
bancárias, etc.), que não
toleram falhas mas aceitam
atrasos sem problemas.
 Multimídia também é
chamada de “mídia de
tempo contínuo”
Classes de aplicações MM:
 Aúdio e vídeo de tempo
contínuo armazenados
 Audío e vídeo de tempo
contínuo ao vivo
 Vídeo interativo em temporeal
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
 Interativo: o usuário pode
controlar a operação (similar a um
VCR: pause, resume, fast
forward, rewind, etc.)
 Atraso: a partir do pedido do
cliente até o início da
apresentação pode ser de 1 a 10
segundos
Tempo-real unidirecional:
 similar à TV convencional, mas a
transferência de informação é
feita pela Internet
 Não interativo, apenas escutar e
ver
Tempo-Real Interativo:
 Conferência de aúdio ou de vídeo
 Mais exigente nos requisitos de
atraso que o tempo real
unidirecional por causa da
necessidade de interatividade em
tempo real
 Vídeo: < 150 ms aceitável
 Aúdio: < 150 ms bom, <400 ms
aceitável
Multimídia em redes (3): desafios
 Arquitetura TCP/UDP/IP
fornece melhor esforço, não
garantias sobre o atraso ou
sobre a variação de atraso.



Aplicaçõ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)
Aplicações Interativas e,m
tempo real têm requisitos
rígidos para atraso de pacotes
e variação de atraso (jitter).
Jitter é a variabilidade do
atraso de pacotes dentro do
mesmo feixe de pacotes.
 Projeto de aplicações
multimídia seria fácil se
houvesse várias classes de
serviço.


Mas na Internet pública
todos os pacotes recebem
igual tratamento.
Pacotes contendo aúdio e
vídelo interativo de tempo
real permanecem nas filas,
como todos os outros.
 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ço
de melhor esforço da
Internet, nós podemos:
 Usar UDP para evitar o TCP e
sua fase de partida lenta…
 Armazenar o conteúdo no
cliente e controlar a
apresentação para remediar o
jiter
 Podemos acrescentar marcas
de tempo nos pacotes para que
o receptor saiba quando
reproduzí-los.
 Adaptar o nível de
compressão à taxa de
transmissão disponível
 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:
 Mudar os protocolos da
Internet de forma que as
aplicações possam reservar uma
banda de transmissão fim-a-fim



Necessita de um novo protocolo
que reserva banda de
transmissão
Deve modificar as regras de
escalonamento nos roteadores
para poder honrar às reservas
Aplicação deve fornecer à rede
uma descrição do seu tráfego e
deve posteriormente respeitar
esta descrição.
 Exige um novo e complexo
software nos hosts e nos
roteadores
Filosofia de serviços Diferenciados
Exige menos mudanças na infraestrutura da Internet, embora
forneça serviços de primeira e de
segunda classe.
Datagramas são marcados.
Usuários pagam mais para enviar e
receber pacotes de primeira classe.
ISPs pagam mais aos provedores de
backbone para enviar e receber
pacotes de primeira classe.
Como a Internet deveria evoluir para
suportar melhor as aplicações multimídia?
Filosofia Laissez-faire
 Não há reservas, nem
marcações de datagramas
 Quando a demanda aumenta,
mais banda de transmissão
deve ser provida
 Coloque armazenadores de
conteúdo nas bordas da rede:



ISPs e provedores de
backbone acrescentam
caches
Provedores de conteúdo
armazenam conteúdo em nós
CDN
P2P: escolhe o parceiro mais
próximo com o conteúdo
desejado
Redes privadas virtuais (VPNs)
 Reserva blocos permanentes
de banda de transmissão para
empresas.
 Roteadores distinguem o
tráfego de cada VPN usando
endereços IP
 Roteadores usam esquemas
de escalonamento especiais
para fornecerem a banda de
transmissão reservada.
Aúdio e Vídeo Armazenados
Mídia de tempo contínuo
armazenada:
Arquivos de Aúdio e de
Vídeo são armazenados em
servidores
Usuários solicitam os
arquivos de aúdio e de vídeo
por demanda.
Aúdio/vídeo são
aprsentandos, digamos, 10 s
após o pedido.
Interatividade (pausa,
deslocamento da
apresentação) é permitido.
Transdutor de Mídia (player):




remove jitter
descomprime
correção de erros
interface gráfica de
usuário com controles para
interatividade
 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)
 Os arquivos de aúdio e de
vídeo são armazenados em
servidores Web
abordagem ingênua
 browser pede o arquivo com
uma mensagem HTTP do tipo
pedido
 Servidor Web envia o arquivo
na mensagem HTTP do tipo
resposta
 O cabeçalho “content-type”
indica uma codificação
apropriada para aúdio e vídeo
 browser dispara o transdutor
de mídia e passa o arquivo para
ele
 transdutor de mídia apresenta
o arquivo
cliente
servidor
• Maior problema: o transdutor
de mídia interage com o servidor
WEB através do Web browser
que atua como intermediário.
Informações de tempo contínuo em
servidores Web (2)
Alternativa: estabelecer conexão
entre o servidor e o
transdutor
 browser Web solicita e recebe
um meta arquivo
(um arquivo descrevendo o
objeto) ao invés de receber o
próprio arquivo;
 O cabeçalho “Content-type”
indica uma específica aplicação
de aúdio e vídeo
 Browser dispare o transdutor
de mídia e passa o meta
arquivo para ele
 Transdutor estabelece uma
conexão TCP com o servidor e
envia a ele a mensagem HTTP
do tipo pedido.
(1) pedido/resposta HTTP
por um meta arquivo
(2) meta arquivo
transdutor
de mídia
(3) arquivo solicitado é enviado
usando o HTTP
Algumas preocupações:
 O transdutor de mídia se
comunica usando HTTP, que
não foi projetado mpara
suportar comandos de
controle de apesentação
 Pode desejar enviar o aúdio
e o vídeo sobre UDP
Obtendo o vídeo de um servidor
dedicado
 Esta arquitetura permite o
uso de outros protocolos
(além do HTTP) entre o
servidor e o transdutor de
mídia
 Pode também usar UDP ao
invés do TCP
(1) HTTP pedido/resposta
para o arquivo descritor
da apresentação
(2) arquivo
descritor
transdutor
de mídia
cliente
(3) arquivo de aúdio
e vídeo pedido e
enviado
servidor
de vídeo
servidores
Opções ao utilizar um servidor de vídeo


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.
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
taxa de leitura
=d
decodificação
e apresentação
taxa de chegada
= x(t)
da rede
área com
vídeo
Real Time Streaming Protocol: RTSP
HTTP
 Projetistas do HTTP tinham
mídias fixas em mente: HTML,
imagens, applets, etc.
 HTTP não pretende tratar
mídia contínua armazenada
(isto é, aúdio, vídeo,
apresentações SMIL, etc.)
RTSP: RFC 2326
 Protocolo de aplicação do
tipo cliente-servidor.
 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:
 não define como o aúdio e o
vídeo é encapsulado para
transmissão sobre a rede
 não restringe como a mídia
contínua é transportada:
pode usar UDP ou TCP
 não especifica como o
receptor armazena o aúdio e
o vídeo
RealNetworks
 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”:
 Um arquivo é transferido
sobre um canal.
 Informação de controle
(mudanças de diretório,
remoção de arquivos,
trocas de nomes, etc.) é
enviada sobre uma conexão
TCP separada.
 Os canais “dentro-dabanda”e “fora-dabanda”usam diferentes
números de portas.
Mensagens RTSP també são enviadas
“for a-da-banda”:
 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”.
 O fluxo de dados de mídia
contínua cuja estrutura de
pacotes não é definida pelo RTSP,
é considerada “dentro-da-banda”.
 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

Web
browser
HTTP GET
presentation
desc.
descr.
apresent.
Web
server

SETUP

PLAY
media
Transdutor
player
de mídia
fluxo
mídia
mediade
stream
PAUSE
media
Servidor
deserver
mídia

TEARDOWN
client
cliente
server
servidor




Cliente obtém uma descrição da
apresentação multimídia, que pode
consistir de vários fluxos de dados.
O browser chama o transdutor de mídia
(aplicação auxiliar) com base no tipo de
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 rtsp://
Transdutor envia o comando RTSP
SETUP; servidor envia a resposta RTSP
SETUP.
Transdutor envia o comando RTSP PLAY;
servidor envia a resposta RTSP PLAY.
O servidor de mídia descarrega o fluxo de
mídia.
Transdutor envia o comando RTSP PAUSE;
o servidor envia a resposta RTSP PAUSE.
Transdutor envia o comando RTSP
TEARDOWN; servidor envia a resposta
RTSP TEARDOWN.
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
 Cada sessão RTSP tem um
identificador de sessão, que é
escolhido pelo servidor.
 O cliente inicia a sessão com o
comando SETUP, e o servidor
responde ao comando com um
identificador.
 O cliente repete o
identificador de sessão em
cada comando, até que o
cliente encera a sessão com o
comando TEARDOWN.
 O número de porta do RTSP é
554.
 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=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
RTSP: cache de dados
 O cache de mensagens de
resposta RTSP faz pouco
sentido.
 Mas é desejável armazenar
fluxos de mídia contínua
próximos ao cliente.
 Muito do controle de cache do
HTTP/1.1 foi adotado pelo
RTSP.
 Cabeçalhos e controle de
cache podem ser
acrescentados às
mensagens RTSP SETUP,
sejam comandos ou
respostas:
• If-modified-since: ,
Expires: , Via: , CacheControl:
O servidor de cache pode manter
somente segmentos de um dado
fluxo de mídia.
 O 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.
 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
 telefone PC-a-PC
 PC-a-telefone


Dialpad
Net2phone
 videoconferência
 Webcams
 Vamos agora examinar um
produto do tipo telefone
PC-a-PC da Internet em
detalhes
Telefonia Internet sobre melhoresforço (1)
Melhor esforço
 atraso de pacotes, perdas e
variação de atraso (jitter)
Exemplo de telefone Internet
 agora vamos examinar como
atrasos de pacotes, perdas
e jitter são muitas vezes
tratados num exemplo de
telefonia IP.
 As aplicações de telefonia
na Internet geram pacotes
durante momentos de
atividade da voz
 taxa de bits é 64 kbps nos
intervalos de atividade
 durante os intervalos de
atividade a aplicação
produz um bloco de 160
bytes a cada 20 ms
(8 kbytes/s * 20 ms)
 cabeçalho é acrescentado
ao bloco; então bloco mais
cabeçalho sáo encapsulados
num pacote UDP e enviados
 alguns pacotes podem ser
perdidos e o atraso de
pacote irá flutuar.
 receptor deve determinar
quando reproduzir um bloco
e determinar o que fazer
com um bloco faltante
Telefonia Internet (2)
perda de pacotes
 O segmento UDP é
encapsulado num datagrama IP
 datagrama pode ser
descartado por falta de
espaço num roteador
 TCP pode eliminar perdas, mas


retransmissões aumentam o
atraso
O controle de congestionamento do TCP limita a taxa
de transmissão
 Pacotes redundantes podem
ajudar
atraso fim-a-fim
acúmulo dos atrasos de transmissão, propagação, processamento e atrasos de filas
 mais que 400 ms de atraso
fim-a-fim compromete a
interatividade; quanto
menor o atraso melhor
variação de atraso
 considere dois pacotes
consecutivos num intervalo
de atividade
 espaçamento inicial é de
20 ms, mas o espaçamento
no receptor pode ser maior
ou menor que 20 ms
removendo o jitter
 número de seqüência
 marcas de tempo
 atrasando a reprodução
Telefonia Internet (3): atraso de
reprodução fixo
 Receptor tenta reproduzir
cada bloco exatamente q ms
depois que o bloco é gerado.


Se o bloco tem marca de
tempo t, receptor usa o
bloco no instante t+q .
Se o bloco chega após o
instante t+q, receptor o
descarta.
 Números de seqüência não
são necessários.
 Estratégia permite pacotes
pedidos.
 Escolha do valor de q:


q grande: menos perda de
pacotes
q pequeno: melhor controle
da interatividade
Telefonia Internet (4): atraso de
reprodução fixo
 Transmissor gera pacotes a cada 20 ms durante os intervalos de
atividade.
 Primeiro pacote é recebido no instante r
 Primeira programação de reprodução: começa em p
 Segunda programação de reprodução: começa em p’
packets
pacotes
pacotes
packets
gerados
generated
loss
perda
pacotes
packets
recebidos
received
progr.
reprodução
playout
schedule
p - rp - r
progr.
playoutreprodução
schedule
p’ --rr
p'
tempo
time
r
p
p'
Atraso de reprodução adaptativo (1)
• 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.
ti  marca de tempodo i  ésimo pacote
ri  instanteno qual o pacotei é recebido pelo receptor
pi  instanteno qual o pacotei é reproduzido no receptor
ri  ti  atrasoda rede para o i - ésimo pacote
d i  estimat ivado atrasona rede após receber o i - ésimo pacote
Estimativa dinâmica do atraso médio no reeptor:
di  (1  u)di 1  u(ri  ti )
onde u é uma constante fixa (ex., u = 0,01).
Atraso de reprodução adaptativo (2)
É também usual estimar a variância média do atraso, vi :
vi  (1  u)vi 1  u | ri  ti  di |
As estimativas de di e vi sã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
é:
pi  ti  di  Kvi
onde K é uma constante positiva. Para este mesmo pacote, o atraso de
reprodução é:
qi  pi  ti
Para o pacote j no mesmo intervalo de atividade, o pacote deve ser
reproduzido em:
p j  t j  qi
Atraso de reprodução adaptativo (3)
Como saber se um pacote é o primeiro de um intervalo de atividade:
 Se nunca houvesse perdas o receptor poderia simplesmente olhar
nas marcas de tempo sucessivas.
Se a diferença de marcas de tempo sucessivas for maior
que 20 ms, então temos o início de um intervalo de
atividade.
 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.
 Se 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.

Recuperação de perdas de pacotes (1)
 Perdas: pacote nunca chega ou
chega depois do seu tempo de
reprodução programado
correção de erro de envio (FEC):
esquema simples
 para cada grupo de n blocos
cria um bloco redundante
realizando uma operação OU
exclusivo entre os n blocos
originais
 envia os n+1 blocos, aumentando
a banda passante por um fator
de 1/n.
 pode reconstruir os n blocos
originais se houver no máximo
um bloco perdido nos n+1 blocos
enviados
 Atraso de reprodução
precisa ser definido para
receber todos os n+1
pacotes
 Compromisso:



aumentar n, menor
disperdício de banda
aumentar n, maior atraso
de reprodução
aumentar n, maior a
probabilidade que dois ou
mais blocos sejam
perdidos
Recuperação de perdas de pacotes (2)
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 redundante a 13 kbps.
• Transmissor cria
pacote tomando o bloco
n do fluxo nominal e
anexando a ele o bloco
(n-1) do fluxo redundante
Fluxo original
Redundância
Perda de Pacote
Fluxo reconstruído
• 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
de baixa qualidade
Recuperação de perdas de pacotes (3)
Intercalação
 blocos são quebrados em
unidades menores
 por exemplo, 4 blocos de
5 ms cada
 intercalar os blocos como
mostrado no diagrama
 pacote agora contém
unidades menores de
diferentes blocos
Fluxo original
Fluxo intercalado
Perda de pacote
Fluxo reconstruído
 Remontar os blocos no
receptor
 Se o pacote é perdido,
ainda resta mais de cada
bloco
Recuperação de perdas de pacotes (4)
Recuperação pelo receptor de
fluxos de aúdio danificados
 produzir uma substituição
para um pacote perdido que
seja similar ao pacote
original
 pode produzir bons
resultados para baixas
taxas de perdas e pacotes
pequenos (4-40 ms)
 estratégia mais simples:
repetiçãon
 estratégia mais complexa:
interpolação
Real-Time Protocol (RTP)
 RTP especifica uma
estrutura de pacotes que
transportam dados de
aúdio e vídeo: RFC 1889.
 pacote RTP oferece



identificação do tipo de
carga
numeração da seqüência de
pacotes
marcas de tempo
 RTP roda nos sistemas
terminais.
 os pacotes RTP são
encapsulados em segmentos
UDP
 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ção
camada de
transporte
Enlace
Física
RTP: Exemplo
 Considere enviar 64 kbps
de voz codificada em PCM
sobre RTP.
 A aplicação reúne dados
codificados em blocos, por
exemplo, a cada 20 ms =
160 bytes por bloco.
 O bloco de aúdio, junto com
o cabeçalho RTP forma o
pacote RTP, que é
encapsulado num segmento
UDP.
 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
 RTP não fornece nenhum
mecanismo para assegurar a
entrega dos pacotes e dados
no tempo correto, nem
fornece outras garantias de
qualidade de serviço.
 O encapsulamento RTP é visto
apenas nos sistemas finais -ele não é percebido pelos
roteadores intermediários.

Roteadores 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.
 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
 RTP permite atribuir a
cada fonte (por exemplo,
uma câmara ou um
microfone) o seu próprio
fluxo de pacotes RTP
independente.

Por 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).
 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.
 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
Número de
Seqüência
Marca de tempo
Identificador
campos de
sincronismo fonte miscelânias
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.
Cabeçalho RTP (2)
 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.

Como 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.
 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.
Real-Time Control Protocol (RTCP)
 Trabalha em conjunto com
o RTP.
 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.
 As estatísticas incluem o
número de pacotes
enviados, número de
pacotes perdidos, variação
de atraso entre chegadas,
etc.
 Esta informação de
realimentação para a
aplicação pode ser usada
para controle do
desempenho e para fins de
diagnóstico.

O 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 do
receptor:
 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:
 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:
 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
 RTCP pode ser usado para
sincronizar diferentes
fluxos de mídia numa
sessão RTP.
 Considere uma aplicação de
videoconferência para a
qual cada transmissor gera
um fluxo RTP para aúdio e
um para vídeo.
 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
relógio de parede).
 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-dotransmissor associa o
relógio de amostragem com
o relógio de tempo real.
 Receptores podem uar esta
associação para sincronizar
a reprodução de aúdio e de
vídeo.
Controle de Banda do RTCP
 O RTCP procura limitar seu
tráfego a 5% da banda
passante da sessão.
 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.
 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.
 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.
 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
 Visão geral
 Terminal H.323
 Codificação H. 323
 Gatekeeper
 Gateway
 Codecs de Aúdio
 Codecs de Vídeo
Visão Geral (1)
 Base para conferência de
aúdio e de vídeo através de
redes IP.
 Objetiva comunicação de
tempo real (ao invés de por
demanda)
 Recomendação quardachuva do ITU-T.
 Escopo largo:
 equipamentos isolados
(ex., telefones Web)
 aplicações em PCs
 conferências ponto-aponto e multiponto
 A especificação H.323 inclui:






Como os equipamentos
terminais fazem e recebem
chamadas.
Como os equipamentos
terminais negociam
codificações comuns de aúdio
e vídeo.
Como os blocos de aúdio e
vídeo são encapsulados e
enviados para a rede.
Como o aúdio e o vídeo são
sincronizados entre si.
Como os equipamentos
terminais se comunicam com
seus respectivos gatekeepers.
Como os telefones IP e os
telefones PSTN/ISDN
convencionais se comunicam.
Visão Geral (2)
 Chamadas telefônicas
Internet
 Chamadas de vídeo
 Conferências
 Quadros brancos
Telefone "Ethernet"
MS Netmeeting
NetSpeak WebPhone
Todos os terminais suportando
H.323
Visão Geral (3)
Gatekeeper
Internet
PSTN
Gatew ay
H.323
SS7, Inband
Terminais H.323 Devem Suportar:
 G.711 - padrão do ITU
para compressão de voz
 RTP - protocolo para
encapsular blocos de dados
de mídia em pacotes
 H.245 - Protocolo de
controle “fora-da-banda”
para controlar a mídia
entre os terminais H.323.
 Q.931 - Um protocolo de
sinalização para
estabelecer e encerrar
chamadas.
 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:
 Terminais H.323 devem
suportar o padrão G.711 para
compressão de voz e
transmissão a 56/64 kbps.
 H.323 está considerando
exigir a codificação G.723 =
G.723.1, que opera a 5.3/6.3
kbps.
 Opcionais: G.722, G.728,
G.729
Vídeo
 Capacidade de vídeo para um
terminal H.323 são opcionais.
 Qualquer terminal H.323 com
capacidade de vídeo deve
suportar o formato QCIF
H.261 (176x144 pixels).
 O suporte a outros esquemas
da recomendação H.261 é
opcional: CIF, 4CIF e 16CIF.
 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
porta
UDP
Internet ou
Gatekeeper
Canal de Controle H.245
 O fluxo H.323 pode conter
múltiplos canais para
diferentes tipos 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.
 Principais tarefas:
Abrir e fechar canais
de mídia.
 Troca de informações
de capacidades: antes
de enviar dados os
terminais devem
concordar sobre o
algoritmo de
codificação
 Nota: H.245 para
conferência multimedia é
análogo ao RTSP para mídia
contínua armazenada

Fluxos de Informação
Canal de Controle
de Chamada
Canal de sinalização de Chamada
Terminal
H.323
Canal de Controle
de Mídia
Terminal
H.323
Canal RAS
H.323
Gatekeeper
Canal de Mídia
1
Canal de Mídia
2
TCP
UDP
terminais H.323
Gatekeeper 1/2
Internet
Rotea
dor
RAS
Gatekeeper
LAN = “Zona”
• 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.
Conveniente para bilhetagem.
• Protocolo RAS (sobre TCP) para comunicação entre terminal-gatekeeper.
Gatekeeper 2/2
 Terminal H.323 deve se
registrar com o
gatekeeper na sua zona.
 Quando 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.
 Se o gatekeeper está
presente numa zona, cada
terminal da zona deve
contacta-lo para pedir
permissão para realizar
uma chamada.
 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.
 Se necessário, o
gatekeeper poderá
consultar outros
gatekeepers em outras
zonas para resolver um
endereço IP. O processo
varia entre os
fornecedores.
Gateway
PSTN
Terminais H.323
Gateway
Router
Internet
RAS
Gatekeeper
LAN = “Zona”
• 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
MOS (Mean Opinion Score)
5
Qualidade comercial
4
interlocutor reconhecível
3
intelegível
2
problemas de inteleg.
1
MOS (Mean Opinion Score)
Codecs de Vídeo
• H.261 (p x 64 kbit/s)
– Vídeo sobre ISDN
– Resoluções : QCIF, CIF
• H.263 (< 64 kbit/s)
– Comunicação de baixa taxa
de bits
– 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)