Protokół konferencji
Niniejszy dokument ma na celu opisanie ewolucji, jakie będziemy dokonywać w zakresie zarządzania konferencjami (audio/video).
Definicje
Host: Czy użytkownik, który miesza strumienie audio/video dla innych
Uczestnik: Każdy użytkownik konferencji, nawet gospodarz
Odpowiedzialność
Dokument ten opisuje tylko pierwsze kroki, które dotyczy identyfikacji uczestników i pozycji w mixerze wideo wysyłanym do wszystkich uczestników.
Możliwe układy
GRID: Każdy członek jest wyświetlany z tą samą wysokością/szerkością
ONE_BIG_WITH_SMALL: Jeden członek jest zwiększony, a drugi wyświetlany
ONE_BIG: Jeden członek wykonuje pełny ekran
W CallManager dostępne są dwie nowe metody zarządzania konfersją Layout:
/**
* 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);
Wdrożenie
Wdrożenie jest dość proste. Wszystko jest zarządzane przez conference.cpp
(do połączenia uczestnika z źródłami) i video_mixer.cpp
(do renderingu pożądanej layout).
Informacje z synchronizacji konferencji
Uwaga: W rzeczywistości słowo uczestnik jest używane do callId mieszany w konferencji.
Celem jest powiadomienie wszystkich uczestników o metadanych z wyświetlanej wideo.
Jeśli uczestnik jest samą konferencją, informacje o jej wchodzącym układzie powinny być połączone, gdy są przesyłane innym uczestnikom.
Informacje o układzie
Layout jest przechowywany jako StringString VectorMap dla klientów i wewnętrznie z wektorem
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"
}
(...)
}
Możliwe klucze to:
uri = ury rachunku
urządzenie = identyfikator urządzenia
media = identyfikator mediów
aktywny = jeżeli uczestnik jest aktywny
x = pozycja (x) w filmie
y = pozycja (y) w filmie
w = wielkość (szerkość) w filmie
h = wielkość (wyżkość) w filmie
videoMutued = jeśli wideo jest wyciszone
audioLocalMuted = jeśli dźwięk jest lokalnie wyciszony
audioModeratorMuted = jeśli dźwięk jest uciszony przez moderatorów
isModerator = jeśli jest to moderator
ręka podniesiona = jeśli ręka podniesiona
aktywność głosu = jeśli strumień ma aktywność głosową
nagrywanie = jeśli rówieśnik nagrywa konferencję
Nowe API
Dostępne jest nowe metody (w CallManager) i nowy sygnał odpowiednio do uzyskania aktualnych informacji i aktualizacji konferencji:
VectorMapStringString getConferenceInfos(const std::string& confId);
void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);
Wdrożenie
Conference
Object (który istnieje tylko wtedy, gdy ≠Call ∞) ∞ (który istnieje tylko wtedy, gdy ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞ ∞
W związku z tym każdy obiekt Call
ma teraz informacje o rozmieszczeniu i jeśli zostanie zaktualizowany, poproś obiekt Conference
o zaktualizowanie informacji.
Właściciel konferencji wysyła swoje informacje przez kanał SIP jako wiadomość z następującym typem MIME: application/confInfo+json
Więc, jeśli telefon otrzymuje jakieś informacje, wiemy, że telefon jest członkiem konferencji.
Call
zarządza otrzymanymi układami, Conference
-managed wysłanymi układami.
Zmiana stanu konferencji
Aby zmienić stan konferencji, uczestnicy muszą wysłać rozkazy, które będzie obsługiwał gospodarz.
Protokół ma następujące potrzeby:
W rzeczywistości dla konferencji jest to 3 poziomy, aby zdefiniować uczestnika:
Konto, który jest tożsamością uczestnika
Urządzenia, ponieważ każdy konto może dołączyć za pośrednictwem wielu urządzeń
Medium, ponieważ mogą być wiele filmów na urządzeniach (np. 1 kamera i 1 współdzielenie ekranu)
Aby zaoszczędzić szerokość pasma, klienci powinni być w stanie wysłać wiele zamówień naraz.
Działania ogólne
Aby zmienić układ, moderator może wysłać ładunek z „aplikacja/confOrder+json” jako typ: gdzie 0 jest siatką, 1 jest jednym użytkownikiem w dużej, inni w małych, 2 jest jednym w dużej
Działania konta
W chwili obecnej nie ma jednak wspieranych działań w przyszłości moderator: prawdziwy/fałszywy
powinien zostać obsługiwany w celu zmiany moderatora.
Działania urządzenia
hangup: true
do zawieszenia urządzenia z konferencji (tylko moderatorzy)raisehand: true/false
do zmiany statusu ręki podwyższającej.
Działania mediów
muteAudio
tylko moderatorzy mogą wyciszyć dźwięk uczestnikamuteVideo
nie jest jeszcze obsługiwany.active
do oznaczenia mediów jako aktywnych.voiceAktywność
do wskazania statusu aktywności głosowej strumienia medialnego (wyłącznie istotne dla dźwięku)
Przykład
W związku z tym aplikacja/pozycja/pozycja+json
zawiera:
{
"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,
}
Uwaga: rodzaj nośnika powinien być włączony do informacji konferencji i może być wykorzystywany do poprawy wyświetlania klienta (np. nie usuwaj udostępniania ekranu)
Kontrola moderatorów
Istnieją 3 możliwości:
Konfiguracja konta zmieniającego do dodania listy moderatorów (w konfiguracji.yml (
defaultModerators
może zawierać listę domyślnych moderatorów)Jeśli
localModeratorsEnabled
jest prawdziwe, wszystkie konta urządzenia będą moderatoramiJeśli
allModeratorsEnabled
jest prawdą, każdy na konferencji będzie moderatorem
Przyszłość
Oddzielne strumienie, aby umożliwić większą kontrolę?
Uwaga/Komentarze
Prawdopodobnie protokół będzie się rozwijał w przyszłości. Myślę, że najlepiej będzie mieć pole „wersja”. Starsza wersja będzie rozpoznawana, jeśli to pole zabraknie.