1 files changed, 70 insertions, 0 deletions
diff --git a/files/ru/web/api/webrtc_api/connectivity/index.html b/files/ru/web/api/webrtc_api/connectivity/index.html
new file mode 100644
index 0000000000..7c4f173c05
--- /dev/null
+++ b/files/ru/web/api/webrtc_api/connectivity/index.html
@@ -0,0 +1,70 @@
+---
+title: WebRTC подключение
+slug: Web/API/WebRTC_API/связь
+translation_of: Web/API/WebRTC_API/Connectivity
+---
+<p>{{WebRTCSidebar}}{{draft}}</p>
+
+<p>Теперь, когда мы рассмотрели протоколы по отдельности, мы можем сложить их вместе. Эта статья описывает, как различные связанные с WebRTC протоколы взаимодействуют друг с другом для того, чтобы создать соединение и передать данные и/или медиа между узлами.</p>
+
+<div class="note">
+<p>Эта страница требует серьёзной переделки для структурной целостности и полноты содержания. Много информации здесь - это хорошо, но организация являет собой путаницу, поскольку сейчас являет собой вид "местности разгрузки"(dumping ground).</p>
+</div>
+
+<h2 id="Что_такое_ПредложениеОтвет_и_Канал_сигнализации">Что  такое Предложение/Ответ и Канал сигнализации?</h2>
+
+<p>К сожалению, WebRTC не может создавать соединения без какого-либо сервера посередине. Мы называем его "каналом сигнализации". Это любого рода канал связи для обмена информацией перед установкой соединения, будь то электронная почта, почтовая открытка или почтовый голубь... Зависит от вас.<br>
+  </p>
+
+<p>Информация, которой мы должны обменяться - это "предложение" и "ответ", которые содержат SDP, упомянутую ниже.</p>
+
+<p>Узел A, тот кто будет инициатором соединения, создаст "предложение". Затем отправит это "предложение" узлу B, используя выбранный "сигнальный канал". Узел B получит "предложение" от "сигнального канала" и создаст "ответ". Затем отправит его обратно узлу A посредством "сигнального канала".</p>
+
+<h3 id="Описания_сессии">Описания сессии</h3>
+
+<p>Конфигурация конечной точки WebRTC-соединения называется <strong>"описание сессии"(session description)</strong>. Описание включает информацию о типе посылаемого медиа, его формате, используемом протоколе передачи, IP-адресе и порте конечной точки, и  другую информацию, необходимую для описания конечной точки передачи медиа. Эта информация обменивается и хранится с помощью <strong>"протокола описания сессии". Session Description Protocol</strong>({{Glossary("SDP")}}). Если вы хотите подробную информацию о формате данных SDP, вы можете найти её в {{RFC(2327)}}.</p>
+
+<p>Когда пользователь запускает WebRTC вызов другого пользователя, создаётся специальное описание, называемое <strong>"предложение"(offer)</strong>. Это описание включает всю информацию для соединения, о предлагаемой конфигурации вызывающего абонента. Получатель затем откликается <strong>"ответом"(answer)</strong>, являющимся описанием его конца соединения. Таким образом, оба устройства разделяют друг с другом информацию, необходимую для того, чтобы обмениваться медиа данными. Этот обмен обрабатывается с помощью "интерактивного создания подключения". Interactive Connectivity Establishment{{Glossary("ICE")}}. ICE - протокол, который позволяет двум устройствам использовать посредника для обмена "предложениями"(offers) и "ответами"(answers), даже если эти два устройства разделены механизмом "преобразования сетевых адресов". ({{Glossary("NAT")}}(Network Address Translation).</p>
+
+<p>Каждый узел, тогда, держит два описания под рукой: <strong>локальное описание (local description)</strong>, описывающее себя и <strong>удалённое описание(remote description)</strong>, описывающее другой конец соединения.</p>
+
+<p>Процесс "предложение/ответ"(offer/answer) выполняется как, когда соединение впервые устанавливается, так и в любой момент, когда формат соединения или другая конфигурация нуждается в изменении. Независимо от того, является ли это новым соединением, или реконфигурированием существующего, это основные шаги, которые должны произойти для обмена "предложением"(offer) и "ответом"(answer). Пропустим ICE-слой на данный момент:</p>
+
+<ol>
+ <li>Вызывающий вызывает {{domxref("RTCPeerConnection.createOffer()")}} для создания "предложения"(offer)</li>
+ <li>Вызывающий вызывает {{domxref("RTCPeerConnection.setLocalDescription()")}} для установки этого "предложения" как локального описания (то есть описания локального конца соединения).</li>
+ <li>Вызывающий использует сигнальный сервер для передачи "предложения" к требуемому получателю вызова.</li>
+ <li>Получатель получает "предложение" и вызывает {{domxref("RTCPeerConnection.setRemoteDescription()")}} для записи его, как удалённого описания(описания другого конца соединения).</li>
+ <li>Получатель делает всякую настройку, которую должен сделать для его конца соединения, включая добавления исходящих потоков для соединения.</li>
+ <li>Получатель затем создаёт "ответ"(answer) посредством вызова {{domxref("RTCPeerConnection.createAnswer()")}}.</li>
+ <li>Получатель вызывает {{domxref("RTCPeerConnection.setLocalDescription()")}}, чтобы установить "ответ"(answer) в качестве локального описания. Получатель теперь знает конфигурацию обоих концов соединения.</li>
+ <li>Получатель использует сигнальный сервер для отправки "ответа"(answer) вызывающему.</li>
+ <li>Вызывающий получает "ответ"(answer).</li>
+ <li>Вызывающий вызывает {{domxref("RTCPeerConnection.setRemoteDescription()")}} для установки "ответа"(answer) как удалённого описания для его конца соединения. Теперь известна конфигурация обоих узлов. Медиа начинает течь в соответствии с настройками.</li>
+</ol>
+
+<h3 id="Рассматриваемые_и_текущие_описания">Рассматриваемые и текущие описания</h3>
+
+<p>Спускаясь на один шаг глубже в процесс, мы находим, что localDescription и remoteDescription, свойства, возвращаемые эти двумя описаниями, не так просты, как выглядят. Потому что во время повторных переговоров(перезаключения) (renegotiation), "предложение"(offer) может быть отклонено, поскольку оно предлагает несовместимый формат. Необходимо, чтобы каждая конечная точка имела возможность предложить новый формат, но не переключаться на него, пока он не принят другим узлом. По этой причине, WebRTC использует <em>"рассматриваемые"</em> и <em>"текущие"</em> "описания".</p>
+
+<p><strong>"Текущее описание"(current description)</strong> (которое возвращается свойствами {{domxref("RTCPeerConnection.currentLocalDescription")}} и {{domxref("RTCPeerConnection.currentRemoteDescription")}}) представляет собой описание, в данный момент, фактически используемое соединением. Это самое недавнее соединение, которое обе стороны полностью согласились использовать.</p>
+
+<p><strong>"Рассматриваемое описание"(pending description)</strong> (возвращаемое {{domxref("RTCPeerConnection.pendingLocalDescription")}} и {{domxref("RTCPeerConnection.pendingRemoteDescription")}}) указывает на то описание, которое в настоящий момент находится на рассмотрении после вызова setLocalDescription() или setRemoteDescription(), соответственно.</p>
+
+<p>При чтении описания (возвращаемого {{domxref("RTCPeerConnection.localDescription")}} и {{domxref("RTCPeerConnection.remoteDescription")}}), возвращаемым значением является значение pendingLocalDescription/pendingRemoteDescription, если есть рассматриваемое описание (то есть, рассматриваемое описание не null). В противном случае, возвращается текущее описание (currentLocalDescription/currentRemoteDescription).</p>
+
+<p>При изменении описания путём вызова setLocalDescription() или setRemoteDescription(), указанное описание устанавливается как "рассматриваемое описание"(pending description), и WebRTC-слой начинает оценивать, действительно ли это приемлемо. После того, как предложенное описание было согласовано, значение currentLocalDescription или currentRemoteDescription изменяется на "рассматриваемое описание"(pending description), и pending description устанавливается снова в null, указывая, что "отложенного описания"(pending description) не существует.</p>
+
+<div class="note">
+<p>pendingLocalDescription содержит не только "предложение" или "ответ" на стадии рассмотрения, но и каких-либо ICE-кандидатов, которые уже были собраны с тех пор, как "предложение" или "ответ" были созданы. Подобным образом, pendingRemoteDescription включает любых удалённых ICE-кандидатов, которые были предоставлены вызовами {{domxref("RTCPeerConnection.addIceCandidate()")}}.</p>
+</div>
+
+<p>Смотрите отдельные статьи по этим свойствам и методам для большей конкретики.</p>
+
+<h2 id="Что_такое_ICE-кандидат">Что такое ICE-кандидат?</h2>
+
+<p>В дополнение к обмену информацией о медиа(обсуждённой выше в offer/answer и SDP), узлы должны обменяться информацией о сетевом соединении. Об этом известно как о ICE-кандидате и деталях доступных методов, которыми узел может общаться (непосредственно или через TURN-сервер).</p>
+
+<h2 id="Весь_обмен_в_сложной_схеме">Весь обмен в сложной схеме</h2>
+
+<p><a href="https://hacks.mozilla.org/wp-content/uploads/2013/07/webrtc-complete-diagram.png"><img alt="A complete architectural diagram showing the whole WebRTC process." src="https://mdn.mozillademos.org/files/6119/webrtc-complete-diagram.png" style="display: block; height: 559px; margin: 0px auto; width: 641px;"></a></p>