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.

quinta-feira, 29 de outubro de 2015

FUTURECON : João Rezende defende a desregulamentação do setor de telecom frente à falta de regulação das OTTs


É melhor desregulamentar de um lado do que engessar do outro”. Essa foi a resposta do presidente da Anatel, João Rezende, às diversas críticas em relação à falta de regulamentação no setor de OTT durante um dos paíneis que aconteceram ontem (27) no Futurecom 2015.
O painel “O Futuro do Setor de Comunicações diante de um Cenário de Profundas Transformações” estava repleto de representantes de diversas provedoras de soluções de infraestrutura de rede e operadoras, além do presidente da Anatel e do Secretário de Telecomunicações do Ministério, Maximiliano Martinhão.
Em um primeiro momento, todos focaram na discussão de modelos de negócio e criticaram fortemente o cenário de regulação das telecomunicações.
“O que nós realmente almejamos é um sistema regulatório bem mais moderno, mais amplo. Nós temos que ser mais ágeis para mudar essas leis e que sejam leis mais duradouras, mais concretas, se não, não vamos nem atrair o capital de fora”, disse Divino Sebastião, da Algar Telecom.
“Um investidor espera uma estabilidade do ponto de vista da regulação básica do setor diante desse cenário de grandes transformações”, disse Rodrigo Abreu, presidente da TIM. Para ele, “uma regulação que já dura 15, 16 anos é uma regulação extremamente bem sucedida, mas agora ela precisa mudar”.
Carlos Zenteno, da Claro, seguiu as discussões defendendo que “os operadores estão fazendo um trabalho muito criativo em desenvolver novos serviços, para continuar gerando consumo, para continuar gerando uso dos serviços, mas, seguramente, tem que ser feito alguma coisa em relação à regulação, não para colocar barreiras, mas para harmonizar o trabalho que fazemos todos juntos aqui”.
Em resposta a todas essas críticas, João Rezende disse que “o risco que se tem de levar a regulamentação da telefonia para os OTTs, pode prejudicar esse setor, acho que se fizermos isso estaremos engessando esse processo de inovação”. Também falando sobre a questão de carga tributária, Rezende se esquivou, falando que essa questão é mais ampla e “não é simples de ser resovida” devido a questões como o principio federativo e impostos que são discutidos a níveis de estado, por exemplo.
Aproveitando a oportunidade, o presidente da Anatel aproveitou para alfinetar as operadoras: “Acho importante dizer que a Anatel não regula o preço de dados, então se existe um problema do relacionamento de OTTs com as empresas é um problema do modelo de negócio adotado”.