• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Análisis de los protocolos de tiempo real RTP, RTCP y RTSP
 

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

on

  • 15,810 views

En este documento se estudian los diferentes

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.

Statistics

Views

Total Views
15,810
Views on SlideShare
15,755
Embed Views
55

Actions

Likes
1
Downloads
540
Comments
0

6 Embeds 55

http://protocolosderedesyservicios.alianzasuperior.com 34
http://redesyserviciosdetelecomunicacion.alianzasuperior.com 16
http://redesyserviciosdetelecomunicacion.aula.la 2
http://www.scoop.it 1
http://webcache.googleusercontent.com 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Análisis de los protocolos de tiempo real RTP, RTCP y RTSP Análisis de los protocolos de tiempo real RTP, RTCP y RTSP Document Transcript

    • Análisis 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. Informática Universidad de Málaga e-mail: manuelfloresv{at}gmail{.}com Resumen— En este documento se estudian los diferentes En la sección II se hará un breve repaso a la historia del protocolos de tiempo real para el envío y recepción de transporte de audio y vídeo sobre Internet. contenidos multimedia en tiempo real a través de La sección III profundizará en la pareja de protocolos Internet. RTP (Real Time Protocol) y RTCP (Real Time Control I. INTRODUCCIÓN Protocol). Desde que la informática se introdujo en el hogar y En la sección IV se analizará el protocolo RTSP (Real aparecieron las primeras GUIs (Interfaces Gráficas de Time Streaming Protocol). Usuario) los contenidos multimedia han estado presentes En la sección V, se estudiarán diferentes tanto en equipos domésticos como en estaciones de trabajo. implementaciones: Hardware, Software y APIs. Y desde hace unos años, también en teléfonos móviles, reproductores portátiles o videoconsolas. Y por último, la sección VI expone las conclusiones de este trabajo. ¿Como se representan audio y vídeo en el ordenador? [6] Los archivos de audio se almacenan comprimidos por II.HISTORIA medio de algoritmos basados en la técnica PNS (norma de percepción del ruido), es decir, aprovechan ciertas Los primeros esfuerzos en transmitir audio sobre frecuencias que el ser humano no reconoce y otras que Internet sobre los protocolos IP y ST-II se remontan a los reconoce mejor. años 70. La compresión de sonido elimina frecuencias Se hacen demostraciones entre USC/ISI (University of imperceptibles sin alterar de forma significativa lo que se Southern California), MIT/LL (Lincoln Laboratory, escucha, pero reduciendo considerablemente el tamaño del Massacchusetts Institute of Tecnology), CHI y SRI. Y fichero. comienzan a aparecer las primeras patentes sobre paquetes de transmisión de voz. Entre los formatos mas comunes, se encuentran: AAC (Advanced Audio Coding), WAV, AU (Audio for Unix), A comienzos de los años 90 se crea DARTnet, una red WMA (Windows Media Audio), MIDI (Musical Instrument internacional formada por unos doce centros de Digital Interface), MPEG (Moving Pictures Experts Group), investigación, donde se hacen experimentos con MBONE, AC3, RealAudio, RealVideo, OGG Vorbis, ATRAC RTP y vat. (Adaptive TRansform Acoustic Coding) o AVI (Audio Estos experimentos usaban hardware de propósito Video Interleave). específico y codificadores como el LPC, pero el interés de Hasta aquí se ha hablado de ficheros multimedia para ser Sun Microsystems en transmitir voz sobre redes de paquetes almacenados en diferentes soportes; pero desde la creación dio lugar a un codec de audio dentro del SPARCstation 1. de Internet, y con el aumento en el número de nodos y de la Además, entre el software disponible para las estaciones de velocidad de la red, han aparecido tecnologías como la radio trabajo de Sun estaban incluidos vt y vtalk. por Internet, videoconferencias, vídeo bajo demanda, VoIP En noviembre de 1995, RTP es aprobado por el IESG (voz sobre IP), televisión por Internet o emisiones en como estándar. directo. Y todos estos servicios requieren que el envío y la recepción de los datos se produzcan en tiempo real, para así Netscape anuncia en enero de 1996 Netscape poder ser reproducidos al momento y sin interrupciones. LiveMedia, un framework basado en estándares para dar soporte de audio y vídeo en tiempo real a la plataforma de Para que estas transmisiones puedan realizarse en tiempo Netscape. Estaba basado en RTP (RFC 1889) y otros real, se necesita de nuevos protocolos, formatos, estándares, estándares como MPEG, H.261 y GSM. algoritmos y aplicaciones en los que se profundizará en las siguientes secciones. 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 RTP soporta transferencia de datos a múltiples destinos comunicaciones de audio, vídeo y datos sobre Internet tan usando distribución multicast si lo proporciona la red sobre fácil como una llamada de teléfono. La implementación la que se usa. incluía las especificaciones T.120, H.323, RTP/RTCP y RTSP. Microsoft dijo que incorporaría esas capacidades Este protocolo, por si solo no proporciona ningún como parte de la tecnología ActiveX en futuras versiones mecanismo para asegurar un envío a tiempo ni garantiza del sistema operativo Windows. calidad de servicio; confía en que un servicio de una capa inferior lo haga. Esto no garantiza que lleguen los datos ni En mayo de 1996, Microsoft afirma que su software de que lleguen en orden. Los números de secuencia incluidos conferencias, NetMeeting, soporta RTP. en RTP permiten al receptor reconstruir la secuencia de paquetes del emisor. El protocolo de streaming en tiempo real (RTSP) fue propuesto por una coalición de 38 industrias [7], que RTP ha sido diseñado principalmente para multimedia, anunció un nuevo estándar de audio y vídeo que permitía a pero no esta limitado a esa aplicación, y también se puede las compañías que usan internet competir con la radio y aplicar a almacenamiento de datos continuos, simulaciones televisión tradicionales. Un estándar que permitía transmitir distribuidas e interactivas o aplicaciones de control. flujos de información digital a ordenadores personales. El estándar RTP es producto del AVT del Internet El grupo liderado por Netscape Communications y Engineering Task Force (IETF), y queda recogido en el Progressive Networks, incluía a IBM, Apple Computer, Sun RFC 3550 [3], que es una revisión del RFC 1889 donde no Microsystems, Digital Equipment, Hewlett-Packard y hay cambios en el formato del paquete, solo en las reglas y Silicon Graphics, pero no a Microsoft. La ausencia de algoritmos que gobiernan como es usado el protocolo. 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. A. Protocolo de transferencia de datos RTP Propósitos: III.RTP Y RTCP – Es ligero respecto a especificación e implementación. – Flexible en el sentido de que proporciona mecanismos. RTP, protocolo de transporte en tiempo real, – Neutral al protocolo: funciona sobre UDP/IP, ST-II, proporciona funciones para redes de extremo a extremo – IPX, ATM, etc. adecuadas para aplicaciones que transmiten datos en tiempo real, como audio, vídeo, o datos provenientes de una – Escalable. simulación, sobre redes unicast o multicast. El transporte de – Separa control y datos. datos es acompañado por un protocolo de control (RTCP) – Y es seguro: soporta cifrado y posibilidad de que permite monitorizar el envío de datos de forma autenticación. escalable en redes multicast. Funciones: RTP y RTCP (en la capa de aplicación) han sido – Segmentación y composición hecha por UDP (o diseñados para ser independientes de las capas de transporte similar). y red sobre las que funcionen. RTP corre normalmente – Resecuenciación (si es necesaria). sobre UDP para hacer uso de sus servicios de – Detección de perdidas para poder estimar la calidad. multiplexación y detección de errores. Sin embargo, RTP – Sincronización entre flujos (sincronización de labios puede ser usado sobre otros protocolos de transporte y de red, incluso IPv6. Todo esto queda recogido en la figura 1. entre audio y vídeo y control de retrasos). – Realimentación de la calidad de servicio y adaptación Figura 1. Posibles protocolos bajo RTP y RTCP. 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): comprobar en la figura 3. Se trata de un mecanismo Trabajan con un único flujo multimedia y pueden para implementaciones específicas o nuevos formatos cambiar la codificación de este (por razones de ancho de de payload que requieran de más información banda) o cambiar el protocolo usado (para cortafuegos). adicional en la cabecera del paquete RTP. Esto permite Además, los datos pueden pasar a través de un traductor y que una implementación que no soporte dicha quedar intactos. extensión pueda trabajar con parte de la información del paquete. A diferencia de los mezcladores, se mantiene la fuente Se puede ver en detalle en la sección 5.3.1 de [3]. (SSRC). Se puede apreciar un ejemplo en la figura 2 (izquierda) donde el flujo DVI4 se traduce a GSM; y el L16 – CSRC Count (CC). Indica el número de fuentes que también. 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 Figura 2. (Izquierda) Traductor. (Derecha) Mezclador. 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. Cabecera del paquete: Por último, un receptor debe de ignorar los paquetes La cabecera de un paquete RTP esta formada por los con un PT que no entiende. siguiente campos: – 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 Figura 3. Cabecera RTP. que incremente de forma monótona y lineal para permitir sincronización. – Version (V): Identifica la versión del protocolo. La El valor inicial debe de ser aleatorio, e incrementa en versión 2 corresponde al estándar actual, la versión 1 al función del tiempo cubierto en el contenido del primer borrador, y el valor 0 era usado por el protocolo paquete. implementado inicialmente en la herramienta “vat”. A diferencia del número de secuencia, varios paquetes RTP pueden tener el mismo timestamp si son imágenes – Padding (P): Se usa para algoritmos de cifrado que del mismo frame. requieren de un tamaño fijo de bloque. Si P es establecido, el paquete contiene uno o más octetos al – Syncronization source identifier (SSRC): Identifica a la final, que no forman parte del payload, el último de fuente con la que se sincroniza, también debe ser estos octetos indica cuantos octetos deben de ser elegido aleatoriamente con la intención de que no haya ignorados (incluido él). dos fuentes en la misma sesión que tengan el mismo identificador SSRC. Sin embargo, todas las – Extension (X): Si el bit de extensión esta activado, la implementaciones de RTP deben estar preparadas para cabecera debe de ir seguida de otra cabecera de detectar y resolver colisiones. extensión (header extension) como se puede
    • – Contributing source identifiers (CSRC): Identifica a – RR: Receiver report. Son generados por participantes las fuentes que contribuyen al payload. El número de que no son emisores. Contienen la calidad con la que identificadores viene dado por el campo CC y esta los datos han sido recibidos, número de paquetes comprendido entre 0 y 15. recibidos y perdidos, y timestamps para calcular el Los identificadores CSRC son insertados por los retraso entre emisor y receptor. mezcladores, usando los identificadores SSRC de las diferentes fuentes. Por ejemplo, para paquetes de – SR: Sender report. Estos son generados por los audio, los SSRC de los emisores que van a ser emisores de la sesión. Además de los datos RR, mezclados son listados en el paquete, permitiendo al incluye una sección de información del emisor con receptor identificar quien habla. información de sincronización, contadores acumulativos de paquetes y número de bytes enviados. – Payload. Hace referencia a los datos transportados por un paquete RTP. Por ejemplo muestras de audio o – SDES: Source description. Contiene información para vídeo comprimido. describir al emisor. Nombre, email, localización, Un perfil (profile) es un documento que define un CNAME (Canonical name). conjunto de codigos payload type y los respectivos formatos de codificación. También puede definir – BYE: Explicit leave. Indica el fin de una participación. extensiones o modificaciones para una clase particular de aplicaciones. Un perfil para audio y vídeo puede ser – APP: Extensions. Definidos por la aplicación (aún encontrado en el RFC 3551 [4]. ninguno). Por otro lado tenemos documentos que especifican el formato de un payload, los cuales definen como una Una descripción detallada del formato de cada paquete codificación concreta de audio o de vídeo tiene que ser se puede ver a partir de la sección 6.4.2 del RFC 3550 [3]. transportada en RTP. En la tabla 1 se presentan algunos de los payloads. Estándar Título RFC 2190 RTP Payload Format for H.263 Video Streams Figura 4. Tráfico RTCP. RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video Estos paquetes de control nos ofrecen los siguientes RFC 3016 RTP Payload Format for MPEG-4 servicios: Audio/Visual Streams – Monitorización de la calidad de servicio y control de la RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio congestión. Es la función principal de RTCP, RFC 3497 RTP Payload Format for Society of Motion proporcionando la calidad de la distribución de los Picture and Television Engineers (SMPTE) datos. Es útil tanto para emisores, como receptores, 292M Video como terceras partes. El emisor puede ajustar la RFC 4103 RTP Payload for Text Conversation transmisión en función del informe recibido; los RFC 4184 RTP Payload Format for AC-3 Audio receptores pueden determinar cuando la congestión es RFC 4587 RTP Payload Format for H.261 Video local, regional o global; y los administradores de red Streams pueden evaluar el rendimiento de la red en una Tabla 1. Ejemplos de payloads. distribución multicast. Por último, en una red, RTP y RTCP no tienen un – Identificación de la fuente. En los paquetes RTP los puerto fijo, pero se usa la siguiente regla: el puerto RTP es emisores son identificados por un número de 32 bits un número par, y el puerto RTCP es el siguiente número. generado aleatoriamente, que no son adecuados para las personas. Los paquetes RTCP SDES contienen B. Protocolo de control RTP información textual como el CNAME que se trata de un identificador único para un participante en la sesión. Es el protocolo de control diseñado para trabajar en Además pueden incluir nombre, número de teléfono y conjunción con RTP. En una sesión RTP, los participantes otra información. envían periódicamente paquetes RTCP con información referente a la calidad de los datos recibidos. – Sincronización entre flujos. Un RTCP sender report contiene una indicación de tiempo real y el Se definen cinco tipos de paquetes para reportar correspondiente timestamp del RTP. Esto puede usarse información de control: para sincronización entre flujos multimedia como sincronización entre labios y vídeo.
    • IV.RTSP – Información de control escalable. Los paquetes RTCP El protocolo de streaming en tiempo real (RTSP) fue son enviados periódicamente por los participantes, y desarrollado por RealNetworks, Netscape Communications cuando el número de estos incrementa es necesario un y Columbia University y está publicado en el RFC 2326 [5], equilibrio entre tener información de control es un protocolo a nivel de aplicación para el envío de datos actualizada y limitar el tráfico de control. RTP limita el con propiedades de tiempo real que puede trabajar junto a tráfico de control a un máximo del 5% de todo el otros protocolos como RTP y RSVP. Proporciona un tráfico de la sesión. 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 C. Protocolo RSVP protocolo puede funcionar sobre UDP, UDP multicast y Protocolo de reservación de recursos (Resource TCP. ReSerVation Protocol). Permite que el receptor de datos El servidor proporciona el contenido multimedia, los acuerde una calidad de servicio determinada extremo a clientes solicitan continuamente datos al servidor; y RTSP extremo para el flujo. se comporta como un mando a distancia entre un cliente y el Las aplicaciones en tiempo real usan RSVP para servidor, que permite: reservar los recursos necesarios en routers durante la transmisión que se va a llevar a cabo. – Conseguir datos del servidor. El cliente le pide al En el diseño de RSVP han formado parte: Xerox Corp.'s servidor que configure una sesión para que le envíe los (PARC), MIT, y el Information Sciences Institute of datos solicitados. University of California (ISI). – Invitar a un servidor a una conferencia. En cuanto a su funcionamiento, el receptor precisa de – Añadir datos a una presentación existente. El cliente o calidad de servicio para su transferencia; y RSVP es el servidor pueden notificarle a la otra parte sobre responsable de las negociaciones de parámetros de datos que se encuentran disponibles. conexión con los routers, y de mantener la situación para proporcionar el servicio requerido. 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 D. Protocolos SRTP y SRTCP operaciones similares. Cada flujo esta identificado por una El Secure Real-time Transport Protocol o (SRTP) URL RTSP. Cada presentación y sus propiedades define un perfil de RTP, para proporcionar cifrado, multimedia quedan recogidas en un fichero de descripción autenticación de mensajes e integridad, además de de la presentación, y este fichero puede ser obtenido por los protección contra reenvíos de los datos RTP tanto en clientes vía HTTP, por email o cualquier otro medio. aplicaciones unicast como multicast. Fue desarrollado por un pequeño equipo del protocolo IP y expertos en Pero RTSP difiere de HTTP en algunos aspectos: criptografía de Cisco y Ericsson. Fue publicado por el IETF mientras que HTTP es un protocolo sin estados, un servidor como el RFC 3711 [9]. RTSP tiene que mantener los estados de las sesiones para hacer corresponder pedidos y flujos. Y además, HTTP es SRTP esta relacionado con el protocolo Secure RTCP un protocolo asimétrico donde el cliente hace peticiones y (SRTCP), que añade características de seguridad al el servidor responde, mientras que en RTSP ambos pueden protocolo de control. hacer peticiones. Utilizando esta nueva pareja de protocolos, cada una de Los servicios y operaciones soportados son los las características que proporcionan (cifrado, autenticación siguientes: e integridad) son opcionales; excepto en SRTCP que es – OPTIONS: El cliente o el servidor le comunican a la obligatoria la autenticación de los mensajes. otra parte que opciones aceptan. – DESCRIBE: El cliente consigue una descripción de un Para cifrar y descifrar flujos de datos (proporcionando contenido identificado por una URL RTSP. confidencialidad) hace uso del algoritmo simétrico de – ANNOUNCE: Actualiza la descripción en tiempo real. cifrado de bloques AES (también conocido como Rijndael). – SETUP: El cliente le pregunta al servidor donde conseguir los datos. Para la autenticación de mensajes y proteger la – PLAY: El cliente le pide al servidor que comience a integridad se utiliza el algoritmo HMAC-SHA1 (funciones mandarle los flujos configurados en SETUP. hash criptográficas en combinación con una clave secreta), – PAUSE: El cliente detiene el envío sin liberar los calculado sobre el payload y algunos campos de la recursos en el servidor. cabecera, como el número de secuencia.
    • – TEARDOWN: El cliente solicita al servidor que Inicialmente solo se podía compilar para Mac OS X, detenga el envío del flujo especificado y libere todos pero a día de hoy funciona sobre Linux, FreeBSD, Solaris, los recursos asociados a él. Tru-64 Unix, Mac OS 9 y Windows. – GET_PARAMETER: Consigue el valor de un parámetro de una presentación o flujo. VI.CONCLUSIONES – SET_PARAMETER: Establece el valor de un Hemos visto como ha evolucionado el transporte de parámetro de una presentación o flujo. contenidos multimedia en Internet, las empresas implicadas, – REDIRECT: El servidor informa al cliente de que debe estándares usados y algunas aplicaciones finales. conectarse al servidor indicado en la cabecera. – RECORD: El cliente comienza a grabar datos de la Gracias a estos estándares es posible la compatibilidad presentación. entre clientes y servidores de distintas plataformas y sistemas operativos. Las peticiones RTSP son enviadas normalmente por un Hemos pasado de usar la red telefónica para conectarse a canal independiente al canal de los datos. Estos últimos Internet, a usar esta red para telefonía IP o televisión por pueden ser transmitidos por otro tipo de conexión. Internet. Y a medio plazo podremos ver todas estas tecnologías funcionar sobre el protocolo IPv6 en las variantes unicast, V.IMPLEMENTACIONES multicast, y también anycast. Existen diferentes implementaciones de los protocolos vistos anteriormente, a nivel de hardware o de software; REFERENCIAS entre ellas podemos encontrar: [1] RTP: About RTP and the Audio-Video Transport Working Group http://www.cs.columbia.edu/~hgs/rtp/ A. Cámaras IP [2] rtsp.org: Real Time Streaming Protocol Information and Updates Podemos encontrar en el mercado cámaras de vídeo con http://www.rtsp.org un puerto RJ-45 o wireless y que implementan servidores [3] RFC 3550 “ RTP: A Transport Protocol for Real-Time Applications” RTP o RTSP. Por ejemplo, el modelo 210 de Axis [15], que http://tools.ietf.org/html/rfc3550 funciona con un sistema operativo empotrado Linux 2.4 y [4] RFC 3551 “RTP Profile for Audio and Video Conferences with soporta los protocolos RTP y RTSP entre otros. 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 Figura 5. Cámara de red Axis 210 [9] RFC 3711 “The Secure Real-time Transport Protocol (SRTP)” http://tools.ietf.org/html/rfc3711 B. Java Media Framework [10] Real-Time Transport Protocol (RTP) Java Media Framework [16] (JMF) permite añadir http://www.cs.columbia.edu/~coms6181/slides/7/rtp.pdf audio, vídeo y otros contenidos con tiempo a aplicaciones y [11] Multimedia Over IP: RSVP, RTP, RTCP, RTSP applets hechos en Java. Pudiendo capturar, reproducir, http://www.cs.wustl.edu/~jain/cis788-97/ftp/ip_multimedia.pdf enviar y traducir múltiples formatos multimedia (AVI, [12] Real-time Transport Protocol MPEG, QuickTime, Sun Audio, etc). Esta API da soporte de http://www.lab.dit.upm.es/~labscom/almacen/sld/rtp.pdf RTP para clientes y servidores. Y recientemente se ha [13] RTP/RTCP and RTSP multimedia protocols for the Internet obtenido soporte para RTSP. http://planete.inrialpes.fr/~roca/doc/ecole_ete_pdms01_v6.pdf [14] Axis Communications C. Darwin Streaming Server [15] http://www.axis.com/ Darwin Streaming Server [17] es el primer servidor de [16] Java Media Framework API (JMF) streaming de código abierto que soporta RTP y RTSP con http://java.sun.com/products/java-media/jmf/ variedad de formatos entre los que se encuentran H.264, [17] Apple Darwin Streaming Server MPEG-4 y 3GPP. Fue desarrollado por Apple, es el http://developer.apple.com/opensource/server/streaming/index.html equivalente al QuickTime Streaming Server, y se basa en su código fuente. [18] Darwin Streaming Server http://en.wikipedia.org/wiki/Darwin_Streaming_Server