Protocole de conférence

Ce document vise à décrire les évolutions que nous allons faire pour la gestion de conférences (audio/vidéo). L’objectif est d’améliorer la mise en œuvre actuelle qui fusionne simplement les appels SIP et fournit une vue de grille, pour une vue où les participants sont répertoriés, peuvent être mutés indépendamment, ou la mise en page vidéo modifiée (pour montrer un seul participant)

Définitions

L’hôte: est l’utilisateur qui mélange les flux audio/vidéo pour les autres
Participant: chaque utilisateur de la conférence, même l’animateur

Déclame de responsabilité

Ce document ne décrit que les premières étapes pour le moment. Cela signifie l’identification des participants et la position dans le mixateur vidéo envoyé à tous les participants.

Des dispositions possibles

GRID: chaque membre est affiché avec la même hauteur/largeur
ONE_BIG_WITH_SMALL: Un membre est zoomé et l’autre prévisualisation est affichée
ONE_BIG: Un membre prend l’écran complet rendu

Deux nouvelles méthodes sont disponibles pour gérer la configuration de la conférence dans 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);

Mise en œuvre

La mise en œuvre est assez simple. Tout est géré par conference.cpp (pour relier le participant aux sources) et video_mixer.cpp (pour rendre la mise en page souhaitée).

Synchronisation des conférences

Remarque: En fait, le mot participant est utilisé pour l’appel mixé dans une conférence. Cela peut conduire au début à certains problèmes pour l’API et doit être corrigé à l’avenir

L’objectif est d’informer tous les participants des métadonnées de la vidéo rendue. Cela signifie qui est le participant à la conférence et où se trouve la vidéo.

Si un participant est lui-même une conférence, ses informations de mise en page entrantes doivent être fusionnées lorsqu’elles sont envoyées à d’autres participants.

Informations sur la mise en page

Le Layout est stocké en tant que VectorMapStringString pour les clients et en interne avec un vecteur avec le format suivant:

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"
    }
    (...)
}

Les clés possibles sont:

uri = le compte de l’urie
le dispositif = le numéro d’identification du dispositif
médias = identité du médias
active = si le participant est actif
x = position (x) dans la vidéo
y = position (y) dans la vidéo
w = taille (largeur) dans la vidéo
h = taille (hauteur) dans la vidéo
vidéo éteinte = si la vidéo est éteinte
audioLocalMuted = si l’audio est localment muté
audioModeratorMuted = si l’audio est muté par les modérateurs
estModerateur = si c’est un modérateur
mainlevée = si la main est levée
voixActivité = si le flux a une activité vocale
enregistrement = si le paire enregistre la conférence

Nouveau API

Une nouvelle méthode (dans CallManager) et un nouveau signal permettant respectivement d’obtenir les informations et les mises à jour actuelles de la conférence sont disponibles:

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

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

Mise en œuvre

L’objet Conference (qui n’existe que si nous mélangons les appels, ce qui signifie que nous sommes le maître) gère les informations pour l’ensemble de la conférence, en fonction des informations de mise en page de chaque objet Call.

Ainsi, chaque objet Call dispose désormais d’une LayoutInfo et s’il est mis à jour, demandez à l’objet Conference de mettre à jour ses informations.

Le maître d’une conférence envoie ses informations via le canal SIP sous forme de message avec le type MIME suivant: application/confInfo+json

Donc, si un appel reçoit des informations confidentielles, nous savons que cet appel est un membre d’une conférence.

En résumé, Call gère les mises en page reçues, Conférence-géré les mises en page envoyées.

Modifier l’état de la conférence

Pour changer l’état de la conférence, les participants doivent envoyer des ordres que l’hôte gérera.

Le protocole a les besoins suivants:

Il doit gérer les commandes à plusieurs niveaux.

Le compte qui constitue l’identité du participant
Dispositifs, car chaque compte peut se connecter via plusieurs appareils
Medias, car il peut y avoir plusieurs vidéos par appareil (par exemple 1 caméra et 1 partage d’écran)

Pour économiser de la bande passante, les clients devraient pouvoir envoyer plusieurs commandes à la fois.

Actions générales

Pour modifier une mise en page, le modérateur peut envoyer une charge utile avec « application/confOrder+json » comme type: où 0 est une grille, 1 est un utilisateur en grand, d’autres en petit, 2 est un en grand

Les actions du compte

Pour l’instant, aucune action n’est soutenue, cependant, dans l’avenir modérateur: true/false doit être géré pour changer un modérateur.

Les actions de l’appareil

hangup: true pour accrocher un appareil de la conférence (uniquement les modérateurs)
raisehand: vrai/false pour modifier le statut de la main levée.

Les actions des médias

muteAudio seulement possible par les modérateurs pour faire taire l’audio d’un participant
muteVideo n’est pas encore pris en charge.
active pour marquer les médias comme actifs.
voiceActivité pour indiquer le statut de l’activité vocale d’un flux multimédia (uniquement pertinent pour l’audio)

Exemple

Ainsi, la demande/confOrder+json` contiendra:

{
    "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,
}

Note: le type de support doit être inclus dans les informations de conférence et peut être utilisé pour améliorer l’affichage du client (par exemple, ne pas supprimer le partage d’écran)

Contrôle des modérateurs

Il y a en fait 3 possibilités:

Configuration du compte changeur pour ajouter une liste de modérateurs (dans la config.yml (defaultModerators peut contenir une liste de modérateurs par défaut)
Si localModeratorsEnabled est vrai, tous les comptes de l’appareil seront des modérateurs
Si allModeratorsEnabled est vrai, toute personne à la conférence sera un modérateur

L’avenir

Des courants séparés pour permettre plus de contrôle?

Notes/commentaires

Il est probable que le protocole évoluera pour les besoins futurs. Je pense qu’il est préférable d’avoir un champ « version ». La version ancienne sera reconnue si ce champ manque.