Лет 20-30 назад карантин, подобный сегодняшнему, проходил бы немного по другому. Очевидно, что виноваты во всём те самые информационные технологии, про которые мы иногда пишем на этом сайте. Самое время осветить одно очень популярное в последнее время направление — видеоконференции и их использование для проведения видеоуроков.

Немного истории и технических подробностей

Идея проводить видеоконференции с помощью компьютеров далеко не нова. Первый стандарт на эту тему ITU-T опубликовала в 1990 году. Интернета тогда по сути ещё не было, да и вычислительных мощностей тоже, поэтому в этом стандарте всё реализовано поверх ISDN, плохо, и дорого.

Перемотаем на 2019 год и увидим современный интернет с протоколом IP в каждом утюге, а самые дешёвые смартфоны по производительности превосходят настольные компьютеры 90х. Появились новые алгоритмы кодирования видео и звука, алгоритмы эхоподавления и шумоподавления. Теперь мы можем удовлетворить потребность в общении в полной мере.

Что нужно для видеоконференции

Для организации видеосвязи двух человек нам нужно, чтобы видео (и звук) с камеры устройства 1 передавалось на устройство 2, и наоборот. Самый оптимальный для этого способ — закодированные данные режутся в UDP пакеты и отправляются по адресу получателя. Таким образом нам не нужно никаких дополнительных мощностей, при условии нормальной связности мы достигаем оптимальной задержки, и количество одновременных разговоров ограничено только пропускной способностью интернета.

При подключении к конференции дополнительных людей у нас возникает выбор:

1. Продолжать действовать по принципу точка-точка, каждый участник шлёт каждому другому участнику своё видео
2. Придумать другой вариант.

Сразу скажу что вариант 1 мы не выберем по причине того, что обычные клиентские подключения и оборудование не рассчитаны на то, чтобы слать N копий видеопотока. Поэтому все системы, о которых мы будем говорить, используют медиасервер (Multipoint Control Unit, Selective Forwarding Unit).

Схема взаимодействия при этом достаточно очевидная — клиент отправляет свой медиапоток на медиасервер и получает с медиасервера данные, которые он после этого отображает.

Есть множество вариантов реализации этой схемы. Например, медиасервер может декодировать все входящие потоки, собирать из них одну картинку, и рассылать эту картинку. Преимущества данной схемы в том, что клиенту не нужно делать практически ничего — достаточно отобразить присылаемый поток; требования к пропускной способности канала минимальны. Есть и недостатки: поскольку пользователь вряд ли захочет смотреть сам на себя, медиасерверу нужно строить и кодировать по картинке на каждого пользователя, что очень затратно; нужно предусмотреть протокол при помощи которого клиент будет управлять композицией картинки на сервере.

Другая крайность — медиасервер представляет собой Selective Forwarding Unit в чистом виде, и не перекодирует потоки, а просто пересылает их клиентам. Теперь нагрузка на перекодирование отсутствует, но клиенту нужно делать гораздо больше, и нагрузка на каналы связи увеличивается при использовании brady bunch layout — расположения видеофрагментов при котором мы одновременно видим всех участников конференции.

Очевидно, что большую роль играет расположение медиасервера относительно всех участников: чем меньше задержка и больше пропускная способность, тем лучше. Большие задержки приводят к такому эффекту, когда несколько участников конференции начинают говорить одновременно. При низкой пропускной способности потери качества могут привести презентацию в нечитаемое состояние.

Последний довольно-таки важный момент, перед тем как мы перейдём к обзору, касается технологий, на которых построены клиенты. Из-за особенностей платформ, чтобы обеспечить хоть какое-нибудь терпимое качество на смартфонах, все без исключения вынуждены писать свои приложения; качество самих приложений при этом сильно разнится. На компьютерах вариантов сделать хорошо гораздо больше — во всех современных браузерах присутствует поддержка WebRTC, что позволяет не писать отдельный клиент.

Кто чем пользуется

Наш карантинный хит-парад не будет отличаться особой глубиной анализа. Продукты в него попали случайно, когда нужно было внезапно начать делать уроки, а ничего не готово. Ни один из них не был предназначен для того, для чего они сейчас используются наиболее болезненно — а именно, для “онлайн обучения”.

• У всех продуктов была какая-то своя ниша и своя целевая аудитория, никак не совпадающая со школьными уроками.
• Все продукты, о которых мы тут будем говорить, используют MCU/SFU архитектуру. Ограничения на количество участников в конференции чаще всего являются функцией от алгоритма обработки конференции в медиа-сервере.
• Практически все продукты позволяют демонстрировать экран — в решениях для бизнеса это применяется для презентаций, а в discord — для потокового вещания игр.

Zoom

Как-то так получилось, что Zoom внезапно оказался в топе нашего хит-парада. Основные клиенты zoom до кризиса — корпорации, не доверяющие Google и покупающие Zoom для проведения видеоконференций. Из всего многообразия возможностей для проведения уроков нужна разве что возможность рисовать на экране. Из недостатков:

• ограничение в 40 минут в бесплатной версии (отсутствует для школ, но какие из саратовских школ официально купили Zoom?)
• отсутствие нормального контроля доступа, из за чего возможен “зум-бомбинг” (школьники дают пароль от зум сессии друзьям, друзья присоединяются и вносят хаос в чёткий образовательный процесс)
• приложение zoom для компьютера представляет из себя один большой backdoor.

В звонке могут участвовать до 100 человек, медиа-сервера zoom запускает в облаке Amazon.

Discord

Discord в наш хит-парад пришёл из геймерского сообщества, и для уроков он предлагает не совсем видеоконференцию, а возможность запустить Go Live поток — можно демонстрировать экран 50 пользователям текстового чата. Для этого также надо ставить приложение. Ближайшие к Саратову медиасервера Discord находятся в Европе.

Google Meet

Google Meet практически не представлен, и вот почему: он доступен только как часть пакета G Suite — платного, или бесплатного для учебных заведений. К сожалению, я знаю только одно учебное заведение в Саратове с действующей подпиской на G Suite, хотя десятки тысяч школ в США и Европе пользуются Google Meet и Google Classroom. В одной конференции Meet могут участвовать 250 человек, можно включить запись и трансляцию на неограниченную аудиторию. Медиасервера находятся в датацентрах Google.

Skype

В Skype тоже можно устраивать видеоконференции до 50 участников. Присутствует довольно своеобразное ограничение по времени: 100 часов в месяц, 4 часа на один вызов. В остальном набор возможностей стандартный. Медиасервера в датацентрах Microsoft.

Что стоит попробовать

Все перечисленные выше системы объединяет тот факт, что ближайшие медиасервера находятся в Европе. Для Саратова это означает задержку в 60-90 миллисекунд (не очень много), а также сильно возросшую нагрузку на внешние каналы провайдеров. Системы стараются подстраиваться под это, но при этом  снижается качество картинки и звука, иногда до совершенно ужасного состояния.

Jitsi Meet отличается от всего вышеперечисленного. У Jitsi есть официальный общедоступный сервер, но при этом jitsi-открытое ПО, с открытым исходным кодом, и любой компетентный специалист сможет установить его на сервер с линуксом за несколько часов. Таким образом можно попытаться решить проблему с загрузкой каналов и задержками. Во многих российских регионах образовательные учреждения запускают сервера на Jitsi в рамках поддержки онлайн-образования в трудную минуту, например вот так сделали на Кубани. В ПРЦНИТ СГУ установлен такой общедоступный сервер в тестовом режиме для оценки производительности. У jitsi нету принципиального ограничения на количество участников в конференции, всё зависит от мощности сервера, на котором запущен jitsi videobridge. Ведущий телеграм-канала ЗаТелеком предлагает помощь в настройке/установке Jitsi.

Связность, пиринговые войны, и Яровая

Прочитав всё вышеперечисленное, можно сделать несколько выводов:

1. Если все внезапно начнут пользоваться zoom, discord, google meet, skype и facetime, то нагрузка на каналы за пределы России вырастет многократно, и скорее всего наши провайдеры этого не осилят.
2. Есть способ оптимизировать этот процесс, запустив географически локальные сервера Jitsi Meet, и используя их по мере необходимости для конференций, участники которых сосредоточены в той же географии.

К сожалению в условиях российского интернета это не работает, и причиной этого является отсутствие связности. С конца 90-х годов многие российские провайдеры достаточно принципиально не стыкуются друг с другом локально, предпочитая гнать местный трафик через аплинк (вышестоящего провайдера). В узких кругах обсуждаются так называемые пиринговые войны, когда из-за каких-то обид операторы отключают прямые каналы связи, ухудшая при этом качество услуг для своих пользователей, фактически держа их в заложниках.

В середине 2000-х ситуация со связностью в Саратове пошла на поправку благодаря безвозмездному вкладу некоторых участников процесса. Однако к 2020 году всё испортилось окончательно из-за современных законодательных инициатив. Например, МТС разорвал все стыки в саратове и отправляет весь трафик в макрорегион, чтобы любые вопросы по его анализу и сохранению решались там. В результате вполне вероятно, что пакеты с данными между вами и сервером видеоконференций, находящимся на соседней улице, будут идти через финляндию.

Есть простой способ проверить, насколько всё плохо: ping jitsi.sgu.ru. Если задержка в пределах 10ms — вы в пределах Саратовской области. Если около 30 — пакеты идут через Москву. 60 — через Европу. Попробуйте, возможно jitsi вам подойдёт больше чем все перечисленные альтернативы. И удачи всем в это непростое время, не болейте.