Servidor modular de streaming con protocolo RTSP

Universidad
Rey Juan Carlos
INGENIERÍA INFORMÁTICA
Curso Académico 2006/2007
Proyecto de Fin de Carrera
SERVIDOR MODULAR DE STREAMING
CON PROTOCOLO RTSP
Autor: Pablo Montero Nóvoa
Tutores: Luis López Fernández y Micael Gallego Carrillo

Agradecimientos
Al terminar la etapa de la universidad es inevitable mirar hacia atrás y hacer
balance de todos estos años. Son muchas horas delante del ordenador peleando con las
prácticas, muchos exámenes y muchas horas de clase. Algunos sinsabores cuando los
resultados no eran los esperados, pero en estos casos una vez superado el obstáculo la
satisfacción ha sido mayor.
Ahora al terminar me quedo con la sensación de que el esfuerzo ha valido la
pena, tanto en lo personal como de cara al futuro.
En primer lugar quiero agradecer a mi familia y amigos el apoyo prestado, así
como el interés sobre el avance (más bien fecha de finalización) de este proyecto.
También quiero dar las gracias a todos mis compañeros durante este año de trabajo en el
Laboratorio de Algoritmia Distribuida y Redes: Alberto, Juan, José, Rosana, Ana,
Roberto y Despo. Gracias a Micael y Luis por su confianza y la ayuda prestada.
Por último, un recuerdo para todos los compañeros de la universidad durante
estos años, tanto en Móstoles como Helsinki.

Índice
SERVIDOR MODULAR DE STREAMING...........................................................1
CON PROTOCOLO RTSP...................................................................................1
AGRADECIMIENTOS..........................................................................................2
ÍNDICE.................................................................................................................3
RESUMEN............................................................................................................5
1.INTRODUCCIÓN...............................................................................................6
2.OBJETIVOS....................................................................................................11
3.DESCRIPCIÓN INFORMÁTICA......................................................................13
3.1. Multimedia...........................................................................................................................................13
3.2. Java.......................................................................................................................................................14
3.3. Protocolos y tecnologías de streaming...............................................................................................16
3.3.1. Protocolos......................................................................................................................................16
3.3.1.1. RTSP.................................................................................................................................... ...........16
3.3.1.2. SIP............................................................................................................................. .....................20
3.3.1.3. RTP.................................................................................................................................. ...............20
3.3.1.3.1. Arquitectura RTP.............................................................................................. ......................21
3.3.1.3.2. Alternativas a RTP.............................................................................................. ....................23
3.3.1.3. SDP........................................................................................................................................ .........24
3.3.2. Tecnologías para la creación de streaming RTP............................................................................25
3.3.2.1. Java Media Framework.................................................................................................... ...............25
3.3.2.2. Freedom for Media in Java.......................................................................................................... ....27
3.3.2.3. VLC Media Player...................................................................................................... ....................28
3.3.2.4. Gstreamer.................................................................................................................................. ......30
3.3.2.5. IBM Toolkit for MPEG-4....................................................................................................... .........31
3.4. Entorno y herramientas ....................................................................................................................33
3.4.1. Sistema operativo Windows XP....................................................................................................33
3.4.2. Entorno de desarrollo Eclipse.......................................................................................................33
3.4.3. Wireshark......................................................................................................................................34
3.4.4. JavaCC..........................................................................................................................................35
3.4.5. Reproductores multimedia............................................................................................................36
3.4.5.1. Reproductor VLC..................................................................................................................... .......36
3.4.5.2. Reproductor QuickTime Player.............................................................................................. .........37
3.5. Diseño e Implementación ..................................................................................................................39
3.5.1. Arquitectura del sistema................................................................................................................39
3.5.1.1. Diagrama de clases Java............................................................................................................. .....41
3.5.2. Proceso de desarrollo....................................................................................................................43
3.5.3. Arranque del servidor....................................................................................................................45
3.5.4. Implementación del protocolo RTSP............................................................................................47
3.5.4.1. Petición RTSP.................................................................................................................. ...............47
3.5.4.2. Respuesta RTSP................................................................................................................ ..............48

3.5.4.3. Funcionamiento del protocolo RTSP........................................................................................ .......49
3.5.4.3.1. Mensajes básicos para la reproducción de un archivo............................................ .................50
3.5.4.3.2. Otros mensajes implementados................................................................................... ............55
3.5.4.3.3. Resto de mensajes RTSP............................................................................................... ..........56
3.5.4.4. Aspectos de la implementación del protocolo................................................................................. .59
3.5.5. Mantenimiento del estado en el servidor......................................................................................62
3.5.5.1. Estructura de datos............................................................................................................ ..............62
3.5.5.2. Relación entre los mensajes RTSP y el estado del servidor........................................... ..................64
3.5.6. Módulo JmfRtpSender..................................................................................................................69
3.5.6.1. Arquitectura de Java Media Framework................................................................................ ..........69
3.5.6.2. Processors.................................................................................................................... ...................73
3.5.6.3. API para RTP.............................................................................................................. ....................78
3.5.6.4. Sesión RTP................................................................................................................................. .....79
3.5.6.5. Implementación de la clase JmfRtpSender.......................................................................... ............81
3.5.6.6. Problema de JMF: sincronización de las pistas........................................................ .......................83
3.5.7. Módulo VlcRtpSender...................................................................................................................84
3.5.7.1. Módulos VLC para streaming...................................................................................... ...................84
3.5.7.2. Comandos para el envío de datos RTP......................................................................... ...................86
3.5.7.3. Control de VLC a través de su interfaz Telnet..................................................................... ............87
3.5.7.4. Clase Runtime....................................................................................................................... ..........88
3.5.7.5. Problemas en el uso de VLC con la clase Runtime........................................................................ ..89
3.5.7.6. Implementación de la clase VlcRtpSender................................................................... ...................93
3.5.8. Módulo VlcSdpGenerator.............................................................................................................95
3.5.8.1. Ejecución de VLC como servidor RTSP................................................................... ......................95
3.5.8.2. Implementación de la clase VlcSdpGenerator................................................................... ..............97
3.5.9. Módulo FileSdpGenerator...........................................................................................................100
4.CONCLUSIONES Y LÍNEAS FUTURAS......................................................101
4.1. Conclusiones......................................................................................................................................101
4.2. Líneas futuras....................................................................................................................................102
BIBLIOGRAFÍA................................................................................................104

Resumen
La difusión de contenidos multimedia está adquiriendo cada vez más relevancia.
El acceso de los usuarios domésticos a Internet y la posibilidad de adquirir hardware
cada vez más potente son los factores que están impulsando este proceso. Dentro del
mundo de la multimedia, destaca en los últimos años la posibilidad de reproducción a
través de streaming, entendiendo como tal la reproducción de cierta información
multimedia obteniendo un flujo de datos a través de la red, sin necesidad de descargar
todo el contenido previamente al disco duro.
Este tipo de tecnología demanda un ancho de banda importante. Este factor,
unido al hecho de que los contenidos multimedia son cada vez más ricos y por lo tanto
ocupan cada vez más espacio, provoca la continua aparición de nuevos protocolos y
métodos de compresión y descompresión. Es pues un campo en constante evolución, y
resulta complicado conseguir una idea global de todas las tecnologías existentes y las
características que diferencian unas de otras.
En el presente proyecto se aborda esta cuestión, a través de la implementación
de un servidor de streaming mediante el protocolo RTSP. Dicho servidor será
configurable y de estructura modular, de forma que se puedan utilizar diferentes
herramientas para conseguir enviar los datos a los clientes, los cuales serán
reproductores multimedia habituales. Esta arquitectura permitirá además dotar al
servidor de la capacidad de evolucionar en el futuro incorporando nuevos módulos,
característica muy interesante teniendo en cuenta el dinamismo presente en el campo del
streaming.

El proceso de desarrollo implicará un estudio de las tecnologías de streaming
existentes, y su posterior adaptación e implementación en el servidor. Se evaluarán las
ventajas e inconvenientes de cada una de ellas, y se enumerarán los posibles problemas
y aspectos a mejorar.
1. Introducción
La palabra streaming hace referencia al envío de contenido multimedia
(habitualmente audio y vídeo) de forma continua desde un origen hasta un destino,
destino en el cual normalmente el contenido es reproducido a la vez que se recibe. Es un
concepto relacionado con la forma en que la información se transmite, no con el tipo de
información en si.
En realidad se puede hablar de streaming remontándonos incluso a antes de la
aparición de la informática. Por ejemplo escuchar un programa de radio o ver la
televisión se pueden considerar como transmisiones de streaming, aunque no haya
ningún ordenador involucrado, ya que la forma en que se transmite el contenido encaja
dentro de la definición dada anteriormente. Como contraposición a este ejemplo,
podríamos ver el mismo vídeo o escuchar el mismo sonido utilizando medios que no
serían streaming, como una película en DVD o un CD de música.
En el campo de la informática, el interés por distribuir contenidos multimedia
existe desde los inicios de la computación, a mediados del siglo pasado, si bien al
principio tímidamente debido a las limitaciones tecnológicas de la época y al alto coste
que era necesario par alcanzar un rendimiento mínimamente aceptable, coste prohibitivo
para los usuarios domésticos. Estas circunstancias unidas al hecho de que Internet no
existía, hacían que esta área no pudiera ser comercialmente rentable. Durante los años
sesenta y setenta los avances fueron mínimos.
En la década de los ochenta se produjeron avances significativos en cuanto a la
capacidad del hardware, especialmente aumento de velocidad en los procesadores y

uses con mayor ancho de banda. Además se redujeron costes, de forma que empezaron
a aparecer usuarios domésticos con equipos capaces de reproducir contenido
multimedia. Sin embargo las redes de ordenadores eran todavía muy limitadas y lentas,
Internet aun estaba dando sus primeros pasos, así que la mayoría del contenido
multimedia todavía se transmitía a través de medios no streaming, como disquetes o
CD-ROMS.
En los noventa se ha producido el gran salto tecnológico que ha permitido la
expansión de los contenidos multimedia a gran escala. En primer lugar las prestaciones
de los equipos domésticos han aumentado de forma vertiginosa, tanto es así que
continuamente aparecen nuevos modelos de procesadores, memorias, etc. que dejan
obsoletos a los modelos anteriores en poco tiempo.
Otro factor fundamental han sido las mejoras en las redes y especialmente en
Internet. No solo en cuanto a fiabilidad y ancho de banda, si no en cuanto a
accesibilidad: hasta hace no muchos años su uso estaba generalmente limitado a
determinados ámbitos (universidades, tecnología militar, investigación). A día de hoy
Internet se ha expandido al ámbito doméstico, y cada día siguen aumentando tanto el
número de usuarios como la velocidad de las conexiones. También ha contribuido el uso
de protocolos y formatos estandarizados y bien conocidos, esto es fundamental para que
millones de usuarios puedan compartir y reproducir el mismo contenido.
Por último hay que señalar un factor que si bien no es tecnológico, es el que ha
posibilitado el desarrollo de todos los anteriores: la aparición del negocio en Internet.
Gracias a estos factores los usuarios domésticos pudieron empezar a descargar y
reproducir contenidos multimedia. Sin embargo, pronto surgió una nueva necesidad.
Los archivos de audio y vídeo eran cada vez más ricos y por lo tanto empezaron a
ocupar más espacio. No había tecnologías de streaming, y era necesario tener todo el
archivo grabado en disco antes de poder hacer uso de él. Esto, en un entorno donde el
ancho de banda es limitado, provocó que los tiempos de espera descargando un archivo
antes de poder reproducirlo empezaran a ser cada vez mayores, acabando muchas veces
con la paciencia del usuario.

De ahí surgió el concepto de audio y vídeo en tiempo real, y en los últimos años
se ha producido una auténtica invasión de esta tecnología en la Web. Para el usuario ha
supuesto un cambio radical, ya que un simple doble clic basta para empezar a ver u oír
el archivo deseado de forma prácticamente inmediata. Por otra parte han aparecido
necesidades tecnológicas asociadas a este tipo de demanda, donde la capacidad y estado
de la red tienen un fuerte impacto. Por ejemplo nuevos protocolos de transmisión,
nuevas formas más eficaces de comprimir la información para facilitar el streaming de
archivos muy grandes, la aparición del multicasting, que permite enviar la misma
información a muchos usuarios simultáneamente sin tener que replicarla para cada uno
de ellos y ahorrando por lo tanto ancho de banda, etc.
La filosofía del streaming es simple: dividir un archivo grande en pequeños
paquetes que se pueden enviar de forma continua, para que el destinatario pueda
empezar a reproducir el archivo en cuanto llena su buffer de entrada. Los paquetes son
almacenados únicamente el tiempo necesario para reproducirlos, y por lo tanto no
quedan almacenados en el disco duro. Además, el servidor debe ser capaz de informar
previamente al cliente de los formatos de audio y vídeo que va a utilizar, para que el
cliente pueda descomprimir y reproducir el contenido correctamente. Por otra parte el
contenido origen no tiene que ser necesariamente un archivo almacenado localmente, si
no que puede ser una fuente de captura en tiempo real. En este sentido, es necesario
diferenciar entre dos tipos de streaming:
• Streaming en vivo: el contenido multimedia es capturado y enviado
inmediatamente. Un ejemplo claro sería una videoconferencia.
• Streaming bajo demanda: el contenido está previamente almacenado en algún
servidor, y el usuario decide cuando visualizarlo.
El streaming ha abierto una amplia gama de posibilidades en Internet y las
telecomunicaciones en general, y su presencia sigue aumentando. Algunos ejemplos
son:
• Desarrollo nuevas formas de televisión que incluyan streaming mezclando
imágenes reales con ficticias, y la composición de historias con texto, fotografía,
audio y video, ya sea con fines educativos o de entretenimiento.

• Videoconferencias en forma de video presencial o conferencias pregrabadas para
audiencias en Internet o Intranet. Telemedicina.
• Videopresentaciones en diapositivas acompañadas de una narración en audio.
• Karaoke o canciones para mezclas de MIDI (Interfaz Digital de Instrumentos
Musicales), con animación y texto de referencia. Sesión en vivo de MIDI, a
través del teclado o de aparatos de percusión vía Internet.
• Programas de video dinámicos para aumentar la capacitación en diferentes
departamentos de una empresa.
• Presentaciones de streaming en Power Point.
El streaming, es un área de la informática en constante evolución. Hay varias
tecnologías de streaming, y continúan apareciendo otras nuevas, de forma que no hay
una única aplicación que permita reproducir cualquier contenido. Además,
continuamente se desarrollan nuevos formatos de compresión y descompresión que
aumentan la eficacia de las transmisiones y ahorran ancho de banda, obligando al
usuario a actualizarse para poder ver los últimos vídeos. Esto, unido a la importancia
creciente del streaming en Internet, conduce a la conclusión de que es un área que
merece la pena investigar.
Por último cabe señalar que la popularización del streaming ha conllevado la
aparición de ciertas cuestiones sociales y legales. Por ejemplo, la distribución de
contenido inadecuado o con derechos de autor. Algunos sectores comerciales temen que
se puedan producir pérdidas económicas al poder los usuarios acceder a casi cualquier
contenido de forma gratuita desde sus casas, y evitando ver los mensajes publicitarios al
poder manejar la reproducción a su antojo. De hecho los productores de streaming
vienen tratando de impedir que los usuarios puedan grabar en disco los vídeos que están
visualizando, tanto por medios técnicos como legales. Sin embargo, estas medidas
pueden ser habitualmente burladas. La legislación ha tenido que ponerse al día, en
cuanto a temas de derechos de autor, patentes y licencias.

2. Objetivos
El objetivo de este proyecto es la implementación de un servidor de streaming.
Se desarrollará un servidor que esperará conexiones de los clientes, y será capaz de
enviarles un flujo de streaming para que estos lo reproduzcan, usando algún tipo de
protocolo existente. Los clientes harán peticiones de streaming indicando el nombre de
la fuente o fichero deseado, y el servidor será capaz de informar al cliente del tipo de
multimedia que se va a enviar, y luego transmitir un flujo de datos coherente con lo
anunciado. Por lo tanto, las tareas fundamentales que el servidor debe ser capaz de
acometer son:
• Intercambio de mensajes con los clientes.
• Ser capaz de obtener información sobre los formatos de los archivos que sirve.
• Transmitir a los clientes la información sobre dichos formatos.
• Transmitir a los clientes el propio flujo de streaming.
Hay que señalar que los objetivos concretos en cuanto a funcionalidad que debe
cumplir el servidor no están claros al inicio del desarrollo (posibilidad de pausar la
transmisión, saltar a un punto determinado del archivo, etc.) Esto es debido a que se
parte de un desconocimiento de las capacidades que ofrecen las actuales tecnologías de
streaming para los desarrolladores. Por lo tanto, se ha realizado una labor de
investigación de algunas de estas tecnologías y se ha tratado de añadir toda la
funcionalidad que ha sido posible. Sin embargo, podemos señalar algunos requisitos
básicos que se ha considerado que el servidor debe cumplir en cualquier caso:
• Modularidad: esta es la principal característica que se pretende incorporar en el
servidor. El servidor no usará una única tecnología para la obtención de la
información sobre los archivos y la creación del flujo de streaming, si no que
será configurable, de forma que se puedan implementar diversas soluciones y
elegir cuales de ellas utilizar al arrancar el servidor.

• Extensibilidad: al hilo de la característica anterior, se implementará el servidor
de forma que en un futuro sea fácil añadir nuevos módulos. Esta característica y
la anterior son especialmente deseables, dado el carácter dinámico de las
tecnologías de streaming.
• Compatibilidad: el servidor debe ser capaz de interoperar con varios clientes
diferentes, que serán reproductores multimedia habituales. Más concretamente
deberá ser compatible con los reproductores VLC y QuickTime, de los que se
hablará más adelante.
• Calidad de servicio: en la medida de lo posible la calidad de la reproducción en
los clientes debe ser óptima, siendo la imagen y sonido fieles a los originales y
no produciéndose retardos excesivos ni ralentizaciones.
• Escalabilidad: el servidor debe ser capaz de atender a varios clientes
simultáneamente.
• Capacidad de servir ficheros almacenados localmente: el objetivo principal
es que el cliente pueda reproducir los ficheros que el servidor tiene almacenados
en su disco duro (vídeo bajo demanda).

3. Descripción informática
3.1. Multimedia
En el presente documento se habla de archivos y contenido multimedia, y si bien
las nociones básicas de este concepto son ampliamente conocidas, llegado este punto
conviene definir más formalmente algunas de sus características.
Un contenido multimedia es aquel que está compuesto de diversos “medios”,
como pueden ser audio, video, texto, etc. Se dice que un contenido multimedia está
basado en el tiempo en tanto que cada uno de sus medios cambia significativamente con
él. Esta característica hace que un contenido multimedia requiera ser proporcionado y
procesado en unas condiciones temporales estrictas. Por ejemplo cuando se reproduce
un video, si los datos multimedia no pueden ser proporcionados lo suficientemente
rápido pueden producirse pausas y retardos en la reproducción; por otro lado si los datos
no pueden ser recibidos y procesados lo suficientemente rápido el video se reproduce a
saltos ya que se desechan cuadros como mecanismo para mantener la tasa de
reproducción. A continuación se enumeran los principales elementos que componen el
contenido multimedia, conviene que el lector se familiarice con ellos porque serán
usados a lo largo de todo el documento.
• Pista (track): Cada uno de los medios de los que se compone un contenido
multimedia. Por ejemplo un contenido multimedia correspondiente a una
videoconferencia puede contener una pista de audio y otra de vídeo. Se dice que
las pistas que componen un contenido multimedia están multiplexadas. Al
proceso de extracción de las distintas pistas que componen un contenido
multimedia se le denomina demultiplexación.
• Formato (format): cada pista posee un formato que define como están
estructurados los datos que forman parte de ella. Los distintos formatos se
distinguen en función de:

o La calidad que proporcionan
o Su exigencia de recursos de CPU para ser procesados
o La cantidad de ancho de banda requerida para su transmisión
Cada formato está destinado a diferentes tipos de aplicaciones y
servicios. Formatos como MPEG 1 de gran calidad pero altos requerimientos de
ancho de banda están destinados usualmente a aplicaciones que trabajan con
almacenamiento local o en dispositivos ópticos como CD-ROM o DVD donde el
ancho de banda y la capacidad de almacenamiento no son limitantes. En cambio
otros formatos como H.261 y H.263 se usan para aplicaciones de
videoconferencia donde el ancho de banda es un bien escaso; de la misma forma
G.723 se usa para producir voz codificada con tasa de bits reducida para
aplicaciones de telefonía IP, por ejemplo.
• Contenedor (container o content-type): es la estructura en que los datos son
enviados o almacenados, en el segundo caso irán asociados a una extensión de
archivo. Cada tipo de contenedor puede llevar dentro pistas en diferentes
formatos, y ser manejado por unas u otras herramientas. Algunos ejemplos de
contenedores habituales son AVI, MP3, WAV, MPG o 3GP, entre otros.
• Transcodificación (transcoding): es el proceso consistente en cambiar el
formato de una pista. Para conseguirlo se usan los codecs (códificadores-
decodificadores), que son programas que incorporan algoritmos capaces de
hacerlo. Cada tipo de codec puede manejar ciertos formatos de entrada y salida.
• Renderización: es el proceso mediante el cual se presenta el multimedia al
3.2. Java
usuario. Normalmente implica la transferencia del contenido digital a algún
dispositivo de salida como un monitor o altavoz.
El lenguaje de programación elegido ha sido Java, al ser considerado la mejor
opción para este proyecto. Java es un lenguaje multiplataforma, cuyos programas se
pueden ejecutar en cualquier sistema operativo que tenga instalada la máquina virtual de
Java. Sin embargo y como se verá más adelante, habrá que considerar ciertas

circunstancias que nos obligarán a decantarnos por un sistema operativo. Tiene ciertas
características que le hacen ser adecuado para el problema que se pretende resolver:
• Simplicidad y alto nivel: es un lenguaje más sencillo que otras opciones como
C++, y libera al programador de preocuparse de ciertas tareas de bajo nivel,
como por ejemplo el uso de la memoria y el manejo de punteros.
• Orientación a objetos: Java es un programa orientado a objetos, en el que la
unidad principal de programación es la clase. Esta característica será útil para,
tal y como se pretende, implementar un servidor de carácter modular. Por
ejemplo si se desea poder generar un flujo de stream de varias maneras
diferentes, habrá que definir una interfaz (conjunto de métodos que una clase
debe implementar) y después implementar varias clases que cumplan la
funcionalidad especificada en ella. A la hora de arrancar el servidor se podrá
elegir entre alguna de estas clases, instanciando objetos a partir de ellas. Además
la orientación a objetos también facilita la escalabilidad, ya que si es necesario
atender a varios clientes a la vez, esto será posible creando varias instancias de
las clases involucradas en el proceso.
• Orientación a la red: la API de Java proporciona clases que facilitan el uso de
conexiones de red y el envío y recepción de datos a través de las mismas. En
particular, los sockets.
• Posibilidad de usar línea de comandos: Java permite la ejecución de
programas de forma similar a si lo hiciéramos escribiendo comandos a través de
una consola del sistema operativo. Como se verá posteriormente, esto
posibilitará el uso de determinadas aplicaciones de streaming ajenas a Java.
La elección de Java tendrá como consecuencia la necesidad de elegir
herramientas de desarrollo que sean compatibles con este lenguaje de programación.
Posteriormente en el capítulo sobre tecnologías de streaming se mencionarán algunas de
ellas.

3.3. Protocolos y tecnologías de streaming
En este capítulo se van a enumerar algunos de los protocolos y tecnologías de
streaming existentes, repasando sus características principales. También se justificará
por qué se han elegido algunos de ellos para la implementación del servidor.
3.3.1. Protocolos
3.3.1.1. RTSP
El protocolo de flujo de datos en tiempo real (del inglés Real Time Streaming
Protocol) establece y controla uno o varios flujos sincronizados de datos, ya sean de
audio o de vídeo. RTSP actúa como un mando a través de la red para servidores
multimedia, y se sitúa en el nivel de aplicación dentro del modelo OSI 1 .
RTSP es un protocolo no orientado a conexión, en lugar de esto el servidor
almacena el estado asociado a las diferentes sesiones de los clientes, y para diferenciar
dichas sesiones se usa un identificador de sesión. Debido a esto en el transcurso de una
sesión RTSP un cliente puede abrir y cerrar varias conexiones a nivel de transporte, sin
que la sesión RTSP se vea afectada.
Es además un protocolo de carácter textual, es decir que los mensajes están
formados por cadenas de caracteres en texto plano (estándar UTF-8). Esto ofrece varias
ventajas, como la posibilidad de añadir nuevos parámetros fácilmente, teniendo en
cuenta además que los parámetros son auto-explicativos, gracias al uso de palabras que
describen su función. Como el número de parámetros es pequeño y la frecuencia en el
envío de mensajes es baja, la eficiencia no resulta un problema.
Estas son sus principales propiedades:
1 El modelo OSI es una descripción abstracta y por capas de los protocolos de comunicaciones en las
redes de ordenadores.

• Seguridad: RTSP reutiliza mecanismos de seguridad. Todas las formas de
autentificación HTTP son directamente aplicables.
• Independencia del protocolo de transporte: RTSP puede usar indistintamente
protocolos de datagrama no fiables (UDP) o fiables (RDP, no muy extendido) o
un protocolo fiable orientado a conexión como TCP.
• Capacidad multi-servidor: cada flujo multimedia dentro de una presentación
puede residir en servidores diferentes, el cliente automáticamente establece
varías sesiones concurrentes de control con los diferentes servidores y la
sincronización la lleva a término la capa de transporte.
• Posibilidad de controlar dispositivos de grabación: el protocolo puede
controlar dispositivos de grabación y reproducción, por ejemplo cámaras IP
RTSP.
• Adecuado para aplicaciones profesionales: RTSP soporta resolución a nivel de
frame 2 mediante marcas temporales SMPTE 3 para permitir edición digital.
Hay que resaltar que RTSP es únicamente un protocolo de control, y el envío de
los datos de streaming se deberá realizar mediante algún otro protocolo destinado a tal
efecto. En la mayoría de los casos RTSP usará TCP como protocolo de transporte, y el
protocolo para la transmisión usará UDP. A continuación se muestra un ejemplo de
mensaje RTSP:
DESCRIBE rtsp://193.147.59.231:10000/video.mp4 RTSP/1.0
CSeq: 1
Accept: application/sdp
Bandwidth: 384000
Accept-Language: en-US
Intencionadamente el protocolo es similar en sintaxis y operación a HTTP de
forma que los mecanismos de expansión añadidos a HTTP pueden en muchos casos
2 Una frame es una imagen independiente que forma parte de una animación. Aunque la traducción en
castellano significa literalmente “fotograma”, también puede aplicarse al sonido.
3 Las marcas SMPTE (Society of Motion Picture and Television Engineers) se usan para etiquetar frames
individuales de un contenido multimedia con códigos de tiempo.

añadirse a RTSP. Los códigos de estado son muy parecidos, valga como ejemplo el
familiar ‘404 Not Found’ que todos hemos visto en nuestro navegador alguna vez. En
cualquier caso RTSP difiere en un número significativo de aspectos de HTTP:
• RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente.
• Un servidor RTSP necesita mantener el estado de la conexión al contrario que
HTTP.
• Tanto el servidor como el cliente pueden lanzar peticiones (aunque el cliente
solo puede lanzar peticiones en el caso de las conexiones persistentes, esto es,
cuando dentro de una sesión RTSP no se producen múltiples conexiones a nivel
de la capa de transporte).
• Los datos son transportados por un protocolo diferente.
Dadas sus características el protocolo RTSP se usa fundamentalmente en tres
contextos diferentes:
• Invitación de un servidor multimedia a una conferencia: Un servidor puede ser
invitado a unirse a una conferencia existente en lugar de reproducir la
presentación o grabar todo o una parte del contenido. Este modo es útil para
aplicaciones de enseñanza distribuida dónde diferentes partes de la conferencia
van tomando parte en la discusión.
• Adición multimedia a una presentación existente: Particularmente para
presentaciones en vivo, útil si el servidor puede avisar al cliente sobre los
nuevos contenidos disponibles.
• Recuperar contenidos multimedia del servidor: Típicamente, el cliente pedirá al
servidor datos sobre el contenido multimedia deseado, y después especificará los
parámetros de transporte para que el servidor envíe el flujo de stream al destino
correcto. El cliente puede solicitar la descripción de una presentación por HTTP
o cualquier otro método. Si la presentación es multicast, la descripción contiene
los puertos y las direcciones que serán usados. Si la presentación es unicast el
cliente es el que proporciona el destino por motivos de seguridad.

Tal y como reza el título del proyecto, RTSP es el protocolo de control que se ha
implementado en el servidor. Se ha considerado que es el más adecuado para alcanzar
los objetivos propuestos, fundamentalmente por dos razones. En primera lugar dadas
sus características es el más adecuado para la recuperación de contenidos multimedia de
un servidor, como se menciona en el párrafo anterior. Por otra parte, existen varios
reproductores multimedia domésticos que soportan el protocolo, como VLC y
QuickTime. Cuando se aborde la implementación del protocolo en el servidor se
explicará su funcionamiento en detalle.

3.3.1.2. SIP
Dentro del campo de los protocolos para el control de streaming, uno de los que
más se puede comparar con RTSP es SIP. El objetivo del Session Initiation Protocol es
la iniciación, modificación y finalización de sesiones interactivas de usuario donde
intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos
online y realidad virtual. Es por tanto un protocolo de control cuya funcionalidad es
similar a RTSP, y además también se parece a este que está basado en texto plano y es
similar a HTTP.
Es un protocolo desarrollado por el IETF 4 , y en noviembre del año 2000 fue
aceptado como el protocolo de señalización de 3GPP 5 y elemento permanente de la
arquitectura IMS 6 . SIP es además uno de los protocolos de señalización para voz sobre
IP.
SIP funciona en colaboración con otros muchos protocolos pero sólo interviene
en la parte de negociación al establecer, modificar y finalizar la sesión de comunicación.
En un uso normal, las sesiones SIP se apoyan en el protocolo RTP, que es el verdadero
portador para lo contenidos de audio y vídeo. SIP es un es una alternativa a RTSP en el
sentido de ser igualmente un protocolo de control, pero está más orientado a
dispositivos móviles y por lo tanto RTSP es más adecuado en nuestro caso.
3.3.1.3. RTP
4 El IETF (Internet Engineering Task Force) es una organización internacional de carácter abierto que
tiene como objetivo contribuir a la ingeniería de Internet. Sus miembros velan porque la arquitectura de la
red y sus protocolos técnicos funcionen correctamente. Es la organización que se considera con más
autoridad para establecer modificaciones de los parámetros técnicos bajo los que funciona la red.
5 3GGP (3rd Generation Parthership Project) es un acuerdo de colaboración entre grupos de
comunicaciones, con el objetivo de conseguir una especificación de sistema global para todos los
teléfonos móviles de tercera generación (3G).
6 IMS (IP Multimedia Subsystem) es una arquitectura para el desarrollo de protocolos para dispositivos
móviles que posibilite la transferencia de multimedia a través de Internet.

RTP son las siglas de Real-time Transport Protocol (Protocolo de Transporte de
Tiempo real). Es un protocolo de nivel de aplicación (no de nivel de transporte, como su
nombre podría hacer pensar) utilizado para la transmisión de información en tiempo
real, como por ejemplo audio y vídeo en una videoconferencia. Se sitúa sobre UDP en
el modelo OSI. Está desarrollado por el grupo de trabajo de transporte de audio y video
del IETF, publicado por primera vez como estándar en 1996 y actualizado
posteriormente en 2003 mediante la RFC 3550, que constituye el actual estándar.
Inicialmente se publicó como protocolo multicast, aunque se ha usado en varias
aplicaciones unicast. Se usa frecuentemente en sistemas de streaming, junto a RTSP,
SIP, videoconferencia y aplicaciones similares. Existe una extensión del perfil de RTP
llamada SRTP (Secure Real-time Transport Protocol) que se usa para conferencias de
audio y vídeo en entornos que necesiten de confidencialidad, autenticación de mensajes
y protección de reenvío para flujos de audio y vídeo.
Va de la mano del protocolo RTCP (RTP Control Protocol), este es un protocolo
de comunicación que proporciona información de control que está asociado con un flujo
de datos para una aplicación multimedia (flujo RTP). Trabaja junto con RTP en el
transporte y empaquetado de datos multimedia, pero no transporta ningún dato por sí
mismo. Se usa habitualmente para transmitir paquetes de control a los participantes de
una sesión RTP, siendo su función principal la de informar de la calidad de servicio
proporcionada por RTP. Este protocolo recoge estadísticas de la conexión y también
información como por ejemplo bytes enviados, paquetes enviados o paquetes perdidos
entre otros. Una aplicación puede usar esta información para incrementar la calidad de
servicio, ya sea limitando el flujo o usando un codec de compresión diferente. RTCP por
sí mismo no ofrece ninguna clase de cifrado de flujo o de autenticación. Para tales
propósitos se puede usar una extensión llamada SRTCP. A partir de este punto, siempre
que se hable de RTP se estará haciendo referencia implícitamente al binomio de
protocolos RTP/RTCP.
3.3.1.3.1. Arquitectura RTP

Una sesión RTP es la asociación de un conjunto de aplicaciones que se
comunican a través de RTP. Un participante de la sesión se identifica mediante una
dirección de red y un par de puertos. El primero se usará para los paquetes de datos
(RTP) y el segundo para los paquetes de control (RTCP), siendo siempre el primero un
número par y el segundo un número impar. Los participantes pueden enviar datos,
recibirlos o enviar y recibir a la vez. Cada tipo de contenido es transmitido en sesiones
diferentes. Por ejemplo si en una videoconferencia se usan a la vez audio y video, se
usará una sesión separada para cada uno de ellos. Esto ofrece la posibilidad a los
clientes de elegir qué tipos de contenidos quieren recibir. Por ejemplo un cliente con
ancho de banda escaso, podría preferir la opción de recibir solo el sonido de la
videoconferencia.
El contenido es enviado en forma de flujos de paquetes de datos. Cada paquete
consta de dos partes: una cabecera estructurada y los propios datos. En la figura 3.1 se
puede ver el esquema de un paquete RTP.
Figura 3.1: paquete RTP
Hay varias cabeceras y no tiene sentido analizar la estructura de los paquetes a
muy bajo nivel, baste señalar que algunas de las cabeceras incluyen números de
secuencia, etiquetas de tiempo para tareas de sincronización y un flag para indicar el
tipo de contenido.

3.3.1.3.2. Alternativas a RTP
Existen algunas alternativas a RTP para la transferencia de streaming, si bien
ninguna es realmente parecida. El protocolo HTTP puede ser usado tanto para la
negociación como para la transmisión de la información, aunque su principal cometido
es la petición y respuesta de páginas HTML. También se puede mencionar el protocolo
MMS (Microsoft Media Services), que el reproductor Windows Media Player utiliza
para tareas de streaming en unicast. Este protocolo acabó cayendo en desuso, y
finalmente Microsoft dejó de darle soporte con la aparición del Windows Media Player
11 en el año 2006.
RTP es claramente la mejor alternativa, de hecho es prácticamente la única para
usar junto con protocolos de control como RTSP o SIP. La mayoría de reproductores
multimedia soportan el protocolo, y es el más extendido para streaming en Internet.
Además existen tecnologías accesibles que permiten a los desarrolladores la creación y
recepción de flujos RTP, algunas de esas tecnologías se usarán en la implementación del
servidor.

3.3.1.3. SDP
El Session Description Protocol (SDP), es un protocolo para describir los
parámetros de inicialización de los flujos multimedia. Fue publicado por el IETF en el
RFC 2327. Es un protocolo textual, y se puede usar en conjunción con RTSP o SIP para
informar al cliente de las características del flujo de streaming que se va a enviar, tanto
en lo referente al contenido como a la manera en que se va a transmitir.
Más concretamente, un SDP consiste en una cadena de texto donde se informa
de las pistas disponibles, en qué formato se encuentran, y otros parámetros relacionados
con el contenido, como por ejemplo la duración. Con esta información los clientes
tendrán constancia de las pistas disponibles y qué formato, pudiendo seleccionar las que
deseen y elegir los codecs adecuados para que la reproducción sea correcta. Si el
reproductor no dispone de ellos, debería desistir. A continuación se muestra un ejemplo
de SDP.
v=0
o=- 5710093000 3 IN IP4 193.147.59.231
c=IN IP4 0.0.0.0
t=0 0
a=tool:vlc 0.8.6a
a=range:npt=0-151.700
m=video 0 RTP/AVP 32
a=rtpmap:32 MPV/90000
a=control:rtsp://193.147.59.231:10000/intro.mpg/trackID=0
m=audio 0 RTP/AVP 14
a=rtpmap:14 MPA/90000
a=control:rtsp://193.147.59.231:10000/intro.mpg/trackID=1
Para comprender la estructura del SDP se mencionará el significado de algunas
de las líneas de texto. El texto a=range:npt=0-151.700 indica que el SDP corresponde
a un archivo que tiene una duración de 151.7 segundos. Las tres siguientes líneas
informan de la existencia de una pista de vídeo, que será transmitida por RTP. Se
proporciona información sobre su formato, y finalmente la URL de control asociada a
ella. Por último se informa análogamente sobre las características de la pista de audio
disponible.
SDP será el protocolo usado para anunciar a los clientes las características de los
contenidos multimedia que ofrecerá el servidor RTSP.

3.3.2. Tecnologías para la creación de streaming RTP
Se han elegido los protocolos RTSP y SDP para el control de las sesiones de
streaming y la descripción de los contenidos. Dado el carácter textual de ambos, su
implementación en el servidor se hará de forma manual. La tercera pieza del servidor es
la generación de datos RTP, y en este caso será necesaria la utilización de alguna
tecnología que lo permita. En este capítulo se describen las características principales de
algunas de estas tecnologías, incluyendo las que finalmente se van a usar
3.3.2.1. Java Media Framework
Java Media Framework (JMF a partir de ahora) es una interfaz de programación
de aplicaciones, (API por sus siglas en inglés). Es un paquete opcional que no forma
parte de la plataforma estándar de Java, y permite a los desarrolladores añadir a sus
programas en java el manejo de contenido multimedia. Con esta API es posible realizar
varias tareas con el contenido multimedia: capturar, reproducir, grabar y por último y
más importante para este proyecto, crear flujos de streaming. Además de forma
simultánea a estas tareas es capaz de realizar funciones de procesamiento, como por
ejemplo cambiar el formato de las pistas. Es una API gratuita pero no libre.
Los principales objetivos de JMF son:
• Ser fácil de programar.
• Permitir la captura de datos multimedia.
• Permitir el desarrollo de aplicaciones de streaming y conferencia.
Específicamente, uno de los principales objetivos de JMF es permitir la
transmisión y recepción de streaming usando el protocolo RTP.
• Permitir a los desarrolladores avanzados crear soluciones personalizadas a partir
de la API existente, integrando fácilmente nuevas características.
• Proporcionar acceso a los datos multimedia en crudo (sin formato).

• Permitir el desarrollo de elementos personalizados a través de plugins
(multiplexadores/demultiplexadores, codecs, renderizadores, etc.
La primera versión apareció en 1997 y las últimas modificaciones por parte de
Sun Microsystems fueron añadidas en 2004. A día de hoy esto denota cierto abandono,
pero sigue siendo una herramienta válida usada por muchos desarrolladores, y prueba de
ello es la actividad que hay en los foros de Internet. Además de la propia API, se
incluyen una serie de herramientas adicionales:
• JMStudio: un reproductor básico con interfaz gráfica. Ha sido especialmente
útil durante el desarrollo porque permite abrir y reproducir un flujo de streaming
vía RTP, especificando la dirección IP y puerto correspondiente. Con esto es
posible comprobar en un momento dado si se está creando un flujo de RTP, ya
sea con el propio JMF u otra herramienta, siempre que el formato pueda ser
reproducido.
• JMFRegistry: una interfaz gráfica para gestionar las características de JMF,
como preferencias y plugins.
• JMFCustomizer: herramienta para crear archivos personalizados JAR (tipo de
archivo que permite ejecutar aplicaciones escritas en Java), únicamente con las
clases JMF necesarias, permitiendo así a los desarrolladores crear aplicaciones
más reducidas. No se ha usado en este proyecto.
• JMFInit: herramienta para el control de los dispositivos de captura audio y
vídeo.
Además JMF proporciona los Performance Packs, paquetes específicos para una
plataforma y que mejoran el rendimiento. Están disponibles para Windows, Linux y
Solaris.
Hay que señalar algunos inconvenientes que acarrea el usar JMF. El principal es
sin duda su estado de abandono. Esto provoca que no estén soportados muchos de los
formatos y codecs de uso actual, como por ejemplo MPEG-2, MPEG-4, Windows
Media, Real Media, la mayoría de películas en QuickTime y Flash 2. Además tampoco
es posible manejar el popular formato de audio MP3.

3.3.2.2. Freedom for Media in Java
Freedom for Media in Java (FMJ) es un intento para crear una implementación
libre de JMF. Su principal objetivo es crear una librería de carácter totalmente libre que
sea compatible con JMF e incluya todas sus funcionalidades, incluyendo captura,
procesamiento, reproducción y transmisión a través de gran variedad de medios. Este
objetivo implica las siguientes metas a conseguir:
• Crear una implementación sustituta de JMF, siendo compatible con el código
que usa JMF.
• Solucionar los problemas de JMF y añadir nuevas características, incluyendo:
o Soporte para codecs modernos.
o Encapsular varias librerías multimedia nativas.
o Soporte dinámico para plugins, codecs y dispositivos de captura.
o Incluir un fichero de registro editable.
o Conseguir que el uso de la API no requiera instalar ningún componente
adicional al entorno de ejecución de Java.
El proyecto se encuentra en sus primeras etapas de desarrollo, y su estado es
todavía bastante precario. El desarrollo es llevado a cabo por personas que deciden
dedicar parte de su tiempo al proyecto, y se basa en hacer pruebas del tipo caja negra 7
sobre la API de JMF y estudiar su especificación. No se usa ninguna información sobre
el código fuente, ya que esto podría acarrear la aparición de problemas legales.
De hecho, el desarrollo es tan precario que todavía no soporta transferencia por
RTP. Esta circunstancia lo elimina como opción para ser usado en el servidor RTSP que
se va implementar, pero se ha mencionado esta tecnología porque puede ser de notoria
importancia en el futuro y conviene tenerla en cuenta.
7 Este tipo de test se caracteriza por analizar la salida que cierto módulo software produce, en función de
los parámetros de entrada. No se analiza ni se tiene en cuenta la implementación interna de dicho módulo,
solo se obtiene información sobre su comportamiento desde el exterior.

Teniendo en cuenta estas circunstancias se ha elegido JMF como API que se
utilizará para la creación de sesiones RTP. Cuando se explique en profundidad la
implementación del servidor, se mostrará el uso concreto que se ha hecho de las
capacidades que ofrece la API.
3.3.2.3. VLC Media Player
VLC Media Player (inicialmente VideoLan Client, VLC a partir de ahora) es un
reproductor y servidor multimedia, distribuido como software libre. Soporta muchos
formatos de audio y vídeo, y también los formatos de DVD y VCD 8 . Además puede
funcionar como servidor de streaming, usando varios de los protocolos existentes en la
actualidad.
Siempre que se habla de software libre merece la pena hacer al menos un breve
repaso de la historia y evolución del producto. Inicialmente el objetivo del proyecto
VLC era crear un servidor capaz de enviar un flujo de streaming a través de la red. Fue
inicialmente desarrollado por estudiantes de la École Centrale Paris, y liberado bajo
licencia GPL 9 el 1 de febrero de 2001. Debido a su éxito y popularización, actualmente
desarrolladores de todo el mundo contribuyen a su evolución. En las primeras etapas el
proyecto constaba de dos módulos bien diferenciados, un reproductor multimedia
(VideoLan Client) y un servidor de streaming (VideoLan Server). Finalmente el
segundo ha quedado obsoleto y toda la funcionalidad se ha unido en un solo producto,
con la denominación VLC Media Player. Sus principales características son:
• Diseño muy modular: además del uso de los módulos existentes facilita la
incorporación de nuevos módulos para soportar más tipos de formatos, codecs o
métodos de streaming. Ofrece la posibilidad de elegir múltiples opciones para la
interfaz, así como entradas y salidas de audio y vídeo, filtros para conseguir
varios efectos, etc. Actualmente hay disponibles más de trescientos módulos
para VLC.
8 VCD o Video CD es un formato estándar para el almacenamiento de vídeo en un disco compacto. Se
pueden reproducir en ordenadores personales y en muchos reproductores de DVD, además de
reproductores VCD específicos.
9 La GPL (General Public License) es una licencia orientada a proteger la libre distribución, modificación
y uso del software, protegiéndolo además de intentos de apropiación que restrinjan estas libertades a los
usuarios. Existen algunas variantes de la licencia.

• Disponible para múltiples plataformas: contando con versiones para
Windows, Linux, Mac OS X, BeOS, BSD, Pocket PC y Solaris. Incluso existe
una versión portátil que puede ser almacenada y usada directamente desde una
memoria USB sin necesidad de instalación alguna.
• Utiliza la biblioteca libre libavcodec del proyecto FFmpeg 10 para manejar los
muchos formatos que soporta, y emplea la biblioteca de descifrado DVD
libdvdcss para poder reproducir los DVDs cifrados. Además soporta otros
codecs no incluidos en el proyecto FFmpeg.
• Dispone de plugins para la Web: en Windows, Linux, y algunas otras
plataformas, VLC incluye un plugin Mozilla, que permite ver algunos archivos
QuickTime y Windows Media en las páginas Web sin tener que utilizar un
reproductor de Microsoft o Apple. Desde la versión 0.8.2 en adelante, VLC
incorpora un plugin ActiveX, que permite ver algunos archivos QuickTime y
Windows Media en las propias webs, cuando se navega con Internet Explorer.
• Robustez: VLC es especialmente popular por su robustez, ya que es capaz de
reproducir archivos incompletos o dañados antes de que se hayan descargado
completamente, por ejemplo a través de programas de intercambio habituales
como Emule o BitTorrent. Esto es debido a que es un reproductor basado en
paquetes.
• Capaz de acceder a archivos de imagen .iso y reproducir los archivos
multimedia contenidos en su interior, incluso si el sistema operativo no es capaz
de trabajar directamente con archivos .iso.
• Dispone de filtros: usando filtros se pueden obtener multitud de efectos, como
distorsionar la imagen, separarla en fragmentos, rotarla, añadir logos, etc.
• Tiene otras funcionalidades peculiares que le pueden hacer atractivo para
muchos usuarios, como por ejemplo reproducir vídeo como si fuera el fondo de
pantalla, reproducción en directo usando una conexión FireWire, etc.
De cara a este proyecto, las capacidades más relevantes que nos pueda ofrecer VLC
son las relacionadas con el streaming, y la posibilidad de integrarlo con el servidor
RTSP que se va a desarrollar. En lo referente al primer punto, estudiando la
10 FFmpeg es una colección de software libre que puede realizar tareas de grabación, transcoding y
streaming sobre contenidos de audio y vídeo. Incluye libavcodec, una librería de códecs. FFmpeg puede
ser utilizada en varios sistemas operativos, incluyendo Linux y Windows.

documentación se ha comprobado que dispone de un módulo específico que permite la
creación de flujos de streaming sobre RTP. En cuanto a lo segundo, VLC ofrece la
posibilidad del manejo a través de línea de comandos como alternativa a la interfaz
gráfica, incluyendo el uso de dicho módulo. Esto es fundamental, puesto que si sólo se
ofreciera la interfaz gráfica no sería posible el uso de VLC desde una aplicación en
Java. VLC ofrece una multitud de opciones y parámetros para lanzarlo a través de una
terminal, usando sus capacidades tanto de reproducción como de servicio streaming.
Atendiendo a estas razones también se ha elegido VLC para la implementación
de uno de los módulos del servidor que se encargará de las sesiones RTP. Se ha elegido
además como contraposición a JMF, de forma que existirá un módulo creado usando
una API de programación y otro módulo equivalente basado en una herramienta de
streaming disponible, enriqueciendo la implementación del servidor al abarcar éste más
tecnologías diferentes.
3.3.2.4. Gstreamer
GStreamer es un framework multimedia libre y multiplataforma, escrito en el
Lenguaje de programación C, usando la librería GObject 11 . GStreamer permite crear
aplicaciones multimedia que usen vídeo, sonido, tareas de transcoding, etc. Esto incluye
realizar tareas cotidianas como reproducir música o tareas más complejas como mezclar
audio y vídeo. GStreamer proporciona un framework para plugins, flujo de datos y
manejo/negociación de distintos tipos de medios. También provee una API para escribir
aplicaciones.
El proyecto fue fundado el año 1999 por Erik Walthinsen, tomando algunas ideas
de un proyecto de investigación desarrollado en la Universidad de Oregon. Inicialmente
fue adoptado por el proyecto GNOME a partir de su versión 2.2, luego prosiguió su
evolución y cada vez más aplicaciones lo utilizan, contribuyendo desarrolladores de
todo el mundo a su progreso.
11 GObject (GLib Object System) es una librería de software libre que proporciona un sistema de objetos
portable y que combina además interoperabilidad entre varios lenguajes de forma transparente. Está
diseñada para ser usada directamente sobre C o indirectamente sobre otros lenguajes, mediante el uso de
determinadas librerías intermedias.

Sus principales características son las siguientes:
• Multiplataforma: está disponible para varios sistemas operativos (Linux,
MacOS, Windows y Solaris).
• basado en plugins: Gstreamer tiene una arquitectura basada en plugins, lo que
provoca que la mayoría de la funcionalidad esté implementada en forma de
librerías compartidas. El núcleo básico contiene funciones para cargar y registrar
dinámicamente los plugins, que permiten el uso de un amplio abanico de
formatos y contenedores, así como drivers de entrada y salida.
• Diseño orientado a objetos.
• Librería del núcleo muy ligera, menos de 150 Kb.
• Soporte para ejecución multihilo, de forma transparente al desarrollador.
• API simple, para el desarrollo de aplicaciones y plugins.
• Transferencia de datos extremadamente ligera, reduciendo así la latencia y
aumentando el rendimiento.
• Completo sistema de depuración.
Gstreamer se puede comparar con VLC atendiendo a dos aspectos: En primer
lugar también hace uso de las librerías que ofrece el proyecto FFmpeg. Por otra parte,
también admite el control a través de la línea de comandos.
Al haber sido ya elegidos JMF y VLC para implementar los módulos RTP, no se
va a hacer uso de Gstreamer por considerar que no aporta contenido sustancialmente
diferente al proyecto, pero sería posible usarlo para implementar un módulo adicional.
3.3.2.5. IBM Toolkit for MPEG-4
Es un conjunto de clases y APIs Java, que permiten la creación de aplicaciones
multimedia capaces de manejar contenido MPEG-4 12 , incluyendo tareas de streaming.
12 MPEG-4 es un conjunto de estándares para la codificación de audio y vídeo, así como las tecnologías
relacionadas. Esto incluye, entre otros, el contenedor MPEG-4 (archivos con extensión .mp4), que como
se llama igual puede dar lugar a confusión.

Es una librería propietaria, pero existe una versión de prueba que permite probar sus
características durante noventa días.
Se ofrece con cinco aplicaciones de ejemplo, tres dedicadas a reproducción y dos
orientadas a la creación de contenido multimedia. Son las siguientes:
• AvGen: herramienta con interfaz gráfica que permite la creación de contenidos
multimedia (audio o vídeo pero no ambos simultáneamente), así como
transmitirlos a través de los protocolos RTSP/RTP para su recepción por
dispositivos que cumplan los estándares 3GPP o ISMA 13
• XMTBatch: esta herramienta permite la creación de contenidos multimedia
MPEG-4 más complejos, que no se limitan simplemente a audio y video. Esto
incluye interacción con el usuario y tareas de transcoding desde varios formatos
a MPEG-4.
• M4Play: aplicación que reproduce contenidos MPEG-4.
• M4Applet for ISMA: reproduce contenido que cumple el estándar ISMA, y que
le llega a través de RTSP/RTP.
• M4Applet for HTTP: applet 14 que reproduce contenido MPEG-4 obtenido a
través de HTTP.
Aunque es una tecnología con bastantes posibilidades, no se ha contemplado su
uso por no ser software libre.
13 ISMA (Internet Streaming Media Alliance) es una organización sin ánimo de lucro cuya misión es
facilitar la implantación en el mercado de estándares abiertos para la transmisión de multimedia sobre
diferentes protocolos de Internet.
14 Un applet es un componente software que se ejecuta en el contexto de otro programa, generalmente un
navegador web.

3.4. Entorno y herramientas
3.4.1. Sistema operativo Windows XP
El sistema operativo en el que el servidor deberá funcionar es Windows. Más
concretamente, el desarrollo se ha hecho sobre Windows XP. La elección de un sistema
operativo en concreto para una aplicación programada en un lenguaje multiplataforma
como Java puede resultar contradictoria en un principio, pero existe fundamentalmente
una circunstancia que ha obligado a tomar esta decisión. La forma de lanzar procesos en
Windows XP es diferente a Linux, por tanto, para lanzar la aplicación VLC es necesario
decantarse por un mecanismo concreto.
No obstante, debido a que los elementos utilizados son multiplataforma (Java,
JMF y VLC) se podría adaptar fácilmente la aplicación a Linux y Solaris.
3.4.2. Entorno de desarrollo Eclipse
El entorno de desarrollo elegido para las tareas de programación ha sido Eclipse.
Eclipse es una plataforma de software de Código abierto independiente de una
plataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente
Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores.
Se ha elegido este entorno de desarrollo por las facilidades específicas que
ofrece para la programación en Java, como por ejemplo la detección automática de
errores, el resaltado de elementos del lenguaje (palabras reservadas, variables), etc.
Estas características facilitan el desarrollo y posterior comprensión del código escrito.

3.4.3. Wireshark
Una necesidad básica para poder realizar pruebas era poder capturar el tráfico
que se estaba intercambiando a través de la red entre los diferentes elementos. La
herramienta elegida ha sido Wireshark, anteriormente conocida como Ethereal.
Wireshark es una herramienta utilizada para realizar análisis y solucionar problemas en
redes de comunicaciones para desarrollo de software y protocolos, y también se usa
como una herramienta didáctica para educación. Cuenta con todas las características
estándar de un analizador de protocolos.
Incorpora una interfaz gráfica y muchas opciones de organización y filtrado de
información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente
una red Ethernet, aunque es compatible con algunas otras) estableciendo la
configuración en modo promiscuo. También incluye una versión basada en texto
llamada Tshark. Permite examinar datos de una red viva o de un archivo de captura
salvado en disco. Se puede analizar la información capturada, a través de los detalles y
sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que
se desea ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP, esta
característica lo hace especialmente útil para examinar los mensajes intercambiados a lo
largo de una sesión RTSP.
Wireshark es software libre, y se ejecuta sobre la mayoría de sistemas operativos
Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD, OpenBSD, y Mac
OS X, así como en Windows. Esta herramienta se usado para dos tareas concretas:
• Examinar el intercambio de mensajes RTSP. Esto incluye tanto el análisis de los
mensajes enviados por servidores y clientes ya existentes para averiguar el uso
real que hacen del protocolo, como la confirmación de que el servidor
implementado envía los mensajes correctamente.
• Comprobar que los flujos de streaming a través de RTP se están creando
correctamente, corroborando que los paquetes UDP están llegando a la dirección
IP y puertos correspondientes.

3.4.4. JavaCC
Como se ha mencionado se va a usar el protocolo RTSP para el control del
streaming, y este es un protocolo de carácter textual. Será por lo tanto necesario que el
servidor sea capaz de interpretar correctamente los mensajes RTSP enviados por los
clientes, identificando el tipo de mensajes y los diferentes campos de información
contenidos en ellos. De ahí nace la necesidad de implementar algún tipo de analizador
de lenguajes que pueda acometer estas tareas. Para ello se ha usado Java Compiler
Compiler (JavaCC), un generador de analizadores sintácticos escrito en Java y que
genera código en Java.
Entrando ya en el campo de los lenguajes, cabe señalar que un analizador
sintáctico lleva asociado un analizador léxico. El analizador léxico es capaz de
reconocer los tokens o elementos unitarios del lenguaje, mientras que posteriormente el
analizador sintáctico analiza la forma en que estos elementos se combinan entre si.
Finalmente el analizador será capaz de determinar si una determinada entrada pertenece
o no al lenguaje especificado. En el caso del protocolo RTSP, los tokens serán las
diferentes cadenas de texto incluidas dentro de los mensajes, y el analizador sintáctico
comprobará que dichas cadenas se combinan para crear un mensaje RTSP correcto.
JavaCC funciona de esta manera: siguiendo unas determinadas reglas de
sintaxis, se puede escribir un fichero que describa la gramática de un cierto lenguaje, en
este caso el lenguaje será el formado por los diferentes mensajes RTSP que se pretenden
reconocer. Después usando un compilador de JavaCC, obtendremos un código en Java
capaz de recibir una cadena de entrada y decidir si dicha cadena cumple o no la
especificación del lenguaje. Además se puede añadir código java combinado con el
análisis, de forma que se realice cualquier acción que programemos al detectar cada
elemento.

3.4.5. Reproductores multimedia
Se ha señalado que el servidor RTSP deberá ser compatible con los
reproductores VLC y QuickTime. Evidentemente, una característica común a ambos es
que son capaces de establecer sesiones RTSP y recibir contenido a través de la red por
RTP. Sin embargo, existen ligeras diferencias en cuanto a la implementación del
protocolo RTSP, que se irán señalando en su momento. Además se pretendió incluir el
reproductor Windows Media Player, de cierta importancia debido a su popularidad entre
muchos usuarios. Sin embargo esta opción se acabó desestimando, debido a problemas
que se expondrán más adelante.
3.4.5.1. Reproductor VLC
Además de sus capacidades de generar streaming, VLC resulta ser un potente
reproductor multimedia. Potente por la variedad de formatos y medios de entrada que
soporta, y por su robustez a la hora de reproducir contenido dañado o incompleto.
Además también soporta la reproducción de archivos de subtítulos y efectos de vídeo
añadidos. La versión que se ha usado es la 0.8.6a.
Los medios de entrada que se pueden abrir incluyen ficheros almacenados en
local, discos DVD, VCD o de música, aparatos externos de captura o flujo de streaming
proveniente de la red. En cuanto a esto último puede establecer sesiones RTSP, o
directamente leer el contenido RTP que llega a un puerto en concreto. También puede
usar los protocolos HTTP, HTTPS, FTP y MMS.
Incluye una barra de desplazamiento para controlar la reproducción, en el
contexto de una sesión RTSP el uso de esta barra provoca el envío de mensajes al
servidor. Se tratará de atender a estas demandas. En la figura 3.2 se muestra una captura
de la interfaz del reproductor VLC.

Figura 3.2: interfaz del reproductor VLC
El reproductor se puede manejar a través de la línea de comandos, remotamente
mediante una conexión Telnet o usando la interfaz de usuario. Es esta última posibilidad
la que se va a usar para hacer las pruebas, por resultar más inmediata y más habitual
desde el punto de vista de los usuarios.
3.4.5.2. Reproductor QuickTime Player
El reproductor QuickTime Player forma parte de QuickTime, que es la
arquitectura multimedia estándar desarrollada por Apple, formada por un conjunto de
bibliotecas y el propio reproductor. Se ha usado la versión básica 7.1.6, existe una
versión “Pro” no gratuita que añade diversas funcionalidades como la edición de vídeo
y codificación a variados formatos como AVI, MOV, MP4. Con la versión Pro, también
es posible grabar audio con un micrófono conectado al ordenador.
QuickTime permite la reproducción de archivos en local y también contenido a
través de la red, incluyendo el protocolo RTSP. Además también puede reproducir
contenidos empotrado en los navegadores Web. Actualmente se encuentra disponible
para los sistemas operativos Windows y Mac Os X. Se puede observar la interfaz de
QuickTime en la figura 3.3.

Figura 3.3: interfaz del reproductor QuickTime
El efecto del uso de la barra de desplazamiento durante las sesiones RTSP tiene
un efecto similar que en el caso de VLC. A diferencia de VLC, sin embargo, no soporta
la reproducción a través de RTP directamente, si no que obligatoriamente debe
producirse en el contexto de una sesión RTSP iniciada desde el reproductor.
Cabe señalar que existe un contenedor multimedia llamado QuickTime
(extensión de archivo “.mov”) capaz de almacenar pistas de audio, vídeo, efectos y
texto. Posibilita además tareas de edición.

3.5. Diseño e Implementación
En este capítulo se aborda el diseño y la implementación del servidor RTSP. Se
ofrecerá primeramente una visión global de la arquitectura, con los elementos
fundamentales que componen el servidor. Se explicará el modelo de desarrollo que ha
servido como guía.
Posteriormente se detallará cómo se ha implementado la funcionalidad RTSP,
incluyendo además información general sobre el protocolo y qué partes de este se han
incluido o no. El resto de elementos a explicar serán el mantenimiento del estado de las
sesiones en el servidor y finalmente la implementación de los diferentes módulos
SdpGenerator y RtpSender usando las tecnologías sobre las que ya se ha hablado en
los primeros capítulos.
3.5.1. Arquitectura del sistema
Una vez elegidas las tecnologías y protocolos que se van a utilizar, hay que
diseñar la arquitectura del servidor. Tal y como se especificó en los objetivos, el
servidor debe ser capaz de contestar las peticiones RTSP de los clientes, obtener los
SDP asociados a un contenido multimedia y crear sesiones RTP para el envío de los
datos. Las dos últimas tareas podrán ser llevadas a cabo por módulos diferentes que
emplearán diferentes tecnologías, y el servidor se podrá configurar en el momento del
arranque. Se ha definido una interfaz java (especificación de los métodos que una clase
debe implementar) para los módulos encargados de obtener los SDP (SdpGenerator) y
los que crearán las sesiones RTP (RtpSender):
• La interfaz SdpGenerator define un solo método, getSdpContent, que devuelve
un SDP recibiendo como parámetro el nombre del contenido multimedia
correspondiente. Lanza una excepción si no se encuentra.
• Por su parte la interfaz RtpSender define tres métodos:

o startTransmission, comienza en envío de información por RTP y
recibe como parámetro el instante inicial expresado en segundos.
o pauseTransmission, detiene la transmisión.
o tearDownTransmission, libera los recursos asociados a la sesión RTP.
Por lo tanto el esquema a alto nivel del servidor y su relación con el cliente es el
representado en la figura 3.4.
Figura 3.4: arquitectura del sistema
Tras analizar las capacidades ofrecidas por las diferentes tecnologías estudiadas,
se ha determinado que se implementarán dos versiones del módulo SdpGenerator otras
dos del RtpSender. El servidor será configurable, de forma que al arrancar se podrá
elegir cuales de estos módulos usar. Por lo tanto, el servidor se podrá arrancar con
cuatro configuraciones diferentes posibles. Se usarán las siguientes tecnologías en la
implementación de los módulos:
• SdpGenerator: habrá una versión básica que se limitará a leer los SDPs de un
fichero de texto, es decir, los SDPs habrán sido obtenidos previamente de otra
forma ajena al servidor (FileSdpGenerator). Otra versión usará VLC para
obtener el SDP asociado a los archivos guardados en disco, aprovechando la
posibilidad de usar esta herramienta como servidor RTSP (VlcSdpGenerator).
• RtpSender: Una versión usará JMF aprovechando las capacidades que ofrece su
API para generar flujos RTP (JmfRtpSender). Una segunda implementación se

servirá de VLC y su posibilidad de ser lanzado mediante línea de comandos,
generando también un flujo RTP (VlcRtpSender).
Para terminar con la visión general de la arquitectura del servidor, hay que
señalar cómo se ha abordado el objetivo referente a la escalabilidad en cuanto al soporte
simultáneo a varios clientes. El servidor esperará peticiones en un determinado puerto, y
para cada conexión abrirá un hilo de ejecución que atenderá las peticiones. Más
concretamente, la clase que esperará las conexiones y sirve para lanzar el servidor es
RtspServer, y cada vez que reciba una nueva conexión se lanzará una instancia de la
clase RequestHandler que interactuará con el cliente. Habrá un único SdpGenerator,
pero como es lógico se podrá instanciar un RtpSender para cada cliente, posibilitando
así el envío simultáneo de datos a todos ellos. Además mantendrá una estructura de
datos que guardará el estado de cada sesión RTSP, llamada RtspSessionData (una
instancia para cada sesión). Es importante tener en cuenta que el número de sesiones no
es igual al número de conexiones con los clientes, ya que al tratarse de un servidor con
estado, durante una única sesión RTSP se podrán producir varias conexiones y
desconexiones a nivel de transporte.
3.5.1.1. Diagrama de clases Java
Se muestra el diagrama de clases Java en la figura 3.5, con todas las clases e
interfaces que constituyen el servidor RTSP salvo algunas clases auxiliares del
analizador sintáctico creado con JavaCC, cuya clase principal es RtspRequestParser.
Estas clases auxiliares se omiten para facilitar la comprensión global de la estructura de
clases, baste decir que RtspRequestParser las usa para el análisis. También se omiten
algunos atributos y métodos, mostrando solo los más relevantes para comprender el
funcionamiento.
A medida que se vaya explicando el funcionamiento interno del servidor se irán
mencionando todos estos elementos y explicando su papel.

Figura 3.5: diagrama de clases java

3.5.2. Proceso de desarrollo
Como metodología para el desarrollo del proyecto se ha seguido el modelo de
ciclo de vida en espiral representado en la figura 3.6. Este modelo consta de iteraciones,
cada una de las cuales consta de ciertas etapas que culminarán en un prototipo más
avanzado. Estas etapas son el análisis de objetivos y requisitos para la iteración, diseño
e implementación, pruebas, y por último se planificará la siguiente fase en caso de que
se vaya a continuar con el desarrollo.
Figura 3.6: modelo de desarrollo en espiral
Considerando la evolución del servidor a lo largo de todo el desarrollo, podemos
enumerar algunos hitos o iteraciones claramente diferenciadas. Cada una de ellas ha
culminado con la obtención de un prototipo más avanzado que el anterior, en el cual se
ha añadido alguna funcionalidad o módulo concreto. Las iteraciones son las siguientes:

• Una primera versión del servidor con la capacidad de contestar a las peticiones
RTSP de los clientes. Es decir, esta versión no generaba ningún flujo de
streaming, y se ha utilizado un SDP insertado directamente en el código, que era
enviado a los reproductores en el mensaje oportuno. Esta versión se limitaba a ir
contestando a los sucesivos mensajes RTSP de los clientes, creando respuestas
válidas que los clientes aceptaban como correctas, dando paso así a las
peticiones subsiguientes. Finalmente se llegaba a un estado donde todos los
mensajes de inicialización se habían intercambiado correctamente, y el cliente se
quedaba a la espera de recibir el flujo de streaming por RTP. La tarea de análisis
en esta fase ha incluido tanto el estudio del protocolo RTSP a nivel teórico a
través de su RFC 2326 y otros documentos, como el estudio de sesiones RTSP
reales para comprobar el uso del protocolo que hacen los distintos reproductores
a la hora de solicitar un archivo.
• La segunda etapa de desarrollo consistió en la implementación del módulo
FileSdpGenerator, y su integración en el servidor de forma que se hacía uso de
él cuando el cliente solicitaba un SDP.
• La tercera versión del servidor consistió en la implementación del módulo
JmfRtpSender. Esto incluyó el estudio de la API, el desarrollo de una aplicación
aislada capaz de enviar un flujo RTP, y finalmente su integración en el servidor
para que iniciara el envío de los flujos RTP en el momento que el cliente lo
solicitara, y a la dirección y puertos indicados por este. Se puede decir que al
final de esta iteración ya se disponía de un servidor RTSP con funcionalidad
completa, capaz de atender las peticiones de los reproductores y enviarles los
datos de una forma completamente autónoma.
• El paso posterior consistió en la implementación del módulo VlcRtpSender.
Primero se estudió la documentación y se hicieron las pruebas pertinentes hasta
conseguir crear flujos de streaming lanzando VLC por línea de comandos, y
después se incluyó un módulo en el servidor que, al igual que en el caso de JMF,
era capaz de iniciar la transmisión en los términos adecuados.
• Llegados a este punto y aprovechando el conocimiento adquirido sobre el
manejo de VLC por línea de comandos, se creó el módulo VlcSdpGenerator.
Este módulo supone un salto de calidad bastante importante, porque con el
módulo FileSdpGenerator era necesario obtener de alguna manera un nuevo

SDP cada vez que se pretendía añadir un nuevo archivo a la lista de los
disponibles en el servidor (esta manera solía ser la adaptación de un SDP
perteneciente a otro archivo multimedia cuyas características eran similares, de
forma que la información contenida era igualmente válida). A partir de este
punto no hay que hacer nada para servir nuevos archivos, ya que este módulo se
encargará de obtener el SDP asociado a cada uno de ellos.
Una vez descritas las tecnologías y protocolos empleados, la arquitectura general
del servidor y el proceso que se ha seguido durante todo el desarrollo, de aquí en
adelante se va a explicar detalladamente el funcionamiento de cada uno de estos
elementos y qué soluciones de implementación se han adoptado.
3.5.3. Arranque del servidor
La clase principal que engloba al servidor RTSP es RtspServer. El constructor de
esta clase recibe como parámetros toda la información de configuración necesaria, a
saber:
• SdpGenerator: (FileSdpGenerator o VlcSdpGenerator)
• RtpSender: (JmfRtpSender o VlcRtpSender)
• Puerto en el que el servidor espera peticiones.
• Ruta al directorio donde se encuentran los archivos multimedia servidos.
• Ruta al directorio donde se encuentran los archivos SDP. En el caso de que se
use el módulo VlcSdpGenerator, el directorio deberá ser el mismo en el que se
encuentran los archivos, ya que los SDP se obtienen directamente de estos.
Además el propio constructor creará el objeto SdpGenerator correspondiente, y
esta instancia será la única de dicho tipo que haya en el servidor, al contrario de los
objetos RTPSender, de los cuales se podrán crear múltiples instancias dependiendo de
las sesiones de streaming que se mantengan simultáneamente.

Una vez creado el servidor se arrancará llamando a su método start(). Esto
hará que el servidor empiece a esperar conexiones en el puerto correspondiente. Por
cada nueva conexión se creará una instancia de la clase RequestHandler. Esta clase
crea un hilo de ejecución consistente en un bucle que atiende a las los mensajes RTSP
de los clientes, realizando las acciones necesarias dependiendo del tipo de mensaje y
enviando las respuestas correspondientes.

3.5.4. Implementación del protocolo RTSP
La especificación del protocolo RTSP es bastante amplia, y viene descrita
exhaustivamente en la RFC 2326, documento que consta de 96 páginas. Dicho
documento abarca más aspectos de los que se van a tener en cuenta en este servidor, y
no tiene sentido describir todos y cada uno de ellos en el presente documento. Las
características generales del protocolo fueron descritas en el capítulo 3.3.1.1., y a partir
de ahora la explicación se va a centrar en los aspectos relevantes para este caso.
Conviene recordar que se trata de un protocolo textual similar a HTTP, en el cual el
servidor mantiene información de estado y las sesiones tienen una estructura secuencial
de petición-respuesta. Sirve para controlar la transferencia de streaming, incluyendo la
inicialización, modificación y finalización de la sesión.
Primeramente se van a describir las peticiones y respuestas RTSP. Después se
explicará el proceso de arranque del servidor y cómo comienza a responder a las
peticiones RTSP de un reproductor que pretende reproducir un archivo multimedia
almacenado en el servidor. Se detallarán dichas peticiones, mostrando capturas de las
mismas y explicando simultáneamente los aspectos del protocolo que se están
utilizando. Además se señalarán las diferencias en el uso del servidor que se han
encontrado entre los reproductores VLC y QuickTime.
3.5.4.1. Petición RTSP
Una petición RTSP está formada por los siguientes elementos, siendo todos ellos
cadenas de caracteres:
• Línea de petición: incluye el tipo de petición, el recurso multimedia al que hace
referencia (habitualmente una URL) y la versión del protocolo. En lugar de la
URL también se puede usar un asterisco, en este caso la petición no hace
referencia a ningún recurso multimedia en particular si no a alguna cuestión
referente al servidor.

• Una o varias líneas de cabecera, algunas serán obligatorias para cada tipo de
mensaje, mientras que muchas serán opcionales.
• Una línea en blanco
• Opcionalmente, un cuerpo del mensaje formado por varias líneas. Por lo general
Ejemplo:
las peticiones carecen de cuerpo.
DESCRIBE rtsp://193.147.59.231:10000/video.mp4 RTSP/1.0
CSeq: 1
Accept: application/sdp
Bandwidth: 384000
Accept-Language: en-US
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
3.5.4.2. Respuesta RTSP
Análogamente una respuesta RTSP está formada por los siguientes elementos,
nótese la similitud con las respuestas HTTP:
• Línea de estado (protocolo, código de estado y frase de estado).
• Una o varias líneas de cabecera.
• Una línea en blanco.
• Cuerpo del mensaje.
Ejemplo:
RTSP/1.0 200 OK
Content-type: application/sdp
Server: VLC Server
Cseq: 1
Cache-Control: no-cache

Las similitudes con el protocolo HTTP son más que evidentes. Obsérvese por
ejemplo la línea de estado en la respuesta o el uso de la cabecera Content-type,
idénticas en ambos protocolos. Cada línea termina además con un retorno de carro.
Una característica importante es que cada petición debe incluir una cabecera con
un número de secuencia, identificada como CSeq. La respuesta a la petición deberá
incluir el mismo número de secuencia y de esta forma la respuesta será asociada
correctamente a la petición a la que corresponde. Esto es importante puesto que aunque
normalmente se use TCP como protocolo de transporte (protocolo fiable que entrega los
mensajes de forma ordenada), pueden establecerse varias conexiones diferentes.
Además, aunque es lo habitual, el uso de TCP no es obligatorio.
3.5.4.3. Funcionamiento del protocolo RTSP
Se ha realizado un estudio del protocolo con el objetivo de determinar qué
mensajes mínimos son necesarios para conseguir la reproducción en un cliente de un
recurso multimedia almacenado en un servidor. Como complemento se han analizado
las trazas de sesiones RTSP reales, conectándose con los reproductores QuickTime y
VLC a servidores RTSP alojados en Internet y extrayendo los mensajes intercambiados
con la herramienta Wireshark, resultando ser este análisis el más útil. Con esta
información se ha programado el servidor para que conteste a los clientes de la forma
adecuada.
En primer lugar se van a mostrar los mensajes básicos necesarios para la
visualización de un archivo multimedia en el cliente. Después se va a hablar de otros
mensajes que añaden alguna otra característica al servidor y que se ha optado por incluir
en la implementación. Finalmente se mencionan el resto de mensajes RTSP que no se
han implementado, para ofrecer de esta forma una visión completa del protocolo. Una
vez descrito el protocolo se comentarán algunas cuestiones sobre su implementación.
Las siguientes trazas corresponden a peticiones enviadas por el reproductor
QuickTime y las respuestas correspondientes enviadas por nuestro servidor RTSP.

3.5.4.3.1. Mensajes básicos para la reproducción de un archivo
El conjunto de mensajes mínimos es el siguiente, y generalmente deberán
enviarse en el orden establecido aunque algunos se pueden repetir para modificar algún
parámetro.
• DESCRIBE: la petición DESCRIBE solicita la descripción de un recurso
multimedia almacenado en el servidor, identificado por una URL. Puede incluir
la cabecera Accept para especificar los formatos de descripción que el cliente es
capaz de entender. El servidor deberá responder con un mensaje que incluirá en
el cuerpo la descripción solicitada. En caso de que el recurso solicitado no
exista, el servidor deberá responder con el mensaje destinado a tal efecto, cuya
línea de estado es RTSP/1.0 404 Not Found. La petición Describe y su
respuesta constituyen la inicialización de la sesión RTSP.
En el siguiente ejemplo se envía una petición DESCRIBE sobre un
archivo multimedia llamado “video.mpg”. Obsérvese la cabecera Accept en la
que se indica que el cliente acepta descripciones en formato SDP.
DESCRIBE rtsp://192.168.1.2:20000/video.mpg RTSP/1.0
CSeq: 1
Accept: application/sdp
Bandwidth: 384000
Accept-Language: en-US
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
La respuesta contiene el SDP solicitado, se puede ver que el recurso
contiene una pista de audio y otra de vídeo.

RTSP/1.0 200 OK
Content-type: application/sdp
Content-Length: 304
Cseq: 1
v=0
o=- 20070859581 3 IN IP4 127.0.0.1
c=IN IP4 0.0.0.0
t=0 0
a=tool:vlc 0.8.6a
a=range:npt=0-151.700
m=video 0 RTP/AVP 32
a=rtpmap:32 MPV/90000
a=control:rtsp://192.168.1.2:20000/video.mpg/trackID=0
m=audio 0 RTP/AVP 14
a=rtpmap:14 MPA/90000
a=control:rtsp://192.168.1.2:20000/video.mpg/trackID=1
• SETUP: Mediante la petición SETUP el cliente indica al servidor los parámetros
de transporte que deberá usar para la transmisión de un determinado flujo de
streaming, identificado mediante una URL que habrá sido obtenida de la
descripción del recurso multimedia. Deberá incluir obligatoriamente la cabecera
Transport, en la que se especifican estos parámetros. Por ejemplo se indicará el
protocolo que se va a usar para enviar los datos (RTP en nuestro caso), la IP de
destino (si no se especifica se deberá usar la misma que la del cliente), así como
los puertos en los que el cliente va a esperar los datos.
La petición SETUP es la primera que cambia el estado del servidor,
haciendo que este reserve los recursos necesarios para la posterior transmisión.
Además después de recibir la primera petición SETUP el servidor deberá generar
un identificador de sesión, que generalmente será un número aleatorio. Este
identificador irá incluido en la respuesta, así como en todas las demás peticiones
y respuestas que se produzcan posteriormente dentro de la misma sesión RTSP.
Por otra parte hay que señalar que cuando un recurso multimedia consta
de varias pistas (por ejemplo audio y vídeo), el envío de los datos puede
realizarse dentro de la misma transmisión RTP (entrelazado) o en transmisiones
diferentes. En el caso de nuestro servidor, el SDP que se envía al cliente le indica
que debe solicitar una sesión RTP diferente para cada pista, puesto que cada una

de ellas viene identificada con una URL diferente. Por lo tanto si un cliente
desea reproducir el audio y el vídeo de un recurso multimedia, deberá hacer dos
peticiones SETUP, especificando en cada una de ellas la pista a la que se hace
referencia a través de la URL, y los puertos RTP/RTCP en los que se esperan los
datos.
La respuesta al mensaje SETUP deberá confirmar la configuración de
transporte pretendida por el cliente, o bien indicar una configuración alternativa
si el servidor no puede satisfacer las demandas del reproductor. Opcionalmente
también puede contener algunos parámetros de transporte relativos al servidor,
por ejemplo los puertos origen de cada flujo RTP. Como conclusión, tras los
mensajes SETUP el servidor sabe que pistas desea el cliente, el protocolo de
streaming que debe utilizar, y cuales son la IP y puertos de destino.
En el siguiente ejemplo se envía una petición SETUP sobre una de las
pistas descritas en el SDP del ejemplo anterior, obsérvese que la URL
corresponde a la pista de video. Si se quisiera activar también la pista de audio
habría que enviar un segundo mensaje SETUP haciendo referencia a la URL
correspondiente. Se puede ver además en la cabecera Transport que el cliente
espera un flujo de datos a través de RTP, y que los puertos RTP/RTCP en que
esperará los datos son 6970 y 6971 respectivamente.
SETUP rtsp://192.168.1.2:20000/video.mpg/trackID=0 RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=6970-6971
x-retransmit: our-retransmit
x-dynamic-rate: 1
x-transport-options: late-tolerance=2.900000
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
Accept-Language: en-US
Como se puede observar la cabecera Transport de la respuesta confirma
los parámetros de transporte que el cliente había especificado. Además se
incluye la cabecera Session con el número aleatorio que el servidor ha
generado, y que se deberá incluir en el resto de peticiones y respuestas.

RTSP/1.0 200 OK
Cseq: 2
Transport: RTP/AVP;unicast;client_port=6970-6971
Session: 902818185
Hay que hacer notar que aunque las URL de las peticiones SETUP tienen
aspecto de dirección de red y puerto, en realidad no tienen ninguna relación con
el protocolo de transporte. El servidor las trata simplemente como cadenas de
texto, y se limita a compararlas con las URL que venían especificadas en el SDP
para comprobar a qué pista hacen referencia.
• PLAY: con la petición PLAY el cliente solicita al servidor el envío de los datos,
usando como parámetros de transporte los indicados en las peticiones SETUP
previas. El cliente no debe enviar el mensaje PLAY antes de haber enviado todos
los mensajes SETUP necesarios y haber recibido las respuestas
correspondientes.
El mensaje debe contar obligatoriamente con la cabecera Range, que
especifica el rango de tiempo que desea ser reproducido. Por ejemplo, puede
solicitarse el envío de un determinado intervalo delimitado por su instante inicial
e instante final, o bien reproducción indefinida a partir de un momento dado.
Estas marcas de tiempo pueden encontrarse en diferentes formatos, en este caso
tanto VLC como QuickTime usan el formato npt, en el cual el tiempo se expresa
en segundos.
Opcionalmente la cabecera Range puede incluir el campo Time, que
incluye el momento en que la reproducción debe comenzar en formato UTC 15 . Si
no se indica este campo la reproducción debe comenzar inmediatamente. Los
clientes VLC y QuickTime no incluyen el campo Time, sin embargo el servidor
está preparado para reconocerlo. Es interesante el hecho de que los dos
reproductores difieren en el uso del protocolo, aunque en este caso sea una
diferencia que no afecta al funcionamiento: VLC no especifica el instante final
15 UTC es el tiempo universal coordinado. Es la zona horaria de referencia respecto a la cual se calculan
todas las otras zonas del mundo

de la reproducción, mientras que QuickTime sí (el instante final es la duración
del archivo).
En este ejemplo se puede observar el uso de la cabecera Range, y cómo el
instante final corresponde al tamaño del archivo que se había indicado en el SDP
(ver ejemplo de la petición DESCRIBE). En el caso del VLC el formato de la
cabecera Range sería simplemente: Range: npt=0.000-
PLAY rtsp://192.168.1.2:20000/video.mpg RTSP/1.0
CSeq: 3
Range: npt=0.000000-151.700000
x-prebuffer: maxtime=2.000000
Session: 902818185
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
RTSP/1.0 200 OK
Cseq: 4
Session: 902818185
• TEARDOWN: este mensaje se usa para detener la transmisión. Además el
servidor debe liberar todos los recursos y la información de estado asociados con
la sesión RTSP. De hecho, si tras un mensaje TEARDOWN el cliente desea
volver a recibir el mismo contenido, deberá volver a enviar los mensajes SETUP
adecuados antes de poder usar el mensaje PLAY.
TEARDOWN rtsp://192.168.1.2:20000/video.mpg RTSP/1.0
CSeq: 4
Session: 902818185
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
Como se puede apreciar la respuesta al mensaje TEARDOWN ya no
contiene un número de sesión, denotando de esta manera que la sesión RTSP ha
terminado.

RTSP/1.0 200 OK
Cseq: 4
3.5.4.3.2. Otros mensajes implementados
Ahora se enumeran otros mensajes que se han implementado en el servidor y
que añaden alguna característica adicional.
• PAUSE: este mensaje no es estrictamente necesario para la transmisión pero
también se ha implementado en el servidor, para añadir funcionalidad en el
cliente y por resultar su implementación posible. Evidentemente, sirve para
detener temporalmente el envío de información. Para reanudarla posteriormente
no habrá que enviar un nuevo mensaje PAUSE, si no PLAY. Hay que tener en
cuenta que en el caso de transmisión en vivo, pausarla significa perder parte del
contenido. En el caso de nuestro servidor simplemente se detiene el envío de los
datos RTP.
PAUSE rtsp://192.168.1.2:20000/video.mpg RTSP/1.0
CSeq: 10
Session: 902818185
User-Agent: QuickTime E-/7.1.6 (qtver=7.1.6;os=Windows NT
5.1Service Pack 2)
RTSP/1.0 200 OK
Cseq: 10
Session: 902818185
• OPTIONS: Ha sido necesario incluir este tipo de mensajes entre los que el
servidor es capaz de reconocer, ya que el reproductor VLC lo utiliza para
empezar las sesiones de streaming. QuickTime por el contrario no lo usa, lo cual
es otro ejemplo de cómo los diferentes reproductores (y servidores) pueden
hacer un uso diferente del protocolo. El mensaje OPTIONS es enviado por un
cliente al servidor con el objetivo de obtener información acerca de algún
contenido multimedia o del propio servidor. En el segundo caso, como el

mensaje no se refiere a ningún contenido multimedia en particular, la primera
línea de la petición contendrá un asterisco en lugar de una URL.
El servidor puede contestar con diferentes tipos de información,
dependiendo este extremo de la implementación de cada servidor en concreto.
Por ejemplo en el caso de que la URL sea un asterisco, puede informar de los
tipos de mensajes RTSP que admite, que es la solución que se ha adoptado en el
caso que nos ocupa aunque se reciba una URL que haga referencia a algún
archivo en concreto. De esta forma se consigue evitar que el cliente envíe al
servidor mensajes que este no sea capaz de reconocer. Por último hay que
señalar que el servidor también puede enviar una petición OPTIONS al cliente,
aunque esta opción es infrecuente.
En este ejemplo se muestra el mensaje OPTIONS que el cliente VLC le
envía al servidor como paso previo a la petición DESCRIBE.
OPTIONS rtsp://192.168.1.2:20000/video.mpg RTSP/1.0
CSeq: 1
User-Agent: VLC media player (LIVE555 Streaming Media
v2006.10.27)
La solución adoptada ha sido informar en la respuesta de los otros
mensajes RTSP que el servidor es capaz de entender, mediante la cabecera
Public.
RTSP/1.0 200 OK
Cseq: 1
Public: DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN
3.5.4.3.3. Resto de mensajes RTSP

En los apartados anteriores se han descrito los mensajes necesarios para la
reproducción de streaming y los mensajes adicionales implementados en este servidor.
Para ofrecer una visión más completa del protocolo RTSP en su conjunto, a
continuación se enumeran el resto de mensajes disponibles, describiendo brevemente su
utilidad.
• ANNOUNCE: el mensaje ANNOUNCE puede ser enviado del cliente al
servidor o del servidor al cliente, y su objetivo varía en cada caso.
o Si se envía del cliente al servidor, sirve para depositar en éste último
información de descripción sobre un contenido multimedia asociado a
una URL. Es decir, sirve para cambiar el estado del servidor, por ejemplo
consiguiendo que asocie un nuevo SDP a un determinado archivo.
o Enviándolo del servidor al cliente, se consiguen actualizar los datos de
descripción en tiempo real, sin detener la transmisión de datos. Por
ejemplo si en un instante determinado se cambia una pista por otra cuyo
formato es diferente, es posible informar de ello al reproductor mediante
un mensaje ANNOUNCE que contendrá el SDP actualizado, sin
necesidad de reiniciar la sesión.
• GET_PARAMETER: El cliente puede usar este mensaje para solicitar algún
tipo de información concreta asociada a la descripción de un contenido, aunque
esto no es muy frecuente puesto que la mayoría de la información debería venir
contenida en la respuesta a la petición DESCRIBE. En realidad la
implementación de la respuesta a este mensaje depende mucho de cada servidor.
• SET_PARAMETER: Se pueden enviar en ambos sentidos y sirven para
establecer el valor de algún parámetro en el otro miembro de la sesión. Esto no
puede incluir parámetros acerca del transporte de los datos, cuyos valores se
deben establecer exclusivamente por medio de los mensajes SETUP. Al igual
que en el caso del mensaje GET_PARAMETER, la implementación varía de
unos servidores a otros y además su uso no está muy extendido.

• REDIRECT: Mediante este mensaje un servidor es capaz de indicarle al cliente
que deberá realizar una nueva conexión a otra dirección de red y/o puerto para
continuar usando el servidor RTSP. Opcionalmente podrá indicar además en qué
momento se va a producir este cambio, de lo contrario se interpretará que el
cambio se produce inmediatamente. Cuando el momento llegue el cliente deberá
terminar la actual sesión con un mensaje TEARDOWN y establecerá una
conexión en la nueva localización.
• RECORD: Es posible que el servidor disponga de algún dispositivo de
grabación, esto es, que le permita crear un archivo multimedia en local
obteniendo los datos de alguna fuente externa. En este caso el cliente podrá
enviarle un mensaje RECORD para que el servidor realice dicha grabación. El
mensaje puede incluir el rango de tiempo que se debe grabar, en caso contrario
la grabación deberá empezar inmediatamente. Los datos también podrían
obtenerse de algún recurso de red, en este caso el mensaje RECORD deberá
incluir la localización de dicho recurso.
Como apunte final respecto a los mensajes RTSP hay que hacer notar lo fácil que
resultaría extender el protocolo con nuevos mensajes por ser un protocolo puramente
textual, bastaría que el servidor y el cliente fueran capaces de entenderlos.
También cabe señalar que además de los reproductores VLC y QuickTime se
trató de que el servidor fuera compatible con el reproductor Windows Media Player,
posibilidad que se consideró interesante debido a su popularidad. Sin embargo esto
resultó no ser posible, debido al uso que hace este reproductor del protocolo.
Observando los mensajes intercambiados con servidores RTSP alojados en Internet, se
comprobó que ignora el protocolo en su mayoría, ya que si bien la secuencia de
mensajes es similar, ignora la mayoría de cabeceras descritas en la RFC y usa las suyas
propias. Para que un servidor sea compatible con Windows Media Player debe ser capaz
de entender sus cabeceras particulares más allá de la especificación del protocolo, esto
se comprobó observando servidores RTSP comerciales, los cuales necesitan algún tipo
de configuración especial para atender las peticiones de este reproductor. Debido a estas
circunstancias fue descartado.

3.5.4.4. Aspectos de la implementación del protocolo
Para la interpretación de los mensajes se utiliza un analizador sintáctico
generado con la herramienta JavaCC, que es capaz de identificar el tipo de mensaje a
partir de su primera línea y después extraer el contenido de las cabeceras y el cuerpo. En
el caso de que el mensaje contenga cuerpo, será necesario tener en cuenta el número de
caracteres que lo componen para poder leerlo, dato que vendrá indicado en la cabecera
Content-Length. Se ha implementado una clase abstracta llamada RtspRequest, que
engloba a todos los tipos de peticiones y almacena los elementos comunes a todos los
tipos de mensajes, comunes en el sentido de que pueden aparecer en cualquier mensaje
aunque no siempre es obligatorio. Son los siguientes:
• Url: se utiliza para indicar el recurso multimedia o pista concreta a la que se
hace referencia, puede referirse al servidor en general si es un asterisco.
• Versión: indica el protocolo RTSP utilizado, actualmente solo existe el 1.0 pero
se almacena pensando en la evolución futura del protocolo.
• Cabecera Cseq: número de secuencia, que se irá incrementando en cada
mensaje del cliente. Las respuestas deberán contener el mismo número de
secuencia que la petición a la que corresponden.
• Cabecera Session: identificador de de sesión.
• Cabecera Content-Length: aparece si el mensaje incluye un cuerpo, y es su
tamaño en número de caracteres.
• Cabecera User-Agent: informa sobre qué cliente está enviando la petición, no
se tiene en cuenta.
• Cabecera Accept-Language: en esta cabecera establece un idioma, por ejemplo
podría tener utilidad si para un determinado recurso existen pistas de audio en
diferentes idiomas, en este servidor no se tiene en cuenta
Por cada tipo de petición hay una clase que extiende a la clase abstracta
RtspRequest, e incorpora los campos necesarios para almacenar las cabeceras

particulares del tipo de mensaje, en caso de haber alguna. A continuación se listan estas
clases y en su caso los campos particulares.
• OptionsRequest
• DescribeRequest
o Accept: Indica el tipo de descripción solicitada por el cliente (por
ejemplo SDP). Se utiliza una lista, ya que se pueden incluir varios tipos
de descripciones.
o Bandwidth: cabecera con un valor numérico relacionado con el ancho de
• SetupRequest
banda que envía el reproductor QuickTime.
o Transport: es la cabecera que contiene los datos de transporte. Para
almacenar su contenido se utiliza una estructura anidada, ya que los
diferentes campos contenidos en ella pueden tener además su propio
valor. Por ejemplo un campo dentro de la cabecera Transport será
Client-Port, y su valor la pareja de puertos RTP/RTSP. Otros datos
habituales dentro de esta cabecera son el protocolo de datos y si se trata
de una transmisión unicast o multicast.
o Se almacenan otras cabeceras relacionadas que el reproductor
• PlayRequest
QuickTime incluye en el mensaje y de las cuales no se hace uso, se
desconoce su utilidad puesto que no vienen definidas en la RFC que
define el protocolo RTSP. Son x-retransmit, x-dynamic-rate y x-
transport-options.
o Range: esta cabecera contiene varios campos relativos al fragmento del
contenido multimedia que se desea reproducir, algunos de ellos
opcionales. En primer lugar contiene el rango de tiempo que se desea
reproducir, incluyendo el instante inicial y el final, en caso de no existir
este último la reproducción es indefinida. Además esta información
puede venir indicada en diferentes formatos, por ejemplo en segundos u
otros. Por lo tanto se almacenan estos tres campos: formato de tiempo,
instante inicial e instante final. La implementación también está
preparada para reconocer el campo Time si existiera, aunque ni VLC ni

• PauseRequest
QuickTime hacen uso de él. En el mensaje play nuevamente QuickTime
incluye una cabecera no descrita en la RFC: x-prebuffer.
• TearDownRequest
Como nota final sobre el almacenamiento de las peticiones en estas clases Java,
hay que hacer notar el hecho de que se almacenan algunos parámetros que luego no se
tienen en cuenta a la hora de generar la respuesta. Se ha considerado que esta es la
implementación más correcta, ya que cabe la posibilidad de que el servidor evolucione y
se tengan en cuenta en el futuro. Además a modo de trazas, los sucesivos mensajes de
petición y respuesta se muestran por pantalla, y su contenido se extrae de estas clases,
así que es necesario almacenar todos los datos para reproducir fielmente todas las
peticiones.
Con esta separación entre clases dependiendo del tipo de petición, la clase
RequestHandler sabrá qué tipo de petición habrá llegado e invocará un método
diferente para atender a cada una de ellas. Estas clases habrán sido generadas por el
analizador obtenido mediante JavaCC, cuyo código java se encuentra en la clase
RtspRequestParser y algunas otras clases auxiliares asociadas.
En cuanto a las respuestas, se ha implementado una única clase RtspResponse.
Esta clase ofrece los métodos necesarios para especificar la primera línea con su código
de estado correspondiente, cuantas cabeceras sean necesarias y finalmente el cuerpo del
mensaje. Para garantizar la fiabilidad en el envío de las respuestas a los reproductores,
estas se pasan a formato de texto plano usando el juego de estándar de caracteres UTF-
8, y finalmente se envían en forma de ristra de bytes.

3.5.5. Mantenimiento del estado en el servidor
Como se ha mencionado, un servidor RTSP debe mantener información de
estado acerca de todas las sesiones activas, y el servidor que se ha creado cumple dicho
requisito. En este apartado se van a describir qué métodos y estructuras de datos se han
utilizado para conseguir este objetivo, y cómo se relacionan los mensajes RTSP con la
información contenida en estas estructuras.
3.5.5.1. Estructura de datos
Las principales clases involucradas son RtspSeverStatus y RtspSessionData.
El servidor llevará asociado un solo objeto RtspServerStatus, que contendrá ciertos
aspectos del estado general del servidor, y además contendrá un conjunto de instancias
de la clase RtspSessionData, cada una de ellas almacenará la información de una
sesión RTSP.
siguientes:
Los campos de información que almacena la clase RtspServerStatus son los
• SdpGenerator: referencia al objeto que implementa esta interfaz y se encargará
de obtener los SDP.

• Tipo de RtpSender: una variable que indica qué implementación de esta interfaz
se va a usar, de este modo se sabrá qué clase habrá que instanciar cuando sea
necesario crear un nuevo flujo de datos RTP.
• Un conjunto de referencias a objetos RtspSessionData, almacenadas en una
tabla Hash e indexadas mediante el número de sesión.
• Ruta al directorio donde se encuentran los archivos servidos, esta información
será necesaria a la hora de crear los flujos RTP para conocer la ubicación del
archivo origen.
• Información auxiliar sobre el analizador sintáctico: el analizador creado con
JavaCC es una clase estática que necesita inicialización la primera vez que se va
a usar y una re-inicialización cada vez que se vaya a volver a usar con
posterioridad mediante la llamada a un método diferente, así que aquí se
almacena un flag que indica si ha sido inicializado por primera vez.
Se creará un objeto RtspSessionData por cada sesión RTSP, y tendrá los
siguientes campos:
• Flag indicando si el cliente desea la pista de vídeo.
• Flag indicando si el cliente desea la pista audio.
• Dirección Ip destino para el vídeo.
• Dirección Ip destino para el audio (no parece tener sentido que las direcciones
de red para audio y vídeo sean diferentes, pero la especificación del protocolo lo
permite así que se ha tenido en cuenta).
• Puerto destino para el vídeo.
• Puerto destino para el audio.
• Referencia al objeto que implementa RtpSender.
• Contenido SDP del archivo que se está sirviendo.
• Variable que indica el estado de la transmisión RTP, que puede ser Deallocated
(no inicializada), Playing (reproduciendo) y Paused (pausada).
En la figura 3.7 se muestra un esquema de la estructura de datos que usa el
servidor para el mantenimiento del estado.

Figura 3.7: estructura de datos para el estado del servidor
3.5.5.2. Relación entre los mensajes RTSP y el estado del servidor
Una vez descrita la estructura de datos en la que se almacena el estado del
servidor, ahora se explicará cuándo y cómo se modifican sus datos, y en qué momento
se hará uso de ellos, en función de los mensajes RTSP.
• Al recibir el mensaje DESCRIBE, el servidor pedirá al módulo SdpGenerator
el SDP asociado a la URL del mensaje. En realidad el módulo SdpGenerator
devuelve un objeto de la clase SdpContent, que incluye toda la información
relevante sobre el SDP:
o URL asociada a la pista de vídeo.
o URL asociada a la pista de audio.
o El propio SDP en forma de cadena de caracteres, se incluirá en la
respuesta al cliente.
Si el archivo solicitado no existe, el SdpGenerator lanzará una
excepción, que será capturada y provocará el envío al cliente de un mensaje
informando de tal circunstancia
• Cuando el servidor reciba el primer mensaje SETUP, creará primeramente un
número de sesión aleatorio, y después un objeto RtspSessionData. Dicho
objeto será almacenado en la tabla Hash contenida en la clase

RtspServerStatus, siendo indexado mediante el propio identificador de sesión.
El servidor sabrá que se trata del primer mensaje SETUP porque no incluirá
identificador de sesión alguno.
Después comparará la URL del mensaje con el contenido del objeto
SdpContent, y así sabrá si el mensaje hace referencia a la pista de audio o vídeo,
activando el flag correspondiente. Posteriormente extraerá la información de
transporte, contenida en la cabecera Transport del mensaje. Los puertos de
destino RTP/RTCP estarán en el campo Client-Port. Se comprobará si existe
el campo Client-Ip-Address, en caso afirmativo se extraerá de él la dirección
IP de destino y de lo contrario será la propia dirección de la conexión con el
cliente.
Inicialmente además el valor del estado de la transmisión RTP es
deallocated, puesto que ni siquiera se ha creado el objeto RtpGenerator. Todos
estos datos son almacenados en el objeto RtspSessionData.
• Si existe otra pista y el cliente la desea activar, enviará un segundo mensaje
SETUP. Este mensaje incorporará un número de sesión igual al devuelto en la
respuesta anterior, así que en lugar de crear un nuevo objeto de estado, se
accederá al objeto RtspSessionData correspondiente, y se almacenarán los
parámetros de transporte de forma análoga al caso anterior. Si por alguna razón
el cliente necesitara cambiar nuevamente los parámetros de alguna pista, podría
hacerlo sin problemas enviando nuevos mensajes SETUP, sobrescribiendo el
servidor los valores de transporte.
• Una vez que el cliente haya enviado todos los mensajes SETUP y recibido sus
correspondientes respuestas, es de esperar que envíe la petición PLAY. En este
caso el servidor seguirá un flujo de control diferente dependiendo de si se está
usando el módulo JmfRtpSender o VlcRtpSender para el stream. Sin embargo
la estructura de las acciones a realizar serán las mismas en los dos casos:
o Si el estado de la transmisión era Deallocated (sin inicializar), se tendrá
que crear el objeto correspondiente que se encargará de generación de los
flujos RTP hacia el cliente, que será una instancia de la clase
JmfRtpSender o VlcRtpSender, ambos implementan la interfaz
RtpSender. Para ello se tendrán en cuenta los parámetros de control
almacenados previamente al recibir los mensajes SETUP: qué pistas

están activadas, dirección y puerto de destino para cada una de ellas,
nombre del fichero multimedia y directorio en el que se encuentra.
También se pasa como parámetro una referencia al objeto
RtspSessionData para que el propio encargado de la transmisión de
datos pueda modificar el estado de la transmisión. Una vez que el objeto
RtpSender esté creado, se comenzará la transmisión llamando al método
startTransmission, pasándole como parámetro el instante de tiempo
inicial indicado en la cabecera Range del mensaje PLAY.
o Si el estado de la transmisión era Paused o Playing, querrá decir que
reinicia la transmisión tras haber sido pausada, o que el usuario ha
movido la barra de desplazamiento en el reproductor, lo que provoca que
éste envíe un nuevo mensaje PLAY indicando el nuevo momento inicial
a partir del cual se debe reproducir. En ambos casos el comportamiento
será el mismo, iniciar la transmisión desde el momento dado mediante el
método startTransmission.
Como es lógico, en cualquiera de las circunstancias anteriormente citadas
el estado de la transmisión pasa a ser Playing. Hay que resaltar que nuevamente
aparece una diferencia significativa entre el comportamiento de los
reproductores QuickTime y VLC. Cuando se mueve la barra de desplazamiento,
VLC simplemente envía un mensaje PLAY con el nuevo instante inicial,
mientras que QuickTime envía primero un mensaje PAUSE e inmediatamente
después el mensaje PLAY. En todo caso el resultado es el mismo.
• Eventualmente es posible recibir un mensaje PAUSE del reproductor. El servidor
se limita a llamar al método pauseTransmission del RtpSender. El estado de
la transmisión pasa a ser paused.
• Finalmente, en algún momento dado el reproductor enviará un mensaje
TEARDOWN. Se ha comprobado que esto sucede si se cierra la ventana del
reproductor, o si se llega al final de la reproducción y se deja pasar un tiempo.
En primer lugar el servidor llamará al método tearDownTransmission del
RtpSender para que este libere internamente sus recursos. Después borrará el
objeto RtspSessionData de la estructura guardada en RtspServerStatus,
borrando así el estado de la sesión en el servidor. En el momento en que se cierre

la conexión a nivel de transporte con el cliente el hilo de ejecución del objeto
RequestHandler llegará a su fin, destruyéndose también este objeto. En
conclusión, cualquier recurso asociado con la sesión que ha finalizado habrá
sido eliminado del servidor.
Para facilitar la comprensión de esta secuencia de mensajes y acciones a
continuación se muestra en la figura 3.8 un diagrama de secuencia que corresponde a
una sesión RTSP, en la cual se reproduce un archivo que consta de una sola pista (un
solo mensaje SETUP). Además se incluye una pausa durante la transmisión.

Figura 3.8: secuencia de mensajes RTSP y cambios de estado en el servidor

3.5.6. Módulo JmfRtpSender
En este capítulo se va a describir el funcionamiento de esta clase, la cual puede
ser utilizada por el servidor RTSP si se configura a tal efecto. Para la implementación se
ha usado la API Java Media Framework, cuyas características generales ya han sido
descritas. A partir de ahora se explicará más detalladamente el proceso de streaming a
través de RTP usando JMF, y cómo se ha integrado con el resto del servidor. Se hará
especial hincapié en las clases relacionadas con la transmisión a través de RTP. Hay que
tener en cuenta que la API está formada por multitud de clases y estructuras, y no es
posible abarcar todas en este documento. Por ello se tratará de mencionar solo las más
relevantes para tratar de ofrecer una idea global de cómo funciona la API, y se
explicarán detalladamente las relacionadas con la solución que se ha implementado.
3.5.6.1. Arquitectura de Java Media Framework
Desde el punto de vista conceptual, JMF abstrae el contenido multimedia en
DataSources (fuentes de datos, a través de las cuales se lee el contenido desde el
exterior) y DataSinks (destinos para el volcado de datos, a través de los cuales se
exporta el contenido al exterior). Los DataSources pueden ser un fichero almacenado en
disco, un dispositivo de captura o un flujo que llega a través de la red. Análogamente los
DataSinks pueden conllevar la grabación en un fichero de destino, la reproducción a
través de un dispositivo de salida o el envío de un flujo por la red. Entre medias se
pueden realizar diversas tareas de procesamiento como compresión/descompresión,
cambio del formato de las pistas y aplicación de efectos, utilizando entidades llamadas
Processors. Esta estructura se puede ver en la figura 3.9.

Figura 3.9: estructura de entrada, procesamiento y salida de datos en JMF
Además utilizando los DataSources y DataSinks se pueden encadenar unos
Processors con otros, realizando múltiples tareas de procesamiento simultáneas,
creando flujos a partir de otros, etc. En la figura 3.10 se muestra un ejemplo. Esta
arquitectura encaja bastante bien con la estructura modular del servidor que se pretende
implementar en este trabajo.
Figura 3.10: ejemplo de estructura modular en JMF
Los DataSources, Processors y DataSinks forman parte de la API de alto nivel
que ofrece JMF, dicha API está orientada a la captura, proceso y presentación de la
multimedia. JMF ofrece otra API de más bajo nivel destinada a la implementación de
extensiones y elementos de procesamiento más personalizados. En este proyecto se ha
hecho uso de la API de más alto nivel, puesto que es la ofrece las posibilidades
necesarias para esta tarea. En la figura 3.11, las clases implementadas en el servidor
RTSP se encontrarían en el nivel más alto, mientras que en el segundo están las clases
JMF que se han utilizado.

Figura 3.11: niveles de la API de JMF
A continuación se va a explicar la forma en que JMF aborda ciertos aspectos
relacionados con la multimedia, como el manejo del tiempo, eventos, datos y formatos,
además de los mecanismos para controlarlos.
• Modelo de tiempo: JMF controla el tiempo con una precisión de nanosegundos.
Internamente, JMF lleva cuenta del tiempo transcurrido para cualquier flujo
multimedia. Esto se usa para tareas de sincronización tanto interna como entre
varios flujos simultáneos. Además posibilita el control del tiempo por parte del
desarrollador, por ejemplo alterando la velocidad original de un vídeo.
• Modelo de eventos: JMF usa una estructura de reporte de eventos, con el
objetivo de tener constancia del estado actual de cada elemento multimedia y
recibir notificaciones de los cambios que puedan experimentar. Existen multitud
de tipos de eventos diferentes para comunicar diferentes circunstancias. Esto
incluye notificaciones y estados de error.
A grandes rasgos, siempre que un objeto de JMF necesita comunicar un
evento, lo hace introduciéndolo en la estructura de eventos. Este evento podrá
ser recogido por el resto de objetos JMF que estén preparados para ello,
dependiendo ya esta circunstancia de la implementación de cada uno de ellos.
Pensando en el servidor objetivo de este proyecto, un evento a tener en cuenta
será el llegar al final del fichero que se está sirviendo.
• Modelo de datos: Como se ha mencionado, los DataSources se usan para
representar el origen de un contenido multimedia. Un DataSource encapsula
tanto la localización del contenido como el software y el protocolo necesarios

para transmitir su contenido. Una vez obtenido un DataSource, no se puede
reutilizar para manejar un contenido diferente.
Un DataSource puede estar identificado por un MediaLocator o una
URL. Un MediaLocator es similar a una URL y puede ser construido a partir de
ella, pero ofrece la ventaja de que puede ser construido incluso si el
correspondiente manejador de protocolo no está instalado en el sistema (en Java
una URL solo puede ser construida si el sistema dispone de su manejador de
protocolo). Un MediaLocator puede ser, por ejemplo, la ruta del archivo. Existen
dos categorías de DataSources que varían en la forma en que se va a extraer la
información, y están asociados al uso con determinados protocolos.
o Pull DataSources: se suele usar en el contexto de sesiones HTTP.
o Push DataSources: Más adecuado para tareas de streaming, como
sesiones RTP.
Además independientemente de la categorización anterior, existen unos
DataSources especiales:
o Cloneable DataSources: se utilizan para obtener nuevos DataSources a
partir de uno dado, por ejemplo se pueden utilizar para replicar flujos de
streaming y enviarlos a diferentes destinos.
o Merging DataSources: son la opción inversa a los anteriores, y sirven
para unir diferentes fuentes en una sola. Por ejemplo se pueden combinar
dos DataSources diferentes de audio y vídeo para obtener un solo
DataSource que maneje ambos flujos, y poder grabar un fichero en disco
que los combine.
• Modelo de formatos: JMF proporciona una jerarquía de clases para definir el
tipo de formatos de cada pista multimedia. A grosso modo, existen dos tipos de
formatos, dependiendo de si son de audio o vídeo. Para estos últimos hay una
subclase particular para cada tipo de formato, y cada una de ellas ofrece métodos
para modificar los parámetros a los que el desarrollador puede acceder. Por
ejemplo la clase H263Format corresponde al formato de vídeo H263.
Para Audio existe un solo formato AudioFormat, que permite acceder a
varios parámetros relacionados con la transmisión de sonido: frecuencia, bitrate,
número de canales (mono o estéreo), etc.

• Controladores: son clases que proporcionan los mecanismos para introducir y
extraer el valor de los atributos de los objetos JMF. Existen multitud de estas
clases y todas implementan la interfaz Contol de JMF, el desarrollador puede
implementar nuevos controladores teniendo en cuenta dicha interfaz. Por
ejemplo si se desea cambiar el valor de algún atributo de la clase AudioFormat,
habrá que obtener primero el control correspondiente.
• Managers: los Managers son los “intermediarios” que ofrece la API para
controlar a todos los elementos descritos anteriormente en este capítulo, y por
tanto es fundamental que el desarrollador los conozca. Los Managers
implementan las interfaces que especifica JMF para definir el comportamiento y
la interacción con los objetos de captura, proceso e implementación de la
multimedia. Existen cuatro Managers:
o Manager: se encargan de la construcción de Processors, DataSources y
DataSinks.
o PackageManager: mantiene un registro de los paquetes que contienen
clases JMF.
o CaptureDeviceManager: mantiene un registro de los dispositivos de
captura disponibles.
o PlugInManager: mantiene un registro de los plugins disponibles para
3.5.6.2. Processors
JMF, como multiplexadores, demultiplexadores, codecs, etc.

Los Processors son objetos que permiten controlar la información multimedia, y
más concretamente los formatos de las diferentes pistas. Como se verá más adelante es
necesario cambiar los formatos de las pistas antes de crear una transmisión RTP, ya que
los formatos originales no serán válidos y será necesario usar formatos equivalentes
válidos para RTP. Desde este punto de vista, la actividad de un Processor se puede
separar en tres fases, representadas en la figura 3.12.
• Demultiplexación: las diferentes pistas se extraen de forma independiente, por
ejemplo de un archivo se extraen las pistas de audio y vídeo. La
demultiplexación se realiza automáticamente siempre que existan varias pistas.
• Transcoding: cada pista se cambia de un formato a otro. Se pueden modificar
otros parámetros, dependiendo del formato específico de cada pista. El
transcoding incluye una etapa previa de pre-procesamiento y una posterior de
post-procesamiento, en las cuales se aplican algunos algoritmos de efecto
dependiendo del tipo de formato.
• Multiplexación: Las pistas se vuelven a unir en un solo contenedor.
Figura 3.12: fases de procesamiento en un Processor
Además de renderizar el contenido para presentarlo por diferentes dispositivos
de salida, los Processors se pueden encadenar unos a otros mediante el uso de
DataSources. Es decir, un Processor puede volcar su salida a un DataSource, y éste
servir de entrada a un nuevo Processor. De este modo se pueden realizar múltiples
tareas de control, replicar los contenidos multimedia para enviarlos a varios destinos
simultáneamente, etc. En la figura 3.13 se pueden ver las alternativas para los datos de
salida de un Processor.

Figura 3.13: alternativas de salida para los datos de un Processor
ESTADOS DEL PROCESSOR
Un Processor pasa por diferentes estados desde el momento en que es creado
hasta que es destruido. Algunos cambios de estado son provocados explícitamente por el
programador mientras que otros se producen por si solos, debido a algún evento o
porque el Processor ha completado cierta tarea. Cuando un processor cambia de estado
puede publicar un evento informando de ello, que deberá ser recogido por los objetos
interesados. A continuación se enumeran los diferentes estados por los que pasa el
Processor, y qué circunstancias provocan el paso de un estado a otro. La figura 3.14
muestra un esquema a este respecto.
• Cuando un Processor se instancia, se encuentra inicialmente en el estado
unrealized. No tiene ninguna información sobre la fuente de multimedia que
deberá manejar.
• Eventualmente el programador hará que el Processor entre en estado
configuring. En este estado el Processor se conecta a su DataSink de entrada, el
cual deberá haber sido configurado previamente con el recurso multimedia al
que se va a acceder. El Processor extraerá las diferentes pistas, y accederá al
formato de cada una de ellas. Si no se produce ningún error, el Processor llegará
al estado configured. Llegado este punto, el programador puede realizar las
tareas de transcoding que desee sobre cada pista, utilizando los controles que
JMF provee para ello.
• Cuando las tareas de transcoding estén completas, el programador podrá hacer
que el Processor pase a estado realizing. Durante este estado el processor
determina los recursos que serán necesarios, y los adquiere. Esto hace referencia
a los recursos que sólo será necesario adquirir una vez. Por ejemplo recursos de

enderizado, o determinados dispositivos hardware. Una vez adquiridos los
recursos, el Processor llegará estado realized, en el cual se encuentra
completamente construido.
• A partir de este estado el programador no dispone de métodos que hagan
referencia explícita a los siguientes estados que el Processor alcanzará. En lugar
de ellos dispone de ciertos métodos para su control, y dependiendo de la
situación el Processor cambiará de estado internamente. Se mencionan los
siguientes cuatro métodos, por ser los que se han usado en la implementación
del objeto JmfRtpSender:
o start: comienza la transmisión desde el Processor. Si el Processor se
encontraba en el estado realized, pasará al estado prefetching, durante el
cual se prepara realizando una precarga de los datos multimedia y
obtiene los recursos exclusivos necesarios que necesite. Si todo va bien
llegará al estado prefetched. En este momento el Processor está
preparado para comenzar la transmisión. Cuando lo haga pasará al estado
started, y esto puede suceder inmediatamente o con posterioridad,
dependiendo de parámetros de tiempo y sincronización que es posible
establecer.
o stop: Si estando en el estado started se llama al método stop, la
actividad del Processor se detiene, y vuelve al estado prefetched. Por lo
tanto sucesivas llamadas a los métodos start y stop harán el que
Processor alterne entre los estados prefetched y started. Como se verá,
esto resultará útil para implementar la funcionalidad de pausa.
o setMediaTime: Este método se puede usar para establecer el punto del
contenido multimedia a partir del cual debe realizar su actividad el
Processor, recibiendo como parámetro el instante de tiempo expresado
en segundos. El Processor volverá al estado realized, y para reanudar la
transmisión será necesario volver a invocar el método start, implicando
todas las operaciones internas descritas anteriormente.
o deallocate: aborta la operación actual y cesa toda actividad que esté
consumiendo recursos. Es ilegal invocar este método en un Processor
que esté en estado started, así que habrá que llamar primero al método

stop. Después se podrá invocar al método deallocate, lo que hará
retroceder al Processor hasta el estado realized.
o close: después de invocar el método anterior se podrá usar el método
close para liberar definitivamente el resto de recursos asociados al
Processor, de forma que éste no podrá volver a utilizarse.
Figura 3.14: estados de un Processor

3.5.6.3. API para RTP
JMF incluye una API específica para RTP, de forma que las tareas de captura,
procesamiento y envío de datos a través de este protocolo se pueden integrar de forma
equivalente a como se hace con el resto de contenidos multimedia. La situación de la
API RTP en relación a JMF se puede ver en la figura 3.15.
Figura 3.15: API para RTP en JMF
La clase RTPManager es la que controla toda la sesión RTP, desde el punto de
vista del participante local. Será necesario instanciar un objeto RTPManager por cada
flujo RTP que se desee enviar o recibir. Además también maneja el canal de control a
través de RTCP. Esta clase además proporciona los métodos necesarios para inicializar y
comenzar las sesiones RTP (en función de las direcciones de red y puertos origen y
destino), así como para detenerlas y liberar los recursos.
Siguiendo el esquema general de JMF que se ha descrito anteriormente, existe
una familia de eventos y controladores relacionados con las sesiones RTP. Además
existe un modelo de datos particular para RTP, con clases para manejar los flujos de
entrada y salida.

3.5.6.4. Sesión RTP
Hasta ahora se han descrito todos los componentes involucrados en la
generación de flujos RTP con JMF. En este apartado se va a explicar cómo se combinan
entre ellos, para obtener finalmente una visión global del proceso en su conjunto.
Téngase en cuenta que esta vez se explican los pasos simplificadamente, y que
realmente involucran todos los detalles explicados anteriormente.
• Generación de un Processor: Primeramente será necesaria la creación de un
Processor, a partir de un DataSource que haga referencia al archivo multimedia
desde el que se va a obtener el flujo RTP.
• Cambio de formato: Para posibilitar el envío a través de RTP no serán válidos
en ningún caso los formatos originales, ya que es necesario usar unos formatos
específicos de JMF. Por tanto, habrá que realizar un cambio de formato para
cada pista, tarea que como se ha explicado es posible realizar con un Processor.
En el caso que nos ocupa, este proceso se habrá de dividir en dos fases:
primeramente se establecerá el contenedor del Processor como RAW_RTP (RTP
en crudo). Después utilizando ciertos métodos que proporciona la API se
obtendrá para cada pista una lista de formatos a los que es posible cambiar la
misma. Por haber establecido el contenedor como RAW_RTP, todos los formatos
de esta lista serán válidos para la transmisión RTP. Cada pista se cambiará al
primero de los formatos de esta lista. Si todo ha ido bien el Processor se
encontrará en el estado realized, pero la transmisión no se inicia todavía.
Como resultado, se obtendrá un Processor con un contenido multimedia
cuyas pistas son parecidas a las originales y válidas para la transmisión RTP.
• Creación de las sesiones RTP: se usa la clase RTPManager para crear las
sesiones RTP, una por cada pista. La fuente de información será el Processor,
del cual es posible obtener su salida de datos en forma de DataSource a través
del método adecuado. De esta forma el Processor y los RTPManager quedan
“encadenados”. Para cada sesión RTP inicializada se obtiene un objeto que
representa la estructura de datos que va a enviar el flujo RTP (sendStream).

A partir de este punto, la transferencia RTP está lista para comenzar, y el
manejo se hará a través del Processor, con los métodos start y stop mencionados
anteriormente.
FINALIZACIÓN
La finalización de la sesión RTP se puede realizar en cualquier momento,
independientemente de que la transmisión de datos haya finalizado o no. Si el contenido
de un archivo multimedia ha sido completamente transmitido, lo único que sucede es
que pasa del estado started al prefetched, siendo posible volver a reiniciar la
transmisión.
Para finalizar la transmisión se libera el Processor con los métodos deallocate
y close, y posteriormente se destruyen las sesiones RTPManager con los métodos
apropiados para ello.
Por último cabe señalar que existe una alternativa al uso de la clase RTPManager
para el envío de los datos a través de RTP. Es el uso de un Datasink configurado de una
manera específica (recuérdese en la descripción general de JMF, que los DataSink son
abstracciones que se usan para indicar el destino de los datos). Se ha desechado esta
opción porque solo permite transmitir la primera pista de un contenido multimedia,
aunque existan más pistas.

3.5.6.5. Implementación de la clase JmfRtpSender
Todos los mecanismos de JMF que se han expuesto han sido plasmados en la
clase JmfRtpSender, que es la que va a formar parte del servidor RTSP. Recuérdese que
esta clase implementa la interfaz RtpSender que ya se describió en su momento. En
este apartado se explica cómo se ha hecho, incluyéndose fragmentos de código para
facilitar la comprensión.
• Inicialización: Las sesiones RTP se inicializan en el propio constructor de la
clase. El constructor recibe como parámetros:
o Ruta al directorio con los archivos multimedia del servidor.
o Nombre del archivo que se pretende transmitir.
o Direcciones Ip origen y destino.
o Puertos de destino para la o las pistas.
o Flags indicando qué pistas se desean transmitir (aunque un archivo
contenga pistas de audio y vídeo, podría darse la circunstancia de que
solo se quiera transmitir una de ellas).
o Referencia al objeto RtspSessionData que contiene el estado de la
sesión en el servidor RTSP.
Dentro del constructor se realizarán todas las tareas de inicialización
explicadas anteriormente. Se identificará el archivo fuente a partir de su nombre
y la ruta que han sido pasados como parámetros, obteniendo un MediaLocator y
construyendo con este un DataSource. Posteriormente se creará un Processor
que recibirá como entrada este DataSource.
Para la creación de las sesiones RTP con RTPManager se usarán los
parámetros de transporte especificados, pero nótese que no se ha indicado
ningún puerto origen. Estos son obtenidos de forma aleatoria, asegurándose de
que son puertos disponibles, y que son números pares (requisito necesario para
RTP).

Si toda la ejecución del constructor se realiza correctamente se obtendrá
un Processor en estado prefetched listo para comenzar la transmisión, y
conectado a las sesiones RTP necesarias. En el objeto RtspSessionData se
cambia el estado de la transmisión de deallocated a paused. En caso de que se
produzca algún error dentro del constructor (por ejemplo tratar de utilizar un
archivo con formatos que JMF no es capaz de manejar), el propio constructor
elevará una excepción que será recogida por la clase RequestHandler.
• Método startTransmission: recibe como parámetro el instante de tiempo a
partir del cual se desea transmitir, expresado en segundos. Realiza tres llamadas
consecutivas a los métodos del Processor:
o stop: detiene el Processor si estuviera en estado started, si no la llamada
no tiene efecto.
o setMediaTime: se le indica al Processor el instante a partir del cual
deberá continuar, usando el parámetro del método startTransmission.
No se puede invocar este método sobre un Processor en estado started,
de ahí la llamada anterior a stop.
o start: se comienza la transmisión, y este paso provocará el comienzo
del envío de los datos RTP a través de la red.
Por último, el estado de la transmisión en el objeto
RtspSessionData se cambia a playing.
• Método pauseTransmission: se detiene el Processor con el método stop, y el
estado de la transmisión en el objeto RtspSessionData se cambia a paused.
• Método tearDownTransmission: se liberan el Processor y los RTPManager de
la forma descrita en el apartado anterior.
El estado de la transmisión (deallocated, paused, playing) no se tiene en cuenta
dentro de la propia clase JmfRtpSender, pero se almacenan para que la clase
RequestHandler tenga constancia del estado de la transmisión, información necesaria
en algunos casos. Por ejemplo cuando llegue un mensaje PLAY sabrá si tiene que
construir o no el objeto JmfRtpSender, dependiendo de si el estado de la transmisión
era deallocated o no.

Por último, se ha implementado un método interno que es capaz de recoger
eventos lanzados por el Processor. El único evento que realmente importa es el que se
lanza cuando se llega al final del archivo (EndOfMediaEvent). Entonces
automáticamente se detiene el Processor con el método stop, y la transmisión se
cambia del estado playing al paused.
3.5.6.6. Problema de JMF: sincronización de las pistas
Para terminar la descripción de JMF, se va a comentar el principal problema que
se ha encontrado. Este problema consiste en que si se transmiten las dos pistas de un
archivo que contenga audio y vídeo, habitualmente estas pistas no se reproducen con la
sincronización adecuada. En lugar de ello, el sonido se reproduce con un ligero retraso
respecto al vídeo, llegando a haber un desfase en ocasiones de 1 segundo
aproximadamente. No es un problema del reproductor puesto que este fenómeno se
manifiesta igualmente con QuickTime y VLC.
Se estudió profundamente la API y la documentación, pero no se encontró forma
alguna de solucionar este problema. Teóricamente, JMF usa internamente los paquetes
RTCP y el modelo de tiempo para mantener la sincronía en la transmisión de las pistas,
y el desarrollador no tiene forma de influir en el ajuste. En los foros de desarrollo de
JMF se comprobó que otras personas sufren el mismo problema, sin que nadie haya sido
capaz de aportar una solución.
Por último se estudió la base de datos de JMF que contiene la información sobre
los bugs. Se encontró un bug que precisamente habla sobre el retardo del vídeo respecto
al audio en la transmisión RTP, concretamente el bug número 4369079. Así que se llegó
a la conclusión de que esta es la causa del problema y se abandonó la búsqueda de una
solución.
Sin embargo sí se ha conjeturado la causa. El desfase es variable (a veces incluso
el sincronismo es perfecto), y se produce al inicio de la reproducción, manteniéndose el
mismo desfase constante durante toda la reproducción hasta el final del archivo. Puede
que la causa sea algún tipo de problema de rendimiento al inicio de la sesión RTP,

teniendo en cuenta las múltiples tareas y cambios de estado del Processor, ya que se
observa que el procesador del ordenador trabaja al 100% durante unos segundos. Esta
idea se refuerza con el hecho de que si después de la reproducción completa del archivo
se vuelve a reiniciar la transmisión desde el principio (no hace falta realizar las tareas de
inicialización), entonces invariablemente el sincronismo es correcto
3.5.7. Módulo VlcRtpSender
Esta clase constituye la segunda posibilidad que se ha implementado para la
transmisión de datos RTP. En el capítulo sobre la descripción de las tecnologías de
streaming ya se han mencionado sus características principales, entre las que destaca la
posibilidad de manejarlo utilizando la línea de comandos, posibilitando de esta forma la
integración de VLC con un programa java, en este caso nuestro servidor RTSP. En este
sentido, la creación de los datos RTP no ha implicando tanto trabajo de desarrollo como
en el caso de JMF, pero ha sido necesario solventar ciertos problemas que se
comentarán en su momento. La mayoría del tiempo dedicado a esta parte del proyecto
ha consistido en la realización de pruebas y la investigación en documentos de VLC y
en los foros de desarrollo en Internet para resolver esos problemas.
En los apartados siguientes se describirá el manejo de VLC por línea de
comandos, se explicará cómo es posible integrar este manejo en un programa en Java, y
por último se detallará la adaptación de estos mecanismos en la clase VlcRtpSender.
3.5.7.1. Módulos VLC para streaming
VLC permite el envío de datos a través de la red y/o su volcado a un archivo.
Durante este proceso se pueden realizar diferentes tareas de procesamiento como
transcoding, aplicación de filtros, modificación del tamaño de la imagen, etc. Existen
diferentes módulos que proporcionan varias funcionalidades, y se pueden usar
simultáneamente encadenando unos con otros. Cada módulo consta de varios campos
que se pueden usar para establecer ciertos parámetros, pero su cantidad es muy grande y

no se van a citar. A continuación se enumeran los módulos disponibles y se explica su
función
• standard: permite el volcado de un contenido streaming a un fichero o a través
de la red. Algunas de sus opciones son el contenedor en que se van a encapsular
lo datos, y el protocolo de red, por ejemplo HTTP o UDP.
• transcode: permite cambiar el formato de los datos que el módulo recibe como
entrada. Si la fuente es un contenido en vivo (proveniente de la red o de algún
dispositivo de captura), el transcoding se hace “al vuelo”, pudiéndose necesitar
mucho trabajo de la CPU dependiendo de los parámetros. Si la fuente es un
archivo o un disco externo, se hace a la mayor velocidad que sea posible.
Incluye una gran variedad de opciones y efectos, destacando la
posibilidad de elegir la librería de codecs que se va a utilizar. También permite
definir el número de imágenes por segundo, escalar la imagen por algún factor,
multiplexar o demultiplexar las pistas, etc.
• duplicate: duplica los datos de entrada, permitiendo el manejo de 2 flujos de
datos iguales a partir del flujo origen. Por ejemplo, se podrían enviar datos a
través de la red y volcarlos localmente a un archivo de forma simultánea.
• display: permite reproducir los datos de entrada de igual forma que lo hace el
reproductor VLC. Permite elegir qué pistas se van a reproducir y también es
posible introducir un retardo. Este módulo podría ser útil, por ejemplo, para
monitorizar el contenido que se está enviando a algún destino.
• rtp: permite el envío de datos a través del protocolo RTP de forma no
entrelazada, es decir que cada pista se envía a un puerto destino diferente.
Permite establecer varios parámetros de transporte como la dirección de destino
y los puertos de destino para audio y vídeo, entre otros. También puede poner a
disposición el SDP asociado al contenido, por ejemplo a través del servidor
HTTP integrado de VLC. Otra posibilidad es establecer el contendor para los
datos.
• elementary stream: permite separar las diferentes pistas que contengan los
datos de entrada. Por ejemplo se podría usar para guardar los datos de vídeo a un
fichero y los de audio a otro fichero diferente. Entre sus opciones está la

posibilidad de especificar contenedores y parámetros de destino diferentes para
cada pista.
3.5.7.2. Comandos para el envío de datos RTP
Al empezar a estudiar la documentación y los ejemplos del manejo de VLC por
línea de comandos para generar el envío de datos por RTP, lo primero que se observó es
que la funcionalidad de algunos módulos parece solaparse, de tal forma que no se sabe
con certeza cual es la mejor manera de realizar ciertas tareas. Parece lógico pensar que
se debería usar el módulo rtp, pero teóricamente el módulo Elementary stream
también debería ser válido puesto que ofrece una cabecera que permite establecer el
método de envío de los datos, y entre las distintas posibilidades se encuentra el
protocolo RTP.
Tras realizar varias pruebas se decidió el uso del módulo rtp, debido a que el
módulo Elementary stream parecía no funcionar bien; se comprobó con Wireshark
que efectivamente se estaban enviado datos, pero los reproductores simplemente no
mostraban ningún contenido. El módulo rtp sí generaba datos capaces de ser
interpretados por los clientes.
El comando se construye como sigue: el primer parámetro es el nombre del
archivo origen de los datos. Después se incluyen los caracteres --sout=, que hacen
referencia a la característica de VLC que permite el envío de streaming, llamada stream
output. A continuación se añade el nombre del módulo rtp, y entre llaves se introducen
los parámetros de transporte necesarios junto con sus correspondientes valores. Estos
parámetros serán la dirección de destino y los puertos de destino para audio y/o vídeo.
Un parámetro adicional es el método de encapsulación. Para RTP las opciones son
MPEG2 o el envío en crudo (sin encapsulación). Si no se especifica este parámetro, se
usa el método en crudo como encapsulado por defecto. La sintaxis exacta varía
ligeramente de un sistema operativo a otro, los ejemplos que se mostrarán corresponden
al sistema operativo Windows.

Este sería el comando necesario para ejecutar VLC e iniciar el envío de datos
RTP, a partir de un archivo llamado “video.mpg” que se encuentra en el directorio
“C:/multimedia” y que contiene dos pistas de audio y vídeo:
vlc C:/multimedia/video.mpg --sout="#rtp{dst=192.168.1.5;
port-video=5000;port-audio=5002}"
3.5.7.3. Control de VLC a través de su interfaz Telnet
Una vez arrancado VLC como servidor de datos RTP, se abre la cuestión de
cómo controlarlo. Por ejemplo, cuando el cliente pause la transmisión o pretenda
reiniciar la transmisión desde un instante diferente porque se ha movido la barra de
desplazamiento, será necesario modificar la ejecución de VLC en consecuencia. Esto es
posible ya que existe la opción de lanzar una consola de control remoto en el momento
de ejecutar VLC y posteriormente conectarse a esta consola a través de Telnet 16 , como
se puede ver en la figura 3.16.
Figura 3.16: servidor RTP desde VLC
Existe la posibilidad de lanzar dos tipos de consolas remotas diferentes, varían
en lo relativo a la cantidad de opciones que ofrecen. Además será necesario indicar la
dirección y puerto donde se realizará la conexión vía Telnet. En cuanto a las opciones de
16 Telnet es el nombre de un protocolo y del programa que lo implementa. Sirve para manejar
remotamente una máquina de igual forma que si se pudieran introducir comandos por el teclado.

control, existen más de veinte diferentes. Permiten controlar la reproducción del
contenido actual, añadir o quitar recursos multimedia a la lista de reproducción, cambiar
el contenedor, mostrar información de la reproducción, cargar y guardar perfiles de
configuración, etc.
Por ejemplo, si se quisiera lanzar la interfaz Telnet que ofrece mayor
funcionalidad de forma que esperara las conexiones en el puerto 5000 de la máquina
local, habría que añadir los siguientes caracteres al ejemplo anterior:
--extraintf=rc --rc-host=localhost:5000
3.5.7.4. Clase Runtime
Todo programa java lleva implícitamente asociada una instancia de la clase
Runtime, la cual permite al programa interaccionar con el entorno en el que se está
ejecutando, mediante la ejecución de aplicaciones externas. Por ejemplo, uno de los
usos más habituales es la apertura de un navegador con información de ayuda en
HTML.
Esta clase permite al programa java la adquisición de un objeto de la clase
Process, que es la referencia al entorno donde el programa se está ejecutando. La clase
Process es abstracta, ya que su implementación depende de cada sistema operativo.
Esta referencia se obtiene con el método Runtime.exec, con este método se iniciará la
ejecución del proceso definido por el comando y los parámetros, de forma similar a
como se haría escribiendo a través de una consola de línea de comandos. También se
puede establecer el valor de las variables de entorno.
Intuitivamente se puede pensar que esta clase permite realizar las mismas
operaciones que una consola del sistema operativo, pero esto no es así y hay que tener
en cuenta sus limitaciones, ya que sólo se puede usar para la ejecución de programas
ejecutables y scripts. No permite realizar el resto de tareas que sí permite una consola,

por ejemplo un error muy común es tratar de usar comandos interpretados como dir en
MS-DOS, esto no es posible ya que no se trata de un ejecutable si no de un comando
interpretado por la consola. Tampoco sería posible volcar la salida de un proceso a la
entrada de otro, etc. Para interaccionar con el proceso externo una vez lanzada se puede
hacer uso de su buffer de entrada y dos buffers de salida: la salida estándar y la salida de
error.
3.5.7.5. Problemas en el uso de VLC con la clase Runtime
Antes de explicar cómo se ha implementado el módulo VlcRtpSender es
necesario comentar algunos problemas que necesariamente han tenido impacto en la
solución final. La principal dificultad radica en que algunos de estos problemas no se
pueden explicar de forma lógica, y la forma de solucionarlos es la realización de
sucesivas pruebas.
• Lanzamiento de la consola: inicialmente se trató de ejecutar directamente VLC
con los parámetros asociados, pero este método no funcionaba. Una opción más
fiable es ejecutar el propio comando que crea una consola (en el caso de
Windows es cmd.exe) pasándole como parámetros el proceso que realmente se
quiere ejecutar y los parámetros de este último.
• Caracteres de entrada: el método exec tiene problemas para reconocer
determinados caracteres, por ejemplo las comillas dobles o simples. Según la
documentación y como se muestra en el ejemplo sobre la llamada a VLC por
línea de comandos, es necesario escribir comillas. Afortunadamente se
comprobó que eliminando las comillas VLC también arranca correctamente,
pero hay que tener presente que esta es una circunstancia arbitraria y en caso de
no funcionar podría haber supuesto un serio problema.
También existen problemas en el uso de espacios en blanco.
Teóricamente se le puede pasar al método exec un array de cadenas de
caracteres, y este lo deberá interpretar como cadenas separadas por un espacio.
Se trató de usar esta característica para incluir espacios en la ruta por defecto
donde se encuentra el ejecutable vlc.exe, pero esto no funciona bien. Por lo

tanto es necesario que el ejecutable (y los archivos que se vayan a servir) se
encuentren en directorios cuyas rutas no contengan espacios.
• Conexión a la interfaz Telnet: El primer problema en cuanto a la conexión por
Telnet con la consola de control es el establecimiento de la propia conexión. Esta
conexión no se establece siempre con éxito al primer intento, de tal forma que ha
sido necesaria la implementación de bucles donde se reintenta la conexión
repetidamente y se produce una pausa de dos segundos entre cada reintento,
hasta que finalmente la conexión se establece. Esta no es una solución muy
elegante, pero ha sido la única forma de garantizar que finalmente la conexión se
acaba realizando, generalmente en dos o tres intentos.
Un segundo problema apareció inmediatamente después de conseguir la
conexión y era que se producía un error de autenticación de igual forma que si se
introdujera una clave errónea. El hecho es que esta conexión no necesita de
clave, y además el error se producía inmediatamente sin que se introdujera clave
alguna. En los foros de desarrollo para VLC se leyó acerca de otras personas con
el mismo problema, y se llegó a la conclusión de que este es un error que se
produce en ciertas circunstancias no del todo claras y dependiendo además de la
versión de VLC que se utilice. Se consiguió evitar este problema usando la
versión de VLC 0.8.6a, mientas que la versión actual en el momento de escribir
este documento es la 0.8.6c.
Por último, existía el problema de que al lanzar la consola de control
remoto esta aparecía en forma de ventana en la pantalla, de forma que no era
posible capturar su buffer de entrada para enviar comandos ya que la entrada era
el teclado del ordenador. Esto se solucionó añadiendo un parámetro que permite
lanzar la consola de control en modo silencioso, este parámetro es --rc-quiet.
• Robustez: en general, el uso de VLC con el método exec no es robusto, y el
éxito de los comandos no siempre está garantizado. Esto quedó patente al
afrontar otros dos problemas en cuanto al control de VLC.
o Cierre de la aplicación: al lanzar VLC por línea de comandos, aparece
en la pantalla una interfaz gráfica VLC con una barra de desplazamiento
que se mueve a medida que avanza el envío de los datos. Surgió el

problema de cerrar esa ventana al finalizar la transmisión RTP, ya que
incluso destruyendo el proceso lanzado con el método exec la ventana de
VLC permanecía. Esto provocaba que tras sucesivas transmisiones RTP
la pantalla estuviera llena de ventanas VLC inactivas.
El primer intento para solucionar esto fue el envío del mensaje
exit a la consola de control remoto, al recibir un mensaje TEARDOWN
del reproductor. Esta solución funcionaba bien por línea de comandos,
pero en el contexto de un programa java con el método exec no tenía
efecto alguno.
Un segundo intento fue el añadir a la lista de reproducción un
objeto especial llamado vlc:quit, que provoca el cierre de la aplicación.
Situado en la lista de reproducción a continuación del archivo que se
quiere transmitir, permitiría el cierre de la ventana al completarse la
transmisión. Nuevamente esta solución funcionaba bien en una consola
pero no en el programa. Se probó la posibilidad de detectar el fin de la
transmisión leyendo las trazas de la salida estándar y el subsiguiente
envío a la consola remota del mensaje goto vlc:quit que debería saltar a
este elemento y por consiguiente cerrar la ventana, pero resultaba
igualmente inútil. Finalmente se encontró una solución que funcionaba,
consistente en introducir la cadena vlc:quit como último parámetro al
lanzar VLC. Hay que hacer notar que según la documentación los
elementos de la lista de reproducción deben ir al principio de los
parámetros y no se hace referencia alguna a su inclusión al final.
o Salto a otro punto del archivo: Se ha implementado esta funcionalidad
mediante la consola de control remoto. Cuando se mueva la barra de
desplazamiento en el reproductor este enviará un mensaje PLAY
conteniendo el nuevo instante inicial de la transmisión. Entonces se le
envía a la consola de control el comando seek seguido del instante en
segundos. Desgraciadamente esto no siempre funciona, y no se ha
conseguido encontrar una solución para que lo haga siempre.
Aproximadamente el 25% de las veces que se envía este comando no se
obtiene ningún efecto, y entonces se produce una incoherencia porque la

arra de desplazamiento en el reproductor no coincide con los datos que
realmente se deberían estar transmitiendo. En todo caso se ha mantenido
su implementación ya que su uso no es obligatorio.
• Captura de las salidas: después de afrontar los problemas anteriores por fin se
consiguió ejecutar VLC desde la propia clase VlcRtpSender, pero entonces
apareció una nueva dificultad: pasado un determinado tiempo la transmisión se
bloqueaba sin motivo aparente. En este caso sí se obtuvo ayuda examinando la
documentación de la clase Runtime.
Como ya se ha mencionado la clase Runtime proporciona dos búferes
para la salida de datos y la salida de errores. Eventualmente estos búferes se
llenan y entonces la ejecución se bloquea. Esta circunstancia fue difícil de
detectar ya que ejecutando VLC por línea de comandos no se produce salida
alguna, sin embargo se comprobó que por alguna razón, si se lanzaba con la
clase Runtime sí se producían abundantes mensajes de trazas tanto por la salida
estándar como por la de error, aunque por esta última no se mostraba error
alguno si no otro tipo de trazas. Por lo tanto ha sido necesario crear procesos
independientes que leen constantemente de estas salidas para que nunca estén
vacías, incluyendo las salidas del proceso VLC y los mensajes devueltos por la
conexión Telnet.
Como conclusión y tras solventar o tratar de paliar estos problemas, la cadena
exacta que se usa con el método exec para arrancar VLC es (extendiendo los ejemplos
anteriores)
cmd.exe /c C:/VLC/vlc.exe C:/multimedia/video.mpg
:sout=#{dst=192.168.1.5;
port-video=5000;port-audio=5002} --extraintf=rc --rchost=localhost::5000
--rc-quiet vlc:quit
Hay que hacer notar que si bien se realizó un estudio previo del manejo de VLC
y la clase Runtime, la implementación efectiva ha requerido de muchas pruebas, alguna
de ellas siguiendo el método de prueba y error. Este no es un método de desarrollo muy
gratificante, sobre todo teniendo en cuenta que el logro de los objetivos propuestos no
estaba garantizado. Finalmente se ha obtenido un resultado que proporciona fiabilidad

en el envío de los datos RTP, con la salvedad de que el salto a diferentes puntos del
contenido no siempre funciona. Por otra parte, esta implementación no se puede
extrapolar a otros sistemas operativos al ser el comportamiento de la clase Runtime
diferente en cada uno de ellos.
3.5.7.6. Implementación de la clase VlcRtpSender
Una vez que se ha averiguado cómo enviar datos RTP mediante VLC desde un
programa Java, se ha procedido a la implementación de la clase VlcRtpSender, que es
la alternativa a la clase JmfRtpSender para el envío de datos, y al igual que esta
implementa la interfaz RtpSender. En esta implementación se han empleado las
soluciones expuestas anteriormente para solucionar los problemas que conlleva el uso
de VLC desde un programa java.
• Inicialización: El constructor recibe los mismos parámetros que la clase
JmfRtpSender, a excepción de la dirección de red local ya que VLC no necesita
de este dato. Desde el constructor se lanza un hilo de ejecución que será el
encargado de lanzar VLC y su consola de control, esto es necesario para que la
clase pueda atender posteriormente a las llamadas a sus métodos. Se usa el
método exec de la clase Runtime, de forma análoga al ejemplo anterior. Para
construir la ruta al fichero se usa el nombre de este concatenado con el directorio
donde se encuentran los archivos servidos, que ha sido pasado como parámetro.
Se tienen en cuenta los flags de las pistas de audio y vídeo para incluir o no los
campos port-video y port-audio. En cuanto al puerto para la consola de
control remoto, este habrá sido obtenido previamente mediante un método
interno que devuelve un puerto libre.
Una vez arrancado VLC se establece la conexión Telnet a su consola de
control. Después se guarda la referencia a su búfer de entrada en una variable
global de la clase, para que el resto de métodos puedan hacer uso de él. Por
último se crean los procesos auxiliares que leerán de las salidas del proceso VLC
y de la conexión Telnet para evitar que se produzcan bloqueos.

Cuando VLC se cierre por si mismo al haber terminado la transmisión de
datos, el estado de la transmisión volverá a Deallocated desde el estado en que
se encontrara y el hilo abierto inicialmente se destruirá.
• Método startTransmission: Primero se comprueba si el hilo de ejecución
creado en el constructor está activo, si no lo está se activa (esto solo se hará la
primera vez que se invoque este método). Después se comprueba si el estado de
la transmisión RTP es Paused, circunstancia que se dará si se ha invocado el
método pauseTransmission anteriormente. En caso afirmativo se continúa con
la transmisión enviando el mensaje pause a la consola de control remoto (los
mensajes pause alternan entre pausa y reproducción). La funcionalidad de pausa
sí funciona de forma fiable
Por último se envía a la consola de control remoto un mensaje seek
seguido del parámetro recibido por el método startTransmission, que es el
instante del contenido a partir del cual se desea enviar datos. En este caso existe
el problema de fiabilidad que ya se ha explicado. Finalmente el estado de la
transmisión pasa a Playing.
• Método pauseTransmission: Se envía a la consola de control un mensaje
pause para detener el envío de datos. Después se pasa el estado de la transmisión
a Paused. Previamente a estas acciones se comprueba que el estado de la
transmisión no sea Deallocated, y en caso de que sí lo sea se omiten todas ellas.
Esto es debido a que QuickTime envía un mensaje PAUSE cuando llega al final
de la reproducción, en tal caso se invocaría el método pauseTransmission
cuando el proceso VLC ya se habría cerrado por si solo, como consecuencia se
produciría un error al intentar enviar un mensaje a la consola de control ya que
la sesión Telnet ya no existirá.
• Método tearDownTransmission: El método se limita a comprobar si la
transmisión RTP está pausada, en dicho caso la transmisión continúa. Aunque el
cliente ya no estará esperando datos RTP, esto se hace para que VLC acabe
llegando al final de la transmisión y se cierre por si solo. De no tomar esta
medida el proceso VLC quedaría abierto indefinidamente.

3.5.8. Módulo VlcSdpGenerator
Aprovechando la experiencia adquirida en cuanto al manejo de VLC desde un
programa Java se procedió a implementar un módulo capaz de obtener una descripción
de archivo multimedia en formato SDP, aprovechando la posibilidad de usar VLC como
servidor de RTSP. El método consistirá en arrancar VLC con dicha configuración y
posteriormente enviarle una petición DESCRIBE sobre el archivo en cuestión, de forma
que VLC contestará con una respuesta cuyo cuerpo contendrá el SDP.
La implementación de este módulo implica la necesidad de resolver nuevamente
todos los problemas asociados al uso de VLC con la clase Runtime que se han descrito
en el capítulo sobre el módulo VlcRtpSender. Como estos problemas ya se conocen no
se va a volver a incidir sobre ellos. Hay que destacar que se ha conseguido que el
funcionamiento de este módulo sea robusto.
3.5.8.1. Ejecución de VLC como servidor RTSP
La ejecución de VLC en este caso requiere la utilización de los parámetros
adecuados para que funcione como servidor de RTSP. Igual que en el caso de la
generación de contenido RTP, al método exec se le pasa como primer parámetro el
comando cmd.exe que arranca una consola de línea de comandos, y a continuación la
ruta al ejecutable que arranca VLC junto con sus parámetros. A continuación se
enumeran cuales son estos parámetros:

• ttl: este parámetro junto con un valor numérico indica el número de saltos que
los paquetes de streaming podrán dar a través de la red, como realmente no se va
a usar VLC para recibir datos RTP este campo es irrelevante, pero es necesario
incluirlo.
• color: no se ha encontrado información en la documentación sobre este
parámetro pero aparece en los ejemplos y sin él se produce un error.
• I telnet: con este parámetro se indica que el servidor RTSP se controlará a
través de una conexión Telnet. A diferencia del módulo VlcRtpSender, en este
caso no es necesario lanzar una consola de control remoto si no que la conexión
Telnet se realiza directamente sobre el proceso VLC.
• telnet-password: con este parámetro y su valor se establece la clave de
autentificación para la conexión Telnet, que en este caso sí será necesaria. Lo
lógico sería pensar que se puede establecer cualquier clave, pero hay que
introducir videolan ya que si se introduce una diferente no será posteriormente
aceptada al intentar establecer la conexión.
• rtsp-host: finalmente este parámetro sirve para especificar la dirección IP y
puerto en donde el servidor esperará las conexiones con los clientes.
Experimentalmente se ha comprobado que hay que introducir la dirección
0.0.0.0, ya que si se intenta usar la dirección local 127.0.0.1 las conexiones no
llegarán a producirse. El puerto se puede elegir libremente.
En el siguiente ejemplo se muestra la cadena de comandos completa que se le pasa
al método exec. El número de puerto y el valor ttl son arbitrarios.
cmd.exe /c C:/VLC/vlc.exe -–ttl 1 --color –I telnet --telnetpassword
videolan --rtsp-host 0.0.0.0:10000

3.5.8.2. Implementación de la clase VlcSdpGenerator
Esta clase implementa la interfaz SdpGenerator, que consta de un solo método que
devuelve el SDP correspondiente a un archivo multimedia recibiendo su nombre como
parámetro.
• Inicialización: el constructor recibe como parámetro el directorio donde se
encuentran los archivos multimedia servidos. Se encarga de lanzar el hilo de
ejecución para el proceso VLC. Este hilo arranca VLC como servidor de RTSP
de la forma descrita en el apartado anterior, previamente se habrá obtenido un
puerto libre para el último parámetro, el valor de este puerto se almacena en una
variable global para su posterior uso.
Una vez arrancado VLC se establece la conexión por Telnet, el puerto
deberá ser el 4212, que es el puerto por defecto para el servidor RTSP de VLC.
Se guarda la referencia al búfer de escritura en una variable global, y se inicia la
sesión Telnet con el envío de la clave, videolan.
En conclusión, el resultado de este proceso de inicialización es el
servidor RTSP de VLC arrancado, el puerto en el que espera las peticiones RTSP
y una referencia al búfer para enviarle comandos a través de Telnet.
• Método getSdpContent: este método obtiene el SDP, recibiendo como
parámetro el nombre del archivo. Como el constructor almacenó el directorio
que contiene los archivos multimedia que se sirven, ya se dispone de la ruta
completa.
Para que el servidor RTSP de VLC pueda servir un archivo determinado,
es necesario configurar a tal efecto el servidor mediante el envío de comandos a

través de la interfaz Telnet, concretamente dos mensajes. El primero es una
cadena compuesta por new, seguido de un identificador arbitrario y por último
vod enabled. El segundo mensaje estará formado por setup, el identificador
anterior, input y finalmente la ruta completa al archivo. Este identificador deberá
estar incluido en la URL de los mensajes que los clientes envíen cuando hagan
referencia a este archivo. Por lo tanto, se usa como identificador el propio
nombre del archivo, y así los clientes se podrán referir a los archivos deseados
por su propio nombre. Así pues, para configurar un archivo llamado video.mpg
se le envían al servidor por Telnet estos dos mensajes:
new video.mpg vod enabled
setup video.mpg input c:/multimedia/video.mpg
Una vez configurado el archivo, se comprueba si se ha establecido una
conexión al puerto donde el servidor espera las peticiones RTSP. En caso
negativo se establece dicha conexión, esta conexión no se cerrará así que este
paso solamente se produce la primera vez que se invoca al método
getSdpContent. Se puede pensar que hubiera sido más lógico establecer esta
conexión al realizar las tareas de inicialización, en lugar de almacenar el puerto
y esperar hasta este momento. Esto no es posible ya que es necesario haber
configurado el servidor para servir al menos un archivo antes de intentar
conectarse con él, en caso contrario dicha conexión fallará.
En este momento ya es posible enviarle el mensaje RTSP al servidor de
VLC. Será un mensaje DESCRIBE cuya URL contendrá el nombre del archivo,
que es el identificador que se ha usado para configurar el servidor en los pasos
previos. De esta forma se simula ser un cliente RTSP. El mensaje se envía en
formato de texto plano (juego de caracteres UTF-8). El mensaje cumple
completamente con el protocolo RTSP, incluyendo el número de secuencia y la
línea en blanco.
DESCRIBE rtsp://127.0.0.1:10000/video.mpg RTSP/1.0
Cseq: 1

Inmediatamente después de enviar el mensaje se recibe la respuesta de
VLC, es la respuesta típica a una petición DESCRIBE. Lo que realmente
interesa es el cuerpo de la respuesta con el SDP, y la cabecera Content-Length
para conocer su tamaño y leerlo correctamente. Así pues se leen las sucesivas
cabeceras de la respuesta y cuando se detecta la cabecera Content-Length se
almacena su valor. Después se siguen descartando otras posibles cabeceras hasta
leer una línea en blanco. El contenido a partir de este punto será el SDP, y
conociendo el tamaño no hay más que leer los siguientes caracteres necesarios.
El método getSdpContent devuelve un objeto de la clase SdpContent,
que contiene el SDP, la URL de control de vídeo y la URL de control de audio.
Se buscan estas URLs en el SDP y se crea el objeto SdpContent con estos tres
elementos. Para buscar las URLs hay que buscar las cabeceras de audio y video
en el SDP m=video, m=audio y a continuación las líneas con las URL, que
empiezan por a=control. Si no existe una de las pistas su valor en el objeto será
null. Finalmente el método devuelve este objeto.
Por último hay que tener en cuenta que es posible que el archivo pedido
no exista. En este caso VLC devuelve un SDP incompleto que solo contiene las
primeras líneas obligatorias pero ninguna información sobre las pistas. Esta
circunstancia se comprueba, y en este caso el método devuelve una excepción.
Esta excepción es capturada por la clase RequestHandler, que en tal caso
informará al cliente que el archivo solicitado no existe.

3.5.9. Módulo FileSdpGenerator
Este módulo constituye la alternativa al módulo VlcSdpGenerator e
implementa la interfaz SdpGenerator al igual que este. Como se mencionó en el
capítulo sobre la metodología de desarrollo este módulo se implementó durante las
primeras etapas, permitiendo al servidor usar SDPs almacenados en disco y así poder
realizar pruebas. Desde el punto de vista conceptual no aporta gran contenido al
proyecto y es el de implementación más sencilla, pero puede resultar útil cuando el
módulo VlcSdpGenerator no es válido, por ejemplo si se quiere servir un archivo cuyo
formato VLC no es capaz de manejar.
• Inicialización: El constructor de la clase FileSdpGenerator recibe como
parámetro la ruta al directorio donde se encuentran los archivos SDP, y lo
almacena.
• Método getSdpContent: este método leerá el contenido del archivo SDP y
creará un objeto SdpContent de forma análoga a la descrita en el capítulo sobre
la clase VlcSdpGenerator. La única decisión de diseño relevante es elegir una
convención para el nombre de los archivos SDP, de forma que se sepa qué
archivo SDP corresponde al archivo multimedia cuyo nombre se ha pasado
como parámetro al método. Se ha escogido esta solución: el nombre del archivo
SDP será el nombre del archivo multimedia concatenado con su extensión
original, y nueva extensión será sdp. Por ejemplo, si se recibe como parámetro el
nombre multimedia.mpg, se intentará leer el SDP del archivo
multimediampg.sdp. Siguiendo esta convención es imposible que dos archivos
multimedia diferentes tengan un archivo SDP con el mismo nombre.
Si no se encuentra el archivo SDP, se eleva una excepción de igual
forma que en la clase VlcSdpGenerator.

4. Conclusiones y líneas futuras
4.1. Conclusiones
Se ha conseguido implementar el servidor de streaming mediante protocolo
RTSP. Este servidor es capaz de servir vídeos almacenados localmente y es compatible
con los reproductores VLC y QuickTime. Este servidor se puede configurar al
arrancarlo de forma que use diferentes módulos a la hora de obtener las descripciones de
los contenidos multimedia y envío de los datos por protocolo RTP. Por lo tanto, el
objetivo principal del proyecto se ha cubierto.
Durante la etapa inicial se realizó un estudio de las tecnologías actuales
relacionadas con el streaming, y la conclusión más importante es que existe una gran
variedad de tecnologías y formatos, y además la rápida evolución en esta área provoca
que sigan apareciendo nuevos elementos a tener en cuenta a gran velocidad. Aunque el
streaming es conceptualmente sencillo, esta variedad de tecnologías dificultan las tareas
de desarrollo, ya que es necesario estudiar sus características y decantarse por algunas
de ellas.
Otro factor a tener en cuenta son las demandas en cuanto a robustez y
rendimiento. El streaming está estrechamente relacionado con el tiempo, la transmisión
de contenidos multimedia requiere de gran ancho de banda, capacidad de proceso e
implementación eficiente. Las ralentizaciones o defectos en general durante la
reproducción no son admisibles por el usuario actual. En este proyecto se han
mencionado algunos problemas como la pérdida de sincronismo entre el audio y el
video en JMF o la falta de robustez de VLC al usarlo desde un programa Java. Estos
problemas no serían tolerables en un entorno con usuarios reales. Prueba de la dificultad
de alcanzar un rendimiento alto es la existencia de productos comerciales que ofrecen

una funcionalidad similar a la de este proyecto, por los que hay que pagar dinero. Este
proyecto ofrece la ventaja de no estar atado a ninguna tecnología de streaming en
concreto debido a su estructura basada en módulos, lo que podría permitir su mejora.
En cuanto al protocolo RTSP, se ha implementado la funcionalidad necesaria
para el cumplimiento de los objetivos. Se han hecho patentes las ventajas de un
protocolo basado en texto a la hora de comprenderlo y hacer uso de él. Un protocolo
textual no destaca por su eficiencia en cuanto a demanda de procesamiento, pero en este
caso ese factor es irrelevante por el pequeño tamaño de los mensajes y su escasa
frecuencia.
También resalta la importancia de seguir los estándares a la hora de implementar
los protocolos. Precisamente el objetivo de la estandarización es la puesta en común de
las características del protocolo, para que los diferentes productos puedan interaccionar
entre ellos. Mientras que ha sido posible compatibilizar el servidor con los
reproductores VLC y QuickTime (este último usa algunas cabeceras no descritas en la
especificación pero es posible ignorarlas), no ha sido así con Windows Media Player.
Esto es debido al amplio uso de cabeceras no estándar, que un servidor debe ser capaz
de comprender para interaccionar con este reproductor. Seguramente esto obedezca a
motivaciones de índole comercial, siguiendo la tradición de Microsoft con otros
productos como su navegador Internet Explorer. El desarrollo del software y su
difusión se ven perjudicados por estas prácticas.
En cuanto a este proyecto, para contribuir a la difusión de las tecnologías de
streaming se ha optado por liberar el código como software libre con licencia GPL.
4.2. Líneas futuras
En cuanto al protocolo RTSP, las posibilidades de ampliación son prácticamente
ilimitadas. Por una parte se puede ampliar su implementación añadiendo las
funcionalidades que ofrece y no han sido tenidas en cuenta en este proyecto. En el
capítulo sobre la descripción de los mensajes RTSP se habló del mensaje RECORD que

permite al servidor realizar una grabación, si está conectado a algún dispositivo de
captura. También se habló del mensaje REDIRECT que permitiría indicar al cliente el
cambio de localización del servidor, por ejemplo esto se podría usar si se tuvieran varias
instancias del servidor arrancadas en diferentes sitios. Los mensajes
GET_PARAMETER y SET_PARAMETER permiten en general establecer valores y
solicitar su contenido, su implementación es abierta y se podría añadir alguna otra
funcionalidad que se considerara interesante. Algunos servidores comerciales, por
ejemplo, envían un mensaje SET_PARAMETER al final de la sesión con estadísticas
sobre la transmisión.
Además de estos mensajes la especificación del protocolo describe otras
cabeceras, así como mensajes de estado en las respuestas para informar de
circunstancias sucedidas en el servidor. También se podrían mejorar algunas de las
cabeceras que se han usado. Por ejemplo la implementación de la cabecera Range está
preparada para reconocer los intervalos de tiempo expresados en segundos, pero es
posible usar otros formatos. Una característica especialmente interesante podría ser el
servicio de contenidos multimedia en vivo, conectando el servidor a algún tipo de
dispositivo de entrada. Por último, recuérdese que RTSP es un protocolo extensible, así
que se podría aumentar la funcionalidad incluso más allá de lo especificado en su RFC.
En cuanto al envío de datos se podría ampliar el servidor mediante la
implementación de nuevos módulos que usen otras tecnologías, por ejemplo alguna de
las descritas en esta memoria y de las cuales no se han hecho uso. Bastaría con
programar clases que cumplan la interfaz RtpSender, que se ha establecido como
patrón para la funcionalidad que los generadores de datos RTP deben cumplir. Tal vez
sería posible alcanzar un mejor rendimiento con alguna otra herramienta, superando los
problemas aparecidos con JMF y VLC. Además esto posibilitaría actualizar el servidor,
ya que muy probablemente en el futuro aparezcan nuevos formatos multimedia, y sería
una manera de evitar que el servidor se quedara obsoleto.

Bibliografía
[1]