Este documento resume tres protocolos clave para transmisión de audio y video en tiempo real por Internet: RTP, RTCP y RTSP. RTP y su protocolo de control asociado RTCP permiten transmisión en tiempo real de datos de audio y video a través de UDP. RTSP es el protocolo de control de transmisión en tiempo real que coordina la entrega y presentación de medios transmitidos con RTP.

1. 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

2. 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.

3. 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

4. – 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.

5. 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.

6. – 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