Жизненный цикл сессии WebRTC

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

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

Интернет большой. Очень большой. Он настолько большой, что много лет назад умные люди увидели его размеры, скорость роста и ограничения 32-битной системы адресации IP и поняли, что что-то нужно предпринять, прежде чем мы исчерпаем все адреса, поэтому они начали разрабатывать новую 64-битную систему адресации. Но они поняли, что переход займет больше времени, чем хватит 32-битных адресов, поэтому другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-битный IP-адрес. Трансляция сетевых адресов (NAT) — это стандарт, который поддерживает такое совместное использование адресов, обрабатывая маршрутизацию данных входящих и исходящих от устройств в локальной сети, все из которых используют один общий WAN (глобальный) IP-адрес.

Проблема для пользователей заключается в том, что каждый отдельный компьютер в интернете не обязательно имеет уникальный IP-адрес, и, на самом деле, IP-адрес каждого устройства может меняться не только при переходе из одной сети в другую, но и при изменении адреса сети с помощью NAT и/или DHCP. Для разработчиков, пытающихся реализовать сетевые подключения «точка-точка», это создаёт дилемму: без уникального идентификатора для каждого устройства пользователя невозможно мгновенно и автоматически определить, как подключиться к конкретному устройству в интернете. Даже если вы знаете, с кем хотите поговорить, вы не обязательно знаете, как его найти или даже его адрес.

Это похоже на попытку отправить посылку вашему другу Мишель, пометив её «Мишель» и бросив в почтовый ящик, не зная её адреса. Вам нужно узнать её адрес и указать его на посылке, иначе она будет гадать, почему вы снова забыли о её дне рождения.

Вот тут и пригождается сигнальный обмен.

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

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

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

Для обмена сигнальной информацией можно отправлять объекты JSON друг другу через соединение WebSocket, или использовать XMPP или SIP по соответствующему каналу, или использовать fetch() по HTTPS с опросом, или любую другую комбинацию технологий, которую вы можете придумать. Вы даже можете использовать электронную почту в качестве канала сигнального обмена.

Также стоит отметить, что канал для проведения сигнального обмена даже не обязательно должен быть сетевым. Один узел может вывести объект данных, который можно распечатать, физически передать (пешком или курьером) на другое устройство, ввести его в это устройство, а затем вывести ответ от этого устройства, чтобы отправить его пешком и так далее, пока соединение WebRTC не будет установлено. Задержка будет очень высокой, но это возможно.

Информация, обмениваемая во время сигнального обмена

Существует три основных типа информации, которые необходимо обменивать во время сигнального обмена:

• Управляющие сообщения, используемые для настройки, открытия и закрытия канала связи и обработки ошибок.
• Информация, необходимая для настройки соединения: IP-адреса и информация о портах, необходимые для того, чтобы узлы могли общаться друг с другом.
• Переговоры о возможностях медиа: какие кодеки и форматы данных медиа поддерживают узлы? Они должны быть согласованы перед началом сессии WebRTC.

Только после успешного завершения сигнального обмена может начаться процесс фактического открытия соединения WebRTC.

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

Процесс сигнального обмена

Для начала сессии WebRTC необходимо выполнить последовательность действий:

1. Каждый узел создаёт объект RTCPeerConnection, представляющий его конец сессии WebRTC.
2. Каждый узел устанавливает обработчик событий icecandidate, который обрабатывает отправку этих кандидатов другому узлу по каналу сигнального обмена.
3. Каждый узел устанавливает обработчик события track, которое срабатывает, когда удалённый узел добавляет поток в поток. Этот код должен подключить потоки к своему потребителю, например, к элементу <video>.
4. Вызывающая сторона создаёт и обменивается с принимающим узлом уникальный идентификатор или маркер, чтобы вызов между ними мог быть идентифицирован кодом на сервере сигнального обмена. Точное содержание и форма этого идентификатора зависят от вас.
5. Каждый узел подключается к согласованному серверу сигнального обмена, например, к серверу WebSocket, с которым они оба умеют обмениваться сообщениями.
6. Каждый узел сообщает серверу сигнального обмена, что хочет присоединиться к той же сессии WebRTC (идентифицируемой маркером, заданным на шаге 4).
7. Описание, кандидаты и т. д. — больше информации следует

Иногда во время жизненного цикла сессии WebRTC меняются сетевые условия. Например, один из пользователей может перейти от сотовой сети к Wi-Fi, или сеть может стать перегруженной. В этом случае агент ICE может выбрать выполнение перезапуска ICE. Это процесс повторной настройки сетевого подключения, точно так же, как выполняется первоначальный процесс переговоров ICE, за одним исключением: медиа продолжает передаваться по исходному сетевому подключению до тех пор, пока новое подключение не будет установлено. Затем медиа переключается на новое сетевое подключение, а старое закрывается.

Если вам нужно изменить конфигурацию подключения (например, изменить набор серверов ICE), вы можете сделать это до перезапуска ICE, вызвав RTCPeerConnection.setConfiguration() с обновлённым объектом конфигурации перед перезапуском ICE.

Чтобы явно запустить перезапуск ICE, начните процесс переподключения, вызвав RTCPeerConnection.createOffer(), указав опцию iceRestart со значением true. Затем обработайте процесс подключения так же, как обычно. Это сгенерирует новые значения для фрагмента имени пользователя ICE (ufrag) и пароля, которые будут использоваться процессом переподключения и полученным соединением.

Сторона ответа автоматически начнёт перезапуск ICE, когда будут обнаружены новые значения для ICE ufrag и ICE пароля.