initial commit

3 files changed, 539 insertions, 0 deletions

diff --git a/files/pt-br/web/api/webrtc_api/index.html b/files/pt-br/web/api/webrtc_api/index.html
new file mode 100644
index 0000000000..f4a91242e3
--- /dev/null
+++ b/files/pt-br/web/api/webrtc_api/index.html
@@ -0,0 +1,197 @@
+---
+title: WebRTC API
+slug: Web/API/WebRTC_API
+tags:
+  - API
+  - Audio
+  - Landing
+  - Media
+  - NeedsTranslation
+  - Networking
+  - TopicStub
+  - Video
+  - WebRTC
+  - WebRTC API
+  - streaming
+translation_of: Web/API/WebRTC_API
+---
+<div>{{APIRef("WebRTC")}}</div>
+
+<p><span class="seoSummary"><strong>WebRTC</strong> (Web Real-Time Communications) é uma tecnologia que permite aplicativos e sites da Web a capturarem e opcionalmente transmitirem mídia de áudio e/ou vídeo, assim como trocar informação arbitrária entre navegadores sem a necessidade de um intermediador. O conjunto de padrões que abrangem WebRTC possibilita o compartilhamento de informação e a realização de teleconferência peer-to-peer, dispensando a instalação de <em>plug-ins</em> ou quaisquer softwares de terceiros.</span></p>
+
+<p>WebRTC consiste em diversas APIs e protocolos interrelacionados que trabalham juntos. A documentação que você encontrará aqui o ajudará a entender os fundamentos de WebRTC, como configurar e usar, tanto informação, quanto conexões de mídia e mais. </p>
+
+<h2 id="WebRTC_conceitos_e_uso">WebRTC conceitos e uso</h2>
+
+<p>WebRTC serve à diversas propostas, e sobrepõe-se substancialmente com a API de Captura e Transmissão. Juntas, provém capacidades poderosas de multimídia para a Web, incluíndo suporte para conferência em áudio e vídeo, troca de arquivos, administração de identidade, e lidando com sistemas telefônicos legados enviando sinais {{Glossary("DTMF")}}.</p>
+
+<p>Conexões entre dois <em>peers </em>são criadas usando—e representadas por—uma interface {{DOMxRef("RTCPeerConnection")}}. Uma vez que a conexão tenha sido estabilizada e iniciada, media streams ({{DOMxRef("MediaStream")}}s) (transmissões de mídia) e/ou data channels ({{DOMxRef("RTCDataChannel")}}s) (canais de dados) podem ser adicionados à conexão.</p>
+
+<p>Dados de mídia podem consistir em qualquer número de <em>tracks</em>(faixas) de dados de mídia; <em>tracks</em>, que são representados por objetos baseados na interface {{DOMxRef("MediaStreamTrack")}} , que podem conter um número dentre tipos de dados de mídia, incluíndo áudio, vídeo e texto (como legendas ou até mesmo nomes de capítulos). A maioria das transmissões consiste de ao menos uma faixa de áudio e comumente também uma faixa de vídeo, e podem ser usadas para enviar e receber ambas as mídias ao vivo ou dados salvos de mídia (como um filme transmitido).</p>
+
+<p>Você também pode usar a conexão entre dois <em>peers </em>para trocar dados arbitrários binários usando a interface {{DOMxRef("RTCDataChannel")}}. Isto pode ser usado para informação de <em>back-channel </em>(canal de volta), troca de <em>metadata</em>, pacotes de <em>status</em> de games, transferência de arquivos, ou até mesmo como um canal primário para transferir dados.</p>
+
+<p><em><strong>são necessários mais detalhes e links e tutoriais relevantes</strong></em></p>
+
+<h2 id="WebRTC_interfaces">WebRTC interfaces</h2>
+
+<p>Porque WebRTC provê interfaces que trabalham em conjunto para realizar uma variedade de tarefas, nós dividimos as interfaces na listagem abaixo por categoria. Por favor, atente-se a sidebar para uma listagem em ordem alfabética.</p>
+
+<h3 id="Conexão_configuração_e_gerenciamento">Conexão, configuração e gerenciamento</h3>
+
+<p>Estas interfaces são usadas para configurar, abrir e gerenciar conexões WebRTC.</p>
+
+<dl>
+ <dt>{{domxref("RTCPeerConnection")}}</dt>
+ <dd>Representa a conexão WebRTC entre o computador local e um peer remoto. É usado para lidar com um streaming eficiente de dados entre os dois peers.</dd>
+ <dt>{{domxref("RTCDataChannel")}}</dt>
+ <dd>Representa um canal de dados bidirecional entre dois peers de uma conexão</dd>
+ <dt>{{domxref("RTCDataChannelEvent")}}</dt>
+ <dd>Represents events that occur while attaching a {{domxref("RTCDataChannel")}} to a {{domxref("RTCPeerConnection")}}. The only event sent with this interface is {{event("datachannel")}}.</dd>
+ <dt>{{domxref("RTCSessionDescription")}}</dt>
+ <dd>Represents the parameters of a session. Each <code>RTCSessionDescription</code> consists of a description <a href="/en-US/docs/Web/API/RTCSessionDescription/type" title="The property RTCSessionDescription.type is an enum of type RTCSdpType describing the description's type."><code>type</code></a> indicating which part of the offer/answer negotiation process it describes and of the <a href="/en-US/docs/Glossary/SDP" title="SDP: SDP (Session Description Protocol) is the standard describing a peer-to-peer connection. SDP contains the codec, source address, and timing information of audio and video.">SDP</a> descriptor of the session.</dd>
+ <dt>{{domxref("RTCStatsReport")}}</dt>
+ <dd>Provides information detailing statistics for a connection or for an individual track on the connection; the report can be obtained by calling {{domxref("RTCPeerConnection.getStats()")}}.</dd>
+ <dt>{{domxref("RTCIceCandidate")}}</dt>
+ <dd>Represents a candidate internet connectivity establishment (ICE) server for establishing an {{domxref("RTCPeerConnection")}}.</dd>
+ <dt>{{domxref("RTCIceTransport")}}</dt>
+ <dd>Represents information about an internet connectivity establishment (ICE) transport.</dd>
+ <dt>{{domxref("RTCPeerConnectionIceEvent")}}</dt>
+ <dd>Represents events that occurs in relation to ICE candidates with the target, usually an {{domxref("RTCPeerConnection")}}. Only one event is of this type: {{event("icecandidate")}}.</dd>
+ <dt>{{domxref("RTCRtpSender")}}</dt>
+ <dd>Manages the encoding and transmission of data for a {{domxref("MediaStreamTrack")}} on an {{domxref("RTCPeerConnection")}}.</dd>
+ <dt>{{domxref("RTCRtpReceiver")}}</dt>
+ <dd>Manages the reception and decoding of data for a {{domxref("MediaStreamTrack")}} on an {{domxref("RTCPeerConnection")}}.</dd>
+ <dt>{{domxref("RTCTrackEvent")}}</dt>
+ <dd>Indicates that a new incoming {{domxref("MediaStreamTrack")}} was created and an associated {{domxref("RTCRtpReceiver")}} object was added to the {{domxref("RTCPeerConnection")}} object.</dd>
+</dl>
+
+<h3 id="Identity_and_security">Identity and security</h3>
+
+<p>The WebRTC API includes a number of interfaces to manage security and identity.</p>
+
+<dl>
+ <dt>{{domxref("RTCIdentityProvider")}}</dt>
+ <dd>Enables a user agent is able to request that an identity assertion be generated or validated.</dd>
+ <dt>{{domxref("RTCIdentityAssertion")}}</dt>
+ <dd>Represents the identity of the a remote peer of the current connection. If no peer has yet been set and verified this interface returns <code>null</code>. Once set it can't be changed.</dd>
+ <dt>{{domxref("RTCIdentityProviderRegistrar")}}</dt>
+ <dd>Registers an  identity provider (idP).</dd>
+ <dt>{{domxref("RTCIdentityEvent")}}</dt>
+ <dd>Represents an identity assertion generated by an identity provider (idP). This is usually for an {{domxref("RTCPeerConnection")}}. The only event sent with this type is {{event("identityresult")}}.</dd>
+ <dt>{{domxref("RTCIdentityErrorEvent")}}</dt>
+ <dd>Represents an error associated with the identity provider (idP). This is usually for an {{domxref("RTCPeerConnection")}}. Two events are sent with this type: {{event("idpassertionerror")}} and {{event("idpvalidationerror")}}.</dd>
+ <dt>{{domxref("RTCCertificate")}}</dt>
+ <dd>Represents a certificate that an {{domxref("RTCPeerConnection")}} uses to authenticate.</dd>
+</dl>
+
+<h3 id="Telephony">Telephony</h3>
+
+<p>These interfaces are related to interactivity with public-switched telephone networks (PTSNs).</p>
+
+<dl>
+ <dt>{{domxref("RTCDTMFSender")}}</dt>
+ <dd>Manages the encoding and transmission of dual-tone multi-frequency (DTMF) signaling for an {{domxref("RTCPeerConnection")}}.</dd>
+ <dt>{{domxref("RTCDTMFToneChangeEvent")}}</dt>
+ <dd>Indicates an occurrence of a of dual-tone multi-frequency (DTMF). This event does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated).</dd>
+</dl>
+
+<h2 id="Guides">Guides</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Protocols">Introduction to WebRTC protocols</a></dt>
+ <dd>This article introduces the protocols on top of which the WebRTC API is built.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Connectivity">WebRTC connectivity</a></dt>
+ <dd>A guide to how WebRTC connections work and how the various protocols and interfaces can be used together to build powerful communication apps.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Session_lifetime">Lifetime of a WebRTC session</a></dt>
+ <dd>WebRTC lets you build peer-to-peer communication of arbitrary data, audio, or video—or any combination thereof—into a browser application. In this article, we'll look at the lifetime of a WebRTC session, from establishing the connection all the way through closing the connection when it's no longer needed.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling">Signaling and two-way video calling</a></dt>
+ <dd>A tutorial and example which turbs a WebSocket-based chat system created for a previous example and adds support for opening video calls among participants. The chat server's WebSocket connection is used for WebRTC signaling.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Using_data_channels">Using WebRTC data channels</a></dt>
+ <dd>This guide covers how you can use a peer connection and an associated {{domxref("RTCDataChannel")}} to exchange arbitrary data between two peers.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Using_DTMF">Using DTMF with WebRTC</a></dt>
+ <dd>WebRTC's support for interacting with gateways that link to old-school telephone systems includes support for sending DTMF tones using the {{domxref("RTCDTMFSender")}} interface. This guide shows how to do so.</dd>
+</dl>
+
+<h2 id="Tutorials">Tutorials</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/adapter.js">Improving compatibility using WebRTC adapter.js</a></dt>
+ <dd>The WebRTC organization <a href="https://github.com/webrtc/adapter/">provides on GitHub the WebRTC adapter</a> to work around compatibility issues in different browsers' WebRTC implementations. The adapter is a JavaScript shim which lets your code to be written to the specification so that it will "just work" in all browsers with WebRTC support.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Taking_still_photos">Taking still photos with WebRTC</a></dt>
+ <dd>This article shows how to use WebRTC to access the camera on a computer or mobile phone with WebRTC support and take a photo with it.</dd>
+ <dt><a href="/en-US/docs/Web/API/WebRTC_API/Simple_RTCDataChannel_sample">A simple RTCDataChannel sample</a></dt>
+ <dd>The {{domxref("RTCDataChannel")}} interface is a feature which lets you open a channel between two peers over which you may send and receive arbitrary data. The API is intentionally similar to the <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a>, so that the same programming model can be used for each.</dd>
+</dl>
+
+<h2 id="Resources">Resources</h2>
+
+<h3 id="Protocols">Protocols</h3>
+
+<h4 id="WebRTC-proper_protocols">WebRTC-proper protocols</h4>
+
+<ul>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/"><cite>Application Layer Protocol Negotiation for Web Real-Time Communications</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/"><cite>WebRTC Audio Codec and Processing Requirements</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/"><cite>RTCWeb Data Channels</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/"><cite>RTCWeb Data Channel Protocol</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/"><cite>Web Real-Time Communication (WebRTC): Media Transport and Use of RTP</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/"><cite>WebRTC Security Architecture</cite></a></li>
+ <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/"><cite>Transports for RTCWEB</cite></a></li>
+</ul>
+
+<h4 id="Related_supporting_protocols">Related supporting protocols</h4>
+
+<ul>
+ <li><a href="https://tools.ietf.org/html/rfc5245">Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocol</a></li>
+ <li><a href="https://tools.ietf.org/html/rfc5389"><cite>Session Traversal Utilities for NAT (STUN)</cite></a></li>
+ <li><a href="https://tools.ietf.org/html/rfc7064"><cite>URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol</cite></a></li>
+ <li><a href="https://tools.ietf.org/html/rfc7065"><cite>Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</cite></a></li>
+ <li><a href="https://tools.ietf.org/html/rfc3264"><cite>An Offer/Answer Model with Session Description Protocol (SDP)</cite></a></li>
+ <li><a href="https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/"><cite>Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization</cite></a></li>
+</ul>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName('WebRTC 1.0')}}</td>
+   <td>{{Spec2('WebRTC 1.0')}}</td>
+   <td>The initial definition of the API of WebRTC.</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Media Capture')}}</td>
+   <td>{{Spec2('Media Capture')}}</td>
+   <td>The initial definition of the object conveying the stream of media content.</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Media Capture DOM Elements')}}</td>
+   <td>{{Spec2('Media Capture DOM Elements')}}</td>
+   <td>The initial definition on how to obtain stream of content from DOM Elements</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>In additions to these specifications defining the API needed to use WebRTC, there are several protocols, listed under <a href="#Protocols">resources</a>.</p>
+
+<h2 class="Related_Topics" id="See_also">See also</h2>
+
+<ul>
+ <li>{{domxref("MediaDevices")}}</li>
+ <li>{{domxref("MediaStreamEvent")}}</li>
+ <li>{{domxref("MediaStreamConstraints")}}</li>
+ <li>{{domxref("MediaStreamTrack")}}</li>
+ <li>{{domxref("MessageEvent")}}</li>
+ <li>{{domxref("MediaStream")}}</li>
+ <li><a href="https://hacks.mozilla.org/2015/06/firefox-multistream-and-renegotiation-for-jitsi-videobridge/">Firefox multistream and renegotiation for Jitsi Videobridge</a></li>
+ <li><a href="https://hacks.mozilla.org/2015/04/peering-through-the-webrtc-fog-with-socketpeer/">Peering Through the WebRTC Fog with SocketPeer</a></li>
+ <li><a href="https://hacks.mozilla.org/2014/04/inside-the-party-bus-building-a-web-app-with-multiple-live-video-streams-interactive-graphics/">Inside the Party Bus: Building a Web App with Multiple Live Video Streams + Interactive Graphics</a></li>
+</ul>
diff --git a/files/pt-br/web/api/webrtc_api/protocols/index.html b/files/pt-br/web/api/webrtc_api/protocols/index.html
new file mode 100644
index 0000000000..973a160ca7
--- /dev/null
+++ b/files/pt-br/web/api/webrtc_api/protocols/index.html
@@ -0,0 +1,70 @@
+---
+title: Introdução aos protocolos WebRTC
+slug: Web/API/WebRTC_API/Protocols
+tags:
+  - API
+  - Audio
+  - Guía
+  - ICE
+  - Iniciante
+  - Media
+  - NAT
+  - Projeto
+  - SDP
+  - STUN
+  - TURN
+  - Video
+  - WebRTC
+  - WebRTC API
+translation_of: Web/API/WebRTC_API/Protocols
+---
+<div>{{WebRTCSidebar}}{{draft}}</div>
+
+<p>Este artigo apresenta os protocolos sobre os quais a API WebRTC é construída.</p>
+
+<h2 id="ICE">ICE</h2>
+
+<p><a href="http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment">Interactive Connectivity Establishment (ICE)</a> é a estrutura que permite seu navegador web se conectar com outras pessoas. Existem muitas razões pelas quais uma conexão direta do Ponto A para o Ponto B simplesmente não funciona. Ele precisa ignorar firewalls que impediriam a abertura de conexões, fornecer um endereço exclusivo, como na maioria das situações, caso seu dispositivo não tiver um endereço IP público e retransmitir dados por meio de um servidor ou se seu roteador não permitir a conexão direta com seus pares . O ICE usa servidores STUN e / ou TURN para fazer isso, conforme descrito abaixo.</p>
+
+<h2 id="STUN">STUN</h2>
+
+<p><a href="http://en.wikipedia.org/wiki/STUN">Session Traversal Utilities for <u>NAT</u> (STU<u>N</u>)</a> (sigla dentro de uma sigla) é um protocolo para descobrir seu endereço público e determinar quaisquer restrições em seu roteador que poderiam impedir uma conexão direta com um par.</p>
+
+<p>O cliente enviará uma solicitação a um servidor STUN na Internet que responderá com o endereço público do cliente e se o cliente está ou não acessível por meio do NAT do roteador.</p>
+
+<p><img alt="An interaction between two users of a WebRTC application involving a STUN server." src="https://mdn.mozillademos.org/files/6115/webrtc-stun.png" style="display: block; height: 378px; margin: 0px auto; width: 259px;"></p>
+
+<h2 id="NAT">NAT</h2>
+
+<p><a href="https://en.wikipedia.org/wiki/Network_address_translation">Network Address Translation (NAT)</a> é usado para dar ao seu dispositivo um endereço IP público. Um roteador terá um endereço IP público e cada dispositivo conectado ao roteador terá um endereço IP privado. As solicitações serão traduzidas do IP privado do dispositivo para o IP público do roteador com uma porta exclusiva. Dessa forma, você não precisa de um IP público exclusivo para cada dispositivo, mas ainda pode ser descoberto na Internet.</p>
+
+<p>Alguns roteadores terão restrições sobre quem pode se conectar a dispositivos na rede. Isso pode significar que, embora tenhamos o endereço IP público encontrado pelo servidor STUN, ninguém pode criar uma conexão. Nesta situação, precisamos voltar para TURN.</p>
+
+<h2 id="TURN">TURN</h2>
+
+<p>Alguns roteadores que usam NAT empregam uma restrição chamada ‘Symmetric NAT’ (<em>NAT simétrico</em>). Isso significa que o roteador só aceitará conexões de pares aos quais você já se conectou.</p>
+
+<p><a href="http://en.wikipedia.org/wiki/TURN">Traversal Using Relays around NAT (TURN)</a> destina-se a contornar a restrição de NAT simétrico abrindo uma conexão com um servidor TURN para que ele re-transmita toda informação. Você criaria uma conexão com um servidor TURN e avisaria a todos os pares (<em>peers</em>) para enviar pacotes para este servidor, que lhe encaminharia. Isso obviamente vem com alguma sobrecarga, então só é usado se não houver outras alternativas.</p>
+
+<p><img alt="An interaction between two users of a WebRTC application involving STUN and TURN servers." src="https://mdn.mozillademos.org/files/6117/webrtc-turn.png" style="display: block; height: 297px; margin: 0px auto; width: 295px;"></p>
+
+<h2 id="SDP">SDP</h2>
+
+<p><a href="http://en.wikipedia.org/wiki/Session_Description_Protocol">Session Description Protocol (SDP)</a> é um padrão para descrever o conteúdo multimídia da conexão, como resolução, formatos, codecs, criptografia, etc., para que os dois pontos possam se entender uma vez que os dados estejam sendo transferidos. Em essência, são os metadados que descrevem o conteúdo e não o conteúdo da mídia em si.</p>
+
+<p>Tecnicamente, então, SDP não é realmente um protocolo, mas um formato de dados usado para descrever a conexão que compartilha mídia entre dispositivos.</p>
+
+<p>A documentação do SDP está bem fora do escopo desta documentação; no entanto, existem algumas coisas que vale a pena observar aqui.</p>
+
+<h3 id="Estrutura">Estrutura</h3>
+
+<p>O SDP consiste em uma ou mais linhas de texto UTF-8, cada uma começando com um tipo de um caractere, seguido por um sinal de igual ("="), seguido por um texto estruturado contendo um valor ou descrição, cujo formato depende do tipo. As linhas de texto que começam com uma determinada letra são geralmente chamadas de "letter-lines" (<em>"linhas de letras</em><em>"</em>). Por exemplo, as linhas que fornecem descrições de mídia têm o tipo "m", portanto, essas linhas são chamadas de "linhas m".</p>
+
+<h3 id="Para_mais_informações">Para mais informações</h3>
+
+<p>Para saber mais sobre o SDP, consulte os seguintes recursos úteis:</p>
+
+<ul>
+ <li>Especificação: {{RFC(4566, "SDP: Session Description Protocol")}}</li>
+ <li><a href="https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml">IANA registry of SDP parameters</a></li>
+</ul>
diff --git a/files/pt-br/web/api/webrtc_api/simples_rtcdatachannel_amostra/index.html b/files/pt-br/web/api/webrtc_api/simples_rtcdatachannel_amostra/index.html
new file mode 100644
index 0000000000..72ac37e56a
--- /dev/null
+++ b/files/pt-br/web/api/webrtc_api/simples_rtcdatachannel_amostra/index.html
@@ -0,0 +1,272 @@
+---
+title: Uma simples amostra de RTCDataChannel
+slug: Web/API/WebRTC_API/Simples_RTCDataChannel_amostra
+translation_of: Web/API/WebRTC_API/Simple_RTCDataChannel_sample
+---
+<p>{{WebRTCSidebar}}</p>
+
+<p>A interface {{domxref("RTCDataChannel")}} é um recurso da <a href="/en-US/docs/Web/API/WebRTC_API">WebRTC API</a> que permite abrir um canal entre dois pares sobre os quais você pode enviar e receber dados arbitrários. A API é intencionalmente semelhante à <a href="/en-US/docs/Web/API/WebSocket_API">WebSocket API</a>, de modo que o mesmo modelo de programação pode ser usado para ambos.</p>
+
+<p>Neste exemplo, abriremos um {{domxref("RTCDataChannel")}} para realizar a conexão entre dois elementos na mesma página. Embora seja obviamente um cenário artificial, é útil para demonstrar o fluxo de conexão entre dois pares. Vamos cobrir a mecânica necessária para conectar, transmitir e receber dados, mas vamos deixar para outro exemplo os detalhes sobre como localizar e se conectar a um computador remoto.</p>
+
+<h2 id="O_HTML">O HTML</h2>
+
+<p>Primeiro, vamos dar uma olhada rápida no <a class="external" href="https://github.com/mdn/samples-server/tree/master/s/webrtc-simple-datachannel/index.html" rel="noopener">HTML que é necessário</a>. Não há nada incrivelmente complicado aqui. Primeiro, temos um par de botões para estabelecer e fechar a conexão:</p>
+
+<pre class="brush: html">&lt;button id="connectButton" name="connectButton" class="buttonleft"&gt;
+  Conectar
+&lt;/button&gt;
+&lt;button id="disconnectButton" name="disconnectButton" class="buttonright" disabled&gt;
+  Desconectar
+&lt;/button&gt;</pre>
+
+<p>Depois, há uma caixa que contém o campo de <em>input </em>no qual o usuário pode digitar uma mensagem para transmitir, com um botão para enviar o texto digitado. Este {{HTMLElement("div")}} será o primeiro ponto (peer) no canal.</p>
+
+<pre class="brush: html">  &lt;div class="messagebox"&gt;
+    &lt;label for="message"&gt;Insira a mensagem:
+      &lt;input type="text" name="message" id="message" placeholder="Texto da mensagem"
+              inputmode="latin" size=60 maxlength=120 disabled&gt;
+    &lt;/label&gt;
+    &lt;button id="sendButton" name="sendButton" class="buttonright" disabled&gt;
+      Enviar
+    &lt;/button&gt;
+  &lt;/div&gt;</pre>
+
+<p>Finalmente, há uma pequena caixa na qual vamos inserir as mensagens. Este bloco {{HTMLElement("div")}} será o segundo ponto do par (peer).</p>
+
+<pre class="brush: html">&lt;div class="messagebox" id="receivebox"&gt;
+  &lt;p&gt;Mensagens recebidas:&lt;/p&gt;
+&lt;/div&gt;</pre>
+
+<h2 id="O_código_JavaScript">O código JavaScript</h2>
+
+<p>Como você pode simplesmente <a class="external" href="https://github.com/mdn/samples-server/tree/master/s/webrtc-simple-datachannel/main.js" rel="noopener">ver o próprio código no GitHub</a>, abaixo, analisaremos as partes do código que fazem o trabalho pesado.</p>
+
+<p>A WebRTC API faz um intenso uso de {{jsxref("Promise")}}s. Que tornam muito fácil encadear as etapas do processo de conexão; Se você ainda não leu sobre esta funcionalidade do <a href="/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla">ECMAScript 2015</a>, você deveria ler sobre eles. Da mesma forma, este exemplo usa <a href="/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions">arrow functions</a> para simplificar a sintaxe.</p>
+
+<h3 id="Começando">Começando</h3>
+
+<p>Quando o script é executado, configuramos um {{event("load")}} ouvinte de eventos (event listener), De modo que, uma vez que a página esteja totalmente carregada, nossa função <code>startup()</code> seja chamada.</p>
+
+<pre class="brush: js">function startup() {
+  connectButton = document.getElementById('connectButton');
+  disconnectButton = document.getElementById('disconnectButton');
+  sendButton = document.getElementById('sendButton');
+  messageInputBox = document.getElementById('message');
+  receiveBox = document.getElementById('receivebox');
+
+  // Define os ouvintes de eventos para os elementos da interface do usuário
+
+  connectButton.addEventListener('click', connectPeers, false);
+  disconnectButton.addEventListener('click', disconnectPeers, false);
+  sendButton.addEventListener('click', sendMessage, false);
+}</pre>
+
+<p>Isso é bastante direto. Pegamos referências de todos os elementos da página que precisaremos acessar e, em seguida, configuramos {{domxref("EventListener", "event listeners")}} nos três botões.</p>
+
+<h3 id="Estabelecendo_uma_conexão">Estabelecendo uma conexão</h3>
+
+<p>Quando o usuário clica no botão "Conectar", o método <code>connectPeers()</code> é chamado. Para que fique mais claro, iremos quebrar o código em mais partes, e analisar um pouco de cada vez.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> Mesmo que ambas as extremidades da nossa conexão estejam na mesma página, vamos nos referir ao ponto que inicia a conexão como "local", e ao outro como sendo o "remoto".</p>
+</div>
+
+<h4 id="Configurando_o_ponto_local_(local_peer)">Configurando o ponto local (local peer)</h4>
+
+<pre class="brush: js">localConnection = new RTCPeerConnection();
+
+sendChannel = localConnection.createDataChannel("sendChannel");
+sendChannel.onopen = handleSendChannelStatusChange;
+sendChannel.onclose = handleSendChannelStatusChange;
+</pre>
+
+<p>O primeiro passo é criar o ponto "local" da conexão. Este é o ponto que enviará o pedido de conexão. O próximo passo é criar o {{domxref("RTCDataChannel")}} chamando {{domxref("RTCPeerConnection.createDataChannel()")}} e configurando ouvintes de eventos (event listeners) para monitorar o canal, e para que possamos saber quando ele for aberto e fechado (isto é, quando o canal está conectado ou desconectado dentro dessa conexão entre pares (peer connection)).</p>
+
+<p>É importante ter em mente que cada extremidade do canal tem seu próprio objeto {{domxref("RTCDataChannel")}} .</p>
+
+<h4 id="Configurando_o_ponto_remoto_(remote_peer)">Configurando o ponto remoto (remote peer)</h4>
+
+<pre class="brush: js">remoteConnection = new RTCPeerConnection();
+remoteConnection.ondatachannel = receiveChannelCallback;</pre>
+
+<p>O ponto remoto está configurado de forma semelhante, exceto que não precisamos nós mesmos criar explicitamente um {{domxref("RTCDataChannel")}} , uma vez que vamos ser conectados através do canal estabelecido acima. Em vez disso, criamos um {{event("datachannel")}} manipulador de eventos (event handler); Isso será chamado quando o canal de dados (data channel) for aberto; Este manipulador (handler) receberá um objeto <code>RTCDataChannel</code>; você verá isso abaixo.</p>
+
+<h4 id="Configurando_ICE_candidates">Configurando  ICE candidates</h4>
+
+<p>O próximo passo é configurar cada conexão com os ouvintes do ICE que serão chamados quando houver um novo candidato ICE para comunicar com o outro lado.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> Em um cenário do mundo real em que os dois pares não estão sendo executados no mesmo contexto, o processo é um pouco mais complexo; Cada lado fornece, um de cada vez, um sugestão sobre como conectar (por exemplo, UDP, UDP com um relay, TCP, etc.) chamando {{domxref("RTCPeerConnection.addIceCandidate()")}}, e eles vão de um lado para outro até chegarem a um acordo. Mas aqui, acabamos de aceitar a primeira oferta de cada lado, uma vez que não existe uma rede real envolvida.</p>
+</div>
+
+<pre class="brush: js">    localConnection.onicecandidate = e =&gt; !e.candidate
+        || remoteConnection.addIceCandidate(e.candidate)
+        .catch(handleAddCandidateError);
+
+    remoteConnection.onicecandidate = e =&gt; !e.candidate
+        || localConnection.addIceCandidate(e.candidate)
+        .catch(handleAddCandidateError);</pre>
+
+<p>Configuramos cada {{domxref("RTCPeerConnection")}} para ter um manipulador de eventos (event handler) para o evento {{event("icecandidate")}} .</p>
+
+<h4 id="Iniciando_a_tentativa_de_conexão">Iniciando a tentativa de conexão</h4>
+
+<p>A última coisa que precisamos fazer para começar a conectar nossos pares é criar uma oferta de conexão.</p>
+
+<pre class="brush: js">    localConnection.createOffer()
+    .then(offer =&gt; localConnection.setLocalDescription(offer))
+    .then(() =&gt; remoteConnection.setRemoteDescription(localConnection.localDescription))
+    .then(() =&gt; remoteConnection.createAnswer())
+    .then(answer =&gt; remoteConnection.setLocalDescription(answer))
+    .then(() =&gt; localConnection.setRemoteDescription(remoteConnection.localDescription))
+    .catch(handleCreateDescriptionError);</pre>
+
+<p>Vamos passar por isto linha por linha e decifrar o que significa.</p>
+
+<ol>
+ <li>Primeiro chamamos {{domxref("RTCPeerConnection.createOffer()")}} método para criar um resumo {{Glossary("SDP")}} (Session Description Protocol) descrevendo a conexão que queremos fazer. Este método aceita, opcionalmente, um objeto com restrições a serem suportadas pela conexão para atender às suas necessidades, como no caso da conexão precisar suportar áudio, vídeo ou ambos. Em nosso exemplo simples, não temos restrições.</li>
+ <li>Se a oferta for criada com sucesso, passamos o resumo junto ao método de conexões locais {{domxref("RTCPeerConnection.setLocalDescription()")}} . Isso configura o ponto local da conexão.</li>
+ <li>O próximo passo é conectar o ponto local ao remoto comunicando ao ponto remoto sobre ele. Isso é feito chamando <code>remoteConnection.</code>{{domxref("RTCPeerConnection.setRemoteDescription()")}}. Agora o <code>remoteConnection</code> conhece a conexão que está sendo construída.</li>
+ <li>Isso significa que é hora do ponto remoto responder. Ele faz isso chamando o método {{domxref("RTCPeerConnection.createAnswer", "createAnswer()")}} . Isso gera um resumo de SDP que descreve a conexão que o ponto remoto está disposto e capaz de estabelecer. Essa configuração está em algum lugar na união das opções que ambos os pares podem suportar.</li>
+ <li>Uma vez que a resposta foi criada, ela é passada para o <em>remoteConnection </em>chamando {{domxref("RTCPeerConnection.setLocalDescription()")}}. Isso estabelece o ponto remoto da conexão (que, para o ponto remoto, é o ponto local. Isso pode parecer confuso, mas você irá se acostumar com isso.</li>
+ <li>Finalmente, a descrição local das conexões remotas está configurada para se referir ao ponto remoto, chamando localConnection's {{domxref("RTCPeerConnection.setRemoteDescription()")}}.</li>
+ <li>O <code>catch()</code> chama uma rotina que lida com os erros que ocorrem.</li>
+</ol>
+
+<div class="note">
+<p><strong>Nota:</strong> Mais uma vez, esse processo não é uma implementação do mundo real; No uso normal, há dois pedaços de código executados em duas máquinas, interagindo e negociando a conexão.</p>
+</div>
+
+<h4 id="Manipulação_da_conexão_de_pares_bem_sucedida">Manipulação da conexão de pares bem sucedida</h4>
+
+<p>Como cada lado da conexão peer-to-peer é conectado com sucesso, o evento correspondente {{domxref("RTCPeerConnection")}}'s {{event("icecandidate")}} é disparado. Esses manipuladores podem fazer o que for necessário, mas, neste exemplo, tudo o que precisamos fazer é atualizar a interface do usuário:</p>
+
+<pre class="brush: js">  function handleLocalAddCandidateSuccess() {
+    connectButton.disabled = true;
+  }
+
+  function handleRemoteAddCandidateSuccess() {
+    disconnectButton.disabled = false;
+  }</pre>
+
+<p>A única coisa que fazemos aqui é desativar o botão "Conectar" quando o ponto local estiver conectado e ativar o botão "Desconectar" quando o ponto remoto se conectar.</p>
+
+<h4 id="Conectando_o_canal_de_dados">Conectando o canal de dados</h4>
+
+<p>Uma vez que o {{domxref("RTCPeerConnection")}} é aberto, o evento {{event("datachannel")}} é enviado para o ponto remoto para completar o processo de abertura do canal de dados; Isso invoca nosso método <code>receiveChannelCallback()</code>, que se parece com isso:</p>
+
+<pre class="brush: js">  function receiveChannelCallback(event) {
+    receiveChannel = event.channel;
+    receiveChannel.onmessage = handleReceiveMessage;
+    receiveChannel.onopen = handleReceiveChannelStatusChange;
+    receiveChannel.onclose = handleReceiveChannelStatusChange;
+  }</pre>
+
+<p>O evento{{event("datachannel")}} inclui, em sua propriedade de canal, uma referência a um {{domxref("RTCDataChannel")}} Representando o ponto remoto do canal. Isso é salvo, e nós configuramos, no canal, ouvintes de eventos para os eventos que queremos manipular. Uma vez feito isso, nosso método <code>handleReceiveMessage()</code> Será chamado cada vez que os dados são recebidos pelo ponto remoto, e o método <code>handleReceiveChannelStatusChange()</code> será chamado sempre que mudar o estado da conexão do canal, para que possamos reagir quando o canal estiver totalmente aberto e quando ele for fechado.</p>
+
+<h3 id="Lidando_com_as_mudanças_de_status_do_canal">Lidando com as mudanças de status do canal</h3>
+
+<p>Ambos nossos pontos locais e remotos usam um único método para lidar com eventos que indicam alguma alteração no status da conexão do canal.</p>
+
+<p>Quando o ponto local experimenta um evento aberto ou fechado, o método<code>handleSendChannelStatusChange()</code> é chamado:</p>
+
+<pre class="brush: js">  function handleSendChannelStatusChange(event) {
+    if (sendChannel) {
+      var state = sendChannel.readyState;
+
+      if (state === "open") {
+        messageInputBox.disabled = false;
+        messageInputBox.focus();
+        sendButton.disabled = false;
+        disconnectButton.disabled = false;
+        connectButton.disabled = true;
+      } else {
+        messageInputBox.disabled = true;
+        sendButton.disabled = true;
+        connectButton.disabled = false;
+        disconnectButton.disabled = true;
+      }
+    }
+  }</pre>
+
+<p>Se o estado do canal mudou para "open", isso indica que terminamos de estabelecer o link entre os dois pares. A interface do usuário é atualizada de forma correspondente: ativando o elemento de input de texto para a mensagem a ser enviada, focando este elemento de input para que o usuário comece imediatamente a digitar, habilitando os botões "Enviar" e "Desconectar", que são agora utilizáveis, E desativando o botão "Conectar", uma vez que não é necessário quando a conexão está aberta.</p>
+
+<p>Se o estado do canal mudou para "closed", ocorre o conjunto oposto de ações: a caixa de entrada de texto e o botão "Enviar" estão desativados, o botão "Conectar" está habilitado para que o usuário possa abrir uma nova conexão se desejar, e o botão "Desconectar" está desativado, uma vez que não é útil quando não existe conexão.</p>
+
+<p>Nosso exemplo de par remoto, por outro lado, ignora os eventos de alteração de status, exceto para registrar o evento no console:</p>
+
+<pre class="brush: js">  function handleReceiveChannelStatusChange(event) {
+    if (receiveChannel) {
+      console.log("Receive channel's status has changed to " +
+                  receiveChannel.readyState);
+    }
+  }</pre>
+
+<p>O método <code>handleReceiveChannelStatusChange()</code> recebe como parâmetro de entrada o evento que ocorreu; Este será um {{domxref("RTCDataChannelEvent")}}.</p>
+
+<h3 id="Enviando_mensagens">Enviando mensagens</h3>
+
+<p>Quando o usuário pressiona o botão "Enviar", o método sendMessage() que estabelecemos como o manipulador para o evento do botão {{event("click")}} é chamado. Esse método é bastante simples:</p>
+
+<pre class="brush: js">  function sendMessage() {
+    var message = messageInputBox.value;
+    sendChannel.send(message);
+
+    messageInputBox.value = "";
+    messageInputBox.focus();
+  }</pre>
+
+<p>Primeiro, o texto da mensagem é obtido dos atributos do elemento de <em>input </em>{{htmlattrxref("value", "input")}} . Isso é enviado para o ponto remoto, ligando para {{domxref("RTCDataChannel.send", "sendChannel.send()")}}. E está tudo aí! O resto deste método é apenas um pouco de açúcar para experiência do usuário - a caixa de entrada é esvaziada e re-focada para que o usuário comece imediatamente a digitar outra mensagem.</p>
+
+<h3 id="Recebendo_mensagens">Recebendo mensagens</h3>
+
+<p>Quando ocorre um evento de "mensagem" no canal remoto, nosso método <code>handleReceiveMessage()</code> é chamado como o manipulador de eventos.</p>
+
+<pre class="brush: js">  function handleReceiveMessage(event) {
+    var el = document.createElement("p");
+    var txtNode = document.createTextNode(event.data);
+
+    el.appendChild(txtNode);
+    receiveBox.appendChild(el);
+  }</pre>
+
+<p>Este método simplesmente executa alguns injeções básicas {{Glossary("DOM")}} ; cria um novo {{HTMLElement("p")}} (paragraph) elemento, então cria um novo nó {{domxref("Text")}} contendo o texto da mensagem, que é recebido na propriedade de dados do evento. Este nó de texto é anexado como um filho do novo elemento, que é então inserido no bloco <em>receiveBox</em>, fazendo com que ele desenhe na janela do navegador.</p>
+
+<h3 id="Desconectando_os_pares_(peers)">Desconectando os pares (peers)</h3>
+
+<p>Quando o usuário clica no botão "Desconectar", o método <code>disconnectPeers()</code> previamente configurado como o manipulador desse botão é chamado.</p>
+
+<pre class="brush: js">  function disconnectPeers() {
+
+    // Close the RTCDataChannels if they're open.
+
+    sendChannel.close();
+    receiveChannel.close();
+
+    // Close the RTCPeerConnections
+
+    localConnection.close();
+    remoteConnection.close();
+
+    sendChannel = null;
+    receiveChannel = null;
+    localConnection = null;
+    remoteConnection = null;
+
+    // Update user interface elements
+
+    connectButton.disabled = false;
+    disconnectButton.disabled = true;
+    sendButton.disabled = true;
+
+    messageInputBox.value = "";
+    messageInputBox.disabled = true;
+  }
+</pre>
+
+<p>Isso começa por fechar cada par {{domxref("RTCDataChannel")}}, então, de forma semelhante, cada um {{domxref("RTCPeerConnection")}}. Então, todas as referências salvas desses objetos são definidas como null para evitar a reutilização acidental, e a interface do usuário é atualizada para refletir o fato de que a conexão foi fechada.</p>
+
+<h2 id="Próximos_passos">Próximos passos</h2>
+
+<p>Você poderia <a href="https://mdn-samples.mozilla.org/s/webrtc-simple-datachannel">tentar este exemplo</a> e dar uma olhada no código fonte <a href="https://github.com/mdn/samples-server/tree/master/s/webrtc-simple-datachannel">webrtc-simple-datachannel</a>, disponível no GitHub.</p>