Protokolo de konferenco

Tiu dokumento celas priskribi la evoluojn, kiujn ni faros por administri konferencojn (aŭdio/video). La celo estas plibonigi la aktualan efektivigon, kiu simple kunigas SIP-vokojn kaj disponigas retan vidon, al vidado, kie partoprenantoj estas listigitaj, povas esti mutaciitaj sendepende, aŭ la videokomplekto ŝanĝis (por montri nur unu partoprenanton)

Difinoj

• Gastiganto: Ĉu la uzanto kiu miksas la aŭdio/vidbendojn por la aliaj

• partoprenanto: Ĉiu uzanto en la konferenco, eĉ la gastiganto

Malkaŝo de respondeco

Tiu dokumento priskribas nur la unuajn paŝojn por nun. Tio signifas la identigon de partoprenantoj kaj pozicio en la videomikso sendita al ĉiuj partoprenantoj.

Eblaj aranĝoj

• GRID: Ĉiu membro estas montrita kun la sama alteco/larĝo

• ONE_BIG_WITH_SMALL: Unu membro estas plilarĝigita kaj la alia antaŭvidado estas montrita

• ONE_BIG: Unu membro prenas la plenekranon renderiĝis

Du novaj metodoj estas haveblaj por administri la konferenco Layout 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 efektivigo estas sufiĉe simpla. Ĉio estas administrita fare de conference.cpp (rilati partoprenanton al fontoj) kaj video_mixer.cpp (rigardi la deziratan aranĝon).

Sinkronigado Konferencoj Informaĵoj

Noto: Fakte, la vorto partoprenanto estas uzita por alvoko miksita en konferenco. Tio povas komence konduki al kelkaj problemoj por la API kaj devas esti fiksita en la estonteco

La celo estas informi ĉiujn partoprenantojn pri la metadatenoj de la montrita video. Tio signifas, kiu partoprenanto estas en la konferenco kaj kie la video estas situanta.

Se partoprenanto mem estas konferenco, ĝia alvenanta aranĝo informoj devus esti kunfandita kiam sendita al aliaj partoprenantoj.

Layout Info

La Layout estas stokita kiel VectorMapStringString por klientoj kaj interne kun vektoro kun la sekva 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"
    }
    (...)
}

Povas esti ŝlosiloj:

• uri = la urino de la konto

• aparato = aparato id

• amaskomunikilaro = la id de amaskomunikilaro

• aktiva = se la partoprenanto estas aktiva

• x = pozicio (x) en la video

• y = pozicio (y) en la video

• w = grandeco (larĝo) en la video

• h = grandeco (alteco) en la video

• videoMudita = se la video estas muta

• audioLocalMuted = se la aŭdio estas loka mutaciita

• audioModeratorMuted = se la aŭdio estas mutaciita de moderistoj

• isModerator = se ĝi estas moderator

• manoLevadita = se la mano estas levita

• voĉActivity = se la fluo havas voĉan agadon

• registrado = se la samrangulo registras la konferencon

Nova API

Nova metodo (en CallManager) kaj nova signalo por ricevi aktualajn konferencojn informojn kaj ĝisdatigojn estas haveblaj:

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

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

La Conference Object (kiu ekzistas nur se ni miksas alvokojn, tio signifas ke ni estas la mastro) administras la informojn por la tuta konferenco, surbaze de la LayoutInfos de ĉiu Call objekto.

Do, ĉiu Call objekto nun havas LayoutInfo kaj se ĝisdatigita, demandu la Conference objekto ĝisdatigi ĝiajn informojn.

La majstro de konferenco sendas sian informon per la SIP-kanalo kiel mesaĝo kun la sekva MIME-tipo: application/confInfo+json

Do, se iu alvoko ricevas iujn informojn, ni scias ke tiu alvoko estas membro de konferenco.

Resume, Call administras ricevitajn aranĝojn, Conference-administritajn senditajn aranĝojn.

Ŝanĝante la staton de la konferenco

Por ŝanĝi la staton de la konferenco, partoprenantoj devas sendi ordonojn, kiujn la gastiganto pritraktos.

La protokolo havas la sekvajn bezonojn:

Ĝi devas trakti ordonojn en pluraj niveloj. Fakte por konferenco estas 3 niveloj por difini partoprenanton:

• La konto kiu estas la identeco de la partoprenanto

• Aparatoj, ĉar ĉiu konto povas ligi tra pluraj aparatoj

• Amaskomunikiloj, ĉar povas esti pluraj videoj per aparatoj (ekz. 1 fotilo kaj 1 ekrano partumado)

Por ŝpari bandobitadon, klientoj devus povi sendi multoblajn ordojn samtempe.

Ĝeneralaj agoj

Por ŝanĝi aranĝon, la moderisto povas sendi utilan ŝarĝon kun “apliko/konfOrder+json” kiel tipo: kie 0 estas griz, 1 estas unu uzanto en granda, aliaj en malgranda, 2 estas unu en granda

La agoj de la konto

Por nun, ekzistas neniu ago apogita, aliflanke, en la estonteco moderator: vera/false devus esti traktita por ŝanĝi moderatoron.

La agoj de la aparato

• hangup: true por pendigi aparaton de la konferenco (nur moderistoj)

• raisehand: vera/falsa por ŝanĝi la staton de la levilo mano. Nur ebla per la aparato mem, alie faligita.

La agoj de la amaskomunikiloj

• muteAudio nur fare de moderistoj por mutacii la aŭdio de partoprenanto

• muteVideo ankoraŭ ne apogita.

• active por marki la amaskomunikilaron kiel aktiva.

• voiceActivity por indiki la statuson de la voĉa agado de amaskomunikila fluo (nur signifa por aŭdio)

Ekzemplo

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 */
}

Noto: la speco de la amaskomunikilaro devus esti inkludita en konferencoj informoj kaj povas esti uzita por la kliento por plibonigi ekrano (ekz. ne tranĉi ekrano dividado)

Kontrolado de moderistoj

Estas fakte tri ebloj:

• Konfigado de ŝanĝanta konto aldoni liston de moderistoj (En la konfig.yml (defaultModerators povas enhavi liston de defaŭltaj moderistoj)

• Se localModeratorsEnabled estas vera, ĉiuj kontoj de la aparato estos moderistoj

• Se allModeratorsEnabled estas vera, ĉiu en la konferenco estos moderisto

Estonteco

• Ĉu apartaj fluoj por permesi pli da kontroloj?

Notoj/Komentoj

Estas probable, ke la protokolo evoluos por estontaj bezonoj. Mi kredas, ke estas plej bone, se ni havas “versio” kampo. La pli malnova versio estos rekonita se tiu kampo mankas.