PROTOCOLOS PARA APLICAÇÕES MULTIMÍDIA

ABSTRACT

The last few years have witnessed an explosive growth in the development and
deployment of networks applications that transmit and receive audio and video over the
Internet. New multimedia networking applications (continuous media applications)
seem to be announced daily. The service requeriments of these applications vary from
the elastic applications, being much more sensitive to delays and less to data loss.
This work shows a little of some multimedia protocols such as RTP, RTCP,
RTSP and the new RSP and some other tools that try to make the internet best effort
less perceptible as possible.

RESUMO
Os últimos anos apresentaram um crescimento explosivo na criação e no
desenvolvimento de aplicações em rede que enviam e recebem áudio e vídeo pela
internet. Novas aplicações multimídia distribuídas parecem nascer todo dia. Os
requerimentos dos serviços para essas aplicações diferem significativamente daqueles
para aplicações elásticas como web, e- mail, login remoto, etc: as aplicações multimídia
são altamente sensíveis aos retardos na rede e menos sensíveis à perda de pacotes.
Neste trabalho, veremos como aplicações multimídias podem ser desenhadas
para tirar bom proveito do “melhor esforço” da internet. Conheceremos alguns
protocolos utilizados no streaming multimídia e suas características.

AUTORES

Roberto Schemid Abo-Gamem da Cunha, Rafael Esteves Mansano.

1 – APLICAÇÕES MULTIMÍDIA DISTRIBUÍDAS

Existem dois pontos destacados no estudo de requerimento de serviços:

considerações sobre o tempo e tolerância à perda de dados. Tempo é importante porque
veremos que muitas aplicações são extremamente sensíveis ao atraso e um pequeno
atraso na chegada de um pacote pode acarretar inutilidade a todo o processo já feito. Por
outro lado, este tipo de aplicação é mais tolerante à perda de dados do que os serviços
elásticos. Uma perda pode ser facilmente aliviada ou até anulada, por certos
mecanismos da aplicação.

1.1 – Exemplos de aplicações multimídia

Streaming Áudio e Vídeos armazenados

Nesta classe de aplicações, um cliente solicita sob demanda áudio ou vídeo comprimido
que estão armazenados em um servidor. Aí, há três pontos distintos:
a.) Mídia armazenada. O conteúdo foi gravado e armazenado. Assim o cliente
pode ver, ouvir, pausar, avançar e retroceder a mídia para o ponto que ele
quiser.
b.) Streaming. O cliente recebe o áudio/vídeo em segundos apões ele requisitar.
Isto significa que enquanto ele recebe o arquivo, ele já pode ver o conteúdo,
evitando que o arquivo tenha que ser baixado completamente para começar
sua execução.
c.) Reprodução contínua. Uma vez que o playout começa, ele deve ocorrer de
acordo com o tempo original de gravação. O dado deve chegar ao destino a
tempo de ser vista corretamente pelo cliente

Streaming Áudio e Video ao vivo

Esta classe é similar a transmissão por tv ou rádio, exceto pelo fato de a
transmissão ser feita pela internet. Permite ao usuário receber uma transmissão ao vivo
de áudio ou vídeo. Como o conteúdo não é armazenado, o cliente não pode pausar,
retroceder a exibição. Isso só seria possível com algum tipo de armazenamento da
transmissão. Neste tipo de aplicação, há vários clientes recebendo o mesmo conteúdo
simultaneamente. O distribuidor deve estar bem preparado com estrutura de ip
multicasting. Atrasos grandes neste caso, são bem desagradáveis e não há como reverter
isso, a menos de um armazenamento do streaming.

Áudio e Vídeo em Tempo Real Interativo.

Esta classe permite ao usuário se comunicar um com os outros em tempo real.

Áudio interativo sobre internet é chamado de Internet Phone. Vídeo conferência é um
exemplo para áudio e vídeo. Delays de mais de 400 milissegundos resultam em
frustrantes e até incompreensíveis conversações.

2 – OBSTÁCULOS PARA MULTIMÍDIA NA INTERNET DE HOJE

 O protocolo IP utilizado na internet hoje provê o “serviço de melhor esforço”
para todos os seus datagramas. Em outras palavras, a internet faz o possível para que
tudo corra bem, mas não dá nenhuma garantia de que isto vai realmente acontecer,
principalmente quanto aos delays dos seus pacotes. Como TCP e UDP rodam sobre o
IP, nenhum dos dois pode garantir o tempo que um pacote levará até chegar ao seu
destino. Devido à falta de um “esforço especial” para esse aspecto, torna-se um grande
desafio resolver este problema para aplicações multimídia na internet. Principalmente
durante os horários de pico na internet, quando o volume de tráfego é maior, a
importância de se resolver este caso mostra-se mais urgente.
É chamado de packet jitter a variação dos delays de um pacote dentro de um
mesmo stream de pacotes. Exemplo: num stream packet são mandados 10 pacotes. Pode
ocorrer de 8 chegarem no determinado tempo e os outros dois não terem chegado a
tempo. As causas podem ser as filas nos roteadores ou congestionamento em algum
ponto da rede, por algum motivo. Tenta-se evitar o jitter packet nas aplicações
multimídias.
Para tratar o jitter packet, poderiam ser atribuídas prioridades a certos pacotes e
fazê-los ter preferência nos roteadores. Há prós e contras nessa implementação. Mas
atualmente na internet, todos os pacotes são tratados iguais.

3 – COMO A INTERNET DEVERIA SE DESENVOLVER PARA SUPORTAR

MELHOR A MULTIMÍDIA

Os debates sobre a forma de evolução da Internet para que ela possa suportar
aplicações multimídia são cada vez mais freqüentes. Existem duas correntes de
pensamentos sobre isso atualmente.
Na primeira, alguns pesquisadores acreditam que a melhor maneira é fazer
mudanças substanciais na rede para que os aplicativos possam alocar explicitamente
bandwidth de um extremo ao outro da conexão. Por exemplo: se o ponto A deseja fazer
uma chamada telefônica através da Internet até o ponto B, então o aplicativo deveria
reservar bandwidth por todo o caminho de A até B. Mas para isso seria necessário um
protocolo que reservasse bandwidth de um ponto ao outro, mudar a política de
chamadas de espera nos roteadores (quem pagasse mais receberia um tratamento
melhor) e descrever o tráfego que se pretende utilizar. Com isso, a rede poderia
selecionar aquelas reservas que certamente conseguirá realizar. RSVP é um protocolo
que faz tais reservas.
A segunda corrente é contrária a primeira e acredita que uma política de
“laissez-faire” seja a solução. Com o aumento da demanda, os ISPs fariam um
balanceamento de sua rede para melhor atender seus usuários. Seriam utilizados CDNs
(redes de distribuição de conteúdo) nas extremidades da internet, evitando assim um
aumento do fluxo no meio dela. Cria r sub-redes para tráfego exclusivo de transmissões
ao vivo, fazendo árvores de transmissão o tráfego ficaria melhor organizado e menos
pesado no ponto de partida da transmissão.
Existe ainda uma corrente de pesquisadores que apóiam as duas anteriores e
sugerem a criação de duas classificações de tráfego para que o usuário pague pelo tipo
que ele usa.
4 – COMPRESSÃO ÁUDIO E VÍDEO

Antes de um áudio ou vídeo ser transmitido por uma rede, ele deve ser
comprimido. Essa necessidade é óbvia: reduzir o número de bits transitando a fim de
garantir sempre banda suficiente para todas as aplicações. Há vários tipos de
compressão existentes hoje e cada um com sua finalidade e característica. Para áudio,
PCM, MP3 e GSM são expoentes. Para vídeo, MPEG-1 e 2 e H-261 destacam-se. Está
por vir MPEG versão 4, tanto para áudio e vídeo.

5 – O STREAMING MULTIMÍDIA

Nos últimos anos, o streaming de áudio e vídeo se tornou uma aplicação mais
popular e um grande consumidor de banda. Esta tendência está para continuar devido a
diversas razões: custo dos dispositivos de armazenamento tem diminuído, a
popularização da banda larga doméstica tem crescido gradativamente, novas técnicas de
distribuição de conteúdo têm também se desenvolvido, etc.
Num streaming multimídia, um cliente solicita uma mídia e o servidor atende à
sua requisição. Este servidor pode ser um servidor normal, como os usados para
internet, bem como pode ser servidor especial para streaming. A mídia chega ao cliente
por meio de sockets, tanto por UDP quanto por TCP. Antes de ser enviado, a mídia é
segmentada e cada segmento é encapsulado com cabeçalhos próprios. O RTP é um
protocolo público usado para tal fim.
Para desfrutar do conteúdo da mídia, é preciso de programas que interpretam a
mídia e expõem-na. Tais programas são denominados “media players”. Estes
programas descomprimem a mídia (que em geral virá comprimida), fazem a remoção de
jitter e também uma correção de erros, a fim de proporcionar um a reprodução boa.
Muitos media players já estão acoplados aos browsers.

5.1 – Acessando Áudio e Vídeo por um Servidor

Áudio e vídeo podem estar armazenados em servidores que os entregam ao

cliente tanto por HTTP quanto por não HTTP .
Suponha um caso de streaming par áudio: se ele está armazenado num servidor
web normal, ele enviará para o cliente através de uma resposta HTTP, numa conexão
TCP. No caso do vídeo, muitas vezes áudio e vídeo estão armazenados separadamente e
por isso, será necessário uma conexão TCP e uma resposta HTTP para cada um. O
media player também pode interagir com o servidor, analogamente a um browser.
Entretanto, HTTP não é considerado um protocolo muito bom para tal situação.
É considerado insuficiente para isso, pois não permite avanço, retrocesso, pausa
facilmente durante a execução da mídia.
Para ficar livre do uso do protocolo HTTP, é possível fazer o streaming
diretamente com o media player, usando uma conexão UDP. Neste caso, o servidor
pode ser um especial para assuntos multimídia, diferentemente dos comuns para web.
6 – PROTOCOLOS PARA APLICAÇÕES MULTIMÍDIA

6.1 – RTP (RFC 1889)

Pode ser usado para encapsular inúmeros formatos populares (GSM, MPEG,
PCM, H263, etc). Há várias implementações para ele, hoje em dia, pelo mundo em
várias aplicações. É também complementar em importantes outros protocolos
interativos para aplicações em tempo real, como SIP e H.323.
O servidor web encapsula o arquivo numa resposta HTTP e manda a mensagem
para o browser. Quando o browser recebe esta resposta, ele chama o media player, de
acordo com o “content type” no cabeçalho da mensagem. Aí, o cliente e o servidor
trocam mensagens RTSP, do tipo setup request, mensagens OK, play/pause request,
etc. Também é possível escolher por exemplo entre uma mídia de maior ou menor
qualidade, de acordo com o interesse ou banda disponível.
O RTP roda basicamente em UDP. O lado servidor encapsula um “pedaço” da
mídia num pacote RTP, depois esse pacote é encapsulado num segmento UDP e então
entregue ao IP. O lado cliente extrai do UDP o pacote RTP, de onde extrai o pedaço da
mídia é passa para o media player.
Se uma aplicação usa RTP em vez de outro esquema proprietário para prover
payload time, timestamps ou números seqüenciais, a aplicação vai facilmente
interoperar com outras aplicações multimídia.
O RTP não provê mecanismos para certificar de que o dado chegará dentro da
data prevista ou outra qualidade de serviço. Nem garante a ordem da chegada dos dados
e nem mesmo a entrega deles. E também, o encapsulamento RTP somente é visto nos
end-systems. Os roteadores não o distinguem: não têm como saber se um datagrama IP
contém ou não um encapsulamento RTP.
Os pacotes RTP funcionam tanto para unicast como para multicast (um para um,
um para muitos e muitos para muitos).

6.1.1 – RTP Packet Fields

Figura 1: campos de um pacote RTP.

Os campos apresentados abreviadamente são:

?? V: versão. A versão 2 significa a especificada na RFC, sendo a 1, no draft.

?? P: (padding) preenchimento. Sinaliza a adição de bits no conteúdo, somente para
uso de algoritmos de criptografia ou transmissões de pequenos conteúdos. O
último octeto no campo de conteúdo (payload) indica quantos octetos de
preenchimento foram inseridos.
 ?? X: extensão. Aumenta o tamanho do cabeçalho normal para um extendido com
maiores informações.
?? CC: contador CSRC. Apresenta o números de identificadores CSRC
apresentados neste campo.
?? M: marcador. Usado geralmente para identificar os limites de um quadro.
?? PT: tipo de conteúdo.

Caso o flag X tenha sido sinalizado, o cabeçalho inclui uma extensão conforme
apresentado na figura abaixo:

Figura 2: parte do cabeçalho RTP, para o caso de flag X sinalizado

O protocolo RTP, por não ser orientado à conexão, não monitora a transmissão e
a recepção dos pacotes. Esta tarefa é realizada por outro protocolo, RTCP, apresentado a
seguir.

6.1.2 – Desenvolvendo aplicações com RTP

Há duas abordagens:
1.) incorporar o código RTP que encapsula e desencapsula (nos lados
cliente e servidor) “à mão”;
2.) usar bibliotecas disponíveis, como as para C e Java.

Aplicação Aplicação
RTP RTP
transporte
Socket UDP
UDP IP
IP Enlace
Enlace Físico
Físico

Figura 3: exemplifica abordagem (1) Figura 4: exemplifica abordagem (2)

6.2 – RTCP (Real Time Control Protocol) (RFC 1889)

O RFC 1889 também especifica o RTCP, um protocolo que uma aplicação

multimídia distribuída pode usar em conjunto como RTP.
Os pacotes RTP e RTCP são distinguidos um do outro pelo uso de diferentes
números de portas. O número da porta do RTCP é o número de porta do RTP + 1. Os
pacotes RTCP não encapsulam nada. Eles são enviados periodicamente por ambos os
lados e contém informações estatísticas que podem ser úteis às aplicações. Estas
informações são: número de pacotes enviados, números de pacotes perdidos e jitter, por
exemplo. O RTP não especifica o que a aplicação deve fazer com esses dados, ficando
isso por conta do programador da aplicação. O transmissor pode usar estas informações
para modificar sua taxa de transmissão enquanto o receptor pode determinar se um
determinado problema é de ordem local, regional ou global.

6.2.1 – Tipos de pacotes do RTCP

Para cada stream RTP que o receptor recebe, ele gera um reporte, que é agregado
a um pacote RTP. Para controlar a transmissão, o RTCP envia os seguintes tipos de
pacotes:

?? SR: relatório do emissor. Para estatísticas de transmissão e recepção sobre os

participantes da sessão que são emissores ativos.
?? RR: relatório do receptor. Para estatísticas de transmissão e recepção sobre os
participantes da sessão que não são emissores ativos.
?? SDES: ítens de descrição da fonte. Inclui o campo CNAME.
?? BYE: finalização da participação da sessão.
?? APP: funções específicas de aplicação.

Um exemplo do pacote com relatório do emissor é apresentado abaixo.

Figura 5: um pacote RTCP.

 O campo RC refere-se ao "contador de relatório de recepção", que indica a
quantidade de blocos de relatórios contidos no pacote. Abaixo são apresentadas tabelas
com os campos do RTCP e seus significados.

abreviação nome valor

SR relatório do emissor 200
RR relatório do receptor 201
SDES descrição da fonte 202
BYE adeus 203
APP definido pela aplicação 204
END fim da lista SDES 0
CNAME nome canônico 1
NAME nome do usuário 2
EMAIL endereço eletrônico do usuário 3
PHONE telefone do usuário 4
localização geográfica do
LOC 5
usuário
nome da aplicação ou da
TOOL 6
ferramenta
NOTE notícias sobre a fonte 7
PRIV extensões privadas 8
Figura 6: alguns campos do cabeçalho do protocolo RTCP

6.3 – RTSP - Real Time Streamming Protocol (RFC 2326)

O RTSP, Protocolo de Fluxo (transmissão) em Tempo Real, é um protocolo

mais robusto para comunicação multimídia e controle de sessões em relação aos
apresentados anteriormente. Seu funcionamento é baseado em streamming
(transmissão) que segmenta os dados em vá rios pacotes onde o tamanho depende da
banda disponível entre cliente e servidor, parâmetro avaliado através do parâmetro
MTU, unidade máxima de transferência, da rede. A aplicação recebe estes pacotes e
recompõe os dados antes de descomprimir e utilizar a informação inicial. Isto permite
que fluxo seja ao vivo ou de dados armazenados. O RTSP é considerado mais próximo à
um datagrama devido a esta característica de remontagem.
A seleção dos canais de envio (UDP, TCP, IP Multicast) e de mecanismos de
transmissão é baseado em RTP, tanto para controlar como para garantir a entrega do
conteúdo em tempo real. O RTSP é também Utilizado com RSVP para solicitar e
garantir banda para sessões.
Este protocolo permite ao usuário controlar (pausar, avançar, retroceder) a
exibição da mídia. Deve estar presente tanto no cliente como no servidor.
 Entretanto o RTSP:
- não define esquemas de compressão para áudio ou vídeo;
- não define como a mídia é encapsulada nem os cabeçalhos. Isto é tarefa do
RTP;
- não restringe como o pacote deve ser transmitido (entre UDP ou TCP);
- não restringe como o media player armazenará (em buffers) o arquivo;
Este é um protocolo out of band, ou seja, suas mensagens são transmitidas em
banda diferente do conteúdo (a própria mídia), usando a porta 544. Suas mensagens
podem ser transmitidas por TCP ou UDP. FTP usa também este esquema de out of
band.
O RTSP também tem a capacidade de permitir ao cliente operações de gravação
no servidor: stream em direção ao servidor. Este protocolo é adotado pela Real
Networks.

6.4 – SDP - Session Description Protocol (RFC 2327)

O SDP, Protocolo de Descrição de Sessão é utilizado para descrição de uma sessão

multimídia (inicialização, convite, anúncio, etc). Ele não tem mecanismo de transporte
próprio, mas é adaptado para utilizar o de outros protocolos mais apropriados como:

?? SAP (Protocolo de Anúncio de Sessão)

?? SIP (Protocolo de Iniciação de Sessão)
?? RTSP
?? SMTP com extensões MIME
?? HTTP, etc

As informações contidas no SDP incluem:

?? o tipo da mídia (áudio, vídeo, etc)

?? o protocolo de transporte (UDP-RTP/IP, H.320, etc)
?? o formato da mídia (H.261 vídeo, MPEG vídeo, etc)
?? endereço de destino
?? porta de recepção no destino
?? URIs (Identificadores Universais de Recursos) com informações sobre a sessão

A descrição da sessão enviada pelo SDP contém os seguintes campos:

?? v = (versão do protocolo)
?? o = (dono/criador e identificador da sessão)
?? s = (nome da sessão)
?? i = (informação da sessão)
?? u = (URI da descrição)
?? e = (endereço email)
?? p = (número do telefone)
?? c = (informação da conexão)
 ?? b = (informação da largura de banda)

Uma ou mais descrições de tempo:

?? z = (ajuste da zona de tempo)

?? k = (chave criptográfica)
?? a = (linhas de atributo da sessão)

Descrição específica do tempo:

?? t = (tempo em que a sessão está ativa)

?? r = (tempo de repetição)

Descrição da mídia:

?? m = (noma da mídia e endereço de transporte)

?? i = (título da mídia)
?? c = (informação da conexão)
?? b = (informação da largura de banda)
?? k = (chave criptográfica)
?? a = (linhas de atributo da mídia)

6.5 – ST-II - Internet Stream Protocol, versão 2

O ST-II, Protocolo de Fluxo (transmissão) Internet - versão 2, foi criado para

substituir o IP. Devido a esta proposta, foi comumente designado de IPv5 (IP versão 5).
O ST-II funciona trocando informações com os roteadores por onde passa. Entre esta
informações, ele recebe dados importantes sobre as condições da rede como:

?? características de performance
?? alocação de recursos

O ST-II tem suporte a serviços como ftp com TCP (porta 21) para garantir uma
maior robustez na entrega dos dados. Além disto, o ST-II tem suporte a outros
protocolos de transporte como:

?? PVP (Protocolo de Vídeo em Pacote)

?? NVP (Protocolo de Voz em Rede)
?? TCP
?? VMTP (Protocolo Versátil de Transação de Mensagem), entre outros

Os pacotes ST-II podem ser encapsulados em IP para dar conectividade e/ou

segurança aos dados. Isto permite uma interoperabilidade com o sistemas anteriores
baseados em IPv4, principalmente por parte dos roteadores.
O ST-II contém uma camada superior destinada ao controle: o SCMP - ST Control
Message Protocol, Protocolo de Mensagem de Controle ST - e este é parte integrante
do ST-II. O SCMP suporta o re-roteamento do fluxo, em caso de falha de algum
roteador, sem a perda da conexão.
Abaixo são apresentadas algumas das mensagens do ST-II:

Nome Valor Significado

AcceptTimeout 2 Um accept não foi reconhecido.
AccessDenied 3 Acesso negado
AckUnexpected 4 Um ACK (reconhecimento) inesperado foi recebido.
ApplAbort 5 A aplicação abortou a conexão anormalmente.
ApplDisconnect 6 A aplicação fechou a conexão normalmente.
AuthentFailed 7 A função de autenticação falhou.
CantGetResrc 8 Incapaz de adquirir fontes (adicionais).
CantRelResrc 9 Incapaz de alocar recursos (em caso de excesso).
Um controle de recepção PDU tem uma mensagem
CksumBadCtl 10
com checksum errado.
Figura 7: algumas mensagens do protocolo ST- II e seus significados.

6.6 Protocolo SIP

Uma das idéias para melhorar os serviços de multimídia na Internet é o

protocolo SIP. Ele foi criado para conectar duas (ou mais) pessoas com transmissão de
vídeo e áudio de maneira que os aplicativos fossem executados em qualquer aparelho
com um endereço IP na Internet (podendo ser um celular, um palm- top, computador,
etc...) e o próprio protocolo provê mecanismos para se descobrir qual é o IP do aparelho
que os usuários estão usando no momento.
Para estabelecer uma conexão SIP o aplicativo envia uma mensagem de convite
(que se assemelha com uma mensagem de pedido de HTTP) utilizando pacotes UDP ou
TCP. Nessa mensagem inicial estará anexado o endereço do outro aplicativo (do usuário
a ser contatado), o IP do usuário que está contatando, os codecs de áudio e vídeo que ele
deseja que o contatado utilize e a porta para qual devem ser enviados os pacotes UDP
ou TCP.
O segundo usuário então responde com uma mensagem de “200 OK” (que se
assemelha com uma mensagem de resposta de HTTP) informando que ele aceitou o
convite e de forma análoga indica suas preferências de quais os codecs de áudio e vídeo
e a porta para a qual esses devem ser enviados.
Após essas trocas iniciais de informações, a conexão é estabelecida. No entanto,
o segundo usuário pode não possuir os codecs que o primeiro requisitou, se isso ocorrer
ele enviará uma mensagem de “600 Not Acceptable” informando que ele não possui os
tais codecs e enviará também uma lista de codecs que ele possui para que o primeiro
usuário possa escolher qual utilizar e refazer o convite.
Vale destacar algumas características do SIP: suas mensagens não utilizam os
sockets utilizados na transferência de multimídia, as mensagens utilizam ASCII e todas
elas devem ter seu recebimento confirmado (ACK) para que seja possível utilizar UDP
ou TCP.

6.7 – H.323

Uma alternativa ao SIP é o H.323. Ele é um padrão popular para conferencia em

tempo real entre end-systems na Internet. Este padrão também cobre como end-systems
na Internet se comunicam com telefones conectados a redes de comutação por circuito
convencionais.
O H.323 inclui as seguintes especificações:
• especificação para como os endpoints negociam codificações para áudio/vídeo
comuns. Como ele suporta uma variedade de codificações padrão, um protocolo é
necessário para um consenso num determinado padrão num momento.
• especificação para como os pedaços de áudio/vídeo são encapsulados e
mandados à rede. Particularmente, H.323 escolhe o RTP para este fim.
• especificação sobre como os endpoints se comunicam com seus respectivos
gatekeepers.
• especificação sobre como os telefones na Internet se comunicam com os
telefones nas redes de comutação por circuito.

Cada endpoint H.323 deve suportar G.711, mas o suporte a vídeo é opcional. Se
suportar o vídeo, o mínimo requerido é o QCIF H.261.

H.323 versus SIP

H.323 é uma suíte de protocolos completa e verticalmente integralizada para

conferencia multimídia; SIP, por outro lado, controla inicio e gerência de sessões, sendo
um componente simples. H.323 vem do ITU enquanto SIP vem de IETF e pega
emprestado muitos conceitos da internet. H.323, sendo um “protocolo guarda-chuva”, é
grande e complexo, enquanto SIP é bem simples.

6.8 – RSVP

Um tipo diferente de algoritmo que pode ser utilizado para controlar fatores
relacionados a multimídia é o Protocolo de Reservas (Reservation Protocol – RSVP).
Ao invés de tentar identificar certos tipos de fluxos assim que eles entram na fila, RSVP
explicitamente aloca bandas para cada fluxo específico.
Aplicações podem requisitar a quantidade de banda prevista para ser usada por
elas. O roteador pode, então, gerenciar a quantidade de banda disponível e a que cada
aplicação precisa.
Para ser implementado, deve haver uma parte RSVP em clientes, servidores e
roteadores. Ele provê as reservas de banda em árvores multicast e é orientado ao
receptor (o receptor é quem inicia e mantém a reserva de recursos para um fluxo).
Entretanto, ele não especifica como a rede proverá a reserva. Também não age como um
protocolo que roteador.
Este protocolo é usado para garantir a QoS (qualidade de serviço) em várias
aplicações numa rede.

6.9 – SRP (Selective Retransmission Protocol)

SRP, Selective Retransmission Protocol é um protocolo desenhado para

melhorar a performance de aplicações multimídia. Ele tenta balancear as altas perdas
com o UDP e a latência do TCP. SRP usa um algoritmo de decisão para determinar se
será pedida ou não a retransmissão de um pacote perdido à aplicação.
SRP é um protocolo no nível de aplicação que usa UDP para transmitir
mensagens. Consiste de um servidor que manda um stream multimídia em uma série de
datagramas numa taxa constante e num cliente que os recebe. Uma aplicação remetente
e uma aplicação receptora controlam o SRP cliente e servidor via funções de interface.
A remetente passa dados para o servidor SRP e o receptor continuamente chama o RSP
cliente pedindo mais dados.
A qualquer momento que o cliente detecta que um frame foi perdido, ele toma uma
decisão de pedir ou não a retransmissão da mensagem. Esta decisão é tomada por um
algoritmo que leva em consideração o quanto de perda e latência pode haver para aquela
aplicação e o quanto desses problemas estão ocorrendo. Se a decisão é de retransimitir,
uma requisição pela retranmissão é feita para o servidor e o cliente espera pela resposta.
Caso esta resposta não chegue dentro do tempo esperado, o pedido é novamente refeito.
Se a decisão for não retransmitir, o cliente desiste daquela mensagem particular e retrata
o erro para a aplicação. Quaisquer mensagens recebidas pela aplicação enquanto espera
pela retransmissão são armazenadas num buffer e utilizadas na hora apropriada. As
retransmissões são esperadas para chegarem em um round trip time.

6.9.1 – Por que UDP?

SRP opera sobre UDP e oferece funcionalidades adicionais ao protocolo. A

aceitação do SRP é fácil uma vez que suas mensagens são essencialmente as mesmas do
UDP.
A razão mais importante para UDP ter sido escolhido no lugar do TCP é que UDP não
implementa retransmissões. Já que TCP tem seu sistema de retransmissão, ele teria que
ser substituído, enquanto ao UDP, sem retransmissões, só seriam adicionadas essas
funcionalidades.

6.9.2 – SRP Packet

SRP usa data packet, nack packet e prob packet para transmitir dados na
rede. O pacote de dados (data packet) tem um tamanho máximo de 1496. A informação
no cabeçalho padrão é de 16 bytes e o resto é reservado para os dados. Nack packet tem
também tamanho de 16 bytes e o probe packet possui 8 bytes.
 type time info data id data size data…

data…

Figura 8: data packet do SRP

type time status data id não usado em pacotes nack SRP

info

Figura 9: nack packet do SRP

type time não usado em pacotes probe SRP

info

Figura 10: probe packet do SRP

7.0 – ALÉM DO MELHOR ESFORÇO

Sabemos que H323, RTP, timestamps, etc não são suficientes para dar às
aplicações multimídias um suporte confiável e robusto. Por ex: telefonia IP tem a
mesma qualidade da telefonia convencional? Não: na telefonia convencional não há
atrasos em pacotes nem jitters. Hoje, a internet trabalha com o melhor esforço para
realizar o que deve ser realizado. Uma aplicação terá uma performance de acordo com o
que a rede poderá oferecer. As aplicações multimídia são bastante sensíveis aos delays e
a principio não há distinção entre os pacotes que circulam.
Veremos aqui novos componentes arquiteturais que podem ser adicionados à
estrutura da internet a fim de melhorar os serviços à multimídia:
1) A marcação e a classificação de pacotes permitiriam um roteador distinguir
um pacote dentre vários diferentes.
2) É desejável determinar um grau de isolamento entre os fluxos para que um
fluxo não seja adversariamente afetado por um outro mal comportado.
 3) Enquanto provendo isolamento entre os fluxos é desejável também que se
use os recursos (banda do link, buffers, etc...) da maneira mais eficiente
possível.
4) Um fluxo declararia seus requerimentos, aí a rede diria se aceita esse fluxo
ou não de acordo com seu requerimento. A esse processo chamamos de “call
admission”. Logo, a “call admission” seria necessária.
Estes acima são princípios básicos para garantir uma qualidade de serviço (QoS)
para as aplicações multimídia. Suas implementações são feitas de acordo com
algoritmos de escalonamento (FIFO, fila de prioridades, round robin, etc...).

8 – REFERÊNCIAS

?? Kurose, James F. and Ross, Ketith W. “Computer Networking – A Top-Down

Approach Featuring the Internet”, second edition.

?? http://www.lcmi.ufsc.br/redes/redes99/helio/protocolos_multimidia/

?? http://www.cs.wpi.edu/~claypool/mqp/srp/report.pdf