Жизнь WebRTC-сессии

Эта статья не вдается в детали фактически использованных API в установке и обработке WebRTC-соединения. Это просто обзор процесса вцелом с некоторой информацией о том, для чего нужен каждый шаг. Смотрите статью Signaling and video calling, чтобы получить пример с пошаговым объяснением того, что делает код.

Установка соединения

Интернет большой. Реально большой. Умные люди, несколько лет назад, заметив то, насколько он велик, каким большим он может стать и то как быстро растёт, а также ограничения 32-битной системы адресации протокола IP, и поняли, что нужно начать что-то делать, чтобы создать новую 64-битную систему адресации. Но в какой-то момент они так же пришли к выводу, что переход на новую систему займёт больше времени, чем продержатся 32-разрядные адреса. Затем другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-итный IP-адрес. Network Address Translation (NAT) - это стандарт, который поддерживает разделение адреса путем маршрутизации входящих и исходящих пакетов данных в и из локальной сети (LAN), которые разделяют единственный WAN (глобальный) адрес.

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

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

Всё это входит в процесс сигнализации.

Процесс Сигнализации

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

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

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

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

Обмен информации во время процесса сигнализации

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

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

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

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

Поцесс сигнализации

Существует последовательность действий, которую нужно выполнить, чтобы стало возможным начало WebRTC-сессии:

1. Каждый узел создает объект RTCPeerConnection, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.
2. Каждый узел устанавливает обработчик события icecandidate, which handles sending those candidates to the other peer over the signaling channel.
3. Каждый узел устанавливает обработчик события addstream, которое происходит когда начинает приходить поток данных от удаленного узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу <video>.
4. Вызывающий узел создает уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваетсяим с принимающим узлом. Форма и содержимое идентификатора остается на усмотрение разработчика.
5. Каждый узел подключается к согласованному сигнальному серверу, такому например как известный обоим WebSocket-сервер, для омена сообщениями.
6. Каждый узел сообщает сигнальному серверу, что хочет подключиться к одной и той же WebRTC-сессии (идентифицируемой токеном, определенным на шаге 4)
7. descriptions, candidates, etc. -- more coming up

ICE restart

Sometimes, during the lifetime of a WebRTC session, network conditions change. One of the users might transition from a cellular to a WiFi network, or the network might become congested, for example. When this happens, the ICE agent may choose to perform ICE restart. This is a process by which the network connection is renegotiated, exactly the same way the initial ICE negotiation is performed, with one exception: media continues to flow across the original network connection until the new one is up and running. Then media shifts to the new network connection and the old one is closed.

There are two levels of ICE restart: full ICE restart causes all media streams in the session to be renegotiated. Partial ICE restart allows ICE renegotiation of specific media streams instead of all of them at once. Some browsers don't yet support partial ICE restart, however. <<<how do you trigger each?>>>

If you need to change the configuration of the connection in some way (such as changing to a different set of ICE servers), you can do so before restarting ICE by calling RTCPeerConnection.setConfiguration() with an updated RTCConfiguration dictionary before restarting ICE.

To explicitly trigger ICE restart, simply start a negotiation process by calling RTCPeerConnection.createOffer(), specifying the iceRestart option with a value of true. Then handle the connection process from then on just like you normally would.

Transmission

getUserMedia

LocalMediaStream object

Reception