Главная » Хабрахабр » [Перевод] Как статы и мониторинг WebRTC изменили мониторинг VoIP

[Перевод] Как статы и мониторинг WebRTC изменили мониторинг VoIP

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

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

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

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

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

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

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

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

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

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

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 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. 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.”

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Особенности работы в интернациональной команде. Япония

Причины переезда всегда разные, но чаще всего люди просто хотят перемен. Поработать в другой стране это, как говорят сейчас, challenge (вызов) для многих российских специалистов: сможешь ли «найти» себя в новой стране, в новой роли. И хорошо, если они к ...

[Перевод] Как работают браузеры — введение в безопасность веб-приложений

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