Ingeniería, 2007-00-00 vol:12 nro:1 pág:39-47

Análisis e implementación de medios de comunicación para transmisión de audio en Internet

Analisys and implementation of media comunication for internet audio transmission over

Álvaro Espinel Ortega
Director del grupo de investigación GESETIC, Universidad Distrital.
Paulo Alonso Gaona García
Pertenece al grupo de Investigación Ontare.

Resumen

El siguiente artículo plantea los resultados obtenidos de un proyecto de investigación sobre el análisis y requerimientos para la creación de un modelo arquitectónico de comunicaciones multimediales y la implementación de un componente de software que permita realizar la transmisión de audio a través de Internet en tiempo real. Para su desarrollo fue necesario determinar elementos funcionales a nivel lógico como transmisiones de tipo multicast, protocolos de enrutamiento y elementos de encoding para la transmisión de audio por Internet; del mismo modo se determinaron elementos físicos mediante la implementación de técnicas de enrutamiento multicast sobre routers para garantizar la comunicación a nivel de Internet y determinar conectividad hacia el exterior.

Palabras clave:
Framework de audio de Java, PIM, RTP, streaming, tiempo real, transmisión multicast

Abstract

The following article show the results obtained of an investigation project on the analysis and requirements for the creation of an architectonic model of multimedial communications and the implementation of a software component that allows to make the transmission of audio through Internet in real time. For this development it was necessary to determine functional elements at logical level like transmissions of type multicast, protocols of routing and elements of encoding for the transmission of audio by Internet; in the same way physical elements by means of the implementation of techniques of routing multicast were determined on routers to guarantee the communication at level of Internet and to determine connectivity towards the outside.

Key words:
JMF, PIM, RTP, real time, streaming, multicast transmission.

1. Introducción

Las transmisiones en Internet de tráfico multimedial ha llevado a investigadores y empresas dedicadas a este tipo de servicio a utilizar las mejores técnicas de encoding para que estas no saturen la red, pero no basta solo con utilizar los mejores formatos y determinar el tiempo de encoding de cada una de ellas si se dispone de medios de transmisión con velocidades relativamente bajas como los tiene actualmente la mayoría de personas con un acceso a Internet limitado, sino de determinar los medios que se utilizan para garantizar el acceso a estos recursos mediante técnicas de enrutamiento óptimo.

Las transmisiones multimediales presentan muchas características en cuanto a medios a utilizar se refiere, pero parte de estas transmisiones dependen de factores externos al medio que se va a transportar en si, sea este audio o video, el problema se vuelve aún mayor cuando se trata de realizar estas transmisiones en tiempo real, y es aqui donde empiezan a ser claves los protocolos de comunicación para llevar a cabo las mejores técnicas de enrutamiento a este nivel, esto, debido a que son funciones que prácticamente no depende de los equipos terminales, sino de los intermedios que hacen parte de esta labor mediante una programación exhaustiva por parte de los administradores de red. Por tal motivo se pretende mostrar un prototipo de arquitectura que logre determinar las bases importantes para la construcción de aplicaciones multimedia orientadas a la Web sobre un modelo de comunicaciones extremo a extremo mediante el protocolo IP en su versión 4.

2. Características de transmisión de audio sobre redes IP

La tendencia al uso de Internet como e medio para el transporte de todos los servicios a nivel multimedia es una realidad tangible. Sin embargo, este crecimiento no ha sido acompañado de un cambio estructural real que permita asegurar garantías de calidad a los usuarios finales en cuanto a tiempo y respuesta se refiere, teniendo en cuenta que la mayoría de usuarios no tienen un servicio a Internet dedicado con velocidades accesibles a ella como las tienen la mayoría de las empresas; Internet es aún una red de mejor esfuerzo(1).

La arquitectura de Internet es un ambiente de trabajo donde el ancho de banda no esta garantizado, la transmisión de paquetes se pierden en el camino y la rata de conexión de los clientes varía dependiendo de su conexión, por lo tanto se necesitan de técnias de enrutamiento adecuadas a gran escala que permitan realizar este tipo de actividades [1], al igual que un esquema de compresión escalable para evitar pérdidas de paquetes cuando se realiza una transmisión [2].

Dentro de las técnicas de compresión, según Levine [3] las técnicas más elaboradas proporcionan una reducción muy importante de la capacidad de almacenamiento, pero requieren también de un importante procesado tanto para compresión como para la descompresión, pero según Hamdy [4] las técnicas más simples ofrecen reducciones moderadas con poco procesamiento.

Existen varios proyectos de renombre relacionados con la transmisión de audio en Internet, por mencionar uno de ellos, Progressive Networks propietaria del software de emisión de audio y vídeo RealPlayer (antes Real Audio), Netscape y la Universidad de Columbia trabajaron juntos para encontrar una solución al envío de datos multimedia a través de arquitecturas de redes basada en IP. El resultado final fue un nuevo protocolo; se trata de un protocolo de control para dirigir la emisión de audio/vídeo desde un servidor, mas sin embargo por sus mismas características de ser propietario, lo limita para trabajar con formatos y el uso de aplicaciones de pago o descarga condicionada por parte del usuario, surgiendo de esta manera múltiples estrategias para la transmisión de este tipo de formatos, la más difundida en este medio se conoce como streaming.

2.1 Servicios de Streaming

En la actualidad el proceso de transmisión de información multimedia se conoce como streaming, el cuál trata de integrar audio y vídeo.

Gracias a la difusión del Streaming en la actualidad las personas se están volviendo dependientes de ciertas herramientas de reproducción las cuales ofrecen ciertas utilidades como guías de radio, skins, actualizaciones permanentes para varios tipos de archivos, pero esto conlleva a que se tengan que realizar estas actualizaciones para poder usar el reproductor y tener que incurrir en costos solamente para que la herramienta funcione bien, entonces se espera que el sistema se desarrolle basándose en un modelo libre, en donde las herramientas utilizadas no tendrán un costo para el usuario, y no será necesario estar realizando actualizaciones constantemente.

En esta medida se desarrollaron protocolos que sirvieran como canal de comunicación entre las aplicaciones desarrolladas para realizar a cabalidad este ejercicio, por ende fue asi como surgieron entidades y empresas involucradas en este proceso para la creación de dispositivos que soporten este tipo de transmisión, en la actualidad la mayoría de estas ciones se basan en estos estándares y recomendaciones dadas también por los RFC´s ². A continuación se presentan trabajos relacionados en esta área para detemrinar la conformación de una arquitectura multimedial.

3. Protocolos de comunicación multimedial

Según Moreno [5] en los últimos años, los protocolos de señalización para el servicio de transmisión de voz han experimentado una fuerte evolución junto con la tendencia a trasportar dicho tráfico desde las redes de conmutación de circuitos hacia las redes de conmutación de paquetes. Esta tendencia queda reflejada con la fuerte evolución de estándares en este ámbito y la aparición de productos en el mercado que cubren las necesidades de operadores, grandes empresas y PYMES, es por ello, que existen desarrollos ajustados a formatos y aplicaciones propietarias que cubren parcialmente estas necesidades,operacionalizando en este sentido todo tipo de control de flujo hacia Internet.

Las entidades que más apoyaron el desarrollo de estos protocolos y estándares para este tipo de comunicaciones fueron la ITU, IETF, ISO, ANSI y forums apoyados por RFC. Para el desarrollo de los mismos y cumplir su cometido que es la transmisión de Voz sobre IP, actualmente existen dos protocolos principales orientados a la telefonía IP. El primero en aparecer fue el conjunto de protocolos H.323 estandarizados por el ITU y que supuso una primera aproximación a la telefonía IP. En la actualidad este protocolo esta siendo superado en popularidad por SIP [6]. Se trata de un protocolo de nivel de aplicación desarrollado por el IETF que ha sido diseñado con la idea de una fácil implementación, buena escalabilidad y flexibilidad. A pesar de ello, el protocolo SIP presenta una serie de problemas ante los firewalls y los sistemas de traducción de direcciones (NAT) [7].

3.1. Protocolos de Tiempo Real sobre IP

Debido a las dificultades que existen para poder transmitir información multimedia en tiempo real a través de Internet, las principales empresas implicadas en estas tareas, así como los organismos de Internet que tienen como misión la búsqueda de nuevos estándares, su desarrollo y correcta implementación, se pusieron manos a la obra para encontrar un sistema más fiable para poder utilizar Internet como soporte para este tipo de emisiones. Con este objetivo, se han desarrollado los protocolos:

• RTP (Real-time Transport Protocol)
• RTCP (Real-time Control Protocol)
• RSVP (Resource Reservation Protocol)
• RTSP (Real Time Streaming Protocol).

Con especial atención se va a llevar a cabo una explicación profunda de RTP, que es uno de los protocolos más importantes para el soporte de transmisiones de tipo multimedia.

3.1.1. RTP

RTP (Real-Time Transport Protocol), es un protocolo encargado de realizar transmisión y recepción de flujos de infor mación multimedial en tiempo real; es utilizado para realizar transmisiones multimediales bajo demanda en internet, un claro ejemplo de ello es VoIP y tiene como objetivo la entrega de datos en tiempo real, incluyendo emisiones de audio y vídeo bajo redes unicast y multicast.

RTP Proporciona servicios de entrega punto-a-punto en la red para transmisión de datos en tiempo real. RTP es independiente de la red y los protocolos de transporte, aunque sea utilizado muchas veces encima de UDP.

El protocolo RTP es utilizado generalmente so bre UDP, segmen tos de datos de video o audio son generados por el transmisor de la aplicación multimedia, estos segmentos son encapsulados en paquetes RTP, y cada paquete RTP es luego encapsulado en segmentos UDP. Según casas en su tesis de maestria [8] RTP provee servicios a la capa de aplicación y por lo tanto puede ser visto como una subcapa de la capa de transporte, como se muestra en la figura 1.

Desde la perspectiva del desarrollador, RTP no forma parte de la capa de transporte. Para el desarrollador, RTP forma parte de la capa de aplicación, por lo tanto se debe escribir el código que encapsula los segmentos de contenido multimedia en paquetes RTP para que la aplicación envíe luego estos paquetes por medio de un socket UDP.

Para realizar este proceso, el proyecto se baso en un API de SUN llamado Java Media Framework (JMF), a continuación se presenta parte de la arquitectura de esta plataforma y el encapsulamiento que trabaja a nivel UDP en su versión 2.1.1 [9].

Esta API se diseño específicamente para trabajar de manera transparente con la captura, presentación y las capacidades de proceso de cada stream enviado. La base de esta aplicación se fundamenta en el protocolo RTP y la libreria JMF para crear la conexión entre el servidor de audio y los clientes, el desarrollo principal sobre el API fue la creación de dos tipos de aplicaciones: servidor y receptor, al igual que la creación de una arquitectura que permitiera administrar todas las trasnmisiones en multicast como se desea realizar, estos resultados se presentan más adelante.

3.1.1.1. Problemas de transmisión RTP

Según Pinedo [10] existen problemas derivados de la propia naturaleza de las redes IP, el enrutamiento best-effort y la falta de QoS que garanticen la calidad de las comunicaciones en tiempo real sin la necesidad de un sobredimensionamiento en los recursos de red y equipos conmutadores, por otro lado se encuentra el problema del control de flujo de datos con el protocolo RTP, ya que los puertos se escogen dinámicamente al establecerse una nueva conexión. Esto supone un serio problema para empresas que lleven a cabo políticas restrictivas de filtrado, más sin embargo son alternativas que se plantean para mejorar el API y la plataforma planteada. Una forma de evitar estos problemas con el flujo RTP consiste en no filtrar los puertos por encima del 1024, ya que RTP selecciona puertos por encima de ese número. Esto en muchos casos puede resultar una solución inaceptable desde el punto de vista de seguridad de una red privada.

Teniendo en cuenta que RTP no provee ningún mecanismo para garantizar la entrega ni para garantizar el orden de arribo de los paquetes, debido a que su encapsulamiento sólo es visto en las "puntas" del sistema (equipos terminales), se desarrollaron mecanismos y algoritmos para tratar de dar un control a este tipo de inconvenientes, uno de los más conocidos dentro de los algoritmos distribuidos y el más representativo en esta rama es MidCom [11].

4. Protocolos de enrutamiento para tráfico multicast sobre internet

Para realizar comunicación de medios en una red se utilizan varios métodos dependiendo del tipo de servicio que se valla a ofrecer. Los más difundidos son:

• Comunicaciones Unicast (unidifusión)
• Comunicaciones Broadcast (difusión)
• Comunicaciones Multicast (multidifusión).

4.1. Transmisión unicast

El modo de transmisión Unicast, se caracteriza porque para cada cliente conectado al servidor se establece un canal único de comunicación entre ambos, que consume parte del ancho de banda disponible. Esta conexión independiente permite la interacción del usuario ó dispositivo conectado a un extremo. Los paquetes (transmisión TCP/IP) van todos asignados con la IP de destino. Unicast es comunicación entre un solo emisor y un solo receptor sobre un ambiente de red.

El efecto que tiene el método de transmisión unicast sobre los recursos de la red es de consumo acumulativo. Cada usuario que se conecta a una transmisión multimedia consume tantos kbps (kilobits por segundo) como la codificación del contenido lo permita. De este modo se obtienen varios modos finales de emisión:

4.1.1. Unicast bajo demanda

Cada cliente tiene un canal propio y por él se envía una copia del contenido que haya solicitado dando independencia a cada usuario, pero consumiendo ancho de banda. La transmisión bajo demanda es la reproducción de contenido pre-grabado, almacenado, y disponible para consultarse en cualquier momento.

4.1.2. Unicast en vivo

La transmisión en vivo reproduce en la computadora del usuario el audio y video de un evento a medida que éste se desarrolla en el sitio de origen. Cada cliente consume un trozo del ancho de banda pero no se permite la interacción con el emisor, es decir solamente permite comunicación en un solo sentido.

4.2. Transmisión broadcast

Se emite en lo que se considera alcance mundial, es decir, para todo el mundo que quiera recibirlo. Tanto el broadcast como el multicast tienen un gran parecido, siendo su diferencia el alcance de la emisión, el número de routers por los que ha de pasar el paquete, viene dado por el número TTL 3. Se pueden encontrar ejemplos de este tipo de transmisiones en algunos de los protocolos de enrutamiento.

Broadcast parece una solución para transmisión multimedia, pero no es la obvia, puesto que funciona bien dentro de entornos de área local, y a raiz de esto puede ocasionar problemas cuando se realizan broadcast de paquetes que deben ser enviados a través de diferentes LAN_s.

4.3. Transmisión multicast

El concepto de transmisión Multicast en IP surge hace aproximadamente 20 años con la definición de IGMP Versión 0 [12]. Desde ese momento, el ámbito de operación de las aplicaciones multicast ha sido restringido a las redes locales e intrarredes.

La mayor experiencia en routing multicast ha sido "Multicast Backbone" o Mbone (Backbone de multidifusión). Utiliza el protocolo IP multicast. Por ende en 1992 se pone en marcha el MBone [13], que siendo experimental en un principio, en la actualidad se considera indispensable para decenas de miles de usuarios. Desde ese momento, el interés de los usuarios en aplicaciones multicast ha crecido enormemente, constituyendo un desafío la extensión del soporte multicast a toda la Internet.

4.3.1. Multicast al interior de una red

Existen dos estrategias básicas a nivel de enlace:

• Utilizar tramas de broadcast o utilizar tramas especiales. Una red Ethernet [14] (y otras tecnologías4) soportan multicast a nivel de enlace.
• Las tarjetas son capaces de escuchar en una o varias direcciones Ethernet multicast.

4.3.2. Problemas en la transmisión multicast

Existen varios problemas en una transmisión multicast [15], todos debidos a la naturaleza de la misma. Como primer problema, encontramos que una dirección multicast nunca puede ser una dirección de destino, es decir, los clientes no podrán transmitir información al servidor por medio del canal. Por supuesto, este problema no es significativo, dado que nuestra finalidad es la de conseguir un sistema capaz de acomodar a cuantos clientes sean necesarios.

Una comunicación multicast requiere de routers multicast que soporten encapsulamiento IP sobre IP [16], para poder llevar a cabo los paquetes del emisor al receptor sin que routers intermedios los desechen.

Todos los protocolos de enrutamiento multicast hacen uso del protocolo IGMP para conocer la filiación de los equipos finales a cada determinado grupo multicast, pero difieren en la forma de intercambiar dicha información entre mrouters vecinos, así como en las técnicas empleadas en la construcción de los árboles de distribución. En cuanto a los algoritmos empleados por los protocolos de enrutamiento multicast, su descripción es compleja y está fuera del propósito de este artículo el proporcionar una explicación de los mismos. Se puede hallar más información en la referencia [17] [19]

Hay que resaltar que los protocolos de enrutamiento multicast son, por lo general, bastante más complejos que sus homólogos en unicast, y por otro lado su desarrollo ha sido más tardío, por lo que aún presentan mayores deficiencias, sobre todo cuando se aplican a redes complejas y no digamos a toda la Internet. Sin embargo su evolución ha sido más rápida, debido en gran medida, al gran interés que ha despertado, en función de sus enormes posibilidades de aplicación, tanto en redes académicas como entre las grandes y pequeñas empresas relacionadas con el sector de las telecomunicaciones. También, por qué no, por la presión de usuarios finales y empresas que hacen uso de Internet en demanda de un medio multicast que permita ampliar sus horizontes de oferta de servicios multimedia de forma eficaz y económica.

5. Arquitectura planteada para el desarrollo del componente

Se propone una arquitectura de tres niveles, cada uno con funcionalidades básicas que van desde el nivel físico, el nivel lógico y el nivel de conocimiento; dentro del nivel físico (Infraestructura) se encuentra el soporte y el backbone mediante técnicas de enrutamiento planteados a nivel LAN-WAN-LAN a través de tráfico multicast, en el nivel lógico (servicios genéricos) se encuentra la lógica del negocio mediante una plataforma propuesta de tres capas (Producción, Distribución y Reproducción) y finalmente encontramos el nivel de capacidades y conocimiento, el cuál se deja planteado para evolución y mejoras de la misma arquitectura.

Dentro de los requerimientos analizados se tienen en cuenta elementos a nivel de comunicación mediante protocolos y dispositivos que cumplen su función como puente de comunicación, al igual de elementos esenciales para llevar a cabo a nivel de software el envío de formatos de audio.

Para llevar a cabo esta implementación dentro del modelo de comunicaciones TCP/IP se debe tener en cuenta protocolos que funcionan a nivel de red para llevar a cabo el enrutamiento del tráfico multicast, el protocolo de transporte para efectuar el envío de la información y los protocolos de aplicación para mantener una comunicación en tiempo real de los usuarios que son participes de una comunicación.

Del mismo modo no hay que olvidar la importancia del componente a implementar, el cuál cumple un papel importante a nivel de Aplicación dentro del modelo de comunicaciones TCP/IP; es por ello que la arquitectura que se propone para realizar la implementación cubre los aspectos desde el punto de vista arquitectónico a nivel de hardware mediante dispositivos de internetworking y a nivel de software mediante la creación de un componente que funcione como un servicio orientado hacia la Web que permita realizar una transmisión de audio.

5.1. Nivel de infraestructura

En este nivel se encuentran los dispositivos de internetworking los cuales son encargados de enrutar de manera óptima todo el tráfico multicast generado en una transmisión, prácticamente vendría siendo la base para llevar a cabo el modelo de una comunicación, por ello en este proyecto se realiza énfasis en los protocolos a nivel de routing implementados para llevar a cabo esta tarea.

Dentro del modelo de comunicaciones planteado, se tienen en cuenta varias áreas y temas del conocimiento a través de dos elementos primordiales, el hardware mediante dispositivos de internetworking y el software mediante el diseño de un componente de audio. Para llevar a cabo el transporte de este tipo de transmisión se necesitan de las autopistas de la información que permiten el tránsito de este tipo de formatos, para ello es necesario entender que la arquitectura propuesta tendrá que adaptarse a cambios que tengan que ver con su entorno.

A partir de este análisis, se pretende aprovechar las bondades de una buena transmisión mediante la implementación de protocolos de enrutamiento sobre dispositivos de internetworking para el transporte de tráfico multicast teniendo en cuenta los siguientes elementos [20]:

1. Conocimiento previo de la topología de red a implementar, para ello se baso en un modelo de arquitectura LAN-WAN-LAN simulando un entorno de trabajo de área Local mediante enlaces ethernet y de área extensa mediante enlaces seriales a través de encapsulamiento a nivel dos dentro del modelo de comunicaciones TCP/IP, HDLC mediante enrutadores Cisco Modelo 2511 y un Switch Cisco Catalyst Modelo 2900. Tener en cuenta que los enrutadores como los switches de capa 2 soportan tráfico IP- Multicast. Para los switches de capa 2 esto es opcional, pero el no soportarlo puede significar un bajo desempeño de la red en situaciones de alto tráfico.

2. Verificar que los enrutadores además de soportar IP-Multicast soporten el protocolo que los valla a enrutar, en este caso la determinación de utilizar PIM-Sparse Dense Mode.

3. Verificar que los equipos de redes pueden soportar IP-Multicast sin degradar su desempeño. Esto varia dependiendo del tamaño de la red y el número de fuentes de multicast.En general se recomienda una red de multinivel (Capa 3 en core/distribución,Capa 2 en acceso) y sin concentradores de ethernet (hubs), además se recomienda que la capa 2 este basada en la familia Ethernet (Ethernet, fastEthernet, Gigabitethernet, 10G), esto es porque el IP-Multicast se adapta muy bien a ambientes de red de acceso múltiple al medio con broadcast; mientras que para redes punto a punto, multipunto, o acceso múltiple al medio sin broadcast.

4. Para implementar sobre red de alta velocidad Renata, es necesario su aplicación sobre la red regional Rumbo para que de esta forma se realice el intercambio de tráfico mediante BGP5 y que el enrutador con la conexión soporte MBGP (multicast BGP) y Multicast Source Discovery Protocol (MSDP), que son protocolos para soporte de tráfico multicast hacia sistemas Interdominio, adicionalmente migrar direcciones Ipv4 sobre Ipv6.

5.2. Nivel de servicios genéricos

En este nivel se encuentra la lógica del negocio, representado mediante la distribución del modelo de comunicaciones, en el se encuentran los servicios esenciales para establecer una comunicación como es el caso del web service, el cuál permitirá trabajar sobre el componente de software y establecer una comunicación mediante protocolos de comunicación en tiempo real como lo es RTP y RTCP a través de técnicas conocidas como encapsulamiento. Para el diseño del web service se tuvo un modelo de tres capas.

Dentro de los servicios genéricos encontramos la lógica del negocio, es decir el desarrollo del componente que nos permitirá establecer una comunicación en tiempo real.

Para su desarrollo se tuvo en cuenta una arquitectura de tres niveles, en donde encontramos: producción, distribución y reproducción, este modelo se representa a continuación en la siguiente figura:

La lógica de estos tres niveles responde la pregunta de mantener una comunicación mediante un servidor de aplicaciones, en donde podemos determinar las siguientes características:

1. Capa de Producción: En esta capa se realiza la captura de audio en vivo y bajo demanda, esto a través del componente encargado de establecer un diálogo mediante los codecs de audio utilizados.

2. Capa de Distribución: Implementación de un servicio que permita realizar transmisión de audio, en este nivel se realiza la distribución de los formatos a trabajar y la implementación de los codecs y protocolos necesarios para determinar el establecimiento de conexiones de los usuarios al aplicativo y la cantidad de información compartida por parte del componente.

3. Capa de Reproducción: Como su mismo nombre lo indica, es el cliente encargado de mantener una comunicación mediante el servidor de streaming para realizar recepción de audio emitido por el usuario iniciador de la comunicación. Dentro de esta capa se presenta la fase de representación de los datos enviados por la red, esto mediante la utilización de reproductores e identificadores de codecs de audio que realizan el proceso inverso de reensamble de paquetes y verificación de paquetes de audio que llegan mediante IP.

Para determinar la construcción del componente existe un elemento primordial y es el soporte de comunicaciones en tiempo Real, para ello es necesario poder determinar e implementar un proceso de encapsulamiento a nivel TCP/IP para realizar este tipo de transmisiones, en el siguiente apartado se presentan las características necesarias para su construcción.

5.3. Nivel de capacidades y conocimiento.

Esta es la parte de evolución del proyecto, este nivel se deja totalmente abierto para que el componente sea lo suficientemente robusto para adaptarse a elementos de conocimiento mediante implementación de componentes semánticos que les permitan tomar decisiones del tipo de contenido que el usuario desea escuchar o de la transmisión que se desea plantear.

Es de resaltar que para llegar a este nivel se requieren de elementos dinamizadores que se salen del tema central de este proyecto, mas sin embargo se plantea de esta manera para que el dispositivo pueda evolucionar y trabajar con más elementos en su entorno.

6. Encapsulamiento RTP en el componente

Para que el cliente empiece a recibir flujo de información en tiempo real, no tiene que tener toda la información disponible, ya que puede escuchar los flujos de audio mientras esta recibiendo la información; como cada flujo no puede tener un tiempo fijo para terminar entonces la descarga del total de flujo requerido puede llegar a ser imposible. Los medios que fluyen a raíz del término de streaming media se utilizan a menudo para referir a esta técnica de entregar el contenido sobre la red en tiempo real y el contenido en tiempo real de los medios se entrega.

Este tipo de encapsulamiento se implemento bajo el esquema y funcionamiento de un API desarrollada por SUN llamado Java Media Framework (JMF) que brinda los servicios del protocolo RTP. Las cabeceras de este protocolo contienen la información necesaria para sincronizar la imagen y el vídeo y determinar si se han perdido paquetes o han llegado en desorden. En una sesión multimedia, cada medio es llevado a través de una sesión RTP por separado, con sus propios paquetes RTCP informando de la calidad de recepción en ese momento. Por ejemplo en una emisión multimedia, el audio y el vídeo pueden viajar por separado (en sesiones RTP distintas) permitiendo al receptor seleccionar qué es lo que quiere recibir.

7. Resultados de arquitectura IP multicast

Para implementar una arquitectura IP multicast, se utilizó el protocolo PIM Sparse dense Mode, bajo la propuesta del doctor Donoso en su tesis doctoral [21], con este protocolo se elimina el tráfico innecesario de tipo multicast sobre enlaces WAN, permitiendo una mayor utilización de recursos y enlaces dedicados a este tipo de transmisiones. Teniendo en cuenta estos resultados se deter mino implementar el algoritmo de enrutamiento PIM en sus dos modalidades:

1 De modo denso, pues según estudios realizados por Donoso, los protocolos Dense Mode están diseñados para trabajar sobre redes preferiblemente con un ancho de banda amplio y los miembros del grupo están densamente distribuidos a través de la red.

2 De modo Disperso, ya que en este caso los miembros del grupo están ampliamente dispersos a través de la red. Este tipo de protocolo se caracteriza por usar árboles compartidos (llamados puntos de reunión o Rendezvous Point, RPs) en donde los receptores escuchan al router origen y mantienen el estado del árbol multicast. Por cada grupo multicast existe un árbol compartido.

Se realizó la implementación utilizando las bondades de estos dos modos de manera híbrida, es decir de modo denso y disperso, con el fin de poder definir ambos ambientes de trabajo sobre Internet según la topología de la red. Además la característica primordial de esta implementación es la utilización de RP (Rendezvous Point) o puntos de reunión donde se concentran la mayor cantidad de grupos de multidifusión de manera óptima para enrutar este tipo de tráfico.

Dentro de la implementación realizada se recomienda que los RP sean descubiertos de forma automáticos por los enrutadores de tal forma que el proceso sea más eficiente y a prueba de fallos. El protocolo que se recomienda es el Bootstrap Router (PIMv2) [22]. Aunque este protocolo es un poco más complejo que el Auto-RP (propietario de Cisco) asegura la interoperabilidad con enrutadores de otras marcas. Esto además de evitar la configuración estática de los RPs y asegura una redundancia en caso de falla de los RP_s.

Estos resultados obtenidos, junto con el modelo arquitectónico propuesto dan las bases necesarias para tener en cuenta la relación de futuros proyectos orientados al tráfico multimedia sobre Internet, teniendo en cuenta aspectos que van desde el punto de vista de hardware de interoperabilidad, como tambien el software de protocolo encargado de encausar todas las peticiones de tipo multimedial. A continuación se presentan algunas de las conclusiones más importantes producto de los resultados obtenidos en el proyecto, las mejoras que se pueden hacer para posibles implementaciones a futuro y problemas relacionados durante el desarrollo del mismo.

8. Conclusiones

Las transmisiones multimedia requieren de un fuerte valor prestacional de la red, el cuál involucra su parte topológica como la disposición de la misma en cuanto al ancho de banda a utilizar, parte del éxito que se tenga en este tipo de transmisiones se basa en los formatos que se desean transmitir y el tipo de codificador a implementar.

Si bien en la actualidad se presentan variadas formas de comunicación en tiempo real mediante software propietario, cada una de ellas en el fondo presenta un modelo de desarrollo complejo que implica de cierta manera tiempo adicional por parte del usuario para descargar paquetes adicionales como plugins en Internet para poderlas compilar y de esta forma reproducirlas.

Dentro del modelo de comunicaciones planteado bajo una arquitectura de desarrollo de tres capas, dentro de la capa de lógica del negocio se tuvo en cuenta el API de JMF desarrollada por SUN Microsystem, esta API nos proporciona el modelo de comunicación básico para determinar elementos necesarios de transmisión como lo son los tipos de encoders y tiempos de sampleo del audio para su posterior reproducción.

Se propuso un esquema de funcionamiento cliente-servidor mediante el desarrollo de un cliente cambiando toda la lógica del negocio, esto mediante la implementación de un modelo de tres capas: Producción, distribución y reproducción, y teniendo como base el modelo de comunicaciones mediante web service.

Las transmisiones multicast reducen notoriamente el porcentaje de utilización de la red en cuanto a ancho de banda se refiere, lo que indica que el encapsulamiento de direcciones IP multicast sobre direcciones IP unicast reduce la utilización del ancho de banda en una red corporativa, al igual que los resultados obtenidos por [21], independientemente de la velocidad con la que se cuente hacia Internet, lo que arrojó buenos resultados del modelo arquitectónico plateado y de la lógica del negocio trabajada.

Uno de los problemas fuertes que se tiene al realizar transmisiones de tipo multicast es garantizar un ancho de banda óptimo sin llegar a saturar la red, por lo tanto según lo planteado por Servin [20] es importante definir los tipos de dispositivos de internetworking involucrados en este proceso y su soporte para este tipo de tráfico; esto junto con elementos a nivel de software que proporcionen un soporte adecuado (que fue uno de los resultados arrojados del proyecto), garantizan su buen funcionamiento al adaptar APIs para su operación sobre cualquier tipo de arquitectura a nivel operativo.

Referencias bibliográficas

[1] Retana, Alvaro Russ White. Advanced IP Network Design (CCIE Professional Development). - CCIE Cisco Press. 1999

[2] T. Verma, A Perceptually Based Audio Signal Model with Application for Scalable Audio Compression, PhD thesis, Stanford University, Palo Alto California, 1999.

[3] S. Levine, Audio Representations for Data Compression and Compressed Domain Processing, PhD thesis, Stanford University Palo Alto California, 1998.

[4] K. Hamdy, et al., "Low bit rate high quality audio coding with combined harmonic and wavelet representations", in Proc. ICASSP, May 1996.

[5] Moreno, Jose Ignacio, Protocolos de Señalización para el transporte de Voz sobre IP. Proyecto PISCIS, Universidad Carlos III. Madrid. 2001.

[6] Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP). RFC 4453. Abril 2006.

[7] Best Current Practices for NAT Traversal for SIP. Internet Draft, IETF, draft- ietf-sipping-nat-scenarios-02. Abril 2005.

[8] Casas, Hernández. Calidad de Servicio Percibida en Servicios de Voz y Video sobre IP. Tesis de Maestria Universidad de la República. 2005

[9] JMF. Java Media Framework disponible en: http://java.sun.com/products/ java-media/jmf [Consulta: Abril 2007]

[10] Christian Pinedo, Oihane Lorente, Eduardo Jacob, Puri Saiz, Marina Aguado. Arquitectura de una solución de Voz sobre IP real compatible con NAT. Departamento de Electrónica y Telecomunicaciones, Universidad del País Vasco, España. 2001.

[11] Middlebox communication architecture and framework. RFC 3303. Agosto 2002

[12] Brian M. Edwards; Leonard A. Giuliano; Brian R. Wright. Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions. Cisco Press. 2002

[13] Brian Adams; Ed Cheng; Tina Fox; Andy Kessler; Mark Manzanares; Bryan Mclaughlin; Jim Rushton; Beverly Tai; Kevin Tran. Interdomain Multicast Solutions Guide. Cisco Press 2002.

[14] Broadcasting Internet Datagrams. RFC 919. 1996.

[15] Halabi, Sam. Internet Routing Architectures, Second Edition. Cisco Press. 2000.

[16] Encapsulation withing IP. RFC 2003. 1996

[17] Grevers Jr Ted.; Joel Christner. Application Acceleration and WAN Optimization Fundamentals. CCIE No. 15311 Cisco Press. 2007

[18] Alex Zinin. Cisco IP Routing: Packet Forwarding and Intra-domain Routing Protocols. Addison Wesley Professional. ISBN-10: 0-201-60473-6 Pages: 656 Pub [October 30, 2001]

[19] Vivek Alwayn. Advanced MPLS Design and Implementation. - CCIE #2995 Cisco Press. 2001.

[20] Arturo Servin. Arquitectura de IP Multicast para backbone de Internet 2 en México. Tecnologico de Monterey 2002.

[21] Yezid Donoso, Jose Luis Marzo. Una Propuesta para la especificación de Multidifusión IP sobre MPLS con Calidad de Servicio. Universidad de Girona. 2002.

[22] Williamson, Developing Multicast Architecture Ed. Prentice Hall Cisco 2001.

Álvaro Espinel Ortega
Ingeniero eléctrico, Universidad Nacional de Colombia. Magíster en teleinformática, Universidad Distrital Francisco José de Caldas. Estudiante del doctorado en ingeniería informática de la Universidad Pontificia de Salamanca, España. Se desempeña como docente en la Universidad Distrital. Actualmente es director del grupo de investigación GESETIC, Universidad Distrital.

Paulo Alonso Gaona García
Ingeniero de sistemas, Universidad Distrital Francisco José de Caldas. Magíster en ciencias de la información y las comunicaciones con énfasis en Teleinformática, Universidad Distrital. Se desempeña en temas de investigación en el grupo de investigación Ontare en temas relacionados en el área de redes y comunicaciones, transmisión multicast, evaluación y desempeños de formatos multimedia.