Análisis de los protocolos de tiempo real en Ethernet RTP, RTCP y RTSP.

Manuel Flores VivasSistemas en Tiempo Real, curso 2006/2007 – E.T.S.I. Informática

Universidad de Málagae-mail: manuelfloresv{at}gmail{.}com

Resumen— En este documento se estudian los diferentes protocolos de tiempo real para el envío y recepción de contenidos multimedia en tiempo real a través de Internet.

I. INTRODUCCIÓN

Desde que la informática se introdujo en el hogar y aparecieron las primeras GUIs (Interfaces Gráficas de Usuario) los contenidos multimedia han estado presentes tanto en equipos domésticos como en estaciones de trabajo. Y desde hace unos años, también en teléfonos móviles, reproductores portátiles o videoconsolas.

¿Como se representan audio y vídeo en el ordenador? [6]

Los archivos de audio se almacenan comprimidos por medio de algoritmos basados en la técnica PNS (norma de percepción del ruido), es decir, aprovechan ciertas frecuencias que el ser humano no reconoce y otras que reconoce mejor.

La compresión de sonido elimina frecuencias imperceptibles sin alterar de forma significativa lo que se escucha, pero reduciendo considerablemente el tamaño del fichero.

Entre los formatos mas comunes, se encuentran: AAC (Advanced Audio Coding), WAV, AU (Audio for Unix), WMA (Windows Media Audio), MIDI (Musical Instrument Digital Interface), MPEG (Moving Pictures Experts Group), AC3, RealAudio, RealVideo, OGG Vorbis, ATRAC (Adaptive TRansform Acoustic Coding) o AVI (Audio Video Interleave).

Hasta aquí se ha hablado de ficheros multimedia para ser almacenados en diferentes soportes; pero desde la creación de Internet, y con el aumento en el número de nodos y de la velocidad de la red, han aparecido tecnologías como la radio por Internet, videoconferencias, vídeo bajo demanda, VoIP (voz sobre IP), televisión por Internet o emisiones en directo. Y todos estos servicios requieren que el envío y la recepción de los datos se produzcan en tiempo real, para así poder ser reproducidos al momento y sin interrupciones.

Para que estas transmisiones puedan realizarse en tiempo real, se necesita de nuevos protocolos, formatos, estándares, algoritmos y aplicaciones en los que se profundizará en las siguientes secciones.

En la sección II se hará un breve repaso a la historia del transporte de audio y vídeo sobre Internet.

La sección III profundizará en la pareja de protocolos RTP (Real Time Protocol) y RTCP (Real Time Control Protocol).

En la sección IV se analizará el protocolo RTSP (Real Time Streaming Protocol).

En la sección V, se estudiarán diferentes implementaciones: Hardware, Software y APIs.

Y por último, la sección VI expone las conclusiones de este trabajo.

II.HISTORIA

Los primeros esfuerzos en transmitir audio sobre Internet sobre los protocolos IP y ST-II se remontan a los años 70.

Se hacen demostraciones entre USC/ISI (University of Southern California), MIT/LL (Lincoln Laboratory, Massacchusetts Institute of Tecnology), CHI y SRI. Y comienzan a aparecer las primeras patentes sobre paquetes de transmisión de voz.

A comienzos de los años 90 se crea DARTnet, una red internacional formada por unos doce centros de investigación, donde se hacen experimentos con MBONE, RTP y vat.

Estos experimentos usaban hardware de propósito específico y codificadores como el LPC, pero el interés de Sun Microsystems en transmitir voz sobre redes de paquetes dio lugar a un codec de audio dentro del SPARCstation 1. Además, entre el software disponible para las estaciones de trabajo de Sun estaban incluidos vt y vtalk.

En noviembre de 1995, RTP es aprobado por el IESG como estándar.

Netscape anuncia en enero de 1996 Netscape LiveMedia, un framework basado en estándares para dar soporte de audio y vídeo en tiempo real a la plataforma de Netscape. Estaba basado en RTP (RFC 1889) y otros estándares como MPEG, H.261 y GSM.

Intel, Microsoft, y un consorcio de más de cien empresas de tecnología pretenden construir una plataforma abierta

basada en los estándares existentes para hacer comunicaciones de audio, vídeo y datos sobre Internet tan fácil como una llamada de teléfono. La implementación incluía las especificaciones T.120, H.323, RTP/RTCP y RTSP. Microsoft dijo que incorporaría esas capacidades como parte de la tecnología ActiveX en futuras versiones del sistema operativo Windows.

En mayo de 1996, Microsoft afirma que su software de conferencias, NetMeeting, soporta RTP.

El protocolo de streaming en tiempo real (RTSP) fue propuesto por una coalición de 38 industrias [7], que anunció un nuevo estándar de audio y vídeo que permitía a las compañías que usan internet competir con la radio y televisión tradicionales. Un estándar que permitía transmitir flujos de información digital a ordenadores personales.

El grupo liderado por Netscape Communications y Progressive Networks, incluía a IBM, Apple Computer, Sun Microsystems, Digital Equipment, Hewlett-Packard y Silicon Graphics, pero no a Microsoft. La ausencia de Microsoft en el grupo era otra indicación de la rivalidad entre la compañía de Redmond y la nueva Netscape. Pero finalmente, tras conversaciones, Microsoft aceptó el nuevo protocolo.

III.RTP Y RTCP

RTP, protocolo de transporte en tiempo real, proporciona funciones para redes de extremo a extremo adecuadas para aplicaciones que transmiten datos en tiempo real, como audio, vídeo, o datos provenientes de una simulación, sobre redes unicast o multicast. El transporte de datos es acompañado por un protocolo de control (RTCP) que permite monitorizar el envío de datos de forma escalable en redes multicast.

RTP y RTCP (en la capa de aplicación) han sido diseñados para ser independientes de las capas de transporte y red sobre las que funcionen. RTP corre normalmente sobre UDP para hacer uso de sus servicios de multiplexación y detección de errores. Sin embargo, RTP puede ser usado sobre otros protocolos de transporte y de red, incluso IPv6. Todo esto queda recogido en la figura 1.

Figura 1. Posibles protocolos bajo RTP y RTCP.

RTP soporta transferencia de datos a múltiples destinos usando distribución multicast si lo proporciona la red sobre la que se usa.

Este protocolo, por si solo no proporciona ningún mecanismo para asegurar un envío a tiempo ni garantiza calidad de servicio; confía en que un servicio de una capa inferior lo haga. Esto no garantiza que lleguen los datos ni que lleguen en orden. Los números de secuencia incluidos en RTP permiten al receptor reconstruir la secuencia de paquetes del emisor.

RTP ha sido diseñado principalmente para multimedia, pero no esta limitado a esa aplicación, y también se puede aplicar a almacenamiento de datos continuos, simulaciones distribuidas e interactivas o aplicaciones de control.

El estándar RTP es producto del AVT del Internet Engineering Task Force (IETF), y queda recogido en el RFC 3550 [3], que es una revisión del RFC 1889 donde no hay cambios en el formato del paquete, solo en las reglas y algoritmos que gobiernan como es usado el protocolo.

A. Protocolo de transferencia de datos RTP

Propósitos:– Es ligero respecto a especificación e implementación.– Flexible en el sentido de que proporciona mecanismos.– Neutral al protocolo: funciona sobre UDP/IP, ST-II,– IPX, ATM, etc.– Escalable.– Separa control y datos.– Y es seguro: soporta cifrado y posibilidad de

autenticación.

Funciones:– Segmentación y composición hecha por UDP (o

similar).– Resecuenciación (si es necesaria).– Detección de perdidas para poder estimar la calidad.– Sincronización entre flujos (sincronización de labios

entre audio y vídeo y control de retrasos).– Realimentación de la calidad de servicio y adaptación

de la calidad.– Identificación de la fuente (emisor).

Mezcladores (mixers):Combinan varios flujos en uno nuevo con una

codificación nueva. Aparecen como una nueva fuente, con su propio identificador y usan un nuevo SSRC.

Se pueden usar en redes con un ancho de banda reducido (como las conexiones vía módem). Un mezclador puede cambiar el formato de los datos (codificación) y combinar flujos a la vez. Y encontramos un ejemplo en la figura 2 (derecha) donde se mezclan dos flujos GSM en uno nuevo.

Traductores (translators):Trabajan con un único flujo multimedia y pueden

cambiar la codificación de este (por razones de ancho de banda) o cambiar el protocolo usado (para cortafuegos). Además, los datos pueden pasar a través de un traductor y quedar intactos.

A diferencia de los mezcladores, se mantiene la fuente (SSRC). Se puede apreciar un ejemplo en la figura 2 (izquierda) donde el flujo DVI4 se traduce a GSM; y el L16 también.

Figura 2. (Izquierda) Traductor. (Derecha) Mezclador.

Cabecera del paquete:La cabecera de un paquete RTP esta formada por los

siguiente campos:

Figura 3. Cabecera RTP.

– Version (V): Identifica la versión del protocolo. La versión 2 corresponde al estándar actual, la versión 1 al primer borrador, y el valor 0 era usado por el protocolo implementado inicialmente en la herramienta “vat”.

– Padding (P): Se usa para algoritmos de cifrado que requieren de un tamaño fijo de bloque. Si P es establecido, el paquete contiene uno o más octetos al final, que no forman parte del payload, el último de estos octetos indica cuantos octetos deben de ser ignorados (incluido él).

– Extension (X): Si el bit de extensión esta activado, la cabecera debe de ir seguida de otra cabecera de extensión (header extension) como se puede

comprobar en la figura 3. Se trata de un mecanismo para implementaciones específicas o nuevos formatos de payload que requieran de más información adicional en la cabecera del paquete RTP. Esto permite que una implementación que no soporte dicha extensión pueda trabajar con parte de la información del paquete.Se puede ver en detalle en la sección 5.3.1 de [3].

– CSRC Count (CC). Indica el número de fuentes que contribuyen.

– Marker (M). La interpretación exacta de este bit queda establecida por los perfiles (profiles). Se usa para notificar de eventos significativos como un cambio de cámara (frame boundaries).Un perfil puede añadir más bits de marcas o decir que este no es un bit de marca cambiando el tamaño del siguiente campo.

– Payload type (PT): Identifica el formato del payload, o método de codificación del audio/vídeo. Puede cambiar durante la sesión, pero no hay que usarlo para multiplexar varios flujos multimedia.Por último, un receptor debe de ignorar los paquetes con un PT que no entiende.

– Sequence number. Este campo se incrementa en una unidad para cada paquete RTP que es enviado. Y le sirve al receptor para detectar pérdidas de paquetes si encuentra saltos, o para reordenar la secuencia de paquetes.El valor inicial debe de ser aleatorio para dificultar ataques basados en conocimiento de texto plano, incluso si una fuente no cifra, porque más tarde un traductor puede hacerlo.

– Timestamp: Refleja el instante de la muestra del primer octeto en un paquete de datos, esto es, una marca de tiempo. Ese instante debe ser calculado con un reloj que incremente de forma monótona y lineal para permitir sincronización.El valor inicial debe de ser aleatorio, e incrementa en función del tiempo cubierto en el contenido del paquete.A diferencia del número de secuencia, varios paquetes RTP pueden tener el mismo timestamp si son imágenes del mismo frame.

– Syncronization source identifier (SSRC): Identifica a la fuente con la que se sincroniza, también debe ser elegido aleatoriamente con la intención de que no haya dos fuentes en la misma sesión que tengan el mismo identificador SSRC. Sin embargo, todas las implementaciones de RTP deben estar preparadas para detectar y resolver colisiones.

– Contributing source identifiers (CSRC): Identifica a las fuentes que contribuyen al payload. El número de identificadores viene dado por el campo CC y esta comprendido entre 0 y 15.Los identificadores CSRC son insertados por los mezcladores, usando los identificadores SSRC de las diferentes fuentes. Por ejemplo, para paquetes de audio, los SSRC de los emisores que van a ser mezclados son listados en el paquete, permitiendo al receptor identificar quien habla.

– Payload. Hace referencia a los datos transportados por un paquete RTP. Por ejemplo muestras de audio o vídeo comprimido.Un perfil (profile) es un documento que define un conjunto de codigos payload type y los respectivos formatos de codificación. También puede definir extensiones o modificaciones para una clase particular de aplicaciones. Un perfil para audio y vídeo puede ser encontrado en el RFC 3551 [4].Por otro lado tenemos documentos que especifican el formato de un payload, los cuales definen como una codificación concreta de audio o de vídeo tiene que ser transportada en RTP.En la tabla 1 se presentan algunos de los payloads.

Estándar TítuloRFC 2190 RTP Payload Format for H.263 Video

StreamsRFC 2250 RTP Payload Format for MPEG1/MPEG2

VideoRFC 3016 RTP Payload Format for MPEG-4

Audio/Visual StreamsRFC 3119 A More Loss-Tolerant RTP Payload Format

for MP3 AudioRFC 3497 RTP Payload Format for Society of Motion

Picture and Television Engineers (SMPTE) 292M Video

RFC 4103 RTP Payload for Text ConversationRFC 4184 RTP Payload Format for AC-3 AudioRFC 4587 RTP Payload Format for H.261 Video

Streams

Tabla 1. Ejemplos de payloads.

Por último, en una red, RTP y RTCP no tienen un puerto fijo, pero se usa la siguiente regla: el puerto RTP es un número par, y el puerto RTCP es el siguiente número.

B. Protocolo de control RTP

Es el protocolo de control diseñado para trabajar en conjunción con RTP. En una sesión RTP, los participantes envían periódicamente paquetes RTCP con información referente a la calidad de los datos recibidos.

Se definen cinco tipos de paquetes para reportar información de control:

– RR: Receiver report. Son generados por participantes que no son emisores. Contienen la calidad con la que los datos han sido recibidos, número de paquetes recibidos y perdidos, y timestamps para calcular el retraso entre emisor y receptor.

– SR: Sender report. Estos son generados por los emisores de la sesión. Además de los datos RR, incluye una sección de información del emisor con información de sincronización, contadores acumulativos de paquetes y número de bytes enviados.

– SDES: Source description. Contiene información para describir al emisor. Nombre, email, localización, CNAME (Canonical name).

– BYE: Explicit leave. Indica el fin de una participación.

– APP: Extensions. Definidos por la aplicación (aún ninguno).

Una descripción detallada del formato de cada paquete se puede ver a partir de la sección 6.4.2 del RFC 3550 [3].

Figura 4. Tráfico RTCP.

Estos paquetes de control nos ofrecen los siguientes servicios:– Monitorización de la calidad de servicio y control de la

congestión. Es la función principal de RTCP, proporcionando la calidad de la distribución de los datos. Es útil tanto para emisores, como receptores, como terceras partes. El emisor puede ajustar la transmisión en función del informe recibido; los receptores pueden determinar cuando la congestión es local, regional o global; y los administradores de red pueden evaluar el rendimiento de la red en una distribución multicast.

– Identificación de la fuente. En los paquetes RTP los emisores son identificados por un número de 32 bits generado aleatoriamente, que no son adecuados para las personas. Los paquetes RTCP SDES contienen información textual como el CNAME que se trata de un identificador único para un participante en la sesión. Además pueden incluir nombre, número de teléfono y otra información.

– Sincronización entre flujos. Un RTCP sender report contiene una indicación de tiempo real y el correspondiente timestamp del RTP. Esto puede usarse para sincronización entre flujos multimedia como sincronización entre labios y vídeo.

– Información de control escalable. Los paquetes RTCP son enviados periódicamente por los participantes, y cuando el número de estos incrementa es necesario un equilibrio entre tener información de control actualizada y limitar el tráfico de control. RTP limita el tráfico de control a un máximo del 5% de todo el tráfico de la sesión.

C. Protocolo RSVP

Protocolo de reservación de recursos (Resource ReSerVation Protocol). Permite que el receptor de datos acuerde una calidad de servicio determinada extremo a extremo para el flujo.

Las aplicaciones en tiempo real usan RSVP para reservar los recursos necesarios en routers durante la transmisión que se va a llevar a cabo.

En el diseño de RSVP han formado parte: Xerox Corp.'s (PARC), MIT, y el Information Sciences Institute of University of California (ISI).

En cuanto a su funcionamiento, el receptor precisa de calidad de servicio para su transferencia; y RSVP es responsable de las negociaciones de parámetros de conexión con los routers, y de mantener la situación para proporcionar el servicio requerido.

D. Protocolos SRTP y SRTCP

El Secure Real-time Transport Protocol o (SRTP) define un perfil de RTP, para proporcionar cifrado, autenticación de mensajes e integridad, además de protección contra reenvíos de los datos RTP tanto en aplicaciones unicast como multicast. Fue desarrollado por un pequeño equipo del protocolo IP y expertos en criptografía de Cisco y Ericsson. Fue publicado por el IETF como el RFC 3711 [9].

SRTP esta relacionado con el protocolo Secure RTCP (SRTCP), que añade características de seguridad al protocolo de control.

Utilizando esta nueva pareja de protocolos, cada una de las características que proporcionan (cifrado, autenticación e integridad) son opcionales; excepto en SRTCP que es obligatoria la autenticación de los mensajes.

Para cifrar y descifrar flujos de datos (proporcionando confidencialidad) hace uso del algoritmo simétrico de cifrado de bloques AES (también conocido como Rijndael).

Para la autenticación de mensajes y proteger la integridad se utiliza el algoritmo HMAC-SHA1 (funciones hash criptográficas en combinación con una clave secreta), calculado sobre el payload y algunos campos de la cabecera, como el número de secuencia.

IV.RTSP

El protocolo de streaming en tiempo real (RTSP) fue desarrollado por RealNetworks, Netscape Communications y Columbia University y está publicado en el RFC 2326 [5], es un protocolo a nivel de aplicación para el envío de datos con propiedades de tiempo real que puede trabajar junto a otros protocolos como RTP y RSVP. Proporciona un entorno para el envío de datos de tiempo real bajo demanda, como lo son el audio y el vídeo. Las fuentes de datos pueden incluir tanto datos en directo, como almacenados. Este protocolo puede funcionar sobre UDP, UDP multicast y TCP.

El servidor proporciona el contenido multimedia, los clientes solicitan continuamente datos al servidor; y RTSP se comporta como un mando a distancia entre un cliente y el servidor, que permite:

– Conseguir datos del servidor. El cliente le pide al servidor que configure una sesión para que le envíe los datos solicitados.

– Invitar a un servidor a una conferencia. – Añadir datos a una presentación existente. El cliente o

el servidor pueden notificarle a la otra parte sobre datos que se encuentran disponibles.

RTSP intenta dar los mismos servicios para audio y vídeo que HTTP hace para texto y gráficos; y ha sido diseñado intencionadamente para que tenga una sintaxis y operaciones similares. Cada flujo esta identificado por una URL RTSP. Cada presentación y sus propiedades multimedia quedan recogidas en un fichero de descripción de la presentación, y este fichero puede ser obtenido por los clientes vía HTTP, por email o cualquier otro medio.

Pero RTSP difiere de HTTP en algunos aspectos: mientras que HTTP es un protocolo sin estados, un servidor RTSP tiene que mantener los estados de las sesiones para hacer corresponder pedidos y flujos. Y además, HTTP es un protocolo asimétrico donde el cliente hace peticiones y el servidor responde, mientras que en RTSP ambos pueden hacer peticiones.

Los servicios y operaciones soportados son los siguientes:– OPTIONS: El cliente o el servidor le comunican a la

otra parte que opciones aceptan.– DESCRIBE: El cliente consigue una descripción de un

contenido identificado por una URL RTSP.– ANNOUNCE: Actualiza la descripción en tiempo real.– SETUP: El cliente le pregunta al servidor donde

conseguir los datos.– PLAY: El cliente le pide al servidor que comience a

mandarle los flujos configurados en SETUP.– PAUSE: El cliente detiene el envío sin liberar los

recursos en el servidor.

– TEARDOWN: El cliente solicita al servidor que detenga el envío del flujo especificado y libere todos los recursos asociados a él.

– GET_PARAMETER: Consigue el valor de un parámetro de una presentación o flujo.

– SET_PARAMETER: Establece el valor de un parámetro de una presentación o flujo.

– REDIRECT: El servidor informa al cliente de que debe conectarse al servidor indicado en la cabecera.

– RECORD: El cliente comienza a grabar datos de la presentación.

Las peticiones RTSP son enviadas normalmente por un canal independiente al canal de los datos. Estos últimos pueden ser transmitidos por otro tipo de conexión.

V.IMPLEMENTACIONES

Existen diferentes implementaciones de los protocolos vistos anteriormente, a nivel de hardware o de software; entre ellas podemos encontrar:

A. Cámaras IP

Podemos encontrar en el mercado cámaras de vídeo con un puerto RJ-45 o wireless y que implementan servidores RTP o RTSP. Por ejemplo, el modelo 210 de Axis [15], que funciona con un sistema operativo empotrado Linux 2.4 y soporta los protocolos RTP y RTSP entre otros.

Figura 5. Cámara de red Axis 210

B. Java Media Framework

Java Media Framework [16] (JMF) permite añadir audio, vídeo y otros contenidos con tiempo a aplicaciones y applets hechos en Java. Pudiendo capturar, reproducir, enviar y traducir múltiples formatos multimedia (AVI, MPEG, QuickTime, Sun Audio, etc). Esta API da soporte de RTP para clientes y servidores. Y recientemente se ha obtenido soporte para RTSP.

C. Darwin Streaming Server

Darwin Streaming Server [17] es el primer servidor de streaming de código abierto que soporta RTP y RTSP con variedad de formatos entre los que se encuentran H.264, MPEG-4 y 3GPP. Fue desarrollado por Apple, es el equivalente al QuickTime Streaming Server, y se basa en su código fuente.

Inicialmente solo se podía compilar para Mac OS X, pero a día de hoy funciona sobre Linux, FreeBSD, Solaris, Tru-64 Unix, Mac OS 9 y Windows.

VI.CONCLUSIONES

Hemos visto como ha evolucionado el transporte de contenidos multimedia en Internet, las empresas implicadas, estándares usados y algunas aplicaciones finales.

Gracias a estos estándares es posible la compatibilidad entre clientes y servidores de distintas plataformas y sistemas operativos.

Hemos pasado de usar la red telefónica para conectarse a Internet, a usar esta red para telefonía IP o televisión por Internet.

Y a medio plazo podremos ver todas estas tecnologías funcionar sobre el protocolo IPv6 en las variantes unicast, multicast, y también anycast.

REFERENCIAS [1] RTP: About RTP and the Audio-Video Transport Working Group

http://www.cs.columbia.edu/~hgs/rtp/

[2] rtsp.org: Real Time Streaming Protocol Information and Updates http://www.rtsp.org

[3] RFC 3550 “ RTP: A Transport Protocol for Real-Time Applications”

http://tools.ietf.org/html/rfc3550

[4] RFC 3551 “RTP Profile for Audio and Video Conferences with Minimal Control”

http://tools.ietf.org/html/rfc3551

[5] RFC 2326 “Real Time Streaming Protocol (RTSP)”

http://tools.ietf.org/html/rfc2326

[6] Formatos de audio y video

http://www.monografias.com/trabajos17/formatos-audio/formatos-audio.shtml

[7] Computer Makers to Announce Audio, Video, Data Standard http://www.nytimes.com/library/cyber/week/1014standards.html

[8] Secure Real-time Transport Protocol

http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol

[9] RFC 3711 “The Secure Real-time Transport Protocol (SRTP)”

http://tools.ietf.org/html/rfc3711

[10] Real-Time Transport Protocol (RTP)

http://www.cs.columbia.edu/~coms6181/slides/7/rtp.pdf

[11] Multimedia Over IP: RSVP, RTP, RTCP, RTSP

http://www.cs.wustl.edu/~jain/cis788-97/ftp/ip_multimedia.pdf

[12] Real-time Transport Protocol

http://www.lab.dit.upm.es/~labscom/almacen/sld/rtp.pdf

[13] RTP/RTCP and RTSP multimedia protocols for the Internet

http://planete.inrialpes.fr/~roca/doc/ecole_ete_pdms01_v6.pdf

[14] Axis Communications

[15] http://www.axis.com/

[16] Java Media Framework API (JMF)

http://java.sun.com/products/java-media/jmf/

[17] Apple Darwin Streaming Server

http://developer.apple.com/opensource/server/streaming/index.html

[18] Darwin Streaming Server

http://en.wikipedia.org/wiki/Darwin_Streaming_Server