Restore "ё" letter in Russian translation (#239)

* docs(ru): restore ё letter

* docs(ru): resolve conflicts

* refactor(idea): remove ide folder

7 files changed, 44 insertions, 44 deletions

diff --git a/files/ru/web/api/webrtc_api/adapter.js/index.html b/files/ru/web/api/webrtc_api/adapter.js/index.html
index efe5581fc2..575e045e1f 100644
--- a/files/ru/web/api/webrtc_api/adapter.js/index.html
+++ b/files/ru/web/api/webrtc_api/adapter.js/index.html
@@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API/adapter.js
 ---
 <p>{{WebRTCSidebar}}</p>
 
-<p>Несмотря на то, что WebRTC <a href="http://www.w3.org/TR/webrtc/">спецификация</a> относительно стабильна, не все еще браузеры полностью реализуют её функциональность. Некоторые реализации в браузерах все еще содержат префиксы производителей в некоторых, или даже всех WebRTC интерфейсах, и разработчик может самостоятельно, в ручную, учесть вопросы несовместимости в своем коде. Но есть более простой выход. Организация <span class="seoSummary">WebRTC</span> <span class="seoSummary"><a href="https://github.com/webrtc/adapter/">предлагает библиотеку adapter.js</a> для обработки вопросов несовместимостей в различных браузерных реализациях WebRTC. Эта библиотека является JavaScript клином, позволяющим писать код в соответствии со спецификацией, чтобы он работал во всех браузерах с различным уровнем поддержки WebRTC. С ней нет необходимости условно использовать префиксные интерфейсы или реализовывать обходные пути</span></p>
+<p>Несмотря на то, что WebRTC <a href="http://www.w3.org/TR/webrtc/">спецификация</a> относительно стабильна, не все ещё браузеры полностью реализуют её функциональность. Некоторые реализации в браузерах все ещё содержат префиксы производителей в некоторых, или даже всех WebRTC интерфейсах, и разработчик может самостоятельно, в ручную, учесть вопросы несовместимости в своём коде. Но есть более простой выход. Организация <span class="seoSummary">WebRTC</span> <span class="seoSummary"><a href="https://github.com/webrtc/adapter/">предлагает библиотеку adapter.js</a> для обработки вопросов несовместимостей в различных браузерных реализациях WebRTC. Эта библиотека является JavaScript клином, позволяющим писать код в соответствии со спецификацией, чтобы он работал во всех браузерах с различным уровнем поддержки WebRTC. С ней нет необходимости условно использовать префиксные интерфейсы или реализовывать обходные пути</span></p>
 
 <div class="note">
 <p><strong>Примечание :</strong> Поскольку функциональность и названия API-терминов в WebRTC и поддерживаемых браузерах постоянно изменяются, обычно рекомендуется использовать этот адаптер.</p>
diff --git a/files/ru/web/api/webrtc_api/index.html b/files/ru/web/api/webrtc_api/index.html
index 1c3d082d99..e1563f8e4f 100644
--- a/files/ru/web/api/webrtc_api/index.html
+++ b/files/ru/web/api/webrtc_api/index.html
@@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API
 
 <p><span class="seoSummary"><strong>WebRTC</strong> (Web Real-Time Communications) - это технология, которая позволяет Web-приложениям и сайтам захватывать и выборочно передавать аудио и/или видео медиа-потоки, а также обмениваться произвольными данными между браузерами, без обязательного использования посредников. Набор стандартов, которые включает в себя технология WebRTC, позволяет обмениваться данными и проводить пиринговые телеконференции, без необходимости пользователю устанавливать плагины или любое другое стороннее программное обеспечение.</span></p>
 
-<p>WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе. Документация, которую вы здесь найдете, поможет вам понять основы WebRTC, как настроить и использовать соединение для передачи данных и медиа-потока, и многое другое.</p>
+<p>WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе. Документация, которую вы здесь найдёте, поможет вам понять основы WebRTC, как настроить и использовать соединение для передачи данных и медиа-потока, и многое другое.</p>
 
 <h2 id="Совместимость">Совместимость</h2>
 
@@ -39,7 +39,7 @@ translation_of: Web/API/WebRTC_API
 
 <dl>
  <dt>{{domxref("RTCPeerConnection")}}</dt>
- <dd>Представляет  WebRTC соединение между локальным компьютером и удаленным узлом. Используется для обработки успешной передачи данных между двумя узлами.</dd>
+ <dd>Представляет  WebRTC соединение между локальным компьютером и удалённым узлом. Используется для обработки успешной передачи данных между двумя узлами.</dd>
  <dt>{{domxref("RTCSessionDescription")}}</dt>
  <dd>Представляет параметры сессии. Каждый <code>RTCSessionDescription </code>содержит описания <a href="/en-US/docs/Web/API/RTCSessionDescription/type">типа</a>, показывающего какую часть (предложение/ответ) процесса переговоров он описывает, и <a href="/en-US/docs/Glossary/SDP">SDP</a>-дескриптор сессии<code>.</code></dd>
  <dt>{{domxref("RTCIceCandidate")}}</dt>
@@ -47,7 +47,7 @@ translation_of: Web/API/WebRTC_API
  <dt>{{domxref("RTCIceTransport")}}</dt>
  <dd>Представляет информацию о средстве подключения к Интернету (ICE).</dd>
  <dt>{{domxref("RTCPeerConnectionIceEvent")}}</dt>
- <dd>Представляет события, которые происходят в отношении кандидатов ICE, обычно {{domxref ("RTCPeerConnection")}}. Один тип передается данному объекту события: {{event ("icecandidate")}}.</dd>
+ <dd>Представляет события, которые происходят в отношении кандидатов ICE, обычно {{domxref ("RTCPeerConnection")}}. Один тип передаётся данному объекту события: {{event ("icecandidate")}}.</dd>
  <dt>{{domxref("RTCRtpSender")}}</dt>
  <dd>Управляет кодированием и передачей данных через объект типа  {{domxref("MediaStreamTrack")}} для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
  <dt>{{domxref("RTCRtpReceiver")}}</dt>
@@ -59,7 +59,7 @@ translation_of: Web/API/WebRTC_API
  <dt>{{domxref("RTCDataChannel")}}</dt>
  <dd>Представляет двунаправленный канал данных между двумя узлами соединения.</dd>
  <dt>{{domxref("RTCDataChannelEvent")}}</dt>
- <dd>Представляет события, которые возникают при присоединении объекта типа  {{domxref("RTCDataChannel")}} к объекту типа {{domxref("RTCPeerConnection")}}. Один тип передается этому событию {{event("datachannel")}}.</dd>
+ <dd>Представляет события, которые возникают при присоединении объекта типа  {{domxref("RTCDataChannel")}} к объекту типа {{domxref("RTCPeerConnection")}}. Один тип передаётся этому событию {{event("datachannel")}}.</dd>
  <dt>{{domxref("RTCDTMFSender")}}</dt>
  <dd>Управляет кодированием и передачей  двухтональной мультичастотной  (DTMF) сигнализацией для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
  <dt>{{domxref("RTCDTMFToneChangeEvent")}}</dt>
@@ -71,9 +71,9 @@ translation_of: Web/API/WebRTC_API
  <dt>{{domxref("RTCIdentityProvider")}}</dt>
  <dd>Активирует возможность браузеру запросить создание или проверку объявления идентификации.</dd>
  <dt>{{domxref("RTCIdentityAssertion")}}</dt>
- <dd>Представляет идентификатор удаленного узла текущего соединения. Если узел еще не установлен и подтвержден, ссылка на интерфейс вернет <code>null</code>. После установки не изменяется.</dd>
+ <dd>Представляет идентификатор удалённого узла текущего соединения. Если узел ещё не установлен и подтверждён, ссылка на интерфейс вернёт <code>null</code>. После установки не изменяется.</dd>
  <dt>{{domxref("RTCIdentityEvent")}}</dt>
- <dd>Представляет объект события объявление идентификатора провайдером идентификации  (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Один тип передается этому событию {{event("identityresult")}}.</dd>
+ <dd>Представляет объект события объявление идентификатора провайдером идентификации  (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Один тип передаётся этому событию {{event("identityresult")}}.</dd>
  <dt>{{domxref("RTCIdentityErrorEvent")}}</dt>
  <dd>Представляет объект события ошибки, связанной с провайдером идентификации (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Два типа ошибки передаются этому событию : {{event("idpassertionerror")}} и {{event("idpvalidationerror")}}.</dd>
 </dl>
@@ -84,11 +84,11 @@ translation_of: Web/API/WebRTC_API
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/Architecture">Обзор архитектуры WebRTC</a></dt>
  <dd>Под API, который применяют разработчики, чтобы создавать и использовать WebRTC, расположен набор сетевых протоколов и стандартов соединения. Этот обзор - витрина этих стандартов.</dd>
  <dt><a href="https://developer.mozilla.org/ru/docs/Web/API/WebRTC_API/Session_lifetime">Жизнь WebRTC-сессии</a></dt>
- <dd>WebRTC позволяет вам организовать соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию в браузере. В этой статье мы взглянем на жизнь WebRTC-сессии, начиная с установки соединения и пройдем весь путь до его завершения, когда оно больше не нужно.</dd>
+ <dd>WebRTC позволяет вам организовать соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию в браузере. В этой статье мы взглянем на жизнь WebRTC-сессии, начиная с установки соединения и пройдём весь путь до его завершения, когда оно больше не нужно.</dd>
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/Overview">Обзор WebRTC API</a></dt>
  <dd>WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе, чтобы обеспечить поддержку обмена данными и медиа-потоками между двумя и более узлами. В этой статье представлен краткий обзор каждого из этих API и какую цель он преследует.</dd>
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/WebRTC_basics">Основы WebRTC</a></dt>
- <dd>Эта статья проведет вас через создание кросс-браузерного RTC-приложения. К концу этой статьи вы должны иметь работающий дата- и медиа-канал, работающий в режиме точка-точка.</dd>
+ <dd>Эта статья проведёт вас через создание кросс-браузерного RTC-приложения. К концу этой статьи вы должны иметь работающий дата- и медиа-канал, работающий в режиме точка-точка.</dd>
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/Protocols">Протоколы WebRTC</a></dt>
  <dd>В этой статье представлены протоколы, в дополнение к которым создан API WebRTC.</dd>
 </dl>
@@ -113,7 +113,7 @@ translation_of: Web/API/WebRTC_API
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/Simple_RTCDataChannel_sample">Простой пример канала данных RTCDataChannel</a></dt>
  <dd>Интерфейс {{domxref("RTCDataChannel")}}  - это функциональность, которая позволяет открыть канал передачи данных между двумя узлами, по которому можно предавать произвольные данные. Эти API намеренно подобны  <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a>, так, что бы в обоих могла использоваться единая модель программирования.</dd>
  <dt><a href="/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling">Сигнализация и двухсторонние видео вызовы</a></dt>
- <dd>Например, мы берем чат на веб сокете, который мы создали в другом примере, и добавляем в него способность создавать видео вызовы. Сервер чата расширяется функциональностью обработки WebRTC сигнализации.</dd>
+ <dd>Например, мы берём чат на веб сокете, который мы создали в другом примере, и добавляем в него способность создавать видео вызовы. Сервер чата расширяется функциональностью обработки WebRTC сигнализации.</dd>
 </dl>
 
 <h2 id="Ресурсы_2"><a id="Ресурсы" name="Ресурсы">Ресурсы</a></h2>
diff --git a/files/ru/web/api/webrtc_api/session_lifetime/index.html b/files/ru/web/api/webrtc_api/session_lifetime/index.html
index 0b052b5475..adf957e2fd 100644
--- a/files/ru/web/api/webrtc_api/session_lifetime/index.html
+++ b/files/ru/web/api/webrtc_api/session_lifetime/index.html
@@ -7,11 +7,11 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
 
 <div class="summary">
 <dl>
- <dd>WebRTC позволяет браузерным приложениям построить соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию. В этой статье мы увидим то, как живет WebRTC-сессия, начиная с установки соединения и пройдём через весь путь до его завершения, если соединение больше не нужно.</dd>
+ <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>
+<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>
@@ -21,7 +21,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
 
 <h2 id="Установка_соединения">Установка соединения</h2>
 
-<p>Интернет большой. Реально большой. Умные люди, несколько лет назад, заметив то, насколько он велик, каким большим он может стать и то как быстро растёт, а также ограничения 32-битной системы адресации протокола IP, и поняли, что нужно начать что-то делать, чтобы создать новую 64-битную систему адресации. Но в какой-то момент они так же пришли к выводу, что переход на новую систему займёт больше времени, чем продержатся 32-разрядные адреса. Затем другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-итный IP-адрес. Network Address Translation ({{Glossary("NAT")}}) - это стандарт, который поддерживает разделение адреса путем маршрутизации входящих и исходящих пакетов данных в и из локальной сети (LAN), которые разделяют единственный WAN (глобальный) адрес.</p>
+<p>Интернет большой. Реально большой. Умные люди, несколько лет назад, заметив то, насколько он велик, каким большим он может стать и то как быстро растёт, а также ограничения 32-битной системы адресации протокола IP, и поняли, что нужно начать что-то делать, чтобы создать новую 64-битную систему адресации. Но в какой-то момент они так же пришли к выводу, что переход на новую систему займёт больше времени, чем продержатся 32-разрядные адреса. Затем другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-итный IP-адрес. Network Address Translation ({{Glossary("NAT")}}) - это стандарт, который поддерживает разделение адреса путём маршрутизации входящих и исходящих пакетов данных в и из локальной сети (LAN), которые разделяют единственный WAN (глобальный) адрес.</p>
 
 <p>Проблемой для пользователя является то, что каждый отдельный компьютер в сети Интернет не обязан иметь уникальный IP-адрес, и по сути, IP-адрес устройства может измениться не только тогда, когда оно перемещается из одной сети в другую, но и если их сетевой адрес был изменён {{Glossary("NAT")}} и/или {{interwiki("wikipedia", "DHCP")}}. Для разработчиков, пытающихся строить одноранговые сети, эта ситуация является хорошей головоломкой: без уникального идентификатора для каждого устройства, нет возможности моментально автоматически выяснить то, как подключиться к конкретному устройству в Интернет.  Если вызнаете, с кем вы хотите поговорить, вам не обязательно знать, какой адрес у вашего собеседника.</p>
 
@@ -31,7 +31,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
 
 <h3 id="Процесс_Сигнализации">Процесс Сигнализации</h3>
 
-<p>Сигнализация - это процесс передачи управляющей информации между двумя устройствами для определения протоколов связи, каналов, кодирования и формата медиа-данных,  методов передачи данных, а также информации, необходимой для маршрутизации. Наиболее важная вещь, о которой нужно знать о процессе сигнализации для WebRTC - <strong>этот процесс не определен в спецификации</strong>.</p>
+<p>Сигнализация - это процесс передачи управляющей информации между двумя устройствами для определения протоколов связи, каналов, кодирования и формата медиа-данных,  методов передачи данных, а также информации, необходимой для маршрутизации. Наиболее важная вещь, о которой нужно знать о процессе сигнализации для WebRTC - <strong>этот процесс не определён в спецификации</strong>.</p>
 
 <p>Вы можете задаться вопросом, почему нечто основоположное для процесса установки WebRTC-соединения вынесено из спецификации? Ответ прост: потому как два устройства не могут контактировать друг с другом, и спецификация не может предусмотреть все возможные способы использования WebRTC, также это приобретает ещё больший смысл с точки зрения предоставления разработчику возможности выбора наиболее подходящей сетевой технологии и протоколов передачи сообщений.</p>
 
@@ -58,18 +58,18 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
 <p>Существует последовательность действий, которую нужно выполнить, чтобы стало возможным начало WebRTC-сессии:</p>
 
 <ol>
- <li>Каждый узел создает объект {{domxref("RTCPeerConnection")}}, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.</li>
+ <li>Каждый узел создаёт объект {{domxref("RTCPeerConnection")}}, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.</li>
  <li>Каждый узел устанавливает обработчик события {{event("icecandidate")}},которая занимается отправкой этих кандидатов в другую сторону по каналу сигнализации.</li>
- <li>Каждый узел устанавливает обработчик события {{event("addstream")}}, которое срабатывает когда начинает приходить поток данных от удаленного узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу {{HTMLElement("video")}}.</li>
- <li>Вызывающий узел создает уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваться с принимающим узлом. Форма и содержимое идентификатора остается на усмотрение разработчика.</li>
+ <li>Каждый узел устанавливает обработчик события {{event("addstream")}}, которое срабатывает когда начинает приходить поток данных от удалённого узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу {{HTMLElement("video")}}.</li>
+ <li>Вызывающий узел создаёт уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваться с принимающим узлом. Форма и содержимое идентификатора остаётся на усмотрение разработчика.</li>
  <li>Каждый узел подключается к согласованному сигнальному серверу, такому например как известный обоим WebSocket-сервер, для обмена сообщениями.</li>
- <li>Каждый узел сообщает сигнальному серверу, что хочет подключиться к одной и той же WebRTC-сессии (идентифицируемой токеном, определенным на шаге 4)</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>
+<p>Иногда, во время срока службы WebRTC сессии, сетевые условия изменяются. Один из пользователей, возможно, перейдёт от сотовой сети к сети WiFi или сеть может стать перегруженной. Например: когда это произойдёт, ICE агент может перезапустить сессию. Это процесс, с помощью которого сетевое соединение перезапустится и восстановится, точно таким же образом выполняется начальная установка сессии, за одним исключением того пока не установится новая сессия. Тогда сессия сменяется и переходит к новому сетевому соединению, а старое соединение закрывается.</p>
 
 <div class="note">
 <p>Различные браузеры поддерживают перезапуск сессии при разных условиях. Не все браузеры будут выполнять перезапуск сессии из-за перегрузки сети, например:</p>
@@ -77,7 +77,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
 
 <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/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>
 
diff --git a/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html b/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html
index 844c8e0d19..73db097039 100644
--- a/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html
+++ b/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html
@@ -5,9 +5,9 @@ translation_of: Web/API/WebRTC_API/Signaling_and_video_calling
 ---
 <div>{{WebRTCSidebar}}</div>
 
-<p><span class="seoSummary"><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a> позволяет обмениваться медиаданными между двумя устройствами напрямую (peer-to-peer) в режиме реального времени. Соединение устанавливается путем обнаружения и согласования, называемым <strong>сигнализацией (signaling)</strong>. Эта статья объясняет, как сделать двусторонний видеозвонок.</span></p>
+<p><span class="seoSummary"><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a> позволяет обмениваться медиаданными между двумя устройствами напрямую (peer-to-peer) в режиме реального времени. Соединение устанавливается путём обнаружения и согласования, называемым <strong>сигнализацией (signaling)</strong>. Эта статья объясняет, как сделать двусторонний видеозвонок.</span></p>
 
-<p><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a> это технология прямого обмена аудио-, видео- и другими данными в режиме реального времени с одним ключевым условием. Процесс обнаружения и согласования медиаформатов должен происходить так чтобы два устройства, подключенные к разным сетям, могли локализовать друг друга, <a href="/en-US/docs/Web/API/WebRTC_API/Session_lifetime#Establishing_a_connection">как обсуждалось здесь</a>. Этот процесс назван <span class="seoSummary"><strong>сигнализацией </strong></span>и подразумевает, что оба устройства подключаются к третьему, обоюдно согласованному серверу. Через третью сторону устройства определяют адреса друг друга и обмениваются согласующими сообщениями.</p>
+<p><a href="/en-US/docs/Web/API/WebRTC_API">WebRTC</a> это технология прямого обмена аудио-, видео- и другими данными в режиме реального времени с одним ключевым условием. Процесс обнаружения и согласования медиаформатов должен происходить так чтобы два устройства, подключённые к разным сетям, могли локализовать друг друга, <a href="/en-US/docs/Web/API/WebRTC_API/Session_lifetime#Establishing_a_connection">как обсуждалось здесь</a>. Этот процесс назван <span class="seoSummary"><strong>сигнализацией </strong></span>и подразумевает, что оба устройства подключаются к третьему, обоюдно согласованному серверу. Через третью сторону устройства определяют адреса друг друга и обмениваются согласующими сообщениями.</p>
 
 <p>В этой статье мы будем дорабатывать  <a class="external external-icon" href="https://webrtc-from-chat.glitch.me/" rel="noopener">WebSocket-чат</a>, созданный для нашей документации к WebSocket, — добавим к нему двусторонний видеозвонок между двумя пользователями. Вы можете <a href="https://webrtc-from-chat.glitch.me/">использовать этот пример на Glitch</a> или <a href="https://glitch.com/edit/#!/remix/webrtc-from-chat">клонировать его</a>, чтобы поэкспериментировать самим. <a href="https://github.com/mdn/samples-server/tree/master/s/webrtc-from-chat">Весь проект</a> можно посмотреть на GitHub.</p>
 
@@ -21,13 +21,13 @@ translation_of: Web/API/WebRTC_API/Signaling_and_video_calling
 
 <p>Во-первых, нужен сам сервер сигнализации. Спецификация WebRTC не определяет, какой транспорт используется для передачи сигнальной информации. Можете использовать какой вам нравится, от <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket</a> до {{domxref("XMLHttpRequest")}} и почтовых голубей, чтобы передать сигнальную информацию между пирами.</p>
 
-<p>Важно, что серверу не нужно понимать или интерпретировать сигнальные данные. Хотя они в формате {{Glossary("SDP")}}, это не имеет особого значения: содержание сообщений, проходящих через сигнальный сервер - по сути, черный ящик. Значение имеет лишь то, что когда подсистема {{Glossary("ICE")}} дает команду передать данные другому пиру, вы просто это делаете, а уже пир знает, как получить эту информацию и доставить ее на свою подсистему ICE. Все что нужно - передавать сообщения туда и обратно. Содержание совершенно не важно для сигнального сервера.</p>
+<p>Важно, что серверу не нужно понимать или интерпретировать сигнальные данные. Хотя они в формате {{Glossary("SDP")}}, это не имеет особого значения: содержание сообщений, проходящих через сигнальный сервер - по сути, чёрный ящик. Значение имеет лишь то, что когда подсистема {{Glossary("ICE")}} даёт команду передать данные другому пиру, вы просто это делаете, а уже пир знает, как получить эту информацию и доставить её на свою подсистему ICE. Все что нужно - передавать сообщения туда и обратно. Содержание совершенно не важно для сигнального сервера.</p>
 
 <h3 id="Подготовка_сервера_чата_к_сигнализации">Подготовка сервера чата к сигнализации</h3>
 
-<p>Наш <a href="https://github.com/mdn/samples-server/tree/master/s/websocket-chat">сервер чата</a> использует <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a> для отправки информации как {{Glossary("JSON")}}  между каждым клиентом и сервером. Сервер поддерживает несколько типов сообщений для нескольких задач : регистрация нового пользователя, установки имен пользователей, отправка сообщений чата.</p>
+<p>Наш <a href="https://github.com/mdn/samples-server/tree/master/s/websocket-chat">сервер чата</a> использует <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a> для отправки информации как {{Glossary("JSON")}}  между каждым клиентом и сервером. Сервер поддерживает несколько типов сообщений для нескольких задач : регистрация нового пользователя, установки имён пользователей, отправка сообщений чата.</p>
 
-<p>Для того, что бы сервер мог поддерживать функциональность сигнализации и согласование соединения, нам нужно обновить код. Нам нужно направлять сообщения одному конкретному пользователю вместо того, чтобы транслировать их всем подключенным пользователям, а также обеспечить передачу и доставку неизвестных типов сообщений, при этом серверу не нужно будет знать, что это такое. Это позволит нам посылать сигнальные сообщения, используя один и тот же сервер, вместо того, чтобы использовать отдельный сервер.</p>
+<p>Для того, что бы сервер мог поддерживать функциональность сигнализации и согласование соединения, нам нужно обновить код. Нам нужно направлять сообщения одному конкретному пользователю вместо того, чтобы транслировать их всем подключённым пользователям, а также обеспечить передачу и доставку неизвестных типов сообщений, при этом серверу не нужно будет знать, что это такое. Это позволит нам посылать сигнальные сообщения, используя один и тот же сервер, вместо того, чтобы использовать отдельный сервер.</p>
 
 <p>Let's take a look which changes we need to make to the chat server support WebRTC signaling. This is in the file <a href="https://github.com/mdn/samples-server/tree/master/s/webrtc-from-chat/chatserver.js">chatserver.js</a>.</p>
 
diff --git a/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html b/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html
index 4d02e4d5d4..8ed6944d59 100644
--- a/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html
+++ b/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html
@@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API/Simple_RTCDataChannel_sample
 
 <p>Интерфейс {{domxref("RTCDataChannel")}} является функциональностью  <a href="/en-US/docs/Web/API/WebRTC_API">WebRTC API</a> , который позволяет открыть канал между узлами соединения, по которому можно отправлять и получать произвольные данные. Эти  API намеренно сходны с  <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a>, для использования единой программной модели.</p>
 
-<p>В этом примере мы откроем соединение {{domxref ("RTCDataChannel")}}, связывающее два элемента на одной странице. Хотя это явно надуманный сценарий, он полезен для демонстрации последовательности соединения двух узлов. Мы расскажем о механизме выполнения соединения, передачи и получения данных, но оставим немного информации о поиске и подключении к удаленному компьютеру для другого примера.</p>
+<p>В этом примере мы откроем соединение {{domxref ("RTCDataChannel")}}, связывающее два элемента на одной странице. Хотя это явно надуманный сценарий, он полезен для демонстрации последовательности соединения двух узлов. Мы расскажем о механизме выполнения соединения, передачи и получения данных, но оставим немного информации о поиске и подключении к удалённому компьютеру для другого примера.</p>
 
 <h2 id="Разметка_HTML">Разметка HTML</h2>
 
diff --git a/files/ru/web/api/webrtc_api/taking_still_photos/index.html b/files/ru/web/api/webrtc_api/taking_still_photos/index.html
index a15d916a7e..c690fafe2a 100644
--- a/files/ru/web/api/webrtc_api/taking_still_photos/index.html
+++ b/files/ru/web/api/webrtc_api/taking_still_photos/index.html
@@ -40,11 +40,11 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 <h2 id="Код_JavaScript">Код JavaScript</h2>
 
-<p>Посмотрим на  <a href="https://github.com/mdn/samples-server/tree/master/s/webrtc-capturestill/capture.js" rel="noopener">JavaScript code</a>. Разобьем его на части, для упрощения объяснения.</p>
+<p>Посмотрим на  <a href="https://github.com/mdn/samples-server/tree/master/s/webrtc-capturestill/capture.js" rel="noopener">JavaScript code</a>. Разобьём его на части, для упрощения объяснения.</p>
 
 <h3 id="Инициализация">Инициализация</h3>
 
-<p>Начнем с обертки всего скрипта в анонимную функцию, во избежании конфликтов глобальных переменных, затем инициализируем различные нужные  переменные.</p>
+<p>Начнём с обёртки всего скрипта в анонимную функцию, во избежании конфликтов глобальных переменных, затем инициализируем различные нужные  переменные.</p>
 
 <pre>(function() {
   var width = 320;    // Этим создадим ширину фотографии
@@ -106,7 +106,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 <p>Здесь мы называем метод  {{domxref("MediaDevices.getUserMedia()")}} , запрашивая медиапоток без аудиопотока (<code>audio : false</code>). Он возвращает промис, на котором мы определяем методы успешного и не успешного выполнений.</p>
 
-<p>Успешное выполнение промиса передает объект потока( <code>stream</code> ) в качестве параметра функции метода <code>then()</code>., который присваивается свойству <code>srcObject</code> элемента {{HTMLElement("video")}}, направляя поток в него.</p>
+<p>Успешное выполнение промиса передаёт объект потока( <code>stream</code> ) в качестве параметра функции метода <code>then()</code>., который присваивается свойству <code>srcObject</code> элемента {{HTMLElement("video")}}, направляя поток в него.</p>
 
 <p>Как только поток связан с элементом <code>&lt;video&gt;</code> ,  запускаем его воспроизведение, вызовом метода <code><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement#play">HTMLMediaElement.play()</a></code>.</p>
 
@@ -114,7 +114,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 <h4 id="Обработка_события_начала_воспроизведения">Обработка события начала воспроизведения</h4>
 
-<p>После момента вызова метода  <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement#play">HTMLMediaElement.play()</a></code> на элементе {{HTMLElement("video")}}, возникает промежуток времени до начала воспроизведения видеопотока. Для недопущения блокирования интерфейса пользователя в это промежуток, нужно установить обработчик события {{event("canplay")}} элемента <code>video</code> , который сработает, когда элемент начнет воспроизведение видеопотока. В этот момент все свойства элемента <code>video</code> конфигурируются на основе формата потока.</p>
+<p>После момента вызова метода  <code><a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement#play">HTMLMediaElement.play()</a></code> на элементе {{HTMLElement("video")}}, возникает промежуток времени до начала воспроизведения видеопотока. Для недопущения блокирования интерфейса пользователя в это промежуток, нужно установить обработчик события {{event("canplay")}} элемента <code>video</code> , который сработает, когда элемент начнёт воспроизведение видеопотока. В этот момент все свойства элемента <code>video</code> конфигурируются на основе формата потока.</p>
 
 <pre>    video.addEventListener('canplay', function(ev){
       if (!streaming) {
@@ -147,7 +147,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 <h4 id="Завершение_метода_startup">Завершение метода  startup() </h4>
 
-<p>Еще пара строк кода в методе <code>startup()</code>:</p>
+<p>Ещё пара строк кода в методе <code>startup()</code>:</p>
 
 <pre>    clearphoto();
   }</pre>
@@ -167,7 +167,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
     photo.setAttribute('src', data);
   }</pre>
 
-<p>Начнем с получения ссылки на скрытый элемент {{HTMLElement ("canvas")}}, который мы используем для рендеринга за пределами экрана. Затем мы устанавливаем свойство <code>fillStyle</code> в  <code>#AAA</code> ( светло-серый) и заполняем весь холст этим цветом, вызывая метод {{domxref("CanvasRenderingContext2D.fillRect()","fillRect()")}}.</p>
+<p>Начнём с получения ссылки на скрытый элемент {{HTMLElement ("canvas")}}, который мы используем для рендеринга за пределами экрана. Затем мы устанавливаем свойство <code>fillStyle</code> в  <code>#AAA</code> ( светло-серый) и заполняем весь холст этим цветом, вызывая метод {{domxref("CanvasRenderingContext2D.fillRect()","fillRect()")}}.</p>
 
 <p>Наконец, в этой функции мы конвертируем <code>canvas</code> в изображение PNG и вызываем метод <code>{{domxref("Element.setAttribute", "photo.setAttribute()")}}</code> отображая захваченный цветовой фон в элементе изображения (бокса для фотографии).</p>
 
@@ -207,9 +207,9 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 <p>Вы можете экспериментировать с этими эффектами, используя, например, инструмент разработчика FirefoxYou  <a href="https://wiki.developer.mozilla.org/en-US/docs/Tools/Style_Editor">редактор стилей</a>; смотрим <a href="https://wiki.developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Edit_CSS_filters">Редактирование с CSS фильтрами</a> о подробностях выполнения.</p>
 
-<h2 id="Использование_определенных_устройств">Использование определенных устройств</h2>
+<h2 id="Использование_определённых_устройств">Использование определённых устройств</h2>
 
-<p>При необходимости вы можете ограничить набор разрешенных источников видео, определенным устройством или набором устройств. Для этого нужно вызвать метод {{domxref("navigator.mediaDevices.enumerateDevices()")}}. Когда промис разрешиться массивом объектов {{domxref("MediaDeviceInfo")}} , описывающих доступные устройства , выберите те, которым хотите разрешить доступ и укажите соответствующий идентификатор устройства {{domxref("MediaTrackConstraints.deviceId", "deviceId")}} или несколько <code>deviceId</code> в объекте  {{domxref("MediaTrackConstraints")}} , переданном в  {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}}.</p>
+<p>При необходимости вы можете ограничить набор разрешённых источников видео, определённым устройством или набором устройств. Для этого нужно вызвать метод {{domxref("navigator.mediaDevices.enumerateDevices()")}}. Когда промис разрешиться массивом объектов {{domxref("MediaDeviceInfo")}} , описывающих доступные устройства , выберите те, которым хотите разрешить доступ и укажите соответствующий идентификатор устройства {{domxref("MediaTrackConstraints.deviceId", "deviceId")}} или несколько <code>deviceId</code> в объекте  {{domxref("MediaTrackConstraints")}} , переданном в  {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}}.</p>
 
 <h2 id="Смотри_так_же">Смотри так же</h2>
 
diff --git a/files/ru/web/api/webrtc_api/using_data_channels/index.html b/files/ru/web/api/webrtc_api/using_data_channels/index.html
index cbb64c54bb..1c2e5b2521 100644
--- a/files/ru/web/api/webrtc_api/using_data_channels/index.html
+++ b/files/ru/web/api/webrtc_api/using_data_channels/index.html
@@ -16,15 +16,15 @@ translation_of: Web/API/WebRTC_API/Using_data_channels
 <p>Основной транспорт передачи данных, использующийся объектом типа {{domxref("RTCDataChannel")}} может быть создан двумя способами:</p>
 
 <ul>
- <li>Позволить WebRTC создать транспорт и сообщить об этом удаленному узлу (вызвав у него событие типа  {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.</li>
+ <li>Позволить WebRTC создать транспорт и сообщить об этом удалённому узлу (вызвав у него событие типа  {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.</li>
  <li>Написать свои скрипты по согласованию транспорта данных, и сигнализированию другому узлу о необходимости присоединения к новому каналу данных.</li>
 </ul>
 
-<p>Разберем оба случая, начиная с первого, как с наиболее распространенного.</p>
+<p>Разберём оба случая, начиная с первого, как с наиболее распространенного.</p>
 
 <h3 id="Автоматический_режим_согласования">Автоматический режим согласования</h3>
 
-<p>Зачастую, разработчик может позволить объекту соединения обработать согласование  {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением <code>false</code>. Это автоматически активирует <code>RTCPeerConnection</code> на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удаленного узла, связывая два узла вместе по сети.</p>
+<p>Зачастую, разработчик может позволить объекту соединения обработать согласование  {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением <code>false</code>. Это автоматически активирует <code>RTCPeerConnection</code> на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удалённого узла, связывая два узла вместе по сети.</p>
 
 <p>Вызов метода <code>createDataChannel()</code> немедленно возвращает объект типа <code>RTCDataChannel</code>. Подписываясь на событие  {{domxref("RTCDataChannel.open_event", "open")}} , можно будет точно определить когда соединение успешно откроется.</p>
 
@@ -39,7 +39,7 @@ dataChannel.addEventListener("open", (event) =&gt; {
 
 <p>Для ручного согласования соединения, сначала необходимо создать новый объект типа {{domxref("RTCDataChannel")}}, используя метод  {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} объекта {{domxref("RTCPeerConnection")}}, определяя свойство  {{domxref("RTCDataChannelInit.negotiated", "negotiated")}} в значение <code>true</code>. Это сигнализирует объекту соединения не пытаться согласовать соединение автоматически.</p>
 
-<p>Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удаленному узлу, что нужно создать собственный объект типа <code>RTCDataChannel</code> со свойством  <code>negotiated</code>, установленным в значение  <code>true</code>, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа  <code>RTCDataChannel </code>через объект типа <code>RTCPeerConnection</code>.</p>
+<p>Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удалённому узлу, что нужно создать собственный объект типа <code>RTCDataChannel</code> со свойством  <code>negotiated</code>, установленным в значение  <code>true</code>, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа  <code>RTCDataChannel </code>через объект типа <code>RTCPeerConnection</code>.</p>
 
 <pre class="brush: js">let dataChannel = pc.createDataChannel("MyApp Channel", {
   negotiated: true
@@ -51,7 +51,7 @@ dataChannel.addEventListener("open", (event) =&gt; {
 
 requestRemoteChannel(dataChannel.id);</pre>
 
-<p>В данном примере канал создается установкой значения свойства <code>negotiated</code> в <code>true</code>, затем вызывается функция  <code>requestRemoteChannel()</code> , запуская согласование соединения для создания удаленного канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала  <code>id</code>.</p>
+<p>В данном примере канал создаётся установкой значения свойства <code>negotiated</code> в <code>true</code>, затем вызывается функция  <code>requestRemoteChannel()</code> , запуская согласование соединения для создания удалённого канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала  <code>id</code>.</p>
 
 <h2 id="Буферизация">Буферизация</h2>
 
@@ -63,11 +63,11 @@ requestRemoteChannel(dataChannel.id);</pre>
 
 <h2 id="Ограничения_размеров_сообщений">Ограничения размеров сообщений</h2>
 
-<p>Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определенного значения (точное число зависит от сети и используемого транспортного уровня).  На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.</p>
+<p>Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определённого значения (точное число зависит от сети и используемого транспортного уровня).  На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.</p>
 
-<p>Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку <code>usrsctp</code> для реализации SCTP, но все еще существуют ситуации, в которых передача данных по <code>RTCDataChannel</code> каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.</p>
+<p>Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку <code>usrsctp</code> для реализации SCTP, но все ещё существуют ситуации, в которых передача данных по <code>RTCDataChannel</code> каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.</p>
 
-<p>Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершенными, и доставит их получающему <code>RTCDataChannel</code> каналу в виде нескольких сообщений</p>
+<p>Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершёнными, и доставит их получающему <code>RTCDataChannel</code> каналу в виде нескольких сообщений</p>
 
 <p>Сообщения размером менее 16 КБ могут отправляться без проблем, поскольку все основные пользовательские агенты обрабатывают их одинаково.</p>
 
@@ -77,9 +77,9 @@ requestRemoteChannel(dataChannel.id);</pre>
 
 <p>В конечном итоге это стало проблемой. Со временем различные приложения (в том числе внедряющие WebRTC) начали использовать SCTP для передачи больших и больших сообщений. В конце концов стало ясно, что когда сообщения становятся слишком большими, передача большого сообщения может блокировать все другие передачи данных в этом канале данных, включая критические сообщения сигнализации.</p>
 
-<p>Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но еще не реализовано в Chrome (см. <a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=7774">Chromium Bug 7774</a>). С поддержкой EOR полезная нагрузка <code>RTCDataChannel</code> может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.</p>
+<p>Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но ещё не реализовано в Chrome (см. <a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=7774">Chromium Bug 7774</a>). С поддержкой EOR полезная нагрузка <code>RTCDataChannel</code> может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.</p>
 
-<p>Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение <a href="https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata">предложение</a> все еще находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.</p>
+<p>Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение <a href="https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata">предложение</a> все ещё находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.</p>
 
 <p>Поддержка Firefox для ndata находится в процессе реализации. <span style="font-size: 1rem; letter-spacing: -0.00278rem;">Команда Chrome отслеживает реализацию поддержки ndata в</span><span style="font-size: 1rem; letter-spacing: -0.00278rem;"> </span><a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=5696" style="font-size: 1rem; letter-spacing: -0.00278rem;">Chrome Bug 5696</a><span style="font-size: 1rem; letter-spacing: -0.00278rem;">.</span></p>