Início e popularização da Internet

Quando os browsers da Internet (ou Rede Mundial) surgiram, por volta dos anos 90, a única coisa que eles podiam exibir era texto, por isso em um primeiro momento, a Rede Mundial despertou muito pouco interesse. Então Mark Anderseen adicionou figuras aos browsers, e em seguida a Rede Mundial "explodiu". Os browsers de hoje são capazes de apresentar um deslumbrante conteúdo de multimídia inclusive interativa. Alguns dos tipos mais interessantes não envolvem só as três dimensões de espaço, que podem ser apresentadas em uma página, mas também a quarta dimensão, o tempo [7]. Outro motivo do sucesso da Internet é o "aponte e clique", fácil de usar, das interfaces de usuário, proporcionada pelo uso do HTML (HyperText Markup Language) e pela filosofia do conjunto de protocolos da rede mundial (World Wide Web abreviada por WWW) [20].

Filosofia cliente servidor na Internet

A forma tradicional de projeto dos sistemas da Rede Mundial, a filosofia cliente servidor, concentra-se na recepção de documentos. A arquitetura das informações que trafegam pela Rede Mundial é dirigida para documentos de natureza estática [20] (mesmo que de multimídia, neste caso o que acontece é que o cliente recebe separadamente arquivos de som e imagem por exemplo). Isto se deve ao uso de protocolos de transferências de arquivos orientado aos dados, como por exemplo o TCP (Transmission Control Protocol [12]). Atualmente os servidores de HTTP (HyperText Transfer Protocol) usam o protocolo de TCP exclusivamente para transferências de todos os tipos de documentos.

Limitações dos Protocolos da Internet

Por outro lado, a atual rede mundial não suporta aplicações tempo-real como as que podem existir em um documento multimídia. Um documento de multimídia pode conter tipos de mídia múltiplos. Algumas destas mídias são estáticas como textos, gráficos e imagens. Algumas são dinâmicas ou tempo contínuo, como áudio e vídeo. Mídia em um documento de multimídia tem relações temporais e de espaço específicas que devem ser mantidas durante apresentação para alcançar os efeitos desejados [3]. Se um receptor tem que esperar por uma retransmissão do TCP, pode haver um gap notável e inaceitável no playout de um documento multimídia [2]. Por outro lado no HTML atual, um vínculo se refere a uma página estática que poderia ser um arquivo de texto (possivelmente com imagens), uma imagem, um arquivo de áudio ou um arquivo vídeo. Não é possível um vínculo se referir a um arquivo de áudio e a um arquivo de vídeo simultaneamente e de modo sincronizado. É claro que se pode tratar um clipe exatamente do mesmo modo que se trata uma página grande (em bytes) na Web (apelido para WWW). Pode-se fazer o download do arquivo de multimídia e "toca-lo" exatamente como foi gravado antes do download. O problema com esta aproximação é o tempo gasto para fazer o download de um clipe. Comumente este tempo é muito longo em comparação ao tempo de duração do clipe [7]. Assim esta aproximação impede a propagação de conteúdo em tempo-real, e desencoraja o usuário que freqüentemente tenta o acesso este tipo de informação. Para prover o suporte aos arquivos de multimídia dinâmica todos os componentes da Rede Mundial (servidores, browsers, etc.) necessitam ser atualizados [3].

As Soluções para Transmissão de Arquivos de Multimídia na Internet e a Definição de jitter

Experiências têm mostrado, entretanto, que é possível a transmissão de áudio e vídeo pela Internet mediante a escolha de protocolos (maneiras) adequados. Um modo melhor para transportar áudio e vídeo na Web é trata-los como um fluxo. Neste conceito um meta-arquivo de um documento de multimídia conteria detalhes de fluxos de mídia do documento, os URLs (Universal Resource Locator) e relações temporais e de espaço. Com esta informação o cliente poderia enviar um pedido de fluxo ao servidor apropriado em um dado momento. Desta forma, logo após os dados de mídia começarem a chegar ao cliente, as informações podem começar a ser apresentadas ao usuário de acordo com as especificações temporais e de espaço, e continuarem a ser apresentadas enquanto existir o fluxo [20] [9] [7]. Ressalta-se que no cliente deveriam ser reservados recursos computacionais de acordo com as mídias a serem apresentadas. Por outro lado se alguns pacotes do fluxo começam a chegar cedo ou tarde, uma condição conhecida como jitter, o resultado visto pelo usuário pode não ser satisfatório [2].

Servidores, o "gargalo" da Internet e a Definição de multicast

Freqüentemente o gargalo neste tipo de transmissão é o servidor. Em um determinado servidor podem haver centenas de clientes. O servidor aceitará os pedidos das centenas de clientes não importa o quanto ocupado ele esteja, e atenderá a todos de acordo com a taxa de congestionamento e sua capacidade de processamento [2]. A referida taxa varia a todo tempo. Isto é inaceitável para arquivos de multimídia que necessitam de uma taxa fixa de transmissão, preferencialmente igual à taxa natural de exibição do arquivo. A entrega deste tipo de conteúdo só fica prática quando mais de um cliente pode compartilhar o mesmo fluxo. A isto dá-se o nome de multicast [3].

MBone e seu Formato

onde, neste caso, a transmissão teria um TTL (Time To Live) de 127; um endereço de multicat sendo 224.2.252.51; um endereço de porta 4739; e um nv indicando o formato da transmissão [20] (por exemplo: h.261). Esta forma se deve ao fato de que o cliente não tem nenhuma necessidade de se comunicar com um servidor HTTP para começar uma sessão, o que parece satisfatório, começar uma sessão de multicast sem uma página de HTML. Mas, ao mesmo tempo que esta idéia parece boa ela pode criar URLs muito indesejável. Por exemplo, Mark Handley (do IETF - Internet Engineering Task Force) sustenta que definir uma sintaxe de URL para mídia de tempo-real é uma idéia ruim[2]. O URL contendo sessão de multicast, formato de mídia, etc., é muito longo, e são tipicamente desnecessários dependendo do protocolo em uso. Além disso, os dados do fluxo de multimídia especificada no URL é insuficiente para múltiplos fluxos de vídeo sincronizados embutidos em um documento de HTML [2](no caso de querer-se múltiplos arquivos de multimídia com por exemplo texto, áudio e video). O IETF acredita ser prematuro definir um protocolo multicast para a Internet [2] (pois este teria implicações importantes e perigosas para a operação global da Web). Atualmente o que o IETF recomenda é o uso de um URL normal. Um exemplo da aplicação do URL na forma normal com arquivos de multimídia são as implementações propostas para o IP/TV[2].

A Melhoria na Eficiência dos Servidores

Um servidor que implemente um Protocolo de Tempo-real, tolerante a faltas na transmissão, com controle da taxa de reconstrução da mídia em resposta ao carregamento CPU do cliente ou ao congestionamento na rede (criando buffers para cada quadro reduzindo o problema do jitter), e também com controle dinâmico das características do protocolo em função do meta-arquivo em transmissão (resincronizando periodicamente o playback), estará apto a servir aplicações de áudio e vídeo (bem como outras) em tempo-real. Para serem organizados e guardados de modo eficiente, os arquivos de multimídia podem ser armazenados em diferentes servidores na Internet [3]. É desejável também que quando um documento de multimídia é solicitado, todas as mídia sejam recuperadas de servidores apropriados, transmitidas e apresentadas sincronizadamente (de acordo com as especificações temporais e de espaço) para o usuário, depois de uma pequena latência.

Garantia da Qualidade de Serviço na Internet

O assunto crítico na comunicação de multimídia é como prover garantia de desempenho e ao mesmo tempo como usar recursos de sistema (banda passante na rede, velocidade da CPU, capacidade de armazenamento, etc.) eficazmente tirando proveito da natureza de uma certa tolerância ao erro que as mídia contínuas admitem. A garantia de desempenho e da qualidade de serviço é o que atualmente é abreviado por QoS. No modelo de QoS, uma aplicação especifica suas exigências que são submetidas ao sistema. O sistema determina se tem recursos suficientes para satisfazer às exigências. Se tiver, aceitará a aplicação e alocará os recursos necessários para servi-la. Se o sistema não possui os recursos suficientes para satisfazer às exigência da aplicação, este ou pode rejeitar a aplicação ou pode sugerir exigências de QoS mais baixas. No segundo caso, se a aplicação aceitar os novos parâmetros de QoS, o sistema alocará os tais recursos e executará a aplicação. Em caso contrário a aplicação será rejeitada, e poderá tentar novamente um tempo depois na esperança de que alguns recursos a mais possam então estar disponíveis. Servidor, protocolos de transporte, sincronização, recursos do cliente, em fim todas as partes do sistema devem ser gerenciados em diferentes níveis para garantia de QoS. Atualmente não há nenhum sistema que integre e gerencie eficientemente e satisfatoriamente todos estes componentes para prover a garantia de QoS à aplicações de multimídia via Internet [3].

Protocolo para Aplicações com Características de Tempo-real em Uso na Internet

Um protocolo, que já se tornou padrão de fato, para transportar aplicações em tempo-real é o RTP (Real Time Protocol), que foi estabelecido pela RFC (Request for Coment) 1889 do IETF (Internet Engineering Task Force) datada de 1992. O RTP mantém um fluxo fixo e controlado de dados entre servidor e cliente, apesar de condições variadas de congestionamento da Rede Mundial ou atrasos na transmissão. Os pacotes de dados deste protocolo possuem datação. A transmissão é monitorada por um outro protocolo relacionado, o RTCP (Real Time Control Protocol). O RTP não é um protocolo completo na medida em que não especifica as formas de tratamento dos diferentes tipos de mídias. Uma alternativa para isso é a utilização de outros protocolos sobre o RTP como por exemplo o LRMP (Lightweight Reliable Multicast), de Web câmeras, para mídias de vídeo [2]. Ressalta-se entretanto que o RTP não possui recursos para a garantia de QoS. A desvantagem do uso do RTP é a de se ter que gerenciar mais um protocolo. A vantagem do uso do RTP é a não necessidade de modificações no atual HTTP[2]. Existem entretanto implementações, inclusive comerciais, que introduzem modificações nas especificações do RTP. Possivelmente as mais conhecidas dessas implementações são os VDP, SIP, SDP (Session Description Protocol), SAP (Session Announcement Protocol), RTSP (Real Time Streaming Protocol), entre outros.

Conclusão da Introdução e Histórico

O assunto da transmissão de multimídia tempo-real na Internet não é novo, nem tão pouco trivial. Em janeiro de 1996 o W3C (World Wide Web Consortium) iniciou as atividades no sentido de prover uma direção para as futuras padronizações para multimídia tempo-real na Web [2]. Outro fato notório ocorreu em 1995 quando Vinary Kumar apresentou seus trabalhos sobre implementação de multicast no browser Shared Mosaic.

Protocolo em seu Sentido mais Amplo

Protocolo é: 1. Registro de uma conferência ou deliberação diplomática. 2. Formulário que regula os atos públicos. 3. Convenção entre duas nações. 4. Cerimonial, formalidade [19]. Nesta mesma linha o termo protocolo, em comunicação de dados é: um conjunto formal de convenções que governam o formato e o tempo relativo de troca de mensagem em um processo de comunicação [11].

Protocolos do Tipo "de Transporte"

Um protocolo de transporte é um protocolo utilizado pela camada 4 do modelo OSI/ISO (esta camada é denominada de transporte ou de segmento). São exemplo de protocolos desta camada o TCP, UDP (User Datagram Protocol) e o RTP. Os protocolos que atuam nesta camada garantem a integridade dos dados de ponto a ponto [12].

Generalidades

O termo tempo-real descreve uma aplicação que exige de um programa computacional uma resposta a estímulos dentro de algum limite superior de tempo de resposta. O controle de processo em uma planta química é o exemplo canônico [6]. Tais aplicações requerem freqüentemente sistemas operacionais especiais e velocidade de processamento. Em outras palavras tempo-real significa que ambos hardware e software devem ser capazes de interagir com eventos físicos externos ao próprio computador, e esta interação deve ser suficientemente rápida para capturar e preservar a informação essencial associada ao evento. Em alguns casos, o computador deve poder também fazer um cálculo rápido de alguns dados de resposta que podem ser aplicados como realimentação para controlar eventos subseqüentes. Naturalmente, esta definição de tempo-real significa que os requisitos para o sistema de computação dependem da velocidade dos processos externos em questão [8]. Um sistema que aquisita dados sobre a energia solar pode ser dito de tempo-real, mas as exigências de tempo são menos severas do que as necessárias para controlar o vôo de uma astronave ou avião.

Na Aquisição de Dados

Em termos de aquisição de dados, será sempre computacionalmente complicado aquisitar dados de sistemas ou processos físicos com variações muito lentas (por exemplo: uma variação significativa a cada ano) ou muito rápidas (por exemplo: 1 milesegundo) [13].

Pelo acima exposto nota-se que a definição de tempo-real ganha conotação quantitativa somente quando associada a uma aplicação específica [10].

Em Processamento Digital de Sinais

Em um sistema analógico toda tarefa é executada em tempo-real com um contínuo processamento. Em um sistema DSP (Digital Signal-Processing), os sinais analógicos são representados por um conjunto de amostras, isto é, valores em pontos discretos do tempo. Assim o tempo para processar um determinado número de amostras em um sistema de DSP pode ter uma interpretação arbitrária em termos de tempo-real e pode depender da taxa de amostragem. Considerar um sistema como operando em tempo-real, significa considerar que todo o processamento de um determinado conjunto de dados (uma ou mais amostras, dependendo do algoritmo) deve ser completado antes da chegada dos dados da nova amostragem [4].

Em Tecnologia da Informação

Em informática a vedete nas discussões quanto a tempo-real em desktops são os sistemas operacionais. Nesta área existe uma subdivisão no conceito de tempo-real, tempo-real flexível (executa interrupções na casa dos segundos) e tempo-real inflexível (executa interrupções na casa dos mili ou microsegundos) [10]. Sistemas operacionais como o MI-RI da Mitsubishi Eletric ou o VxWorks da Wide River Systems são considerados de tempo-real inflexível (apresentam resposta a interrupções na casa dos 1 ms ou menos). A Microsoft anunciou em 1998 que estaria trabalhando para tornar o Windows CE um sistema operacional de tempo-real inflexível [10]. Entretanto testes realizados em plataformas comuns (Pentium 200 MHz), em 1999 com a atual versão do Windows CE reportam tempos entre interrupções na casa dos 20 ms [5]. Os defensores do Windows CE passaram a utilizar o termo tempo crítico em alusão ao tempo, do ponto de vista do processo, tolerável para se tomar uma atitude de controle; por exemplo, afirmam que 20 ms é muito inferior ao tempo crítico de muitos processos [5].

Introdução

O protocolo de transporte RTP provê serviços de entrega de ponto a ponto para dados com características de tempo-real como áudio e vídeo interativo. Aplicações típicas rodam RTP sobre o UDP/IP fazer uso dos seus serviços de multiplexação e checksum. Porém, RTP pode ser usado com outros protocolos de transporte. O RTP suporta transferência de dados à destinos múltiplos usando a distribuição por multicast se disponível na rede.

O RTP e a Garantia da Qualidade de Serviço

Note que o RTP não provê nenhum mecanismo para assegurar o tempo de entrega ou outras garantias de qualidade de serviço (QoS). O RTP também não garante entrega ou previne entrega fora de ordem. Por outro lado ele não assume que a rede seja fidedigna e entregue os pacotes em seqüência.

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.

RTP & RTCP

O RTP esta associado ao RTCP, que monitora a qualidade de serviço e carrega informações sobre os participantes.

Limitações e Expansões do RTP

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 um camada diferente da de aplicação. Devido às definições anteriores nota-se que o RTP esta deliberadamente incompleto na RFC 1889. Para torna-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ções do RTP

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 desenvolvedores devem tomar as precauções apropriadas para limitar uso de uma banda passante acidentalmente muito larga.

Exemplos de Aplicação Ilustrando o Funcionamento do RTP

A seguir descreve-se alguns aspectos do uso de RTP. Os exemplos foram escolhidos para ilustrar a operação básica de aplicações que usam RTP, não limitando entretanto o campo para o qual RTP pode ser usado. Nestes exemplos, RTP "roda" sobre o UDP/IP, e segue as convenções estabelecidas pelo perfil para áudio e vídeo específicos para Internet.

Áudio-Conferência

Supõe-se que um grupo de pessoas resolva fazer uma reunião por comunicação de voz utilizando a Internet. Por algum mecanismo de distribuição disponível na Web o grupo obtém um endereço de multicast e um par de portas (Nota: o termo porta aqui é utilizado como uma abstração que protocolos de transporte usam para distinguir entre destinos múltiplos dentro de um mesmo computador. O TCP/IP usa inteiros positivos pequenos. O RTP depende do protocolo de camada mais baixa para prover algum mecanismo, como portas, para multiplexação e identificação dos participantes de uma conferência). Uma porta é usada para dados (áudio), e outra é usada para os pacotes de monitoramento (RTCP). Este endereço e o número das portas são distribuídos aos participantes. Se é desejada a privacidade, os dados podem ser codificados (encriptados). Os detalhes exatos do mecanismo de encriptação e distribuição das chaves não é contemplado no RTP.

Se os membros da conferência estão trabalhando em grupo será útil saber quais membros então participando da conferência a qualquer momento e quão bem eles estão recebendo os dados de áudio. Para este propósito, a cada instante da conferência a aplicação envia mensagens multicast com um relatório de recepção mais o nome de seu usuário na porta de RTCP (monitoramento). O relatório de recepção indica quão bem o locutor atual está sendo recebido e pode ser usado para controlar codificações adaptáveis. Além do nome de usuário, pode ser incluída também outra informação identificando ou sugerindo os limites de banda passante.

Quando um dos membros deixa a conferência, envia pelo RTCP um pacote com BYE.

Conferência Áudio-Visual

Uma motivação para esta separação é permitir que alguns participantes da conferência recebam, se desejarem, só uma das mídias. Apesar da separação, o sincronismo do playback de uma fonte áudio e de outra de vídeo pode ser alcançado usando-se a datação dos pacotes de ambas as seções.

Mixers no RTP

Até o momento assumiu-se que todos os locais recebem dados de mídia no mesmo formato. Porém, isto pode não ser apropriado. Considere o caso onde alguns participantes estão conectados por um links de baixa velocidade, enquanto que a maioria dos participantes da conferência desfrutam de um acesso de rede em alta velocidade. Em vez de forçar a todos um link menos velos, reduzindo a qualidade de áudio (por exemplo), um dispositivo previsto no RTP, chamado de mixer, pode ser colocado na interface com o link de baixa velocidade. Este mixer promove a resincronização e reconstrução de pacotes mixando diferentes fluxos e mudando codificações dos pacotes, e finalmente, criando novo fluxo mais adequado ao link de baixa velocidade. Note que os fluxos de entrada no mixer podem não estar sincronizados mas o mixer enviará à sua saída pacotes devidamente sincronizado, fazendo todos os ajustes necessários na codificação das informações. Assim todos os pacotes RTP que se originam de um mixer o terão como fonte de sincronização. O cabeçalho do RTP inclui meios para que o mixer identifique as fontes que contribuíram a um determinado pacote misturado-as de forma que a correta indicação do(s) locutor(es) pode ser informada aos receptores. Os novos pacotes podem ser distribuídos por endereços unicast a um único receptor ou por endereços multicast para receptores múltiplos.

Tradutores no RTP

Quando um participante ou participantes encontram-se em uma rede local protegida por um firewall que não deixará passar nenhum endereço IP para dentro da rede local, um novo dispositivo, chamado tradutor, é previsto pelo RTP. São instalados dois tradutores, um em cada lado do firewall. Do lado exterior o tradutor abre os pacotes e os envia ao firewall sem o endereço IP de multicast externo. Do lado de dentro o tradutor reconstrói os pacotes e os envia novamente como pacotes de multicast para o grupo de participantes internos à rede local. O tradutor pode incluir rotinas de conversão de modos de codificação dos sinais sem mixa-los, replicando-os para transmissão em outro endereço multicast ou em vários endereços unicast.

Outras Aplicações para Mixers e Tradutores no RTP

Podem ser projetados mixers e tradutores para uma grande variedade de propósitos. Um exemplo é um mixer de vídeo que seleciona as imagens de pessoas individuais em fluxos de vídeo separados e as combina em um fluxo de vídeo similar a uma cena de grupo. Outros exemplos de tradução incluem a conexão de um grupo que fala só UDP/IP para um grupo que só entende outro tipo de protocolo de transporte.

O Formato do RTP

Os primeiros doze octetos estão presentes em todo pacote de RTP, enquanto a lista de identificadores de CSRC só está presente quando inserida por um mixer. Os campos têm o significado seguinte:

Definição dos Campos do Cabeçalho do RTP

Padding (P): 1 bit. Se o bit padding estiver setado, o pacote contém um ou mais octetos adicionais no final do cabeçalho que não é parte do payload. O padding pode ser necessário para alguns algoritmos de encriptação com tamanhos de bloco fixos ou para levar vários pacotes de RTP a outros tipos de protocolos de camada mais baixas.

Tipo de payload (PT): 7 bits. Este campo identifica o formato do payload carregado pelo RTP e determina sua interpretação pela aplicação. Este campo não deve ser utilizado para multiplexação de fluxos de mídia separados.

Datação: 32 bits. A datação reflete o momento da amostragem do primeiro octeto do pacote de dados RTP. O momento deve ser obtido de um relógio que incremental monotonicamente e linearmente permitindo a sincronização contemplando os problemas de jitter. A resolução do relógio deve ser suficiente para a precisão de sincronização requerida pelo tipo de mídia (playload). O valor inicial da datação é fortuito, como o número seqüencial. Vários pacotes de RTP sucessivos podem ter datação igual se eles forem (logicamente) dependentes, por exemplo, pertençam ao mesmo quadro de vídeo. Pacotes de RTP sucessivos podem conter datação não monotonica se o dados não são transmitido na ordem em que foram amostrados, como no caso de MPEG que interpola quadros de vídeo. A datação é feita em segundos. O referencial (tempo absoluto) é o mesmo do Protocolo de Tempo de Rede (NTP) e é relativo à 0h UTC de 1 de janeiro de 1900. A resolução da datação, prevista no RTP, é de, no máximo, 64 bits com numeração decimal de ponto fixo sem sinal. A parte inteira ocupa os primeiros 32 bits e a parte fracionária os últimos 32 bits. Em aplicações com menores exigências quanto ao tempo podem ser utilizados apenas os 32 bits medianos, isto é, a parte inteira ocupa os últimos 16 bits a ela reservada antes do ponto, e a parte fracionária ocupa os próximos 16 bits após o ponto. Os primeiro 16 bits da parte inteira podem ser determinados independentemente da aplicação (se ela assim o permitir).

SSRC: 32 bits. O campo de SSRC (Synchronization SouRCe ) identifica a fonte de sincronização. Este identificador é fortuitamente escolhido, com a intenção de que duas fontes de sincronização dentro da mesma seção de RTP tenham o mesmo identificador de SSRC. Embora a probabilidade de fontes múltiplas que escolherem o mesmo identificador seja baixa, todos as implementações de RTP devem estar preparadas para descobrir e solucionar colisões. Se uma fonte muda seu endereço de transporte, também tem que escolher um identificador de SSRC novo para evitar ser interpretada como uma fonte em laço. Todos os pacotes RTP possuem um SSRC para que o receptor possa reconstruir as informações de mídia e apresenta-las ao usuário de modo sincronizado. Exemplos de fontes de sincronização incluem o remetente de um fluxo de pacotes derivado de uma fonte como um microfone ou uma máquina fotográfica, ou um mixer de RTP. Se um participante gera fluxos múltiplos em uma seção de RTP, por exemplo de câmeras separadas, cada fluxo deve ser identificado como um SSRC diferente.

lista CSRC: de 0 a 15 itens, 32 bits cada. Em uma conferência vários fluxos podem ser mixados em um mesmo pacote RTP. A lista de CSRC (Contributing SouRCe) identifica as fontes contribuintes do payload contido no mesmo pacote. Se há mais de 15 fontes contribuintes serão identificados apenas 15. Os identificadores na lista de CSRC são inseridos por mixers e usam os identificadores de SSRC das fontes contribuintes. Por exemplo, para pacotes de áudio são listados os identificadores de SSRC de todas as fontes que foram mixadas para criar um pacote, o que permite a correta identificação do locutor pelo receptor. Um exemplo aplicação de é uma áudio-conferência onde um mixer indica todos os locutores cujas falas foram combinadas para produzir o pacote de saída do mixer, e permitindo ao receptor identificar o locutor atual, embora todos os pacotes auditivos contenham o mesmo identificador de SSRC (o do mixer).

Playload: É o dado transportado pelo pacote de RTP, por exemplo um arquivo de áudio ou de vídeo compactado. As interpretações do playload não são definidos pelo (ou no) RTP.

Multiplexação de Seções do RTP

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 demultiplexadas no receptor.

Modificações nas Especificações do Cabeçalho do RTP por Arquivos de Perfil

Acredita-se que o cabeçalho de RTP contem todas as informações necessárias para prover o suporte a todas as aplicações que necessitam do conceito de tempo-real. Porém, o cabeçalho pode ser adaptado, por modificações ou adições definidas em uma especificação no arquivo de perfil, para uma aplicação em especial. Por exemplo, se determinada codificação de vídeo não implementa (não inclui no playload) as informações necessárias para sua decodificação, estas poderão ser enviadas no cabeçalho do RTP.

Se uma classe particular de aplicações necessita de funcionalidades adicionais independentes do formato do payload, o arquivo de perfil debaixo do qual essas aplicações operam pode definir campos fixos adicionais imediatamente após o campo de SSRC do cabeçalho fixo existente. Essas aplicações usarão esta parte do cabeçalho enquanto que outras aplicações padrão simplesmente descartar tais campos adicionais. Se uma nova funcionalidade é necessária em comum a todos os perfis, então uma versão nova de RTP deveria ser definida para fazer uma mudança permanente na parte fixa do cabeçalho.

Extensão do Cabeçalho do RTP

Note que esta extensão possui limitações quanto ao uso. A maioria dos usos potenciais deste mecanismo seriam melhor 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.

Introdução

O protocolo RTP de "controle" (RTCP) está baseado na transmissão periódica de pacotes com informações úteis ao controle de fluxo a todos os participantes da seção, usando o mesmo mecanismo de distribuição dos pacotes de dados. O RTCP executa quatro funções:

Funções Desempenhadas pelo RTCP

1. A função primária é prover a realimentação da qualidade da distribuição de dados. A realimentação pode ser útil para controle de codificações adaptáveis, mas experiências com multicast mostraram que também é crítico obter realimentação dos receptores para diagnosticar faltas na distribuição. O envio de realimentação por todos os participante é útil para avaliar se determinado problema é individual ou global. Com um mecanismo de distribuição como multicast de IP, é também possível para uma entidade como um provedor de serviço de acesso que não esta envolvido na seção de RTP receber a informação de realimentação e agir como um monitor para diagnosticar problemas de rede.

As funções de 1 a 3 são obrigatórias quando RTP é usado em um ambiente IP multicast, e é recomendado para todos os ambientes. É aconselhável evitar implementações unicast.

Tipos de Pacotes RTCP

Tipos adicionais de pacotes RTCP podem ser registrados na IANA (Internet Assigned Numbers Authority).

Regras Quanto ao Uso dos Pacotes RTCP

Os receptores novos precisam receber o campo CNAME o mais cedo possível para identificar fontes de fluxo.

Relatório Tipo SR

Padding (P): 1 bit. Se o bit padding estiver setado, este pacote de RTCP contém octetos adicionais. Iste campo pode ser utilizado por alguns algoritmos de encriptação.

Valor de jitter: 32 bits. Uma estimativa estatística da discrepância entre o tempo "impresso" pacote RTP de dados e o momento em que este foi recebido.

Variação de tempo do último SR (DLSR): 32 bits. A demora entre o recebimento do último SR da n-ésima fonte e o envio deste relatório.

Relatório Tipo RR

Relatório Tipo SDES

Contador de fonte (SC): 5 bits. O número de pedaços de SSRC/CSRC contidos neste pacote de SDES.

Relatório Tipo ADEUS

Contar de fonte (SC): 5 bits. O número de identificadores incluidos neste pacote de ADEUS.

Relatório Tipo APP

Dados dependentes da aplicação: tamanho variável de dados. Neste campo são inseridos os dados da Aplicação.

Durante as pesquisas para a realização do trabalho pode-se notar também que o RTP é um protocolo que tornou-se padrão de fato por ser implementado em vários outros protocolos de outras entidades (em particular os protocolos do ITU-T) [15].

Por outro lado também pode-se notar que o RTP necessita mesmo de complementos para o transporte de mídias. Isto aliás aparentemente levou os desenvolvedores e a própria IETF a escrever ou normalizar outros protocolos similares e muitas vezes mais próximos do HTTP.

Agradecimentos: aos colegas da Intertechne, do departamento de tecnologia da informação e do departamento de engenharia elétrica, pelos debates esclarecedores e pelas referências bibliográficas indicadas.