Webrtc В Mail.ru Агенте И Icq – Плюсы, Минусы И Перспективы

Привет, Хабр!

WebRTC в Mail.Ru Агенте и ICQ – плюсы, минусы и перспективы

Недавно мы выпустили вышла новая версия Mail.Ru Агента 5.10 для платформы Windows, и в списке новых «возможностей» этой версии появилась незаметная строчка: «улучшено качество голосовых и видеозвонков».

На первый взгляд незначительное изменение – но только на первый взгляд. По сути, мы полностью отказались от медиатеки, которую использовали до сих пор, и перешли на использование собственного «движка», построенного на открытом решении WebRTC. Об этом нам хотелось бы сегодня поговорить подробнее.

История Итак, до недавнего времени (то есть до версии 5.9) мы использовали в нашем десктопном клиенте «движок», лицензированный несколько лет назад у компании Глобальные IP-решения (ГИПС).

Идея лицензировать чужой продукт казалась на тот момент вполне удачной: мы получили готовое решение от одного из лидеров рынка, а вместе с ним и возможность быстро добавить в Mail.Ru Агент функционал звонков, необходимость в котором стало очевидным.

Правда, на практике все оказалось не так радужно: «из коробки» библиотека GIPS работала не совсем корректно, ее закрытый код не способствовал быстрому решению проблем, и в итоге нам даже пришлось разместить «боец» шведских инженеров в офисе Mail.Ru Group, который прямо на месте исправлял ошибки в своем «движке».

Однако в итоге мы получили то, что хотели – звонки в Агенте, реализованные «с нуля» в короткие сроки (2-3 месяца).

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

К сожалению, нам не удалось удовлетворить все запросы пользователей — закрытость библиотеки и зависимость от сторонней компании лишили нас необходимой гибкости в решении возникающих проблем.

Поэтому начиная с определенного момента мы начали задумываться об отказе от решения GIPS. Последний гвоздь в гроб лицензионного движка забила компания Google, купившая Global IP Solutions летом 2009 года.

После покупки стало ясно, что ждать улучшений в библиотеке нет смысла (Google обычно покупает команда и технологии, а не клиентская база).

Таким образом, мы были лишены не только исправления ошибок в будущем, но и надежд на покорение мобильных платформ.

Кроме того, примерно в это же время мы сами приобрели ICQ у AOL, и вопрос единой медиаплатформы стал очень актуальным.

Мы рассматривали множество вариантов, от собственной разработки до лицензирования движка у другого поставщика, но корректировки снова были внесены Google, который неожиданно открыл часть исходного кода GIPS как часть своего новый проект WebRTC .

ВебRTC Суть инициативы WebRTC — предоставить возможность совершать голосовые и видеозвонки прямо с веб-страниц, без установки дополнительных плагинов.

Для достижения этой цели разработчики должны встроить в свои веб-браузеры набор медиа-компонентов и сделать их доступными через общий (стандартный) API JavaScript высокого уровня .

Что ж, идея хорошая – однако статус ее пока весьма туманен.

Единственный браузер, который в настоящее время поддерживает WebRTC, — это разрабатываемая версия Chrome (так называемые «ночные сборки»), этой технологии еще далеко до того, чтобы стать стандартом W3C, а Microsoft не дремлет, активно продвигая свой Silverlight. Короче говоря, никакой революции в звонках из сети с выходом WebRTC пока не произошло.

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

Лицензия BSD (возможность использования и модификации библиотеки без обязательства раскрытия исходного кода всего продукта);
наличие всех необходимых компонентов для совершения звонков между клиентами;
Семантика API близка к движку GIPS, который мы использовали ранее;
Частые обновления кода, свидетельствующие об активном развитии проекта.

Однако более детальное знакомство с WebRTC привело к первым неприятным открытиям:

проект был полон ошибок, из коробки почти ничего не работало;
качество видео оказалось достаточно низким (особенно в плане адаптации к потерям каналов);
поддерживалась только платформа Windows (в репозитории содержался рудиментарный код для Android, но на момент его изучения он даже не был собран);
реализация одного из важнейших акустических компонентов — эхоподавителя (AEC — Acoustic Echo Canceller) в WebRTC оказалась хуже, чем в GIPS;
Кодек VP8 , включенный в WebRTC, в некоторых ситуациях оказался хуже фирменного кодека GIPS LSVX, который мы использовали ранее;
большое количество «мусора» — неиспользуемого кода.

Главный вывод, который мы сделали по итогам исследования, заключается в том, что часть, отвечающая за видео в библиотеке WebRTC, «сломана» и требует тщательной работы над исправлением ошибок.

Однако, несмотря на множество обнаруженных недостатков, мы решили, что WebRTC — хорошая основа для собственного «движка», и начали его разработку самостоятельно.

Мы посчитали, что полный контроль над кодом и независимость от стороннего вендора в долгосрочной перспективе для нас важнее, чем быстрый запуск Mail.Ru Агента и ICQ с лицензионным «движком» от нового поставщика.

Итак, наша стратегия была следующей — сначала довести код WebRTC до производственного качества, а затем решать более сложные задачи: переписать ряд особо проблемных модулей, добавить поддержку видеокодека h.264 (из коробки выходит только VP8) , портировать код на мобильные платформы и т. д. Собственно, первую часть проблемы мы успешно решили, и Mail.Ru Агент 5.10 является своего рода доказательством концепции — первым реальным продуктом, на котором была протестирована библиотека WebRTC с нашими доработками.

Что нового в звонках в Агенте 5.10? Если сравнивать новую версию с предыдущими (по звонкам), то изменений, на первый взгляд, немного.

Однако сразу обращает на себя внимание резко возросшая скорость установления сеанса между клиентами.

Это было достигнуто за счет использования либджингл – один из компонентов WebRTC. Libjingle — достаточно сложный фреймворк для организации P2P-сессий, изначально разработанный для совершения звонков в мессенджере Google Talk. Поскольку Google Talk работает по протоколу XMPP, значительная часть кода libjingle обрабатывает передачу сигналов (то есть обмен параметрами сеанса) по этому протоколу IM. Поскольку мы не используем XMPP , мы сохранили свою сигнализацию, но взяли код из libjingle, непосредственно отвечающий за организацию соединения всеми возможными способами, включая прохождение различных NAT, фаерволов и т.п.

Идея преодоления NAT сама по себе несложна – двум клиентам достаточно просто «договориться» о внешних IP-адресах, а также о портах, на которых следует открывать исходящие соединения и на которых нужно «прослушивать», и с этими параметрами устанавливать двустороннее соединение транспортного уровня (в нашем случае — по протоколу RTP/RTCP через UDP).

Однако на практике это оказывается не так просто сделать — из-за разных типов NAT, за которыми могут находиться клиенты, из-за фаерволов (на которых могут быть закрыты определенные диапазоны портов или даже целые протоколы — например, UDP) , из-за ошибок в реализации сетевых компонентов в различных домашних маршрутизаторах и других особенностей сетевых конфигураций.

Ранее мы решали проблему обхода NAT с помощью «самодельного» (и достаточно примитивного) механизма.

В libjingle реализована гораздо более «умная» логика установления соединения.

Среди наиболее интересных функций — оптимизация сортировки «кандидатов» (пары IP:порт), использование всех сетевых интерфейсов и IP-адресов, доступных на компьютере, для попыток подключения (если одному интерфейсу назначено более 1 IP-адреса), инкапсуляция UDP-пакетов в TCP-соединение (в случае, если UDP заблокирован в сети), используйте Оглушение -серверы и т.д. Использование libjingle существенно улучшило связность Mail.Ru Агента: количество соединений, устанавливаемых напрямую между клиентами (без использования промежуточных ретрансляторов), увеличилось в 3 раза по сравнению с нашим предыдущим решением, что очень положительно сказалось на качество аудио и видео за счет уменьшения количества задержек и потерь пакетов в пути.

Скорость установки соединения также была значительно улучшена.

Оба эти эффекта весьма заметны визуально.

Также мы провели некоторую работу по улучшению адаптации к каналу, а также перешли на кодек VP8. Это также способствовало повышению качества, хотя здесь нам еще есть над чем поработать.

Опробовать новый «движок» можно, скачав его с официального сайта.

Последняя версия клиент (5.10).

Разумеется, у вашего собеседника тоже должна быть установлена эта версия.

Планы На данный момент у нас есть 3 основных приоритета:

улучшенное качество видео (включая лучшую адаптацию к пропускной способности канала и потере пакетов);
расширение диапазона возможных разрешений видео (теперь, как и в предыдущей версии, поддерживается только CIF, т.е.
352х288 – планируем добавить как минимум VGA и 720p);
портирование движка на мобильные платформы Android и iOS.

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

Он абстрагирован в отдельную библиотеку, не привязан к конкретной платформе или продукту, и мы будем рады со временем опубликовать его код. Но, к сожалению, мы сейчас вносим в него столько изменений, что говорить о стабильном публичном релизе пока рано.

Чтобы постоянно улучшать субъективное качество, мы меняем ключевые Компоненты «движок»: буфер джиттера, ARS (автоматический выбор скорости), FEC (прямая коррекция ошибок), AEC (подавитель акустического эха) и т. д. Мы также начали предварительное сравнение h.264 с VP8 — весьма вероятно, что в в будущих версиях мы будем использовать разные видеокодеки для разных параметров вызова (пропускная способность, тип и производительность клиентского устройства).

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

Главные из них — производительность и совместимость с железом, и во многом они взаимосвязаны.

Особенно это касается платформы Android, на которой сейчас производится огромное количество устройств, построенных на совершенно разных аппаратных решениях.

Например, большинство современных решений SoC (System-on-a-Chip) для архитектуры ARM содержат аппаратный ускоритель кодирования и декодирования видео в стандарте h.264 (именно поэтому мы начали работать над включением кодека h.264 в наш двигатель).

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

Для «родного» ПО телефона или планшета это не представляет проблемы: такому ПО достаточно только уметь работать с одним ускорителем.

Однако стороннему приложению необходимо поддерживать все распространённые на данный момент чипсеты — а это не так-то просто, учитывая, что открытая документация часто отсутствует. В целом большинство проблем на Android связано в основном с разными уровнями абстракции ОС, то есть с программными «прослойками» между приложением и железом.

Причем некоторые из этих «слоев» (например, драйверы) зачастую различаются от производителя к производителю, от модели к модели.

Основные усилия связаны с поддержкой этого «зоопарка».

Кроме того, в некоторых случаях необходимо оптимизировать ресурсоемкий код, изначально разработанный для платформы x86, для платформы ARM. Это усугубляется большим разнообразием версий ОС Android, существенно отличающихся друг от друга в самых неожиданных местах.

Например, поведение стека Wi-Fi при выключенном экране (обычное состояние телефона, подключенного к уху) меняется с версии 2.2 на версию 4.0. У iOS есть свои шутки.

Конечно, с железом проблем значительно меньше — количество конфигураций строго ограничено, тестирование не представляет сложности.

Но здесь на первый план выходят ограничения операционной системы — многие вещи невозможно сделать через публичные API (например, доступ к тому же ускорителю кодирования), а использование приватных методов чревато проблемами с прохождением «цензуры» перед получением в App Store. Несмотря на все эти трудности, работа по портированию активно ведется, и в ближайшее время мы представим Android-клиент с поддержкой звонков.

Следите за обновлениями! Илья Наумов, Менеджер проекта Агент Mail.Ru Теги: #mail.ru #webrtc #nat #voip #voip #stun #agent #agent #Agent #libjingle