RTP/RTCP
| ||||
Protocolo RTP y RTCP: Real-time Transport Protocol (Protocolo en Tiempo Real) es una aplicación que envía contenido multimedia sobre la red en tiempo real, le debe agregar números de secuencia y marcas de tiempo a los segmentos antes de pasarlo a la capa de transporte.
Sumario
Utilidad
Estos son necesarios para reconstruir el contenido en el receptor sin tener que esperar a bajar el contenido completo (o una parte suficientemente grande). Es conveniente tener una estructura estandarizada de paquetes que tenga campos que indiquen el tipo de codificación, marcas de tiempo, número de secuencia y otros campos potencialmente útiles.
En el RFC 1889 se define el estándar RTP que cumple con las características mencionadas. Puede ser utilizado para transportar formatos comunes como WAV o GSM para audio y MPEG1 o MPEG2 para video. También permite utilizar formatos propietarios de sonido y video.
Historia
RTP fue en un principio diseñado para emisiones multicast de tráfico en tiempo real (aunque también se puede utilizar en emisiones unicast) y puede ser utilizado para el video bajo demanda y servicios interactivos tales como telefonía en Internet.
RTP ha sido diseñado para funcionar junto con el protocolo de control auxiliar RTCP para conseguir mantener la calidad en la transmisión de datos y proporcionar información sobre los participantes al iniciarse la sesión.
Características
El objetivo de RTP es que sea maleable y proporcionar la información requerida por una aplicación particular y normalmente será integrada dentro de la aplicación en vez de constituir un nivel separado. La intención de RTP es que sea adaptado a través de las modificaciones y/o adiciones de las cabeceras necesarias. Dentro de sus principales características se tienen:
- Se encapsula sobre UDP (TCP no sirve para aplicaciones de tiempo real).
- Usa puertos de usuario para cada medio que se transfiere.
- Puede enviar tramas generadas por cualquier algoritmo de Codificación: H261, MPEG-1, MPEG-2.
- Puede usarse con direcciones de destino unicast o multicast.
- Identifica los orígenes del tráfico, lo que permite reencapsular agrupando tráficos a mitad de camino.
- Incorpora marcas de tiempo para cada medio:
- Para sincronización intra-flujo (eliminar jitter).
- Para sincronización inter-medios (coincidencia audio/vídeo).
- Incluye números de secuencia para detectar pérdidas dentro de un flujo.
Cabecera de los paquetes
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.
- X (extensión), 1 bit: indica si a continuación viene una cabecera de extensión.
- CC (CSRC count), 4 bits: número de indentificadores CSRC que siguen a la cabercera fija.
- M (marker), 1 bit: está indicada para señalar elementos especiales como salirse de los límites.
- PT (payload type), 7 bits: formato de la información que se transporta para que lo interprete la aplicación.
- Número de secuencia, 16 bits: se incrementa en uno por cada paquete que se envía y sirve para que el receptor detecte pérdidas de paquetes.
- Timestamp, 32 bits: tiempo en el que se muestra el primer octeto de los datos transmitidos en el paquete.
- SSRC, 32 bits: identifica la fuente del paquete.
- CSRC, 32 bits: esta información es introducida por los mezcladores para indicar que han contribuido a modificar la información.
Protocolo RTCP
El protocolo RTCP (Protocolo de Control RTP) se basa en la transmisión periódica de paquetes de control a todos los participantes de la sesión, utilizando el mismo mecanismo de transporte que los paquetes RTP. Utiliza un puerto distinto que RTP, por lo general se utilizan puertos consecutivos donde el par es asignado a el flujo RTP y el impar al flujo RTCP.
Principales Funciones
- Feedback RTCP: es el encargado de la distribución de la información de realimentación
de la calidad de los datos. Uno podría tomar acciones para mejorar el rendimiento de la aplicación con esta información, por ejemplo cambiar la codificación, para disminuir la tasa de bits.
- Identificación: es necesario tener un identificador persistente a nivel de capa de transporte
para las fuentes RTP. Este identificador se llama Nombre Canónico. Dado que el SSRC puede cambiar debido a un conflicto o debido a el reinicio del programa, los receptores utilizan el nombre canónico para mantener una lista de los participantes de la sesión. También se utiliza para agrupar distintos streams de un participante, por ejemplo para sincronizar audio con video.
Control de Participantes: las funciones anteriores obligan a los participantes de la sesión a enviar periódicamente paquetes RTCP, la tasa de envío de esos paquetes tiene que ser controlada para permitir acceso a mas participantes. Dado que los participantes envían los paquetes de control a todos los demás participantes, cada uno observa localmente el número de participantes y calcula a partir de este número la tasa de envío de paquetes de control.
Cabecera de los paquetes
Cada paquete RTCP empieza con una parte fija que es similar a los paquetes de datos RTP, seguido por elementos estructurados que pueden ser de longitud variable de acuerdo con el tipo de paquete.
Para cumplir las funciones de este protocolo se imponen las siguientes condiciones:
- Las estadísticas de recepción (en SR o RR) deben ser enviadas tan a menudo como lo
permita el ancho de banda para maximizar la resolución de las estadísticas.
- Los nuevos receptores deben recibir el CNAME de una fuente tan pronto como sea
posible para identificar la fuente.
- El número de tipos de paquetes deben aparecer en el primer paquete para determinar
su tratamiento.
El intervalo de transmisión de paquetes RTCP debe ser calculado de forma que se permita tener sesiones que vayan desde pocos participantes a miles. Para ello, en cada sesión se asume que el tráfico de datos está sujeto a un límite denominado “ancho de banda de sesión” que se divide entre los participantes. Este ancho de banda debe ser reservado y limitado por la red. El parámetro de ancho de banda de sesión debe ser proporcionado por la aplicación de control de sesión. A partir de este valor y en función del número de participantes se calcula el intervalo con una formula empírica.
Fuentes
- [1]
- Protocolos para telefonía sobre IP.
