Está en la página 1de 59

REDES MULTIMEDIA

2DA PARTE

Cada paquete de audio o vdeo digital que se enva en H.323 lleva una
cabecera RTP que contiene una serie de campos de entre los cuales
destacamos los siguientes:
El campo Tipo de carga til (Payload Type) permite especificar el formato
de la informacin digital de audio o vdeo que lleva el paquete (por ejemplo
el valor 9 representa audio G.722). Esto permite al receptor realizar
correctamente la decodificacin. El emisor puede variar el formato cuando lo
desee durante una sesin simplemente cambiando el valor de este campo.

El campo Nmero de secuencia lo utiliza el emisor para numerar de


forma ascendente los paquetes enviados. Esto permite al receptor (o
receptores) detectar paquetes perdidos (por ejemplo por congestin en la
red) y reordenar los paquetes recibidos fuera de orden.

El campo Timestamp es una marca de tiempo que indica a que instante


pertenece la informacin que contiene el paquete. Esto permite al receptor
correlacionar y sincronizar la reproduccin de diferentes flujos de
informacin producidos por una misma fuente (por ejemplo audio y vdeo).
Un mismo paquete puede contener muestras pertenecientes a instantes
diferentes (por ejemplo varias muestras de audio) en cuyo caso el timestamp
corresponde a la primera. Tambin puede darse el caso de que varios
paquetes lleven el mismo timestamp, por ejemplo si pertenecen a un mismo
fotograma MPEG que ha tenido que ser fragmentado en varios paquetes
RTP para su transmisin.

Ver: indica la versin (actualmente versin 2)


P: (Padding, relleno). Este bit indica si el paquete contiene bytes de relleno
(a veces el paquete ha de tener una longitud mltiplo entero de algn
nmero, por ejemplo en algunos algoritmos de encriptacin).
X: (Extensin). Este bit indica si la cabecera RTP va seguida de una
cabecera de extensin.
CC: (CSRC Count). Este campo indica cuantos Identificadores de fuente
colaboradora contiene la cabecera.
M: (Marker). Este bit sirve para marcar eventos considerados como
importantes por el nivel de aplicacin. Por ejemplo uno de esos eventos
podra ser en una transmisin de vdeo MPEG el paquete que corresponde
a un cambio de fotograma.
Tipo de carga til: campo antes descrito
Nmero de secuencia: campo antes descrito
Timestamp:. campo antes descrito
Identificador de sincronizacin de la fuente: Este campo es un sello
que identifica los paquetes que corresponden a una fuente de informacin
dada, lo que podemos denominar un flujo RTP. Por ejemplo una
videoconferencia genera tpicamente dos flujos, uno de audio y uno de
vdeo, y cada uno vendr identificado por un valor diferente de este campo.
No se puede utilizar el campo Tipo de carga til para identificar el flujo ya
que el emisor podra decidir en cualquier momento cambiar la codificacin
de un flujo (por ejemplo de G.711 a G.729).

Gracias a la informacin suministrada por RTP


(fundamentalmente el nmero de secuencia) el
terminal receptor puede obtener unas estadsticas
detalladas de la calidad de la transmisin que est
teniendo lugar. Esta informacin la utiliza para
generar informes peridicos que son enviados al
emisor, de forma que ste recibe realimentacin del
receptor y puede por ejemplo reducir el caudal si
detecta que se estn produciendo prdidas. De esta
forma sera posible implementar un cierto grado de
control de congestin a nivel de la aplicacin.
Adems de estas funciones de control de trfico
RTCP puede utilizarse como mecanismo para
averiguar que receptores est teniendo una emisin
de tipo multicast, ya que normalmente todos los
receptores generarn mensajes RTCP
peridicamente

Al analizar los requerimientos de las diversas aplicaciones


multimedia que se pueden dar en una red podemos distinguir tres
grupos en funcin que si se requiera o no transmisin en tiempo
real y de que si se necesite o no comunicacin bidireccional, es
decir que se requiera la posibilidad de interaccin entre los
participantes.
En el primer grupo se encuentran las aplicaciones bidireccionales
que requieren tiempo real. Estas son las ms exigentes pues
adems de tener que realizar la compresin y descompresin en
tiempo real el retardo introducido por todo el proceso ha de ser
pequeo para que la interactividad no se vea afectada de forma
importante. El ejemplo ms claro de este tipo de aplicaciones es la
vdeoconferencia
El segundo grupo est formado por las aplicaciones que requieren
transmisin en tiempo real pero no interaccin; en este caso la
compresin/descompresin ha de hacerse en tiempo real, pero
puede introducir un retardo importante (de hasta 15-20 segundos)
permitiendo as al codec optimizar el cdigo generado. Este grupo
est formado por las emisiones en directo de eventos.
El tercer grupo lo constituyen las aplicaciones que permiten la
emisin en diferido, como el vdeo bajo demanda. En este caso el
nico requisito es que la descompresin se realice en tiempo real;
la compresin puede hacerse en diferido con el fin de obtener la
mxima calidad y por supuesto el retardo introducido por sta es
irrelevante.

VDEOCONFERENCIA

Debido a su requisito de bajo retardo la vdeoconferencia nunca utiliza los


algoritmos de compresin MPEG, ni en audio ni en vdeo. En su lugar
emplea los H.261 y H.263 que, al ser menos agresivos en cuanto la
eficiencia de compresin, son mas rpidos (menos retardo) y ms ligeros
(menor consumo de CPU). El bajo retardo permite la interaccin entre los
participantes, reduce los efectos de eco en el sonido (que se acentan
cuando aumenta el retardo) y ha hecho factible desde hace ya unos cinco
aos disponer de estaciones aptas para la videoconferencia a partir de PCs
normales sin necesidad de utilizar codecs hardware. Por ejemplo cualquier
PC actual permite mantener sin problemas una vdeoconferencia en
formato CIF a razn de 15 fotogramas por segundo sin necesidad de
hardware adicional.
Para el audio se utilizan los formatos de compresin habituales en
telefona que en su mayora limitan el ancho de banda (y por tanto la
calidad del sonido) a los 3,1 KHz del canal telefnico.
A pesar de lo dicho aun tienen cabida los equipos especializados que
incorporando codecs hardware permiten una compresin ms
eficiente y con ello una mayor calidad, especialmente en entornos en que
el caudal disponible es limitado. Otros factores importantes en los que los
equipos especializados mejoran la calidad son los mecanismos de
supresin de eco y los sistemas de control y enfoque de las cmaras.

Aplicaciones multimedia ms utilizadas es la vdeoconferencia.


La forma ms sencilla de suministrar la Calidad de Servicio que requieren
este tipo de aplicaciones es asegurar el caudal necesario extremo a
extremo; por este motivo la forma habitual de realizar vdeoconferencia ha
sido durante muchos aos el uso de circuitos RDSI entre los dos
participantes.
Los equipos tradicionales de vdeoconferencia estn formados por un
ordenador con un codec hardware (H.26x) y una conexin RDSI, al que se
le acopla un monitor de televisin y una serie de dispositivos de
entrada/salida de altas prestaciones, tales como cmaras activadas por la
voz, cmaras de documentos, micrfonos direccionales, micrfonos de
ambiente, un sistema de altavoces de alta calidad, etc. Adems incorporan
sofisticados sistemas de supresin de eco para mejorar la calidad del
sonido.
La conexin RDSI tpica es de un acceso bsico con lo que se puede llegar
a 128 Kb/s. Los equipos de gama alta suelen disponer de tres accesos
bsicos con lo que consiguen mayor calidad ya que pueden llegar a 384
Kb/s.
Dado que se utiliza la RDSI cada terminal recibe una direccin E.164 (es
decir, un nmero de telfono tradicional) y, en principio, cualquier terminal
puede conectar con cualquier otro. El protocolo de sealizacin es el
habitual de la red telefnica. Una vez establecida la conexin los dos
terminales establecen un dilogo inicial, se anuncian mutuamente los
formatos soportados de audio y vdeo y negocian un formato comn antes
de proceder al intercambio de informacin.

H 323.

En el caso de H.323 la situacin es similar, salvo que en


vez de RDSI se utiliza Internet. Dado que en Internet no
existe en general Qos, el usuario no tiene garantizado el
caudal y la calidad de la transmisin puede verse afectada
en situaciones de congestin.
Las direcciones utilizadas por el protocolo de sealizacin
en este caso son las direcciones IP de los terminales
implicados.
Existen multitud de productos comerciales que
implementan H.323 y que van desde soluciones gratuitas
puramente software, como el Netmeeting de Microsoft,
hasta otras que incluyen un codec por hardware y tarjeta
para la conexin de una cmara analgica.
En muchos casos los terminales H.323 ofrecen una calidad
inferior comparados con los H.320 debido al tipo de
componentes utilizados: cmaras digitales de baja calidad,
micrfonos baratos, no supresin de eco en el software
(como es el caso del Netmeeting), etc.

Gatekeepers

Es un elemento opcional en la comunicacin entre


terminales H.323. No obstante, es el elemento ms
importante de una red H.323.
Actan 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 acta como un conmutador
virtual.
Los Gatekeepers proporcionan dos importantes funciones
de control de llamada:
Traduccin de direcciones desde la red H.323 a
direcciones IP o IPX, tal y como est especificado en RAS
( Registration, Admission, and Status)
Gestin de ancho de banda, tambin especificado en
RAS. Por ejemplo, si un administrador de red ha
especificado un umbral para el nmero de conferencias
simultneas, el Gatekeeper puede rechazar hacer ms
conexiones cuando se ha alcanzado dicho umbral.

Gatekeepers
Una caracterstica opcional, pero valiosa de los
gatekeepers es la de enrutar llamadas. Si se enruta la
llamada por un gatekeeper, esta puede ser controlada
ms efectivamente. Los proveedores de servicio necesitan
esta caracterstica para facturar las llamadas realizadas a
travs de su red. Este servicio tambin puede ser usado
para re-enrutar una llamada a otro terminal en caso de
estar no disponible el llamado. Adems con esta
caracterstica un gatekeeper puede tomar decisiones que
involucren el balanceo entre varios gateways.
Mientras que un Gatekeeper est lgicamente separado
de los extremos de una conferencia H.323, los fabricantes
pueden elegir incorporar la funcionalidad del Gatekeeper
dentro de la implementacin fsica 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 traduccin de direcciones, control de
admisin, control de ancho de banda y gestin de zonas.

En la anterior figura muestra la relacin que guardan entre s los


diversos componentes que constituyen el estndar H.323.
Los formatos de audio y vdeo son slo una parte del conjunto de
piezas que componen el estndar, que est formado adems por
una serie de protocolos estndar de sealizacin y control.
El audio y vdeo se apoyan en UDP como protocolo de transporte..
Para desarrollar las funciones propias de la transmisin de
informacin en tiempo real se utilizan dos protocolos por encima de
UDP, que son el RTP (Real time Transport Protocol) y el RTCP
(RTP Control Protocol) descritos en el RFC 1889.
La llamada de un terminal a otro se realiza mediante el protocolo de
sealizacin H.245.
Las funciones RAS (Registration, Admission, and Status) se
realizan interactuando con el gatekeeper mediante el protocolo
H.225.0.
Para la comparticin de aplicaciones se utilizan los protocolos
T.123, T.124 y T.125, conocidos colectivamente como T.120.
El mbito de aplicacin de los protocolos RTP y RTCP es ms
amplio que los estndares H.323, pues se utilizan en la mayora de
las aplicaciones de audio y vdeo en tiempo real de Internet.

Cuando est presente el Gatekeeper desarrolla las


siguientes funciones:
Traduccin de direcciones: El Gatekeeper traduce de
direcciones E.164 o alias (userid) a direcciones IP. Para ello
utiliza una tabla de traduccin que se construye y actualiza
mediante los mensajes de registro.
Control de Admisin: El Gatekeeper autoriza el acceso a los
terminales de la LAN mediante los mensajes ARQ/ACF/ARJ del
protocolo H.225.0.
Control del Ancho de Banda: El Gatekeeper soporta mensajes
que permiten de forma explcita solicitar y confirmar (o rechazar)
la asignacin de anchos de banda requeridos para la
comunicacin. La aceptacin se basa en el tipo de aplicacin u
otro criterio definido a priori de forma esttica, pero en la
ocupacin de la red (para esto se utiliza la funcin opcional
gestin de ancho de banda").
Gestin de Zona: El Gatekeeper suministra las funciones
anteriores para los terminales, MCUs y Gateways que se han
registrado ante el, es decir que pertenecen a su zona.

El Gatekeeper puede tambin realizar otras funciones


opcionales tales como:
Sealizacin de Control de la Llamada: El Gatekeeper puede elegir
completar la llamada sealizando hacia los dos terminales y
completando la sealizacin l mismo. Alternativamente puede indicar a
los terminales que conecten directamente el Canal de Sealizacin de la
Llamada, evitando as tener que manejar l, las seales de control
H.225.0.
Autorizacin de la Llamada: Mediante el uso de la sealizacin
H.225.0 el Gatekeeper puede rechazar llamadas de un terminal debido a
fallo en la autorizacin. Las razones del rechazo pueden ser por ejemplo
acceso restringido hacia/desde terminales concretos o durante ciertos
perodos de tiempo.
Gestin de Ancho de Banda: Controla el nmero de terminales H.323
que pueden acceder simultneamente a la LAN. Por medio de la
sealizacin H.225.0 el Gatekeeper puede rechazar llamadas de un
terminal debido a limitaciones en el ancho de banda. Esto ocurre cuando
el gatekeeper determina que no hay bastante ancho de banda disponible
en la red para soportar la llamada. Esta funcin tambin opera durante
una llamada activa cuando un terminal solicita ancho de banda adicional.
Gestin de Llamada: El Gatekeeper puede por ejemplo mantener una
lista de llamadas H.323 en curso. Esta informacin puede ser necesaria
para indicar que un terminal al que se ha llamado est ocupado, y para
suministrar informacin a la funcin de gestin de ancho de banda.

H.323 surge la necesidad de interconectar con el


servicio de vdeoconferencia tradicional, H.320. Para
esto se utiliza una pasarela o gateway, que traduce la
sealizacin de un protocolo a otro.
Evidentemente para desarrollar su funcin la pasarela
necesita disponer de una conexin a la RDSI y de una
conexin a Internet. Adems en funcin del ancho de
banda que tengan estas dos conexiones vendr fijado el
nmero mximo de usuarios simultneos que la
pasarela podr soportar.
Gracias a la pasarela el usuario de Internet puede llamar
a un usuario de la RDSI y establecer con l una
vdeoconferencia; sin embargo el establecimiento de la
comunicacin en sentido inverso no es posible.

Para poder resolver el problema de la


comunicacin en sentido inverso es preciso
incorporar un nuevo elemento en la Internet, el
denominado Gatekeeper o equipo selector.
El Gatekeeper se ocupa de registrar a cada nuevo
usuario que aparezca en la Internet y asignarle
una direccin en el espacio de direcciones E.164,
para que pueda ser llamado desde la RDSI.
La funcin de gatekeeper puede ser desempeada
por un host, un router o tambin por el mismo
equipo que acta de pasarela. Aunque en este
ltimo caso el dispositivo fsico sea el mismo y la
direccin IP coincida se trata de una entidad lgica
diferente con funciones perfectamente definidas.

Existen varias formas de asignar


direcciones E.164 a terminales H.323,
siendo la ms universal la asignacin de
nmeros de extensin. En este caso cada
terminal tiene asignado y configurado un
nmero de extensin. Cuando el usuario
arranca en su ordenador el software
H.323 este enva un mensaje de registro
al Gatekeeper, con lo cual ste lo
incorpora en su tabla. A partir de ese
momento el terminal H.323 puede recibir
llamadas de la RDSI.

Cuando existe Gatekeeper en la red el usuario H.323


que desea llamar a un terminal H.320 realizar la
solicitud al gatekeeper, el cual le indicar la direccin del
Gateway que debe utilizar.
De este modo si el Gatekeeper mantiene el control de
varios Gateway puede asignar en cada caso aquel que
se encuentre ms prximo al destinatario RDSI,
reduciendo as el costo de la llamada por la red
telefnica conmutada.
El Gatekeeper decidir el Gateway a utilizar en funcin
de la direccin E.164 de destino.

Las conferencias multipunto (vdeo o audio) permiten la


comunicacin simultnea entre ms de dos participantes;
son por tanto similares a las party lines.
Dado que los terminales H.320 no estn capacitados para
conectar con ms de un terminal simultneamente, la
forma de establecer una vdeoconferencia multipunto
es utilizar un equipo repetidor o reflector llamado MCU
(Multipoint Control Unit).
Todos los participantes en la multiconferencia se conectan
a la MCU, la cual se ocupa de tomar la seal de
audio/vdeo de uno de los participantes (normalmente el
que est hablando en ese momento) y emitirla a todos los
dems.
Dado que la MCU ha de crear un flujo diferente para cada
receptor el caudal soportado por este dispositivo crece
linealmente con el nmero de receptores.

En el ejemplo de la figura la MCU ha de emitir tres copias


del flujo entrante, con lo que el flujo saliente ser de 384 x
3 = 1152 Kb/s en caso de que el emisor utilice al mximo
las posibilidades de su equipo. En este caso la MCU podra
soportar como mximo cinco usuarios, ya que con un flujo
entrante y cuatro salientes se ocupara toda la capacidad
del acceso primario. Para soportar ms usuarios sera
preciso reducir el caudal generado por el emisor; por
ejemplo utilizando 5 canales (320 Kb/s) se podra soportar
un flujo entrante y cinco salientes (6 flujos x 5 canales/flujo
= 30 canales).
Normalmente la vdeoconferencia multipunto se establece,
como el ejemplo de la figura, con un emisor y n receptores;
el moderador elige el emisor, o se puede conmutar por la
voz de forma automtica. Tambin es posible tener n
emisores y n receptores, aunque en este caso cada
terminal ha de recibir n flujos simultneos, con lo que el
caudal por flujo se reduce y con el la calidad; as por
ejemplo en el caso de la figura cada terminal recibira tres
flujos cada uno de los cuales tendra solo 128 Kb/s.

El concepto de MCU es igualmente aplicable a la


vdeoconferencia H.323. Se aplican aqu los mismos
criterios en cuanto a caudales necesarios que en el caso
de H.320, es decir, la MCU ha de replicar n veces el flujo
de audio-vdeo recibido, por lo que su conexin a la red
ha de ser de mayor capacidad que los terminales a los
que da servicio.

Un problema que se plantea a menudo en las


videoconferencias multipunto es la diferencia de
facilidades y/o ancho de banda de los participantes.
Una solucin es forzar a todos los participantes a
adoptar el conjunto ms restrictivo de facilidades y el
ancho de banda ms reducido.
Ejemplo de la figura una serie de terminales H.320
desean participar en una vdeoconferencia multipunto en
la que el emisor y algunos receptores disponen de
accesos RDSI 3*BRI (384 Kb/s) y posibilidad de
codificar/decodificar vdeo H.263.
Sin embargo el terminal de Atenas dispone de un
acceso RDSI BRI nicamente y solo soporta H.261. El
formato H.261 es un subconjunto del H.263, por lo que
el emisor podra generar un flujo H.261 de 128 Kb/s y en
ese caso todos los receptores podran seguir la emisin.
Pero esto supone una merma de calidad importante
para los terminales de mayores prestaciones de Bilbao y
Toulouse.

La solucin a este problema est en realizar


transcodificacin en la MCU.
El emisor genera el vdeo con la calidad ms alta, es decir
H.263 con un caudal de 384 Kb/s, y el MCU al realizar las
copias se encarga de generar una H.261 de 128 Kb/s para
Atenas.
La transcodificacin es una labor intensiva de CPU ya que
supone realizar la descompresin de un formato y la
compresin en otro distinto. Cuando ha de realizarse en
tiempo real como en el ejemplo de la figura es preciso
disponer de un procesador potente o de algn tipo de
asistencia hardware para ejecutar con rapidez los
algoritmos implicados.

En la anterior figura se han combinado todos los


componentes que hemos visto en los ejemplos
anteriores.
Es posible disponer como en el ejemplo de la figura de
dos MCUs, una para el mbito H.323 y otra para el
mbito H.320. En este caso, al disponer adems de una
pasarela que interconecta ambos entornos los usuarios
pueden en principio establecer vdeoconferencias
multipunto haciendo uso de cualquiera de las dos MCUs.
Atendiendo puramente a factores de eficiencia y
optimizacin de recursos lo lgico sera utilizar en cada
caso la MCU correspondiente a la red donde se
encuentre el mayor nmero de participantes en la
vdeoconferencia; por ejemplo si hay diez participantes
de los cuales siete son H.323 y tres son H.320 lo lgico
sera utilizar la MCU de H.323, ya que de esta forma solo
tres sesiones tendrn que atravesar la pasarela. Ahora
bien, si se quisiera realizar transcodificacin habra que
utilizar la H.320, ya que en el ejemplo se supone que esta
funcin no est soportada por la MCU H.323.

También podría gustarte