Header de rtp

RTP
PROTOCOLO PARA APLICACIONES MULTIMEDIALES
Versión 1.01

4. Formato del header

La siguiente figura muestra el header utilizado por el protocolo RTP.

Los primeros 12 octetos (es decir, los campos V, P, X, CC, M, PT, sequence number, timestamp y SSRC) SIEMPRE están presentes, en tanto que los identificadores de "fuentes contribuyentes" (nodos que generan información al mismo tiempo para, supongamos, una videoconferencia) son utilizados sólo en ciertas circunstancias. Después del header "básico" puede tenerse extensiones opcionales para el header (Extension header).

Finalmente el header es seguido por los datos (payload) que transporta RTP y su formato es definido por la aplicación.

El diseño del header de RTP busca llevar sólo aquellos campos que son necesarios para diversos tipos de aplicaciones.

V (versión), 2 bits: Los primeros dos bits identifican la versión del protocolo.
P (padding), 1 bit: El siguiente bit identifica el padding. Informa que los datos de RTP llevan un "relleno" para completar un bloque de cierto tamaño. El último byte en el mensaje UDP dice de qué tamaño es el padding

Con esto se cumple el objetivo de tener un header RTP pequeño. La longitud de los datos se calcula a partir de la información del header del protocolo de la capa inferior (UDP en este caso).
X (extension), 1 bit: El bit de extensión es utilizado para indicar la presencia de un header de extensión que puede ser definido para una aplicación específica y sigue al header principal. Ese tipo de headers son utilizados en raras ocasiones ya que es posible definir un header dentro de los datos (payload) como parte de la definición del formato de los datos para una aplicación en particular.
CC (CSRC count), 4 bits: El bit X es seguido por 4 bits (CC) que cuentan el número de "fuentes contribuyentes" incluidas en el header de RTP (en caso de que existan dichas fuentes).
M (marker), 1 bit: Este bit es utilizado para indicar el frame. Por ejemplo, puede indicar el inicio de una conversación en RTP: el primer frame.
PT (payload type), 7 bits: Los siguientes 7 bits indican qué tipo de dato multimedial se está transportando (payload type). Un posible uso de este campo es permitir a una aplicación pasar de un esquema de codificación a otro basado en la información sobre la disponibilidad de recursos en la red. El uso exacto del bit "marker" (M) y del "payload type" (PT) dependen del perfil (profile) de la aplicación. El payload type NO se usa como llave de demultiplexamiento para dirigir los datos a una aplicación diferente; ese demultiplexamiento lo realiza el protocolo de la capa inferior: UDP. Dos streams de datos multimediales diferentes utilizan números de puerto diferente.
Sequence number, 16 bits: El número de secuencia es utilizado para permitir al receptor de un stream RTP detectar paquetes perdidos o que lleguen en desorden. Observe que RTP no indica qué hacer cuando se pierde un paquete (muy diferente a TCP que corrige la perdida -por retransmisión- e interpreta la perdida como un indicador de congestión -que puede llevar a reducir el tamaño de la ventana en TCP-). Por el contrario, RTP deja que la aplicación decida qué es lo mejor que puede hacer cuando el paquete se pierde.
Timestamp, 32 bits: El campo de timestamp permite al receptor reproducir (playback) las muestras en los intervalos de tiempo apropiados y permite que diferentes media streams se puedan sincronizar. RTP no especifica en que unidades se debe enviar este timestamp -las aplicaciones y sus formatos requieren diferentes granularidades en tiempo-. El timestamp viene a ser un contador de "ticks" donde el tiempo entre "ticks" depende del formato de codificación de la aplicación (la granularidad del reloj es uno de los detalles que se especifica en el profile de RTP o en los datos -payload- de la aplicación).
SSRC, 32 bits: El identificador de fuente de sincronización (SSRC) es un número de 32 bits que identifica de manera única una sola fuente en un stream RTP. En una conferencia multimedial, cada emisor escoge un SSRC aleatorio. El identificador de fuente es diferente de la dirección IP o del número de puerto, que permite, por ejemplo, que un nodo con múltiples fuentes (un equipo con varias cámaras) distinga cada una de las fuentes. Cuando un sólo nodo genera diferentes media streams (por ejemplo, audio y video al mismo tiempo), no es necesario que utilice el mismo SSRC en cada stream ya que RTCP tiene un mecanismo para hacer sincronización intermedia.
Lista CSRC, de 0 a 15 elementos, cada uno de 32 bits: El identificador de fuente contribuyente (CSRC) es utilizado sólo cuando varios streams RTP pasan a través de un mezclador (mixer). Un mezclador puede ser utilizado para reducir los requerimientos de ancho de banda para una conferencia recibiendo datos de muchas fuentes y enviando estas como un sólo stream. El número de identificadores incluidos en el header RTP viene colocado en el campo CC (CSRC count). Si hay más de 15 fuentes contribuyentes, sólo 15 pueden ser identificadas.

[Anterior] [Índice] [Siguiente]