На пике популярности наша образовательная платформа пропускает до 4 тысяч уроков в час.
Основным инструментом общения преподавателя и ученика является видеосвязь, ведь для обучения важно видеть и слышать друг друга.
В самом начале мы использовали Skype, но его не удалось интегрировать в платформу и вести журнал уроков.
Потом мы перешли на SaaS-решения, но это оказалось очень дорого.
Мы начали искать альтернативы и в 2016 году отказались от покупных решений в пользу WebRTC и Janus. Сейчас дорабатываем видеоконференции для образовательной платформы силами собственной команды.
Да, пришлось копать глубже и наступать на грабли чужой технологии.
Расскажем, как мы выкрутились и улучшили видеосвязь, чтобы она не попала в топ жалоб клиентов.
Протокол имеет значение
Когда мы впервые интегрировали видеозвонки в образовательную платформу, мы пошли по самому простому и очевидному пути — обратились к людям, которые предлагают готовые решения.Это быстро, удобно и не нужно вкладывать средства в развитие инфраструктуры.
Соединение работало по TCP и UDP, звук и изображение нас устраивали, но был фатальный недостаток — дороговато.
Поискали еще раз и нашли решение почти в 5 раз дешевле — все то же самое, но работает только через UDP. Мы подключились к нему.
Но тут появляется новый крупный корпоративный клиент, система безопасности которого блокирует UDP. Возвращаться к старому дорого, а новый в TCP этого сделать не может. Чтобы не терять клиентов, мы пару лет работали с двумя подрядчиками, но каждая оплата счета была болью.
Это не могло продолжаться долго.
Мы посчитали, что дешевле будет собрать собственную команду и вложиться в инфраструктуру.
Стали посматривать в сторону сочетания WebRTC и Janus с открытым исходным кодом: он будет служить сервером сигнализации, обязательным элементом для организации связи через WebRTC. У него была интерфейсная библиотека janus-lib.js, с помощью которой мы могли легко интегрировать видеоконференции в нашу платформу.
Была возможность записывать аудио и видео потоки.
Казалось, что все, что мы можем сделать, это добавить функции под свои нужды, ведь в самом WebRTC мы ничего не могли изменить.
И хотя запустить и настроить его с помощью Януса можно было без проблем, были и подводные камни.
Ты умный, но WebRTC умнее (нет)
WebRTC сам может регулировать трафик в зависимости от интернет-соединения.Если мы посмотрим на графики во время звонка, то увидим, что при ухудшении соединения клиента битрейт временно снижается.
Правда, для этого сначала нужно потерять достаточную часть пакетов, чтобы WebRTC зарегистрировал потери и начал даунгрейд.
А когда WebRTC снизил трафик во время пробного урока, конверсия упала на 10%.
С другой стороны, когда у клиента хорошее соединение, WebRTC использует канал по максимуму, увеличивая битрейт. А это уже грозит перегрузкой сети на сервере, потому что.
если на него будет отправлено больше трафика, чем сможет обработать Янус, то у многих клиентов произойдет потеря соединения.
Был и второй минус: если битрейт очень высокий, то оригинальные записи занимают больше места на диске и могут его заполнить.
Мы подумали об этом и установили ограничение на битрейт в 256 кбит/с, чтобы точнее рассчитать нагрузку на серверы и обеспечить приемлемое качество видео.
Но иногда случаются вещи, на которые мы не можем повлиять.
Например, когда клиент сидит в классе рядом с работающей микроволновкой, которая блокирует радиосигнал между роутером и компьютером (да, у нас был такой случай).
Пока он не отключен, даже умное снижение битрейта не поможет. Чтобы успокоить пользователя, мы начали отображать подсказки и предупреждения о том, что с интернет-соединением что-то не так.
Это подсказки, которые начали появляться.
Чтобы их понять, нужно выучить английский :)
Мощнее значит лучше
Запуская WebRTC, мы наивно полагали, что если у нас будет мощное железо с хорошим каналом, то всё будет работать легко и быстро.Мы рассчитали плановую нагрузку, прописали необходимые конфигурации сервера, но что-то пошло не так.
Жалобы на общение со стороны учителей начали поступать гораздо раньше, чем мы достигли потолка.
Мы это не изучали, но, видимо, внутри самого шлюза Януса были какие-то ограничения.
Потом попробовали снизить лимит пропускной способности с 300 до 200 Мбит/с — проблемы ушли.
Дальше копать не стали, а купили сервера попроще с меньшими лимитами.
Также мы обнаружили ошибку в алгоритме построения маршрута между клиентами.
По умолчанию был выбран более мощный сервер с большей пропускной способностью, независимо от того, где он физически находился.
В результате преподаватель и ученик из одного города могли общаться через сервер из другого — путь усложнялся, и пакеты было легче терять.
Мы переписали алгоритм так, чтобы на основе пингов от пары клиентов к серверам выбирался ближайший.
Как только мы сократили путь, пакеты стали теряться реже.
WebRTC одинаково хорошо работает с разными браузерами.
А если нет, то проблему можно решить с помощью волшебной таблетки библиотеки webrtc-адаптера.
Да, но не совсем.
Например, Китай радует нас не только разнообразием товаров с Али, но и мобильными браузерами типа QQ и UC. Когда мы попытались выйти на китайский рынок, то обнаружили, что они поддерживают WebRTC только в одном направлении: запрещают доступ к микрофону и камере устройства, воспроизводя видео со второго клиента.
Та же проблема возникла в Европе с браузером DuckDuckGo. И однажды к нам поступила жалоба, что невозможно учиться через браузер Тесла! А поскольку мы не можем на все это повлиять, мы просим клиентов использовать последнюю версию Google Chrome. 
Ничего не работает? Используйте Google Chrome! Хотя до недавнего времени с ним не все было гладко на iOS-устройствах: когда пользователи запускают видеозвонок в Chrome с мобильного устройства, iOS ругается и требует открыть Safari. Safari только недавно получил поддержку WebRTC, и не все в нем работает так, как должно.
Например, его не устраивает маленькое разрешение камеры (для экономии трафика мы передаем изображение 640 на 480), и он требует установить видеосвязь более высокого качества.
И еще один сюрприз: на устройствах iOS студенты не могут одновременно подключиться и воспроизвести видеофайл с заданием.
Вот и теперь им предстоит сделать выбор и что-то отключить.
И с этим нам тоже пришлось смириться.
Вы не можете просто пойти дальше и разрешить доступ к вашей видеокамере.
Для видеоурока вам необходимо включить камеру и микрофон.
Казалось бы, очевидно.
Но мы заметили, что зачастую соединение не устанавливается из-за того, что пользователь блокирует и то, и другое.
Причем делает он это автоматически, потому что окно с запросом похоже на другие запросы с других сайтов и тоже появляется там же.
Потом мы стали показывать это уведомление непосредственно в момент входа в первый урок и для надежности дополнительный попап в другом месте экрана.
Стало гораздо яснее и проблема решилась.
Если вдруг не будет доступа к камере и микрофону, мы обязательно запросим его еще раз перед началом занятия.
Каков результат?
Наше оборудование и команда позволили нам сократить затраты на видеосвязь более чем в 10 раз.Мы снизили риск потери пакетов, выбрав оптимальный сервер между двумя клиентами.
Мы смогли быстрее реагировать на поведение пользователей и улучшить пользовательский опыт. А в прошлом году команда начала работу над своей видеотекой: планируют настроить автопереподключение и добавлять различные подсказки.
Кстати, Илья Левин , старший разработчик видеокоманды, подготовил отчет о том, как запустить видеоконференцию на базе WebRTC и Януса и жить с ней дальше - приходите слушать жить 27 февраля.
Начало в 11-00 по московскому времени.
Что еще посмотреть и прочитать по теме:
- Отчет о том, как мы реализовали видеосвязь, наступая на все возможные грабли.
- Кирилл Роговой говорит, что у WebRTC под капотом и почему от тебя почти ничего не зависит.
- Отчет с советами о том, как использовать WebRTC в вашем продукте.
- Подробный статья о том, как мы организовали видеосвязь через сеть и с какими проблемами столкнулись.
-
Скорость Передачи Lte И Dl
19 Oct, 24 -
Онлайн-Встреча Для Android-Разработчиков
19 Oct, 24 -
Dvicecast #1 (Ранее Радио-Ю)
19 Oct, 24 -
Предварительный Просмотр Xfn (Тизер)
19 Oct, 24
