WebRTC — общение в реальном времени, успешный кейс использования технологии

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

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

Есть три варианта конфигурации такого приложения: использование STUN серверов, использование TURN серверов и использование обоих. Для этого в объекте RTCPeerConnection предусмотрено свойство iceTransportPolicy, которое способно принимать два значения: all (STUN + TURN) и relay (только TURN).

Зачем нужны STUN и TURN серверы? STUN сервер позволяет Пете узнать IP Васи, а Васе — узнать IP Пети. Если их устройства не находятся за NAT, то в таком случае их браузеры успешно увидят друг друга и смогут договориться об открытии соединения (идеально, когда они оба находятся в одной сети). Но в реальности наши устройства не имеют статичных IP и зачастую находятся за NAT, и одним STUN сервером здесь не обойтись.

TURN сервер имеет статичный IP-адрес. Петя и Вася подключаются к нему, и TURN сервер успешно выполняет функцию ретранслятора пакетов данных. Петя и Вася могут общаться друг с другом, находясь за NAT, главное, чтобы они видели TURN сервер.

Мы на пальцах разобрали то, как устроены STUN и TURN сервера, но только ими здесь не обойтись. Нам нужен еще сигнальный сервер. Это тот, кто поможет Пете передать предложение (Offer) Васе, а Васе — передать ответ (Answer) Пете. Только после этого обмена их браузеры смогут наладить соединение и начать передачу данных.

Но что если к ним захочет присоединиться Толя (это уже видеоконференция many-to-many, когда все трое будут видеть друг друга)? Толя должен попросить сигнальный сервер сообщить Пете и Васе, чтобы те выслали предложение (Offer) Толе, а Толя, в свою очередь, должен передать Пете и Васе ответ (Answer), так все трое смогут общаться друг с другом в режиме реального времени.

Важный момент: когда Петя формирует Offer, он должен дождаться, пока свойство соединения signalingState будет равно have-local-offer и iceGatheringState будет равно complete. Только тогда он может выслать Offer Васе, а Вася, в свою очередь, должен передать Answer только тогда, когда его соединение получит статус iceGatheringState равный complete.

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

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