Materialización de la arquitectura: Erizo

La descripción, intencionadamente abierta, expuesta en los apartados anteriores viene a concretarse en este. Erizo es una puesta en práctica de esta arquitectura teórica centrada en el mundo de WebRTC. Siguiendo con la nomenclatura, Erizo tiene dos partes bien diferenciadas:

ErizoController y ErizoCore.

ErizoCore tiene tres tipos de nexos: WebRTCConn, ExternalInput y ExternalOutput. El primero implementa la pila de protocolos de WebRTC, permitiendo comunicarse con cualquier

dispositivo compatible. ExternalOutput y ExternalInput son nexos de salida y de entrada, respectivamente que conectan tanto con sistemas de ficheros como a servidores RTSP. Además,

en la actualidad soporta dos operaciones: OTM y T.

En ErizoController, siendo la WebRTC la orientación principal, tiene sentido tener en cuenta qué formatos y lenguajes son más útiles para trabajar en este entorno. JSON el formato de datos

herramientas para el control y señalización en Erizo.

Para facilitar la creación de aplicaciones, se encapsula la comunicación entre clientes y ErizoController en ErizoClient: una librería implementada en JavaScript. Al crear una aplicación

Web que utilice las capacidades de Erizo, los desarrolladores utilizarán la librería ErizoClient para definir la interacción en la aplicación. Cómo se obtenga la aplicación web está fuera del

alcance de esta sección.

ErizoClient se comunica, por un lado, con el API de WebRTC del navegador y, por otro, con ErizoController mediante WebSockets. Este interfaz permitirá a los clientes unirse a salas,

publicar flujos y subscribirse a ellos. Además, este interfaz servirá como vía para intercambiar los SDPs necesarios para establecer las conexiones WebRTC. Aprovechando el canal de Websockets

establecido entre ErizoController y todos los clientes, se ofrece la posibilidad de enviar mensajes a nivel de aplicación a través del mismo.

En la figura 4.2 podemos ver un ejemplo típico de sesión en Erizo. Un cliente de navegador

está publicando un flujo multimedia, WebRTCConn se encarga de descifrar el mismo. El flujo pasa a OTM, que lo replica. A partir de ahí, otros WebRTCConn (de salida) lo mandan a otros

navegadores volviendo a cifrar los datos. Por otro lado, un nexo External se encarga de almacenar los datos en el disco duro de manera adecuada.

Control y señalización

Veamos como se maneja el control y la señalización en ErizoController. Como sabemos, en los clientes están organizados en salas. Una vez conectados a la sesión deben intercambiar mensajes

con ErizoController para establecer las conexiones necesarias.

En la tabla 4.1 se detallan los mensajes enviados desde ErizoClient hacia ErizoController, siempre a través de Websockets. Como vemos permiten unirse a una sala publicar y recibir

diversos flujos disponibles dentro del ámbito de esta sala. Además, se permite el envío de mensajes de datos a través desendData.

Los mensajes en sentido contrario vienen detallados en la tabla 4.2. El cliente se mantiene

actualizado con los flujos publicados en la sesión mediante la lista obtenida como respuesta a

Connect y, a partir de ahí obtendrá cualquier nueva publicación o retirada de flujos mediante

onAddStreamyonRemoveStream.

4.3. DESARROLLO DE UNA MCU ORIENTADA A WEBRTC

Connect

Establece la conexión con ErizoController que, a su vez, crea las estructuras de memoria necesarias para almacenar la información de los posibles flujos multimedia. Devuelve la lista de los flujos disponibles en la sala roomId

Parámetros roomId Devuelve streamList

publish

Indica a ErizoController que el cliente quiere publicar un flujo. Indica el tipo de flujo (audio, video y/o datos), opcionalmente puede incluir ya un SDP. En la respuesta se le asigna un id a ese flujo (streamId) y, en caso de que sea necesario vendrá un SDP de respuesta.

Parámetros hasVideo, hasAudio, hasData, (SDP) Devuelve streamId, (SDP)

unpublish

Indica a ErizoController que el cliente quiere dejar de publicar el flujo streamId. Como respuesta se obtiene un código de resultado indicando el éxito de la operación.

Parámetros streamId Devuelve Resultado

subscribe

Anuncia la intención del cliente de suscribirse a un flujo identificado por streamId. Se puede adjuntar el SDP inicial opcionalmente. Como respuesta se obtiene un indicador del resultado de la operación y un SDP de respuesta si fuera necesario.

Parámetros streamId, (SDP) Devuelve Resultado, (SDP)

unsubscribe

El cliente quiere dejar de recibir la información del el flujo streamId. Como respuesta se obtiene el resultado de la operación.

Parámetros streamId Devuelve Resultado

sendData

En caso de que el este cliente haya publicado un flujo de datos, utilizará este mensaje para mandar información.

Parámetros streamId, Mensaje Devuelve Resultado

signallingMessage

Mensaje destinado a enviar mensajes de actualización de la descripción de la sesión mediante SDP.

Parámetros SDP

Devuelve Resultado

onAddStream

Indica que se han publicado nuevos flujos multimedia en la sesión. Se envía el id del nuevo flujo disponible en la sala.

Parámetros streamId Devuelve Resultado

onDataStream

Indica que se ha enviado un mensaje de datos a uno de los streams a los que está suscrito el cliente. Como parámetros incluye el id del flujo y el mensaje.

Parámetros streamId, mensaje Devuelve Resultado

onRemoveStream

Indica que uno de los flujos multimedia ha dejado de estar disponible en la sala. Parámetros streamId

Devuelve Resultado

onSignallingMessage

Erizo quiere comunicar un cambio en el SDP de comunicación con un flujo del cliente. Parámetros streamId, SDP

Devuelve Resultado

Tabla 4.2 : Mensajes desde ErizoController a ErizoClient

durante gran parte del diseño y desarrollo de este proyecto un estándar en proceso de definición,

no todas las implementaciones de WebRTC permiten la misma flexibilidad a la hora del establecimiento de la conexión. Algunas implementaciones requieren un esquema de oferta y

respuesta rígido y obligan a establecer una nueva conexión para cualquier modificación. Otras, sin embargo permiten volver a negociar diversos parámetros dinámicamente mediante una

negociación parcial a través de SDP.

Un buen ejemplo de esto es el intercambio de candidatos ICE. Siendo la generación de candidatos un proceso relativamente lento, el poder pasar candidatos incrementalmente (Trickle ICE) permitiendo un establecimiento de la conexión más rápido en muchos casos.

signallingMessage y onSignallingMessage permiten este intercambio de SDPs fuera del establecimiento inicial de la conexión.

En la figura 4.3 vemos el intercambio de mensajes entre ErizoController y ErizoClient para la

publicación de un flujo por parte del Cliente A y la recepción del mismo por parte del Cliente B, ambos conectados a la sala roomA.

En primer lugar A envía el mensaje de conexión a la roomA, asumimos que la respuesta es un código de respuesta OK. El cliente B llega en este momento también. A los dos les llega una lista

4.3. DESARROLLO DE UNA MCU ORIENTADA A WEBRTC

Figura 4.3 : Señalización y control en Erizo

A partir de ahí A inicia la publicación de su flujo mediante el mensaje Publish. Como

respuesta a esta petición, el cliente recibirá el identificador que se le ha asignado a este flujo y un SDP de respuesta. En este caso utilizamos el esquema rígido Oferta-Respuesta de negociación,

evitandosignallingMessagepor simplicidad.

Tras el intercambio de SDPs, comienza el establecimiento de la conexión mediante ICE,

mostrado en al figura como un lapso de tiempo, en este proceso se harán chequeos entre los candidatos pasados a través de los SDPs hasta encontrar una vía de comunicación (pares

IP-puerto) válida. Cuando el proceso llega a su fin con éxito, ErizoController notifica al resto de clientes de la presencia de un nuevo flujo en la sala mediante onAddStream incluyendo el

identificador generado anteriormente para A. En la mayoría de los casos A ignorará este mensaje ya que no querrá suscribirse a su propio flujo, sin embargo B puede decidir que quiere recibir el

el establecimiento de la conexión con Erizo. Una vez completado con éxito el proceso de ICE quedarán establecidas todas las conexiones y el flujo proveniente de A será retransmitido hacia B.

Internamente, en Erizo, se habrá creado un WebRTCConn para A. Este WebRTCConn-A habrá

sido asignado como emisor en un OTM creado para él (OTM-A). Con la llegada de B se habrá creado otro WebRTCConn que habrá sido configurado como receptor del OTM-A.

Como resultado de esta sección obtenemos una MCU que permite interconectar clientes en un esquema basado en salas, aportando además operaciones tales como transcodificación y grabación.

Además, se permite la publicación de mensajes de datos dentro de las salas aprovechando el canal de comunicación vía Websockets existente entre los ErizoClients y ErizoController.