Сегодня мы публикуем перевод об очередном тренде WebRTC, спасибо за это консультанту Цахи. Какие изменения несет в мир VoIP технология WebRTC и что как меняется подход к статистике: об этом под катом. Кстати, возможно вы помните, что Цахи Левент-Леви приезжал на нашу конференцию Intercom 2017 – тогда он читал доклад про историю и влияние WebRTC на современные коммуникации; однако на нашей ближайшей конфе его, увы, не будет. Но зато блог bloggeek.me всегда доступен, а мы стараемся сделать его еще доступнее своими переводами :) Итак, речь про сбор статистики с видеозвонков через клиентов, прошу под кат.

---

Для сбора статистики WebRTC мониторинг сейчас смещается от сервера к клиентской части.

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

Главный пример – для групповых звонков мы сместили фокус с микширующей модели MCU на модель SFU-роутинга. И тут – внезапно – одно только желание развернуть MCU стало выглядеть нелепо. Я знаю, о чем говорю – я работал в компании, где более 60% звонков проходило через MCU.

Переход к SFU означает, что мы больше полагаемся на возможности и производительность конечного устройства, даем ему больше привилегий по разметке дисплея (а не делаем эту тяжелую работу на бэкенде, используя MCU). Следующим шагом будут многосвязные сети, но я не думаю, что это реализуется в ближайшем будущем.

Собственно, к чему я вел: нечто похожее происходит и со статистикой производительности VoIP (точнее, со статистикой WebRTC). Мы перестаем собирать статистику на бэкенде, но предпочитаем брать ее прямо из браузера/устройства.

Сборы статистики и мониторинг VoIP

Если вы не знакомы со сбором статистики и мониторингом VoIP, вот короткое объяснение:

VoIP основано на совместимости. Разработчики создают продукт, а затем тестируют его согласно спецификации и в угоду совместимости. Далее те, кто занимается деплоем, собирают и запускают сервис. Иногда это приводит к тому, что используется один вендор, но чаще продукты разных вендоров работают в одной сборке.

Не существует спецификации или стандарта, как делать мониторинг или какая статистика может/должна/будет собираться. Есть несколько способов сбора статистики, самый распространенный – применение HEP/EEP. Как гласит спецификация:

“The Extensible Encapsulation protocol (“EEP”) provides a method to duplicate an IP datagram to a collector by encapsulating the original datagram and its relative header properties (as payload, in form of concatenated chunks) within a new IP datagram transmitted over UDP/TCP/SCTP connections for remote collection. Encapsulation allows for the original content to be transmitted without altering the original IP datagram and header contents and provides flexible allocation of additional chunks containing additional arbitrary data. The method is NOT designed or intended for “tunneling” of IP datagrams over network segments, and best serves as vector for passive duplication of packets intended for remote or centralized collection and long term storage and analysis.”

Простым языком: медиапакеты дублируются, чтобы отсылать дубли на анализ в сервис мониторинга.

Дублирование пакетов происходит на бэкенде, через медиасерверы VoIP-сети. Вот как это проиллюстрировано на сайте HOMER/SIPCAPTURE:


HOMER получает данные прямиком от серверов – OpenSIPS, FreeSWITCH, Asterisk, Kamailio – это не пользовательские устройства, только бэкенд-серверы.

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

Это отлично работает, но это не нужно или полезно для WebRTC.

Сборы статистики и мониторинг WebRTC

Существует немного браузеров, которые работают с WebRTC (4 браузера, если быть точным), и все они работают со схожим API (собственно, с WebRTC). В этих браузерах есть метод getstats(), которые возвращает то же, что и chrome://webrtc-internals.

Многие реализации – это использование peer-to-peer, в котором медиа передается
напрямую через Интернет, не затрагивая бэкенд. Google Hangouts начал так делать 2 года назад. Сервис Jitsi добавил эту возможность под именем Jitsi P2P4121. Как эти сервисы следят за качеством для своих пользователей?

Если вы посмотрите на другие сервисы, то поймете, что им всего несколько лет. А WebRTC уже 6 лет. Так что все уже сосредоточились на функциональности и стабильности; качество и мониторинг уже не в центре внимания.

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

Конечный результат? Опенсорсные проекты – например, rtcstats – и коммерческие сервисы вроде callstats.io. В их основе лежит статистика WebRTC (собранная с помощью getstats() API в интервале от 1 до нескольких секунд), которую отправляют на сервер для мониторинга – там статистика собирается, хранится и анализируется. Мы используем похожую схему в testRTC, чтобы собирать, анализировать и визуализировать результаты наших замеров.

Что нам это дает?

1. Точные показания производительности у конечного пользователя – так как статистика собираются с клиентского устройства, больше нет потерь информации из-за бэкенда.
2. Легкий доступ к информации, потому что используются единые способы для сбора информации. К тому же, их можно внедрить в нативные мобильные и десктопные приложения, которые используют WebRTC.
3. Доверие к конечным устройствам – тренд в WebRTC, которые мы видим везде.

Что дальше?

WebRTC меняет многое в том, как мы привыкли думать про VoIP-сети. Конкретно подход про сбор статистики, почему и как это сделано – я не видел, чтобы это активно обсуждалось, поэтому я хотел рассказать об этом.

На это у меня три причины:

1. Кое-кто спрашивал меня об этом здесь в последние дни, так что имело смысл написать развернутый ответ.
2. Мы в testRTC подумываем о том, чтобы предложить “локальную” услугу пассивного мониторинга. Если вы хотите собирать, хранить и анализировать вашу WebRTC-статистику, не отдавая ее стороннему облачному сервису, то напишите нам.
3. Мой онлайн-курс по WebRTC сейчас обновляется, плюс я готовлю новые семинары. Это будет в апреле (в день публикации курс имел обновление от сентября 2017, подробности на сайте bloggeek.me – прим.переводчика). Запишитесь на курс, если хотите обучиться WebRTC.