Como hemos visto, la solución de movilidad de flujos multimedia que mejor se adapta al escenario de videoconferencia es la especificación MICE. No obstante, es necesario adaptarla a las necesidades concretas de este escenario añadiendo algunas características y modificando algunas partes de su comportamiento. A continuación voy a analizar las carencias de MICE que ponen de manifiesto esta necesidad de adaptación.
Peer B
MCU 1 MCU 2
Peer A
Figura 3.8 : Arquitectura de movilidad de flujos multimedia.
En la Figura 3.8 podemos observar un escenario donde elPeer Ay elPeer Bestán conectados a laMCU 1y preparados para intercambiar paquetes de datos con ella. Ambos participantes podrían estar conectados directamente desde una red pública o en una red privada a través de un NAT. Para establecer la conexión con el dispositivo MCU han utilizado el protocolo ICE. El Peer Aestá enviando un flujo de datos a laMCU 1y ésta lo está redirigiendo alPeer B. En otras palabras, el
3.4. MOVILIDAD DE FLUJOS MULTIMEDIA
de ese flujo multimedia deMCU 1aMCU 2para que elPeer Aenvíe los paquetes aMCU 2y ésta los redirija aPeer B(como muestra la línea de puntos en la figura). Como he explicado antes este proceso resulta de gran utilidad en escenarios en los que realizamos escalabilidad de MCUs. Si necesitamos apagar la máquina en la que está alojadaMCU 1yMCU 2tiene recursos disponibles, de esta manera lograremos redistribuir los recursos utilizados.
Este es un escenario básico en que elPeer Asolamente envía datos y elPeer Bunicamente los recibe. Sin embargo en caso de que ambos envíen y reciban flujos de datos el problema es el mismo pero duplicado. De igual manera en configuraciones complejas con más de dos participantes conectados a una misma MCU las características del escenario pueden extrapolarse. En un escenario destreaminguno de los participantes publica su flujo y la MCU lo redirige al resto. Por su parte, en una sesión de multi videoconferencia, cada uno de los participantes publican y la MCU redirige al resto. Dicho esto, en esta sección voy a analizar el caso simple explicado en la Figura 3.8 y su solución podrá extrapolarse fácilmente al resto de escenarios y configuraciones.
Como he introducido en la Sección 3.4.1, la especificación MICE describe dos mecanismos para realizar movilidad de participantes entre redes en tiempo real. La segunda de ellas puede aplicarse en escenarios donde solamente uno de los participantes soportan MICE. El caso de movilidad de flujos entre MCUs es muy parecido a éste ya que solamente queremos modificar la dirección IP de uno de los extremos, la MCU. Sin embargo es importante recordar que hablamos de escenarios de tiempo real en los que la experiencia de usuario debe ser la mejor posible. Esto significa que cuando movamos los flujos multimedia de MCU 1 a MCU 2, elPeer 2 no debe experimentar ningún tipo de interrupción en la recepción de paquetes. Esto hace que MICE no sea valido por sí mismo.
El mecanismo propuesto por MICE extiende la especificación TURN descrita en [Mahy 2010]. Para poner en contexto al lector explicaré brevemente en que consiste un servidor TURN actuando de relay. Normalmente se utiliza este tipo de configuración TURN para disponer de un nodo intermedio entre dos pares localizado en una red pública y al que ambos tienen acceso. De esta forma solamente debe ser conocida la dirección de este servidor y puede conseguirse conectividad en escenarios con dispositivos NAT restrictivos. Así, el servidor TURN establece una asignación (TURN allocation) entre la dirección del par llamado cliente y la dirección derelay. Cada asignación se identifica mediante la dirección derelayy tiene asociada una estructura de datos (5-tuple) con la información del cliente.
En nuestro escenario, colocando un servidor TURN actuando a modo de relay entre los extremos, los participantes corresponden con la dirección derelayy las MCUs serían los clientes, cuya información se encuentra en las tuplas de cada asignación. En esta configuración, MICE permite refrescar una asignación TURN con un nuevo parámetro (MOBILITY-TICKET) que indica una variación en la dirección IP y puerto del cliente (la MCU). De esta manera el servidor TURN modifica la tupla asociada a la asignación reemplazándola con una nueva que contiene la nueva dirección IP/puerto.
A partir de ese momento todos los paquetes que provienen de la dirección/puerto de relay
correspondiente a la asignación (los que provienen de los participantes) serán enviados a la nueva IP/puerto de cliente (una nueva MCU). Por otra parte todos los datos de aplicación que provienen de la nueva dirección IP/puerto serán enviados a través de la dirección derelaya los participantes. Pero en el momento de actualizar la tupla algunos paquetes pueden haber sido enviados a la antigua MCU y por lo tanto no serán procesados por el servidor de TURN cuando vuelvan porque la antigua tupla no existirá.
TURN MCU 1 MCU 2 P1 P2 P3 P4 P5
Figura 3.9 : Ejemplo de pérdida de paquetes en movilidad
La figura 3.9 muestra un ejemplo que permite entender con más claridad este problema. El servidor de TURN envía paquetes aMCU 1. Justo antes de enviar el paquete número 3 (P3en la figura) se cambia la tupla de la asignación deMCU 1 aMCU 2. Por lo tanto el paquete número 4 se envía aMCU 2. Los paquetes 1, 2 y 3 están siendo procesados por la MCU y por lo tanto aún no han llegado al servidor de TURN. Cuando finalmente llegan la tupla deMCU 1no existirá
3.4. MOVILIDAD DE FLUJOS MULTIMEDIA
y estos paquetes serán ignorados. El resultado es una pérdida de paquetes en el cliente con la correspondiente interrupción y corte en la recepción del flujo multimedia.
En la siguiente sección propongo un mecanismo que, extendiendo la actual especificación MICE, permite resolver este problema. Durante la descripción de esta solución utilizaré algunos términos definidos en la especificación TURN y MICE. Intentaré explicar cada paso de tal forma que sea entendible sin ser expertos en dichas especificaciones. Pero en cualquier caso éstas han de servir como posible referencia en caso de duda [Mahy 2010, Wing 2013].