path: root/files/ru/web/api/webrtc_api/session_lifetime/index.html

---
title: Жизнь WebRTC-сессии
slug: Web/API/WebRTC_API/Session_lifetime
translation_of: Web/API/WebRTC_API/Session_lifetime
---
<p>{{WebRTCSidebar}}{{draft}}</p>

<div class="summary">
<dl>
 <dd>WebRTC позволяет браузерным приложениям построить соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию. В этой статье мы увидим то, как живет WebRTC-сессия, начиная с установки соединения и пройдём через весь путь до его завершения, если соединение больше не нужно.</dd>
</dl>
</div>

<p>Эта статья не вдается в детали фактически использованных API в установке и обработке WebRTC-соединения. Это просто обзор процесса в целом с некоторой информацией о том, для чего нужен каждый шаг. Смотрите статью <a href="/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling">Signaling and video calling</a>, чтобы получить пример с пошаговым объяснением того, что делает код.</p>

<div class="note">
<p>Эта страница находится в стадии разработки, и некоторое из содержания будут перемещаться на другие страницы, как направляющий материал. </p>

<p>Вы можете помочь перевести документацию для других разработчиков. Пожалуйста принесите пользу миру и помогите с качественным переводом этой документации.</p>
</div>

<h2 id="Установка_соединения">Установка соединения</h2>

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

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

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

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

<h3 id="Процесс_Сигнализации">Процесс Сигнализации</h3>

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

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

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

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

<h4 id="Обмен_информации_во_время_процесса_сигнализации">Обмен информации во время процесса сигнализации</h4>

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

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

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

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

<h4 id="Процесс_сигнализации">Процесс сигнализации</h4>

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

<ol>
 <li>Каждый узел создает объект {{domxref("RTCPeerConnection")}}, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.</li>
 <li>Каждый узел устанавливает обработчик события {{event("icecandidate")}},которая занимается отправкой этих кандидатов в другую сторону по каналу сигнализации.</li>
 <li>Каждый узел устанавливает обработчик события {{event("addstream")}}, которое срабатывает когда начинает приходить поток данных от удаленного узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу {{HTMLElement("video")}}.</li>
 <li>Вызывающий узел создает уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваться с принимающим узлом. Форма и содержимое идентификатора остается на усмотрение разработчика.</li>
 <li>Каждый узел подключается к согласованному сигнальному серверу, такому например как известный обоим WebSocket-сервер, для обмена сообщениями.</li>
 <li>Каждый узел сообщает сигнальному серверу, что хочет подключиться к одной и той же WebRTC-сессии (идентифицируемой токеном, определенным на шаге 4)</li>
 <li><strong><em>descriptions, candidates, etc. -- more coming up</em></strong></li>
</ol>

<h2 id="Перезапуск_сессии_ICE_агент"><strong>Перезапуск сессии ICE агент</strong></h2>

<p>Иногда, во время срока службы WebRTC сессии, сетевые условия изменяются. Один из пользователей, возможно, перейдет от сотовой сети к сети WiFi или сеть может стать перегруженной. Например: когда это произойдет, ICE агент может перезапустить сессию. Это процесс, с помощью которого сетевое соединение перезапустится и восстановится, точно таким же образом выполняется начальная установка сессии, за одним исключением того пока не установится новая сессия. Тогда сессия сменяется и переходит к новому сетевому соединению, а старое соединение закрывается.</p>

<div class="note">
<p>Различные браузеры поддерживают перезапуск сессии при разных условиях. Не все браузеры будут выполнять перезапуск сессии из-за перегрузки сети, например:</p>
</div>

<p>Есть два уровня перезапуска сессии: полная перезагрузка сессии вызывает все мультимедийные потоки в сеансе и должны быть пересмотрены. Частичная перезагрузка сессии позволяет агенту сессии перезапустить конкретный медиапоток вместо того, чтобы перезапускать  все медиаданные. Некоторые браузеры пока не поддерживают частичную перезагрузку сессии, однако. &lt;&lt;&lt; Все зависит от вашего кодерства... &gt;&gt;&gt;</p>

<p>Если вам необходимо изменить конфигурацию соединения каким-либо образом (например, изменение к другому набору связи), вы можете сделать это перед <code><a href="https://developer.mozilla.org/ru/docs/Web/API/RTCPeerConnection/setConfiguration" title="Документация об этом ещё не написана; пожалуйста, поспособствуйте её написанию!">RTCPeerConnection.setConfiguration()</a>(перед назначением конфигурации)</code> с обновленной <code><a href="https://developer.mozilla.org/ru/docs/Web/API/RTCConfiguration" title="Документация об этом ещё не написана; пожалуйста, поспособствуйте её написанию!">RTCConfiguration</a>(конфигурацией)</code> перед повторным запуском движка.</p>

<p>Чтобы явно вызвать перезапуск сессии, нужно начать переговорный процесс с помощью вызова <code><a href="https://developer.mozilla.org/ru/docs/Web/API/RTCPeerConnection/createOffer" title="Документация об этом ещё не написана; пожалуйста, поспособствуйте её написанию!">RTCPeerConnection.createOffer()</a>,</code> указав параметр iceRestart(перезапуск сессии) со значением истины(true). Затем обработать процесс соединения так, как вы это обычно делаете.</p>

<h2 id="Transmission">Transmission</h2>

<h3 id="getUserMedia">getUserMedia</h3>

<p>LocalMediaStream object</p>

<h2 id="Reception">Reception</h2>