AgoraRed-2: Aplicaciones multimedia de gestión cooperativa

Transcripción

1 1 AgoraRed-2: Aplicaciones multimedia de gestión cooperativa Miguel Ángel Melón Pérez, Carlos Vecino de Casas y José Luis González Sánchez Resumen El proyecto AgoraRed2 es la continuación del Proyecto Final de Carrera desarrollado por David Cortés, titulado AgoraRed, centrado en las comunicaciones multimedia sobre redes cooperativas. El proyecto se basó en el estudio del protocolo RTP/RTCP y sus implicaciones en las redes de datos, así como en el estudio de las aplicaciones MBone y QBone. Para ello se desarrolló sobre el sistema operativo GNU/LinEx la herramienta VLinEx, implementada en Java, que permite la comunicación multicasting entre diferentes ordenadores dentro de una red local (isla multicast) y, además, transmite al resto de islas a través de túneles. AgoraRed2 recoge el testigo de su predecesor y porta el código interpretado a C/C++, añadiendo además una serie de mejoras tanto de eficiencia como de codecs soportados. I. INTRODUCCIÓN Las tecnologías actuales han conseguido que los diferentes sectores de las telecomunicaciones, como los datos, la radio y la televisión se fusionen en uno solo. Esta convergencia está desarrollándose a escala mundial y está consiguiendo cambiar los hábitos de comunicación de las personas, así como las especificaciones y los dispositivos. En el centro de dicho proceso hay un ente común a todos, formando la columna vertebral del proceso, las redes IP. Cada vez aumenta más el uso de sesiones, presentaciones o clases online y se hacen necesarias nuevas herramientas que faciliten el manejo y den rapidez a la nueva forma de comunicarse. Por ello, se necesita hacer accesible esta tecnología a toda clase de personas, sean o no usuarios expertos de ordenadores y sin que éstos tengan que sufrir cambios innecesarios en las rutinas ya aprendidas. Al tratar este proyecto del diseño de una aplicación compuesta por elementos multimedia nos centraremos en ellos, ya que a medida que ha ido aumentando la potencia de los equipos, esa potencia se ha destinado a la ejecución de aplicaciones multimedia más complejas en el PC. En la actualidad, las aplicaciones multimedia se diseñan para usarse en la red. Las aplicaciones de transmisiones de sucesos de audio y vídeo grabados o en directo son sólo dos de las muchas aplicaciones que se combinan en redes y tecnologías multimedia. No obstante, la transferencia completa de archivos pesados hace que los tiempos de espera sean demasiado largos para lograr ver y escuchar en tiempo real. Las redes actuales están diseñadas para transmitir datos de forma fiable mediante conexiones punto a punto. El uso de estas nuevas tecnologías multimedia requiere nuevas formas de transmitir la información en la red. La primera regla que hay que tener en cuenta es que la transmisión de audio y vídeo, para retransmisiones en tiempo real, no tolera retardos en la entrega. Una red cuya tarea básica sea mover archivos de un lugar a otro puede transmitir paquetes de datos a una velocidad variable; si parte de un archivo llega lentamente o desfasado, no pasa nada. En cambio, en una transmisión multimedia, es necesario que los paquetes de datos lleguen al cliente a tiempo y en el orden correcto. Los protocolos de tiempo real y las garantías de calidad de servicio (QoS) presentes en la red abordan este problema. En segundo lugar, hay que tener muy presente la gran cantidad de datos que usan las transmisiones multimedia, es decir, se transmiten muchos datos a través de la red, con lo que se utiliza gran cantidad del ancho de banda de la misma. La forma idónea para enviar archivos de tipo multimedia sería generar un flujo de vídeo que fuera desde un servidor hasta el cliente, que previamente tendría que haber solicitado al servidor el vídeo. Acto seguido, el cliente debería reproducir el flujo de vídeo entrante en tiempo real según fuera recibiendo los datos (streaming). Hay que destacar que el vídeo transmitido sobre redes de paquetes que funcionan al mejor esfuerzo tiene ciertas complicaciones debidas al desconocimiento de los diferentes anchos de banda, sus variaciones en las diferentes redes, demoras, pérdidas de paquetes y otros, como compartir los recursos de la red de manera eficiente y el desarrollo de comunicación entre un punto y varios. Hoy en día ya existen aplicaciones que dan servicios de streaming de vídeo, videoconferencia y presentaciones en directo, pero con una calidad aceptable dependiendo sólo del uso al que se dedique. Por otra parte, hay empresas que ofrecen servicios de streaming de videos, pero con unos costes demasiados elevados. El diseño de la aplicación se compone de dos partes, una dedicada al tratamiento de la señal de vídeo y otra a los protocolos de establecimiento de sesiones y transporte en tiempo real. En la parte del vídeo, el problema que hay es la compresión. Si se quiere calidad, va en contraposición del volumen que ocupa el fichero o stream de vídeo, y como se está hablando de una difusión de datos a través de una red, existen limitaciones de ancho de banda. Por eso es importante la elección de los codecs, ya que son los encargados de que haya más o menos compresión y calidad. Aunque hoy en día hay codecs que, teniendo una alta tasa de compresión, generan un vídeo de una excelente calidad. Por otro lado está el problema de los protocolos, que están evolucionando continuamente, y la industria no se pone de acuerdo en el uso de un único estándar, como puede ocurrir con SIP y H.323.

2 2 II. II-A. ITU-T H.323 ESTADO DEL ARTE PROTOCOLOS DE SESIÓN H.323 es una norma creada por la ITU-T en Nació para dar soporte a comunicaciones de audio, vídeo y datos a través de la red IP (sin garantizar servicios QoS). También forma parte del estándar de Audiovisual and Multimedia Systems, the series H.32X, donde se define la transmisión multimedia a través de diferentes tipos de medios como: H.320: Comunicaciones multimedia sobre RDSI. H.310 y H.321: Comunicaciones multimedia sobre ATM. H.324: Comunicaciones multimedia sobre RTC. H.323: Comunicaciones multimedia sobre IP. Aunque H.323 es uno de los pilares de la telefonía sobre IP y sigue acaparando mucha cuota de mercado, a continuación se van exponer varios motivos por los que su uso puede empezar a desaparecer: Es muy específico para telefonía IP, no intenta abrirse a las fronteras de la mensajería o servicios más avanzados como video-mail y buzones de voz. Es un protocolo muy cerrado, sólo permite el uso de codecs estandarizados por el ITU-T. Dejando de lado a los nuevos tipos de compresión de vídeo actuales, por lo que sería incompatible con el sistema que se intentará desarrollar. Los estándares que definen H.323 no son públicos, por lo que hay que pagar licencias al ITU-T. Todos los flujos multimedia van sobre RTP o RTCP. No se permiten más protocolos de transporte, por lo tanto habría que olvidarse de RTSP, por ejemplo. Es un protocolo demasiado complejo. Nació con la idea de ser muy eficiente, pero esto complica, por ejemplo, la compatibilidad con diferentes terminales. No menciona nada de localización de usuarios. De hecho, el direccionamiento se basa en el formato de direcciones E.164 1, lo cual está muy bien si nos encontramos en una red privada y tenemos acceso a cierta infraestructura (como gatekeepers y gateways). Pero si no disponemos de esas facilidades, deberemos reconocer al extremo por su dirección de red y de transporte. En H.323 sobre Internet (o sobre una red IP genérica) implica conocer la dirección IP y el puerto TCP del terminal al que queremos llamar, lo que es prácticamente imposible con el uso de las direcciones IP dinámicas y redes con firewalls. Éste es el gran punto débil de H.323. Los mensajes de señalización de H.323 están en formato binario (ASN.1). Esto en la actualidad no tiene sentido, pero conlleva una gran dificultad: hace terriblemente difícil el proceso de depurado. Por tanto, para desarrollar una aplicación que haga uso de H.323 se necesitan herramientas de codificación y decodificación de mensajes para poder estudiar con exactitud el protocolo. 1 E.164: recomendación de la Unión Internacional de Telecomunicaciones (UIT) que asigna a cada país un código numérico (código de país) usado para las llamadas internacionales. H.323 es totalmente incompatible con cualquier tipo de filtrado (no puede atravesar firewalls) o mapeo de direcciones (no puede acceder a una red privada enmascarada con NAT 2 ). II-A1. Arquitectura H.323: H.323 define los requisitos que el sistema de comunicación debe tener para realizar transmisiones multimedia sobre redes de paquetes (PBN, Packet Based Network) que pueden no proporcionar una calidad de servicio (QoS, Quality Of Sevice) garantizada. Las redes de paquetes se pueden clasificar en: redes locales (LAN), redes empresariales, redes metropolitanas (MAN), intranet, e Internet. Estas redes también incluyen conexiones obtenidas por marcación o conexiones punto-a-punto sobre la red pública de telefonía o RDSI. El sistema H.323 está compuesto de Terminales, Pasarelas (Gateway), Gatekeepers y Unidades de Control Multipunto (MCU) [1]. Figura 1. Interfuncionamiento de los terminales H.323 II-A1a. Terminal: Un terminal H.323 [2] es un dispositivo de usuario final que facilita las comunicaciones bidireccionales en tiempo real con otro terminal, pasarela o MCU. El terminal puede dar soporte de audio, vídeo y datos. La figura que se mostrará a continuación muestra un diagrama de un equipo terminal que debe de contener un sistema de control, el codec de audio y la interfaz de red. Los codecs de vídeo y las aplicaciones de datos de usuario son opcionales. 2 NAT (Network Address Translation - Traducción de Dirección de Red): es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que se asignan mutuamente direcciones incompatibles. Consiste en convertir en tiempo real las direcciones utilizadas en los paquetes transportados.

3 3 con uno o varios participantes. Estas sesiones incluyen llamadas de teléfono a través de Internet, distribución de contenidos multimedia y conferencias. En la siguiente imagen podemos ver dónde se encuentra SIP dentro de la arquitectura multimedia de protocolos propuestos por la IETF. Lógicamente se encuentra al mismo nivel que H.323: Figura 2. Diagrama de un equipo terminal II-A1b. Gateway: Los gateways o pasarelas son dispositivos muy importantes para conseguir la integración de H.323 en una red. Proporciona las comunicaciones entre terminales que soportan H.323 y otros terminales de otras redes, realizando funciones de traductor entre ambas redes. II-A1c. Gatekeeper: Otro dispositivo importante es el gatekeeper o controlador de acceso (esta unidad es opcional), que proporciona servicio de control de llamada a los puntos finales. En las redes H.323 puede haber más de un gatekeeper, que interaccionarán entre sí. Cada zona de la red tiene que tener al menos un gatekeeper, y las funciones que deben prestar son las siguientes: Conversión de dirección: El gatekeeper traduce el alias a dirección IP o a dirección E.164, necesarios para el establecimiento de las comunicaciones a través de una tabla de traducciones. Control de admisiones: El controlador de acceso gestiona el establecimiento de llamadas mediante mensajes Admission Request/Admission Confirm/Admision Reject (ARQ/ACF/ARJ). Control de ancho de banda: Controla el número de usuarios simultáneos que el sistema puede soportar con los siguientes mensajes: Bandwidth Request/Bandwidth Confirm/Bandwidth Reject (BRQ/BRJ/BCF). Gestión de zona: Coordinación de acciones entre los distintos dispositivos que se encuentran dentro de una misma zona de terminales registrados, gateways y MCU. Control de señalización (opcional): Usa el modelo Gatekeeper Router Call Signaling (GKRCS). II-A1d. Unidad de Control Multipunto (MCU): La Unidad de Control Multipunto (MCU) soporta conferencias entre tres o más terminales y gateways en una conferencia multipunto. La MCU también puede negociar las capacidades de ancho de banda de los terminales de cara a una conferencia y garantizar una comunicación óptima. II-B. SIP Según el RFC 2543, el Protocolo de Inicio de Sesiones (SIP, Session Initiation Protocol) es un protocolo de control de nivel de aplicación para crear, modificar y terminar sesiones Figura 3. Arquitectura multimedia de la IETF SIP es únicamente un protocolo para introducir en el modelo de Internet el nivel de sesión que le falta en comparación con el modelo OSI. En dicho modelo (OSI), el nivel de sesión realiza las siguientes funciones: Gestión de diálogos Gestión de la sincronización Intercambio de datos Gestión de actividades Notificación de excepciones Además, presenta las siguientes características: Establece la comunicación entre dos aplicaciones junto con unas reglas para el diálogo. Se trata de un nivel orientado a conexión: Establecimiento, transferencia de datos y liberación de sesiones. Permite una liberación de las sesiones de forma ordenada, impidiendo la pérdida de datos. Suministra primitivas a los niveles superiores (en este caso, al de aplicación) para establecer sesiones. SIP cumple perfectamente con los requerimientos de un protocolo de nivel de sesión, y por lo tanto puede realizar esta función. Además, SIP puede usarse perfectamente para transmitir información en forma de ficheros, tanto para el acceso a servicios web como para todas las aplicaciones que además de transmitir datos requieran un nivel de abstracción superior como en aplicaciones de videoconferencia. Desde sus comienzos, SIP ha estado muy relacionado con la transmisión de información multimedia, y se ha enfocado hacia la señalización: SIP será el encargado de gestionar sesiones entre dos extremos SIP y de permitir las negociaciones de flujos multimedia, transportando un protocolo de descripción de sesiones, para lo que se utiliza SDP. La relación que existe entre SIP y SDP es arbitraria. Sin embargo, forman una pareja perfecta para soportar aplicaciones tales como teleconferencias, videoconferencias simples y mejoradas (con posibilidad de incorporar buzones de audio y vídeo) y todo tipo de transmisiones de información en tiempo

4 4 real que requieran uno ó más flujos de transporte; la forma de asociar dichos flujos usados será mediante una sesión SIP. Actualmente se está trabajando en desarrollar métodos que den soporte a funciones básicas de mensajería instantánea, como: Localización de usuarios en base a direcciones globales, independientes de la dirección de transporte. Detección de presencia o ausencia de usuarios. Transmisión de información en forma de mensajes (que podrán estar codificados en texto plano, en HTML o XML. Es más, será posible que contengan cualquier tipo MIME válido). Compatibilidad con CPIM, el estándar del IETF para la mensajería. que más ha sorprendido a los autores de este proyecto: comparándola con las implementadas por otros sistemas (H.323, ICQ y otros sistemas de señalización y mensajería) se trata de un diseño potente y escalable. A grandes rasgos, consiste en extender el mejor sistema de localización existente hasta la fecha: el del correo electrónico. Por último, veremos en la siguiente figura la relación de SIP con protocolos como SDP, RTP y RTCP, así como la forma en que podemos dividir a este protocolo, en un núcleo que se encarga de las transacciones y un controlador de sesiones: SIP es un protocolo que continúa en desarrollo: en mayo del 2000 apareció la versión 2.0, pero hasta la fecha ha sido sometido a diez revisiones hasta la publicación del RFC 2543, con lo que se puede ver lo novedoso del protocolo. Está siendo desarrollado por el IETF (Internet Engineering Task Force) y se enmarca perfectamente en el modelo de Internet. Es más, tanto a nivel de uso como de implementación, guarda muchas relaciones con protocolos de gran éxito y mayor difusión (como HTTP o el sistema de correo electrónico). Se basa en un modelo cliente/servidor. Los mensajes SIP están codificados como texto plano. La definición de dichos mensajes se expresa mediante Augmented Backus Naus Form (BNF aumentado o ABNF) [3]. La transmisión de los mensajes en un diálogo se agrupa en forma de transacciones formadas por peticiones y respuestas a esas peticiones (modelo request/response). El modelo de localización hace uso del sistema de DNS y se basa en la delegación de responsabilidades a los dominios. SIP posee, a grandes rasgos, tres características que hacen que haya un creciente interés en la industria y en la comunidad tecnológica: Generalidad: Se pueden acceder a servicios web mediante el uso de SOAP 3 sobre SIP, lo que proporciona el concepto de estado, del que carece HTTP (que es el protocolo tradicional para servicios web usando SOAP). También podemos realizar una llamada de audio contra otro usuario SIP, o podemos mandarle un mensaje de texto junto con una imagen. SIP no especifica la aplicación: toma las funcionalidades de nivel de transporte y proporciona primitivas a los niveles superiores, implementando una capa de sesión genérica. Simplicidad: SIP pertenece al modelo Internet, y como tal, busca realizar la mayor cantidad posible de operaciones de la forma más sencilla. Mediante el uso de texto plano para la señalización, el ancho de banda usado aumenta, pero también se facilita en gran mediada los procesos de depurado del protocolo. Localización global de usuarios: De todas las características de SIP, la localización de usuarios ha sido la 3 SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Figura 4. Pila de SIP. Características y relaciones Hecha esta introducción sobre SIP, ahora se pasará a estudiar más en profundidad la arquitectura, los elementos y mensajes que necesita SIP para su correcto funcionamiento. II-B1. Componentes de la arquitectura SIP: La base de la arquitectura de servicios SIP está constituida de servidores de aplicación, servidores de media y de S-CSCF (Serving Call Session Control Function). El Servidor de Aplicación SIP ejecuta servicios (ejemplo: Push To Talk, Presence, Prepaid, Instant messaging, etc.) y puede influir el desempeño de la sesión a petición del servicio. El servidor de aplicación corresponde al SCP de la Red Inteligente. El Servidor de Media SIP (Multimedia Resource Function o MRF) es el encargado del estrablecimiento de las conferencias multimedia, toca anuncios vocales o multimedia y recopila información del usuario. Se trata de la evolución de la entidad Specialized Resource Point o SRP en el mundo multimedia. El Servidor de Llamada SIP (Proxy Server) tiene el objetivo de ser el punto desde el que los clientes puedan requerir los servicios de SIP. Dispone del perfil de servicio del abonado que le indica los servicios suscritos por el abonado y bajo qué condiciones invocar estos servicios. Corresponde al SSP de la arquitectura Red Inteligente. II-B2. Mensajes SIP: SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP. Los UAC realizan las peticiones y los UAS retornan respuestas a las peticiones de los clientes.

5 5 SIP define la comunicación a través de dos tipos de mensajes. Las solicitudes (métodos) y las respuestas (códigos de estado) emplean el formato de mensaje genérico establecido en el RFC 2822, que consiste en una línea inicial seguida de uno o más campos de cabecera (headers), una línea vacía que indica el final de las cabeceras, y por último, el cuerpo del mensaje, que es opcional. II-B2a. Métodos SIP: Las peticiones SIP son diferenciadas por la primera línea del mensaje, llamada Request-Line, que contiene el nombre del método, el identificador del destinatario de la petición(request-uri) y la versión del protocolo SIP. Además, este protocolo dispone de seis métodos básicos (definidos en el Request For Comments 2543 [4]) que describen las peticiones de los clientes: INVITE: ACK: OPTION: Permite invitar a un usuario o servicio para participar en una sesión o para modificar parámetros en una sesión ya existente. Confirma el establecimiento de una sesión. Solicita información sobre las capacidades de un servidor. BYE: Indica la terminación de una sesión. CANCEL: Cancela una petición pendiente. REGISTER: Registrar al User Agent. No obstante, existen otros métodos adicionales que pueden ser utilizados, publicados en otros RFCs, como los métodos INFO, SUBSCRIBER, etc. Figura 5. Ejemplo de petición II-C. PROTOCOLOS DE TRANSPORTE EN TIEMPO REAL RTP RTP (Real-time Transport Protocol) proporciona funciones de transporte punto a punto para aplicaciones que necesiten realizar transmisiones de datos en tiempo real. Los desarrolladores de RTP fueron los integrantes del grupo de trabajo AVT (Audio-Video Transport), un grupo de la Internet Engineering Task Force (IETF). La primera especificación de RTP fue aprobada el 22 de noviembre de 1995, dando lugar a su publicación en el RFC La primera implementación del protocolo vino de la mano de Netscape, quien a principios de 1996 anunció un Framework para la transmisión de audio y vídeo en tiempo real, basado en RTP. En la actualidad, RTP se ha convertido en el protocolo estándar de Internet para el transporte de datos en tiempo real, tanto de datos de audio como de vídeo. Puede ser usado tanto para medios bajo demanda como para servicios interactivos, como VoIP. Con la especificación publicada en el RFC 1889, RTP se revisó y cambiaron ligeramente algunos algoritmos y aspectos del protocolo. La nueva revisión fue publicada en el RFC 3550, así como un sinfín de perfiles para optimizar el funcionamiento del protocolo, adaptándolo a cualquier tipo de tráfico. RTP intenta dar soporte a las aplicaciones para que puedan controlar las conexiones establecidas en tiempo real, permitiendo a éstas poder ofrecer una cierta calidad de servicio. Hay que dejar claro que RTP no proporciona QoS al tráfico transmitido en tiempo real, sino que la función de RTP es dotar a las aplicaciones de una cierta inteligencia para que puedan optimizar la transmisión de contenidos en tiempo real, adaptándola a las características y al estado de la red. El diseño de RTP se realizó para que pueda cumplir con su cometido, independientemente de la capa de transporte. Esto significa que RTP se utiliza como una capa intermedia entre la aplicación y el transporte. Por esta independencia con la capa de transporte, se pueden usar diferentes protocolos para transmitir paquetes RTP, como por ejemplo UDP, el más utilizado, debido a que no ofrece ningún método de control específico para acceso a contenidos estáticos y ofrece una tasa de transmisión más elevada que TCP. Sin embargo, hay que señalar que RTP es un protocolo deliberadamente incompleto. Esto se ha hecho así para que cada aplicación pueda modificar ciertas funciones, dependiendo de la naturaleza de lo transmitido, así como las prestaciones que se pretenden obtener. Por tanto, la especificaión de RTP es muy general y necesita de otros documentos para completarla y poder hacer uso de él en una aplicación específica: Perfil: En este documento se definen el conjunto de tipos de payload, como por ejemplo codificaciones de audio. Además, en el perfil se pueden definir extensiones y modificaciones del protocolo RTP específicas de la aplicación que lo requiera. Existe una gran cantidad de perfiles específicos de la transmisión de distintos tipos de datos, siendo el más común el especificado en el RFC 3351, el cual describe las reglas para manejar comunicaciones de audio y vídeo con muy bajo nivel de control. Formato del payload: En este documento se define cómo tiene que ser transportado por un RTP un tipo particular de payload. Normalmente nos referimos a RTP como si se tratase de un único protocolo. No obstante, RTP está formado por dos componentes estrechamente ligados que estudiaremos en profundidad más adelante: RTP Data Transfer Protocol (RDTP). Este protocolo es el que se encarga del transporte de los datos en tiempo real. RTP Control Protocol (RTCP). RTCP cumple una importante función: se encarga de generar información de control de todos los participantes de una sesión RTP. Las aplicaciones pueden recopilar la información necesaria de todas las fuentes con el fin de monitorizar la calidad de servicio y permitir así tomar las decisiones pertinentes para mantener un cierto grado de calidad de servicio.

6 6 En el siguiente esquema se muestran todos los componentes RTP, así como las capas subyacentes: Figura 6. Componentes RTP II-D. RTCP La función del protocolo RTCP (RTP Control Protocol) es la difusión de mensajes de control para que se pueda establecer una comunicación con garantías mediante RTP. Los mensajes de RTCP se utilizan para que las aplicaciones puedan conocer el estado de la comunicación en todos los puntos finales de la sesión multimedia, pudiendo adaptar lo transmitido para que la calidad de servicio ofrecida sea la conveniente. Por último, y gracias a RTCP, es posible la sincronización de varios streams pertenecientes a distintas sesiones RTP. II-D1. Funciones de RTCP: Al igual que ocurría con el protocolo RTP, RTCP también puede ser modificado para adaptarse a aplicaciones concretas. Se pueden crear diferentes tipos de paquetes RTCP independientes a la especificación del protocolo RTP, pero todas las implementaciones de RTCP tienen que cumplir las siguientes cuatro funciones: La función principal de RTCP es proporcionar feedback entre los distintos componentes de una sesión multimedia. Esto permite monitorizar la calidad de servicio de la distribución de los datos en los clientes de las aplicaciones. Para ello, tanto los emisores como los receptores generan paquetes con información relativa al estado de la comunicación, como número de paquetes perdidos, retardos y niveles de jitter, por ejemplo. Esta función se lleva a cabo mediante dos tipos de paquetes RTCP (sender report y receiver report), que se verán más adelante. Si la red utiliza un mecanismo de distribución multicast, estos mensajes pueden llegar a aplicaciones conocidas como monitores. Los monitores podrán controlar el estado de las comunicaciones y avisar a las aplicaciones para que tomen las medidas oportunas. De esta forma se puede liberar a las aplicaciones de realizar esta tarea. RTCP es el encargado de transportar el nombre canónico (CNAME) de las fuentes RTP. Éste es un identificador persistente a nivel de transporte. Su existencia es necesaria, debido a que los identificadores SSRC pueden sufrir variaciones en presencia de colisiones, así como por reinicio en las aplicaciones. Los receptores necesitan tener un CNAME asociado a cada fuente para poder identificar a los participantes. El SSRC identifica una sesión RTP, por lo tanto, una fuente que esté transmitiendo, por ejemplo, audio y vídeo en II-E. diferentes sesiones RTP, estará utilizando dos SSRC diferentes. Para poder sincronizar estas dos sesiones en la recepción, la aplicación receptora necesita el CNAME de la fuente para poder asociar las distintas sesiones RTP de una única fuente. De esta forma, RTCP permite hacer una asociación entre uno o varios SSRC y un CNAME. RTCP debe controlar la tasa de envío de los paquetes. De esta forma, es posible obtener un protocolo escalable, soportando gran número de participantes en una sesión. Debido a que todos los participantes tienen que enviar mensajes de control (tanto los receptores como los emisores), cada aplicación puede conocer el número total de participantes. Este número se debe utilizar para controlar la tasa de envío de paquetes RTCP. Esta última función es opcional, pues se trata de una mínima información de control. Gracias al envío de paquetes que contienen información de los participantes, las aplicaciones pueden, por ejemplo, mostrar sus datos por pantalla. No obstante, el protocolo no está especificado para el manejo y gestión de este tipo de información, ya que para ello existen protocolos de más alto nivel, como SIP o H.323. RTSP El Real-Time Streaming Protocol (RTSP) o Protocolo de Streaming en Tiempo Real [5] establece y controla uno o varios flujos sincronizados tanto de vídeo como de audio. RTSP actúa como un control de red remoto para servicios multimedia. Según el grupo Internet Engineering Task Force, no hay noción de conexión RTSP. En cambio, el servidor mantiene la sesión etiquetada por un identificador. En la mayoría de los casos, RTSP usa TCP para gestionar los datos de control del reproductor y UDP para los datos de audio y vídeo, aunque también puede usar TCP en caso de que sea necesario. Durante la sesión RTSP el cliente puede abrir otras conexiones de transporte con el servidor para afrontar la conexión RTSP. En una conexión RTSP el servidor mantiene una sesión continua. Durante la sesión el cliente envía y recibe múltiples peticiones RTSP al servidor. Figura 7. Uso de los protocolos TCP y UDP en RTSP El mecanismo de transporte que suele usar RTSP es RTP (Real-time Transport Protocol), aunque las operaciones en RTSP no dependen del protocolo de transporte usado. La sintaxis y operaciones de RTSP son similares a las de HTTP, por lo que una gran parte de las funcionalidades y extensiones de HTTP pueden ser añadidos a este protocolo. No obstante, posee algunas diferencias notables con HTTP: RTSP tiene un protocolo de identificación diferente e introduce un gran número de nuevos métodos.

7 7 Un servidor RTSP necesita mantener su estado, lo que es totalmente opuesto a HTTP, que no tiene estado. Un cliente y un servidor RTSP pueden realizar peticiones. RTSP está definido para usar la ISO Los datos son transportados con un protocolo diferente. Este protocolo soporta las siguientes operaciones: Recuperación de datos multimedia de un servidor: El cliente puede realizar una petición de la descripción de una transmisión vía HTTP o con algún otro método. Si la transmisión es realizada vía multicast, la descripción contendría la dirección multicast y puertos que deben ser utilizados por el flujo continuo. Si la transmisión se va a realizar a un único cliente vía unicast por razones de seguridad, el cliente proporcionaría el destino. Invitación de un servidor multimedia: Un servidor multimedia puede invitar a un cliente a unirse a una conferencia existente, tanto para reproducir o grabar un conjunto de la transmisión. Esto es muy usado en aplicaciones de enseñanza distribuida. Añadir datos multimedia a una transmisión existente: Como caso particular, para transmisiones en vivo, es muy usual que el servidor pueda proporcionar a los clientes información adicional disponible. Las propiedades más importantes de este protocolo son las siguientes: Extensible: Nuevos métodos y parámetros pueden ser añadidos muy fácilmente. Seguro: RTSP usa los mecanismos de seguridad web, tanto a nivel de transporte como en el protocolo mismo. Todas los mecanismos de autentificación de HTTP pueden ser usados directamente. Independiente del transporte: Puede usar tanto un protocolo de datos (UDP) como un protocolo de stream tal que TCP. Capacidad de utilizar múltiples servidores: Cada flujo de transmisión media puede ser realizado en un servidor diferente. El cliente automáticamente establecería varias sesiones concurrentes con los diferentes servidores. La sincronización es realizada en el nivel de transporte. Control de dispositivos de grabación: El protocolo puede controlar tanto dispositivos de reproducción y grabación como dispositivos que combinen los dos modos. Separación del control del flujo y la inicialización de una conferencia: El control del flujo está separado de invitar a un servidor media a una conferencia. El único requisito es que la inicialización de la conferencia se realice con un único identificador de conferencia. Idóneo para aplicaciones profesionales: RTSP soporta edición digital remota. Descripción de la transmisión neutral: El protocolo no impone un tipo particular de descripción de la transmisión. Sin embargo, la descripción debe contener al menos un RTSP URI. Compatible con Proxy y Firewall: Puede ser usado junto con estos dos tipos de aplicaciones. Similar a HTTP: Como se ha explicado, RTSP utiliza algunos conceptos de HTTP, por lo que las infraestructuras existentes pueden ser reutilizadas. Esta infraestructura incluye PICS (Plataforma para la Selección del Contenido). Control de servidor: Si un cliente puede iniciar un flujo, también tiene que ser capaz de poder detenerlo. Independiente del protocolo: El cliente puede negociar el método de transporte antes de necesitar el flujo multimedia. Cada media stream debe estar representado por un identificador URL RTSP. Las propiedades de la transferencia son definidas en un archivo de descripción. Este archivo puede ser obtenido por el cliente usando HTTP u otros métodos, es decir, no está necesariamente almacenado en el servidor. Se pueden distinguir varios modos de operaciones, entre los más importantes se pueden destacar: Unicast: El flujo es transmitido con el número de puerto elegido por el cliente. Multicast, el servidor elige la dirección: El servidor multimedia elige la dirección y el puerto. Este es el caso típico de transmisiones de Video on Demand. Multicast, el cliente elige la dirección: Se da cuando el servidor está participando en una conferencia multicast, y por lo tanto, la dirección es proporcionada por el cliente en la descripción de la conferencia. El servidor necesita mantener un estado de la sesión para ser capaz de seleccionar la respuesta que debe dar. Las peticiones más importantes son: SETUP Especifica cómo será transportado el flujo de datos. La petición contiene la URL del flujo multimedia y una especificación de transporte. Dicha especificación típicamente incluye un puerto para recibir los datos (audio o vídeo), y otro para los datos RTCP (meta-datos). El servidor responde confirmando los parámetros escogidos y selecciona las partes restantes, como los puertos escogidos por el servidor. Cada flujo de datos debe ser configurado con SETUP antes de enviar una petición de PLAY. PLAY/RECORD Una petición de PLAY provocaría que el servidor comience a enviar datos de los flujos especificados utilizando los puertos configurados PAUSE con SETUP. Detiene temporalmente uno o todos los flujos, de manera que puedan ser recuperados con un PLAY posteriormente. TEARDOWN Detiene la entrega de datos para la URL indicada. Libera los recursos asociados con el flujo. La sesión RTSP debe existir en el servidor. Otras peticiones menos importantes son: OPTIONS, AN- NOUNCE, DESCRIBE, REDIRECT y SET PARAMETER. En la Figura 8 se puede observar el proceso que se lleva a cabo cuando un cliente hace una petición de un flujo multimedia a un servidor. En primer lugar, el cliente accede a la URL y hace una petición DESCRIBE a un servidor web para que éste le devuelva la descripción de la presentación. Seguidamente, el servidor devuelve información que puede incluir la versión de RTSP, la fecha, el número de sesión, el nombre del servidor y los métodos soportados.

8 8 A continuación, el cliente realiza una petición de SETUP al servidor media, por lo que se especifican los protocolos aceptados para el transporte de los datos. Si todo es correcto, el cliente podrá hacer una petición de PLAY que informa al servidor de que ahora es el momento de comenzar a enviar datos, por lo que el servidor manda al cliente flujos de vídeo y audio RTSP. El cliente puede finalizar en cualquier momento la recepción del flujo mediante la petición al servidor de TEARDOWN. momento de su difusión (emisiones en directo). A continuación se muestra un gráfico con la arquitectura básica de todo sistema de streaming. Figura 9. Arquitectura básica de un servicio de video streaming Figura 8. Proceso RTSP STREAMING El vídeo puede ser capturado y codificado en tiempo real o puede ser codificado previamente y guardado para una visualización posterior. En muchas aplicaciones, el contenido de vídeo es codificado previamente y almacenado para su posterior visualización, lo que puede ser hecho de forma local o remota. El vídeo codificado previamente tiene la ventaja de no poseer restricciones de tiempo real. Esto permite la implementación de una codificación más eficiente, como la de múltiples pasadas utilizadas en los DVD. Por otro lado, la flexibilidad es limitada, ya que el vídeo previamente codificado no puede adaptarse a los canales de bit rate variable o a los clientes que tienen capacidad de visualización diferente a la originalmente codificada. Como el caso que concierne a este proyecto es la difusión de sesiones en directo, trataremos más a fondo la codificación en tiempo real. También hay que tener en cuenta las variaciones significativas de las características del canal de comunicación, como puede ser el ancho de banda, las demoras y las pérdidas si son estáticas o dinámicas, ya que la aplicación que se va a desarrollar al ser utilizada en una intranet puede encontrarse con diferentes tipos de conexiones. Los canales inalámbricos son variables en el tiempo y muchos de los desafíos del video streaming se relacionan con los atributos de estos canales. II-F1. Streaming Unicast: La mayoría de archivos de audio y vídeo que se visualizan en el ordenador, sea cual sea el reproductor que se utilice (Real, Windows Media), proviene de un servicio unicast. Este servicio consiste en un servidor que envía paquetes de datos a cada PC que solicita un stream. Unicast es una buena opción para recibir transmisiones en vivo, pero tiene sus desventajas, ya que el servidor debe enviar el flujo de datos individualmente a todo aquel que quiere recibir la transmisión. Es decir, es una aplicación 1:1, donde para cada cliente se establece una conexión. Si el conjunto de clientes que están recibiendo el stream es pequeño, no ofrece mayor inconveniente, pero si se trata de difundir un material a miles de usuarios, deberán considerarse entonces dos inconvenientes que se explican a continuación. II-F. Streaming a través de la red Todo sistema de streaming viene definido por una codificación y un sistema de transporte. La codificación puede ser MPEG-1, MPEG-2, Real, MPEG-4, QT, etc., y como protocolo de transporte se suele utilizar UDP (unicast o multicast), aunque también hay sistemas que utilizan TCP. Los contenidos pueden estar almacenados en un servidor (VoD, Vídeo Bajo Demanda) o bien crearse en el mismo Figura 10. Servidor unicast enviando paquetes de datos II-F1a. Demasiadas peticiones: Con unicast, el servidor tiene que procesar cada solicitud de stream y despacharla. Cada stream toma una pequeña porción de poder de procesamiento del servidor. Si se reciben muchas solicitudes, el servidor no podrá sostener la sobrecarga y muchas personas no podrán recibir la transmisión.

9 9 II-F1b. Demasiados paquetes: El segundo problema con unicast, y un gran número de solicitantes simultáneos de stream, es que una serie separada de paquetes de datos debe ser enviada a cada persona. Incluso si el servidor pudiera hacer esta tarea, el número de paquetes de datos en tránsito haría flooding, es decir, inundaría el sistema entero haciendo que la transmisión se vuelva muy lenta, o hasta se detenga. Considerando una emisión de larga duración (por ejemplo, un evento en vivo que dure una hora), la cantidad de paquetes a transmitir aumenta, por lo que se puede desbordar la red. II-F2. Streaming Multicast: Multicast utiliza una nueva forma de funcionamiento de redes. En lugar de enviar streams desde un solo servidor a un solo cliente, multicast envía una serie de paquetes que puede ser recibida por cualquiera, desde diversos puntos de distribución. Multicast permite un procesamiento estable del streaming en el servidor y alivia el tráfico en la red. Figura 11. Servidor enviando paquetes de datos a través de multicast El multicast hace su trabajo de transmisión de manera similar a como funcionan los canales de televisión o las estaciones de radio: el archivo de audio/vídeo se emite desde la estación hacia los servidores conectados a la red, los cuales se encargan de distribuir el stream a los usuarios. Cuando el espectro de usuarios se extiende, se agregan servidores. Mediante esta técnica se envía una sola copia de los datos a los clientes que lo han solicitado, permite implementar aplicaciones multimedia en la red y minimizar al mismo tiempo la demanda de ancho de banda de estas aplicaciones. paquete de datos para que sea enviado de nuevo. Esto quiere decir que algunos paquetes se perderán, incluso antes de que el usuario pueda notarlo, debido en parte a la manera en que el reproductor codifica los archivos. El multicast todavía no ha reemplazado al unicast en Internet, porque algunas partes de la red no han sido conectadas a routers que entiendan el proceso multicast. La mayoría de los nuevos routers pueden manejar multicast eficientemente, pero algunos países aún usan tecnología obsoleta que no está preparada para la transmisión multicast. Del lado del usuario, la mayoría de las tarjetas de red en los equipos más recientes también entienden el funcionamiento de multicast. Sin embargo, existe un área de las telecomunicaciones actuales donde multicast se está haciendo popular: las intranets. Debido a que el equipamiento tecnológico de las compañías se está modernizando, en términos generales, se pueden interconectar muchos equipos donde es posible trabajar con multicast. II-F2b. Enrutamiento multicast: Los enrutadores de la red y los protocolos que estos ejecutan llevan a cabo la mayor parte del trabajo necesario para permitir multicast. En la actualidad, se usan varios protocolos de enrutamiento de multicast: el Distance Vector Multicast Routing Protocol (Protocolo de Rnrutamiento Multicast por Vector Distancia, DVMRP), el Multicast Open Shortest Path First (Protocolo de Abrir Primero la Ruta de acceso más Corta de Multicast, MOSPF) y el Protocol Independent Multicast (Multicast Independiente del Protocolo, PIM). La tarea de estos protocolos es crear rutas de entrega de multicast eficaces a través de la red. Los protocolos de enrutamiento de multicast utilizan distintos algoritmos para lograr esta eficacia. II-F2c. Ruta de los datos multicast: Una ruta de entrega eficaz implica que los datos de multicast viajen únicamente a los clientes que desean recibirlos y que usen la ruta de acceso más corta a esos clientes. Si los datos viajan a cualquier otro lugar a través de la red, estarán usando un ancho de banda innecesario. Puede imaginarse la red como una estructura de árbol. El origen de multicast envía los datos a través de las ramas del árbol. Los routers son los responsables de enviar los datos por las ramas correctas a los otros routers y a las subredes en las que los miembros de un grupo están esperando los datos. Los routers cortan las ramas en las que nadie desea datos y las vuelven a insertar en el árbol cuando un cliente de una nueva subred se une al grupo. III. DESCRIPCIÓN DEL PROYECTO Figura 12. Tráfico de difusión multicast y unicast II-F2a. Recibiendo multicast: Debido a que el multicast es una transmisión por envío de una serie de paquetes de datos, no hay una manera sencilla de que el reproductor solicite un El proyecto AgoraRed2 es la continuación del Proyecto Final de Carrera desarrollado por David Cortés, titulado AgoraRed, centrado en las comunicaciones multimedia sobre redes cooperativas. El proyecto se basó en el estudio del protocolo RTP/RTCP y sus implicaciones en las redes de datos, así como en el estudio de las aplicaciones MBone y QBone. Para ello se desarrolló sobre el sistema operativo GNU/LinEx la herramienta VLinEx, que permite la comunicación multicasting entre diferentes ordenadores dentro de

10 10 una red local (isla multicast) y, además, transmite al resto de islas a través de túneles. Esta herramienta proporciona ventajas sobre el resto de herramientas existentes, dado que al estar escrita sobre Java es multiplataforma y permite, asimismo, el uso de componentes ya creados y probados que posibilitan la comunicación con las diferentes herramientas ya desarrolladas. No obstante, el sistema cuenta con algunos inconvenientes debidos al uso del propio framework, que facilita el desarrollo de la aplicación, pero que lleva sin actualizarse varios años, con lo que el desfase es considerable. Por eso, la aplicación sólo puede enviar información a otras islas con el codec H.263 (codec usado para videoconferencia en la actualidad). Pese a todo, es necesario incorporar nuevos codecs, como x.264 ó MPEG4, que doten de más calidad a la información y permitan llegar a resoluciones de HD. Por otro lado, como el lenguaje de programación Java utilizado es precompilado y necesita muchos más recursos para trabajar, esto sobrecarga el sistema, por lo que es necesaria una máquina potente para poder usarlo de forma fluida. Es por esto necesario reescribir la herramienta en un lenguaje de programación mucho más liviano, como es C++, para que la aplicación se ejecute con más fluidez. Las sesiones son propias del programa, pero si queremos hacer un sistema de sesiones que sea más universal, se debería usar SIP como protocolo de sesiones, que no está siendo usado en VLinEx. III-A. Objetivos de AgoraRed2 El objetivo principal del proyecto será la reimplementación de la aplicación VLinEx, desarrollada en el PFC AgoraRed. El principal problema que tenía VLinEx era la implementación desarrollada en un lenguaje interpretado y los problemas de rendimiento que esto conlleva. En lo referente a aspectos técnicos, y sin dejar de lado todo el trabajo previo de investigación y puesta al día en cuanto a tecnologías y protocolos necesarios, se estudiará: III-B. La aplicación de protocolos como SIP y SDP para el establecimiento de sesiones. Protocolos RTP y RTSP para la transmisión de vídeo mediante streaming. El desarrollo de un reproductor de vídeo con tecnología SDL. Incorporación de los codecs FFmpeg al reproductor. Estudio de codecs de transmisión que acepten formatos de vídeo de alta calidad. Desarrollo III-B1. Preparación del hardware, drivers y entorno de desarrollo: Antes de proceder con la construcción de la solución software final es fundamental adaptar los equipos de trabajo para que las condiciones de desarrollo y productividad sean óptimas. En primer lugar, se instalará en los ordenadores la distribución Linux elegida, Ubuntu 8.04 LTS. Seguidamente, se configurará el hardware correspondiente para realizar capturas de imágenes y sonidos, reproducciones de vídeo y audio, telecomunicaciones, etc. En este punto es imprescindible que todo funcione correctamente, ya que será la base de nuestro sistema. Finalmente, esta etapa concluye implantando el entorno de desarrollo integrado seleccionado para codificar, compilar y depurar la aplicación. III-B1a. Configuración del hardware: Debido a que el hardware disponible para la consecución del proyecto es el propio de los proyectandos y que las máquinas para el desarrollo son portátiles MacBook de Apple, será necesario llevar a cabo un exhaustivo proceso de configuración de los diferentes dispositivos del equipo. En primer lugar, es necesaria la instalación de un sistema operativo de libre distribución (GNU) como es Linux. Después de probar varias distribuciones como OpenSuSE, Fedora y Ubuntu, se elegió esta última porque era la que ofrecía más soporte técnico para el hardware disponible de entre todas las analizadas. La última versión disponible en este momento del desarrollo es la 8.04, utilizando como base el kernel de Linux. Este periodo de adaptación de equipos tuvo una duración demasiado prolongada por la cantidad de problemas de compatibilidad e inconsistencia que ofrecía el sistema operativo a nuestras máquinas. Hubo dificultades a la hora de configurar la tarjeta gráfica, teclas de función, sonido y sobretodo con la cámara integrada isight y la conexión a Internet (tanto a través de la tarjeta ethernet como con la tarjeta Wi-Fi). En mayor o menor medida los problemas se fueron solucionando, aunque por ejemplo, como solución más fiable, se optó por el uso de una webcam USB para la consecución del desarrollo. III-B1b. Entorno de desarrollo: Una vez superados los primeros escollos se prosiguió con la elección del entorno de desarrollo. Se han utilizado varios diferentes como Anjuta, Code::Blocks, Monodevelop, Netbeans y Eclipse. Como el desarrollo de la interfaz gráfica se realizará con las librerías GTK+ (nativas de GNOME, el escritorio utilizado en Ubuntu), en un principio se pensó que el idóneo sería Anjuta por su soporte para GTK+, gracias a su extensión Glade. Por todo lo anterior, al principio del desarrollo se usó Anjuta, aunque al empezar a programar y darnos cuenta de carencia tales como la inexistencia de un depurador eficiente e intuitivo, o que para programar aplicaciones GTK+ Glade no ofrecía gran ayuda debido a que era necesario escribir la mayor parte del código de la interfaz a mano, se optó por buscar otras herramientas, pasando a usar definitivamente Netbeans. Netbeans se eligió por su fiabilidad, usabilidad y su depurador funcional e intuitivo. Sobre este entorno de desarrollo integrado (IDE) se desarrollarán las partes relacionadas con los módulos visor de la webcam y reproductor de vídeo. A medida que avanzó el desarrollo y se comenzó con el estudio y pruebas de los protocolos de comunicación, se utilizó Eclipse también como entorno de desarrollo por su solidez y facilidad de manejo. III-C. Visor de cámara web En esta sección se hablará del desarrollo del módulo dedicado a mostrar en pantalla las imágenes captadas por la cámara web del ordenador.

11 11 Después de realizar un proceso de información e investigación exhaustivos sobre las API s necesarias para captar imágenes y controlar los diferentes componentes de la webcam, se decidió utilizar la API v4l2. Esta elección se realizó porque era la única manera de poder utilizar la cámara web integrada en nuestros ordenadores. En un principio se implementó un pequeño visor siguiendo las nociones dadas por la apliación UVCView [6] (Figura 13). Ésta es una aplicación muy básica que únicamente muestra la imagen de la webcam, sin soporte para la captura de sonido ni para el volcado de vídeo a disco. Hace uso de v4l2, con lo que en principio sería funcional en nuestro sistema. Después de conseguir hacer funcionar la cámara se encontró un problema con la decodificación de los colores debido a un bug de la librería v4l2 con la decodificación de UYVY4, por lo que los colores de salida del vídeo eran verde y rosa. El anterior problema, unido al poco soporte ofrecido por v4l2, la escasez de ejemplos de proyectos anteriores y la falta de consistencia en el funcionamiento de la isight sobre Ubuntu hicieron que se desechara el programa y se buscase tanto nuevo hardware como otras formas de conseguir un visor estable. Por tanto, se empezó a trabajar con las webcams USB disponibles en el laboratorio G ITACA, dos Logitech QuickCam Communicate S. Una vez reconfigurado el hardware, se comprobó que era necesario el uso de una API anterior a v4l2, denominada v4l, para que funcionasen las nuevas cámaras, por lo que el uso de v4l2 y el programa UVCView tuvieron que ser desechados. Visores que usasen la tecnología v4l eran más difíciles de encontrar, aunque las investigaciones realizadas nos condujeron al descubrimiento de la API unicap [7], que ofrece soporte uniforme tanto para interfaces de vídeo como de audio, permitiendo a las aplicaciones que usasen la captura de vídeo emplear una única API para este fin. Unicap también facilita la posibilidad de ofrecer un video display widget específico mediante la librería unicapgtk, para que el diseño de interfaces GTK sea lo más sencillo posible. En definitiva, se pensó que lo más conveniente sería usar unicap para el desarrollo del sistema y comenzó el aprendizaje del uso de la API mediante ejemplos proporcionados por el autor del proyecto, Arne Caspari. Más adelante se descubrió la aplicación UCView [8], incluida en el proyecto unicap y que tenía todas las funcionalidades requeridas para el desarrollo de este módulo, por lo que se optó por desarrollar el proyecto a partir de esta aplicación, ampliándola y adaptándola para cubrir nuestras necesidades. El resultado del módulo se muestra a continuación mediante la explicación de la interfaz gráfica de la aplicación: Al iniciar la aplicación se muestra el cuadro de diálogo ilustrado en la Figura 14. En dicha ventana se puede seleccionar el dispositivo de captura, el formato de vídeo a capturar y la resolución soportada por la webcam. Una vez realizadas todas las configuraciones necesarias, se abrirá la ventana principal. Figura 14. Selección de dispositivo En la ventana principal de la aplicación se puede ver la imagen captada por la webcam y una serie de iconos para capturar vídeo, hacer instantáneas y controlar el reproductor de vídeo que se detallará en la siguiente sección. Figura 13. Ilustración de UVCView En el transcurso de este proceso de migración a v4l se empezó a usar Anjuta como IDE por el hecho de incluir soporte directo para la creación de interfaces GTK+ sobre la herramienta Glade. Debido a la carencia de un depurador funcional y completo se desechó esta opción, pasando a usar Netbeans en su versión UYVY es un formato de empaquetado de píxeles para la representación de imágenes RGB. Figura 15. Ventana principal En la misma ventana vemos los botones Ajustes y Preferencias, que mostrarán cuadros de diálogo donde po-

12 12 dremos elegir diversas opciones sobre la configuración de la cámara y captura de vídeo, audio, instantáneas, etc. entornos GNOME) no soporta la integración de manera nativa de las librerías gráficas de SDL en sus widgets. No obstante, se intentó llevar a cabo dicha integración a través del uso de hacks, aunque finalmente el resultado no era el esperado y provocaba un gran número de errores e inconsistencias en la aplicación. Por tanto, se optó por mantener el reproductor en una ventana flotante aparte, como puede verse en la Figura 17. Figura 16. Ventanas de ajustes y preferencias III-D. Reproductor de vídeo Para la consecución del módulo de reproducción de vídeo se ha optado por hacer uso de la librería SDL o Simple DirectMedia Layer [9] para realizar la salida de audio y vídeo de los archivos multimedia a tratar. SDL es una excelente biblioteca multiplataforma, utilizada en diferentes programas como reproductores MPEG, emuladores y videojuegos. SDL es una librería escrita en C y trabaja perfectamente incluso en C++, así como en diversos lenguajes como Java, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk y Tcl. Es por ello que se podrá realizar la programación del reproductor sin demasiados problemas. En primer lugar se escribió un sencillo programa para reproducir ficheros de audio y vídeo desde línea de comandos, utilizando para ello esta librería gráfica en conjunto con una serie de codecs más generales y antiguos como MPEG-1. Seguidamente se amplió dicho reproductor para que soportase el paquete de codecs de FFmpeg. FFmpeg es una colección de software libre y librerías escritas en C que permiten grabar, convertir y hace streaming de audio y vídeo. Incluye libavcodec, que es la biblioteca principal del proyecto, capaz de codificar/decodificar en varios formatos de audio y vídeo. De esta manera se dotaba a la aplicación de la capacidad de reproducir prácticamente cualquier formato: Vídeo: H.263, H.264, AVI, MPEG-1, MPEG-2, MPEG- 4, Theora, etc. Audio: Apple Lossless, MP3, Vorbis, FLAC, WMA, etc. También contiene otras librerías complementarias como son: libavformat: Librería que contiene los multiplexadores/demultiplexadores para los archivos contenedores multimedia. libavutil: Biblioteca de apoyo que contiene todas las rutinas comunes en las diferentes partes de FFmpeg. libpostproc: Esta librería contiene funciones de postproceso de vídeo. libswscale: Esta biblioteca permite realizar funciones de escalado de vídeo. El siguiente paso fue integrar en la interfaz gráfica el reproductor de vídeo, aunque finalmente no se logró ya que GTK+ (biblioteca para desarrollar Interfaces Gráficas de Usuario en Figura 17. Ventana principal con el reproductor activo Para concluir con este apartado, las funcionalidades implementadas en el reproductor de vídeo son las de reproducir (Play), retroceder (Rebobinar), avanzar (Avanzar) y detener (Parar Reproducción) sobre un fichero o flujo de vídeo. III-E. Intercomunicación de equipos Para ahorrar tiempo y aumentar la productividad del equipo de desarrollo, se decidió diversificar el trabajo. De esta manera, uno de los componentes del grupo de desarrollo se centró en dar soporte a la intercomunicación de los equipos a través de RTP/RTSP y SIP mientras que el otro continuó indagando sobre la posibilidad de integrar SDL dentro de una ventana GTK. Así pues, comenzó el proceso de comunicación entre terminales. Desde el primer momento se pudo comprobar que este fin sería difícil de conseguir. En un principio se dedicó la mayor parte de los esfuerzos a encontrar una API que implementase la pila de protocolos de transporte y de sesión, es decir, RTP/RTSP y SIP respectivamente. Esta búsqueda se realizó en primera instancia de manera individual, es decir, buscando librerías que diesen un soporte independiente para cada uno de los protocolos. III-E1. Sistema de sesiones: API s para SIP construidas sobre sistemas UNIX no se encontraron muchas, pues aunque parezca sorprendente, la inmensa mayoría de ellas están implementadas para trabajar en sistemas Symbian, esto es, en dispositivos móviles. No obstante, dentro de las pocas que se encontraron para Linux, la mayor parte eran API s escritas en Java, por lo que también tuvieron que ser descartadas. Sin embargo, se encontró la librería PJSIP [10], escrita en C y con soporte no sólo para sistemas UNIX, sino que también podría utilizarse en plataformas como Windows, Mac o cualquier sistema para dispositivos móviles, con lo cual era apta para nuestros propósitos.

13 13 Investigando de manera más exhaustiva sobre PJSIP, rápidamente se percibió que la virtud que tenía era que no solamente es una API para el manejo del protocolo de sesiones SIP, sino que consistía en una completa arquitectura de componentes para las transmisiones multimedia, tal y como se puede ver en la Figura 18: Figura 18. Arquitectura de componentes de PJSIP Esta arquitectura incluye también el componente PJMEDIA, encargado de gestionar todos los aspectos referentes a los flujos de audio y vídeo y su transmisión en tiempo real, dando soporte para ello mediante la implementación de RTP/RTSP. Por tanto, parece que PJSIP era la API ideal a utilizar en AgoraRed2. Sin embargo, no todo fue tan inmediato como se supuso en un principio al encontrar esta librería, ya que al intentar compilarla para generar las librerías dinámicas y estáticas que posteriormente utilizaríamos en nuestro proyecto comenzaron a surgir una serie de problemas de compilación, tales como referencias corruptas a directorios inexistentes con los ficheros de cabecera de funciones o incompatibilidad de versiones en las herramientas de compilación de C y de autogeneración. Uno a uno estos problemas se fueron solucionando, modificando para ello los ficheros Makefile encargados de la generación de las librerías y adaptándolos tanto a las características de nuestro sistema como a su estructura de directorios. Finalmente, se pudo deducir que la causa de todos estos errores era que el sistema de generación de la API fue diseñado para funcionar en un tipo de distribución Linux (presumiblemente sistemas basados en Red Hat) sin atender a otros tipos de distribuciones, como Debian o Slackware, por ejemplo. Tras solucionar el inconveniente mencionado anteriormente, se comenzó con la programación de la parte relacionada con las comunicaciones entre los equipos, pero los problemas no desaparecieron, ya que una vez compilada la API y generadas todas las librerías correspondientes, al hacer uso de ellas o de las funciones que implementaban producían errores incoherentes, tales como inexistencia de funciones dentro de determinadas librerías o número de parámetros incorrecto en varias funciones. Llegados a este punto se decidió dejar de lado temporalmente el soporte de sesiones para centrar los esfuerzos del equipo de desarrollo en las transmisiones de ficheros multimedia en tiempo real haciendo uso del streaming. III-E2. Protocolos de transporte: La búsqueda de API s para RTP y RTSP dieron bastantes resultados, aunque se tuvo que desechar la mayor parte de ellos al estar escritos en Java (al igual que ocurría para el protocolo SIP), quedándonos finalmente con las escritas en C/C++: RTP from vovida.org ( Ortp ( GNU ccrtp ( RTPlib ( Librtp ( librtp) Microsoft RTC API ( sipxmedialib ( PJMEDIA [10] ( Zfone ( html) JRTPlib [11] De todas estas API s, y tras haber probado de manera superficial la mayor parte de ellas, se decidió utilizar JRTPlib, ya que es una librería con bastantes referencias en la red y que actualmente utilizan varios proyectos. Está escrita en C++ y además incluye una clase opcional llamada JThread, capaz de gestionar de una manera sencilla y transparente el manejo de hebras en la aplicación. Esta API fue realizada como Proyecto Fin de Carrera [11] por Jori Liesenborgs [12] y contiene una documentación aceptable a pesar de su propósito académico. Las primeras pruebas mostraron que la librería funcionaba correctamente. Para ello, se implementó un programa que enviaba desde un terminal a otro un mensaje con texto plano, utilizando para el trasporte paquetes RTP generados con JRTPlib y en cuyo payload se encontraba dicho mensaje. Se comprobó con Wireshark, tanto en el equipo emisor como en el receptor, que las tramas estaban bien formadas y que efectivamente transportaban el texto. Una vez comprobada la funcionalidad de la API a niveles básicos, se pasó a programar la parte del envío de vídeo de AgoraRed2. Como debía dar soporte a emisiones multicast y unicast, se pensó que en primer lugar sería conveniente probar esta última, por lo que se diseñó un sencillo programa que permitiese reproducir y enviar a través de la red un fichero de vídeo desde un ordenador a otro, estableciendo así una comunicación 1:1 utilizando RTP. Es en este punto cuando comenzaron los problemas con el uso conjunto de esta API y el paquete de codecs FFmpeg, concretamente al decodificar los paquetes que llegaban al receptor, momento en el que el sistema se volvía inestable y provocaba fallos de segmentación que forzaban el cierre de la aplicación. Haciendo varios análisis de los paquetes enviados y recibidos con Wireshark y ejecutando varias trazas en el receptor, se determinó que el problema radicaba en que FFmpeg no soporta el streaming directamente, sino que hace uso de

14 14 un servidor intermedio llamado FFserver, el cual habría que levantar y configurar antes de proceder con la emisión multimedia. Antes de pasar a implementar el uso de FFserver en Agora- Red2, el equipo de desarrollo se centró en buscar aplicaciones libres que dispusiesen de esta funcionalidad de FFmpeg para comprobar así su funcionamiento. MPlayer y VLC son algunos de los ejemplos, aunque finalmente sólo se probó con este último, ya que MPlayer no dispone de soporte para streaming. Tras realizar las pruebas con VLC se determinó que la aplicación hacía uso de su propia versión del protocolo de transporte RTP, ya que los frames de audio y vídeo que envía no los encapsula como paquetes RTP, sino como paquetes UDP con información referente al stream codificada dentro del campo de datos. Determinado que no se podía hacer uso de partes del proyecto VLC para incluirlo en AgoraRed2, los desarrolladores volcaron todos sus esfuerzos en diseñar una capa que gestionase todo lo referente al streaming. No obstante esto no fue posible, tanto por la falta de tiempo (o recursos) como por la inexistencia de documentación para la API de FFmpeg [13], ya que ésta sólo está disponible en la web del proyecto [14] y únicamente se basaba en la descripción de las cabeceras de las funciones y sus argumentos, sin facilitar ningún tipo de información adicional sobre su uso, el fin del mismo o ejemplos de código. Además, en caso de que se hubiesen adquirido los conocimientos suficientes para implementar esta nueva capa en AgoraRed2 sería inviable, ya que la fecha de entrega del proyecto estaba próxima y esto daba al equipo muy poco margen de tiempo. No obstante, se siguió trabajando para conseguir tener una base hecha de cara a futuros proyectos. IV. PRUEBAS REALIZADAS Una vez llegados al límite del tiempo estipulado para la implementación de AgoraRed2, el equipo de desarrollo centró su trabajo en elaborar la documentación final del proyecto, reflejada en este documento, y en realizar un conjunto de pruebas sobre la herramienta software diseñada. En primer lugar, los desarrolladores comprobaron tanto los límites de la aplicación como el hecho de que efectivamente el problema existente con las API s era de carácter general y no específico de las circunstancias dadas y elementos utilizados en el proyecto. Para ello, se prepararon dos equipos diferentes con dos distribuciones Linux distintas: Equipo 1: Ordenador de sobremesa con procesador Intel Pentium 4 a 3 GHz y con 2 MB de caché, 1 GB de memoria RAM, tarjeta gráfica ATI Radeon 9200 PRO y sistema de audio integrado. El sistema operativo instalado en él es Debian Linux 4.0rev5 (Etch) y el kernel de Linux sobre el que funciona es el Las herramientas, librerías y API s instaladas en él y sus respectivas versiones han sido las siguientes: gcc: make: 3.81 JThread: JRTPlib: Unicap: libsdl: FFmpeg: r11872 (svn_snapshot ) libavutil: libavcodec: libavformat: libavdevice: libswscale: Figura 19. GNU/Linux Debian Equipo 2: Ordenador de sobremesa con procesador Intel Pentium 4 a 2,8 GHz y con 512 KB de caché, 1 GB de memoria RAM, tarjeta gráfica nvidia GeForce FX 5200 y sistema de audio integrado. El sistema operativo instalado en él es opensuse 11.0 y el kernel de Linux sobre el que funciona es el Las herramientas, librerías y API s instaladas en él y sus respectivas versiones han sido las siguientes: gcc: make: 3.81 JThread: JRTPlib: Unicap: libsdl: FFmpeg: SVN-r15866 libavutil: libavcodec: libavformat: libavdevice: libswscale: Figura 20. Novell opensuse En ambos casos, las pruebas relativas tanto al funcionamiento de la aplicación como a la captura de imágenes a través de la webcam o la reprodución de ficheros multimedia almacenados en disco resultaron satisfactorias, incluso realizando estas dos últimas funciones de manera simultánea y paralela gracias al uso de la librería JThread. No obstante, no se puede decir lo mismo de las referentes al uso de las librerías JRTPlib y FFmpeg en conjunto, ya que en ambos equipos nos encontramos con los mismos problemas que surgieron en la fase de desarrollo. Al invocar las

15 15 funciones de decodificación sobre los paquetes que llegaban al receptor, el sistema se vuelve inestable y provocaba fallos de segmentación que fuerzan el cierre de la aplicación. Vemos más detalladamente este caso. La siguiente secuencia de código pertenece a la función principal del ejemplo utilizado para realizar las pruebas de comunicación, ubicada en el fichero RTPStream.cpp. En él puede observarse el comportamiento del programa, ya que puede actuar como servidor de la sesión de streaming o como cliente receptor: #include "StreamSession.h" #include "VideoPlayer.h" using namespace std; void imprimirayuda(char* exec) cout << endl; cout << "Programa de pruebas para << endl; cout << JRTPlib y FFmpeg" << endl; cout << "Modo de uso:" << endl; cout << exec << "MODO [Fichero]" << endl; cout << "MODO: " << endl; cout << "-s: Realiza streaming" << endl; cout << "-c: Recibe los cout << frames de vídeo" << endl; cout << endl; int main(int argc, char *argv[]) if ((argc!= 2 && argc!= 3) ((strcmp(argv[1],"--help") == 0) (strcmp(argv[1],"-h") == 0))) imprimirayuda(argv[0]); return EXIT_SUCCESS; else if ((strcmp(argv[1],"--cliente") == 0) (strcmp(argv[1],"-c") == 0)) StreamSession client=streamsession(); client.solicitardatosrecepcion(); asignarsesion(client.getsesion()); receivevideo(); else if (((strcmp(argv[1],"--servidor")==0) (strcmp(argv[1],"-s")==0)) && argc==3) StreamSession server=streamsession(); server.solicitardatosemision(); asignarsesion(server.getsesion()); streamvideo(argv[2]); else imprimirayuda(argv[0]); return EXIT_SUCCESS; En caso de que queramos ejecutar en una máquina el programa en modo servidor, introduciríamos la siguiente orden en la línea de comandos desde el directorio en el que se encontrase el binario:./rtpstream --servidor FicheroMultimedia De esta manera, se creará una sesión multimedia en modo servidor, solicitando al usuario los datos de la máquina o grupo al que se desea enviar el flujo de datos. Seguidamente, el programa comenzará a emitir paquetes y a reproducir en modo local el fichero con el que se está trabajando. Todo esto se gestiona desde la función streamvideo(ficherovideo), perteneciente al fichero VideoPlayer.cpp. Una vez que tenemos el programa servidor ejecutándose en una máquina, podemos arrancar otra instancia del mismo en otro ordenador en modo cliente../rtpstream --cliente Así, la aplicación se quedará a la espera de recibir paquetes RTP en un puerto cualquiera, indicado durante el proceso de configuración por parte del usuario. En el momento en que empiecen a llegar paquetes a través de dicho puerto, el programa comenzará a decodificarlos y reproducirlos gracias a la función receivevideo(), codificada también en el fichero VideoPlayer.cpp: bool receivevideo() //Open video SDL_Event event; VideoState *is; is = (VideoState*) av_mallocz(sizeof(videostate)); //Register all formats and codecs av_register_all(); if (SDL_Init(SDL_INIT_VIDEO SDL_INIT_AUDIO SDL_INIT_TIMER)) fprintf(stderr, "Couldn t init SDL: %s\n", SDL_GetError()); exit(1); //Make a screen to put our video #ifndef DARWIN screen=sdl_setvideomode(640,480,0,0); #else screen=sdl_setvideomode(640,480,24,0); #endif if (!screen) fprintf(stderr, "SDL: couldn t set video. Exit\n"); exit(1); strcpy(is->filename, "udp://@"); is->pictq_mutex = SDL_CreateMutex(); is->pictq_cond = SDL_CreateCond(); schedule_refresh(is, 40); is->av_sync_type = DEFAULT_AV_SYNC_TYPE; //Put decode function into a Thread is->parse_tid = SDL_CreateThread (stream_decode_thread,is); if (!is->parse_tid) av_free(is); return -1 ; av_init_packet(&flush_pkt); flush_pkt.data = (uint8_t*) "FLUSH"; for (;;) double incr, pos; SDL_WaitEvent(&event); switch (event.type) case SDL_KEYDOWN: switch (event.key.keysym.sym) case SDLK_LEFT: incr = ; goto do_seek; case SDLK_RIGHT: incr = 10.0; goto do_seek; case SDLK_UP: incr = 60.0; goto do_seek; case SDLK_DOWN: incr = ;

16 16 goto do_seek; do_seek: if (global_video_state) pos = get_master_clock (global_video_state); pos += incr; stream_seek(global_video_state, (int64_t) (pos*av_time_base), incr); break; default: break; break; case FF_QUIT_EVENT: case SDL_QUIT: is->quit = 1; SDL_Quit(); return (0); break; case FF_ALLOC_EVENT: alloc_picture(event.user.data1); break; case FF_REFRESH_EVENT: video_refresh_timer (event.user.data1); break; default: break; return true; Como se puede ver, la parte más importante de esta función es la asignación de la función de decodificación stream_decode_thread a un hilo independiente de la ejecución principal. Este thread se encargará de recibir todos los paquetes multimedia que lleguen y decodificarlos, introduciéndolos además en las colas de audio y vídeo correspondientes: int stream_decode_thread(void *arg) VideoState *is = (VideoState *) arg; AVFormatContext *pformatctx; AVPacket pkt1, *packet = &pkt1; int video_index = -1 ; int audio_index = -1 ; int i, status; is->videostream = -1 ; is->audiostream = -1 ; global_video_state = is; //Open video file ByteIOContext *ByteIOCtx; if (av_open_input_stream(&pformatctx, ByteIOCtx, is->filename, NULL, NULL)!=0) return -1 ; //Couldn t open file is->pformatctx = pformatctx; //Retrieve stream information if (av_find_stream_info(pformatctx) < 0) //Couldn t find stream information return -1 ; //Dump information about file //onto standard error dump_format(pformatctx, 0, is->filename, 0); //Find the first video stream for (i=0;i<pformatctx->nb_streams;i++) if (pformatctx->streams[i]->codec->type== CODEC_TYPE_VIDEO && video_index < 0) video_index = i; if (pformatctx->streams[i]->codec->type== CODEC_TYPE_AUDIO && audio_index < 0) audio_index = i; if (audio_index >= 0) stream_component_open(is, audio_index); if (video_index >= 0) stream_component_open(is, video_index); if (is->videostream<0 is->audiostream<0) fprintf(stderr, " %s: couldn t open codecs\n", is->filename); goto fail; //Main decode loop for (;;) if (is->quit) break; //Seek stuff goes here if (is->seek_req) int stream_index = -1 ; int64_t seek_target = is->seek_pos; if (is->videostream >= 0) stream_index = is->videostream; else if (is->audiostream >= 0) stream_index = is->audiostream; if (stream_index >= 0) seek_target = av_rescale_q (seek_target, AV_TIME_BASE_Q, pformatctx-> \\ streams[stream_index]->time_base); if (!av_seek_frame(is->pformatctx, stream_index, seek_target, is->seek_flags)) fprintf ( stderr, " %s: error while seeking\n", is->pformatctx->filename ); else if ( is->audiostream >= 0 ) packet_queue_flush(&is->audioq); packet_queue_put(&is->audioq, &flush_pkt); if ( is->videostream >= 0 ) packet_queue_flush(&is->videoq); packet_queue_put(&is->videoq, &flush_pkt); is->seek_req = 0; //End decode loop if ( is->audioq.size> MAX_AUDIOQ_SIZE is->videoq.size> MAX_VIDEOQ_SIZE ) SDL_Delay ( 10 ); continue;

17 17 if (av_read_frame(is->pformatctx,packet)<0) if (url_ferror((byteiocontext*) &pformatctx->pb)==0) /* no error; wait for user input */ SDL_Delay ( 100 ); continue; else break; //Is this a packet from the video stream? if (packet->stream_index == is->videostream ) packet_queue_put(&is->videoq, packet); else if (packet->stream_index == is->audiostream ) packet_queue_put(&is->audioq, packet); else av_free_packet ( packet ); /* All done. Wait for it */ while (!is->quit ) SDL_Delay ( 100 ); fail: SDL_Event event; event.type = FF_QUIT_EVENT; event.user.data1 = is; SDL_PushEvent ( &event ); return 0; Figura 21. Paquetes RTP recibidos en la máquina de pruebas Sin embargo, tal y como se comentó anteriormente, al invocar las funciones de decodificación sobre los paquetes que llegan al receptor, el sistema se vuelve inestable y provoca fallos de segmentación, forzando el cierre de la aplicación. Tras realizar varias trazas en el depurador de Eclipse junto con Wireshark, el cual mostraba que el formato de los paquetes recibidos era correcto (Figura 21), el equipo de desarrollo pudo determinar que el problema residía concretamente al ejecutar la sentencia if (av_read_frame(is->pformatctx,packet)<0), ya que al proceder a la lectura del frame de audio o vídeo recibido, la librería dinámica que contiene esta función de FFmpeg falla. Al no poder acceder a ella para realizar una traza, no se pudo determinar a ciencia cierta cuál es el error concreto o la causa que lo produce. Por tanto, se puede asegurar definitivamente que los errores producidos durante el desarrollo de AgoraRed2 a la hora de implementar el módulo de intercomunicación de los equipos se deben a fallos en el uso conjunto de estas dos librerías, concretamente en la decodificación del stream por parte de FFmpeg. V. CONSIDERACIONES FINALES En primer lugar, para desarrollar aplicaciones en entornos libres (como Linux) es recomendable, al menos de momento, utilizar hardware cuyas especificaciones estén abiertas o semi-abiertas, o al menos cuyos drivers sean facilitados por la empresa desarrolladora. De esta manera nos aseguraremos de que el hardware que utilizamos es 100 % compatible y funcional con el sistema operativo. Parte de los problemas que se han tenido en este proyecto han sido causados por el hecho de que las máquinas utilizadas para su desarrollo fuesen principalmente dos MacBook de Apple, que son computadoras muy potentes y resolutivas, pero únicamente funcionales en su totalidad con el sistema operativo propio de Apple, OS X. Hay que dejar claro que las limitaciones de AgoraRed2 no se han hecho patentes únicamente por incompatibilidades de hardware con los MacBook, puesto que su arquitectura está basada en procesadores Intel, lo que hace posible la instalación de manera nativa de prácticamente cualquier sistema operativo actual (en nuestro caso Ubuntu Linux). Sin embargo, no se ha podido utilizar algunos componentes propios de los ordenadores, como la cámara integrada isight, el chip Wi-Fi o la tarjeta de sonido, o al menos no con todas sus capacidades. No obstante estas dificultades se salvaron utilizando hardware externo, ya que otra posible solución hubiese sido adquirir nuevos equipos, pero esto resultaba inviable, puesto que AgoraRed2 estaba enmarcado como Proyecto Fin de Carrera y no tenía ninguna concesión económica para su desarrollo. En segundo lugar, los autores del presente documento han echado en falta la existencia de una API plenamente funcional, tanto para la pila de protocolos de transporte RTP/RTCP, como para SIP. Cierto es que el candidato ideal para nuestro caso de estudio hubiese sido la pila PJSIP, que integraba tanto la parte referente al sistema de sesiones con SIP como los protocolos de transporte en una única arquitectura. No obstante, esta API aún está en una fase muy temprana de desarrollo y habrá que esperar a futuras versiones para percibir una mayor madurez. Quizás hubiese sido recomendable la realización de un Proyecto Fin de Carrera anterior a éste para elaborar una API en C/C++ que aglutinase todos los aspectos mencionados en el párrafo anterior. De esta manera se habría facilitado mucho la tarea y no se tendría que haber realizado el proceso de indagación, prueba y descarte de API s que ha copado gran parte del tiempo empleado para el desarrollo de AgoraRed2.

18 18 Otra posible solución podría haber sido emplear más recursos humanos para solventar esta dificultad y de esta manera haber construido dentro del ámbito del proyecto las API s necesarias. Como el tiempo dedicado para el desarrollo del proyecto tiene una duración específica, ésta sería la única solución viable en las circunstancias acontecidas, ya que así se multiplicaría la capacidad de trabajo del equipo de análisis y desarrollo. Evidentemente esto sería imposible, ya que AgoraRed2 es un Proyecto Fin de Carrera y no un proyecto de desarrollo convencional promovido por una empresa. Por último, y a modo de recomendación para la comunidad de desarrollo en Linux, sería conveniente concienciarse para seguir unas normas o estándares más rígidos que los actuales a la hora de diseñar la jerarquía de directorios en este sistema operativo. Está claro que existen varias distribuciones Linux principales (Debian, Red Hat, Slackware, etc.) de las que derivan una infinidad de distribuciones hijas (Ubuntu, Fedora, opensuse, SLAX, Knoppix, Mandriva, etc.). Cada una de esas distribuciones madre tiene su propia jerarquía de directorios (y por tanto las distribuciones hijas heredan esta arquitectura), en la que los paquetes instalan sus ficheros, ya sean archivos de cabecera, código fuente o librerías. Evidentemente, si los desarrolladores controlan estos aspectos a la hora de diseñar una nueva aplicación, no debe surgir ningún problema, pero aún así resulta contraproducente mantener esta diversificación del sistema de archivos entre los distintos tipos de distribuciones, pues, en definitiva, cada una de ellas está implementada sobre el mismo sistema operativo, que es Linux. Resulta incomprensible, por ejemplo, que unas librerías instalen sus archivos en /usr/local/lib, mientras que otras lo hagan en /usr/lib, cuando no existe una razón de fuerza mayor que obligue a ello. Si se normalizara este aspecto a la hora de instalar paquetes o compilar programas distribuidos junto con su código fuente, todos los sistemas tendrían las librerías requeridas en el mismo path, evitando el tener que usar herramientas como configure para comprobar si existen en el sistema o no y consiguiendo así sistemas estables y compatibles entre sí. VI. CONCLUSIONES Actualmente nos encontramos en una coyuntura muy favorable para la tecnología multimedia y las comunicaciones colaborativas, ya que se están produciendo una serie de cambios e innovaciones que influyen positivamente en ella. Estos cambios van desde el desarrollo del sistema de Voz sobre IP, hasta la aparición de sistemas emergentes, como videoconferencias sobre redes inalámbricas o transimisiones de Alta Definición con HDTV, sin olvidar el amplio horizonte que se vislumbra al adentrarnos en el sistema de telefonía móvil. Como consecuencia de todo este conjunto de innovaciones, actualmente se suceden las apariciones de nuevos estándares y normas, codecs multimedia y sistemas y aplicaciones colaborativas nuevas. Los sistemas de sesiones empleados en las tecnologías colaborativas se han ido simplificando y aligerando con el paso de los años, favoreciendo así los procesos de configuración, localización y conexión de varios usuarios en sistemas multimedia. El caso más importante es la aparición y adopción como protocolo de señalización del 3GPP de SIP, mucho más sencillo y eficiente que su predecesor, H.323, el cual suponía un impedimento para los desarrolladores por ser una norma muy poco trasparente a la hora de codificar los mensajes, ya que utiliza un sistema binario como es ASN.1. Con respecto a los protocolos y técnicas utilizados para el transporte de datos en este tipo de sistemas, RTP/RTCP y la tecnología multicast, es evidente que están en plena decadencia, y en el caso particular del multicast, parece que es una tecnología obsoleta por el alto ancho de banda que requiere. Sin embargo, su uso sigue siendo recomendable y efectivo en determinados escenarios, como cursos de formación para el personal o reuniones interdepartamentales de una determinada institución, todos ellos localizados en intranets y con determinadas limitaciones para evitar posibles colapsos en las redes. No obstante, poco a poco estas tecnologías están siendo desbancadas por nuevos protocolos y normas más eficientes, aunque aún es muy temprano para utilizarlos o adoptarlos como un estándar en las comunicaciones multimedia. En definitiva, podemos afirmar que el futuro de las comunicaciones colaborativas y las aplicaciones multimedia está asegurado, ya que gran parte de los proyectos actuales e investigaciones están enmarcados en el ámbito de estas tecnologías. Seguramente, en un futuro no muy lejano, aquel utópico sueño de la humanidad de estar constantemente comunicados unos con otros se convierta en una auténtica realidad. VII. TRABAJO FUTURO La finalización de este proyecto no supone el dejar todo este trabajo olvidado en una estantería o en los repositorios de un grupo de investigación. Al contrario, sirve como base para futuros trabajos o investigaciones, y mucho más cuando algunos de los aspectos no han podido desarrollarse por el vacío existente en el marco de las API s disponibles para la realización de aplicaciones multimedia y cooperativas. En este sentido, una línea lógica de posibles nuevos trabajos sería la de diseñar y contruir una pila que implementase un conjunto de protocolos necesarios para este tipo de telecomunicaciones, como por ejemplo RTP, junto con su protocolo de control RTCP y de streaming RTSP y un sistema de sesiones basado en SIP. De esta manera, y uniéndolo a la aplicación AgoraRed2, que ya implementa la parte del cliente en este tipo de comunicaciones multimedia, se tendría una aplicación completa y funcional basada en todas las tecnologías estudiadas durante el desarrollo de este proyecto. También se podría buscar alguna alternativa para poder homogeneizar la aplicación y fusionar las dos ventanas independientes (reproductor de vídeo SDL y visor de la webcam) en una sola, aunque esto depende de la librería SDL, por lo que habría que esperar a nuevas versiones para ver si sus desarrolladores consideran a bien solventar este problema. No obstante, también podrían buscarse nuevas librerías de gestión gráfica que permitiesen realizar esa unión, aunque en la actualidad la situación del mercado en este sentido no es muy alentadora y habría que esperar a la aparición de nuevos proyectos. Otra posible linea de futuros trabajos sería la de incluir soporte para el descubrimiento de servicios cooperativos

19 19 multimedia en redes locales, tales como compartición de pantalla, escritorios remotos, clientes o grupos de clientes con disponibilidad para hacer videoconferencias en el instante de una manera rápida y sencilla, sin apenas configuraciones previas, etc. Todo esto sería posible gracias a la inclusión de una capa en el programa que diese soporte a protocolos como Zeroconf 5, basado en mdns (Multicast DNS). Dicha capa podría estar basada en la implementación libre en sistemas Linux de este protocolo, denominada Avahi [16]. Finalmente, y atendiendo a las tendencias actuales del mercado tecnológico, que cada vez centra más sus esfuerzos en los servicios web, sería interesante dotar a la aplicación de alguna funcionalidad orientada a este aspecto. Localización de usuarios de AgoraRed2 a través de Internet, gestión de perfiles identificativos, servicio de chat o llamadas perdidas son algunos ejemplos de posibles mejoras para la aplicación en este sentido. [15] Apple. (2004) Bonjour. [Online]. Available: http: // [16] P. Avahi. (2004) Avahi - Trac. The Avahi Project. Lennart Poettering and Trent Lloyd. [Online]. Available: REFERENCIAS [1] ITU-T, H.323 Serie H: Sistemas audiovisuales y multimedios, ITU-T Std., [2] U. Black, Voice Gateways and Gatekeeper. Prentice Hall, [3] U. de Geneve UNIGE. (1995) Informacion general sobre Backus Naur Form (BNF). Centre Universitaire dõinformatique Ð Le CUI. [Online]. Available: Enseignement/analyseinfo/AboutBNF.html [4] M. Handley, H. Schulzrinne, H. Schooler, and J. Rosenberg, SIP: Session Initation Protocol, IETF, Tech. Rep. RFC 2543, [5] H. Schulzrinne, A. Rao, and R. Lanphier, Real Time Streaming Protocol (RTSP), IETF, Tech. Rep. RFC 2626, [6] (2008) UVCView a simple UVC viewer. [Online]. Available: hack/uvcview.html [7] A. Caspari. (2008) unicap - The uniform API for image acquisition devices. [Online]. Available: [8]. (2008) UCView - A Versatile Image Capture and Processing Application. [Online]. Available: http: // [9] S. Lantinga. (1998) Simple DirectMedia Layer. [Online]. Available: [10] PJSIP.ORG. (2005) Open Source Portable SIP Stack and Media Stack for Windows and Mac OS X from PJSIP.ORG. [Online]. Available: [11] J. Liesenborgs. (2000) Jori s page CS/Jrtplib. [Online]. Available: ~jori/page/index.php?n=cs.jrtplib [12]. (2004) Jori s page. [Online]. Available: php?n=main.about [13] FFmpegProject. (2006) FFmpeg Documentation. [Online]. Available: ffmpeg-docs/ [14]. (2006) The FFmpeg Project. [Online]. Available: 5 Una de las implementaciones de este protocolo con más éxito es Bonjour [15] de Apple, aunque sólo es compatible con sistemas Mac y Windows.