3.0 - RTP

            O RTP ou Protocolo de Transporte em Tempo Real (Real-Time Transport Protocol) foi apresentado formalmente em janeiro de 1996 pelo Grupo de trabalho de Redes (Networkig Working Group) do IETF (Internet Engineering Task Force) com objetivo de fornecer uma padronização de funcionalidades para os aplicativos de transmissão de dados em tempo-real como vídeo, áudio, tanto em redes unicast como nas multicast, sem entretanto garantir a qualidade de serviço QoS ou reservar recursos de endereçamento.
 O RTP roda sobre a camada UDP/IP utilizando os serviços de multiplexação e cheksum do UDP estabelecendo uma comunicação fim a fim. As porções de áudio e vídeo produzidas pelo aplicativo remetente são encapsuladas em pacotes RTP que por sua vez são encapsulados em um segmento UDP. Entretanto, apesar de utilizar o UDP e o IP, o RTP pode ser implementado em outros ambientes já que necessita apenas de serviços de transporte não orientado à conexão.
Normalmente, o RTP é implementado como parte da aplicação e não como parte do Kernel do sistema operacional. Basicamente, o protocolo permite a especificação dos requisitos de tempo e conteúdo pertinentes à transmissão de multimídia, tanto no envio quanto da recepção através de:

- numeração seqüenciada,
- selo de temporização (estampilho),
- envio de pacotes sem retransmissão,
- identificação de origem
- identificação de conteúdo,
- Sincronismo.
 

Mais especificamente:

 Numeração seqüenciada: o RTP atribui número de ordem aos pacotes. Isto pode ser usado para verificação das perdas, seqüenciamento e possível redirecionamento de pacotes.

Selo de temporização (estampilho):  possibilita a correta temporização dos pacotes contendo áudio e/ou vídeo.

Envio de pacotes sem retransmissão: característica fundamental das transmissões em multimídia, pequena perdas não ofendem a qualidade do envio e a não retransmissão torna o sistema mais robusto. O RTP apenas permite ao receptor notar as perdas e ou atrasos.

Identificação de origem: Necessário para indicar quem enviou o pacote. Numa conferência multicast, um mesmo fluxo pode ter várias origens.

Identificação de conteúdo:  permite a alteração dinâmica dos vocoders em redes sem garantia de QoS em função das perdas e do atraso a fim de melhorar a qualidade final acústica.

Sincronismo: pacotes de um mesma corrente podem sofre diferentes atrasos. A variação deste atraso é prejudicial à reprodução da mídia. Buffers adicionais podem então ser utilizados para eliminar a diferença entre os atrasos (jitter). Esses mecanismos processam de informações de tempo de cada pacote. RTP provê esta informação.

 Apesar de todas essas vantagens, o RTP ainda não possui componentes de segurança e nem monitora a transmissão nem a recepção dos pacotes. Essa última tarefa é realizada pelo RTCP – item 4.0.
 

PRÓXIMO
ANTERIOR
 PRINCIPAL