Данную информацию отображают при нажатии кнопки «Свойства» при активном статусе участника. Подробнее в статье «Список участников (+DTMF)».
Если участнику FullHD не хватает 2,5 свободных лицензий, то он подключится на HD и займёт одну. А если осталась только 0,5 лицензии, то он подключится на VGA и возьмёт эти 0,5 лицензии. Данная логика применима к системе лицензирования с раскладывающимися лицензиями, а не к лицензированию по портам. (В распространяемом дистрибутиве по умолчанию используется лицензирование по портам.)
При использовании лицензирования по портам и нехватке лицензий FHD и наличии HD, VGA и аудио сначала выбираются лицензии с видео, а потом только с аудио. При нехватке всех типов лицензий сервер запрещает подключение в конференцию абоненту, выполняя отбой звонка как из конференции, так и в конференцию. Если вызов осуществляется из конференции, данное событие записывается в лог этой конференции; если вызов входящий — в «Логи», находящиеся в «Отчётах» сервера.
Видеокарту — до 90%, ЦП — 70%.
Запись не запустится, если имеющееся количество лицензий на сервере уже было использовано. В логах конференции появится сообщение «Participant monitor disconnected self moveto= cause=-1». Если есть возможность, активируйте запись заранее, при запуске конференции. Активная запись начнётся сама, когда в конференции будет хотя бы один участник. Она займёт свою лицензию и уже не прервётся, если не выключать её вручную, до того как конференцию не покинут все участники. В логах конференции будет соответствующее сообщение — «Conference recording was enabled» и «Участник monitor успешно подключен».
Совпадение, с учётом регистра, ищется по полям: «Номер», «Имя» и IP.
Чем выше частота кадров, тем более высокие требования предъявляются к серверу, клиентскому оконечному оборудованию и каналам связи. Если требуется лучшее качество совещания и оборудование поддерживает, то смысл есть.
Рекомендуемые минимальные соотношения
| Разрешение | Минимальная скорость | Рекомендуемая скорость |
|---|---|---|
| 360p | 384k | 512k |
| 720p | 1M | 2M |
| 1080p | 2M | 4M |
Для приложения Vinteo Desktop и для web-клиента используется тип абонента WS. Для SIP-подключений тип абонента SIP, для H323 — H323 соответственно.
Пин-код автоматически генерируется при создании комнаты. Абоненты-участники конференции могут подключиться без ввода пин-кода, если они будут делать вызов на номер конференции.
Если абонент знает номер открытой конференции и сделает вызов на этот номер, то сервер не будет запрашивать пин-код, даже если подключение анонимное, и подключит в конференцию.
У каждого клиента (аппаратного кодека) своя адресная книга, которая формируется и администрируется локально на терминале. У Vinteo Desktop своя адресная книга для каждого абонента типа WS. При логине абонента в Vinteo Desktop адресная книга синхронизируется с сервером. Таким образом абонент может иметь одну и ту же адресную книгу, пересаживаясь за другое рабочее место.
В Vinteo механизм подключения WebRTC реализован полностью в соответствии со стандартом. Стандарт предусматривает шифрование сигнального потока (websocket) по протоколу TLS (v1.2), а медиапотоков — по DTLS SRTP. Подробнее можно прочитать в статье на Habr: https://habr.com/ru/company/Voximplant/blog/413165/
Достоинством нашего решения является отсутствие нарушений принципов сквозного шифрования, которое присуще решениям видеоконференцсвязи на технологиях проксирования видеопотоков участников конференции.
Да, в версии 26.0.7 это предусмотрено. Можно создать несколько учётных записей администраторов в разделе «Пользователи».
Также любой абонент, прошедший аутентификацию на сервере, может создавать и планировать, а также модерировать собственные конференции и конференции, в которых он назначен модератором другими модераторами или администратором. Различия в возможностях между модератором и администратором заключаются в том, что модератору недоступны настройки сервера, записи конференций (кроме тех, где они являются модераторами), функция загрузки видеороликов на сервер, редактирование списка абонентов, возможность создавать постоянно существующие шаблоны конференций и добавлять себя к ним или удалять себя из них в качестве модератора, а также диагностическая информация о работе сервера. В остальном абонент в конференции, в которой он назначен модератором, обладает такими же правами, как и администратор.
IP-адреса, прописанные для абонентов сервера или для шлюзов, не попадают в список блокировки. Поэтому можно либо создать абонента с нужным IP-адресом, либо шлюз и указать на нём, что разрешены входящие подключения.
Для стабильной работы необходимо обеспечить подключение со следующими параметрами:
• скорость подключения в обе стороны должна быть не меньше минимального значения для используемого разрешения. См. Какое оптимальное соотношение пропускной способности и разрешения для настройки клиента?;
• отсутствие потерь пакетов (если есть потери, то не более 1%);
• низкий джиттер (≤ 30 мс);
• задержка прохождения пакетов (RTT) ≤ 850 мс.
Довольно часто возникают ситуации, когда участник отключается во время конференции, и необходимо выяснить причины такого отключения.
Причины могут быть различны:
• сетевые проблемы;
• отключение участника администратором или модератором;
• участник самостоятельно инициировал отключение.
Для выяснения причины необходимо обратиться к логу конференции. Если конференция запущена в данный момент, то её лог можно увидеть, нажав кнопку «Лог конференции» в верхней правой части экрана.
По окончании конференции для получения отчёта нужно открыть список раздела «Отчёты» и перейти на страницу «Логи», где выбрать необходимую запись лога.
С логами возможны следующие действия:
• просмотр лога;
• сохранение на станцию администратора для последующего анализа.
Лог конференции имеет следующий вид:
В момент разрыва соединения в логе появляется строка, содержащая disconnected, с указанием инициатора отключения: system или self.
Self — говорит о том, что отключение было инициировано устройством или ПО участника конференции. Если соединение было по протоколу H.323, то по коду отключения можно наиболее точно определить, что послужило причиной разъединения.
Для определения кодов ответа (Cause code) можно воспользоваться статьёй: https://ru.wikipedia.org/wiki/Q.931
Для SIP и WebRTC подключений имеется только один информативный код отключения: 130, который означает таймаут получения медиатрафика, то есть какую-то сетевую проблему. Код 200 говорит о том, что отключение было со стороны клиента по неизвестной причине.
Если после disconnected указывается system, это говорит о том, что инициатором отключения выступил сервер. В этом случае для понимания причины необходимо изучить лог ниже сообщения об отключении.
При отключении администратором участника конференции из web-интерфейса управления конференцией в логах будет отображаться сообщение с параметром system и кодом 200, если участник был подключён по WebRTC или SIP.
Кодом -1 (то есть без кода), если участник был подключён по H.323.
Чтобы при запуске конференции микрофоны участников были выключены, необходимо сделать следующее:
- до запуска конференции на странице управления конференцией перейти на вкладку «Настройки»;
- активировать переключатель «При подключении микрофон выключен»;
- нажать в нижней части страницы кнопку «Сохранить».
При подключении в конференцию в качестве участника по ссылке вы можете отключить собственный микрофон, нажав кнопку в нижней части экрана. Микрофон будет неактивен.
В случае HLS-трансляции характеристики системы не являются определяющими, так как в операционном плане это выражается в одном дополнительном подключении к конференции, собирающем и обрабатывающем видео, в делении его на отрезки (чанки) и размещении на RAM-диске сервера. Каждый зритель в случайном порядке обращается к серверу по TCP и по мере просмотра загружает отрезки видео на максимально доступной скорости.
В связи с этим наибольшее значение имеет пропускная способность канала от зрителя до сервера, в том числе на конечных интерфейсах. То есть, например, при ширине полосы 1000 MB, при условии одновременного подключения, скачивая чанки со скоростью 10 MB, 100 зрителей загрузят канал полностью (в зависимости от настроек HLS). Но, как правило, по мере подключения нагрузка распределяется равномерно. На выделенном канале трансляция будет проходить без проблем для участников конференции.
В параметрах HLS-трансляции вы можете выставить разрешение, битрейт каждого HLS-потока, длину и размер сегментов и попробовать в тестах вычислить общую потребность в канале связи для необходимого количества зрителей трансляции (Настройка трансляций на сервере).
Альтернативный вариант — транслировать конференцию по RTMP/RTMPS на CDN (Content Delivery Network) ресурсы. В таком случае нагрузка на канал будет выражаться в одном дополнительном потоке, отправляющем трафик до CDN. Зрители подключаются и получают трансляцию уже оттуда, не влияя на работу сервера. CDN-ресурсами являются, например, VK, YouTube, Telegram.
Таким образом, рекомендуем обеспечить широкую полосу пропускания и выделить на сервере для веб-трансляции отдельный интерфейс, либо транслировать конференцию по RTMP/RTMPS на CDN-ресурсы (VK, YouTube, Telegram — Трансляция конференции в профиле ВКонтакте).