Actualizado el 16/05/2002

RedIRIS © 1994-2008

• Servicios

Tecnologías de red

H.320

Introducción

            El protocolo H.320 define el estándar para vídeoconferencia sobre RDSI y otros medios de transmisión sobre banda estrecha definidos por la ITU (International Telecommunications Union).  Este protocolo define un “paraguas”  que comprenden tres grupos de protocolos, cada uno de los cuales atiende a una necesidad dentro de la videoconferencia, a saber: H.261 para vídeo, G.711, G.722 y G.728 para audio y T.120 para datos.

Arquitectura H.320

H.261 es un formato de compresión de vídeo para ser usado en canales que vayan de  64 Kbits a 2 Mbits. También llamado px64  donde p es  un rango comprendido entre 1 y 30 (los múltiplos que puede tener  un canal B. Este algoritmo utiliza la codificación tanto intratrama como intertrama. La primera utiliza DCT (Discrete Cosine Transform), similar a la utilizada por JPEG. La segunda por su parte utiliza un esquema de codificación basado en las diferencias entre bloques. H.261 define a su vez dos tamaños de ventana CIF (Common Intermediate Format) con una resolución de 352 x 288 y QCIF (Quarter CIF) con una resolución de 176 x 144.

En cuanto a los protocolos de audio soportados por H.320 (G.711, G.722 y G.728) diseñados para  distintas necesidades de audio. G.711 utiliza la codificación PCM proporcionando calidad de audio a 64 Kbits (en el tramo de 3 KHz). G.722 es idéntico al anterior pero a 7 Khz. El último utiliza 16 Kbits a 3Khz.

H.221 define la estructura de las tramas para comunicaciones sobre canales de 64 a 2 Mbits. Las tramas tienen un tamaño de 80 bytes de longitud. Cada byte contiene audio, vídeo y datos multiplexados, generados por otros protocolos de la norma H.320. Tal como construye la trama la norma H.221 se puede decir que utiliza un cuarto del canal para audio, otro cuarto para datos y la mitad para la señal de vídeo.

H.231 define el estándar para multipunto y cifrado de datos. Cuando se utiliza la utilidad multipunto entra en juego la MCU (Multipoint Central Unit) . cada uno de los participantes utilizará entonces los protocolos H.242 y H.243 para intercambio de información con ésta. Durante esta comunicación, la MCU guarda los datos acerca de formatos de vídeo (CIF, QCIF), tipo de codificación de audio soportado por cada uno de los clientes. Una vez conseguida esa información, establecerá conexiones con cada uno de ellos de acuerdo a los datos conseguidos.

           

H.323

Introducción

El estándar H.323 proporciona una base para las comunicaciones de audio, video y datos a través de una red IP como Internet. Los productos que cumplen con el estándar H.323 pueden ínteroperar con los  productos de otros, permitiendo de esta manera que los usuarios puedan comunicarse sin preocuparse con problemas de compatibilidad.

H.323 es un estándar bajo el amparo de la ITU, es un conjunto de estándares para la comunicación multimedia sobre redes que no proporcionan calidad de servicio (QoS). Estas redes son las que predominan hoy en todos los lugares, como redes de paquetes conmutadas TCP/IP e IP sobre Ethernet, Fast Ethernet y Token Ring. Por esto, los estándares H.323 son bloques importantes de construcción para un amplio rango de aplicaciones basadas en redes de paquetes para la comunicación multimedia y el trabajo colaborativo.

El estándar tiene amplitud e incluye desde dispositivos específicos hasta tecnologías embebidas en ordenadores personales, además de servir para comunicación punto-punto o conferencias multi-punto. H.323 habla también sobre control de llamadas, gestión multimedia y gestión de ancho de banda, además de los interfaces entre redes de paquetes y otras redes (RTC p.e.)

H.323 forma parte de una gran serie de estándares que permiten la videoconferencia a través de redes. Conocidos como H.32X, esta serie incluye H.320 y H.324, que permiten las comunicaciones RDSI y RTC respectivamente.

Arquitectura H.323

La Recomendación H.323 cubre los requerimientos técnicos para los servicios de comunicaciones entre Redes Basadas en Paquetes (PBN) que pueden no proporcionar calidad de servicio (QoS). Estas redes de paquetes pueden incluir Redes de Área Local (LAN’s), Redes de Área Extensa (WAN), Intra-Networks y Inter-Networks (incluyendo Internet). También incluye conexiones telefónicas o punto a punto sobre RTC o ISDN que usan debajo un transporte basado en paquetes como PPP. Esas redes pueden consistir de un segmento de red sencillo, o pueden tener topologías complejas que pueden incorporar muchos segmentos de red interconectados por otros enlaces de comunicación.

La recomendación describe los componentes de un sistema H.323, estos son: Terminales, Gateways, Gatekeepers, Controladores Multipunto(MC), Procesadores Multipunto (MP) y Unidades de Control Multipunto (MCU)

Terminales

Los terminales son puntos finales de la comunicación. Proporcionan comunicación en tiempo real bidireccional. Los componentes de un terminal se pueden ver a continuación:

Para permitir que cualesquiera terminales ínter operen se define que todos tienen que tener un mínimo denominador que es, soportar voz y con un codec G.711. De esta manera el soporte para video y datos es opcional para un terminal H.323.

Todos los terminales deben soportar H.245, el cual es usado para negociar el uso del canal y las capacidades. Otros tres componentes requeridos son: Q.931 para señalización de llamada y configuración de llamada, un componente llamado RAS (Registrantion/Admisión/Status), este es un protocolo usado para comunicar con el Gatekeeper; y soporte para RTP/RTCP para secuenciar paquetes de audio y video.

Otros componentes opcionales de los terminales H.323 son: los codec de video, los protocolos T.120 para datos y las capacidades MCU.

Gateways

El Gateway (o Pasarela) es un elemento opcional de una conferencia H.323. Es necesario solo si necesitamos comunicar con un terminal que está en otra red (por ejemplo RTC) Los Gateways proporcionan muchos servicios, el más común es la traducción entre formatos de transmisión (por ejemplo H.225.0 a H.221) y entre procedimientos de comunicación (por ejemplo H.245 a H.242). Además el Gateway también traduce entre los codecs de video y audio usados en ambas redes y procesa la configuración de la llamada y limpieza de ambos lados de la comunicación.

El Gateway es un tipo particular de terminal y es una entidad llamable (tiene una dirección).

En general, el propósito del Gateway es reflejar las características del terminal en  la red basada en paquetes en el terminal en la Red de Circuitos Conmutados (SCN) y al contrario. Las principales aplicaciones de los Gateways son:

·         Establece enlaces con terminales telefónicos analógicos conectados a la RTB (Red Telefónica Básica)

·         Establecer enlaces con terminales remotos que cumple H.320 sobre redes RDSI basadas en circuitos conmutados (SCN)

·         Establecer enlaces con terminales remotos que cumple H.324 sobre red telefónica básica (RTB)

Los Gateways no se necesitan si las conexiones son entre redes basadas en paquetes.

Muchas funciones del Gateway son dejadas al diseñador. Por ejemplo, el número de terminales H.323 que pueden comunicar a través del Gateway no es asunto de estandarización. De la misma manera el número e conexiones con la SCN, el número de conferencias individuales soportadas, las funciones de conversión de audio/video/datos, y la inclusión de funciones multipuntos son dejadas al diseñador. Debido a la incorporación de los Gateways a la especificación H.323, la ITU posicionó H.323 como el pegamento que junta todos los terminales para conferencias funcionando juntos.

 

Gatekeepers

Son un elemento opcional en la comunicación entre terminales H.323. No obstante, son el elemento más importante de una red H.323. Actúan como punto central de todas las llamadas dentro de una zona y proporcionan servicios a los terminales registrados y control de las llamadas. De alguna forma, el gatekeeper H.323 actúa como un conmutador virtual.

Los Gatekeepers proporcionan dos importantes funciones de control de llamada:

·         Traducción de direcciones desde alias de la red H.323 a direcciones IP o IPX, tal y como está especificado en RAS.

·         Gestión de ancho de banda, también especificado en RAS. Por ejemplo, si un administrador de red a especificado un umbral para el número de conferencias simultáneas, el Gatekeeper puede rechazar hacer más conexiones cuando se ha alcanzado dicho umbral. El efecto es limitar el ancho de banda total de las conferencias a alguna fracción del total existente para permitir que la capacidad remanente se use para e-mail, transferencias de archivos  y otros protocolos.

A la colección de todos los Terminales, Gateways y MCU’s gestionados por un gatekeeper se la conoce como Zona H.323. Ver figura.

Una característica opcional, pero valiosa de los gatekeepers es la habilidad para enrutar llamadas. Si se enruta la llamada por un gatekeeper, esta puede ser controlada más efectivamente. Los proveedores de servicio necesitan esta característica para facturar por las llamadas realizadas a través de su red. Este servicio también puede ser usado para re-enrutar una llamada a otro terminal en caso de estar no disponible el llamado. Además con esta característica un gatekeeper puede tomar decisiones que involucren el balanceo entre varios gateways. Por ejemplo, si una llamada es enrutada por un gatekeeper, ese gatekeeper puede re-enrutar la llamada a uno de varios gateways basándose en alguna lógica de enrutamiento propietaria.

Mientras que un Gatekeeper está lógicamente separado de los extremos de una conferencia H.323, los fabricantes pueden elegir incorporar la funcionalidad del Gatekeeper dentro de la implementación física de Gateways y MCU’s.

A pesar de que el Gatekeeper no es un elemento obligatorio, si existe, los terminales deben usarlo. RAS define para estos la traducción de direcciones, control de admisión, control de ancho de banda y gestión de zonas.

Los Gatekeepers juegan también un rol en las conexiones multipunto. Para soportar conferencias multipunto, los usuarios podrían emplear un Gatekeeper para recibir los canales de control H.245 desde dos terminales en una conferencia punto-punto. Cuando la conferencia cambia a multipunto, el Gatekeeper puede redireccionar el Canal de Control H.245 a un controlador multipunto, el MC. El Gatekeeper no necesita procesar la señalización H.245, solo necesita pasarla entre los terminales o entre los terminales y el MC.

Las redes que posean un Gateway pueden también tener un Gatekeeper para traducir llamadas entrantes E.164 (número de teléfono convencionales) a direcciones de transporte. Debido a que una Zona está definida por su Gatekeeper, las entidad H.323 que contengan un Gatekeeper interno necesitan de un mecanismo para desactivar su funcionamiento cuando hay varias entidades H.323 que contiene un Gatekeeper dentro de la red,  las entidades pueden ser configuradas para estar en la misma Zona.

Existen dos formas para que un terminal se registre en un gatekeeper, sabiendo su ip y enviando entonces un mensaje de registro unicast a esta dirección o bien enviando un mensaje multicast de descubrimiento del gatekeeper (GRQ) que pregunta ¿quién es mi gatekeeper?

Funciones obligatorias Gatekeeper

·         Traducción de Direcciones: Traducción de alias a direcciones de transporte, usando para ello una tabla que es modificada con mensajes de Registration. Se permiten otros métodos de modificar la tabla.

·         Control de Admisión: El Gatekeeper debería autorizar el acceso a la red usando mensajes H.225.0 ARQ/ACF/ARJ. Esto puede basarse en autorización de llamada, ancho de banda, o algún otro criterio que es dejado al fabricante. También puede ser una función nula que admita todas las peticiones.

·         Control de Ancho de Banda: El Gatekeeper debería soportar mensajes BRQ/BRJ/BCF. Esto puede usarse para gestión del ancho de banda. También se puede aceptar todas las peticiones de ancho de banda.

·         Gestión de Zona: El Gatekeeper debería suministrar la funciones anteriores a: todos los terminales, MCU’s y Gateways que se encuentren registrados en su Zona de control.

Funciones opcionales del Gatekeeper

·         Señalización de control de llamada: El Gatekeeper puede elegir completar la señalización de llamada con los extremos y procesar la señalización de llamada el mismo. Alternativamente, puede elegir que los extremos conecten directamente sus señalizaciones de llamada. De esta manera el Gatekeeper puede evitar gestionar las señales de control H.225.0.

·         Autorización de llamada: El Gatekeeper puede rechazar una llamada desde un terminal basándose en la especificación Q.931. (H.225.0) Las razones para rechazar la llamada pueden ser, pero no están limitadas a, acceso restringido desde o hacia un terminal particular o Gateway, y acceso restringido durante un periodo de tiempo. El criterio para determinar si se pasa la autorización o falla, está fuera del alcance de H.323.

·         Gestión de llamada: El Gatekeeper puede mantener una lista de las llamadas en curso, esta información puede ser usada para indicar si un terminal está ocupado o para dar información a la función de gestión de ancho de banda.

·         Otros como: estructura de datos de información para la gestión, reserva de ancho de banda y servicios de directorio.

Unidades Control Multipunto(MCU)

La MCU soporta conferencias entre tres o mas extremos. En terminología H.323, el MCU se compone de: Controlador Multipunto (MC) que es obligatorio, y cero o más Procesadores Multipunto (MP). El MC gestiona las negociaciones H.245 entre todos los terminales para determinar las capacidades comunes para el procesado de audio y video. El MC también controla los recursos de la conferencia para determinar cuales de los flujos, si hay alguno, serán multicast. Las capacidades son enviadas por el MC a todos los extremos en la conferencia indicando los modos en los que pueden transmitir. El conjunto de capacidades puede variar como resultado de la incorporación o salida de terminales de la conferencia.

El MC no trata directamente con ningún flujo de datos, audio o video. Esto se lo deja a el MP, este mezcla, conmuta y procesa audio, video y/o bits de datos. Las capacidades del MC y MP pueden estar implementadas en un componente dedicado o ser parte de otros componentes H.323, en concreto puede ser parte de un Gatekeeper, un Gateway, un terminal o una MCU.

El MP recibe flujos de audio, video o datos desde los extremos, estos pueden estar involucrados en una conferencia centralizada, descentralizada o híbrida. El MP procesa esos flujos y los devuelve a los extremos.

La comunicación entre el MC y el MP no es asunto de estandarización.

Conferencias Multipunto

Existen una variedad de métodos de gestionar las conferencia multipunto. La Recomendación hace uso de los conceptos de conferencia centralizada y descentralizada.

La conferencias centralizadas requieren de una MCU. Todos los terminales envían audio, video, datos y flujos de control a la MCU en un comportamiento punto-punto. La MC gestiona de forma centralizada la conferencia usando las funciones de control H.245 que también definen las capacidades de cada terminal. El MP mezcla el audio, distribuye los datos y mezcla/conmuta el video y envía los resultados en flujos de vuelta a cada terminal participante.

En conferencia multipunto descentralizadas se puede hacer uso de tecnología multicast. Los terminales H.323 participantes envían audio y video a otros terminales participantes sin enviar los datos a una MCU. Sin embargo el control de los datos multipunto sigue siendo procesado de forma centralizada por la MCU, y la información del canal de control H.245 sigue siendo transmitida de modo unicast a un MC.

Son los terminales que reciben múltiples flujos de audio y video los responsables de procesarlos. Los terminales usan los canales de control H.245 para indicar a un MC cuantos flujos simultáneos de video y audio son capaces de decodificar. El número de capacidades simultáneas de un terminal no limita el número de flujos de audio y video que son enviado por multicast en una conferencia.

Las conferencias multipunto híbridas usan una combinación de características de las centralizadas y descentralizadas. Las señalizaciones y cualquier flujo  de audio o video es procesado a través de mensajes punto a punto enviados a la MCU. Las restantes señales (audio o video) son enviadas a los participantes a través de multicast.

Una ventaja de las conferencias centralizadas es que todos los terminales soportan comunicaciones punto a punto. La MCU puede sacar varios flujos unicast a los participantes y no se requiere ninguna capacidad de la red especial. También es posible que la MCU reciba varios flujos unicast, mezcle el audio, y conmute el video, y saque un flujo multicast, conservando de esta manera el ancho de banda de la red.

H.323 también soporta conferencias multipunto mixtas en las cuales algunos terminales están en una conferencia centralizada, mientras otros están en una descentralizada, y una MCU proporciona el puente entre los dos tipos. Al terminal le es transparente la naturaleza mixta de la conferencia, solo tiene en cuenta el modo en que envía o recibe.

Multicast hace más eficiente el uso del ancho de banda de la red, pero supone una más alta carga computacional en los terminales que tienen que mezclar y conmutar entre los flujos de audio y video que reciben. Además, el soporte multicast es necesario en elementos de la red como routers y switches.

Un MC puede estar localizado en un Gatekeeper, un Gateway, un terminal o una MCU.

 

Multicast  

            El objetivo de este capítulo es describir brevemente la tecnología multicast y qué parámetros de configuración son aconsejables para su buen funcionamiento. El hecho de que una red soporte multicast es básico a la hora de plantearse la realización/difusión de contenidos multimedia dentro de una red corporativa o en la Internet, ya sea streaming o videoconferencia multicast.

Introducción

            El multicast (o multienvío) permite mandar paquetes IP a un conjunto de ordenadores situados en cualquier punto de la red. Este envío se realiza a una dirección de grupo[1]. Con este mecanismo conseguimos una serie de mejoras:

-          En el ancho de banda.

-          En la carga de los servidores.

-          En carga de la red. 

Básicamente, todas estas mejoras se derivan del hecho de que es la red la encargada de duplicar los paquetes en aquellos puntos que sean necesarios (donde haya clientes interesados en la información) por lo que el flujo origen no depende en ningún momento del número de clientes. Todo el mecanismo de solicitud de un flujo de información y réplica de ésta, será realizado por IGMP (Internet Group Management Protocol) y los protocolos de encaminamiento multicast. El proceso de mandar tráfico multicast no difiere en nada del unicast, salvo que la dirección destino es un poco “especial”. La diferencia radica en recibirlo. Ya que debe ser el cliente, el encargado de comunicar a su “router local” que desea recibir el tráfico de un grupo determinado.

Así, el modelo multicast se puede resumir en:

·         Los emisores envían información a una dirección de grupo (multicast).

·         Los receptores muestran su interés en una dirección de grupo.

·         Los routers interesados dirigen el tráfico desde los emisores a los receptores.

El protocolo IGMP fue desarrollado por Steve Deering y la versión 1 se definió en el RFC 1112. Una segunda versión con nuevas funciones fue reflejado en el RFC 2236. Este protocolo es el encargado de comunicar al router local que un cliente quiere recibir la información de un grupo o quiere abandonarlo[2]. En la actualidad, este protocolo no sólo se utiliza para este fin sino además, para que algunos protocolos de encaminamiento (como por ejemplo PIM-SP) intercambien información de control.

En cuanto al encaminamiento, los paquetes se distribuyen formando un árbol de distribución multicast. Existen distintas formas de crear estos árboles[3]. Los protocolos de encaminamiento se pueden dividir en varios tipos

·         Protocolos en modo denso (DVMRP, PIM-DM)

·         Protocolos en modo disperso (PIM-SP , CBT)

·         Protocolos “estado del enlace” (MOSPF)

En un principio, se utilizaba los primeros (sobre todos túneles que implementaban DVMRP). Pero en la actualidad se está produciendo el cambio a los segundos (PIM-SP)[4].

Una parte importante, es el control de los paquetes multicast. Este control se puede realizar de dos maneras: TTL (Time To Live) y “Administrative Scopes”.

Nivel de enlace

El proceso de paso de direcciones multicast de nivel tres a nivel dos, presenta el problema de solapamiento, debido al echo de que de los 28 bits (32 de la dirección IP menos 4 de 1110)  sólo se utilizan 23 para el paso a su equivalente a dirección MAC (ver figura 1). Esto da lugar a que una dirección multicast L3 da como resultado 32 direcciones multicast L2 (28 – 23).

 

Figura 1

Figura 2

Además, es interesante describir, como las redes de datos tratan el tráfico multicast para ver la manera de optimizarlo. Generalmente, los equipos activos de red (conmutadores) dejan pasar el tráfico multicast tal cual (como si se tratase de un broadcast), aunque no haya ningún cliente interesado en ese flujo en el equipo. Este funcionamiento “defectuoso” es debido, a que generalmente los conmutadores aprende las direcciones MAC en el campo origen del paquete. Pero como una dirección multicast nunca aparece en ese campo, el conmutador no la incluye nunca en su tabla.

Para remediar este problema (que entre otras cosas, origina una sobre carga de la red) existen una serie de protocolos que permiten corregir este mal funcionamiento. Los dos protocolos más utilizados son IGMP snooping y CGMP (Cisco Group Management Protocol). El primero hace que el conmutador intercepte los paquetes IGMP y actualiza sus tablas MAC, para la utilización de esta solución es necesario hardware especial (ASIC) en los equipos. El segundo permite que el router “entienda” las peticiones IGMP que realizan los clientes, y éste informa a los conmutadores del contenido de esos paquetes IGMP.

Vamos a ver un ejemplo de configuración del protocolo IGMP en los equipos CISCO (router y conmutador).

Router ( activar en cada uno de los interfaces que tengan configurado multicast).

ip cgmp

Catalys (no soportado en el 6000)

set cgmp en

set cgmp leave[5]

Básicamente, el router, enviará  paquetes CGMP a los conmutadores con  una dirección multicast destino predefinido (0100:ocdd:dddd que éstos anotarán en sus tablas). El paquete CGMP contiene: tipo de operación (join o leave), dirección MAC del cliente IGMP y dirección multicast del grupo.

Es conveniente describir  brevemente como funcionan los interface de red de los clientes. Las tarjetas de red realizan distintas técnicas de filtrado con el tráfico multicast:

·         La forma más sencilla llamada “single bit” consiste en la activación de un bit que acepta o rechaza el tráfico multicast  que le llega a la tarjeta. Este bit se activa en cuanto se una a un grupo multicast. Como por defecto para que uno pueda recibir este tipo de tráfico debe estar apuntado al grupo ALL-SYSTEMS (224.0.0.1) se recibirá todo el tráfico multicast que se genere en la red (tanto si está como sino interesado en él). Esto se pasará a los niveles superiores donde será descartado.

·         Otra técnica es la “hash table”. La tarjeta tiene una función hash para las direcciones multicast y utiliza un arrays de “bit flags”. Si el bit asociado a esa dirección se activa se recibe este tráfico. El tamaño de la tabla puede variar siendo su tamaño normal 64. Si se produce alguna colisión en una tabla, se borra el grupo en cuestión por lo que pasaría el tráfico a los niveles superiores.

·         Por último está el método en el que la tarjeta implementa una tabla que incluye exactamente las direcciones de los paquetes que se deberían aceptar. Es decir, sólo las direcciones  de los grupos apuntados pasaran al nivel superior.

 

Protocolo encaminamiento (PIM-SP)

Vamos a ver de forma resumida como configurar  PIM-SP en un  router CISCO y algunas consideraciones adicionales. Se elige este protocolo por ser el más utilizado como protocolo “intra-dominio” y el protocolo a utilizar dentro de la comunidad RedIRIS. La configuración propuesta supone la utilización de Auto RP[6]. No es objetivo de este documento entrar en los detalles  de funcionamiento del protocolo PIM-SP. Para una mayor información consulta la bibliografía.

Activación PIM-SP.

Ámbito global:

ip multicast-routing

En cada uno de los interfaces:

ip pim sparse-dense mode[7]

ip sap listen

ip cgmp

Opcionalmente podemos configurar algunos parámetros como:

ip multicast ttl-threshold 32[8]

ip multicast rate-limit 1024

Videoconferencia multicast

Se describe en este apartado las herramientas necesarias para la realización de videoconferencias (multiconferencias) utilizando la tecnología multicast. Es importante señalar que no sólo estamos hablando de utilidades de vídeo o audio, sino de un conjunto de herramientas que aportan entre otras cosas pizarra electrónica, WWW multicast, editores compartidos,…Veamos brevemente una pequeña relación de las más utilizadas[9].

·         vic: Se utiliza para recibir/emitir vídeo.

·         vat: Idem para audio.

·         rat: Idem para audio.

·         nt: Editor compartido.

·         wb: Pizarra compartida.

·         sdr: Directorio de sesiones.

Es interesante, además, instalar herramientas de control/calidad de la red multicast. Como herramienta para controlar la calidad de nuestra red multicast se recomienda utilizar beacon. Es una utilidad cliente/servidor basada en JAVA que nos ofrece una serie de datos sobre distintas medidas (perdidas, retardo, jitter,…). Es necesario ejecutar un cliente y conectarse a un servidor instalado en RedIRIS[10].

Existen algunos paquetes que intentan facilitar el uso de estas herramientas. La idea es integrarlas bajo un único interface. Como ejemplo podemos mencionar ReLaTE y Deta[11]  

Streaming

Se entiende por streaming  la capacidad de distribución de contenido multimedia, con la característica de poder visualizar estos contenidos mientras esa información está siendo trasmitida por la red. Este sistema tiene la ventaja frente al sistema existente anteriormente, (era necesario bajar completamente el vídeo para comenzar su visualización) pero necesita que tanto el servidor de vídeo como las redes de datos sean capaces de mantener un flujo constante de esa información. Básicamente cualquier sistema de streaming estará formado por: Compresión, transmisión y buffering.

Las configuraciones de este tipo de servicios, pueden variar desde un número pequeño de usuarios y contenidos, hasta un gran número de ellos y mucho volumen de información. Evidentemente, el planteamiento será distinto según la solución a tratar. Aquí la red de comunicaciones también es importante, tanto en su ancho de banda como en la posibilidad de manejar tráfico multicast.

A la hora de dimensionar una solución de streaming , es necesario tener en cuenta varios factores: número de usuarios simultáneos, número de horas de almacenamiento y cómo se va a utilizar el servicio. Cuando el almacenamiento crece, es necesario plantearse el incorporar a la solución un sistema, tanto de catalogación, como de recuperación de esa información. Así como un sistema que permita manejar toda ese volumen de datos.

Además, es importante tener en cuenta otros factores como: formatos de vídeo soportados por la servidor de streaming (Real, MPEG-1, MPEG-2, MPEG-4, QT,…), protocolos utilizados para el transporte  (RTP, RTSP, soluciones propietarias), soporte de multicast (real o simulado), soporte de SMIL,…

En relación a los servidores de streaming se pueden dividir en dos tipos: Intranet video servers e Internet video servers

Los primeros, suelen utilizar formatos de vídeo de más calidad y más ancho de banda. Aquí estamos hablando de MPEG-1 (1 a 3 Mbits) con una calidad similar al VHS, MPEG-2 (3 a 10 Mbits) con calidad DVD. Además necesitaremos las tarjetas capturadoras (encoders) que nos generen esta salida. Aquí el precio variará dependiendo del formato que hayamos elegido. La elección de un formato u otro dependerá de varios factores: uso que se la dará a esos contenidos, disponibilidad de ancho de banda en la red, calidad y tipo del material (master), lugar de visualización de contenidos,…

Como ejemplo de ancho de banda/calidad diremos que una ventana pequeña con calidad VHS se puede estar hablando de (80 Kbits para una solución propietaria y hasta 0.5 Mbits para MPEG-1). Una pantalla grande con calidad S-VHS necesitaremos de 1 a 2 Mbits para MPEG-1. Para una mayor calidad como Betacam-SP hablaremos ya de 3 Mbits en MPEG-1 a 5 Mbits en MPEG-2. Evidentemente con este volumen de información tenemos que plantearnos la elección de un sistema de almacenamiento acorde a nuestras necesidades.

El segundo tipo de servidores se utilizarán para dar servicio a Internet. Aquí los anchos de banda (a día de hoy) son considerablemente menores[12]. Se está hablando de velocidad que va desde los 28-56 Kbits, a 128 o 384 kbits. Con formatos como Realvideo o ASF (Advanced Stream Format). Evidentemente, las necesidades de almacenamiento cambian radicalmente con el primer tipo de servidores, y los precios de la solución final (incluyendo estaciones de codificación) también.

En cuanto a la forma de trabajar y planificar el trabajo, es independiente del tipo de servidor que tengamos (internet o intranet). En las tablas 1 y 2 se pueden ver las distintas formas de planificación existentes.

 

 

Bajo demanda	Directo	Diferido
Se puede acceder en cualquier momento.	Sólo se puede ver cuando se emite.	Igual que en directo
Ficheros almacenados en el servidor.	No están guardados en el servidor.	Similar a los de bajo demanda.
Vemos la emisión desde el principio.	Todo el mundo ve la misma parte de la emisión al mismo tiempo.	Igual que en directo.
Podemos hacer pausa, rebobinar,..	No podemos interactuar con la emisión.	Igual que en directo.

                                                           Tabla 1

 

 

	Bajo demanda	Directo	Diferido
Emisión	Grabado previamente.	En directo.	En diferido
Acceso	Se puede acceder en cualquier momento. Rebobinar, pausa, avanzar.	Sólo cuando se emite.	Sólo cuando se emite.
	Streaming, Spliting (con algunas soluciones)	Unicast, Spliting (división de la carga entre varios servidores) multicast	Unicast, Spliting, multicast
Ámbito	- Número limitado de usaurios. - Necesita ancho de banda (dependiendo calidad y número).	En unicast número limitado de usuarios	- En multicast número ilimitado de usuarios. - La red debe soportar multicast.

                                                                       Tabla 2

           

Por último, como elementos a resaltar en una solución de streaming podemos citar:

·         Servidor de streaming: estará formado por el software de streaming y sistema de catalogación en caso de ser necesario.

·         Estación de captura (codificación): nos permite realizar la captura de la señales de audio y vídeo para trabajar de cualquiera de las formas vistas anteriormente.

·         Sistema de almacenamiento: se dimensionará según las necesidades.

·         Herramientas de produción: En algunos casos puede ser interesante disponer de software adicional que nos permita generar contenidos más elaborados.

Real

Bajo este epígrafe se describe la solución que ofrece RealNetworks para la producción y distribución de contenido multimedia.

RealServer: Es el software de Real para la distribución de contenidos vía streaming tanto en directo como en diferido. El software es multiplataforma y puede ser instalado tanto en Windows como en sistemas Unix (Linux y Solaris, HP-UX, IRIX,). Se puede instalar una versión de demo que permite la conexión de hasta 25 usuarios simultáneos. Esta solución viene limitada en algunas de sus funcionalidades (mutlicast y splitting).

Como herramientas para producir podemos citar entre otras: RealProducer (codificación en formato RealVideo tanto en directo como en diferido), RealPresenter (para realizar presentaciones de audio, vídeo con PowerPoint y WWW), RealSlideShow (presentaciones con gráficos y audio).

 

Como características de este conjunto de software se puede resaltar:

·         Facilidad de instalación y configuración.

·         Multiplataforma en Servidor, codificación y visualizadores.

·         Administración y configuración vía WWW.

·         Se apoya en estándares (SMIL, RTP/RTCP, RTSP,..).

·         Soporte multicast (real y simulado).

·         Soporta protocolos de sesión como SAP/SDP para su comunicación con las herramientas típicas de videoconferencia multicast (sdr).

·         Herramientas de control y estadísticas de uso (JAVA).

·         Control de acceso (por dirección IP).

·         Soporta formatos como: AVI, MOV, QT, MP3, RealVideo8, MPEG-1, MPEG-2[13]

 

 

Windows Media

Es la tecnología perteneciente a Microsoft engloba una serie de herramientas para la generación de elementos audiovisuales y su difusión por intranets o internet.

Soporta video bajo de manda (VoD), emisión en vivo y programada. La emisión puede ser entregada de múltiples formas al receptor:

·         Multicast: si la red lo soporta y es un contenido en vivo o diferido.

·         UDP: si no soporta multicast.

·         TCP: si los puertos UDP están filtrados

·         HTTP: Si las conexiones TCP están filtradas puede ser entregado por HTTP, a través de proxies. Esta forma de entrega es la menos eficiente pero en muchas empresas todo lo demás está cortado.

Windows Media es una solución propietaria que aporta sus propios protocolos. La conexión entre cliente y servidor se negocia usando el protocolo MMS (Multi Media Server) o también se puede hacer streaming sobre HTTP.  MMS funciona encima de TCP, usa el puerto 1755 y con él se negocian las características de velocidad de la conexión así como el modo de entrega que en particular puede ser sobre HTTP. Los servidores que sirven contenidos de Windows Media usan urls del tipo MMS://, o bien MMSU:// (para forzar UDP) o bien MMST:// (para forzar TCP). La negociación de la forma de entrega es la siguiente: primero se intenta Multicast (sí el servidor está configurado para hacerlo), después UDP, TCP y HTTP. El cliente puede forzar un modo si quiere en Herramientas->Opciones->Red.

Los contenidos de Windows Media pueden ser difundidos desde un servidor web por HTTP. Comparado con un servidor Web, el Windows Media Service aporta varias ventajas:

·         Uso más eficiente del ancho de banda. El Windows Media Service puede hacer uso como ya se indicó de varios transportes que hacen más eficiente la entrega.

·         Mejor calidad para el usuario

·         Envio de flujos multistream. Para que según el ancho de banda del cliente se envie con distintas calidades.

·         Protección de contenidos con copyright

·         Escalabilidad. Soporta más clientes.

·         Control del ancho de banda en uso.

Por lo que se conoce, MMS es equivalente a RTP, RTCP y RTSP del IETF.

Los formatos de archivo propios de Windows Media son asf, wmv y wma. En realidad los archivos wmv y wma (video y audio respectivamente) pueden ser renombrados a asf ya que su estructura es idéntica. En ciertos sitios puede demandarse un archivo de tipo asf y nosotros tener uno codificado que sea wmv por ejemplo, en cuyo caso solo lo tenemos que renombrar a asf.

Una de las ventajas de esta solución de streaming frente a otros productos es la calidad de sus CODEC. Actualmente se soportan los siguientes CODEC para video: MPEG4 v3 (no cumple el estándar), MPEG4 ISO, Windows Media V7, Windows Media V8.

Otro punto fuerte a favor de esta solución es el precio, Microsoft lo distribuye desde su Web de forma gratuita.

Codificación

Para la generación de archivos en formatos asf, wmv y wma se pueden utilizar dos soluciones:

• Batch Encode Utility: para generar archivos asf, wmv y wma a partír de archivos en otros formatos (por ejemplo avi, mp3, wav, mpg, etc.
• Windows Media Encoder: Se puede usar para lo mismo que el anterior pero además permite tomar como fuente una captura audio y/o video que es codificada en tiempo real. En este se pueden especificar varias fuentes (por ejemplo un video de entrada, un anuncio, un gráfico, etc) e ir pasando de unas a otras. Se pueden generar eventos que son generados en el reproductor del cliente. El contenido que está siendo generado puede almacenarse en un archivo, difundirse a Media Players por HTTP o bien difundirse a un Windows Media Services también por HTTP y que sea este el que lo distribuya a los clientes. No se aconseja más de 30 clientes conectados directamente al Windows Media Encoder. El inconveniente principal de conectar de esta forma a los clientes es que sólo se pueden entregar los contenidos por HTTP.

Difusión

Para la difusión del contenido multimedia como ya se dijo además de un servidor web se pueden utilizar los Windows Media Services. Estos son administrados desde una interface web simple.

Una vez instalado el servicio, que puede funcionar tanto en NT como en Windows 2000 (en este viene en el CD-ROM de instalación), habrá que instalar los puntos de publicación de unidifusión a petición. Esto es equivalente a dar la raíz en un servidor WEB. Una vez hecho esto cualquier archivo archivo asf colocado en dicho directorio será servido bajo demanda usando la sintaxis mms://nombreservidor/archivo.asf. También se puede dar un alias al punto de montaje y entonces sería mms://nombreservidor/alias/archivo.asf. Esta url la entienden Explorer o Media Player, en el caso del Explorer lanza el Media Player para que la use.

Con lo explicado en el párrafo anterior tendríamos video bajo demanda. Otras posibilidades son: emisora difundiendo contenidos en vivo (desde un Encoder) o contenidos grabados, ambas distribuidas por unicast o multicast. Todas ellasa se encuentran extensamente documentadas en la ayuda.

Puesto que una url de tipo mms:// solo es entendida por Internet Explorer, se usa un formato de archivo denominado asx que además sirve para definir el comportamiento del Media Player. Este archivo se baja por HTTP  y está asociado al Media Player. Dentro de este archivo se encuentra la url mms:// o http:// del contenido a visualizar, también se pueden poner banners, y metainformación sobre el contenido en emisión, además de listas de reproducción y más características interesantes.

El video puede ser visualizado embebido dentro de una página web en cuyo caso la apariencia del video puede ser cambiada, por ejemplo con botones o sin ellos, etc.

Kasenna

Orientado a audio y video de alta calidad aunque soporta velocidades bajas también. Las principales características de este producto son:

• Multiformato: MPEG-1, MPEG-2, QuickTime, Real, Windows Media y MPEG4 en un futuro cercano.
• Gestión de contenidos: se almacena metainformación de cada elemento publicable (asset) y esta información puede ser ampliada.
• Basado en estándares. RTSP, RTP, RTCP.

La infraestructura software está compuesta de un conjunto de componentes que sirve de base a la entrega de video. Los componentes se integran a través del uso de metainformación asociada con los contenidos, que es accesible y modificable desde todos los componentes. Los cuatro componentes básicos de Kasenna son:

·         Gestión de la adquisición de contenidos:

Proporciona un conjunto de funcionalidades que permiten a sistemas externos (como encoders, servidores, etc) publicar archivos de audio y video en el servidor de Kasenna. Una vez que el contenido ha sido colocado en el sistema, el software permite introducir metainformación (dada por el sistema o definida por el usuario)

Los contenidos puedes ser pre-grabados o en vivo como la señal de una cámara que es codificada por un encoder.

Soporta multitud de encoders para MPEG-1, MPEG-2, QuickTime and Real.

Tiene la posibilidad de añadir nuevos encoders y sistemas de gestión de assets a través de los APIS de Kasenna.

Permite publicar un contenido pre-grabado desde el sistema del cliente usando Java, Active/X o programas nativos usando un API que proporciona Kasenna.

Soporta el almacenamiento de los archivos en sistemas de almacenaje adecuados para sistemas de ficheros de tiempo real como jukeboxes.

·        Gestión de la distribución de contenidos

Proporciona los métodos para distribuir los contenidos y metainformación entre un servidor origen y servidores hoja.

Soporta variedad de sistemas de distribución tales como push bajo demanda, push programado y pull bajo demanda (desde los servidores hoja) y un sistema de distribución propio llamado Prefix Caching, soportado para flujos MPEG-1 y MPEG-2.

Prefix Caching consiste en que los servidores guardan replicada una copia del prefijo del contenido (unos segundos), de esta manera el cliente cuando se conecta empieza a ver el contenido inmediatamente y mientras tanto el video completo se baja a toda velocidad del servidor que contiene el contenido completo.

 

·        Streaming

·        Gestión del ciclo de vida de los contenidos