Arquitecturas de videoconferencia para múltiples usuarios

Principalmente desde la transición de la videoconferencia a las redes IP [Willebeek-LeMair 1994],

[Willebeek-LeMair 1995], [Willebeek-LeMair 1997], se han contemplado dos arquitecturas base para la videoconferencia entre múltiples usuarios en lo que se refiere a la distribución de los flujos

multimedia: centralizada y distribuida.

En un esquema distribuido puro, cada cliente recibe el vídeo y el audio de todos los participantes que participen en la conferencia. Evidentemente, esto indica que cada participante

debe enviar una copia de sus flujos multimedia a cada uno de los clientes. En este tipo de esquemas suele existir un servidor central que únicamente implementa el plano de control de

conferencia para interconectar a los diferentes clientes pero, una vez establecida la misma, deja de participar en la sesión. Sin embargo, en el plano de medios se establece una interconexión

total entre los participantes de la conferencia.

La principal ventaja de este tipo de sistemas es que se ahora gran cantidad de recursos y de complejidad en la parte del servidor, ya que todo el proceso y el ancho de banda se consume en los

clientes. Como contrapartida, los clientes tienen que enviar mucha más información consumiendo una gran cantidad de ancho de banda de subida, que suele ser más escaso. A esto habría que

añadir el problema de los retardos, al no haber un control centralizado de la capa de medios, es posible que el retardo con el que los participantes reciben los flujos varíe mucho entre unos y otros,

dificultando la comunicación. Estos problemas crecen con el número de participantes.

En un esquema centralizado puro, los clientes se interconectan siempre a través de un servidor central, llamado en el mundo de la videoconferencia MCU del inglés Multipoint Control

Unit o Unidad de Control Multipunto. Principalmente, la MCU evita que los clientes tengan que enviar múltiples copias de sus flujos ya que una de sus funciones es replicar los paquetes que se

2.2. TECNOLOGÍAS UTILIZADAS EN SISTEMAS DE VIDEOCONFERENCIA

(a) Punto a punto en malla (b) Punto a punto a través de multicast IP Figura 2.5 : Topologías distribuidas de videoconferencia multiusuario

operaciones avanzadas sobre los propios flujos ya que es capaz de recibir, en todo momento, toda

la información multimedia de la sesión y luego reenviarla a los clientes. En general, va a descargar de proceso a los clientes y va a permitir utilizar la videoconferencia para varios

usuarios en terminales más limitados ya sea en términos de CPU, memoria o ancho de banda. Un gran ejemplo de aplicación para este caso son los terminales móviles que, como sabemos, en

general tienen menores capacidades que los ordenadores completos. Esta es la razón por la que la mayoría de las aplicaciones de videoconferencia actuales solo ofrecen conferencias entre dos en

sus versiones destinadas a teléfonos inteligentes.

Existen, además, soluciones híbridas que intentan aprovechar la capacidad de las dos

principales arquitecturas, la flexibilidad y ahorro de costes de la videoconferencia distribuida con el rendimiento, las capacidades añadidas y la adaptabilidad a diferentes terminales de una

estructura centralizada. Por ejemplo, en [Wu 2013] los autores proponen un esquema en el que se despliegan ayudantes en la nube que se encargan de adaptar los flujos multimedia a los diferentes

clientes móviles, siendo necesario uno de estos ayudantes por cada terminal. A pesar de la promesa que muestran algunos de estos trabajos, ninguno ha sido adoptado por los proveedores

comerciales de videoconferencia.

En [Schulzrinne 2003] y [Westerlund 2008] se realiza una clasificación de las diferentes topologías posibles de cara a realizar videoconferencia para múltiples usuarios en entornos en los

que se utilice RTP. Por otro lado, en [Willebeek-LeMair 1994] se sientan las bases de los tipos de MCU. Haremos aquí un repaso sobre las topologías de red destinadas a la comunicación

(a) MCU conmutadora (b) MCU mezcladora

(c) MCU transcodificadora (d) SFU

Figura 2.6 : Topologías centralizadas de videoconferencia multiusuario

Punto a punto

Consiste en interconectar todos los nodos mediante enlaces individuales. De esta manera, como vemos en la figura 2.5(a), el nodo A debe enviar sus flujos multimedia a B, C y D y así

sucesivamente. Este la configuración mencionada anteriormente, en la que el ancho de banda de subida necesario para cada cliente aumenta con el número de participantes.

En términos de RTP existen dos opciones. En una todos formarían parte de una misma sesión,

teniendo que tener en cuenta que los SSRCs no deben solaparse. La alternativa es generar una sesión individual para cada enlace entre nodos.

En 2.5(b) tenemos la misma arquitectura utilizando multicast IP para aliviar el problema de

subida de ancho de banda. Un ejemplo comentado anteriormente que utiliza esta arquitectura es [Turletti 1996]

MCU conmutadora

La MCU conmutadora o mixing MCU es el primer tipo de MCU utilizada históricamente.

Establece una comunicación punto a punto con cada uno de los participantes, permitiéndoles mandar sus flujos multimedia. A partir de ahí, se selecciona a uno de los participantes y ese es el

2.2. TECNOLOGÍAS UTILIZADAS EN SISTEMAS DE VIDEOCONFERENCIA

varias fuentes de media no es posible por limitaciones de los terminales. Por lo general, no se realiza ningún tipo de operación sobre el flujo reenviado con lo que no impone requisitos fuertes

de proceso en el servidor.

Hoy en día es poco habitual el uso de MCUs conmutadoras puras. En general, en este tipo de MCUs, el audio suele ir por otro canal o se combina con mezclas del mismo, permitiendo en todo

momento la comunicación mediante audio mientras se selecciona únicamente un emisor de vídeo. Esta configuración la podemos ver en la figura 2.6(a) donde vemos que, aunque la MCU recibe

flujos multimedia de A, B y C, únicamente el flujo proveniente de B es reenviado sin ninguna modificación.

MCU Mezcladora

La MCU mezcladora omixing MCUes la primera que viene a la mente cuando se utiliza el término MCU, una de las razones por las que es necesario realizar esta clasificación. En su modo normal

de operación recibe flujos de varios clientes y selecciona varios de ellos para generar un nuevo combinando la información proveniente de ellos. Podemos ver un ejemplo en la figura 2.6(b)

donde se está generando un nuevo flujo compuesto por los flujos de A, B y C.

La MCU mezcladora más común seguramente sea la de audio. Desde un punto de vista de procesamiento de la señal, los flujos de audio se decodifican y se generanNsumas diferentes para

losNparticipantes. Posteriormente, los flujos se codifican y se envía a cada participante la suma que le corresponde. Se necesitan diferentes mezclas para que cada participante reciba una suma

del resto de audios sin incluir el suyo propio. En general, se realizan más operaciones como la normalización de los niveles de audio o supresión de ruidos.

La composición o mezcla de vídeo tiene un significado diferente. En este caso la MCU

genera una composición espacial o mosaico de los flujos de vídeo atendiendo a diversos parámetros de manera parecida a como un interfaz de usuario colocaría diversos reproductores de

vídeo simultáneos. Para conseguir esta composición, se deben decodificar todos lo vídeos y generar una imagen en crudo que combine los mismos, esta sucesión de imágenes compuestas se

codifican como un único flujo de vídeo.

Las MCUs mezcladoras tienen varios inconvenientes. En primer lugar la composición o mezcla de flujos tiene un coste computacional muy alto, decodificar, efectuar la mezcla en el

Por otro lado, existe una disminución de calidad de los flujos ya que, en general, estaremos partiendo de codificaciones con pérdidas y en el proceso de reconstrucción se empeorará la

fidelidad. Por último, el retardo introducido por la mezcla puede ser molesto, especialmente en vídeo.

La principal ventaja es que permite participar en la comunicación multiusuario a dispositivos que, por diseño o por falta de capacidad de proceso, no son capaces de manejar múltiples flujos

multimedia simultáneamente. Por esta razón, este tipo de MCUs son muy utilizadas para conseguir compatibilidad hacia atrás con dispositivos antiguos.

MCU transcodificadora

Una MCU transcodificadora modifica los flujos provenientes de los participantes generando otros

nuevos que serán redistribuidos. En la figura 2.6(c) se muestra como el resultado de la operación sobre los flujos A, B y C es un flujo nuevo T.

En general, la transcodificación se utiliza para adaptar los flujos generados por unos clientes a las capacidades de otros. En parte de la literatura se considera a las MCU transcodificadoras

como traductoras entre diferentes tecnologías de media. En este sentido, se puede comunicar dos clientes que soportan dos codificaciones diferentes mediante este tipo de esquema. La MCU

tendría aquí que decodificar y volver a codificar en ambos sentidos, cambiando el codificador utilizado.

Otro uso común es el de obtener diversas tasas de envío de un mismo flujo enviado por un participante, pudiendo de esta manera enviar estos flujos de menor calidad a clientes con peores

conexiones sin necesidad de que el cliente emisor realice ninguna operación.

Una vez más, el consumo excesivo de recursos en el servidor es el principal inconveniente de

esta configuración. Si bien en este caso no se suelen hacer transformaciones sobre los propios flujos, el coste de decodificar y volver a codificar suele limitar fuertemente el número de

conexiones simultáneas que una MCU puede soportar.

SFU

Es un término acuñado muy recientemente, divulgado en [Westerlund 2015]. SFU (Selective Forwarding Unit) o unidad de reenvío selectivo es una vuelta más al enfoque de la conmutación de vídeo. Una SFU recibe todos los flujos disponibles en la sesión y decide cuáles de estos

2.2. TECNOLOGÍAS UTILIZADAS EN SISTEMAS DE VIDEOCONFERENCIA

reenvía al resto de participantes. En la figura 2.6(d) vemos como la SFU recibe todos los flujos y decide reenviar únicamente los flujos A y B, siempre sin realizar ninguna operación sobre ellos.

A diferencia de las otras, más generales y que en su mayoría preceden a RTP, la SFU está más enfocada a un entorno RTP/RTCP y, de hecho, es en este ámbito donde es más fácil hacer la

distinción entre SFU y MCU de conmutación de vídeo.

En el esquema de conmutación de vídeo, la MCU mantiene una sesión RTP con cada cliente

al que le quiera mandar información. Esta sesión RTP y su SSRC se mantendrá constante y la MCU será la encargada de formar esos paquetes RTP de manera coherente de manera que cuando

cambie el flujo de origen, la información de los paquetes RTP permita al receptor decodificarlos de manera correcta. Esto implica generar nuevos paquetes RTP con una marca de tiempo y un

número de secuencia coherente. Si se quisieran conmutar enviando dos vídeos en lugar de uno, se publicarían dos SSRCs nuevos y se establecerían dos flujos RTP generados por la MCU y así

sucesivamente.

Una SFU "proyecta" los SSRCs disponibles hacia el resto de participantes en una sesión RTP independiente para cada participante. Sin embargo, este flujo RTP no tiene que ser totalmente

nuevo, de hecho puede ser el mismo. Únicamente habrá que realizar una serie de operaciones mínimas, como tener en cuenta los saltos de número de secuencia si se decide desactivar y volver

a activar un flujo pasado un período de tiempo.

Una SFU bien diseñada tendrá en cuenta el posible canal de retorno de RTCP que puedan tener

los flujos enviados, ahí radica gran parte de su potencial. A partir de esta información la SFU debe decidir si responder a las peticiones por sí misma o reenviar la petición al servidor.

Un ejemplo de este tipo de mensaje es un indicador de pérdida de imagen o PLI (Picture Loss Indication). Este mensaje suele ser respondido con la generación de un nuevo cuadro de referencia en el emisor, para que el receptor pueda recomponer la imagen. Cuando una SFU está en el medio, debe de tomar la decisión de reenviar este mensaje, aumentando el ancho de banda

consumido instantáneamente o retrasarlo y permitir que el receptor en cuestión tenga una peor calidad temporalmente.

Si los emisores son capaces de adaptar la calidad del vídeo que envían dinámicamente, una SFU puede, sin necesidad de transcodificación, adaptar dinámicamente la calidad a los receptores

Adaptación dinámica de calidad

Para evitar el consumo excesivo de la transcodificación y la necesidad de adecuar la calidad de los flujos a varios clientes en una sesión con múltiples participantes, surgen varias alternativas.

Entre ellas destacan las codificaciones de vídeo escalables o SVC (Scalable Video Coding) y el simulcast.

SVC permite la transmisión y decodificación parcial de flujos de bits para ofrecer servicios

de vídeo con menor resolución espacial o temporal. Es decir, con un subconjunto de los datos enviados, los clientes pueden obtener una versión con menor calidad en términos de resolución

o de cuadros por segundo sin necesidad de codificar el flujo a diferentes calidades de antemano. Una MCU intermedia puede, en este caso, decidir si enviar la totalidad de la información emitida

o un subconjunto de la misma dependiendo de la conexión de los participantes.

Simulcast y SVC funcionan especialmente bien combinados con una SFU capaz de soportar ambas técnicas.

Simulcastconsiste en el envío de varios flujos simultáneos por parte de los clientes, cada uno codificado a una calidad diferente. En cierto modo supone exportar la funcionalidad de una MCU

transcodificadora a los clientes. La MCU será la encargada, en este caso, de decidir cuál de entre las calidades disponibles reenvía a cada participante.