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