PROTOCOLO DE TRANSPORTE EM TEMPO REAL

INTRODUÇÃO
RTP (Real Time Protocol) é um protocolo utilizado para o transporte de mídias
contínuas de tempo real em uma conexão ponto a ponto, como áudio, vídeo ou
dados de uma simulação. Pode ser usado não somente em uma comunicação ponto
a ponto, mas também pode ser usada em uma comunicação multidestinatária
utilizando um endereço IP da faixa reservada para grupos multicast (transmissão
multidestinatária). Este protocolo não reserva recursos nem garante qualidade de
serviço (QoS), porém ele é frequentemente utilizado em paralelo com o RTCP (RTP
Control Protocol) permitindo que haja uma certa monitoração da comunicação. O
uso deste protocolo será descrito na sessão seguinte deste documento. RTP e
RTCP são utilizados paralelamente, mas os pacotes de cada protocolo são
transmitidos de forma independente.

Abrangência do RTP
Embora o RTP tenha sido projetado para satisfazer, principalmente, as
necessidades de conferência em multimídia de múltiplos participantes, ele não se
limita a esta aplicação em particular. Armazenamento de dados contínuos,
simulação distribuída interativa, e aplicativos de controle de processos e medição
remota também podem aplicar o RTP.

Limitações e Expansões
O RTP representa um estilo novo de protocolo que segue os princípios de nível de
aplicação. Pretende-se que o RTP seja maleável para prover a informação requerida
por uma aplicação particular ou mesmo para ser integrado a ela. O RTP também
pode, por outro lado, ser implementado em uma camada diferente da de aplicação.
Devido às definições anteriores nota-se que o RTP está deliberadamente incompleto
na RFC 1889. Para torná-lo completo para uma determinada aplicação a
implementação deverá utilizar-se de arquivos profile (ou de perfil). Este arquivo pode
definir extensões ou modificações no RTP.

Implementação
Já foram implementadas várias aplicações de RTP experimental e comercialmente.
Estas aplicações incluem ferramentas de áudio e vídeo junto com ferramentas de
diagnóstico como monitores de tráfego. Porém, a Internet atual ainda não suporta a
demanda potencial de serviços de tempo-real. Banda passante larga para serviços
que usam RTP, como vídeo, podem degradar potencialmente e seriamente a
qualidade de serviços para outras aplicações da Internet. Assim, os
2
desenvolvedores devem tomar as precauções apropriadas para limitar uso de uma
banda passante acidentalmente muito larga.

Aplicação
Cenários de aplicação do RTP:

 Audioconferência multicast: Técnica de entregar informações aos usuários um

para vários ou vários para vários. Dispositivos como hubs, switches devem
participar das trocas de informação. O desempenho do sistema inteiro
depende do desempenho da rede.
 Videoconferência: Discussões em grupo ou de vários para vários como se
estivessem no mesmo local. Os dados de áudio e vídeo são transportados
separadamente em sessões RTP. A separação é necessária para permitir
que cada participante da conferência receba apenas um tipo de mídia a sua
escolha.
 Tradutores: O protocolo RTP suporta o uso de tradutores e mixers para
modificar o pacote do fluxo RTP. Tradutores são usados para mudar o tipo de
payload (formato do arquivo). Se o usuário mantiver uma videoconferência
em MPEG com 1.5Mbit/s e o outro participante está conectado a 1Mbit/s
talvez essa largura de banda seja insuficiente para a transmissão em tempo
real sendo necessária a troca do formato de vídeo para outro de tamanho
menor (h.261, com 256Kbit/s).
 Mixers: A função do mixer e ressincronizar pacotes de áudio para reconstruir
sequências que foram enviadas, ou seja, converter várias rajadas de dados
em uma só rajada e codificar os dados com um padrão mais apropriado a
baixas velocidades.

Cabeçalho RTP
O cabeçalho RTP comportará as seguintes informações:

<--------------------------- 32 bits --------------------------->

V=2 P X CC M Sequence number
Datação
Identificador da fonte de sincronização (SSRC)
Identificadores da fonte de contribuição (CSRC)

Veja o significado dos diferentes campos do cabeçalho:

3
  O campo versão (V), de 2 bits de comprimento, indica a versão do protocolo.
 O campo padding ou preenchimento (P) tem 1 bit; se P for igual a 1, o pacote
contém bytes adicionais de preenchimento para terminar o último pacote.
 O campo extensão (X) tem 1 bit; se X for igual a 1, o cabeçalho é seguido de
um pacote de extensão.
 O campo CSRC count (CC), de 4 bits, contém o número de CSRC que
acompanha o cabeçalho.
 O campo marker (M) tem 1 bit e sua interpretação é definida por um perfil de
aplicação.
 O campo payload type (PT), de 7 bits, identifica o tipo de dado transferido
(áudio, vídeo, imagem, texto, HTML etc.).
 O campo sequence number, de 16 bits, tem valor inicial aleatório e recebe um
valor 1 por pacote enviado, o que ajuda a detectar pacotes perdidos.
 O campo datação, de 32 bits, reflete o momento em que o primeiro byte do
pacote RTP foi mostrado. Este momento deve ser derivado de um relógio que
avança de maneira linear para permitir a sincronização e a chegada ao
destino.
 O campo SSRC, de 32 bits, identifica de maneira única a fonte de
sincronização. Este identificador é escolhido de maneira aleatória para que
seja único entre todas as fontes de uma mesma sessão. A lista dos CSRC
identifica as fontes (SSRC) que contribuíram para a obtenção dos dados
contidos no pacote com estes identificadores. O número de identificadores é
dado no campo CC.
 O campo CSRC, de 32 bits, identifica as fontes.

Extensão do Cabeçalho do RTP

Um mecanismo de extensão é provido para permitir implementações individuais com
funções novas que exigem levar informações adicionais no pacote de dados do
cabeçalho do RTP. Este mecanismo é projetado de forma que a extensão do
cabeçalho pode ser ignorada por outras implementações que não necessitem das
informações contidas na extensão.
Note que esta extensão possui limitações quanto ao uso. A maioria dos usos
potenciais deste mecanismo seriam mais bem implementados com recursos de
modificações nas especificações do cabeçalho anteriormente descritas. Por outro
lado, informações adicionais requeridas por um formato de payload em particular
não deveriam usar esta extensão de cabeçalho, mas deveriam ser levadas na
própria seção de payload do pacote. A especificação padrão do RTP não define
nenhum tipo de extensão para o cabeçalho do RTP.

Multiplexação de Seções
Para um processo de transporte eficiente, deve ser minimizado o número de pontos
de multiplexação. Por exemplo, em um teleconferência composta de mídias de áudio
e vídeo codificadas separadamente, cada mídia deve ser levada em uma seção de
RTP separada com seu próprio endereço de destino. As mídias de áudio e vídeo
não devem ser multiplexadas em uma mesma seção de RTP, enviadas, e de
multiplexadas no receptor.
4
REFERÊNCIAS
MUXFELDT, Pedro.”; Os protocolos RTP/RTCP”; CCM. Disponível em
< https://br.ccm.net/contents/281-os-protocolos-rtp-rtcp. >;
Acesso em 26/05//2021
CAMPANER, Ronni M..”; O RTP, UM PROTOCOLO DE TRANSPORTE PARA
APLICAÇÕES DE TEMPO-REAL”; CRICTE.UFPR. Disponível em
< http://www.cricte2004.eletrica.ufpr.br/edu/anterior/cd00/trab/rtp/. >;
Acesso em 26/05//2021
ALMEIDA, Juliana.”; RTP (Real Time Protocol)”; GTA.UFRJ. Disponível em
< https://www.gta.ufrj.br/grad/01_2/vidconf/rtp.html. >;
Acesso em 26/05//2021
WANDERLEI, Bruno Lima, DOS SANTOS, Renato Moraes.”; Telefonia IP:
Protocolos e Internet”; TELECO. Disponível em
< https://www.teleco.com.br/tutoriais/tutorialtelip2/pagina_3.asp. >;
Acesso em 26/05//2021