Anlisis de los protocolos de tiempo real en Ethernet RTP, RTCP y RTSP.

Manuel Flores Vivas

Sistemas en Tiempo Real, curso 2006/2007 E.T.S.I. Informtica Universidad de Mlaga e-mail: manuelfloresv{at}gmail{.}com Resumen En este documento se estudian los diferentes protocolos de tiempo real para el envo y recepcin de contenidos multimedia en tiempo real a travs de Internet. I. INTRODUCCIN Desde que la informtica se introdujo en el hogar y aparecieron las primeras GUIs (Interfaces Grficas de Usuario) los contenidos multimedia han estado presentes tanto en equipos domsticos como en estaciones de trabajo. Y desde hace unos aos, tambin en telfonos mviles, reproductores porttiles o videoconsolas. Como se representan audio y vdeo en el ordenador? [6] Los archivos de audio se almacenan comprimidos por medio de algoritmos basados en la tcnica PNS (norma de percepcin del ruido), es decir, aprovechan ciertas frecuencias que el ser humano no reconoce y otras que reconoce mejor. La compresin de sonido elimina frecuencias imperceptibles sin alterar de forma significativa lo que se escucha, pero reduciendo considerablemente el tamao 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 creacin de Internet, y con el aumento en el nmero de nodos y de la velocidad de la red, han aparecido tecnologas como la radio por Internet, videoconferencias, vdeo bajo demanda, VoIP (voz sobre IP), televisin por Internet o emisiones en directo. Y todos estos servicios requieren que el envo y la recepcin 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, estndares, algoritmos y aplicaciones en los que se profundizar en las siguientes secciones. En la seccin II se har un breve repaso a la historia del transporte de audio y vdeo sobre Internet. La seccin III profundizar en la pareja de protocolos RTP (Real Time Protocol) y RTCP (Real Time Control Protocol). En la seccin IV se analizar el protocolo RTSP (Real Time Streaming Protocol). En la seccin V, se estudiarn implementaciones: Hardware, Software y APIs. diferentes

Y por ltimo, la seccin 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 aos 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 transmisin de voz. A comienzos de los aos 90 se crea DARTnet, una red internacional formada por unos doce centros de investigacin, donde se hacen experimentos con MBONE, RTP y vat. Estos experimentos usaban hardware de propsito especfico y codificadores como el LPC, pero el inters de Sun Microsystems en transmitir voz sobre redes de paquetes dio lugar a un codec de audio dentro del SPARCstation 1. Adems, 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 estndar. Netscape anuncia en enero de 1996 Netscape LiveMedia, un framework basado en estndares para dar soporte de audio y vdeo en tiempo real a la plataforma de Netscape. Estaba basado en RTP (RFC 1889) y otros estndares como MPEG, H.261 y GSM. Intel, Microsoft, y un consorcio de ms de cien empresas de tecnologa pretenden construir una plataforma abierta

basada en los estndares existentes para hacer comunicaciones de audio, vdeo y datos sobre Internet tan fcil como una llamada de telfono. La implementacin inclua las especificaciones T.120, H.323, RTP/RTCP y RTSP. Microsoft dijo que incorporara esas capacidades como parte de la tecnologa 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 coalicin de 38 industrias [7], que anunci un nuevo estndar de audio y vdeo que permita a las compaas que usan internet competir con la radio y televisin tradicionales. Un estndar que permita transmitir flujos de informacin digital a ordenadores personales. El grupo liderado por Netscape Communications y Progressive Networks, inclua 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 indicacin de la rivalidad entre la compaa 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, vdeo, o datos provenientes de una simulacin, sobre redes unicast o multicast. El transporte de datos es acompaado por un protocolo de control (RTCP) que permite monitorizar el envo de datos de forma escalable en redes multicast. RTP y RTCP (en la capa de aplicacin) han sido diseados 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 multiplexacin y deteccin 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 mltiples destinos usando distribucin multicast si lo proporciona la red sobre la que se usa. Este protocolo, por si solo no proporciona ningn mecanismo para asegurar un envo a tiempo ni garantiza calidad de servicio; confa en que un servicio de una capa inferior lo haga. Esto no garantiza que lleguen los datos ni que lleguen en orden. Los nmeros de secuencia incluidos en RTP permiten al receptor reconstruir la secuencia de paquetes del emisor. RTP ha sido diseado principalmente para multimedia, pero no esta limitado a esa aplicacin, y tambin se puede aplicar a almacenamiento de datos continuos, simulaciones distribuidas e interactivas o aplicaciones de control. El estndar RTP es producto del AVT del Internet Engineering Task Force (IETF), y queda recogido en el RFC 3550 [3], que es una revisin 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 Propsitos: Es ligero respecto a especificacin e implementacin. 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 autenticacin. Funciones: Segmentacin y composicin hecha por UDP (o similar). Resecuenciacin (si es necesaria). Deteccin de perdidas para poder estimar la calidad. Sincronizacin entre flujos (sincronizacin de labios entre audio y vdeo y control de retrasos). Realimentacin de la calidad de servicio y adaptacin de la calidad. Identificacin de la fuente (emisor). Mezcladores (mixers): Combinan varios flujos en uno nuevo con una codificacin 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 va mdem). Un mezclador puede cambiar el formato de los datos (codificacin) 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 codificacin de este (por razones de ancho de banda) o cambiar el protocolo usado (para cortafuegos). Adems, los datos pueden pasar a travs 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 tambin.

comprobar en la figura 3. Se trata de un mecanismo para implementaciones especficas o nuevos formatos de payload que requieran de ms informacin adicional en la cabecera del paquete RTP. Esto permite que una implementacin que no soporte dicha extensin pueda trabajar con parte de la informacin del paquete. Se puede ver en detalle en la seccin 5.3.1 de [3].

CSRC Count (CC). Indica el nmero de fuentes que contribuyen. Marker (M). La interpretacin exacta de este bit queda establecida por los perfiles (profiles). Se usa para notificar de eventos significativos como un cambio de cmara (frame boundaries). Un perfil puede aadir ms bits de marcas o decir que este no es un bit de marca cambiando el tamao del siguiente campo. Payload type (PT): Identifica el formato del payload, o mtodo de codificacin del audio/vdeo. Puede cambiar durante la sesin, 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 prdidas 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 ms 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 montona y lineal para permitir sincronizacin. El valor inicial debe de ser aleatorio, e incrementa en funcin del tiempo cubierto en el contenido del paquete. A diferencia del nmero de secuencia, varios paquetes RTP pueden tener el mismo timestamp si son imgenes del mismo frame. Syncronization source identifier (SSRC): Identifica a la fuente con la que se sincroniza, tambin debe ser elegido aleatoriamente con la intencin de que no haya dos fuentes en la misma sesin que tengan el mismo identificador SSRC. Sin embargo, todas las implementaciones de RTP deben estar preparadas para detectar y resolver colisiones.

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 versin del protocolo. La versin 2 corresponde al estndar actual, la versin 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 tamao fijo de bloque. Si P es establecido, el paquete contiene uno o ms 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 extensin esta activado, la cabecera debe de ir seguida de otra cabecera de extensin (header extension) como se puede

Contributing source identifiers (CSRC): Identifica a las fuentes que contribuyen al payload. El nmero 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 vdeo comprimido. Un perfil (profile) es un documento que define un conjunto de codigos payload type y los respectivos formatos de codificacin. Tambin puede definir extensiones o modificaciones para una clase particular de aplicaciones. Un perfil para audio y vdeo 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 codificacin concreta de audio o de vdeo tiene que ser transportada en RTP. En la tabla 1 se presentan algunos de los payloads.
Estndar RFC 2190 RFC 2250 RFC 3016 RFC 3119 RFC 3497 RFC 4103 RFC 4184 RFC 4587 Ttulo RTP Payload Format for H.263 Video Streams RTP Payload Format for MPEG1/MPEG2 Video RTP Payload Format for MPEG-4 Audio/Visual Streams A More Loss-Tolerant RTP Payload Format for MP3 Audio RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video RTP Payload for Text Conversation RTP Payload Format for AC-3 Audio RTP Payload Format for H.261 Video Streams

RR: Receiver report. Son generados por participantes que no son emisores. Contienen la calidad con la que los datos han sido recibidos, nmero 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 sesin. Adems de los datos RR, incluye una seccin de informacin del emisor con informacin de sincronizacin, contadores acumulativos de paquetes y nmero de bytes enviados. SDES: Source description. Contiene informacin para describir al emisor. Nombre, email, localizacin, CNAME (Canonical name). BYE: Explicit leave. Indica el fin de una participacin. APP: Extensions. Definidos por la aplicacin (an ninguno).

Una descripcin detallada del formato de cada paquete se puede ver a partir de la seccin 6.4.2 del RFC 3550 [3].

Figura 4. Trfico RTCP.

Tabla 1. Ejemplos de payloads.

Estos paquetes de control nos ofrecen los siguientes servicios: Monitorizacin de la calidad de servicio y control de la congestin. Es la funcin principal de RTCP, proporcionando la calidad de la distribucin de los datos. Es til tanto para emisores, como receptores, como terceras partes. El emisor puede ajustar la transmisin en funcin del informe recibido; los receptores pueden determinar cuando la congestin es local, regional o global; y los administradores de red pueden evaluar el rendimiento de la red en una distribucin multicast.

Por ltimo, en una red, RTP y RTCP no tienen un puerto fijo, pero se usa la siguiente regla: el puerto RTP es un nmero par, y el puerto RTCP es el siguiente nmero. B. Protocolo de control RTP Es el protocolo de control diseado para trabajar en conjuncin con RTP. En una sesin RTP, los participantes envan peridicamente paquetes RTCP con informacin referente a la calidad de los datos recibidos. Se definen cinco tipos de paquetes para reportar informacin de control:

Identificacin de la fuente. En los paquetes RTP los emisores son identificados por un nmero de 32 bits generado aleatoriamente, que no son adecuados para las personas. Los paquetes RTCP SDES contienen informacin textual como el CNAME que se trata de un identificador nico para un participante en la sesin. Adems pueden incluir nombre, nmero de telfono y otra informacin. Sincronizacin entre flujos. Un RTCP sender report contiene una indicacin de tiempo real y el correspondiente timestamp del RTP. Esto puede usarse para sincronizacin entre flujos multimedia como sincronizacin entre labios y vdeo.

IV.RTSP

Informacin de control escalable. Los paquetes RTCP son enviados peridicamente por los participantes, y cuando el nmero de estos incrementa es necesario un equilibrio entre tener informacin de control actualizada y limitar el trfico de control. RTP limita el trfico de control a un mximo del 5% de todo el trfico de la sesin.

C. Protocolo RSVP Protocolo de reservacin 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 transmisin que se va a llevar a cabo. En el diseo 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 parmetros de conexin con los routers, y de mantener la situacin 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, autenticacin de mensajes e integridad, adems de proteccin contra reenvos de los datos RTP tanto en aplicaciones unicast como multicast. Fue desarrollado por un pequeo equipo del protocolo IP y expertos en criptografa de Cisco y Ericsson. Fue publicado por el IETF como el RFC 3711 [9]. SRTP esta relacionado con el protocolo Secure RTCP (SRTCP), que aade caractersticas de seguridad al protocolo de control. Utilizando esta nueva pareja de protocolos, cada una de las caractersticas que proporcionan (cifrado, autenticacin e integridad) son opcionales; excepto en SRTCP que es obligatoria la autenticacin de los mensajes. Para cifrar y descifrar flujos de datos (proporcionando confidencialidad) hace uso del algoritmo simtrico de cifrado de bloques AES (tambin conocido como Rijndael). Para la autenticacin de mensajes y proteger la integridad se utiliza el algoritmo HMAC-SHA1 (funciones hash criptogrficas en combinacin con una clave secreta), calculado sobre el payload y algunos campos de la cabecera, como el nmero de secuencia.

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 aplicacin para el envo de datos con propiedades de tiempo real que puede trabajar junto a otros protocolos como RTP y RSVP. Proporciona un entorno para el envo de datos de tiempo real bajo demanda, como lo son el audio y el vdeo. 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 sesin para que le enve los datos solicitados. Invitar a un servidor a una conferencia. Aadir datos a una presentacin 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 vdeo que HTTP hace para texto y grficos; y ha sido diseado intencionadamente para que tenga una sintaxis y operaciones similares. Cada flujo esta identificado por una URL RTSP. Cada presentacin y sus propiedades multimedia quedan recogidas en un fichero de descripcin de la presentacin, y este fichero puede ser obtenido por los clientes va 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 adems, HTTP es un protocolo asimtrico 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 descripcin de un contenido identificado por una URL RTSP. ANNOUNCE: Actualiza la descripcin 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 envo sin liberar los recursos en el servidor.

TEARDOWN: El cliente solicita al servidor que detenga el envo del flujo especificado y libere todos los recursos asociados a l. GET_PARAMETER: Consigue el valor de un parmetro de una presentacin o flujo. SET_PARAMETER: Establece el valor de un parmetro de una presentacin 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 presentacin.

Inicialmente solo se poda compilar para Mac OS X, pero a da 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, estndares usados y algunas aplicaciones finales. Gracias a estos estndares es posible la compatibilidad entre clientes y servidores de distintas plataformas y sistemas operativos. Hemos pasado de usar la red telefnica para conectarse a Internet, a usar esta red para telefona IP o televisin por Internet. Y a medio plazo podremos ver todas estas tecnologas funcionar sobre el protocolo IPv6 en las variantes unicast, multicast, y tambin anycast. REFERENCIAS
[1] [2] [3] [4] RTP: About RTP and the Audio-Video Transport Working Group http://www.cs.columbia.edu/~hgs/rtp/ rtsp.org: Real Time Streaming Protocol Information and Updates http://www.rtsp.org RFC 3550 RTP: A Transport Protocol for Real-Time Applications http://tools.ietf.org/html/rfc3550 RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control http://tools.ietf.org/html/rfc3551 RFC 2326 Real Time Streaming Protocol (RTSP) http://tools.ietf.org/html/rfc2326 Formatos de audio y video http://www.monografias.com/trabajos17/formatos-audio/formatosaudio.shtml Computer Makers to Announce Audio, Video, Data Standard http://www.nytimes.com/library/cyber/week/1014standards.html Secure Real-time Transport Protocol http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol RFC 3711 The Secure Real-time Transport Protocol (SRTP) http://tools.ietf.org/html/rfc3711 Real-Time Transport Protocol (RTP) http://www.cs.columbia.edu/~coms6181/slides/7/rtp.pdf Multimedia Over IP: RSVP, RTP, RTCP, RTSP http://www.cs.wustl.edu/~jain/cis788-97/ftp/ip_multimedia.pdf Real-time Transport Protocol http://www.lab.dit.upm.es/~labscom/almacen/sld/rtp.pdf RTP/RTCP and RTSP multimedia protocols for the Internet http://planete.inrialpes.fr/~roca/doc/ecole_ete_pdms01_v6.pdf Axis Communications http://www.axis.com/ Java Media Framework API (JMF) http://java.sun.com/products/java-media/jmf/ Apple Darwin Streaming Server http://developer.apple.com/opensource/server/streaming/index.html Darwin Streaming Server http://en.wikipedia.org/wiki/Darwin_Streaming_Server

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

V.IMPLEMENTACIONES Existen diferentes implementaciones de los protocolos vistos anteriormente, a nivel de hardware o de software; entre ellas podemos encontrar: A. Cmaras IP Podemos encontrar en el mercado cmaras de vdeo 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.

[5] [6]

[7] [8] Figura 5. Cmara de red Axis 210 [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

B. Java Media Framework Java Media Framework [16] (JMF) permite aadir audio, vdeo y otros contenidos con tiempo a aplicaciones y applets hechos en Java. Pudiendo capturar, reproducir, enviar y traducir mltiples 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 cdigo 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 cdigo fuente.