Протокол конференции

Этот документ направлен на описание эволюций, которые мы сделаем для управления конференциями (аудио/видео). Цель состоит в улучшении текущей реализации, которая просто объединяет 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 смешанной в конференции. Это может привести вначале к некоторым проблемам для API и должно быть исправлено в будущем

Цель состоит в том, чтобы уведомить всех участников о метаданных от отображаемого видео. Это означает, кто является участником конференции и где находится видео.

Если участник сам является конференцией, информация о его входящем макете должна быть объединена, когда отправлена другим участникам.

Информация о оформлении

Лейут хранится в виде 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"
    }
    (...)
}

Возможные ключи:

Ури = Ури счета
устройство = идентификатор устройства
СМИ = идентификатор СМИ
активный = если участник активен
x = положение (x) в видео
y = положение (y) в видео
w = размер (ширина) в видео
h = размер (высота) в видео
videoMuted = если видео заглушено
audioLocalMuted = если аудио локально заглушено
audioModeratorMuted = если аудио заглушается модераторами
isModerator = если это модератор
поднятая рука = если поднята рука
голосовая активность = если поток имеет голосовую активность
запись = если одноклассник записывает конференцию

Новый API

Новый метод (в CallManager) и новый сигнал для получения текущей информации и обновлений конференции доступны:

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

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

Реализация

ConferenceObject (который существует только при смешивании звонков, это означает, что мы являемся мастером) управляет информацией для всей конференции, основываясь на LayoutInfos каждого объекта Call.

Таким образом, каждый объект Call теперь имеет информацию о разряде и, если она обновляется, попросите объект Conference обновить свою информацию.

Мастер конференции отправляет свою информацию по каналу SIP в виде сообщения следующего типа MIME: application/confInfo+json

Так что, если звонок получает некоторую информацию, мы знаем, что этот звонок является членом конференции.

В общем, Call управляет полученными макетами, Conference-managed отправленными макетами.

Изменение состояния конференции

Чтобы изменить состояние конференции, участникам необходимо отправить заказы, которые будет выполняться хозяином.

Протокол имеет следующие потребности:

На самом деле для конференции это 3 уровня, чтобы определить участника:

Счет, который является личностью участника
Устройства, потому что каждый аккаунт может присоединиться через несколько устройств
СМИ, потому что может быть несколько видео по устройствам (например, 1 камера и 1 совместное использование экрана)

Чтобы сэкономить пропускную способность, клиенты должны иметь возможность отправлять несколько заказов одновременно.

Общие действия

Чтобы изменить макеты, модератор может отправить полезную нагрузку с «приложение/конфордер+json» в качестве типа: где 0 является сеткой, 1 является одним пользователем в большом, другие в маленьком, 2 является одним в большом

Действия счета

Пока что, однако, в будущем модератор не поддерживается: true/false следует обрабатывать для изменения модератора.

Действия устройства

hangup: true для подвешивания устройства конференции (только модераторы)
raisehand: true/false изменить статус подъемной руки.

Действия СМИ

muteAudio только модераторы могут заставить замолчать аудио участника
muteVideo пока не поддерживается.
active для отметки СМИ как активных.
голосоваядеятельность для указания статуса голосовой деятельности медиапотока (только актуально для аудио)

Пример

Таким образом, заявка/конфармация+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 является правдой, кто-либо на конференции будет модератором

Будущее

Отдельные потоки, чтобы позволить больше контроля?

Замечания/Отчеты

Вполне вероятно, что протокол будет развиваться для будущих нужд. Я считаю, что лучше, если у нас есть поле «версии». Старая версия будет признана, если это поле отсутствует.