Redes Multimidia

1. 1
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 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
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 infra-
estrutura 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.

2. 2
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.
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:
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
• 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
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.
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
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
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
(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
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
área com
vídeo
taxa de chegada
= x(t)
da rede
taxa de leitura
= d
decodificação
e apresentação

3. 3
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-da-
banda”e “fora-da-
banda”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
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.
HTTP GET
SETUP
PLAY
media stream
PAUSE
TEARDOWN
media
player
Web
server
media
server
Web
browser
client server
presentation desc.
Transdutor
de mídia
Servidor
de 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
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=0-
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK

4. 4
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: , Cache-
Control:
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 melhor-
esforç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 congestio-
namento do TCP limita a taxa
de transmissão
Pacotes redundantes podem
ajudar
atraso fim-a-fim
acúmulo dos atrasos de trans-
missão, propagação, proces-
samento 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
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

5. 5
Atraso de reprodução adaptativo (1)
pacoteésimo-oreceberapósredenaatrasodoestimativa
pacoteésimo-opararededaatraso
receptornooreproduzidépacoteoqualnoinstante
receptorpelorecebidoépacoteoqualnoinstante
pacoteésimodotempodemarca
id
itr
ip
ir
it
i
ii
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( 1 iiii trudud −+−= −
onde u é uma constante fixa (ex., u = 0,01).
É também usual estimar a variância média do atraso, vi :
||)1( 1 iiiii dtruvuv −−+−= −
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
é:
iiii Kvdtp ++=
onde K é uma constante positiva. Para este mesmo pacote, o atraso de
reprodução é:
iii tpq −=
Para o pacote j no mesmo intervalo de atividade, o pacote deve ser
reproduzido em:
ijj qtp +=
Atraso de reprodução adaptativo (2)
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.
Atraso de reprodução adaptativo (3) 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
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
de baixa qualidade
Recuperação de perdas de pacotes (2)
Fluxo original
Redundância
Perda de Pacote
Fluxo reconstruído
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 Remontar os blocos no
receptor
Se o pacote é perdido,
ainda resta mais de cada
bloco
Recuperação de perdas de pacotes (3)
Fluxo original
Fluxo intercalado
Perda de pacote
Fluxo reconstruído

6. 6
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
Recuperação de perdas de pacotes (4) 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
Enlace
Física
camada de
transporte
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.

7. 7
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
Identificador
sincronismo fonte
campos de
miscelânias
Cabeçalho RTP
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.
Cabeçalho RTP (2)
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-do-
transmissor 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.

8. 8
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 quarda-
chuva do ITU-T.
Escopo largo:
equipamentos isolados
(ex., telefones Web)
aplicações em PCs
conferências ponto-a-
ponto 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.
Chamadas telefônicas
Chamadas de vídeo
Conferências
Quadros brancos
Todos os terminais
suportando H.323
Internet
Telefone "Ethernet"
MS Netmeeting
NetSpeak WebPhone
Visão Geral (2)
H.323 SS7, Inband
Internet PSTN
Gateway
Gatekeeper
Visão Geral (3) 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)

9. 9
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
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 Chamada
Gatekeeper 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.
Conveniente para bilhetagem.
• Protocolo RAS (sobre TCP) para comunicação entre terminal-gatekeeper.
terminaisH.323
Gatekeeper
Rotea
dor
Internet
LAN = “Zona”
RAS

10. 10
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
TerminaisH.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)
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 (128 x 96)
(176 x 144)
(352 x 288)
(704 x 576)
(1408 x 1152)
SQCIF
QCIF
CIF
4CIF
16CIF