Pesquisar este blog

Translate This Post

terça-feira, 3 de novembro de 2015

Os protocolos RTP/RTCP

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.
Além disso, o RTP pode ser veiculado por pacotes multicast para encaminhar conversas para
destinatários múltiplos.

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 "temporeal".
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









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.


A fórmula para calculá-lo é: J=J+ (|D (i-1, i)|- J) /16 O interarrival jitter é calculado a cada pacote
de dados recebido pela fonte  SSRC_n i --> Primeiro pacote i-1 --> pacote precedente D -->
diferença J --> Segundo pacote

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.
RTP/RTCP protocols Protocolos RTP/RTCP Die RTP/RTCP Protokolle Les protocoles
RTP/RTCP I protocolli RTP/RTCP
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.

Nenhum comentário:

Postar um comentário

Aqui você é livre para opnar, mas por favor, não utilize
palavrões e não faça aos outros o que não quer que façam a você.