diff options
Diffstat (limited to 'files/ja/web/api/webrtc_api')
| -rw-r--r-- | files/ja/web/api/webrtc_api/connectivity/index.html | 138 | ||||
| -rw-r--r-- | files/ja/web/api/webrtc_api/index.html | 243 | ||||
| -rw-r--r-- | files/ja/web/api/webrtc_api/protocols/index.html | 56 |
3 files changed, 437 insertions, 0 deletions
diff --git a/files/ja/web/api/webrtc_api/connectivity/index.html b/files/ja/web/api/webrtc_api/connectivity/index.html new file mode 100644 index 0000000000..20b60fd87d --- /dev/null +++ b/files/ja/web/api/webrtc_api/connectivity/index.html @@ -0,0 +1,138 @@ +--- +title: WebRTC connectivity +slug: Web/API/WebRTC_API/Connectivity +translation_of: Web/API/WebRTC_API/Connectivity +--- +<div>{{WebRTCSidebar}}{{draft}}</div> + +<p><span class="seoSummary">WebRTC ではさまざまなプロトコルが相互作用してピア間の接続を確立し、データやメディアの転送を行いますが、この記事ではその仕組みを解説します。</span></p> + +<div class="note"> +<p><strong>Note:</strong> This page needs heavy rewriting for structural integrity and content completeness. Lots of info here is good but the organization is a mess since this is sort of a dumping ground right now.</p> +</div> + +<h2 id="シグナリング">シグナリング</h2> + +<p>残念なことに、WebRTC は中間に何らかのサーバーがなければ接続を作成できません。このサーバーを<strong>シグナルチャンネル</strong>、または<strong>シグナリングサービス</strong>と呼びます。接続を確立する前に情報を交換する伝達手段はどんなものでも構いません。Eメール、はがき、伝書鳩でも...決めるのはあなたです。</p> + +<p>交換する必要のある情報はオファーとアンサーと呼ばれ、その中身は下記で説明する {{Glossary("SDP")}} です。</p> + +<p>ピア A が接続を初期化する側とすると、ピア A がオファーを作成します。それから選択されたシグナルチャンネルを使ってピア B にオファーを送ります。ピア B はシグナルチャンネルからオファーを受け取ると、アンサーを作成します。それからピア B はピア A にシグナルチャンネルを使ってアンサーを送り返します。</p> + +<h3 id="Session_descriptions">Session descriptions</h3> + +<p>WebRTC 接続のエンドポイント設定は <strong>session description</strong> と呼ばれます。そこに含まれる情報は、送られるメディアの種類、形式、使用される転送プロトコル、エンドポイントの IP アドレスとポート、またその他メディア転送エンドポイントを記述するのに必要な情報です。この情報を <strong>Session Description Protocol</strong> ({{Glossary("SDP")}}) を使って交換し、保存します。SDP データ形式の詳細は {{RFC(2327)}} にあります。</p> + +<p>ユーザーが WebRTC コールを他のユーザーに開始するとき、<strong>オファー</strong>と呼ばれる特別な記述を作成します。コールする側がコールに必要な設定を提案し、そのすべての情報をオファーの記述に盛り込みます。受け取る側は<strong>アンサー</strong>を返します。アンサーは受け取る側が用意する記述です。このようにして、両デバイスがお互いにメディアデータの交換に必要な情報を共有します。この交換は Interactive Connectivity Establishment ({{Glossary("ICE")}}) を使って行われます。ICE とは二つのデバイスが Network Address Translation ({{Glossary("NAT")}}) によって隔てられていてもオファーとアンサーを交換するために媒介を利用できるようにするプロトコルです。</p> + +<p>各ピアは二つの記述を手に入れます。 <strong>local description</strong> が自分側の記述で、 <strong>remote description</strong> が相手側の記述です。</p> + +<p>オファー／アンサーの交換はコールを最初に確立する際に実行されますが、それだけでなくフォーマットや他の設定に変更が必要なときにも随時実行されます。コールの新規作成時でも既存の設定変更時でも、いずれにしてもオファーとアンサーを交換するために以下のような基本的なステップが実行されます。なお、ここでは ICE レイヤーは除外しています。</p> + +<ol> + <li>呼び出す側が {{domxref("navigator.mediaDevices.getUserMedia()")}} を通じてローカルメディアを取得する</li> + <li>呼び出す側が <code>RTCPeerConnection</code> を作成し、 {{domxref("RTCPeerConnection.addTrack()")}} を実行する。(<code>addStream</code> が非推奨であるため)</li> + <li>呼び出す側がオファーを作成するために {{domxref("RTCPeerConnection.createOffer()")}} を実行する</li> + <li>呼び出す側がオファーを <em>local description</em> (ローカル側の接続の記述) として設定するために {{domxref("RTCPeerConnection.setLocalDescription()")}} を実行する</li> + <li>呼び出す側は setLocalDescription() を実行した後、STUN サーバーに問い合わせて ICE 候補を生成する</li> + <li>呼び出す側がシグナリングサーバーを使ってオファーを届けたい相手に送る</li> + <li>受け取る側がオファーを受け取り、それを <em>remote description</em> (相手側の接続の記述) として記録するために {{domxref("RTCPeerConnection.setRemoteDescription()")}} を実行する</li> + <li>受け取る側がコールに必要なセットアップを行う。ローカルメディアを取得し、 {{domxref("RTCPeerConnection.addTrack()")}} を通じてメディアトラックをピア接続にアタッチする</li> + <li>受け取る側が {{domxref("RTCPeerConnection.createAnswer()")}} を実行することでアンサーを作成する</li> + <li>受け取る側が {{domxref("RTCPeerConnection.setLocalDescription()")}} に作成したアンサーを渡して実行し、アンサーを自身の local description としてセットする。この時点で受け取る側は両側の接続設定を知ることになる。</li> + <li>受け取る側がシグナリングサーバーを使ってアンサーを呼び出す側に送る</li> + <li>呼び出す側がアンサーを受け取る。</li> + <li>呼び出す側がアンサーを remote description として設定するために {{domxref("RTCPeerConnection.setRemoteDescription()")}} を実行する。これで呼び出す側も両者の設定を知ることになる。設定した通りにメディアが流れ始める。</li> +</ol> + +<h3 id="Pending_and_current_descriptions">Pending and current descriptions</h3> + +<p>Taking one step deeper into the process, we find that <code>localDescription</code> and <code>remoteDescription</code>, the properties which return these two descriptions, aren't as simple as they look. Because during renegotiation, an offer might be rejected because it proposes an incompatible format, it's necessary that each endpoint have the ability to propose a new format but not actually switch to it until it's accepted by the other peer. For that reason, WebRTC uses <em>pending</em> and <em>current</em> descriptions.</p> + +<p>The <strong>current description</strong> (which is returned by the {{domxref("RTCPeerConnection.currentLocalDescription")}} and {{domxref("RTCPeerConnection.currentRemoteDescription")}} properties) represents the description currently in actual use by the connection. This is the most recent connection that both sides have fully agreed to use.</p> + +<p>The <strong>pending description</strong> (returned by {{domxref("RTCPeerConnection.pendingLocalDescription")}} and {{domxref("RTCPeerConnection.pendingRemoteDescription")}}) indicates a description which is currently under consideration following a call to <code>setLocalDescription()</code> or <code>setRemoteDescription()</code>, respectively.</p> + +<p>When reading the description (returned by {{domxref("RTCPeerConnection.localDescription")}} and {{domxref("RTCPeerConnection.remoteDescription")}}), the returned value is the value of <code>pendingLocalDescription</code>/<code>pendingRemoteDescription</code> if there's a pending description (that is, the pending description isn't <code>null</code>); otherwise, the current description (<code>currentLocalDescription</code>/<code>currentRemoteDescription</code>) is returned.</p> + +<p>When changing the description by calling <code>setLocalDescription()</code> or <code>setRemoteDescription()</code>, the specified description is set as the pending description, and the WebRTC layer begins to evaluate whether or not it's acceptable. Once the proposed description has been agreed upon, the value of <code>currentLocalDescription</code> or <code>currentRemoteDescription</code> is changed to the pending description, and the pending description is set to null again, indicating that there isn't a pending description.</p> + +<div class="note"> +<p>The <code>pendingLocalDescription</code> contains not just the offer or answer under consideration, but any local ICE candidates which have already been gathered since the offer or answer was created. Similarly, <code>pendingRemoteDescription</code> includes any remote ICE candidates which have been provided by calls to {{domxref("RTCPeerConnection.addIceCandidate()")}}.</p> +</div> + +<p>See the individual articles on these properties and methods for more specifics, and <a href="/en-US/docs/Web/Media/Formats/WebRTC_codecs">Codecs used by WebRTC</a> for information about codecs supported by WebRTC and which are compatible with which browsers. The codecs guide also offers guidance to help you choose the best codecs for your needs.</p> + +<h2 id="ICE_candidates">ICE candidates</h2> + +<p>As well as exchanging information about the media (discussed above in Offer/Answer and SDP), peers must exchange information about the network connection. This is known as an <strong>ICE candidate</strong> and details the available methods the peer is able to communicate (directly or through a TURN server). Typically, each peer will propose its best candidates first, making their way down the line toward their worse candidates. Ideally, candidates are UDP (since it's faster, and media streams are able to recover from interruptions relatively easily), but the ICE standard does allow TCP candidates as well.</p> + +<div class="note"> +<p>Generally, ICE candidates using TCP are only going to be used when UDP is not available or is restricted in ways that make it not suitable for media streaming. Not all browsers support ICE over TCP, however.</p> +</div> + +<p>ICE allows candidates to represent connections over either {{Glossary("TCP")}} or {{Glossary("UDP")}}, with UDP generally being preferred (and being more widely supported). Each protocol supports a few types of candidate, with the candidate types defining how the data makes its way from peer to peer.</p> + +<h3 id="UDP_candidate_types">UDP candidate types</h3> + +<p>UDP candidates (candidates with their {{domxref("RTCIceCandidate.protocol", "protocol")}} set to <code>udp</code>) can be one of these types:</p> + +<dl> + <dt><code>host</code></dt> + <dd>A host candidate is one for which its {{domxref("RTCIceCandidate.ip", "ip")}} address is the actual, direct IP address of the remote peer.</dd> + <dt><code>prflx</code></dt> + <dd>A peer reflexive candidate is one whose IP address comes from a symmetric NAT between the two peers, usually as an additional candidate during trickle ICE (that is, additional candidate exchanges that occur after primary signaling but before the connection verification phase is finished).</dd> + <dt><code>srflx</code></dt> + <dd>A server reflexive candidate is generated by a STUN/TURN server; the connection's initiator requests a candidate from the STUN server, which forwards the request through the remote peer's NAT, which creates and returns a candidate whose IP address is local to the remote peer. The STUN server then replies to the initiator's request with a candidate whose IP address is unrelated to the remote peer.</dd> + <dt><code>relay</code></dt> + <dd>A relay candidate is generated just like a server reflexive candidate (<code>"srflx"</code>), but using {{Glossary("TURN")}} instead of {{Glossary("STUN")}}.</dd> +</dl> + +<h3 id="TCP_candidate_types">TCP candidate types</h3> + +<p>TCP candidates (that is, candidates whose {{domxref("RTCIceCandidate.protocol", "protocol")}} is <code>tcp</code>) can be of these types:</p> + +<dl> + <dt><code>active</code></dt> + <dd>The transport will try to open an outbound connection but won't receive incoming connection requests. This is the most common type, and the only one that most user agents will gather.</dd> + <dt><code>passive</code></dt> + <dd>The transport will receive incoming connection attempts but won't attempt a connection itself.</dd> + <dt><code>so</code></dt> + <dd>The transport will try to simultaneously open a connection with its peer.</dd> +</dl> + +<h3 id="Choosing_a_candidate_pair">Choosing a candidate pair</h3> + +<p>The ICE layer selects one of the two peers to serve as the <strong>controlling agent</strong>. This is the ICE agent which will make the final decision as to which candidate pair to use for the connection. The other peer is called the <strong>controlled agent</strong>. You can identify which one your end of the connection is by examining the value of {{domxref("RTCIceTransport.role", "RTCIceCandidate.transport.role")}}, although in general it doesn't matter which is which.</p> + +<p>The controlling agent not only takes responsibility for making the final decision as to which candidate pair to use, but also for signaling that selection to the controlled agent by using STUN and an updated offer, if necessary. The controlled agent just waits to be told which candidate pair to use.</p> + +<p>It's important to keep in mind that a single ICE session may result in the controlling agent choosing more than one candidate pair. Each time it does so and shares that information with the controlled agent, the two peers reconfigure their connection to use the new configuration described by the new candidate pair.</p> + +<p>Once the ICE session is complete, the configuration that's currently in effect is the final one, unless an ICE reset occurs.</p> + +<p>At the end of each generation of candidates, an end-of-candidates notification is sent in the form of an {{domxref("RTCIceCandidate")}} whose {{domxref("RTCIceCandidate.candidate", "candidate")}} property is an empty string. This candidate should still be added to the connection using {{domxref("RTCPeerConnection.addIceCandidate", "addIceCandidate()")}} method, as usual, in order to deliver that notification to the remote peer.</p> + +<p>When there are no more candidates at all to be expected during the current negotiation exchange, an end-of-candidates notification is sent by delivering a {{domxref("RTCIceCandidate")}} whose {{domxref("RTCIceCandidate.candidate", "candidate")}} property is <code>null</code>. This message does <em>not</em> need to be sent to the remote peer. It's a legacy notification of a state which can be detected instead by watching for the {{domxref("RTCPeerConnection.iceGatheringState", "iceGatheringState")}} to change to <code>complete</code>, by watching for the {{domxref("RTCPeerConnection.icegatheringstatechange_event", "icegatheringstatechange")}} event.</p> + +<h2 id="When_things_go_wrong">When things go wrong</h2> + +<p>During negotiation, there will be times when things just don't work out. For example, when renegotiating a connection—for example, to adapt to changing hardware or network configurations—it's possible that negotiation could reach a dead end, or some form of error might occur that prevents negotiation at all. There may be permissions issues or other problems as well, for that matter.</p> + +<h3 id="ICE_rollbacks">ICE rollbacks</h3> + +<p>When renegotiating a connection that's already active and a situation arises in which the negotiation fails, you don't really want to kill the already-running call. After all, you were most likely just trying to upgrade or downgrade the connection, or to otherwise make adaptations to an ongoing session. Aborting the call would be an excessive reaction in that situation.</p> + +<p>Instead, you can initiate an <strong>ICE rollback</strong>. A rollback restores the SDP offer (and the connection configuration by extension) to the configuration it had the last time the connection's {{domxref("RTCPeerConnection.signalingState", "signalingState")}} was <code>stable</code>.</p> + +<p>To programmatically initiate a rollback, send a description whose {{domxref("RTCSessionDescription.type", "type")}} is <code>rollback</code>. Any other properties in the description object are ignored.</p> + +<p>In addition, the ICE agent will automatically initiate a rollback when a peer that had previously created an offer receives an offer from the remote peer. In other words, if the local peer is in the state <code>have-local-offer</code>, indicating that the local peer had previously <em>sent</em> an offer, calling <code>setRemoteDescription()</code> with a <em>received</em> offer triggers rollback so that the negotiation switches from the remote peer being the caller to the local peer being the caller.</p> + +<h3 id="ICE_restarts">ICE restarts</h3> + +<p>For now, see {{SectionOnPage("/en-US/docs/Web/API/WebRTC_API/Session_lifetime", "ICE restart")}}.</p> + +<h2 id="The_entire_exchange_in_a_complicated_diagram">The entire exchange in a complicated diagram</h2> + +<p><a href="https://hacks.mozilla.org/wp-content/uploads/2013/07/webrtc-complete-diagram.png"><img alt="A complete architectural diagram showing the whole WebRTC process." src="https://mdn.mozillademos.org/files/6119/webrtc-complete-diagram.png" style="display: block; height: 559px; margin: 0px auto; width: 641px;"></a></p> diff --git a/files/ja/web/api/webrtc_api/index.html b/files/ja/web/api/webrtc_api/index.html new file mode 100644 index 0000000000..4b03a5ed78 --- /dev/null +++ b/files/ja/web/api/webrtc_api/index.html @@ -0,0 +1,243 @@ +--- +title: WebRTC API +slug: Web/API/WebRTC_API +tags: + - API + - Audio + - Conferencing + - Landing + - Media + - Networking + - Video + - WebRTC + - WebRTC API + - streaming + - ストリーミング + - ネットワーク +translation_of: Web/API/WebRTC_API +--- +<div>{{WebRTCSidebar}}</div> + +<p><span class="seoSummary"><strong>WebRTC</strong> (Web Real-Time Communications、ウェブリアルタイムコミュニケーション) は、ウェブアプリケーションやウェブサイトにて、仲介を必要とせずにブラウザー間で直接、任意のデータの交換や、キャプチャしたオーディオ／ビデオストリームの送受信を可能にする技術です。 WebRTC に関する一連の標準規格は、ユーザーがプラグインやサードパーティ製ソフトウェアをインストールすることなく、ピア・ツー・ピアにて、データ共有や遠隔会議を実現することを可能にします。</span></p> + +<p>WebRTC は、相互に関連したいくつかの API とプロトコルで構成されており、これらが連携してこれを実現しています。ここで紹介するドキュメントでは、WebRTC の基礎知識、データ接続とメディア接続、両方の設定方法と、使用方法などを理解するのに役立ちます。</p> + +<h2 id="Interoperability" name="Interoperability">相互運用性</h2> + +<p>WebRTC の実装はまだ進化しており、ブラウザごとに<a href="/en-US/docs/Web/Media/Formats/WebRTC_codecs">コーデック</a>や WebRTC 機能のサポートレベルが異なるため、コードを書き始める前に Google が提供する <a href="https://github.com/webrtcHacks/adapter">Adapter.js</a> ライブラリを利用することを強く検討する必要があります。</p> + +<p>Adapter.js はシム ({{Glossary("Shim")}}) やポリフィル ({{Glossary("polyfill")}}) を使用して、サポートしている環境によって異なる WebRTC 実装の違いを滑らかにします。また、接頭辞やその他の名前の違いも Adapter.js が処理することで、WebRTC の開発プロセス全体がより簡単になり、より広範な互換性のある結果が得られるようになります。このライブラリは <a href="https://www.npmjs.com/package/webrtc-adapter">NPM パッケージ</a>としても提供されています。</p> + +<p>Adapter.js の詳細については、<a href="/en-US/docs/Web/API/WebRTC_API/adapter.js">WebRTC adapter.js を使用した互換性の向上</a>を参照してください。</p> + +<h2 id="WebRTC_concepts_and_usage" name="WebRTC_concepts_and_usage">WebRTC の概念と使い方</h2> + +<p>WebRTC は複数の目的に対応しています。<a href="/ja/docs/Web/API/Media_Streams_API">Media Capture と Streams API</a> と一緒に使用することで、音声・ビデオ会議、ファイル交換、画面共有、ID 管理、{{Glossary("DTMF")}} (タッチトーンダイヤル信号) の送信サポートを含む旧来の電話システムとのインターフェースなど、強力なマルチメディア機能を Web に提供します。ピア間の接続は、特別なドライバやプラグインを必要とせずに行うことができ、多くの場合、中間サーバーを介さずに行うことができます。</p> + +<p>2つのピア間の接続は {{DOMxRef("RTCPeerConnection")}} インターフェースで表現されます。接続が確立され、<code>RTCPeerConnection</code> を使用して開かれると、メディアストリーム(({{DOMxRef("MediaStream")}}s))やデータチャンネル ({{DOMxRef("RTCDataChannel")}}s) を接続に追加することができます。</p> + +<p>メディアストリームは、メディア情報の任意の数のトラックで構成することができます。トラックは、{{DOMxRef("MediaStreamTrack")}} インターフェイスに基づいたオブジェクトで表され、オーディオ、ビデオ、テキスト（字幕やチャプター名など）を含むメディアデータのいくつかのタイプのうちの1つを含むことができます。ほとんどのストリームは少なくとも 1 つのオーディオトラックとビデオトラックで構成されており、ライブメディアや保存されたメディア情報（ストリーミングされた動画など）の送受信に使用することができます。</p> + +<p>また、2 つのピア間の接続を使用して、{{DOMxRef("RTCDataChannel")}} インターフェイスを使用して任意のバイナリデータを交換することもできます。これは、バックチャンネル情報、メタデータ交換、ゲームステータスパケット、ファイル転送、あるいはデータ転送のためのプライマリチャンネルとして使用することができます。</p> + +<p><em><strong>より多くの詳細と関連するガイドやチュートリアルへのリンクが必要ですね…。</strong></em></p> + +<h2 id="WebRTC_reference" name="WebRTC_reference">WebRTC リファレンス</h2> + +<p>WebRTC は、様々なタスクを達成するために連携して動作する複数のインターフェースを提供しているため、以下のリストのインターフェースをカテゴリ別に分けています。アルファベット順のリストはサイドバーをご覧ください。</p> + +<h3 id="Connection_setup_and_management" name="Connection_setup_and_management">接続の設定と管理</h3> + +<p>以下のインターフェイス、辞書、型は、WebRTC 接続のセットアップ、オープン、管理に使用します。これには、ピアメディア接続、データチャネルおよび、それぞれのピアが双方向メディア接続のために最適な設定を選択する機能に関する情報をやりとりするためのインターフェースが含まれています。</p> + +<h4 id="Interfaces" name="Interfaces">インターフェイス</h4> + +<dl> + <dt>{{DOMxRef("RTCPeerConnection")}}</dt> + <dd>ローカルコンピュータとリモートピア間の WebRTC 接続を表します。これは、2つのピア間のデータの効率的なストリーミングを処理するために使用されます。</dd> + <dt>{{DOMxRef("RTCDataChannel")}}</dt> + <dd>接続の2つのピア間の双方向データチャネルを表します。</dd> + <dt>{{DOMxRef("RTCDataChannelEvent")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} に {{DOMxRef("RTCDataChannel")}} をアタッチしている間に発生するイベントを表します。このインタフェースで送信されるイベントは、データチャネル {{event("datachannel")}} のみです。</dd> + <dt>{{DOMxRef("RTCSessionDescription")}}</dt> + <dd>セッションのパラメータを表します。各 <code>RTCSessionDescription</code> は、オファー/アンサーネゴシエーションプロセスの、どの部分を記述するかを示す記述型 ({{DOMxRef("RTCSessionDescription.type", "type")}}) と、セッションの {{Glossary("SDP")}} 記述子で構成されます。</dd> + <dt>{{DOMxRef("RTCStatsReport")}}</dt> + <dd>接続または接続上の個々のトラックの統計情報の詳細を提供します。{{DOMxRef("RTCPeerConnection.getStats()")}} を呼び出すと報告を取得できます。 WebRTC 統計情報の使用に関する詳細は、 <a href="/ja/docs/Web/API/WebRTC_Statistics_API">WebRTC 統計 API</a> を参照してください。</dd> + <dt>{{DOMxRef("RTCIceCandidate")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} を確立するための {{Glossary("ICE")}}(インタラクティブ接続確立) サーバの候補を表します。</dd> + <dt>{{DOMxRef("RTCIceTransport")}}</dt> + <dd>{{Glossary("ICE")}} トランスポートに関する情報を表します。</dd> + <dt>{{DOMxRef("RTCPeerConnectionIceEvent")}}</dt> + <dd>ターゲットとの {{Glossary("ICE")}} 候補(通常は {{DOMxRef("RTCPeerConnection")}} )に関連して発生するイベントを表します。このタイプのイベントは {{event("icecandidate")}} 1つだけです。</dd> + <dt>{{DOMxRef("RTCRtpSender")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} 上の {{DOMxRef("MediaStreamTrack")}} のデータのエンコードと送信を管理します。</dd> + <dt>{{DOMxRef("RTCRtpReceiver")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} 上の {{DOMxRef("MediaStreamTrack")}} のデータの受信とデコードを管理します。</dd> + <dt>{{DOMxRef("RTCTrackEvent")}}</dt> + <dd>このインターフェイスは {{domxref("RTCPeerConnection.track_event", "track")}} イベントを表すもので、 {{DOMxRef("RTCRtpReceiver")}} オブジェクトが {{DOMxRef("RTCPeerConnection")}} オブジェクトに追加されたことを示すトラックイベントを表現するために使用されるインターフェースで、新しい着信 (incoming) {{DOMxRef("MediaStreamTrack")}} が生成され、<code>RTCPeerConnection</code> に追加されたことを示します。</dd> + <dt>{{DOMxRef("RTCSctpTransport")}}</dt> + <dd>Stream Control Transmission Protocol (<strong>{{Glossary("SCTP")}}</strong>) トランスポートを説明する情報を提供し、 {{DOMxRef("RTCPeerConnection")}} のすべての<a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection" title="The RTCPeerConnection interface represents a WebRTC connection between the local computer and a remote peer. It provides methods to connect to a remote peer, maintain and monitor the connection, and close the connection once it's no longer needed."><code>RTCPeerConnection</code></a> のデータチャネルの SCTP パケットが送受信される Datagram Transport Layer Security (<strong>{{Glossary("DTLS")}}</strong>) トランスポートにアクセスする方法も提供します。</dd> + <dt> + <h4 id="Dictionaries" name="Dictionaries">辞書</h4> + </dt> + <dt>{{DOMxRef("RTCConfiguration")}}</dt> + <dd><a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection" title="The RTCPeerConnection interface represents a WebRTC connection between the local computer and a remote peer. It provides methods to connect to a remote peer, maintain and monitor the connection, and close the connection once it's no longer needed."><code>RTCPeerConnection</code></a> の {{DOMxRef("RTCPeerConnection")}} の構成オプションを提供するために使用します。</dd> + <dt>{{DOMxRef("RTCIceServer")}}</dt> + <dd>({{Glossary("STUN")}} や {{Glossary("TURN")}} サーバのような) 単一の {{Glossary("ICE")}} サーバーを定義します。</dd> + <dt>{{DOMxRef("RTCRtpContributingSource")}}</dt> + <dd>ソース貢献されているパケットが再生された直近の時刻を含む、特定の貢献ソース (contributing source; CSRC)に関する情報が含まれています。</dd> + <dt> + <h4 id="Types" name="Types">型</h4> + </dt> + <dt>{{DOMxRef("RTCSctpTransportState")}}</dt> + <dd>{{DOMxRef("RTCSctpTransport")}} インスタンスの状態を示します。</dd> + <dt>{{DOMxRef("RTCSessionDescriptionCallback")}}</dt> + <dd><code>RTCSessionDescriptionCallback</code> は、オファーやアンサーの作成を要求する際に {{DOMxRef("RTCPeerConnection")}} オブジェクトに渡されます。</dd> +</dl> + +<h3 id="Identity_and_security" name="Identity_and_security">アイデンティティとセキュリティ</h3> + +<p>これらの API は、セキュリティとアイデンティティを管理し、ユーザーの接続を認証するために使われます。</p> + +<dl> + <dt>{{DOMxRef("RTCIdentityProvider")}}</dt> + <dd>ユーザー・エージェントが ID アサーションの生成または検証を要求できるようにします。</dd> + <dt>{{DOMxRef("RTCIdentityAssertion")}}</dt> + <dd>現在の接続のリモートピアの ID を表します。まだピアが設定されておらず、検証されていない場合、このインターフェイスは <code>null</code> を返します。一度設定すると変更することはできません。</dd> + <dt>{{DOMxRef("RTCIdentityProviderRegistrar")}}</dt> + <dd>ID プロバイダ(idP)を登録します。</dd> + <dt>{{DOMxRef("RTCIdentityEvent")}}</dt> + <dd>ID プロバイダ (idP) によって生成された ID アサーションを表します。これは通常、{{DOMxRef("RTCPeerConnection")}} に対して行われます。このタイプで送信されるイベントは {{event("identityresult")}} のみです。</dd> + <dt>{{DOMxRef("RTCIdentityErrorEvent")}}</dt> + <dd>ID プロバイダ (idP) に関連するエラーを表します。これは通常、 {{DOMxRef("RTCPeerConnection")}} に対して行われます。このタイプでは、 {{event("idpassertionerror")}} と {{event("idpvalidationerror")}} の 2 つのイベントが送信されます。</dd> + <dt>{{DOMxRef("RTCCertificate")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} が認証に使用する証明書を表します。</dd> +</dl> + +<h3 id="Telephony" name="Telephony">電話通信</h3> + +<p>以下のインターフェイスは、公衆電話網 (public-switched telephone networks; PTSNs) と通信するために利用します。</p> + +<dl> + <dt>{{DOMxRef("RTCDTMFSender")}}</dt> + <dd>{{DOMxRef("RTCPeerConnection")}} のデュアルトーン多周波 (DTMF) シグナリングのエンコーディングと送信を管理します。</dd> + <dt>{{DOMxRef("RTCDTMFToneChangeEvent")}}</dt> + <dd>DTMF トーンが開始または終了したことを示すために{{domxref("RTCDTMFSender.tonechange_event", "tonechange")}} イベントで使用されます。このイベントは（別段の記載がある場合を除き）泡立たず (bubble) 、（別段の記載がある場合を除き）キャンセルできません。</dd> +</dl> + +<h2 id="Guides" name="Guides">ガイド</h2> + +<dl> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Protocols">WebRTC プロトコル入門</a></dt> + <dd>この記事では、WebRTC API の基礎となっているプロトコルについて説明しています。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Connectivity">WebRTC 接続</a></dt> + <dd>WebRTC 接続がどのように動くかを説明するガイド。どのように様々なプロトコルとインターフェースが協調して用いられることで強力なコミュニケーションアプリを構築することができるかについて説明しています。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Session_lifetime">WebRTC セッションのライフタイム</a></dt> + <dd>WebRTCは任意のデータ、音声、映像またはそれらの組み合わせをやりとりするピアツーピア通信をブラウザアプリケーション上に構築することができます。この記事では、接続の確立から不要となり閉じられるまでのWebRTCのライフタイムについて見ていきます。</dd> +</dl> + +<dl> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Perfect_negotiation">接続の確立: 完全なネゴシエーションパターン</a></dt> + <dd><strong>完全なネゴシエーション</strong>はシグナリングプロセスが従うべき推奨されるデザインパターンです。二者を区別するためにたくさんのコーディングを必要とせずに、双方をオファー側とアンサー側のどちらにもなれることを可能にするネゴシエーションにおける透過性を提供します。</dd> +</dl> + +<dl> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Signaling_and_video_calling">シグナリングと双方向ビデオ通話</a></dt> + <dd>以前の例で作成したウェブソケットベースのチャットシステムに参加者同士のビデオ通話機能を追加するチュートリアルと例。チャットサーバのウェブソケット接続は WebRTC のシグナリングとして用いられます。</dd> + <dt><a href="/ja/docs/Web/Media/Formats/WebRTC_codecs">WebRTC で用いられるコーデック</a></dt> + <dd>WebRTC を用いる上でブラウザがサポートしているべきコーデックと様々なポピュラーなブラウザでサポートされている追加的なコーデックについてのガイド。必要に応じたベストなコーデックの選び方についてのガイドも含みます。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Using_data_channels">WebRTC データチャネルを使う</a></dt> + <dd>このガイドでは、ピア接続と関連する {{DOMxRef("RTCDataChannel")}} を使用して、2 つのピア間で任意のデータを交換する方法について説明します。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Using_DTMF">DTMFをWebRTCと共に用いる</a></dt> + <dd>{{DOMxRef("RTCDTMFSender")}}インターフェースを用いたDTMFトーン送信サポートを含む、旧式の電話システムとのゲートウェイとやりとりを行うためのWebRTCサポートについて、このガイドでは、その方法を説明します。</dd> +</dl> + +<h2 id="Tutorials" name="Tutorials">チュートリアル</h2> + +<dl> + <dt><a href="/ja/docs/Web/API/WebRTC_API/adapter.js">Improving compatibility using WebRTC adapter.js</a></dt> + <dd>WebRTC 組織は、異なるブラウザの WebRTC 実装における互換性の問題を回避するため <a href="https://github.com/webrtc/adapter/">adapter.js</a> を提供しています。このアダプタは JavaScript のはシム ({{Glossary("Shim")}}) で、あなたのコードを仕様に合わせて記述することで、WebRTC をサポートしているすべてのブラウザで「ただ動く (just work) 」ようにしてくれます。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Taking_still_photos">WebRTC で静止画を撮る</a></dt> + <dd>この記事では、WebRTC に対応したパソコンや携帯電話でWebRTCを使ってカメラにアクセスして写真を撮る方法を紹介しています。</dd> + <dt><a href="/ja/docs/Web/API/WebRTC_API/Simple_RTCDataChannel_sample">シンプルな RTCDataChannel のサンプル</a></dt> + <dd>{{DOMxRef("RTCDataChannel")}} インターフェイスは、2つのピア間で任意のデータを送受信するためのチャネルを開くことができる機能です。このAPIは意図的に <a href="/ja/docs/Web/API/WebSocket_API">WebSocket API</a> に似せているので、それぞれに同じプログラミングモデルを使用することができます。</dd> +</dl> + +<h2 id="Resource" name="Resource">リソース</h2> + +<h3 id="Protocols" name="Protocols">プロトコル</h3> + +<h4 id="WebRTC-proper_protocols" name="WebRTC-proper_protocols">WebRTC-proper プロトコル</h4> + +<ul> + <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/"><cite>WebRTC のためのアプリケーションレイヤプロトコルネゴシエーション</cite></a></li> + <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio/"><cite>WebRTC オーディオコーデックと処理要件</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>ウェブリアルタイム通信 (WebRTC): メディアトランスポートとRTPの利用</cite></a></li> + <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/"><cite>WebRTC セキュリティアーキテクチャ</cite></a></li> + <li><a href="http://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/"><cite>RTCWEB用トランスポート</cite></a></li> +</ul> + +<h4 id="Related_supporting_protocols" name="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><br> + </li> +</ul> + +<h4 id="WebRTC_statistics" name="WebRTC_statistics">WebRTC 統計情報</h4> + +<ul> + <li><a href="/ja/docs/Web/API/WebRTC_Statistics_API">WebRTC 統計 API</a></li> +</ul> + +<h2 id="Specifications" name="Specifications">仕様書</h2> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">仕様書</th> + <th scope="col">状態</th> + <th scope="col">備考</th> + </tr> + </thead> + <tbody> + <tr> + <td>{{SpecName('WebRTC 1.0')}}</td> + <td>{{Spec2('WebRTC 1.0')}}</td> + <td>WebRTC API の初期定義。</td> + </tr> + <tr> + <td>{{SpecName('Media Capture')}}</td> + <td>{{Spec2('Media Capture')}}</td> + <td>メディアコンテンツのストリームを伝達するオブジェクトの初期定義。</td> + </tr> + <tr> + <td>{{SpecName('Media Capture DOM Elements')}}</td> + <td>{{Spec2('Media Capture DOM Elements')}}</td> + <td>DOM 要素からコンテンツのストリームを取得する方法の初期定義。</td> + </tr> + </tbody> +</table> + +<p>これらの API 仕様に加えて、Web RTC は <a href="#Protocols">リソース</a> に示されているさまざまなプロトコルを用いる必要があります。</p> + +<h2 id="See_also" name="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/">SocketPeer を使った WebRTC Fog の中のピアリング</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: 複数のライブビデオストリーム＋インタラクティブグラフィックスを使ったWebアプリの構築</a></li> +</ul> diff --git a/files/ja/web/api/webrtc_api/protocols/index.html b/files/ja/web/api/webrtc_api/protocols/index.html new file mode 100644 index 0000000000..f0c9931852 --- /dev/null +++ b/files/ja/web/api/webrtc_api/protocols/index.html @@ -0,0 +1,56 @@ +--- +title: WebRTC プロトコル入門 +slug: Web/API/WebRTC_API/Protocols +tags: + - API + - Audio + - Beginner + - Draft + - Guide + - ICE + - Media + - NAT + - SDP + - STUN + - TURN + - Video + - WebRTC + - WebRTC API + - ガイド + - メディア + - 初心者 +translation_of: Web/API/WebRTC_API/Protocols +--- +<div>{{WebRTCSidebar}}{{draft}}</div> + +<p>この記事では、 WebRTC API の基礎となっているプロトコルについて説明します。</p> + +<h2 id="ICE">ICE</h2> + +<p><a href="http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment">Interactive Connectivity Establishment (ICE)</a> は、ウェブブラウザーをピアと接続することを可能にするフレームワークです。さまざまな理由から、ピア A からピア B に直接接続することはできません。ファイアウォールをバイパスする必要があるからです。ファイアウォールは直接接続を開くことを妨害したり、端末がパブリック IP アドレスを持たない多くの場合にはユニークなアドレスを与えたり、ルーターがピアとの直接接続を許さない場合にはサーバー経由でデータをリレーしたりします。以下で説明するように、 ICE は STUN や TURN サーバーを使用してこれを解決しています。</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> (頭字語中に頭字語が含まれている) は、パブリックアドレスを発見し、ピアとの直接接続を妨害するルーターの制限を特定するためのプロトコルです。</p> + +<p>クライアントがインターネット上の STUN サーバーにリクエストを送信すると、サーバーは、クライアントのパブリックアドレスと、ルーターの NAT 内部にアクセス可能かどうかを答えます。</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> は、端末にパブリック IP アドレスを割り当てるために使われます。ルーターはパブリック IP アドレスを持ち、ルーターに接続されたすべての端末はプライベート IP アドレスを持ちます。リクエストが送られると、端末のプライベート IP から、特定のポートを持つルーターのパブリック IP へ変換されます。こうすることで、各端末にユニークな IP アドレスを割り当てずともインターネット上で発見することができるようになります。</p> + +<p>ルーターによっては、ネットワーク上の端末に接続できる相手に制限をかけている場合があります。つまり、 STUN サーバーが発見できるパブリック IP アドレスを持っていたとしても、すべての相手が接続を張れるわけではないということです。このような状況では、TURN を使う必要があります。(訳注: 原文では「TURN を turn on する必要がある」と書かれている。)</p> + +<h2 id="TURN">TURN</h2> + +<p>NAT を使用するルーターの一部は、‘Symmetric NAT’ と呼ばれる制限をかけています。その場合、ルーターは過去に接続したことのあるピアから来る接続しか受け入れることができません。</p> + +<p><a href="http://en.wikipedia.org/wiki/TURN">Traversal Using Relays around NAT (TURN)</a> サーバを使って接続を張り、すべての通信をこのサーバを通して行うことで'Symmetric NAT'制限を回避できます。TURNサーバを使って接続し、すべての相手にはこのサーバにパケットを送信させることでそれらが転送されてきます。明らかにオーバヘッドが生じますので、他の選択肢がない場合にのみ使うべきです。</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> とは、解像度、フォーマット、コーデック、暗号化などのマルチメディアコンテンツを指定するための標準です。これにより、データが転送された際に双方が理解できるようになります。本来、これらはメディアコンテンツそのものではなくそのコンテンツを指定するメタデータです。</p> |