Протокол на конференцията
Този документ има за цел да опише развитието, което ще направим за управление на конференциите (аудио/видео). Целта е да се подобри текущото прилагане, което просто съчетава SIP повиквания и да осигури мрежово виждане, за да се види, където участниците са изброени, могат да бъдат заглушени независимо, или видео оформлението променено (за да се покаже само един участник)
Определения
Хост: Потребителят, който смесва аудио/видео потоците за другите
Участник: Всеки потребител на конференцията, дори домакинът
Отговорност
Този документ описва само първите стъпки засега. Това означава идентифицирането на участниците и позицията в видео миксера, изпратен на всички участници.
Възможни размери
ГРИД: Всеки член е показан със същата височина/ширина
ONE_BIG_WITH_SMALL: Един член е увеличен и се показва другият предварително преглед
ONE_BIG: Един член взема пълния екран
Съществуват два нови метода за управление на конференцията Layout в 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);
Изпълнение
Изпълнението е доста просто. Всичко се управлява от conference.cpp
(за свързване на участника с източници) и video_mixer.cpp
(за препращане на желаното оформление).
Информацията за синхронизиране на конференциите
Забележка: Всъщност думата участник се използва за callId, смесен в конференция.
Целта е да се уведоми всички участници за метаданните на представяното видео. Това означава кой участник е в конференцията и къде се намира видеото.
Ако участникът е сам конференция, информацията за входящата й планировка трябва да бъде сливана, когато се изпрати на другите участници.
Информация за оформлението
Разположението се съхранява като VectorMapStringString за клиенти и вътрешно с вектор
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"
}
(...)
}
Възможни ключове са:
uri = ури на сметката
устройство = идентификационен номер на устройството
медиа = идентификационен номер на медиа
активна = ако участникът е активен
x = позиция (x) в видеото
y = позиция (y) в видеото
w = размер (ширина) в видеото
h = размер (височина) в видеото
videoMuted = ако видеото е заглушено
audioLocalMuted = ако аудиото е локално заглушено
audioModeratorMuted = ако аудиото е заглушено от модераторите
isModerator = ако е модератор
ръка вдигната = ако ръката е вдигната
VoiceActivity = ако потокът има гласова активност
записване = ако партньорът записва конференцията
Нови API
На разположение са нов метод (в CallManager) и нов сигнал за получаване на съвременни конферентни данни и актуализации:
VectorMapStringString getConferenceInfos(const std::string& confId);
void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);
Изпълнение
Conference
Object (което съществува само ако смесим обаждания, което означава, че ние сме майстора) управлява информацията за цялата конференция, въз основа на LayoutInfos на всеки Call
объект. getConferenceInfos ще извлече информация директно от този обект.
Така че всеки Кал
обект вече има LayoutInfo и ако се актуализира, помолете Конференц
обект да актуализира информацията си.
Управителят на конференция изпраща информацията си чрез SIP канала като съобщение с следното тип MIME: application/confInfo+json
Така че, ако обаждането получи някаква информация, знаем, че това обаждане е член на конференция.
В общи линии, Кал
управлява получените планировки, Конференция
управлява изпратени планировки.
Промяна на състоянието на конференцията
За да промените състоянието на конференцията, участниците трябва да изпращат поръчки, които домакинът ще обработи.
Протоколът има следните нужди:
Всъщност за конференция е необходимо 3 нива, за да се определи участник:
Счетоводното лице, което е самоличността на участника
Устройства, тъй като всеки акаунт може да се присъедини чрез няколко устройства
Медиа, тъй като може да има няколко видеоклипа по устройства (напр. 1 камера и 1 споделяне на екран)
За да се спести лентова ширина, клиентите трябва да могат да изпращат няколко поръчки наведнъж.
Общи действия
За да промените макета, модераторът може да изпрати полезна натоварване с „приложение/конфордер+json“ като тип: където 0 е мрежа, 1 е един потребител в голям, други в малък, 2 е един в голям
Действия на сметката
Засега обаче няма подкрепяно действие в бъдеще модератор: трябва да се обработи true/false
за смяна на модератор.
Действия на устройството
hangup: true
да се окаже, че устройството от конференцията (само модераторите)raisehand: true/false
за промяна на статуса на ръката за вдигане.
Действия на медиите
muteAudio
само модераторите могат да заглушат аудиото на участникmuteVideo
не се поддържа още.active
за да се отбележи, че медиите са активни.voiceActivity
за посочване на статуса на гласовата активност на медиен поток (само подходящ за аудио)
Пример
Така че application/confOrder+json
ще съдържа:
{
"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,
}
Забележка: типът на медиите трябва да бъде включен в информацията за конференциите и може да се използва за клиента за подобряване на отоплението (например не се разделя екран)
Контролиране на модераторите
Всъщност има три възможности:
Конфигурация на счетоводното изменение за добавяне на списък на модератори (в config.yml (
defaultModerators
може да съдържа списък на дефолтните модератори)Ако
localModeratorsEnabled
е вярно, всички акаунти на устройството ще бъдат модераториАко
allModeratorsEnabled
е вярно, всеки на конференцията ще бъде модератор
Бъдещето
Отделни потоци, за да позволят повече контрол?
Забележки/Коментар
Вероятно протоколът ще се развие за бъдещи нужди. Мисля, че е най-добре да имаме поле „версия“.