aboutsummaryrefslogtreecommitdiff
path: root/files/ru/web/api/webrtc_api
diff options
context:
space:
mode:
Diffstat (limited to 'files/ru/web/api/webrtc_api')
-rw-r--r--files/ru/web/api/webrtc_api/adapter.js/index.html4
-rw-r--r--files/ru/web/api/webrtc_api/index.html10
-rw-r--r--files/ru/web/api/webrtc_api/session_lifetime/index.html8
-rw-r--r--files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html4
-rw-r--r--files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html4
-rw-r--r--files/ru/web/api/webrtc_api/taking_still_photos/index.html18
-rw-r--r--files/ru/web/api/webrtc_api/using_data_channels/index.html6
7 files changed, 27 insertions, 27 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 97e09d25e2..efe5581fc2 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>
@@ -17,7 +17,7 @@ translation_of: Web/API/WebRTC_API/adapter.js
<h2 id="Как_работает_adapter.js">Как работает adapter.js</h2>
-<p>Для каждой версии  браузера, поддерживающего WebRTC, <code>adapter.js</code> реализует необходимые полизаполнители, устанавливает имена API без префиксов и применяет любые другие изменения, необходимые для того, чтобы браузер выполнял код, в сообтветствии со спецификацией WebRTC.</p>
+<p>Для каждой версии  браузера, поддерживающего WebRTC, <code>adapter.js</code> реализует необходимые полизаполнители, устанавливает имена API без префиксов и применяет любые другие изменения, необходимые для того, чтобы браузер выполнял код, в соответствии со спецификацией WebRTC.</p>
<p>Например, в версиях Firefox старше 38 адаптер добавляет свойство {{domxref ("RTCPeerConnection.urls")}}; Firefox изначально не поддерживает это свойство до Firefox 38, а в Chrome адаптер добавляет поддержку API {{jsxref ("Promise")}}, если он отсутствует. Это всего лишь пара примеров. Вот в кратце, какие корректировки производит библиотека.</p>
diff --git a/files/ru/web/api/webrtc_api/index.html b/files/ru/web/api/webrtc_api/index.html
index 78971cd1df..1c3d082d99 100644
--- a/files/ru/web/api/webrtc_api/index.html
+++ b/files/ru/web/api/webrtc_api/index.html
@@ -49,7 +49,7 @@ translation_of: Web/API/WebRTC_API
<dt>{{domxref("RTCPeerConnectionIceEvent")}}</dt>
<dd>Представляет события, которые происходят в отношении кандидатов ICE, обычно {{domxref ("RTCPeerConnection")}}. Один тип передается данному объекту события: {{event ("icecandidate")}}.</dd>
<dt>{{domxref("RTCRtpSender")}}</dt>
- <dd>Управляет кродированием и передачей данных через объект типа  {{domxref("MediaStreamTrack")}} для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
+ <dd>Управляет кодированием и передачей данных через объект типа  {{domxref("MediaStreamTrack")}} для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
<dt>{{domxref("RTCRtpReceiver")}}</dt>
<dd>Управляет получением и декодированием данных через объект типа {{domxref("MediaStreamTrack")}} для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
<dt>{{domxref("RTCTrackEvent")}}</dt>
@@ -57,19 +57,19 @@ translation_of: Web/API/WebRTC_API
<dt>{{domxref("RTCCertificate")}}</dt>
<dd>Представляет сертификат, который использует объект {{domxref("RTCPeerConnection")}}.</dd>
<dt>{{domxref("RTCDataChannel")}}</dt>
- <dd>Представляет двунапрвленный канал данных между двумя узлами соединения.</dd>
+ <dd>Представляет двунаправленный канал данных между двумя узлами соединения.</dd>
<dt>{{domxref("RTCDataChannelEvent")}}</dt>
<dd>Представляет события, которые возникают при присоединении объекта типа  {{domxref("RTCDataChannel")}} к объекту типа {{domxref("RTCPeerConnection")}}. Один тип передается этому событию {{event("datachannel")}}.</dd>
<dt>{{domxref("RTCDTMFSender")}}</dt>
- <dd>Управляет кодированием и передачей  двутональной мультичастотной  (DTMF) сигнализацией для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
+ <dd>Управляет кодированием и передачей  двухтональной мультичастотной  (DTMF) сигнализацией для объекта типа {{domxref("RTCPeerConnection")}}.</dd>
<dt>{{domxref("RTCDTMFToneChangeEvent")}}</dt>
<dd>Указывает на входящее событие изменение тона двутоновой мультичастотной сигнализации  (DTMF). Это событие не всплывает (если не указано иначе) и не является отменяемым (если не указано иначе).</dd>
<dt>{{domxref("RTCStatsReport")}}</dt>
- <dd>Ассинхронно сообщает статус для переданного объекта типа  {{domxref("MediaStreamTrack")}} .</dd>
+ <dd>Асинхронно сообщает статус для переданного объекта типа  {{domxref("MediaStreamTrack")}} .</dd>
<dt>{{domxref("RTCIdentityProviderRegistrar")}}</dt>
<dd>Регистрирует провайдер идентификации (idP).</dd>
<dt>{{domxref("RTCIdentityProvider")}}</dt>
- <dd>Активирует возможность браузеру запросить создание или проверку обяъвления идентификации.</dd>
+ <dd>Активирует возможность браузеру запросить создание или проверку объявления идентификации.</dd>
<dt>{{domxref("RTCIdentityAssertion")}}</dt>
<dd>Представляет идентификатор удаленного узла текущего соединения. Если узел еще не установлен и подтвержден, ссылка на интерфейс вернет <code>null</code>. После установки не изменяется.</dd>
<dt>{{domxref("RTCIdentityEvent")}}</dt>
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 958fd99136..0b052b5475 100644
--- a/files/ru/web/api/webrtc_api/session_lifetime/index.html
+++ b/files/ru/web/api/webrtc_api/session_lifetime/index.html
@@ -11,7 +11,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
</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>
@@ -23,7 +23,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
<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>Проблемой для пользователя является то, что каждый отдельный компьютер в сети Интернет не обязан иметь уникальный IP-адрес, и по сути, IP-адрес устройства может измениться не только тогда, когда оно перемещается из одной сети в другую, но и если их сетевой адрес был изменён {{Glossary("NAT")}} и/или {{interwiki("wikipedia", "DHCP")}}. Для разработчиков, пытающихся строить одноранговые сети, эта ситуация является хорошей головоломкой: без уникального идентификатора для каждого устройства, нет возможности моментально автоматически выяснить то, как подключиться к конкретному устройству в Интернет.  Если вызнаете, с кем вы хотите поговорить, вам не обязательно знать, какой адрес у вашего собеседника.</p>
<p>Это похоже на попытку отправить письмо подруге Мишель, написав только на конверте слово "Мишель" и опустить в почтовый ящик. Вам необходимо выяснить её адрес и указать его на конверте, иначе она сильно удивится, почему вы забыли про её день рождения.</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>
@@ -46,7 +46,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
<ul>
<li>Управляющие сообщения, используемые для настройки, открытия и закрытия каналов коммуникации, а также для обработки ошибок</li>
<li>Информация, необходимая для того, чтобы настроить соединение: информация об IP-адресе и порте необходима узлам, чтобы они могли разговаривать друг с другом.</li>
- <li>Необходимо согласовать медиа-потоки: какие могут использоваться между узлами кодеки и форматы медиа-данных? Все это необходимо согласовать дотого, как будет установлена WebRTC-сессия.</li>
+ <li>Необходимо согласовать медиа-потоки: какие могут использоваться между узлами кодеки и форматы медиа-данных? Все это необходимо согласовать до того, как будет установлена WebRTC-сессия.</li>
</ul>
<p>Только после успешного завершения процесса сигнализации, может быть возможен процесс открытия WebRTC-соединения между узлами.</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 4c4f7ea418..844c8e0d19 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
@@ -1,5 +1,5 @@
---
-title: Сигнализирование и видео вызов
+title: Сигнализированные и видео вызов
slug: Web/API/WebRTC_API/Signaling_and_video_calling
translation_of: Web/API/WebRTC_API/Signaling_and_video_calling
---
@@ -23,7 +23,7 @@ translation_of: Web/API/WebRTC_API/Signaling_and_video_calling
<p>Важно, что серверу не нужно понимать или интерпретировать сигнальные данные. Хотя они в формате {{Glossary("SDP")}}, это не имеет особого значения: содержание сообщений, проходящих через сигнальный сервер - по сути, черный ящик. Значение имеет лишь то, что когда подсистема {{Glossary("ICE")}} дает команду передать данные другому пиру, вы просто это делаете, а уже пир знает, как получить эту информацию и доставить ее на свою подсистему ICE. Все что нужно - передавать сообщения туда и обратно. Содержание совершенно не важно для сигнального сервера.</p>
-<h3 id="Подготовка_сервера_чата_к_сигнализиции">Подготовка сервера чата к сигнализиции</h3>
+<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>
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 5d818e7829..4d02e4d5d4 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
@@ -5,7 +5,7 @@ translation_of: Web/API/WebRTC_API/Simple_RTCDataChannel_sample
---
<p>{{WebRTCSidebar}}</p>
-<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")}} является функциональностью  <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>
@@ -20,7 +20,7 @@ translation_of: Web/API/WebRTC_API/Simple_RTCDataChannel_sample
  Disconnect
&lt;/button&gt;</pre>
-<p>Затем, определяем блок, который содержит элемент управления ввода текста, в который пользователь печатает текст свого сообщения, предназначенного для отправки, по нажатию кнопки. Элемент {{HTMLElement("div")}} будет представлять первый узлел в канале передачи (сторона отправителя).</p>
+<p>Затем, определяем блок, который содержит элемент управления ввода текста, в который пользователь печатает текст своего сообщения, предназначенного для отправки, по нажатию кнопки. Элемент {{HTMLElement("div")}} будет представлять первый узел в канале передачи (сторона отправителя).</p>
<pre class="brush: html">  &lt;div class="messagebox"&gt;
    &lt;label for="message"&gt;Enter a message:
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 ec5e7ec42d..cdd65b56e9 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
@@ -7,17 +7,17 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
---
<p dir="rtl"><span><span><span><span>{{WebRTCSidebar}}</span></span></span></span></p>
-<p><span class="seoSummary"><span><span><span><span>В этой статье объясняется как использовать WebRTC для получения доступа к камере компьютера или мобильного устройства, и захвата кадров с их помощью. </span></span></span></span></span><a href="https://mdn-samples.mozilla.org/s/webrtc-capturestill"><span><span><span><span>Ознакомтесь с примером,</span></span></span></span></a><span><span><span><span> а затем узнайте как это работает.</span></span></span></span></p>
+<p><span class="seoSummary"><span><span><span><span>В этой статье объясняется как использовать WebRTC для получения доступа к камере компьютера или мобильного устройства, и захвата кадров с их помощью. </span></span></span></span></span><a href="https://mdn-samples.mozilla.org/s/webrtc-capturestill"><span><span><span><span>Ознакомьтесь с примером,</span></span></span></span></a><span><span><span><span> а затем узнайте как это работает.</span></span></span></span></p>
<p><img alt="Uz WebRTC balstīta attēla uztveršanas lietotne - kreisajā pusē un bez tīmekļa kameras uzņemšanas video straumē un poga" src="https://mdn.mozillademos.org/files/10281/web-rtc-demo.png" style="display: block; height: 252px; margin: 0 auto; width: 677px;"></p>
-<p><span><span><span><span>Перейдите непостредственно </span></span></span></span><a class="external" href="https://github.com/mdn/samples-server/tree/master/s/webrtc-capturestill" rel="noopener"><span><span><span><span>к коду на Github</span></span></span></span></a><span><span><span><span> , при желании.</span></span></span></span></p>
+<p><span><span><span><span>Перейдите непосредственно </span></span></span></span><a class="external" href="https://github.com/mdn/samples-server/tree/master/s/webrtc-capturestill" rel="noopener"><span><span><span><span>к коду на Github</span></span></span></span></a><span><span><span><span> , при желании.</span></span></span></span></p>
<h2 id="Разметка_HTML"><span><span><span><span>Разметка HTML</span></span></span></span></h2>
<p><a class="external" href="https://github.com/mdn/samples-server/tree/master/s/webrtc-capturestill/index.html" rel="noopener"><span><span><span><span>Наш HTML интерфейс</span></span></span></span></a><span><span><span><span> состоит из двух секций : панель отображения видео потока, из которого будет производиться захват и панель отображения результата захвата. Каждая панель имеет свой элемент </span></span></span><span><span><span>{{HTMLElement ("div")}}, для облегчения стилизации и управления.</span></span></span></span></p>
-<p><span><span><span><span>Первая панель слева содержит два компонента : элемент {{HTMLElement ("video")}} , который будет получать поток, отводимый с камеры, и элемент  </span></span></span></span>{{HTMLElement("button")}}, каторый будет использоваться пользователем для активации захвата видео кадра.</p>
+<p><span><span><span><span>Первая панель слева содержит два компонента : элемент {{HTMLElement ("video")}} , который будет получать поток, отводимый с камеры, и элемент  </span></span></span></span>{{HTMLElement("button")}}, который будет использоваться пользователем для активации захвата видео кадра.</p>
<pre>  &lt;div class="camera"&gt;
    &lt;video id="video"&gt;Video stream not available.&lt;/video&gt;
@@ -40,7 +40,7 @@ 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>
@@ -73,7 +73,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
<dt><code>photo</code></dt>
<dd>Содержит ссылку на элемент  {{HTMLElement("img")}} после загрузки страницы.</dd>
<dt><code>startbutton</code></dt>
- <dd>Содержит ссылку на элемент  {{HTMLElement("button")}} после загрузки страницы, используюется для старта захвата.</dd>
+ <dd>Содержит ссылку на элемент  {{HTMLElement("button")}} после загрузки страницы, используется для старта захвата.</dd>
</dl>
<h3 id="Функция_startup">Функция  startup()</h3>
@@ -104,9 +104,9 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
});
</pre>
-<p>Здесь мы вазываем метод  {{domxref("MediaDevices.getUserMedia()")}} , запрашивая медиапоток без аудиопотока (<code>audio : false</code>). Он возвращает промис, на котором мы определяем методы успешного и не успешного выполнений.</p>
+<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>
@@ -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>
@@ -197,7 +197,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
<p><strong>Примечание :</strong> Используется факт того, что интерфейс {{domxref("HTMLVideoElement")}} похож на интерфейс {{domxref("HTMLImageElement")}} для любых API , которые принимают <code>HTMLImageElement</code> в качестве параметра, с текущим кадром видео, представленным как содержимое изображения.</p>
</div>
-<p>Как тоько  <code>canvas</code> будет содержать захваченное видео, конвертируем его в  PNG формат, вызывая метод {{domxref("HTMLCanvasElement.toDataURL()")}} на нем; наконец вызываем метод {{domxref("Element.setAttribute", "photo.setAttribute()")}} отображая захваченное изображение в элементе изображения (бокса фотографии).</p>
+<p>Как только  <code>canvas</code> будет содержать захваченное видео, конвертируем его в  PNG формат, вызывая метод {{domxref("HTMLCanvasElement.toDataURL()")}} на нем; наконец вызываем метод {{domxref("Element.setAttribute", "photo.setAttribute()")}} отображая захваченное изображение в элементе изображения (бокса фотографии).</p>
<p>Если подходящее изображение не доступно (то есть, <code>width</code> и <code>height</code> равны  0), отчищаем содержимое элемента изображения, вызывая метод <code>clearphoto()</code>.</p>
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 f8074830d4..cbb64c54bb 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
@@ -37,9 +37,9 @@ dataChannel.addEventListener("open", (event) =&gt; {
<h3 id="Ручной_режим_согласования">Ручной режим согласования</h3>
-<p>Для ручного согласования соединения, сначала необходимо создать новый объект типа {{domxref("RTCDataChannel")}}, используя метод  {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} объекта {{domxref("RTCPeerConnection")}}, определяя свойство  {{domxref("RTCDataChannelInit.negotiated", "negotiated")}} в значение <code>true</code>. Это сигнализирует объекту соединения не пытыться согласовать соединение автоматически.</p>
+<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>