Konferensprotokollet
Detta dokument syftar till att beskriva de förändringar som vi kommer att göra för att hantera konferenser (audio/video). Målet är att förbättra den nuvarande implementeringen som helt enkelt kombinerar SIP-samtal och ger en nätvisning, till en bild där deltagarna är listade, kan stämmas självständigt eller videolägenheten ändras (för att bara visa en deltagande)
Definitioner
Värd: Är användaren som blandar ljud-/videostreamen för de andra
Deltagare: Alla användare i konferensen, även värden
Avstå från ansvar
Detta dokument beskriver endast de första stegen för närvarande. Detta innebär att deltagarna identifieras och positionen i videomiksen skickas till alla deltagande.
Möjliga layouter
Grid: Varje ledamot visas med samma höjd/bredd
ONE_BIG_WITH_SMALL: Ett medlem zoomeras och det andra förhandsgranskningen visas
ONE_BIG: En medlem tar hela skärmen renderad
Det finns två nya metoder för att hantera konferensens layout i 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);
Genomförande
Genomförandet är ganska enkelt. Allt hanteras av conference.cpp
(för att länka deltagaren till källor) och video_mixer.cpp
(för att återge den önskade layouten).
Sammanställning av konferensinformation
Observera: I själva verket används ordet deltagande för callId blandad i en konferens. Detta kan först leda till vissa problem för API och måste åtgärdas i framtiden
Målet är att informera alla deltagare om metadata om den video som visas.
Om en deltagare själv är en konferens, bör den inkommande layout-informationen sammansättas när den skickas till andra deltagare.
Layout Info
Layout lagras som en VectorMapStringString för klienter och internt med en vektor
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"
}
(...)
}
Möjliga nycklar är:
Uri = räkenskapens uri
Anordning = anordningens ID
media = mediets ID
aktiv = om deltagaren är aktiv
x = position (x) i videon
Y = position (y) i videon
w = storlek (bredd) i videon
h = storlek (höjd) i videon
video Muted = om videon är muted
audioLocalMuted = om ljudet är lokalt stillt
AudioModerator Muted = om ljudet är muterat av moderatorer
isModerator = om det är en moderator
handRaised = om handen är höjd
röstaktivitet = om strömmen har röstaktivitet
upptagning = om peern spelar in konferensen
Nya API
En ny metod (i CallManager) och en ny signal för att respektive få aktuell konferensinformation och uppdateringar är tillgängliga:
VectorMapStringString getConferenceInfos(const std::string& confId);
void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);
Genomförande
Conference
Object (som endast finns om vi blandar samtal, det betyder att vi är mästaren) hanterar informationen för hela konferensen, baserat på LayoutInfos för varje Call
objekt.
Så varje Call
objekt har nu en LayoutInfo och om uppdaterad, be Conference
objekt att uppdatera sin information.
Konferenschefen skickar sin information via SIP-kanalen som ett meddelande med följande MIME-typ: application/confInfo+json
Så om ett samtal får lite information, vet vi att det är en konferensmedlem.
Sammanfattningsvis hanterar Call
mottagna layouter, Conference
-hanterade skickade layouter.
Förändring av konferensens status
För att ändra konferensens status måste deltagarna skicka order som värden kommer att hantera.
Protokollen har följande behov:
Det är faktiskt tre nivåer för en konferens att definiera en deltagare:
Kontot som är deltagarens identitet
Enheter, eftersom varje konto kan ansluta via flera enheter
Medier, eftersom det kan finnas flera videor per enhet (t.ex. 1 kamera och 1 skärmdelning)
För att spara bandbredd bör kunderna kunna skicka flera beställningar samtidigt.
Allmänna åtgärder
För att ändra en layout kan moderatorn skicka en nyttolast med ”applikation/confOrder+json” som typ: där 0 är ett nät, 1 är en användare i stor, andra i liten, 2 är en i stor
Kontonets åtgärder
För närvarande finns det dock ingen åtgärd som stöds i framtiden moderator: true/false
bör hanteras för att byta en moderator.
Anordningens åtgärder
hangup: true
att hänga upp en enhet från konferensen (bara moderatorer)raisehand: true/false
för att ändra höjningshandens status.
Mediernas åtgärder
muteAudio
endast möjligt av moderatorer att stumma ljudet av en deltagaremuteVideo
inte stöds ännu.active
att markera media som aktiva.voiceAktivitet
för att ange status för en mediaströms röstaktivitet (bara relevant för ljud)
Exempel
Således kommer ansökan/conforder+json
att innehålla:
{
"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,
}
Obs!: typ av media bör inkluderas i konferensinformation och kan användas för att klienten ska kunna förbättra visningen (t.ex. inte skära in skärmdelningen)
Kontroll av moderatorer
Det finns faktiskt tre möjligheter:
Konfiguration för att lägga till en lista över moderatorer (I config.yml (
defaultModerators
kan innehålla en lista över standardmoderatorer)Om
localModeratorsEnabled
är sant, kommer alla konton på enheten att vara moderatorerOm
allModeratorsEnabled
är sant, kommer alla i konferensen att vara moderator
Framtiden
Särskilda strömmar för att kunna kontrollera mer?
Anmärkningar/Kommentarer
Det är troligt att protokollet kommer att utvecklas för framtida behov. Jag tror att det är bäst om vi har ett ”version” fält. Den äldre versionen kommer att erkännas om detta fält saknas.