Protocolo de la conferencia

Este documento tiene como objetivo describir las evoluciones que haremos para la gestión de conferencias (audio/video). El objetivo es mejorar la implementación actual que simplemente fusiona llamadas SIP y proporciona una vista de cuadrícula, para una vista donde los participantes están listados, se pueden silenciar de forma independiente, o el diseño de vídeo cambiado (para mostrar sólo a un participante)

Definiciones

• Anfitrión: Es el usuario que mezcla las transmisiones de audio/vídeo para las demás

• Participante: Cada usuario de la conferencia, incluso el anfitrión

Disclaimer de responsabilidad

Este documento sólo describe los primeros pasos por ahora. Esto significa la identificación de los participantes y la posición en el mezclador de vídeo enviado a todos los participantes.

Los diseños posibles

• GRID: Cada miembro se muestra con la misma altura/ancho

• ONE_BIG_WITH_SMALL: Un miembro se hace zoom y se muestra la vista previa del otro

• ONE_BIG: Un miembro toma la pantalla completa

Dos nuevos métodos están disponibles para gestionar la configuración de la conferencia en CallManager:

/**
 * Change the conference layout
 * @param confId
 * @param layout    0 = matrix, 1 = one big, others in small, 2 = one in big
 */
void setConferenceLayout(const std::string& confId, int layout);

/**
 * Change the active participant (used in layout != matrix)
 * @param confId
 * @param participantId    If participantId not found, the local video will be shown
 */
void setActiveParticipant(const std::string& confId, const std::string& participantId);

La implementación es bastante sencilla. Todo es administrado por conference.cpp (para vincular al participante a las fuentes) y video_mixer.cpp (para renderizar el diseño deseado).

Sincronización de la información de las conferencias

Nota: En realidad, la palabra participante se utiliza para llamar mezclado en una conferencia. Esto puede llevar al principio a algunos problemas para la API y debe ser solucionado en el futuro

El objetivo es notificar a todos los participantes de los metadatos del video renderizado. Esto significa qué participante está en la conferencia y dónde se encuentra el video.

Si un participante es en sí mismo una conferencia, su información de diseño entrante debe ser fusionada cuando se envía a otros participantes.

Información de diseño

La Layout se almacena como VectorMapStringString para clientes e internamente con un vector con el siguiente formato:

Layout = {
    {
        "uri": "participant", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "true"
    },
    {
        "uri": "participant1", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "false"
    }
    (...)
}

Las claves posibles son:

• uri = la uría de la cuenta

• dispositivo = identificación del dispositivo

• media = identificación de los medios

• activo = si el participante es activo

• x = posición (x) en el video

• y = posición (y) en el video

• w = tamaño (ancho) en el video

• h = tamaño (altura) en el video

• videoMutuado = si el video está silenciado

• audioLocalMuted = si el audio está localmente silenciado

• audioModeratorMudado = si el audio está silenciado por los moderadores

• esModerador = si es un moderador

• mano levantada = si la mano está levantada

• Actividad de voz = si la corriente tiene actividad de voz

• grabación = si el compañero está grabando la conferencia

Nuevo API

Un nuevo método (en CallManager) y una nueva señal para obtener información y actualizaciones de conferencias actuales están disponibles:

VectorMapStringString getConferenceInfos(const std::string& confId);

void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);

El Conference Object (que sólo existe si mezclamos llamadas, esto significa que somos el maestro) gestiona la información para toda la conferencia, basándose en los LayoutInfos de cada Call objeto.

Así que, cada objeto Call ahora tiene una información de configuración y si se actualiza, pida al objeto Conferencia actualizar su información.

El director de una conferencia envía su información a través del canal SIP como un mensaje con el siguiente tipo de MIME: application/confInfo+json

Así que, si una llamada recibe alguna información confidencial, sabemos que esta llamada es un miembro de una conferencia.

En resumen, Call gestiona los diseños recibidos, Conferencia-gestiona los diseños enviados.

Cambiar el estado de la conferencia

Para cambiar el estado de la conferencia, los participantes necesitan enviar órdenes que el anfitrión manejará.

El protocolo tiene las siguientes necesidades:

En realidad, para una conferencia, es necesario definir un participante en 3 niveles:

• La cuenta que constituye la identidad del participante

• Dispositivos, porque cada cuenta puede unirse a través de múltiples dispositivos

• Medios, porque puede haber varios vídeos por dispositivos (por ejemplo, 1 cámara y 1 compartición de pantalla)

Para ahorrar ancho de banda, los clientes deben poder enviar múltiples pedidos a la vez.

Acciones generales

Para cambiar un diseño, el moderador puede enviar una carga útil con «aplicación/confOrder+json» como tipo: donde 0 es una cuadrícula, 1 es un usuario en grande, otros en pequeño, 2 es uno en grande

Acciones de la cuenta

Por ahora, no hay ninguna acción apoyada, sin embargo, en el futuro moderador: verdadero/falso debe ser manejado para cambiar un moderador.

Las acciones del dispositivo

• hangup: true para colgar un dispositivo de la conferencia (sólo moderadores)

• raisehand: true/false para cambiar el estado de la mano elevable.

Las acciones de los medios

• muteAudio sólo es posible por los moderadores para silenciar el audio de un participante

• muteVideo todavía no está soportado.

• active para marcar los medios como activos.

• voiceActividad para indicar el estado de la actividad de voz de una transmisión de medios (solo relevante para el audio)

Ejemplo

So, the application/confOrder+json will contain:

{
    "989587609427420" : {
        "moderator": true, /* false  */
        "devices": {
            "40940943604396R64363": {
                "hangup": true,
                "raisehand": true, /* false */
                "media":{
                    "3532532662432" : {
                        "muteAudio": true, /* false */
                        "muteVideo": true, /* false */
                        "active": true, /* false */
                        "voiceActivity": true /* false */
                    }
                }
            }
        }
    },
    "layout": 0, /* 1, 2 */
}

Nota: el tipo de medio debe incluirse en la información de las conferencias y puede utilizarse para que el cliente mejore la visualización (por ejemplo, no cortar el uso compartido de pantalla)

Control de los moderadores

Hay en realidad 3 posibilidades:

• Configuración de la cuenta de cambio para agregar una lista de moderadores (En la config.yml (defaultModerators puede contener una lista de moderadores por defecto)

• Si localModeratorsEnabled es cierto, todas las cuentas del dispositivo serán moderadores

• Si allModeratorsEnabled es cierto, cualquiera en la conferencia será un moderador

El futuro

• ¿Reactos separados para permitir más controles?

Nota/Comentarios

Es probable que el protocolo evolucione para futuras necesidades. Creo que es mejor si tenemos un campo «versión». La versión anterior será reconocida si este campo falta.