Documento escrito por Nico VanHaute, Julien Barascud e Jean-Roland Conca

Introdução: O que é o RTP e o RTCP?

A difusão dos computadores, associada à disponibilidade de material informático audio/vídeo barato, bem como à disponibilidade de ligações com débito mais elevado, fez emergir o interesse de utilizar a rede Internet para enviar áudio e vídeo, tipos de dados que estavam tradicionalmente reservados para as redes especializadas para esse efeito, e já há alguns anos, o áudio e a videoconferência tornaram-se uma prática corrente. Mas a própria natureza da Internet, que faz com que esta rede não seja adaptada para a transmissão dos dados em tempo real, tem como consequência que a qualidade do áudio enviado através da Internet tenha em média uma qualidade medíocre. Esta tese dirige-se precisamente à análise e solução destes problemas para permitir a uma aplicação de audioconferência ou telefone na Internet adaptar o seu comportamento para manter uma qualidade auditiva aceitável mesmo em casos em que a rede esteja bastante congestionada. Estas soluções, sob a forma de mecanismos de controlo, foram aplicadas e testadas no software de audioconferência e telefone na Internet Free Phone que desenvolvemos. Um estudo sobre o comportamento que teriam estes mecanismos numa Internet que evoluía para integrar a disciplina de serviço Fair Queueing mostrou que estes mecanismos, que seriam ainda necessários, teriam mesmo um melhor desempenho neste tipo de rede.

RTP (Real-time Transfert Protocolo)

O objectivo do RTP é fornecer um meio uniforme para transmitir em IP dados sujeitos a constrangimentos de tempo real (áudio, vídeos,…). O papel principal do RTP consiste em aplicar números de sequência de pacotes IP para reconstituir as informações de voz ou de vídeo, ainda que a rede subjacente altere a ordem dos pacotes.

O RTP permite:

• identificar o tipo de informação transportada,
• acrescentar indicadores temporais e números de sequência à informação transportada
• controlar a chegada ao destino dos pacotes.

RTCP (Real-time Transfert Control Protocol)

O protocolo RTCP baseia-se em transmissões periódicas de pacotes de controlo por todos os participantes da sessão.

É um protocolo de controlo dos fluxos RTP, permitindo veicular informações básicas sobre os participantes de uma sessão, e sobre a qualidade de serviço.

Utilização prevista do RTP e do RTCP

O RTP permite uma gestão dos fluxos multimédia (voz, vídeo) em IP. O RTP funciona em UDP. O cabeçalho RTP comporta informações de sincronização, de numeração. A codificação dos dados dependerá do tipo de compressão. O RFCxxxx especifica RTP, em contrapartida a adaptação de um método de compressão ao RTP será descrita num RFC específico, por exemplo H261 em RTP é descrito no RFCxxxx. Um canal RTP é empregado por tipo de fluxo: um para o áudio, um para o vídeo. O campo xxx é empregado para a sincronização. O RTP oferece um serviço de extremo a extremo. Acrescenta um cabeçalho que fornece as informações de timing necessárias para a sincronização de fluxos tempo real do tipo som e vídeo. O RTP (Realtime Transport Protocol) e o seu companheiro RTCP (Realtime Transport Control Protocol) permitem respectivamente transportar e controlar ondas de dados que têm propriedades "tempo-real". O RTP e o RTCP são protocolos que se situam a nível da aplicação e utilizam os protocolos subjacentes de transporte TCP ou UDP. Mas a utilização de RTP/RTCP faz-se geralmente acima o UDP. O RTP e o RTCP podem utilizar o modo Unicast (ponto a ponto) assim como o modo Multicast (multiponto). Cada um deles utiliza uma porta separada de um par de portas. O RTP utiliza a porta par e o RTCP a porta ímpar imediatamente superior.

Formato dos cabeçalhos e os seus conteúdos

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

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

Eis o significado dos diferentes campos do cabeçalho:

• O campo Versão V de 2 bits de comprimento indica a versão do protocolo (V=2)
• O campo padding P : 1 bit, se P for igual a 1, o pacote contém bytes adicionais de enchimento (padding) para terminar o último pacote.
• O campo extensão X : 1 bit, se X=1 o cabeçalho é seguido de um pacote de extensão
• O campo CSRC count CC : 4 bits, contém o número de CSRC que acompanham o cabeçalho
• O campo marker M : 1 bit, a sua interpretação é definidas por um perfil de aplicação (profile)
• O campo payload type PT : 7 bits, este campo identifica o tipo de payload (áudio, vídeo, imagem, texto, HTML, etc.)
• O campo sequence number : 16 bits, o seu valor inicial é aleatório e incrementa-se de 1 por cada pacote enviado, pode servir para detectar pacotes perdidos
• O campo timestamp : 32 bits, reflecte o momento em que o primeiro byte do pacote RTP foi amostrado. Este momento deve ser derivado de um relógio que avança de maneira monótona e linear no tempo, para permitir a sincronização e o cálculo ao destino
• O campo SSRC : 32 bits, identifica de maneira única a fonte, o seu valor é escolhido de forma aleatória pela aplicação. O campo SSRC identifica a fonte de sincronização (ou simplesmente “a fonte”). 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 que contém estes identificadores. O número de identificadores é dado no campo CC
• O campo CSRC : 32 bits, identifica as fontes que contribuem.

O cabeçalho RTCP

O objectivo do RTCP é fornecer diferentes tipos de informações e um feedback quanto à qualidade de recepção.

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

• O campo versão (2 bits)
• O campo padding (1 bits) indica que há enchimento cuja dimensão é indicada no último byte
• O campo recepção report count (5 bits): números de relatórios no pacote
• O campo packet tipo (8 bits) 200 para SR
• O campo length (16 bits) comprimento do pacote em palavras de 32 bits
• O campo SSRC (32 bits) :identificação da fonte específica ao emissor
• O campo NTP timestamp (64 bits)
• O campo RTP timestamp (32 bits)
• O campo sender' s packet count (32 bits)
• O campo sender' s byte count (32 bits) estatísticas
• O campo SSRC-n (32 bits) número da fonte cujo fluxo é analisado
• O campo fraction lost (8 bits)
• O campo cumulative number of packets lost (24 bits)
• O campo extended highest sequence number received (32 bits)
• O campo interarrival jitter (32 bits). É uma estimativa do intervalo de tempos de um pacote de dados RTP que é medido com o timestamp e que está sob a forma de um número inteiro. É, com efeito, o tempo relativo de trânsito entre dois pacotes de dados.

• O campo last SR timestamp (32 bits)
• O campo delay since last SR (32 bits)

Como é utilizado o RTCP no que diz respeito ao RTP ?

O RTCP é um protocolo de controlo associado ao RTP e mede os desempenhos; em contrapartida não oferece garantias. Por isso é necessário empregar um protocolo de reserva do tipo RSVP ou assegurar-se que as relações de comunicações utilizadas são dimensionadas correctamente em relação à utilização que é feita.

A partir de que protocolos funcionam o RTP e o RTCP

O RTP/RTCP está acima do transporte UDP/TCP, mas praticamente acima UDP.
O RTP é um protocolo de sessão, mas está colocado na aplicação. Cabe ao programador integrá-lo.

Como é o tipo de fluxo veiculado?

O RTP não tem nada a ver com o tipo de fluxo, está acima do UDP, e este acima do IP. O tipo de fluxo é teoricamente utilizado em IP.
O RTP traz um número de sequência, um timestamp e um identificador único da fonte (SSRC).

Artigo escrito por Nico VanHaute, Julien Barascud e Jean-Roland Conca.

Última modificação do dia Segunda 17 de Agosto de 2009 às 16:33:08.Este documento, intitulado « Os protocolos RTP/RTCP »a partir de Kioskea (pt.kioskea.net) está disponibilizado sob a licença Creative Commons. Você pode copiar, modificar cópias desta página, nas condições estipuladas pela licença, como esta nota aparece claramente.