Download - Trabalho de IPTV Carlos Alexandre
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 1/9
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 2/9
2
INSTITUTO NACIONAL DE TELECOMUNICAÇÕES – INATELCURSO DE PÓS – GRADUAÇÃO EM ENGENHARIA DE
TV DIGITAL E IPTV
PROTOCOLOS DE SINALIZAÇÃO RTP E RTCP
Trabalho elaborado para obtenção de notaparcial da disciplina TP418 ministrada pelo Prof. Dr.
José Marcos C. Brito.
Aluno: Carlos Alexandre Bernardo da Silva
MANAUS
2011
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 3/9
3
1. PROTOCOLOS DE SINALIZAÇÃO RTP E RTCP
Com a evolução das redes computacionais, houve um acentuado crescimento nos
serviços de tráfego de dados. Operadoras de telecomunicações buscaram nestes
serviços novas oportunidades de renda/negócio e passaram a investir em redes de dados
(pacotes) para ofertarem tais serviços [1].
O IPTV ( Internet Protocol Television) é um serviço de internet utilizando
conexão de banda larga onde possui uma comunicação através de pacotes IP. Este faz a
entrega com segurança de um determinado conteúdo de alta qualidade de televisão
aberta e/ou vídeo-on-demand através de uma rede banda larga. O IPTV utiliza um
serviço triple play, ou seja, um serviço que combina voz, dados e vídeo sobre um único
canal de banda larga, principalmente o envio de informação multimídia [2].
O IPTV é um termo que geralmente aplica-se para a entrega de canais
tradicionais de TV, filmes e conteúdo de video-on-demand sobre uma rede privada,
diferente de Internet TV que não garante uma qualidade de serviço ao enviar pacotes
através da Internet Pública. A partir de uma perspectiva do usuário final, o IPTV opera
como um serviço de televisão por assinatura padrão.
O IPTV utiliza uma plataforma IP convergente de maneira que estes tipos de
serviços sejam comparáveis aos que são oferecidos pelas operadoras de TV por
assinatura a cabo e/ou via satélite, oferecendo uma qualidade de serviço (QoS) e suporte
a tráfego Multicast garantida em ambiente controlado [2]. Além de transmitir vídeo,
áudio e dados, o IPTV também permite aplicações interativas (lojas, filmes, show e etc.)
entre telespectadores de televisão e os provedores de conteúdo de televisão. Esse nível
de interatividade consiste em estabelecer para o usuário informações de programas
como estatística, jogadas de evento em tempo real, por exemplo: podendo assistir um
jogo de futebol e mesmo assim interagir com algum outro jogo em paralelo.
O foco principal deste trabalho está relacionado aos protocolos de sinalização
para o fluxo de áudio e vídeo de IPTV.
Geralmente a transmissão de mídias contínuas como as de áudio e vídeo são
realizados sobre protocolo UDP (User Datagem Protocol) para diminuir a latência e
aumentar a vazão. Este protocolo oferece conexão de transporte não orientado para o
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 4/9
4
tráfego IP. O UDP não é um protocolo confiável de transmissão no sentido de que não
oferece qualquer mecanismo de recuperação de erros. Em tempo real não há como
retransmitir pacotes perdidos ou corrompidos [4]. Para solucionar esta questão, foi
desenvolvidos protocolos de sinalização como RTP e RTCP [3].
O RTP do termo inglês Real Time Transport Protocol (Protocolo de Transporte
em Tempo Real) é um protocolo que está destinado para aplicações multimídias como
áudio e vídeo pela internet em tempo real, mas também pode ser usado para outras
aplicações como armazenamento de dados contínuos. O RTP foi projetado para rodar
sobre um protocolo de transporte sem a conexão como UDP, pois este já implementa
funções de transportes como seqüenciamento. O RTP foi definido pela Internet
Engineering Task Force (IETF) através da recomendação RFC 1889 [4].
O protocolo RTP insere cabeçalhos para ajudar no controle do receptor. No
cabeçalho podemos citar o número de sequência, onde os pacotes são enviados e
numerados de acordo com a sessão. Os números ajudam o receptor a verificar se existe
perda na rede. Ele inclui um timestamp, onde cada pacote enviado recebe uma marcação
de tempo. Esta marcação pode ser usada no receptor para verificar Jitter (Fenômeno que
ocorre em uma rede IP definido pela chegada fora de ordem dos pacotes no destino).
Este usa um tipo de identificador chamado payload, onde envia uma mensagem ao
receptor sobre o tipo de dados que está sendo transportados no payload e como esses
dados foram codificados [4].
O RTP possui um identificador chamado fonte de sincronização (SSRC), este
identificador faz com que a informação gravada seja identificada por um número de 32
bits e enviado junto com os dados. O mesmo transmissor pode gerar múltiplos fluxos
RTP com diferentes SSCRs. Por exemplo, dois fluxos RTP com dois SSCRs diferentes
podem ser transmitidos durante uma videoconferência, um deles para vídeo, e outro
para o fluxo de áudio. Cada SSCR, mesmo quando provem da mesma fonte, tem
seqüenciamento e timestamp dedicado. O caso mais simples de fluxo RTP é a
comunicação entre duas partes, uma no transmissor e outra no receptor. Uma chamada
telefônica Voip a uma única pessoa é um bom exemplo. Neste caso, o transmissor
codifica os dados a serem transmitidos e gera um fluxo RTP. Os dados são enviados
diretamente para o receptor. O transmissor se identifica com o seu próprio endereço IP,
mas também com um número escolhido aleatoriamente de 32 bits: o SSRC [4]
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 5/9
5
Muitas vezes, as aplicações RTP envolvem mais de um receptor ou mais de um
transmissor conforme mostrado na figura 1, a distribuição de sinais de TV ou chamadas
telefônicas Voip são dois exemplos importantes. Quando a situação multi- transmissor
surge, pode ser necessário combinar o fluxo de cada transmissor em um único fluxo
RTP antes da entrega. Para esta tarefa há um dispositivo responsável chamado Mixer .
Figura 1 – (a) Uma sessão simples de RTP utilizando um transmissor e um receptor (b) Uma
sessão de RTP utilizando multi-transmissores e sendo controlado pelo dispositivo Mixer .
Os tradutores e Mixers são sistemas intermediários que funcionam no nível de
RTP. Eles estão encarregados de fazer a tradução e formato do protocolo. Os tradutores
por sua vez alteram o formato dos pacotes que chegam RTP e transmite ao seu destino
final junto do seu identificador SSCR encapsulada. As operações realizadas pelos
tradutores incluem downsampling de dados RTP pare redes de baixa largura de banda
alterando a codificação de vídeo ou áudio. Os Mixers têm a mesma função que os
tradutores, mas, além disso, eles podem combinar fluxo de diferentes fontes em um
único fluxo RTP de saída [4]
Na figura 2 é mostrado o formato do pacote RTP. Na primeira linha temos a
campo V que indica a versão do RTP. O campo P (Padding) é definido com 1 bit para
informar ao receptor que o pacote contém um ou mais Bytes adicionais padding no final
que não carregam informações, este número de Bytes a ser descartado é realizado no
Byte de padding passado. O campo X é definido com uma setagem de 1 bit para dizer
ao receptor que o cabeçalho RTP opcional está habilitada. O campo CC ou contator
CSRC indica o número de identificadores CSRC para o pacote RTP. O campo M pode
ser usado para marcar os limites de quadros de nível superior, ou para sinalizar tipos de
payloads extra, geralmente este campo não é utilizado para algumas aplicações. O
campo PT especifica o formato do payload e do tipo de mídia realizado no fluxo RTP,este é usado pelo receptor para escolher o decodificador mapeado de diferentes
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 6/9
6
codificadores e formatos de payload para códigos bit dependendo do perfil. O campo
SQ é um número escolhido aleatoriamente pelo receptor quando começa a transmitir um
fluxo RTP, este número é incrementado para cada pacote enviando, tornando possível
para que o receptor faça a detecção da perda de pacotes. O campo do Timestamp é um
onde cada pacote enviado recebe uma marcação do tempo, esta marcação pode ser
usada no receptor para verificar Jitter . O campo SSRC é um número escolhido
aleatoriamente, identificando o autor do fluxo de dados do RTP. O campo lista CSRC
gera uma lista de fontes que contribuem para o payload do pacote, o número de itens
desta lisa é sinalizado pelo campo de cabeçalho CC [4].
Figura 2 – formato do Pacote RTP
O protocolo RTP não oferece qualquer mecanismo para garantir uma Qualidade
de Serviço (QoS) para determinados fluxos de dados que este carrega, pois ele se baseia
em mecanismo QoS fornecidos pela rede, tais como pacotes marcados, modelados e
programados. O transporte de dados é incrementado através do protocolo de controle
RTCP que por sua vez monitora a entrega dos dados e provê funções mínimas de
controle e identificação. [5]
O RTCP do termo inglês Real Time Control Protocol (Protocolo de Transporte
em Tempo Real) é um protocolo de controle do RTP, onde opera de modo multicast
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 7/9
7
para prover realimentação para as fontes do RTP. O protocolo RTCP usa o mesmo
serviço de transporte do protocolo UDP, porém usa uma porta diferente [6].
O RTCP permite que o distribuidor tenha um canal de retorno com o cliente para
informações acerca de qualquer perturbação na rede de acesso (altas latências, Jitter ,
perda de pacotes, congestionamentos, etc.) percebidas com a ajuda do RTP.
O protocolo RTCP complementa a RTP da seguinte maneira: Dando feedback
sobre a qualidade de transmissão; Carrega na camada de transporte identificadores de
fontes RTP como o SSRC. Este identificador pode não ser o suficiente para algumas
aplicações, por que pode mudar quando ocorre uma colisão ou se o equipamento do
cliente é reiniciado. Um exemplo são de sessões distintas entre áudio e vídeo estar em
progresso; O RTCP pode fornecer fonte complementar de informação; Ele fornece
informação mínima de controle de sessão. Um exemplo é uma identificação do
participante que é mostrado na interface do usuário [4] [7].
Essas funções são obrigatórias para aplicações multicast e recomendado através
da RFC 1889. Para realizar estas funções, De acordo com o padrão, os pacotes de
controle RTCP devem ser multiplexadas pelo mesmo canal de transmissão de dados,
como mostra na figura 3 [3]. A taxa de bits do RTCP é limitada para manter odesempenho dos fluxos RTP para poder transportar dados do usuário. Para uma sessão,
a largura de banda do RTCP é geralmente em torno de 5%.[4].
Figura 3 – Multiplexação de pacotes RTCP em uma transmissão UDP.
O formato do pacote RTCP depende da finalidade do pacote. O cabeçalho
sempre contém um campo de versão de 2 bits que deve coincidir com o campo de
versão do cabeçalho do RTP, um indicador padding, um campo de Payload de 8 bits e
um campo de comprimento de 16 bits. Outros campos podem estar presentes,
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 8/9
8/6/2019 Trabalho de IPTV Carlos Alexandre
http://slidepdf.com/reader/full/trabalho-de-iptv-carlos-alexandre 9/9
9
2. Referências Bibliográficas
[1] MOULTON, Pete. “Telecommunications Survival Guide”. U.S.A.: Prentice Hall
PTR, 2001.
[2] O´DRISCOLL, Gerard. “ NEXT GENERATION IPTV SERVICES AND
TECHNOLOGIES”, Wiley-Interscience, Canada, 2008.
[3] SCHULZRINNE, H. RFC 3550. “ RTP: A Transport Protocol for Real- Time
Applications”. RFC Editor United States, 2003.
[4] HENS, Francisco J., and Caballero José M. “ TRIPLE PLAY – Bulding the
Converged Network for IP, Voip and IPTV”, John Wiley & Sons, Ltd, England, 2008.
[5] SIMPSON, Wes. “VIDEO OVER IP – IPTV, Internet Video, H.264, P2P, Web TV,
and Streaming: A Complete Guide to Understanding the Technology”. Second Edition,
Focal Press, USA, 2008.
[6] POIKSELKA. MIIKKA; MAYER, GEORG; KHARTABIL, HISHAM ; NIEMI,
AKI. “ IMS IP Multimedia Concepts and Services in the Mobile Domain”. U.K.:, John
Wiley & Sons, 2004.
[7] <www.ietf.org/rfc/rfc1889.txt > Acesso em: 19 jun. 2011.