参考: 翻訳
Initial Author of this Specification was Ian Hickson, Google Inc., with
the following copyright statement:
© Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera
Software ASA. You are granted a license to use, reproduce and create
derivative works of this document. All subsequent changes since 26 July
2011 done by the W3C WebRTC Working Group are under the following
Copyright:
Copyright © 2011-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本文書は、ECMAScript APIのセットをWebIDLで定義し、メディアや汎用アプリケーションデータを、適切なリアルタイムプロトコルを実装する他のブラウザやデバイスへ送受信できるようにします。本仕様は、IETF RTCWEBグループによるプロトコル仕様およびローカルメディアデバイスへのアクセスAPI仕様と連携して開発されています。
このセクションは、公開時点での文書のステータスを説明しています。現在のW3C公開文書および本技術レポートの最新版は W3C技術レポート一覧 https://www.w3.org/TR/ にてご覧いただけます。
本書には候補修正が含まれています。
関連するテストスイートは、 勧告として初めて公開された時点でAPIの実装レポート作成に使用されました。そのテストスイートはその後、提案および候補修正を統合するよう更新され、これら修正の実装状況に焦点を当てた最新の実装レポートが作成されました。二重実装された機能は提案修正として選定され、本勧告バージョンに完全に統合されています。
本文書はWeb Real-Time Communicationsワーキンググループによって 勧告プロセスに基づき勧告として公開されました。 候補修正を含み、前回の勧告以降、重要な変更や新機能が追加されています。
W3Cは本仕様のWeb標準としての広範な展開を推奨します。
W3C勧告は、十分な合意形成の後に W3Cおよびそのメンバーによって承認され、 ワーキンググループのメンバーによる ロイヤルティフリーライセンス のコミットメントが伴います。 今後の勧告更新で 新機能 が組み込まれる可能性があります。
候補追加箇所は文書内で明示されています。
候補修正箇所は文書内で明示されています。
本文書は W3C 特許ポリシー のもとで活動するグループによって作成されました。 W3Cは 関連する特許開示の公開リスト を管理しており、そのページには特許開示方法も記載されています。個人が本仕様に関して 必須クレーム を含む特許について認識している場合は、 W3C特許ポリシー第6節 に従って情報開示を行う必要があります。
本文書は 2023年11月3日 W3Cプロセス文書 に準拠しています。
このセクションは規範的ではありません。
本仕様で扱うHTMLにおけるピアツーピア通信およびビデオ会議には、いくつかの側面があります:
これらの機能に使用されるAPIを本文書で定義します。本仕様は、IETF RTCWEBグループが策定するプロトコル仕様や、WebRTCワーキンググループが策定するローカルメディアデバイスへのアクセスのAPI仕様 [GETUSERMEDIA] と連携して開発されています。システムの概要は [RFC8825] および [RFC8826] に記載されています。
規範的でないと記載されたセクションだけでなく、本仕様内のすべての著作ガイドライン、図、例、注記も規範的ではありません。それ以外の本仕様の内容は規範的です。
本文書における MAY、MUST、MUST NOT、SHOULD というキーワードは、BCP 14 [RFC2119] [RFC8174] に記載された通りに解釈されます。これらは、すべて大文字で表記されている場合のみ、ここで示すように解釈されます。
本仕様は、含まれるインターフェイスを実装する単一製品、すなわち ユーザーエージェント に適用される適合基準を定義します。
アルゴリズムや特定の手順として表現された適合要件は、最終結果が等価である限り、どのような方法で実装しても構いません。(特に、本仕様で定義されているアルゴリズムは理解しやすくするためであり、性能を考慮したものではありません。)
本仕様で定義するAPIをECMAScriptで実装する場合、MUST Web IDL仕様 [WEBIDL] で定義されるECMAScriptバインディングに従って実装しなければなりません。本仕様はWeb IDL仕様とその用語を使用しています。
コールバックとしてイベントハンドラ用に使われる EventHandler インターフェイスは [HTML] で定義されています。
queue a task や networking task source の概念は [HTML] で定義されています。
fire an event の概念は [DOM] で定義されています。
event、event handlers、event handler event types という用語は [HTML] で定義されています。
Performance.timeOrigin および Performance.now() は [hr-time] で定義されています。
シリアライズ可能オブジェクト、serialization steps、deserialization steps という用語は [HTML] で定義されています。
MediaStream、
MediaStreamTrack、
MediaStreamConstraints という用語は [GETUSERMEDIA] で定義されています。なお、MediaStream は本書の 9.2
MediaStream で拡張されており、MediaStreamTrack は 9.3
MediaStreamTrack で拡張されています。
Blob という用語は [FILEAPI]
で定義されています。
メディア記述 という用語は [RFC4566] で定義されています。
メディアトランスポート という用語は [RFC7656] で定義されています。
世代 という用語は [RFC8838] の Section 2 で定義されています。
統計オブジェクト、監視オブジェクト という用語は [WEBRTC-STATS] で定義されています。
例外について言及する場合、throw および created という用語は [WEBIDL] で定義されています。
コールバック VoidFunction は
[WEBIDL] で定義されています。
"throw" という用語は [INFRA] で規定されている通りに使われます:現在の処理手順を終了します。
Promiseに関連する fulfilled、 rejected、resolved、および settled という用語は [ECMASCRIPT-6.0] で定義されています。
AlgorithmIdentifier は [WebCryptoAPI] で定義されています。
一般的なJavascript APIの原則が適用されます。これは run-to-completion の原則や、[API-DESIGN-PRINCIPLES]
で定義されるデータレースなしの原則を含みます。つまり、タスク実行中は外部イベントがJavascriptアプリケーションから見える状態に影響しません。例えば、データチャネルで "send"
を呼んだ際にバッファされたデータ量はJavascript実行中に増加し、パケット送信による減少はタスクチェックポイント後に見えるようになります。
ユーザーエージェントは、アプリケーションへ提示する値が一貫性を持つよう責任を持ちます。例えば
getContributingSources()(同期関数)が返す値は、すべて同時に測定されたソースであることが保証されます。
このセクションは規範的ではありません。
RTCPeerConnection
インスタンスは、アプリケーションが他の
RTCPeerConnection
インスタンス(別のブラウザや必要なプロトコルを実装している他のエンドポイント)と
ピアツーピア通信を確立することを可能にします。通信は、シグナリングチャネル(制御メッセージの交換、シグナリングプロトコルと呼ばれる)を介して調整されます。
シグナリングチャネルは何らかの方法で提供されますが、通常はサーバーを介したページ内スクリプトによって提供されます。例えば、
WebSocket や
XMLHttpRequest
などです。
RTCConfiguration は、
RTCPeerConnection を介して確立または再確立される
ピアツーピア通信の構成方法を指定するためのパラメータセットを定義します。
WebIDLdictionary RTCConfiguration {
sequence<RTCIceServer> iceServers = [];
RTCIceTransportPolicy iceTransportPolicy = "all";
RTCBundlePolicy bundlePolicy = "balanced";
RTCRtcpMuxPolicy rtcpMuxPolicy = "require";
sequence<RTCCertificate> certificates = [];
[EnforceRange] octet iceCandidatePoolSize = 0;
};
RTCConfiguration のメンバー
iceServers 型 sequence<RTCIceServer>,
デフォルト値は []。
ICEが利用可能なサーバー(STUNやTURNサーバーなど)を記述するオブジェクトの配列です。 ICEサーバーの数が実装定義の制限を超えた場合、制限を超えたICEサーバーは無視されます。この実装定義の制限は 必須で少なくとも32でなければなりません。
iceTransportPolicy 型
RTCIceTransportPolicy,
デフォルト値は "all"。
ICEエージェント が 使用できる候補を示します。
bundlePolicy 型 RTCBundlePolicy,
デフォルト値は
"balanced"。
ICE候補を収集する際に使用する メディアバンドルポリシー を示します。
rtcpMuxPolicy 型 RTCRtcpMuxPolicy,
デフォルト値は
"require"。
ICE候補を収集する際に使用する rtcp-muxポリシー を示します。
certificates 型 sequence<RTCCertificate>,
デフォルト値は []。
RTCPeerConnection
が認証に使用する証明書セットです。
このパラメータの有効な値は、
generateCertificate()
関数の呼び出しによって作成されます。
いずれのDTLS接続も1つの証明書のみを使用しますが、この属性によって異なるアルゴリズムをサポートする複数の証明書を指定できます。
実際に使用される証明書はDTLSハンドシェイクによって選択され、許可された証明書が確立されます。
RTCPeerConnection の実装が
どの証明書を使用するか選択しますが、証明書の選択方法はこの仕様の範囲外です。
既存の実装では最初の証明書のみが利用され、他の証明書は無視されます。
この値が存在しない場合、各
RTCPeerConnection
インスタンスごとにデフォルトの証明書セットが生成されます。
このオプションによりアプリケーションはキーの継続性を確立できます。
RTCCertificate は
[INDEXEDDB] に保存して再利用できます。保存と再利用により、
キー生成コストも回避できます。
この構成オプションの値は初期選択後に変更できません。
iceCandidatePoolSize 型
octet, デフォルト値は
0
[RFC9429] (セクション 3.5.4. および セクション 4.1.1.) で定義されるプリフェッチされたICEプールのサイズです。
RTCIceServer 辞書は、
ICEエージェント がピアとの接続を確立するために利用できる
STUNおよびTURNサーバーを記述するために使用されます。
WebIDLdictionary RTCIceServer {
required (DOMString または sequence<DOMString>) urls;
DOMString username;
DOMString credential;
};
RTCIceServer のメンバー
urls 型 (DOMString または
sequence<DOMString>), 必須
username 型 DOMString
この RTCIceServer オブジェクトが
TURNサーバーを表す場合、この属性はそのTURNサーバーで使用するユーザー名を指定します。
credential 型 DOMString
この RTCIceServer オブジェクトが
TURNサーバーを表す場合、この属性はそのTURNサーバーで使用する認証情報を指定します。
credential は
[RFC5389]、
セクション10.2で説明されている長期認証用のパスワードを表します。
RTCIceServer オブジェクトの配列例:
[
{urls: 'stun:stun1.example.net'},
{urls: ['turns:turn.example.org', 'turn:turn.example.net'],
username: 'user',
credential: 'myPassword',
];
[RFC9429] (セクション
4.1.1.)で説明されているように、
iceTransportPolicy
メンバーが
RTCConfiguration に指定された場合、
ブラウザがアプリケーションに許可された候補を表面化するために使用する
ICE候補ポリシー [RFC9429] (セクション 3.5.3.)
を定義します。これらの候補のみが接続性チェックに使われます。
WebIDLenum RTCIceTransportPolicy {
"relay",
"all"
};
| 列挙値 | 説明 |
|---|---|
relay
|
ICEエージェント は TURNサーバーを通過する候補など、メディアリレー候補のみを使用します。
注記
これにより、リモートエンドポイントがユーザーのIPアドレスを知るのを防ぐことができます。これは特定のユースケースで望ましい場合があります。
例えば「通話」ベースのアプリケーションでは、被呼者が何らかの方法で同意するまで
発信者が被呼者のIPアドレスを知るのを防ぎたい場合などです。
|
all
|
この値が指定されている場合、ICEエージェント は あらゆる種類の候補を使用できます。
注記
実装はまだ独自の候補フィルタリングポリシーを使用して
アプリケーションに公開されるIPアドレスを制限できます。
詳細は
RTCIceCandidate の
address
の説明を参照してください。
|
[RFC9429] (セクション 4.1.1.)で説明されているように、 バンドルポリシーは、リモートエンドポイントがバンドル対応していない場合に どのメディアトラックがネゴシエートされるかや、どんなICE候補が収集されるかに影響します。 リモートエンドポイントがバンドル対応している場合、すべてのメディアトラックとデータチャネルは同じトランスポートにバンドルされます。
WebIDLenum RTCBundlePolicy {
"balanced",
"max-compat",
"max-bundle"
};
| 列挙値 | 説明 |
|---|---|
balanced
|
使用中の各メディアタイプ(音声、映像、データ)ごとにICE候補を収集します。 リモートエンドポイントがバンドル対応していない場合は、音声・映像トラックのみ 別々のトランスポートでネゴシエートします。 |
max-compat
|
各トラックごとにICE候補を収集します。 リモートエンドポイントがバンドル対応していない場合は、 すべてのメディアトラックを別々のトランスポートでネゴシエートします。 |
max-bundle
|
1つのトラックのみのICE候補を収集します。 リモートエンドポイントがバンドル対応していない場合は、1つのメディアトラックのみネゴシエートします。 |
[RFC9429] (セクション
4.1.1.)で説明されているように、
RTCRtcpMuxPolicy は非多重化RTCPをサポートするために
どのICE候補が収集されるかに影響します。この仕様で定義される値は "require" のみです。
WebIDLenum RTCRtcpMuxPolicy {
"require"
};
| 列挙値 | 説明 |
|---|---|
require
|
RTPおよび多重化RTCPのためのみICE候補を収集します。 リモートエンドポイントがrtcp-mux非対応の場合、セッションネゴシエーションは失敗します。 |
これらの辞書はオファー/アンサー生成処理を制御するために使用できるオプションを記述します。
WebIDLdictionary RTCOfferAnswerOptions {};
WebIDLdictionary RTCOfferOptions : RTCOfferAnswerOptions {
boolean iceRestart = false;
};
iceRestart 型 boolean, デフォルト値は
false
この辞書メンバーの値が trueの場合、または該当するRTCPeerConnection
オブジェクトの [[LocalIceCredentialsToReplace]]
スロットが空でない場合、生成される記述には現在の認証情報と異なるICE認証情報が含まれます
(currentLocalDescription
属性のSDPで確認できます)。生成された記述を適用すると、[RFC5245]
セクション9.1.1.1で説明されているようにICEが再起動されます。
この辞書メンバーの値が falseで、該当するRTCPeerConnection
オブジェクトの [[LocalIceCredentialsToReplace]]
スロットが空であり、
currentLocalDescription
属性に有効なICE認証情報がある場合、生成される記述には
currentLocalDescription
属性の現在値と同じICE認証情報が含まれます。
iceConnectionState
が "failed"
に遷移した時にICEの再起動を行うことが推奨されます。
アプリケーションはさらに、
iceConnectionState
が "disconnected"
に遷移した際に
getStats
などで数秒後送受信バイト数が増加しているかを測定するなど
他の情報源を使ってICE再起動が適切か判断することもできます。
RTCAnswerOptions 辞書は
"answer"
型のセッション記述に固有のオプションを記述します
(この仕様の現行標準バージョンではオプションはありません)。
WebIDLdictionary RTCAnswerOptions : RTCOfferAnswerOptions {};
WebIDLenum RTCSignalingState {
"stable",
"have-local-offer",
"have-remote-offer",
"have-local-pranswer",
"have-remote-pranswer",
"closed"
};
| 列挙値 | 説明 |
|---|---|
stable
|
オファー/アンサー交換処理が進行中ではありません。これは初期状態でもあり、ローカル・リモート記述が空の場合です。 |
have-local-offer
|
"offer" 型のローカル記述が正しく適用されました。
|
have-remote-offer
|
"offer" 型のリモート記述が正しく適用されました。
|
have-local-pranswer
|
"offer" 型のリモート記述が正しく適用され、
"pranswer"
型のローカル記述が正しく適用されました。
|
have-remote-pranswer
|
"offer" 型のローカル記述が正しく適用され、
"pranswer"
型のリモート記述が正しく適用されました。
|
closed
|
RTCPeerConnection
がクローズされており、
[[IsClosed]] スロットが
true です。
|
遷移例セット:
stable"
have-local-offer"
have-remote-pranswer"
stable"
stable"
have-remote-offer"
have-local-pranswer"
stable"
WebIDLenum RTCIceGatheringState {
"new",
"gathering",
"complete"
};
| 列挙値 | 説明 |
|---|---|
new
|
いずれかの RTCIceTransport が
"new" の収集状態にあり、
かついずれのトランスポートも
"gathering"
状態でない、
またはトランスポートが存在しない場合。
|
gathering
|
いずれかの RTCIceTransport が
"gathering"
状態にある場合。
|
complete
|
少なくとも1つの RTCIceTransport が存在し、
すべての RTCIceTransport が
"complete"
の収集状態にある場合。
|
対象となるトランスポートの集合は、
現在 RTCPeerConnection の
トランシーバ集合および、
RTCPeerConnection の
[[SctpTransport]]
内部スロットが null でない場合に考慮されます。
WebIDLenum RTCPeerConnectionState {
"closed",
"failed",
"disconnected",
"new",
"connecting",
"connected"
};
| 列挙値 | 説明 |
|---|---|
closed
|
[[IceConnectionState]]
が
"closed"
です。
|
failed
|
前の状態が適用されず、または
[[IceConnectionState]]
が
"failed"
であるか、
いずれかの RTCDtlsTransport が
"failed"
状態である場合。
|
disconnected
|
前の状態が適用されず、
[[IceConnectionState]]
が
"disconnected"
である場合。
|
new
|
前の状態が適用されず、または
[[IceConnectionState]]
が
"new"
であり、すべての
RTCDtlsTransport が
"new" または
"closed"
状態であるか、トランスポートが存在しない場合。
|
connected
|
前の状態が適用されず、
[[IceConnectionState]]
が
"connected"
であり、すべての
RTCDtlsTransport が
"connected"
または
"closed"
状態である場合。
|
connecting
|
前の状態が適用されません。 |
"connecting"
状態では、1つ以上の
RTCIceTransport が
"new" または
"checking" 状態、
または1つ以上の
RTCDtlsTransport が
"new" または
"connecting"
状態です。
対象となるトランスポートの集合は、
現在 RTCPeerConnection の
トランシーバ集合および
RTCPeerConnection の
[[SctpTransport]]
内部スロットが null でない場合に考慮されます。
WebIDLenum RTCIceConnectionState {
"closed",
"failed",
"disconnected",
"new",
"checking",
"completed",
"connected"
};
| 列挙値 | 説明 |
|---|---|
closed
|
RTCPeerConnection
オブジェクトの [[IsClosed]]
スロットが true である状態。
|
failed
|
以前の状態が該当せず、すべての
RTCIceTransport が
"failed"
状態にある場合。
|
disconnected
|
以前の状態が該当せず、いずれかの
RTCIceTransport が
"disconnected"
状態にある場合。
|
new
|
以前の状態が該当せず、すべての
RTCIceTransport が
"new" または
"closed"
状態、もしくはトランスポートが存在しない場合。
|
checking
|
以前の状態が該当せず、いずれかの
RTCIceTransport が
"new" または
"checking"
状態にある場合。
|
completed
|
以前の状態が該当せず、すべての
RTCIceTransport が
"completed"
または
"closed"
状態にある場合。
|
connected
|
以前の状態が該当せず、すべての
RTCIceTransport が
"connected",
"completed"
または
"closed"
状態にある場合。
|
対象となるトランスポートの集合は、現在参照されている RTCPeerConnection の
トランシーバ集合および RTCPeerConnection の
[[SctpTransport]]
内部スロットが null でない場合に限ります。
RTCIceTransport が
シグナリングの結果として廃棄された場合(例: RTCP muxやバンドル)、または
シグナリングの結果として生成された場合(例: 新しい メディア記述 の追加)には、
状態が直接別の状態に遷移することがあります。
[RFC9429] 現行標準仕様全体で
RTCPeerConnection
の動作詳細が記述されています。
必要に応じて [RFC9429]
の個別サブセクションへの参照があります。
new
を呼び出すことで
RTCPeerConnection(configuration)RTCPeerConnection オブジェクトが生成されます。
configuration.iceServers には
ICEで利用するサーバーの情報が含まれます。アプリケーションは各タイプのサーバーを複数指定でき、
TURNサーバーはサーバー反射候補の収集目的でSTUNサーバーとしても利用できる 可能性があります。
RTCPeerConnection オブジェクトは
[[SignalingState]]、
集約状態として
[[ConnectionState]]、
[[IceGatheringState]]、
[[IceConnectionState]]
を持ちます。これらはオブジェクト生成時に初期化されます。
RTCPeerConnection のICEプロトコル実装は
ICEエージェント
[RFC5245]
で表されます。
RTCPeerConnection の特定のメソッドは
ICEエージェント とやり取りします。具体的には
addIceCandidate、
setConfiguration、
setLocalDescription、
setRemoteDescription、
close
です。これらのやり取りの詳細は本仕様および [RFC9429] で説明されています。
ICEエージェント は
RTCIceTransport
の内部状態が変化した際に
ユーザーエージェントへ通知も行います(5.6
RTCIceTransport インターフェイス 参照)。
このセクション記載のタスクのタスクソースは ネットワークタスクソース です。
SDPネゴシエーションの状態は内部変数
[[SignalingState]]、
[[CurrentLocalDescription]]、
[[CurrentRemoteDescription]]、
[[PendingLocalDescription]]、
[[PendingRemoteDescription]]
で表現されます。これらは
setLocalDescription
および setRemoteDescription
操作でのみ設定されます。さらに
addIceCandidate 操作と
候補の公開 手順によっても変更されます。
いずれの場合も、5つの変数へのすべての変更はイベント発火やコールバック呼び出しの前に完了し、
変更は同時に可視化されます。
アンロードドキュメントのクリーンアップ手順の一つとして、次の手順を実行する:
window を document の 関連付けられたグローバルオブジェクト とする。
RTCPeerConnection オブジェクト
connection について、
その 関連付けられたグローバルオブジェクト が window である場合、
接続を終了する を connection および値
true で実行する。
RTCPeerConnection.constructor()
が呼び出されたとき、
ユーザーエージェントは 必須で以下の手順を実行する:
以下に列挙されたいずれかの手順が、ここで特に指定されていない理由で失敗した場合、
throw で UnknownError
を、message
属性には適切な説明を設定して送出する。
connection を新しく作られた
RTCPeerConnection オブジェクトとする。
connection に [[DocumentOrigin]] 内部スロットを持たせ、 関連付けられた設定オブジェクト の origin で初期化する。
configuration の certificates
の値が空でない場合、
certificates の各 certificate について以下の手順を実行する:
certificate.expires
の値が現在時刻未満の場合、
throw で
InvalidAccessError を送出する。
certificate.[[Origin]] が
同一オリジン でない場合、
connection.[[DocumentOrigin]] と比較して、
throw で InvalidAccessError を送出する。
certificate を保存する。
それ以外の場合は、新しい RTCCertificate インスタンスを
この RTCPeerConnection
インスタンスと共に生成し、保存する。
これは 非同期で実行される可能性があり、
certificates
の値は後続ステップでは undefined のままとなる。
[RFC8826] Section 4.3.2.3
に記載の通り、WebRTCは
PKI証明書ではなく自己署名証明書を利用するため、有効期限チェックは鍵の無制限利用防止のためであり、追加の証明書チェックは不要である。
connection の ICEエージェント を初期化する。
connection に
[[Configuration]]
内部スロットを持たせ、null で初期化する。
指定された構成を設定する を configuration
で実行する。
connection に [[IsClosed]]
内部スロットを持たせ、false で初期化する。
connection に
[[NegotiationNeeded]] 内部スロットを持たせ、false
で初期化する。
connection に
[[SctpTransport]] 内部スロットを持たせ、null で初期化する。
connection に [[DataChannels]] 内部スロットを持たせ、空の 順序付き集合 で初期化する。
connection に [[Operations]] 内部スロットを持たせ、操作チェーンを表し、空のリストで初期化する。
connection に
[[UpdateNegotiationNeededFlagOnEmptyChain]]
内部スロットを持たせ、false で初期化する。
connection に
[[LastCreatedOffer]] 内部スロットを持たせ、"" で初期化する。
connection に
[[LastCreatedAnswer]] 内部スロットを持たせ、""
で初期化する。
connection に [[EarlyCandidates]] 内部スロットを持たせ、空のリストで初期化する。
connection に
[[SignalingState]]
内部スロットを持たせ、"stable" で初期化する。
connection に
[[IceConnectionState]]
内部スロットを持たせ、"new" で初期化する。
connection に
[[IceGatheringState]]
内部スロットを持たせ、"new" で初期化する。
connection に
[[ConnectionState]]
内部スロットを持たせ、"new" で初期化する。
connection に
[[PendingLocalDescription]]
内部スロットを持たせ、null で初期化する。
connection に
[[CurrentLocalDescription]]
内部スロットを持たせ、null で初期化する。
connection に
[[PendingRemoteDescription]]
内部スロットを持たせ、null で初期化する。
connection に
[[CurrentRemoteDescription]]
内部スロットを持たせ、null で初期化する。
connection に [[LocalIceCredentialsToReplace]] 内部スロットを持たせ、空集合で初期化する。
connection を返す。
RTCPeerConnection オブジェクトは、操作
チェーン、[[Operations]]を持ち、これによってチェーン内で一度に実行される
非同期操作が1つだけであることが保証される。以前の呼び出しによって返された Promise が
まだ確定していない間に後続の呼び出しが行われた場合、それらは
チェーンに追加され、それ以前のすべての呼び出しの実行が完了し、
それらの Promise が確定した時点で実行される。
RTCPeerConnection オブジェクトの操作チェーンに操作をチェーンするには、次の
手順を実行する。
connectionをRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、新たに作成されたInvalidStateErrorで拒否された Promise を返す。
operationをチェーンする操作とする。
pを新しい Promise とする。
operationを[[Operations]]に追加する。
[[Operations]]の長さがちょうど1である場合、
operationを実行する。
operationによって返された Promise が 履行または拒否されたとき、 次の 手順を実行する。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
[[Operations]]の最初の要素を削除する。
[[Operations]]が
空でない場合、
[[Operations]]の最初の要素によって表される
操作を実行し、
これらの手順を中止する。
connection.[[UpdateNegotiationNeededFlagOnEmptyChain]]
がfalseである場合、これらの手順を中止する。
connection.[[UpdateNegotiationNeededFlagOnEmptyChain]]
をfalseに設定する。
connectionについてネゴシエーション必要フラグを 更新する。
pを返す。
RTCPeerConnection オブジェクトは
集約された
[[ConnectionState]]
を持ちます。
RTCDtlsTransport の状態が変化したとき、
ユーザーエージェントは必須で次の手順をキューイングします:
connection を、状態が変化した RTCPeerConnection
オブジェクトと関連付けられた RTCDtlsTransport オブジェクトとする。
connection.[[IsClosed]] が
true なら、これらの手順を中止する。
newState を、RTCPeerConnectionState
列挙型で記述された新しい状態値とする。
connection.[[ConnectionState]] が
newState と等しい場合、これらの手順を中止する。
connection.[[ConnectionState]] を
newState に設定する。
イベントを発火する、名前をconnectionstatechangeとし、
connectionで発火する。
ローカルセッション記述を設定するには、
RTCPeerConnection オブジェクト
connection上のdescriptionについて、追加の値
falseを用いて、connection上に
descriptionというセッション
記述を設定する。
リモートセッション記述を設定するには、RTCPeerConnection オブジェクト
connection上のdescriptionについて、追加の値
trueを用いて、connection上に
descriptionというセッション
記述を設定する。
RTCPeerConnection オブジェクト
connection上にdescriptionというセッション
記述を設定するには、
remoteブール値を与えて、次の手順を実行する。
pを新しい Promise とする。
description.typeが
"rollback"であり、
connection.[[SignalingState]]
が "stable"、
"have-local-pranswer"、
または
"have-remote-pranswer"
のいずれかである場合、新たに作成された
InvalidStateErrorでpを拒否し、これらの
手順を中止する。
jsepSetOfTransceiversを、 connectionのトランシーバーの集合の浅いコピーとする。
並行して、[RFC9429] (5.5節および 5.6 節)に記述されているように、 descriptionを適用するプロセスを、次の追加制限とともに開始する。
どの "RtpTransceivers" が存在するかについての
信頼できる情報源としてjsepSetOfTransceiversを使用し、
それらの[[JsepMid]]内部スロットを
"mid
プロパティ" として使用する。
remoteがfalseであり、これによって[RFC9429]
(5.9
節)の ICE 候補収集プロセスが開始される場合、ICE エージェントは、
管理上
禁止されることになる候補を収集してはならない
(MUST NOT)。
remoteがtrueであり、これによって[RFC9429]
(5.10
節)の ICE 接続性チェックが開始される場合、
ICE エージェントは、
管理上
禁止されている候補への接続を試みてはならない(MUST NOT)。
remoteがtrueである場合、後続のオファーに対する
チェックを stable 状態であるかのように実行することにより、
連続するオファーを、その間にアンサーが適用されたかのように検証する。
descriptionを適用することで トランシーバーtransceiverが変更され、 transceiver.[[Sender]].[[SendEncodings]] が空でなく、かつdescriptionの処理によって 得られるエンコーディングと等しくない場合、 descriptionの適用プロセスは失敗する。この 仕様では、リモート側から開始される RID 再ネゴシエーションを許可しない。
descriptionを適用するプロセスが何らかの 理由で失敗した場合、ユーザーエージェントは次の手順を実行するタスクを キューに入れなければならない(MUST)。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
description.type
が、
[RFC9429]
(5.5
節および5.6
節)に記述されているように、現在の
connection.[[SignalingState]]
に対して無効である場合、新たに作成されたInvalidStateError
でpを拒否し、
これらの手順を中止する。
descriptionの内容が有効な
SDP 構文でない場合、pを
RTCErrorで拒否する
(errorDetail
を
"sdp-syntax-error"
に設定し、
sdpLineNumber
属性を、構文エラーが
検出された SDP 内の行
番号に設定する)。その後、これらの手順を中止する。
remoteがtrueであり、
connectionのRTCRtcpMuxPolicy
が
require
で、かつ記述が
RTCP mux を使用していない場合、新たに作成された
InvalidAccessErrorで
pを拒否し、
これらの手順を中止する。
上述のように、記述が RID の再ネゴシエーションを試みた場合、
新たに作成された
InvalidAccessErrorで
pを拒否し、
これらの手順を中止する。
descriptionの内容が無効である場合、
新たに作成されたInvalidAccessErrorで
pを拒否し、
これらの手順を
中止する。
その他すべてのエラーについて、新たに作成されたOperationErrorで
pを拒否する。
descriptionが正常に適用された場合、 ユーザーエージェントは次の手順を実行するタスクをキューに 入れなければならない(MUST)。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
remoteがtrueであり、
descriptionの型が
"offer"である場合、
descriptionを適用するプロセス中に
connection上のいずれかの
addTrack()
メソッドが成功した場合、
これらの手順を中止し、それらが事前に成功していたものとして
プロセスを最初から開始し、追加の
トランシーバーをプロセスに含める。
connectionに関連付けられた
RTCRtpSender上のsetParameters
メソッドからのいずれかの Promise が確定していない場合、
これらの手順を中止してプロセスを最初から開始する。
descriptionの型が
"offer"であり、
connection.[[SignalingState]]
が "stable"
である場合、connectionのトランシーバーの
集合内の各
transceiverについて、次の手順を実行する。
transceiver.[[Sender]].[[LastStableStateSenderTransport]]
を
transceiver.[[Sender]].[[SenderTransport]]
に設定する。
transceiver.[[Sender]].[[SendEncodings]].length
が1であり、その唯一のエンコーディングにrid
メンバーが含まれていない場合、
transceiver.[[Sender]].[[LastStableRidlessSendEncodings]]
を
transceiver.[[Sender]].[[SendEncodings]]
に設定する。それ以外の場合、
transceiver.[[Sender]].[[LastStableRidlessSendEncodings]]
をnullに設定する。
transceiver.[[Receiver]].[[LastStableStateReceiverTransport]]
を
transceiver.[[Receiver]].[[ReceiverTransport]]
に設定する。
transceiver.[[Receiver]].[[LastStableStateAssociatedRemoteMediaStreams]]
を
transceiver.[[Receiver]].[[AssociatedRemoteMediaStreams]]
に設定する。
transceiver.[[Receiver]].[[LastStableStateReceiveCodecs]]
を
transceiver.[[Receiver]].[[ReceiveCodecs]]
に設定する。
remoteがfalseである場合、次の手順の
いずれかを実行する。
descriptionの型が
"offer"
である場合、
connection.[[PendingLocalDescription]]
をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[SignalingState]]
を
"have-local-offer"
に設定し、早期候補を
解放する。
descriptionの型が
"answer"
である場合、これによって
オファー・アンサーのネゴシエーションが完了する。
connection.[[CurrentLocalDescription]]
をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[CurrentRemoteDescription]]
を
connection.[[PendingRemoteDescription]]
に設定する。
connection.[[PendingRemoteDescription]]
と
connection.[[PendingLocalDescription]]
の両方をnullに設定する。
connection.[[LastCreatedOffer]]
と
connection.[[LastCreatedAnswer]]
の両方を""に設定し、
connection.[[SignalingState]]
を
"stable"
に設定し、早期
候補を解放する。最後に、
connection.[[LocalIceCredentialsToReplace]]
内の ICE 資格情報がどれもdescriptionに存在しない場合、
connection.[[LocalIceCredentialsToReplace]]
を空集合に設定する。
descriptionの型が
"pranswer"
である場合、
connection.[[PendingLocalDescription]]
をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[SignalingState]]
を
"have-local-pranswer"
に設定し、
早期
候補を解放する。
それ以外の場合(remoteが
trueの場合)、次の手順のいずれかを実行する。
descriptionの型が
"offer"
である場合、
connection.[[PendingRemoteDescription]]
属性をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[SignalingState]]
を
"have-remote-offer"
に設定する。
descriptionの型が
"answer"
である場合、これによって
オファー・アンサーのネゴシエーションが完了する。
connection.[[CurrentRemoteDescription]]
をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[CurrentLocalDescription]]
を
connection.[[PendingLocalDescription]]
に設定する。
connection.[[PendingRemoteDescription]]
と
connection.[[PendingLocalDescription]]
の両方をnullに設定する。
connection.[[LastCreatedOffer]]
と
connection.[[LastCreatedAnswer]]
の両方を""に設定し、
connection.[[SignalingState]]
を
"stable"
に設定する。最後に、
connection.[[LocalIceCredentialsToReplace]]
内の ICE 資格情報がどれも、新たに設定された
connection.[[CurrentLocalDescription]]
に存在しない場合、
connection.[[LocalIceCredentialsToReplace]]
を空集合に設定する。
descriptionの型が
"pranswer"
である場合、
connection.[[PendingRemoteDescription]]
をdescriptionから構築した新しいRTCSessionDescription
オブジェクトに設定し、
connection.[[SignalingState]]
を
"have-remote-pranswer"
に設定する。
descriptionの型が
"answer"であり、
[RFC8841]
の10.3節および10.4節で定義されているように、
既存の SCTP アソシエーションの終了を開始する場合、
connection.[[SctpTransport]]
の値を
nullに設定する。
trackEventInits、 muteTracks、addList、 removeList、およびerrorListを 空のリストとする。
descriptionの型が
"answer"または"pranswer"
である場合、次の手順を実行する。
descriptionが、
[RFC8841]
の10.3節および10.4節で定義されているように、
新しい SCTP アソシエーションの確立を開始する場合、
初期状態を"connecting"
としてRTCSctpTransport
を
作成し、その結果を
[[SctpTransport]]
スロットに割り当てる。それ以外の場合、SCTP
アソシエーションが確立されているが、
max-message-size SDP
属性が更新された場合、
connection.[[SctpTransport]]のデータの最大メッセージサイズを更新する。
descriptionが SCTP トランスポートの DTLS
ロールをネゴシエーションする場合、nullのidを持つ
各RTCDataChannel
channelについて、次の手順を
実行する。
[[ReadyState]]
を
"closed"
に設定し、
channnelをerrorListに追加する。
descriptionの型が
"rollback"
でない場合、次の
手順を実行する。
remoteがfalseである場合、
description内の各メディア記述について
次の手順を実行する。
メディア
記述がまだ
RTCRtpTransceiver
オブジェクトに関連付けられていない場合、
次の手順を実行する。
transceiverを、
メディア
記述の作成に使用された
RTCRtpTransceiver
とする。
transceiver.[[Mid]]
を
transceiver.[[JsepMid]]
に設定する。
transceiver.[[Stopped]]
がtrueである場合、これらのサブ
手順を中止する。
メディア
メディア
記述が、[RFC8843]
に従って、既存のメディア
メディア
トランスポートを使用すると示されている場合、
transportを、そのトランスポートの
RTP/RTCP コンポーネントを表す
RTCDtlsTransport
オブジェクトとする。
それ以外の場合、transportを、
新しい基礎となる
RTCIceTransport
を持つ、新たに作成されたRTCDtlsTransport
オブジェクトとする。
transceiver.[[Sender]].[[SenderTransport]]
をtransportに設定する。
transceiver.[[Receiver]].[[ReceiverTransport]]
をtransportに設定する。
transceiverを、
メディア
記述に関連付けられた
RTCRtpTransceiver
とする。
transceiver.[[Stopped]]
がtrueである場合、これらのサブ手順を中止する。
directionを、メディア
メディア
記述からの方向を表す
RTCRtpTransceiverDirection
値とする。
directionが
"sendrecv"
または
"recvonly"
である場合、
transceiver.[[Receptive]]
をtrueに設定し、それ以外の場合は
falseに設定する。
transceiver.[[Receiver]].[[ReceiveCodecs]]
を、descriptionが受信用に
ネゴシエーションし、ユーザーエージェントが現在
受信する準備ができているコーデックに設定する。
descriptionの型が
"answer"
または
"pranswer"
である場合、次の
手順を実行する。
transceiver.
[[Sender]].[[SendEncodings]]
.length が1より大きい場合、
次の手順を実行する。
descriptionに、以前にネゴシエーションされた
すべてのレイヤーが欠けている場合、
transceiver.[[Sender]].[[SendEncodings]]
内の辞書を、最初の1つを除いて
すべて削除し、次の
手順を飛ばす。
descriptionに、以前にネゴシエーションされた
いずれかのレイヤーが欠けている場合、
欠けているレイヤーに対応する辞書を
transceiver.[[Sender]].[[SendEncodings]]
から削除する。
transceiver.[[Sender]].[[SendCodecs]]
を、descriptionが送信用に
ネゴシエーションし、ユーザーエージェントが現在
送信可能なコーデックに設定し、
transceiver.[[Sender]].[[LastReturnedParameters]]
をnullに設定する。
directionが
"sendonly"
または
"inactive"
であり、
transceiver.[[FiredDirection]]
が
"sendrecv"
または
"recvonly"
のいずれかである場合、次の手順を実行する。
transceiver.[[Receiver]]、
空のリスト、別の空のリスト、
およびremoveListを与えて、
関連付けられたリモートストリームを
設定する。
メディア
記述について、transceiverと
muteTracksを与えて、
リモート
リモート
トラックの削除を処理する。
transceiver.[[CurrentDirection]]
と
transceiver.[[FiredDirection]]
をdirectionに設定する。
それ以外の場合(remoteが
trueの場合)、description内の
各メディア記述について
次の手順を実行する。
descriptionの型が
"offer"
であり、
メディア
記述がサイマルキャストを受信する要求を
含む場合、simulcast
属性で指定された rid 値の順序を使用して、
各サイマルキャストレイヤーについて
RTCRtpEncodingParameters
辞書を作成し、対応する rid 値値
(カンマ区切りの代替候補が存在する場合は最初の値のみを使用する)に従って
rid
メンバーを設定し、sendEncodingsproposedSendEncodings
を、作成した辞書を含むリスト
リストとする。それ以外の場合、sendEncodings
proposedSendEncodings
を空の
空の
リストとする。
proposedSendEncodings内の各エンコーディング
encodingについて逆順に、
encodingの
rid
が
proposedSendEncodings内の別のエンコーディングのものと
一致する場合、encodingを
proposedSendEncodingsから削除する。
scaleResolutionDownBy
を2^(length of sendEncodingsproposedSendEncodings -
encoding index - 1)に設定する。
[RFC8829RFC9429]
(5.10
節)で記述されているように、
メディア
記述を表す既存の
RTCRtpTransceiver
オブジェクト
transceiverを見つけることを試みる。
適切なトランシーバーが見つかり
(transceiverが設定されている)、かつ
sendEncodingsproposedSendEncodings
が空でない場合、
transceiver.[[Sender]].[[SendEncodings]]
を
sendEncodingsに設定し、
transceiver.[[Sender]].[[LastReturnedParameters]]
を次の
手順を実行する。
nullに設定する。
transceiver.[[Sender]].[[SendEncodings]]
の長さが1であり、唯一のエンコーディングに
rid
メンバーが含まれていない場合、
transceiver.[[Sender]].[[SendEncodings]]
をproposedSendEncodingsに設定し、
transceiver.[[Sender]].[[LastReturnedParameters]]
をnullに設定する。
適切なトランシーバーが見つからなかった場合 (transceiverが未設定)、次の 手順を実行する。
sendEncodingsproposedSendEncodings
を使用して、メディア
メディア
記述から
RTCRtpSender
を
作成し、
senderとする。
メディア
メディア
記述から
RTCRtpReceiver
を作成し、
receiverとする。
sender、receiver
および値が
"recvonly"
であるRTCRtpTransceiverDirection
値を用いてRTCRtpTransceiver
を作成し、
その結果をtransceiverとする。
transceiverを
connectionのトランシーバーの集合
集合
に追加する。
descriptionの型が
"answer"
または
"pranswer"
であり、
transceiver.
[[Sender]].[[SendEncodings]]
.length が1より大きい場合、
次の手順を実行する。
descriptionがサイマルキャストは
サポートされていない、または望まれていないことを示す場合、または
descriptionに以前にネゴシエーションされた
すべてのレイヤーが欠けている場合、
transceiver.[[Sender]].[[SendEncodings]]
内の辞書を最初の1つを除いてすべて削除し、
これらのサブ手順を中止する。
descriptionが拒否する
欠いているものが、
オファーされた
以前に
ネゴシエーションされたレイヤーのいずれかである場合、
transceiver.[[Sender]].[[SendEncodings]]
から、拒否された
欠けている
レイヤーに対応する辞書
辞書
を削除する。
各サイマルキャスト
レイヤーの一時停止状態を[RFC8853]
の指示に従って更新するため、
transceiver.[[Sender]].[[SendEncodings]]
内の対応する辞書の
メンバーを、一時停止していない場合はactivetrue、
一時停止している場合はfalseに設定する。
transceiver.[[Mid]]を
transceiver.[[JsepMid]]
に設定する。
directionを、メディア
メディア
記述からの方向を表す
RTCRtpTransceiverDirection
値とする。ただし、このピアの
視点を表すために、送信方向と受信方向を逆にする。
メディア
記述
が拒否されている場合、directionを
"inactive"
に設定する。
directionが
"sendrecv"
または
"recvonly"
である場合、msidsを、メディア記述が
transceiver.[[Receiver]].[[ReceiverTrack]]
と関連付けるよう示している MSID のリストとする。
それ以外の場合、
msidsを空のリストとする。
transceiver、direction、 msids、addList、 removeList、および trackEventInitsを用いてリモート トラックを処理する。
transceiver.[[Receiver]].[[ReceiveCodecs]]
を、descriptionが受信用に
ネゴシエーションし、ユーザーエージェントが現在
受信する準備ができているコーデックに設定する。
descriptionの型が
"answer"
または
"pranswer"
である場合、次の
手順を実行する。
transceiver.[[Sender]].[[SendCodecs]]
を、descriptionが送信用に
ネゴシエーションし、ユーザーエージェントが現在
送信可能なコーデックに設定する。
transceiver.[[CurrentDirection]]
および
transceiver.[[Direction]]群
をdirectionに設定する。
transportを、
[RFC8843]
に従って、transceiverに関連付けられた
メディア
記述が使用するメディア
メディア
トランスポートの
RTP/RTCP コンポーネントを表す
RTCDtlsTransport
オブジェクトとする。
transceiver.[[Sender]].[[SenderTransport]]
をtransportに設定する。
transceiver.[[Receiver]].[[ReceiverTransport]]
をtransportに設定する。
[RFC8445]
の規則に従って、
transportの[[IceRole]]
を設定する。
[[IceRole]]
が
unknown
でない場合、
[[IceRole]]
を変更しない。
controlling
に設定する。
a=ice-liteを含む場合、
[[IceRole]]
を
controlling
に設定する。
a=ice-liteを含まない場合、
[[IceRole]]
を
controlled
に設定する。
[[IceRole]]
が常に値を持つことが保証される。
メディア
記述が拒否されており、
かつ
transceiver.[[Stopped]]
が
falseである場合、
transceiverをRTCRtpTransceiver
を
RTCRtpTransceiver
を
停止する。
それ以外の場合(descriptionの型が
"rollback"
である場合)、次の手順を実行する。
pendingDescriptionを、
connection.[[PendingLocalDescription]]
または
connection.[[PendingRemoteDescription]]
のうち、nullでない方とする。
connectionのトランシーバーの集合 内の各transceiverについて、 次の手順を実行する。
pendingDescriptionが設定される前に
transceiverがメディア
記述に関連付けられていなかった場合、
関連付けを解除し、
transceiver.[[JsepMid]]
とtransceiver.[[Mid]]の両方を
nullに設定する。
transceiver.[[Sender]].[[SenderTransport]]
を
transceiver.[[Sender]].[[LastStableStateSenderTransport]]
に設定する。
transceiver.[[Sender]].[[LastStableRidlessSendEncodings]]
がnullでなく、かつ
transceiver.[[Sender]].[[SendEncodings]]
内のいずれかのエンコーディングが
rid
メンバーを含む場合、
transceiver.[[Sender]].[[SendEncodings]]
を
transceiver.[[Sender]].[[LastStableRidlessSendEncodings]]
に設定する。
transceiver.[[Receiver]].[[ReceiverTransport]]
を
transceiver.[[Receiver]].[[LastStableStateReceiverTransport]]
に設定する。
transceiver.[[Receiver]].[[ReceiveCodecs]]
を
transceiver.[[Receiver]].[[LastStableStateReceiveCodecs]]
に設定する。
connection.[[SignalingState]]
が "have-remote-offer"
である場合、次のサブ手順を実行する。
msidsを、
transceiver.[[Receiver]].[[LastStableStateAssociatedRemoteMediaStreams]]
内のすべての
MediaStream
オブジェクトの
idのリストとし、
存在しない場合は空のリストとする。
transceiver、
transceiver.[[CurrentDirection]]、
msids、addList、
removeList、および
trackEventInitsを用いてリモート
トラックを処理する。
pendingDescriptionが設定されたときに
transceiverが作成され、
addTrack()
を介してトラックが一度も接続されていない場合、
transceiverをRTCRtpTransceiver
を
停止するものとし、
connectionのトランシーバーの
集合から削除する。
connection.[[PendingLocalDescription]]
と
connection.[[PendingRemoteDescription]]
をnullに設定し、
connection.[[SignalingState]]
を
"stable"
に設定する。
descriptionの型が
"answer"である場合、
次の手順を実行する。
connectionのトランシーバーの集合 内の各transceiverについて、 次の手順を実行する。
transceiverが
stopped
であり、m= セクションに
関連付けられており、
関連付けられた m=
セクションが
connection.[[CurrentLocalDescription]]
または
connection.[[CurrentRemoteDescription]]
で拒否されている場合、
transceiverを
connectionのトランシーバーの
集合から削除する。
connection.[[SignalingState]]
が現在
"stable"
である場合、次の
手順を実行する。
前の手順でトランシーバーの集合から
削除された任意のtransceiverについて、
そのトランスポート
(transceiver.[[Sender]].[[SenderTransport]]
または
transceiver.[[Receiver]].[[ReceiverTransport]])
のいずれかがまだ閉じられておらず、かつ停止していない
トランシーバーから参照されなくなっている場合、
RTCDtlsTransport群
およびそれらに関連付けられた
RTCIceTransport群を閉じる。
これにより、キューに入れられたタスク内で
これらのオブジェクト上にイベントが発火する。
connectionのトランシーバーの 集合内の各transceiverについて:
codecsをtransceiver.[[Sender]].[[SendCodecs]]
とする。
codecsが空のリストでない場合:
transceiver.[[Sender]].[[SendEncodings]]
内の各encodingについて、
ignoreLevelsを
trueに設定したコーデック
辞書一致アルゴリズムを使用して、
encoding.codec
がcodecs内のどのエントリにも一致しない場合、
encoding.codec
を削除する。
connection.[[SignalingState]]
が上記で変更された場合、connectionで
イベントを発火し、その名前を
signalingstatechange
とする。
errorList内の各channelについて、
channelで
イベントを発火し、その名前をerror
とする。このとき、
errorDetail
属性を
"data-channel-failure"
に設定した
RTCErrorEvent
インターフェイスを使用する。
muteTracks内の各trackについて、
trackのミュート
状態を設定し、値をtrueとする。
removeList内の各streamとtrackの ペアについて、streamから trackというトラックを削除する。
addList内の各streamとtrackの ペアについて、streamに trackというトラックを 追加する。
trackEventInits内の各エントリentryについて、
connectionオブジェクトでイベントを
発火し、その名前を
trackとする。このとき、RTCTrackEvent
インターフェイスを使用し、
そのreceiver
属性を
entry.receiverで初期化し、
そのtrack
属性を
entry.trackで初期化し、
その
streams
属性を
entry.streamsで初期化し、
さらに
そのtransceiver
属性を
entry.transceiverで
初期化する。
undefinedで
pを解決する。
pを返す。
構成を設定するために configuration を用いる場合、次の手順を実行する:
connection を対象の RTCPeerConnection
オブジェクトとする。
oldConfig を
connection.[[Configuration]]
とする。
もし oldConfig が null でないなら、以下の手順を実行し、そのいずれかが失敗した場合は
例外を投げ
InvalidModificationError を送出する:
configuration.certificates
の長さが
oldConfig.certificates
の長さと異なるなら失敗とする。
index を 0 とする。
index が
configuration.certificates
の長さより小さい間、次を実行する:
configuration.certificates
の index 位置の値で表される ECMAScript オブジェクトが、
oldConfig.certificates
の index 位置の値で表される ECMAScript オブジェクトと同一でなければ、失敗とする。
index を 1 増加させる。
configuration.bundlePolicy
の値が
oldConfig.bundlePolicy
と異なるなら失敗とする。
configuration.rtcpMuxPolicy
の値が
oldConfig.rtcpMuxPolicy
と異なるなら失敗とする。
configuration.iceCandidatePoolSize
の値が
oldConfig.iceCandidatePoolSize
と異なり、かつ setLocalDescription
が既に呼び出されている場合、失敗とする。
iceServers を
configuration.iceServers
とする。
iceServers をサポートされる最大要素数まで切り詰める。
iceServers の各 server について、 次を実行する:
urls を
server.urls
とする。
もし urls が文字列なら、urls をその文字列のみからなるリストに設定する。
もし urls が空なら、"SyntaxError" の
DOMException を
送出する。
urls 内の各 url について、ICE サーバー URL を検証する アルゴリズムを url に対して実行する。
ICE Agent の ICE トランスポート設定
を
configuration.iceTransportPolicy
の値に設定する。[RFC9429]
(セクション
4.1.18.) に定義されるように、新しい ICE トランスポート設定 が既存の設定を変更しても、
次の収集フェーズまで何も行われない。スクリプトが即座の反映を望む場合、ICE リスタートを行うべきである。
ICE Agent の事前取得された ICE 候補プールサイズ を [RFC9429]
(セクション 3.5.4.
および セクション
4.1.1.) に従い、
configuration.iceCandidatePoolSize
の値に設定する。新しい ICE 候補プールサイズ
が既存の設定を変更する場合、
これは [RFC9429]
(セクション
4.1.18.) に定義されるように、新しいプール候補の即時収集、もしくは既存のプール候補の破棄を引き起こし得る。
ICE Agent の ICE サーバーリスト を iceServers に設定する。
[RFC9429] (セクション 4.1.18.) に定義されるように、新しいサーバーのリストが ICE Agent の既存の ICE サーバーリスト を置き換えても、 次の収集フェーズまで何も行われない。スクリプトが即座の反映を望む場合、ICE リスタートを行うべきである。 しかし ICE 候補プール のサイズが 0 でない場合、 既存のプール候補は破棄され、新しいサーバーから新しい候補が収集される。
configuration を
[[Configuration]] 内部スロットに格納する。
ICE サーバー URL を検証する url について、次の手順を実行する:
url を [RFC3986]
に定義された
一般的な URI 構文でパースし scheme
name を得る。 [RFC3986]
の構文に基づく
パースに失敗したら throw
SyntaxError
を送出する。
もし scheme name がブラウザに実装されていなければ throw
NotSupportedError
を送出する。
もし scheme name が
turn または turns で、
[RFC7065]
に定義された構文による
url のパースが失敗したら throw SyntaxError
を送出する。
もし scheme
name が stun または
stuns で、
[RFC7064]
に定義された構文による
url のパースが失敗したら throw
SyntaxError
を送出する。
parsedURL を パース した url の結果とする。
以下のいずれかの条件が当てはまる場合、
throw し、
"SyntaxError" の
DOMException を送出する:
"stun",
"stuns", "turn", "turns" のいずれでもない
"/" または
"@" を含む
"stun" または
"stuns" であり、かつ parsedURL の query が non-null である
もし parsedURL の scheme がユーザーエージェントに実装されていなければ、
throw し
NotSupportedError を送出する。
hostAndPortURL を、
"https://" と parsedURL の path を連結したものを
パース した結果とする。
hostAndPortURL が failure なら、
throw し
"SyntaxError" の
DOMException を送出する。
もし hostAndPortURL の path,
username, または password が non-null であれば
throw し "SyntaxError" の
DOMException を送出する。
もし parsedURL の query が non-null で、かつ parsedURL の query が "transport=udp" または
"transport=tcp"
のいずれとも異なる場合、
throw し "SyntaxError" の
DOMException を送出する。
もし scheme nameparsedURL の scheme が turn"turn" または または
turns"turns" であり、
server.username または
server.credential が 省略されている
存在しない なら、
throw し
InvalidAccessError を送出する。
もし scheme name が turn または turns で、
server.credentialType が
""
で、
かつ
server.passwordcredential が
DOMString でないなら
throw し InvalidAccessError
を送出する。
本節で提示される RTCPeerConnection インターフェイスは、この仕様全体を通じて複数の partial
interface により拡張される。特に、RTP メディア API の節では、MediaStreamTrack オブジェクトを送受信するための API が追加される。
WebIDL[Exposed=Window]
interface RTCPeerConnection : EventTarget {
constructor(optional RTCConfiguration configuration = {});
Promise<RTCSessionDescriptionInit> createOffer(optional RTCOfferOptions options = {});
Promise<RTCSessionDescriptionInit> createAnswer(optional RTCAnswerOptions options = {});
Promise<undefined> setLocalDescription(optional RTCLocalSessionDescriptionInit description = {});
readonly attribute RTCSessionDescription? localDescription;
readonly attribute RTCSessionDescription? currentLocalDescription;
readonly attribute RTCSessionDescription? pendingLocalDescription;
Promise<undefined> setRemoteDescription(RTCSessionDescriptionInit description);
readonly attribute RTCSessionDescription? remoteDescription;
readonly attribute RTCSessionDescription? currentRemoteDescription;
readonly attribute RTCSessionDescription? pendingRemoteDescription;
Promise<undefined> addIceCandidate(optional RTCIceCandidateInit candidate = {});
readonly attribute RTCSignalingState signalingState;
readonly attribute RTCIceGatheringState iceGatheringState;
readonly attribute RTCIceConnectionState iceConnectionState;
readonly attribute RTCPeerConnectionState connectionState;
readonly attribute boolean? canTrickleIceCandidates;
undefined restartIce();
RTCConfiguration getConfiguration();
undefined setConfiguration(optional RTCConfiguration configuration = {});
undefined close();
attribute EventHandler onnegotiationneeded;
attribute EventHandler onicecandidate;
attribute EventHandler onicecandidateerror;
attribute EventHandler onsignalingstatechange;
attribute EventHandler oniceconnectionstatechange;
attribute EventHandler onicegatheringstatechange;
attribute EventHandler onconnectionstatechange;
// レガシーインターフェイス拡張
// 本節のメソッドをサポートするかどうかは任意である。
// これらのメソッドをサポートする場合
// 定義されたとおりに実装しなければならない
// 「Legacy Interface Extensions」節で
Promise<undefined> createOffer(RTCSessionDescriptionCallback successCallback,
RTCPeerConnectionErrorCallback failureCallback,
optional RTCOfferOptions options = {});
Promise<undefined> setLocalDescription(RTCLocalSessionDescriptionInit description,
VoidFunction successCallback,
RTCPeerConnectionErrorCallback failureCallback);
Promise<undefined> createAnswer(RTCSessionDescriptionCallback successCallback,
RTCPeerConnectionErrorCallback failureCallback);
Promise<undefined> setRemoteDescription(RTCSessionDescriptionInit description,
VoidFunction successCallback,
RTCPeerConnectionErrorCallback failureCallback);
Promise<undefined> addIceCandidate(RTCIceCandidateInit candidate,
VoidFunction successCallback,
RTCPeerConnectionErrorCallback failureCallback);
};
localDescription
の型は RTCSessionDescription,
readonly,
nullable
localDescription
属性は
[[PendingLocalDescription]]
が null でない場合それを返し、そうでない場合は
[[CurrentLocalDescription]]
を返さなければならない (MUST)。
注意:
[[CurrentLocalDescription]].sdp
と
[[PendingLocalDescription]].sdp
は、対応する sdp 値を
setLocalDescription
呼び出しに渡した文字列と逐語的に同一である必要はない (SDP がパースされ再整形されることや、ICE candidate が追加されることがある)。
currentLocalDescription
の型は RTCSessionDescription,
readonly,
nullable
currentLocalDescription
属性は
[[CurrentLocalDescription]]
を返さなければならない (MUST)。
これは RTCPeerConnection が最後に
stable 状態へ遷移した時に
正常にネゴシエートされたローカル記述と、その offer または answer が作成されて以後
ICE Agent
によって生成されたすべてのローカル candidate を合わせたものを表す。
pendingLocalDescription
の型は RTCSessionDescription,
readonly,
nullable
pendingLocalDescription
属性は
[[PendingLocalDescription]]
を返さなければならない (MUST)。
これはネゴシエーション中のローカル記述と、その offer または answer が作成されて以後
ICE Agent により生成された
すべてのローカル candidate を含んだものを表す。RTCPeerConnection が
stable 状態にある場合、この値は null である。
remoteDescription
の型は RTCSessionDescription,
readonly,
nullable
remoteDescription
属性は
[[PendingRemoteDescription]]
が null でない場合それを返し、そうでない場合は
[[CurrentRemoteDescription]]
を返さなければならない (MUST)。
注意:
[[CurrentRemoteDescription]].sdp
と
[[PendingRemoteDescription]].sdp
は、対応する
sdp 値を
setRemoteDescription
呼び出しに渡した文字列と逐語的に同一である必要はない (SDP がパースされ再整形されることや、ICE candidate が追加されることがある)。
currentRemoteDescription
の型は RTCSessionDescription,
readonly,
nullable
currentRemoteDescription
属性は
[[CurrentRemoteDescription]]
を返さなければならない (MUST)。
これは
RTCPeerConnection が最後に
stable 状態へ遷移した時に
正常にネゴシエートされた最新のリモート記述と、その offer または answer が作成されて以後
addIceCandidate()
により供給されたすべてのリモート candidate を合わせたものを表す。
pendingRemoteDescription
の型は RTCSessionDescription,
readonly,
nullable
pendingRemoteDescription
属性は
[[PendingRemoteDescription]]
を返さなければならない (MUST)。
これはネゴシエーション中のリモート記述と、その offer または answer が作成されて以後
addIceCandidate()
によって供給されたすべてのリモート candidate を含むものを表す。RTCPeerConnection が
stable 状態にある場合、この値は null である。
signalingState の型は
RTCSignalingState,
readonly
signalingState
属性は
RTCPeerConnection
オブジェクトの
[[SignalingState]]
を返さなければならない (MUST)。
iceGatheringState
の型は RTCIceGatheringState,
readonly
iceGatheringState
属性は
RTCPeerConnection
オブジェクトの
[[IceGatheringState]]
を返さなければならない (MUST)。
iceConnectionState
の型は RTCIceConnectionState,
readonly
iceConnectionState
属性は
RTCPeerConnection
オブジェクトの
[[IceConnectionState]]
を返さなければならない (MUST)。
connectionState
の型は RTCPeerConnectionState,
readonly
connectionState
属性は
RTCPeerConnection
オブジェクトの
[[ConnectionState]]
を返さなければならない (MUST)。
canTrickleIceCandidates の型は
boolean, readonly, nullable
canTrickleIceCandidates
属性はリモートピアが trickle ICE candidate
[RFC8838]
を受け入れ可能かどうかを示す。この値はリモート記述が
[RFC9429]
(section
4.1.17.) に定義されるとおり trickle ICE サポートを示しているかどうかに基づき決定される。
setRemoteDescription
の完了前は、この値は null である。
onnegotiationneeded の型は
EventHandler
negotiationneeded である。
onicecandidate の型は EventHandler
icecandidate である。
onicecandidateerror の型は
EventHandler
icecandidateerror である。
onsignalingstatechange の型は
EventHandler
signalingstatechange である。
oniceconnectionstatechange の型は
EventHandler
iceconnectionstatechange
である
onicegatheringstatechange の型は
EventHandler
icegatheringstatechange
である。
onconnectionstatechange の型は
EventHandler
connectionstatechange
である。
createOffer
createOffer
メソッドは、このセッションでサポートされる
構成を含む RFC 3264 オファーを格納した SDP の blob を生成する。これには、
この
RTCPeerConnectionに接続されたローカルのMediaStreamTrackの記述、この実装がサポートする
コーデック/RTP/RTCP 機能、およびICE エージェントと DTLS
接続のパラメーターが含まれる。
生成されるオファーをさらに制御するために、
optionsパラメーターを指定できる。
システムのリソースが限られている場合(たとえば、デコーダーの数が有限である場合)、
createOffer
はシステムの現在の状態を反映したオファーを返す必要があり、それによって
setLocalDescription
がそれらのリソースを取得しようとしたときに成功するようにする。
セッション記述は、返された Promise の履行
コールバックが少なくとも終了するまでは、エラーを発生させることなくsetLocalDescription
で使用可能な状態を維持しなければならない(MUST)。
SDP の作成は、[RFC9429] に記述された
オファー生成の適切なプロセスに従わなければならない(MUST)。ただし、この場合、
ユーザーエージェントは RFC9429 の目的上、stopping
状態のトランシーバーをstoppedとして扱わなければならない(MUST)。
オファーとして、生成される SDP には、
セッションがサポートまたは優先するコーデック/RTP/RTCP 機能の完全な集合が含まれる
(使用する特定のネゴシエーション済みサブセットのみを含むアンサーとは対照的である)。
セッション確立後に
createOfferが
呼び出された場合、
createOffer
は現在のセッションと互換性のあるオファーを生成し、
トラックの追加や削除など、前回の完全な
オファー・アンサー交換以降にセッションへ加えられた変更を
組み込む。変更が加えられていない場合、オファーには
現在のローカル記述の機能に加えて、
更新されたオファーでネゴシエーション可能な追加機能も
含まれる。
生成される SDP には、ICE
エージェントの
usernameFragment、
passwordおよび ICE
オプション([RFC5245]
の
14節で定義されている)も含まれ、エージェントが収集した
任意のローカル候補も含まれることがある。
certificates
の
configuration内の値は、RTCPeerConnection
に対してアプリケーションが構成した証明書を
RTCPeerConnectionに提供する。これらの
証明書は、任意のデフォルト証明書とともに
証明書フィンガープリントの集合を生成するために使用される。
これらの証明書フィンガープリントは
SDP の構築に使用される。
SDP を生成するプロセスは、基盤となるシステムの
メディア機能の一部を公開し、これはデバイスに関する
一般に永続的なオリジン横断情報を提供する。
したがって、アプリケーションのフィンガープリンティング面を
拡大する。プライバシーに敏感な状況では、ブラウザーは
機能の共通サブセットのみに一致する SDP を生成するなどの
緩和策を検討できる。
メソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、新たに作成されたInvalidStateErrorで
拒否された Promise を返す。
connectionを用いてオファーを 作成する結果を、 connectionの操作チェーンにチェーンする結果を返す。
connectionを与えてオファーを作成するには、 次の手順を実行する。
connection.[[SignalingState]]
が
"stable"
でも
"have-local-offer"
でもない場合、
新たに作成されたInvalidStateErrorで
拒否された
Promise を返す。
pを新しい Promise とする。
並行して、connectionと pを与えて、オファーを作成する 並行手順を開始する。
pを返す。
connectionと Promise pを与えた場合の オファーを作成する並行手順 は次のとおりである。
connectionが証明書の集合を用いて構築されておらず、 まだ証明書が生成されていない場合、 生成されるまで待つ。
[RFC9429] (4.1.8 節)に記述されているように、 オファーを生成するために必要な現在利用可能なリソースを 決定するため、オファー側のシステム状態 を検査する。
この検査が何らかの理由で失敗した場合、新たに作成された
OperationErrorで
pを拒否し、
これらの手順を中止する。
connectionとpを与えて、オファーを作成する 最終手順を実行するタスクをキューに入れる。
connectionと Promise pを与えた場合の オファーを作成する最終手順は 次のとおりである。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
connectionが、オファー側のシステム状態を 追加で検査する必要があるように変更されている場合、 並行して、connectionとpを与えて オファーを作成する 並行手順を再度開始し、これらの 手順を中止する。
RTCRtpTransceiver
のみがconnectionに追加されているときにcreateOffer
が呼び出されたものの、
オファーを作成する
並行手順の実行中に、映像の
RTCRtpTransceiver
が追加され、映像システムのリソースを
追加で検査する必要が生じた場合などに必要となることがある。
以前の検査から得られた情報、connectionの現在の状態
およびそのRTCRtpTransceiver群をもとに、
[RFC9429]
(5.2
節)に記述されているように、SDP オファー
sdpStringを生成する。
[RFC8843]
(7節)で説明されているように、
バンドルを使用する場合(RTCBundlePolicyを参照)、
BUNDLE グループをネゴシエーションするために、
オファー側タグ付き m= セクションを選択しなければならない。
ユーザーエージェントは、トランシーバーの集合のうち
最初の停止していないトランシーバーに対応する m= セクションを、
オファー側タグ付き m= セクションとして
選択しなければならない(MUST)。
これにより、リモートエンドポイントは
SDP を解析することなく、どのトランシーバーが
オファー側タグ付き m= セクションであるかを予測できる。
filteredCodecsを、
transceiver.[[PreferredCodecs]]
に次のフィルターを適用した結果とする。
フィルタリングはコーデック
優先設定の順序を変更してはならない(MUST NOT)。
kindをtransceiverの
[[Receiver]]の
[[ReceiverTrack]]の
kindとする。
transceiver.direction
が "sendonly"
または "sendrecv"
である場合、kindについての
実装済み送信コーデックの
リストに含まれないコーデックを除外する。
その際、コーデック
辞書一致
アルゴリズムを使用し、ignoreLevelsを
trueに設定する。
transceiver.direction
が "recvonly"
または "sendrecv"
である場合、kindについての
実装済み受信コーデックの
リストに含まれないコーデックを除外する。
その際、コーデック
辞書一致
アルゴリズムを使用し、ignoreLevelsを
trueに設定する。
メディア 記述に関連付けられたトランシーバー transceiverのコーデック優先設定は、 filteredCodecsが空でない場合はその値であるとし、 それ以外の場合は未設定であるとする。
RTCRtpSenderの
[[SendEncodings]]
スロットの長さが1より大きい場合、
RTCRtpSenderの
[[SendEncodings]]
に与えられた各エンコーディングについて、
対応するメディアセクションにa=rid send行を追加し、
encodings
フィールドに与えられた順序と同じ順序で RID を指定する
a=simulcast:send
行を追加する。RID
の制限は設定しない。
[RFC8853] の5.2節では、a=simulcast 行における RID の順序が、提案される優先順位を示すことを規定している。 ブラウザーがすべてのエンコーディングを送信しないことを 決定した場合、まずリストの最後のエンコーディングの 送信を停止すると予想される。
offerを、新たに作成した
RTCSessionDescriptionInit
辞書とし、その
type
メンバーを文字列 "offer" で初期化し、
sdp
メンバーを
sdpStringで初期化する。
[[LastCreatedOffer]]
内部スロットを
sdpStringに設定する。
offerでpを解決する。
createAnswer
createAnswer
メソッドは、リモート構成のパラメーターと互換性のある
セッションのサポート対象構成を含む
[SDP]
アンサーを生成する。
createOffer
と同様に、返される SDP の blob には、このRTCPeerConnectionに接続された
ローカルMediaStreamTrackの記述、
このセッションについてネゴシエーションされたコーデック/RTP/RTCP オプション、
およびICE エージェントによって
収集された任意の候補が含まれる。
生成されるアンサーをさらに制御するために、
optionsパラメーターを指定できる。
createOffer
と同様に、返される記述はシステムの現在の状態を
反映することが推奨される(SHOULD)。
セッション記述は、返された Promise の履行コールバックが少なくとも終了するまでは、
エラーを発生させることなくsetLocalDescription
で使用可能な状態を維持しなければならない(MUST)。
アンサーとして、生成される SDP には、 対応するオファーとともにメディアプレーンをどのように 確立するかを指定する特定のコーデック/RTP/RTCP 構成が含まれる。 SDP の生成は、 [RFC9429] に記述された アンサー生成の適切なプロセスに従わなければならない(MUST)。
生成される SDP には、ICE
エージェントの
usernameFragment、
passwordおよび ICE
オプション([RFC5245]
の
14節で定義されている)も含まれ、エージェントが収集した
任意のローカル候補も含まれることがある。
configuration内の
certificates
値は、RTCPeerConnection
に対してアプリケーションが構成した証明書を
RTCPeerConnectionに提供する。これらの
証明書は、任意のデフォルト証明書とともに
証明書フィンガープリントの集合を生成するために使用される。
これらの証明書フィンガープリントは
SDP の構築に使用される。
[RFC9429]
(4.1.10.1
節)に記述されているように、
typeを
"pranswer"
に設定することで、アンサーを暫定としてマークできる。
メソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、新たに作成されたInvalidStateErrorで
拒否された Promise を返す。
connectionを用いてアンサーを 作成する結果を、 connectionの操作チェーンにチェーンする結果を返す。
connectionを与えてアンサーを作成するには、 次の手順を実行する。
connection.[[SignalingState]]
が
"have-remote-offer"
でも
"have-local-pranswer"
でもない場合、
新たに作成されたInvalidStateErrorで
拒否された
Promise を返す。
pを新しい Promise とする。
並行して、connectionと pを与えて、アンサーを作成する 並行手順を開始する。
pを返す。
connectionと Promise pを与えた場合の アンサーを作成する 並行手順は 次のとおりである。
connectionが証明書の集合を用いて構築されておらず、 まだ証明書が生成されていない場合、 生成されるまで待つ。
[RFC9429] (4.1.9 節)に記述されているように、 アンサーを生成するために必要な現在利用可能なリソースを 決定するため、アンサー側のシステム状態 を検査する。
この検査が何らかの理由で失敗した場合、新たに作成された
OperationErrorで
pを拒否し、
これらの手順を中止する。
pを与えて、アンサーを作成する 最終手順を実行するタスクをキューに入れる。
Promise pを与えた場合の アンサーを作成する最終手順は 次のとおりである。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
connectionが、アンサー側のシステム状態を 追加で検査する必要があるように変更されている場合、 並行して、connectionとpを与えて アンサーを作成する 並行手順を再度開始し、これらの 手順を中止する。
RTCRtpTransceiverの
direction が
"recvonly"
のときにcreateAnswer
が呼び出されたものの、
アンサーを作成する
並行手順の実行中に direction が
"sendrecv"
に変更され、
映像エンコーディングリソースを追加で検査する必要が生じた場合などに必要となることがある。
以前の検査から得られた情報と、
connectionおよびそのRTCRtpTransceiver群の現在の状態をもとに、
[RFC9429]
(5.3
節)に記述されているように、
SDP アンサー sdpStringを生成する。
m= セクションに関連付けられたトランシーバーの
コーデック優先設定は、
.[[PreferredCodecs]]
に次のフィルタリングを適用した値であるとする
(または[[PreferredCodecs]]が空の場合は未設定であるとする)。
RTCRtpTransceiver
が
"directionsendrecv"
である場合、
.RTCRtpSender(kind).getCapabilities
と
codecs.RTCRtpReceiver(kind).getCapabilities
の共通部分に含まれないコーデックを除外する。
codecs
が
"direction"
である場合、
sendonly.RTCRtpSender(kind).getCapabilities
に含まれないコーデックを除外する。
codecs
が
"direction"
である場合、
recvonly.RTCRtpReceiver(kind).getCapabilities
に含まれないコーデックを除外する。
codecs
フィルタリングはコーデック優先設定の 順序を変更してはならない(MUST NOT)。
の[[SendEncodings]]
スロットの長さが1より大きい場合、
RTCRtpSender
の[[SendEncodings]]
に与えられた各エンコーディングについて、
対応する
メディアセクションにRTCRtpSendera=rid send行を追加し、
フィールドに与えられた順序と同じ順序で RID を指定する
encodingsa=simulcast:send行を追加する。RID
の制限は設定しない。
filteredCodecsを、
transceiver.[[PreferredCodecs]]
に次のフィルターを適用した結果とする。
フィルタリングはコーデック
優先設定の順序を変更してはならない(MUST NOT)。
kindをtransceiverの
[[Receiver]]の
[[ReceiverTrack]]の
kindとする。
transceiver.direction
が "sendonly"
または "sendrecv"
である場合、kindについての
実装済み送信コーデックの
リストに含まれないコーデックを除外する。
その際、コーデック
辞書一致
アルゴリズムを使用し、ignoreLevelsを
trueに設定する。
transceiver.direction
が "recvonly"
または "sendrecv"
である場合、kindについての
実装済み受信コーデックの
リストに含まれないコーデックを除外する。
その際、コーデック
辞書一致
アルゴリズムを使用し、ignoreLevelsを
trueに設定する。
メディア 記述に関連付けられたトランシーバー transceiverのコーデック優先設定は、 filteredCodecsが空でない場合はその値であるとし、 それ以外の場合は未設定であるとする。
これがサイマルキャストの受信を求めるオファーへのアンサーである場合、 サイマルキャストの受信を要求する各メディアセクションについて、 次の手順を実行する。
a=simulcast
属性に RID のカンマ区切りの代替候補が含まれている場合、
最初のもの以外をすべて削除する。
a=simulcast属性に
同じ名前の RID がある場合、
最初のもの以外をすべて削除する。RID
の制限は設定しない。
アンサーのメディアセクションから、対応するトランシーバーの
[[Sender]].[[SendEncodings]]
に見つからない RID をすべて除外する。
setRemoteDescription(offer)
が送信側の提案された
エンベロープを確立すると、
送信側の[[SendEncodings]]
は
"have-remote-offer"
で更新され、
ロールバック可能になる。しかし、送信側について
サイマルキャスト
エンベロープが確立された後は、
送信側の[[SendEncodings]]
の後続の削減は、このアンサーが
setLocalDescription
で設定されるときに行われる。
answerを、新たに作成した
RTCSessionDescriptionInit
辞書とし、その
type
メンバーを文字列 "answer" で初期化し、
sdp
メンバーを
sdpStringで初期化する。
[[LastCreatedAnswer]]
内部スロットを
sdpStringに設定する。
answerでpを解決する。
setLocalDescription
setLocalDescription
メソッドは、
RTCPeerConnectionに、
指定された
RTCLocalSessionDescriptionInit
をローカル
記述として適用するよう指示する。
この API はローカルメディア状態を変更する。
アプリケーションが、あるメディア形式から別の互換性のない形式へ
変更することを提案しようとするシナリオを正常に処理するため、
RTCPeerConnectionは、
最終アンサーを受信するまで、現在のローカル記述と
保留中のローカル記述の両方を同時に使用できるよう
サポートしなければならない(MUST)(たとえば、両方の記述に存在するコーデックをサポートする)。
最終アンサーを受信した時点で、RTCPeerConnectionは
保留中のローカル記述を完全に採用できる。または、
リモート側が変更を拒否した場合は現在の
記述へロールバックできる。
記述を渡すことは任意である。省略した場合、
setLocalDescription
は必要に応じて暗黙的にオファーを作成するか、
アンサーを作成する。
[RFC9429]
(5.4
節)で述べられているように、
SDP を含む記述が渡された場合、その SDP は、
createOfferまたは
createAnswerから返された時点から
変更されていてはならない。
メソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
descriptionをメソッドの第1引数とする。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
sdpを
description.sdp
とする。
次の手順を connectionの操作チェーンにチェーンする結果を返す。
typeを、
description.type
が存在する場合はその値とし、存在せず、
connection.[[SignalingState]]
が "stable"、
"have-local-offer"、
または
"have-remote-pranswer"
のいずれかである場合は
"offer"
とし、それ以外の場合は
"answer"
とする。
typeが "offer"
であり、
sdpが空文字列ではなく、かつ
connection.[[LastCreatedOffer]]
と等しくない場合、新たに
作成された
InvalidModificationError
で拒否された Promise
を返し、
これらの手順を中止する。
typeが "answer"
または
"pranswer"
であり、sdpが
空文字列ではなく、かつ
connection.[[LastCreatedAnswer]]
と等しくない場合、新たに
作成された
InvalidModificationError
で拒否された Promise
を返し、
これらの手順を中止する。
sdpが空文字列であり、
typeが "offer"
である場合、次の
サブ手順を実行する。
sdpを
connection.[[LastCreatedOffer]]
の値に設定する。
sdpが空文字列である場合、または connectionのオファー側の システム状態を もはや正確に表していない場合、pを connectionを用いてオファーを 作成する結果とし、 pに対して、最初の引数で示されるローカル セッション記述を設定する履行手順を用いて 反応する結果を返す。
sdpが空文字列であり、
typeが "answer"
または
"pranswer"
である場合、次の
サブ手順を実行する。
sdpを
connection.[[LastCreatedAnswer]]
の値に設定する。
sdpが空文字列である場合、または connectionのアンサー側の システム状態を もはや正確に表していない場合、pを connectionを用いてアンサーを 作成する結果とし、 pに対して次の 履行手順を用いて 反応する結果を返す。
answerを、これらの履行手順への 第1引数とする。
{type,
answer.
で示されるローカル
セッション記述を設定する結果を返す。
sdp}
{type, sdp}で示されるローカルセッション
記述を設定する結果を返す。
[RFC9429] (5.9 節)で述べられているように、この メソッドを呼び出すと、ICE エージェントによる ICE 候補収集プロセスが開始されることがある。
setRemoteDescription
setRemoteDescription
メソッドは、
RTCPeerConnectionに、
指定された
RTCSessionDescriptionInit
をリモートオファーまたは
アンサーとして適用するよう指示する。この API はローカルメディア状態を変更する。
メソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
descriptionをメソッドの第1 引数とする。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
次の手順を connectionの操作チェーンにチェーンする結果を返す。
もし
description.type
が "offer"
であり、
かつ
[RFC9429]
(5.5
節および5.6
節)で説明されているように、
現在の
connection.[[SignalingState]]
に対して無効である場合、
次のサブステップを実行する。
pを、
{type:
"
で示されるローカル
セッション記述を設定する結果とする。
rollback"}
pに対して、descriptionを リモート セッション記述として設定する履行手順を用いて 反応する結果を返し、 これらの手順を中止する。
descriptionをリモートセッション 記述として設定する結果を返す。
addIceCandidate
addIceCandidate
メソッドは、リモート候補を
ICE エージェントに提供する。このメソッドは、
candidateメンバーに
空文字列を指定して呼び出すことで、
リモート候補の終端を示すためにも使用できる。
このメソッドが使用する引数のメンバーは、
candidate、sdpMid、
sdpMLineIndex、
および
usernameFragment
のみであり、残りは無視される。
メソッドが呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
candidateをメソッドの引数とする。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
candidate.candidate
が空文字列ではなく、かつ
candidate.sdpMidと
candidate.sdpMLineIndex
の両方がnullである場合、新たに作成されたTypeErrorで
拒否された
Promise を返す。
次の手順を connectionの操作チェーンにチェーンする結果を返す。
remoteDescription
が
nullである場合、新たに作成された
InvalidStateErrorで
拒否された
Promise を返す。
candidate.sdpMid
がnullでない場合、次の手順を実行する。
candidate.sdpMid
が、
remoteDescription
内のいずれのメディア記述の mid とも等しくない場合、
新たに作成されたOperationErrorで
拒否された
Promise を返す。
それ以外の場合、candidate.sdpMLineIndex
がnullでなければ、次の手順を実行する。
candidate.sdpMLineIndex
が
remoteDescription
内のメディア記述の数以上である場合、
新たに作成されたOperationErrorで
拒否された
Promise を返す。
candidate.sdpMid
または
candidate.sdpMLineIndex
のいずれかが、
remoteDescription
内の、関連付けられたトランシーバーがstoppedである
メディア記述を示している場合、
undefinedで解決された
Promise を返す。
candidate.usernameFragment
がnullでなく、かつ、適用されたリモート
記述の対応するメディア
記述内に存在するいずれの username fragment とも等しくない場合、
新たに作成されたOperationErrorで
拒否された Promise
を返す。
pを新しい Promise とする。
並行して、候補が管理上
禁止されていない場合、
[RFC9429]
(4.1.19
節)に記述されているように、
ICE 候補candidateを追加する。
ICE の世代を識別するために
candidate.usernameFragment
を使用する。
usernameFragment
が
nullである場合、candidateを
最新の ICE 世代について処理する。
candidate.candidate
が空文字列である場合、candidateを、
対応するメディア記述と
ICE 候補世代に対する
候補終端の指示として処理する。
candidate.sdpMid
と
candidate.sdpMLineIndex
の両方がnullである場合、この候補終端
の指示はすべてのメディア記述に適用される。
candidateを正常に 追加できなかった場合、ユーザーエージェントは 次の手順を実行するタスクをキューに入れなければならない(MUST)。
connection.[[IsClosed]]
がtrueである場合、これらの
手順を中止する。
新たに作成されたOperationError
でpを拒否し、
これらの手順を中止する。
candidateが正常に適用された場合、 または候補が管理上 禁止されていた場合、ユーザーエージェントは 次の手順を実行するタスクをキューに入れなければならない (MUST)。
connection.[[IsClosed]]
がtrueである場合、これらの
手順を中止する。
connection.[[PendingRemoteDescription]]
がnullでなく、
candidateが処理された ICE
世代を表す場合、
candidateを
connection.[[PendingRemoteDescription]].sdp
に追加する。
connection.[[CurrentRemoteDescription]]
がnullでなく、
candidateが処理された ICE
世代を表す場合、
candidateを
connection.[[CurrentRemoteDescription]].sdp
に追加する。
undefinedで
pを解決する。
pを返す。
UA がこのアドレスへの接続試行を許可しないと 決定した場合、候補は管理上禁止されている。
プライバシー上の理由から、 アドレス/ポートがブロックされているかどうかについて 開発者に示される情報はなく、 そのアドレスから応答がなかった場合とまったく同じように動作する。
UA は、[Fetch] の不正なポートをブロックするリストにあるアドレスへの 接続を禁止しなければならず(MUST)、 その他のアドレスへの接続を 禁止することを選択してもよい(MAY)。
RTCConfigurationの
iceTransportPolicy
メンバーが
relay
である場合、mDNS 候補や DNS
候補など、外部での名前解決を必要とする候補は禁止されなければならない(MUST)。
WebIDL 処理により、
addIceCandidate(null)
はデフォルト辞書が存在する呼び出しとして
解釈される。これは上記のアルゴリズムでは、すべてのメディア記述と
ICE 候補世代について候補の終端を示す。
これはレガシー上の理由から意図された設計である。
restartIce
restartIce
メソッドは、ICE を再起動すべきことをRTCPeerConnection
に通知する。後続の
createOffer
呼び出しは、[RFC5245]
の9.1.1.1節に記述されているように、
ICE を再起動する記述を作成する。
このメソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
connectionを、メソッドが呼び出されたRTCPeerConnection
とする。
connection.[[LocalIceCredentialsToReplace]]
を空にし、
connection.[[CurrentLocalDescription]]
内に見つかるすべての ICE 資格情報
([RFC5245]
の15.4節で定義される ice-ufrag および
ice-pwd)と、
connection.[[PendingLocalDescription]]
内に見つかるすべての ICE 資格情報を
そこに格納する。
connectionについてネゴシエーション必要 フラグを更新する。
getConfiguration
このRTCPeerConnectionオブジェクトの
現在の構成を表すRTCConfigurationオブジェクトを
返す。
このメソッドが呼び出された場合、ユーザーエージェントは、
[[Configuration]]内部
スロットに格納された
RTCConfigurationオブジェクトを
返さなければならない(MUST)。
setConfiguration
setConfiguration
メソッドは、この
RTCPeerConnection
オブジェクトの構成を更新する。
これには、ICE
エージェントの構成の変更も含まれる。
[RFC9429]
(3.5.1
節)で述べられているように、
ICE の構成が新たな収集フェーズを必要とするように
変更された場合、ICE の再起動が必要となる。
setConfiguration
メソッドが呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
connectionを、メソッドが呼び出されたRTCPeerConnection
とする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを
投げる。
configurationによって指定された構成を 設定する。
close
closeメソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
falseを用いて接続を閉じる。
connectionとdisappearブール値を与えた場合の 接続を閉じるアルゴリズムは、 次のとおりである。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
connection.[[IsClosed]]を
trueに設定する。
connection.[[SignalingState]]
を
"closed"
に設定する。
これはいかなるイベントも発火しない。
transceiversを、
CollectTransceivers
アルゴリズムを実行した結果とする。
transceivers内のすべての
RTCRtpTransceiver
transceiverについて、
次の手順を実行する。
transceiver.[[Stopped]]が
trueである場合、これらのサブ手順を中止する。
transceiverとdisappearを用いて RTCRtpTransceiver を 停止する。
connectionの各RTCDataChannelの
[[ReadyState]]スロットを
"closed"
に設定する。
RTCDataChannel群は
即座に閉じられ、
クローズ手続きは呼び出されない。
connection.[[SctpTransport]]が
nullでない場合、SCTP ABORT チャンクを送信して
基盤となる SCTP
アソシエーションを破棄し、
[[SctpTransportState]]
を
"closed"
に設定する。
connectionの各RTCDtlsTransportの
[[DtlsTransportState]]
スロットを
"closed"
に設定する。
connectionのICE エージェントを破棄し、 アクティブな ICE 処理を即座に終了して、 関連するリソース(たとえば TURN 権限)を解放する。
connectionの各RTCIceTransportの
[[IceTransportState]]
スロットを
"closed"
に設定する。
connection.[[IceConnectionState]]
を "closed"
に設定する。
これはいかなるイベントも
発火しない。
connection.[[ConnectionState]]
を
"closed"
に設定する。
これはいかなるイベントも
発火しない。
RTCPeerConnection
インターフェイスの主たる定義の中に含まれている。
本節のメソッドをサポートするかどうかは任意である。しかし、サポートする場合はここで規定されるとおりに実装することが必須である。
RTCPeerConnection 上に存在した
addStream メソッドは次のように容易にポリフィルできる:
RTCPeerConnection.prototype.addStream = function(stream) {
stream.getTracks().forEach((track) => this.addTrack(track, stream));
};
createOffer
createOffer
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない (MUST):
successCallback をメソッドの第一引数とする。
failureCallback をメソッド第二引数で示されるコールバックとする。
options をメソッド第三引数で示されるコールバックとする。
RTCPeerConnection
の
createOffer()
メソッドを options を唯一の引数として実行し、結果の Promise を p とする。
p が fulfillment し値 offer を得たとき、successCallback を offer を引数として呼び出す。
p が理由 r で rejection したとき、 failureCallback を r を引数として呼び出す。
undefined で resolved された Promise を返す。
setLocalDescription
setLocalDescription
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない (MUST):
description をメソッドの第一引数とする。
successCallback をメソッド第二引数で示されるコールバックとする。
failureCallback をメソッド第三引数で示されるコールバックとする。
RTCPeerConnection
の
setLocalDescription
メソッドを description を唯一の引数として実行し、結果の Promise を p
とする。
p が fulfillment したとき、
successCallback を undefined を引数として呼び出す。
p が理由 r で rejection したとき、 failureCallback を r を引数として呼び出す。
undefined で resolved された Promise を返す。
createAnswer
createAnswer メソッドは
RTCAnswerOptions
引数を取らない。
これは既知のレガシー実装においてこのオプションがサポートされた例が存在しなかったためである。
createAnswer
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない (MUST):
successCallback をメソッドの第一引数とする。
failureCallback をメソッド第二引数で示されるコールバックとする。
RTCPeerConnection
の
createAnswer()
メソッドを引数なしで実行し、結果の Promise を p とする。
p が fulfillment し値 answer を得たとき、successCallback を answer を引数として呼び出す。
p が理由 r で rejection したとき、 failureCallback を r を引数として呼び出す。
undefined で resolved された Promise を返す。
setRemoteDescription
setRemoteDescription
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない (MUST):
description をメソッドの第一引数とする。
successCallback をメソッド第二引数で示されるコールバックとする。
failureCallback をメソッド第三引数で示されるコールバックとする。
RTCPeerConnection
の
setRemoteDescription
メソッドを description を唯一の引数として実行し、結果の Promise を p
とする。
p が fulfillment
したとき、
successCallback を undefined を引数として呼び出す。
p が理由 r で rejection したとき、 failureCallback を r を引数として呼び出す。
undefined で resolved された Promise を返す。
addIceCandidate
addIceCandidate
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行しなければならない (MUST):
candidate をメソッドの第一引数とする。
successCallback をメソッド第二引数で示されるコールバックとする。
failureCallback をメソッド第三引数で示されるコールバックとする。
RTCPeerConnection
の
addIceCandidate()
メソッドを candidate を唯一の引数として実行し、結果の Promise を p とする。
p が fulfillment
したとき、
successCallback を undefined を引数として呼び出す。
p が理由 r で rejection したとき、 failureCallback を r を引数として呼び出す。
undefined で resolved された Promise を返す。
これらのコールバックはレガシー API でのみ使用される。
WebIDLcallback RTCPeerConnectionErrorCallback = undefined (DOMException error);
RTCPeerConnectionErrorCallback
のパラメータ
error (型:
DOMException)
WebIDLcallback RTCSessionDescriptionCallback = undefined (RTCSessionDescriptionInit description);
RTCSessionDescriptionCallback
のパラメータ
RTCSessionDescriptionInit)
この節は、RTCPeerConnection に追加されたメディアに加え、offer
の生成方法に影響を与えるために使用され得る一連のレガシー拡張を記述する。開発者は代わりに
RTCRtpTransceiver API
の使用が推奨される。
createOffer
が本節で規定される任意のレガシーオプション付きで呼び出された場合、通常の
createOffer
手順ではなく以下の手順を実行する:
options をメソッドの第一引数とする。
connection を現在の
RTCPeerConnection オブジェクトとする。
options 内の 各 offerToReceive<Kind> メンバ (種別
kind) について、次を実行する:
transceiver
kind kind の停止していない
"sendrecv"
トランシーバそれぞれについて、
transceiver.[[Direction]]
を
"sendonly"
に設定する。
transceiver
kind kind の停止していない
"recvonly"
トランシーバそれぞれについて、
transceiver.[[Direction]] を
"inactive"
に設定する。
次のオプションへ進む (あれば)。
connection が
"sendrecv"
または
"recvonly"
の停止していないトランシーバ (種別
transceiver kind
kind)
を持つなら、次のオプションへ進む (あれば)。
transceiver を
connection.addTransceiver(kind)
と等価な呼び出しの結果とする。ただしこの操作は
negotitation-needed
フラグを更新してはならない (MUST NOT)。
直前の操作がエラーを投げた結果 transceiver が未設定である場合、これらの手順を中止する。
transceiver.[[Direction]] を
"recvonly"
に設定する。
createOffer
により規定される手順を実行して offer を生成する。
WebIDLpartial dictionary RTCOfferOptions {
boolean offerToReceiveAudio;
boolean offerToReceiveVideo;
};
offerToReceiveAudio (型:
boolean)
この設定は音声の方向性に対し追加の制御を提供する。例えば音声を送信するかどうかに関わらず音声を受信可能であることを保証するために利用できる。
offerToReceiveVideo (型:
boolean)
この設定は映像の方向性に対し追加の制御を提供する。例えば映像を送信するかどうかに関わらず映像を受信可能であることを保証するために利用できる。
任意のイベントがそのオブジェクト上のイベントハンドラを発火させ得る限り、
RTCPeerConnection
オブジェクトはガーベジコレクションされてはならない (MUST not)。オブジェクトの
[[IsClosed]] 内部スロットが
true のとき、そのようなイベントハンドラは発火し得ず、そのため当該オブジェクトをガーベジコレクションしても安全である。
RTCPeerConnection に接続されているすべての
RTCDataChannel および
MediaStreamTrack オブジェクトは、
その RTCPeerConnection オブジェクトへの強参照を保持する。
Promise を返すすべてのメソッドは、Promise の標準的なエラー処理規則に従う。Promise を返さないメソッドは、エラーを示すために例外を投げる場合がある。
RTCSdpType 列挙は
RTCSessionDescriptionInit、
RTCLocalSessionDescriptionInit、
あるいは RTCSessionDescription インスタンスの種類を表す。
WebIDLenum RTCSdpType {
"offer",
"pranswer",
"answer",
"rollback"
};
| 列挙値 | 説明 |
|---|---|
offer
|
" |
pranswer
|
" |
answer
|
" |
rollback
|
" |
RTCSessionDescription クラスは
RTCPeerConnection
によってローカルおよびリモートのセッション記述を公開するために用いられる。
WebIDL[Exposed=Window]
interface RTCSessionDescription {
constructor(RTCSessionDescriptionInit descriptionInitDict);
readonly attribute RTCSdpType type;
readonly attribute DOMString sdp;
[Default] RTCSessionDescriptionInit toJSON();
};
constructor()
RTCSessionDescription()
コンストラクタは辞書引数 description を受け取り、その内容で新しい
RTCSessionDescription
オブジェクトを初期化する。このコンストラクタは非推奨であり、レガシー互換性のためだけに存在する。
type (型: RTCSdpType), readonly
sdp (型: DOMString), readonly, 既定値 ""
toJSON()
WebIDLdictionary RTCSessionDescriptionInit {
required RTCSdpType type;
DOMString sdp = "";
};
type (型: RTCSdpType), required
sdp (型: DOMString)
type が
"rollback" の場合、このメンバーは使用されない。
WebIDLdictionary RTCLocalSessionDescriptionInit {
RTCSdpType type;
DOMString sdp = "";
};
type (型: RTCSdpType)
setLocalDescription
は RTCPeerConnection の
[[SignalingState]] に基づいて型を推論する。
sdp (型: DOMString)
type が
"rollback" の場合、このメンバーは使用されない。
RTCPeerConnection
の状態に対する多くの変更は、望む効果を得るためにシグナリングチャネルを介したリモート側との通信を必要とする。アプリはいつシグナリングが必要かについて、negotiationneeded イベントを監視することで把握できる。このイベントは、接続の
negotiation-needed フラグ の状態に従って発火し、これは [[NegotiationNeeded]] 内部スロットで表される。
この節は規範的ではない (non-normative)。
シグナリングを必要とする操作が RTCPeerConnection
に対して行われた場合、接続はネゴシエーションが必要とマークされる。例として、RTCRtpTransceiver の追加または停止、あるいは最初の RTCDataChannel
の追加などが含まれる。
実装内部での変更によっても接続がネゴシエーション必要状態とマークされることがある。
negotiation-needed フラグの更新 の正確な手順は後述で規定されている点に注意。
この節は規範的ではない (non-normative)。
ネゴシエーション必要フラグは、型が
"answer" のセッション記述が正常に設定され、かつ指定された記述が
現在
RTCPeerConnection上に存在する
RTCRtpTransceiver群および
RTCDataChannel群の状態と
一致する場合にクリアされる。具体的には、これはすべての
stoppedでないトランシーバーに、一致する
プロパティを持つローカル記述内の関連付けられたセクションが存在し、さらにデータチャネルが作成されている場合は、
ローカル記述内にデータ
セクションが存在することを意味する。
ネゴシエーション必要フラグを 更新するための正確な手順は、以下で規定されていることに注意されたい。
以下の処理は本仕様書内の他の箇所から参照されたときに発生する。また、ネゴシエーションに影響する実装内部の変更の結果として発生することもある。そのような変更が起きた場合、ユーザーエージェントは MUST negotiation-needed フラグを更新 しなければならない。
negotiation-needed フラグを更新 するために connection について以下の手順を実行する:
connection.[[Operations]] の長さが 0 でないなら、
connection.[[UpdateNegotiationNeededFlagOnEmptyChain]]
を true に設定し、これらの手順を中止する。
次の手順を実行するタスクをキューする:
connection.[[IsClosed]] が
true なら、これらの手順を中止する。
connection.[[Operations]] の長さが
0 でないなら、
connection.[[UpdateNegotiationNeededFlagOnEmptyChain]]
を true に設定し、これらの手順を中止する。
connection.[[SignalingState]] が
"stable"
でないなら、これらの手順を中止する。
negotiation-needed フラグ は状態が
"stable"
に遷移した際、
セッション記述を 設定する 手順の一部として更新される。
ネゴシエーションが必要かの確認 の結果が
false なら、
negotiation-needed フラグをクリア するため
connection.[[NegotiationNeeded]] を
false に設定し、これらの手順を中止する。
connection.[[NegotiationNeeded]] が既に
true の場合、これらの手順を中止する。
connection.[[NegotiationNeeded]] を
true に設定する。
Fire an event 名 negotiationneeded を
connection で発火させる。
タスクのキューイングにより、複数の connection への変更が同時に行われている一般的な状況で
negotiationneeded
が早期に発火することを防ぐ。
さらに、negotiationneeded は operations chain
が空のときのみ発火させることでネゴシエーションメソッドとの競合を避ける。
ネゴシエーションが必要かの確認 を connection について行うには、以下の確認を実施する:
節冒頭で述べたような実装依存のネゴシエーションが必要な場合、true を返す。
connection.[[LocalIceCredentialsToReplace]]
が空でないなら true を返す。
description を
connection.[[CurrentLocalDescription]]
とする。
connection が任意の RTCDataChannel を作成しており、かつ
description 内にデータ用の m= セクションがまだネゴシエートされていないなら
true を返す。
connection の set of transceivers 内の各 transceiver について以下を確認する:
transceiver.[[Stopping]] が
true かつ
transceiver.[[Stopped]] が
false なら true を返す。
transceiver が stopped ではなく、かつ
description 内の m= セクションとまだ associated していないなら true を返す。
transceiver が stopped でなく、かつ
description の m= セクションと associated している場合、次を確認する:
transceiver.[[Direction]]が
"sendrecv"
または
"sendonly"
であり、かつdescription内の関連付けられた m=
セクションが、
単一のa=msid行を含まないか、または
このm=セクション内の
a=msid行から得られる MSID の数、
あるいは MSID の値
自体が、
transceiver.sender.[[AssociatedMediaStreamIds]]内のものと異なる場合、
trueを返す。
descriptionの型が
"offer"であり、かつ
connection.[[CurrentLocalDescription]]
と
connection.[[CurrentRemoteDescription]]
のいずれにおいても、関連付けられた m=
セクションの方向が
transceiver.[[Direction]]と一致しない場合、
trueを返す。この手順では、
[[CurrentRemoteDescription]]内で見つかった方向と
方向を比較する場合、記述の
方向は、ピアの
視点を表すために反転しなければならない。
descriptionの型が
"answer"であり、かつ
description内の関連付けられた m=
セクションの方向が
transceiver.[[Direction]]
とオファーされた方向との共通部分(
[RFC9429]
(5.3.1
節)で説明されているもの)
に一致しない場合、
trueを返す。
transceiver が stopped で、m= セクションと associated しているが、
その m= セクションがまだ
connection.[[CurrentLocalDescription]]
または
connection.[[CurrentRemoteDescription]]
で拒否されていないなら true を返す。
以上の確認を行っても true が返されなかった場合、ネゴシエーションすべきものは残っていないので false を返す。
このインターフェイスは [RFC5245]
セクション 2 で記述される ICE candidate を表す。
candidate,
sdpMid,
sdpMLineIndex および
usernameFragment 以外の属性は、
candidateInitDict 内の candidate
メンバを(正しく構成されていれば)パースすることで導出される。
[Exposed=Window]
interface RTCIceCandidate {
constructor(optional RTCIceCandidateInit candidateInitDict = {});
readonly attribute DOMString candidate;
readonly attribute DOMString? sdpMid;
readonly attribute unsigned short? sdpMLineIndex;
readonly attribute DOMString? foundation;
readonly attribute RTCIceComponent? component;
readonly attribute unsigned long? priority;
readonly attribute DOMString? address;
readonly attribute RTCIceProtocol? protocol;
readonly attribute unsigned short? port;
readonly attribute RTCIceCandidateType? type;
readonly attribute RTCIceTcpCandidateType? tcpType;
readonly attribute DOMString? relatedAddress;
readonly attribute unsigned short? relatedPort;
readonly attribute DOMString? usernameFragment;
readonly attribute RTCIceServerTransportProtocol? relayProtocol;
readonly attribute DOMString? url;
RTCIceCandidateInit toJSON();
};
constructor()
RTCIceCandidate()
コンストラクターは
辞書引数 candidateInitDict を受け取り、
その内容を使用して新しい
RTCIceCandidate
オブジェクトを初期化する。
呼び出された場合、次の手順を実行する。
sdpMid と
sdpMLineIndex
メンバーの両方が
null である場合、投げる、TypeError を。
candidateInitDict を用いてRTCIceCandidate を 作成する 結果を返す。
candidateInitDict 辞書を用いてRTCIceCandidate を 作成するには、次の手順を実行する。
RTCIceCandidate
オブジェクトとする。
null で初期化する。
foundation、
component、priority、address、
protocol、port、type、tcpType、
relatedAddress、
および relatedPort。
candidate、sdpMid、
sdpMLineIndex、
usernameFragment。
candidate
辞書メンバーとする。candidate が
空文字列でない場合、次の手順を実行する。
candidate-attribute
文法を使用して candidate を構文解析する。
candidate-attribute
の構文解析に失敗した場合、
これらの手順を中止する。
RTCIceCandidate
のコンストラクターは、
candidateInitDict 内の辞書メンバーについて基本的な
構文解析と型チェックのみを行う。
candidate、
sdpMid、
sdpMLineIndex、
usernameFragment
と対応するセッション記述との
適格性に関する詳細な検証は、
RTCIceCandidate
オブジェクトを
addIceCandidate()
に渡す際に行われる。
後方互換性を維持するため、
candidate 属性の構文解析時のエラーはすべて無視される。その
場合、candidate
属性は、
candidateInitDict で指定された未処理の
candidate
文字列を保持するが、
foundation、
priority
などの派生属性は
null に設定される。
以下のほとんどの属性は [RFC5245] セクション 15.1 で定義される。
candidate 型 DOMString、readonly
candidate-attribute
を保持する。
この RTCIceCandidate が
end-of-candidates 指示または peer reflexive リモート candidate を表す場合、
candidate
は空文字列となる。
sdpMid 型 DOMString、readonly、nullable
null でない場合、これは該当候補が関連付けられるメディアコンポーネントの
[RFC5888]
で定義された
メディアストリーム "identification-tag" を含む。
sdpMLineIndex 型
unsigned short、readonly、nullable
null でない場合、候補が対応する SDP 内の
media description
のインデックス(0 起算)を示す。
foundation 型 DOMString、readonly、nullable
RTCIceTransport 上に出現する候補を
ICE が相関付けるための一意識別子。
component 型 RTCIceComponent、
readonly、nullable
rtp" または "rtcp")。
これは candidate-attribute の
component-id フィールドに対応し、
RTCIceComponent
で定義される文字列表現にデコードされる。
priority 型 unsigned long、readonly、nullable
address 型 DOMString、readonly、nullable
候補のアドレス。IPv4 / IPv6 アドレスおよび FQDN を許容。
これは candidate-attribute
内の connection-address フィールドに対応する。
リモート候補は、たとえば
[[SelectedCandidatePair]].remote
を介して公開されることがある。
デフォルトでは、ユーザーエージェントは、公開される
すべてのリモート候補について
address
属性をnullのままにしておかなければならない
(MUST)。
RTCPeerConnection
インスタンスが、
Web アプリケーションによる
addIceCandidate
の使用を通じてアドレスを認識すると、
ユーザーエージェントは、その新たに認識された
アドレスを持つリモート候補を表す、
その
RTCPeerConnection
インスタンスの任意の
RTCIceCandidateで
address
属性値を公開できる。
ICE により収集され
RTCIceCandidate
インスタンスとしてアプリケーションに渡されるアドレスは、
WebRTC 非対応ブラウザでユーザーが期待する以上の(例: 位置情報やローカルネットワークトポロジ)情報を
デバイス・ユーザーについて漏らし得る。
これらのアドレスは常にアプリケーションおよび通信相手に公開され得るもので、 (データチャネルのみの接続や受信専用などにおいて)特別なユーザー同意無しに公開され得る。
これらのアドレスは一時的または永続的なクロスオリジン状態として利用され得、
デバイスのフィンガープリンティング面を増大させる。
通信相手にアドレスを公開しない(あるいは一時的に抑制する)ために、
アプリケーションは
ICE Agent に
リレー候補のみを
iceTransportPolicy
メンバを通じて強制することで可能であり、
これは RTCConfiguration
の設定である。
アプリケーション自身に露出されるアドレスを制限するため、 ブラウザはユーザーにローカルアドレス共有ポリシーを選択できるようにでき、 これは [RFC8828] に定義される。
protocol 型 RTCIceProtocol、
readonly、nullable
udp"/"tcp")。これは
candidate-attribute の
transport フィールドに対応する。
port 型 unsigned short、readonly、nullable
type 型 RTCIceCandidateType、
readonly、nullable
candidate-attribute の
candidate-types フィールドに対応する。
tcpType 型 RTCIceTcpCandidateType、
readonly、nullable
protocol が "tcp"
の場合、
tcpType は TCP
候補の種別を表す。
それ以外の場合 tcpType は
null。
これは candidate-attribute の
tcp-type フィールドに対応。
relatedAddress 型
DOMString、readonly、nullable
relatedAddress
は元となる候補の IP アドレス。
host 候補では relatedAddress
は null。これは
candidate-attribute の
rel-address フィールドに対応する。
relatedPort 型 unsigned short、readonly、nullable
relatedPort
は元となる候補のポート。
host 候補では relatedPort は
null。これは candidate-attribute の
rel-port フィールドに対応。
usernameFragment 型 DOMString、readonly、nullable
ufrag を保持する。
relayProtocol 型 RTCIceServerTransportProtocol、readonly、
nullable
relay" の場合、
エンドポイントが TURN サーバと通信する際に使用したプロトコル。
それ以外の候補では null。
toJSON()
RTCIceCandidate インターフェイスの
toJSON()
操作を呼び出すには、
次の手順を実行する。
RTCIceCandidateInit
辞書とする。
candidate, sdpMid,
sdpMLineIndex,
usernameFragment»
内の各属性識別子
attrについて、
RTCIceCandidate
オブジェクトを与えて、
attrによって識別される属性の
基礎となる値を取得した結果をvalueとする。
json[attr]
をvalueに設定する。
WebIDLdictionary RTCIceCandidateInit {
DOMString candidate = "";
DOMString? sdpMid = null;
unsigned short? sdpMLineIndex = null;
DOMString? usernameFragment = null;
};
candidate 型 DOMString、既定値
""
candidate-attribute を保持する。
end-of-candidates 指示を表す場合、
candidate
は空文字列となる。
sdpMid 型 DOMString、nullable、既定値
null
null でない場合、
メディアストリーム
"identification-tag"
を保持する。
sdpMLineIndex 型 unsigned short、nullable、既定値
null
null でない場合、候補が対応する SDP 内の
media description
のインデックス(0 起算)を示す。
usernameFragment 型 DOMString、nullable、既定値
null
null でない場合、[RFC5245]
セクション 15.4 で定義される
ufrag を保持する。
candidate-attribute 文法は
candidate メンバを
RTCIceCandidate()
コンストラクタ内でパースするために使用される。
candidate-attribute の主要文法は
[RFC5245]
セクション 15.1 で定義される。
さらにブラウザは [RFC6544]
セクション 4.5 で定義される
ICE TCP の文法拡張を MUST サポートする。
ブラウザは他の RFC で定義される
candidate-attribute の文法拡張を
MAY サポートしてもよい。
RTCIceProtocol は ICE candidate のプロトコルを表す。
WebIDLenum RTCIceProtocol {
"udp",
"tcp"
};
| 列挙値 | 説明 |
|---|---|
udp
|
[RFC5245] に記述される UDP 候補。 |
tcp
|
[RFC6544] に記述される TCP 候補。 |
RTCIceTcpCandidateType は ICE TCP
候補の種別を表し、
[RFC6544]
で定義される。
WebIDLenum RTCIceTcpCandidateType {
"active",
"passive",
"so"
};
| 列挙値 | 説明 |
|---|---|
active
|
"active"
TCP 候補は、アウトバウンド接続を開こうとするが受信接続要求は受けないもの。
|
passive
|
"passive"
TCP 候補は、受信接続試行を受け入れるが自ら接続を試みないもの。
|
so
|
"so" 候補は
ピアと同時に接続確立を試みるもの。
|
ユーザーエージェントは通常
active な ICE TCP
候補のみ収集する。
RTCIceCandidateType は
ICE candidate の種別を [RFC5245]
セクション 15.1 に従って表す。
RTCIceServerTransportProtocol
はクライアントとサーバ間で用いられる転送プロトコル種別を [RFC8656]
セクション 3.1 に従って表す。
WebIDLenum RTCIceServerTransportProtocol {
"udp",
"tcp",
"tls",
};
| 列挙値 | 説明 |
|---|---|
udp
|
TURN クライアントがサーバへのトランスポートとして UDP を使用している。 |
tcp
|
TURN クライアントがサーバへのトランスポートとして TCP を使用している。 |
tls
|
TURN クライアントがサーバへのトランスポートとして TLS を使用している。 |
icecandidate イベントは
RTCPeerConnection 上で
RTCPeerConnectionIceEvent
インターフェイスを使用する。
RTCIceCandidate オブジェクトを
含む RTCPeerConnectionIceEvent イベントを
発火する場合、
sdpMid と sdpMLineIndex の両方の値を
含めなければならない(MUST)。
RTCIceCandidate の型が
"srflx" または
"relay" である場合、イベントの
url プロパティは、
候補の取得元である ICE サーバーの URL に設定されなければならない(MUST)。
icecandidate イベントは 3 種類の通知に使用される:
候補が収集された。イベントの
candidate
メンバは通常どおり値を持つ。これをリモートピアへシグナリングし、
addIceCandidate
に渡す。
ある RTCIceTransport が一つの
generation の候補収集を完了し、
[RFC8838]
セクション 8.2 に定義される end-of-candidates 指示を提供する。
これは
candidate.candidate
が空文字列に設定されることで示される。
この candidate
オブジェクトは通常の ICE candidate 同様にリモートピアへシグナリングし
addIceCandidate
に渡し、end-of-candidates 指示をリモートピアに伝える。
すべての RTCIceTransport が候補収集を完了し、
RTCPeerConnection の
RTCIceGatheringState
が "complete"
に遷移した。
これはイベントの candidate
メンバが null に設定されることで示される。
(後方互換性のみのために存在し)リモートピアへシグナリングする必要はない。
これは "complete"
状態の
icegatheringstatechange
イベントと同等。
WebIDL[Exposed=Window]
interface RTCPeerConnectionIceEvent : Event {
constructor(DOMString type, optional RTCPeerConnectionIceEventInit eventInitDict = {});
readonly attribute RTCIceCandidate? candidate;
readonly attribute DOMString? url;
};
RTCPeerConnectionIceEvent.constructor()
candidate 型 RTCIceCandidate、
readonly、nullable
candidate
属性はイベントを引き起こした新しい ICE 候補を持つ
RTCIceCandidate オブジェクト。
候補収集終了を示すイベントでは、この属性は null に設定される。
複数メディアコンポーネントがあっても、null 候補を含むイベントは一度だけ発火する。
url 型 DOMString、readonly、nullable
url 属性は、
その候補を収集した STUN または TURN サーバを識別する STUN/TURN URL。
STUN/TURN サーバから収集されていない候補では null。
この属性は非推奨であり、レガシー互換性のためだけに存在する。候補の
url を利用すること。
WebIDLdictionary RTCPeerConnectionIceEventInit : EventInit {
RTCIceCandidate? candidate;
DOMString? url;
};
candidate 型は RTCIceCandidate、
nullable
RTCPeerConnectionIceEvent
インターフェイスの
candidate
属性を参照。
url 型は DOMString、nullable
url 属性は、
この候補の収集に使用された
STUN または TURN サーバーを識別する STUN または TURN URL である。
icecandidateerror イベントは
RTCPeerConnection 上で
RTCPeerConnectionIceErrorEvent
インターフェイスを使用する。
WebIDL[Exposed=Window]
interface RTCPeerConnectionIceErrorEvent : Event {
constructor(DOMString type, RTCPeerConnectionIceErrorEventInit eventInitDict);
readonly attribute DOMString? address;
readonly attribute unsigned short? port;
readonly attribute DOMString url;
readonly attribute unsigned short errorCode;
readonly attribute USVString errorText;
};
RTCPeerConnectionIceErrorEvent.constructor()
address 型 DOMString、readonly、nullable
address
属性は STUN または TURN サーバとの通信に用いられたローカル IP アドレスである。
マルチホーム環境では複数のインターフェイスがサーバ接続に使用され得るため、この属性によりどのインターフェイスで失敗が起きたかをアプリケーションが把握できる。
ローカル IP アドレス値がまだローカル候補の一部として公開されていない場合、
address
属性は null に設定される。
port 型 unsigned
short、readonly、nullable
port
属性は STUN または TURN サーバとの通信に使用されたポートである。
url 型 DOMString、readonly
url
属性は障害が発生した STUN または TURN サーバを識別する STUN/TURN URL である。
errorCode 型 unsigned short、readonly
errorCode
属性は STUN または TURN サーバから返された数値 STUN エラーコード
[STUN-PARAMETERS] である。
いずれの host candidate もサーバに到達できない場合、
errorCode
は STUN エラーコード範囲外の値 701 に設定される。このエラーは
RTCIceGatheringState が
"gathering"
の間、サーバ URL ごとに一度だけ発火する。
errorText 型 USVString、readonly
errorText
属性は STUN または TURN サーバから返された STUN reason text
[STUN-PARAMETERS] である。
サーバに到達できなかった場合、
errorText
はエラーの詳細を示す実装依存の値に設定される。
WebIDLdictionary RTCPeerConnectionIceErrorEventInit : EventInit {
DOMString? address;
unsigned short? port;
DOMString url;
required unsigned short errorCode;
USVString errorText;
};
address 型 DOMString、nullable
STUN または TURN サーバとの通信に使用されたローカルアドレス。あるいは null。
port 型 unsigned short、nullable
STUN または TURN サーバとの通信に使用されたローカルポート。あるいは null。
url 型 DOMString
障害が発生した STUN または TURN サーバを識別する STUN/TURN URL。
errorCode 型 unsigned short、required
STUN または TURN サーバから返された数値 STUN エラーコード。
errorText 型 USVString
STUN または TURN サーバから返された STUN reason text。
ピアとの認証に RTCPeerConnection インスタンスが使用する証明書は
RTCCertificate
インターフェイスを用いる。これらのオブジェクトはアプリケーションが
generateCertificate
メソッドで明示的に生成でき、
新しい RTCConfiguration を用いて
RTCPeerConnection
インスタンスを構築する際に提供できる。
ここで提供される明示的な証明書管理機能は任意である。アプリケーションが
certificates 構成オプションを
RTCPeerConnection
構築時に提供しない場合、
新しい証明書セットが MUST で ユーザーエージェント により生成されなければならない。そのセットには
P-256 曲線上の秘密鍵を持つ ECDSA 証明書と SHA-256 ハッシュによる署名を MUST で含める。
WebIDLpartial interface RTCPeerConnection {
static Promise<RTCCertificate>
generateCertificate(AlgorithmIdentifier keygenAlgorithm);
};
generateCertificate, static
generateCertificate
関数は ユーザーエージェント に X.509 証明書
[X509V3]
と対応する秘密鍵を作成させる。情報へのハンドルは
RTCCertificate
インターフェイスの形で提供される。返された
RTCCertificate は
RTCPeerConnection が確立する DTLS
セッションで提示される証明書を制御するために使用できる。
keygenAlgorithm 引数は証明書に関連付けられる秘密鍵がどのように生成されるかを制御する。keygenAlgorithm 引数は WebCrypto [WebCryptoAPI] AlgorithmIdentifier 型を利用する。
次の値は ユーザーエージェント が MUST
でサポートしなければならない:
{ name: "RSASSA-PKCS1-v1_5",
modulusLength: 2048, publicExponent: new Uint8Array([1, 0,
1]), hash: "SHA-256" } および { name:
"ECDSA", namedCurve:
"P-256"
}。
ユーザーエージェント は受け付ける値の集合を小規模または固定にすることが想定される。
このプロセスで生成される証明書には署名も含まれる。署名の妥当性は互換性の理由のみで意味を持つ。
RTCPeerConnection
によって使用されるのは公開鍵と結果の証明書フィンガープリントのみであるが、証明書が整形式である方が受け入れられる可能性が高い。ブラウザは証明書の署名に使用するアルゴリズムを選択する。ブラウザはハッシュアルゴリズムが必要な場合
SHA-256
[FIPS-180-4]
を選択することを SHOULD である。
生成された証明書はユーザーまたは ユーザーエージェント にリンク可能な情報を MUST NOT で含んではならない。識別名およびシリアル番号にはランダム化された値を用いることが SHOULD である。
メソッドが呼び出されたとき、ユーザーエージェントは MUST で次の手順を実行する:
keygenAlgorithm を
generateCertificate
の第1引数とする。
expires を 2592000000 (30*24*60*60*1000) の値とする。
これはデフォルトで証明書が
generateCertificate
呼び出し時点から 30 日後に失効することを意味する。
keygenAlgorithm がオブジェクトであれば以下を実行する:
certificateExpiration を
変換
により、keygenAlgorithm を表す ECMAScript オブジェクトを
RTCCertificateExpiration
辞書に変換した結果とする。
変換が error で失敗した場合、error で reject された promise を返す。
もし
certificateExpiration.expires
が undefined でなければ、expires を
certificateExpiration.expires
に設定する。
expires が 31536000000 を超える場合、 expires を 31536000000 に設定する。
これは証明書が
generateCertificate
呼び出し時点から 365 日より長く有効にならないことを意味する。
ユーザーエージェント は MAY でさらに expires の値を上限設定してよい。
normalizedKeygenAlgorithm を
アルゴリズムの正規化
(operation name: generateKey、
supportedAlgorithms
は
RTCPeerConnection
の証明書生成専用の値)した結果とする。
上記正規化ステップが error で失敗したなら、 error で reject された promise を返す。
normalizedKeygenAlgorithm が特定するアルゴリズムを
ユーザーエージェント が
RTCPeerConnection
の証明書生成に使用できない/使用しない場合、
reject された
DOMException
(NotSupportedError) を伴う promise
を返す。特に
normalizedKeygenAlgorithm は DTLS 接続認証に使用される署名を生成可能な非対称アルゴリズムであることを
MUST とする。
p を新しい promise とする。
次の手順を 並行して実行する:
normalizedKeygenAlgorithm で指定された generate key 操作を keygenAlgorithm を用いて実行する。
generatedKeyingMaterial および generatedKeyCertificate を上記で生成された秘密鍵材料と証明書とする。
certificate を新しい
RTCCertificate
オブジェクトとする。
certificate.[[Expires]] を現在時刻 + expires に設定する。
certificate.[[Origin]] を
関連設定オブジェクト の
origin に設定する。
generatedKeyingMaterial を安全なモジュールに保存し、handle をそれへの参照識別子とする。
certificate.[[KeyingMaterialHandle]]
を handle に設定する。
certificate.[[Certificate]] を
generatedCertificate に設定する。
現在の realm の グローバルオブジェクト を global として ネットワークタスクソース 上で グローバルタスクをキューし、 p を certificate で resolve する。
p を返す。
RTCCertificateExpiration は
generateCertificate
により生成される証明書に有効期限を設定するために使用される。
WebIDLdictionary RTCCertificateExpiration {
[EnforceRange] unsigned long long expires;
};
expires, of type unsigned long long
アルゴリズム定義(
generateCertificate
に渡される)に MAY で追加できる任意の
expires
属性。存在する場合、これは
証明書が作成された時点から計測して
RTCCertificate が有効でいられる最大時間(ミリ秒)を示す。
RTCCertificate インターフェイスは
WebRTC 通信を認証するために使用される証明書を表す。可視プロパティに加え、内部スロットは生成された秘密鍵材料へのハンドル ([[KeyingMaterialHandle]])、ピアとの認証に
RTCPeerConnection が使用する証明書 ([[Certificate]])、およびオブジェクトを作成したオリジン ([[Origin]]) を含む。
WebIDL[Exposed=Window, Serializable]
interface RTCCertificate {
readonly attribute EpochTimeStamp expires;
sequence<RTCDtlsFingerprint> getFingerprints();
};
expires of type EpochTimeStamp, readonly
expires 属性は、1970-01-01T00:00:00Z
からのミリ秒で表される、ブラウザがその証明書を無効とみなす日時を示す。この時刻以降、この証明書を用いて
RTCPeerConnection
を構築しようとする試みは失敗する。
この値は証明書自体の notAfter パラメータに反映されないことがある点に注意。
getFingerprints
証明書フィンガープリントの一覧を返す。そのうち1つは証明書署名で使用されたダイジェストアルゴリズムで計算される。
本 API の目的では、[[Certificate]]
スロットには非構造化バイナリデータが含まれる。アプリケーションが
[[KeyingMaterialHandle]]
内部スロットやそれが参照する鍵材料へアクセスする仕組みは提供されない。実装は
MUST でアプリケーションが
RTCCertificate
オブジェクトを永続ストレージへ保存および取得することをサポートし、その際
[[KeyingMaterialHandle]]
が参照する鍵材料も保持しなければならない。実装は機微な鍵材料を同一プロセスメモリアタックから安全なモジュールに保存することを SHOULD
とする。これにより秘密鍵は保存および使用できるが、メモリアタックで容易に読み出されない。
RTCCertificate オブジェクトは
serializable
objects
[HTML] である。これらの シリアライズ手順 は value と
serialized が与えられたとき以下:
expires 属性の値に設定する。
[[Certificate]] 内の非構造化バイナリデータのコピーに設定する。
[[Origin]]
内の非構造化バイナリデータのコピーに設定する。
[[KeyingMaterialHandle]]
内のハンドル(秘密鍵材料自体ではない)のシリアライズ結果に設定する。
これらの デシリアライズ手順 は serialized と value が与えられたとき:
expires
属性を serialized.[[Expires]] を含むよう初期化する。
[[Certificate]] を
serialized.[[Certificate]] のコピーに設定する。
[[Origin]]
を
serialized.[[Origin]] のコピーに設定する。
[[KeyingMaterialHandle]] を
serialized.[[KeyingMaterialHandle]] のデシリアライズ結果である秘密鍵材料ハンドルに設定する。
この方法で構造化複製をサポートすることにより、
RTCCertificate インスタンスをストアに永続化できる。また
postMessage(message, options)
[html] のような API
を使って他オリジンへ渡すことも可能になる。しかし、そのオブジェクトは元々作成したオリジン以外では使用できない。
RTPメディアAPIは、
ウェブアプリケーションがピアツーピア接続を通じて
MediaStreamTrackを
送受信できるようにします。トラックが
RTCPeerConnectionに追加されるとシグナリングが発生し、
このシグナリングがリモートピアに転送されることで、リモート側にも対応するトラックが作成されます。
ある
RTCPeerConnection
から送信されたトラックと相手側で受信されるトラックには、厳密な1:1対応関係はありません。
まず、送信側のトラックIDと受信側のトラックIDには対応関係がありません。
また、
replaceTrackは、
RTCRtpSenderが送信するトラックを変更しますが、
受信側で新しいトラックが作成されることはありません。対応する
RTCRtpReceiverは常に一つのトラックだけを持ち、
そのトラックは複数のメディアソースが繋ぎ合わされている可能性があります。
addTransceiverや
replaceTrackを使うことで
同じトラックを複数回送信することもでき、受信側ではそれぞれ独立したトラックとして複数のレシーバーから観測されます。
したがって、RTCRtpSender
と、対応する受信側の
RTCRtpReceiverのトラックとの間に
1:1関係があると考える方が正確です。必要に応じて
RTCRtpTransceiverの
midで送信者と受信者を照合できます。
メディア送信時には、SDPでネゴシエートされた条件、エンコーダの整列制約、CPU過負荷検出や帯域幅推定など、様々な要件を満たすために メディアをリスケールやリサンプルする必要がある場合があります。
[RFC9429] (section 3.6.)に従い、 動画は縮小しても構いません。 メディアは、入力ソースに存在しない偽データを生成するために拡大してはならず、 ピクセル数の制約を満たすため以外には切り抜きしてはならず、 アスペクト比も変更してはなりません。
WebRTCワーキンググループは、この状況のより複雑な処理の必要性とタイムラインについて、実装者からのフィードバックを求めています。 いくつかの設計案がGitHub issue 1283で議論されています。
scaleResolutionDownBy
の結果として動画が再スケーリングされる場合、
結果の幅または高さが整数にならない
状況が発生することがある。ユーザーエージェントは、
scaleResolutionDownBy
によってスケーリングされた幅と高さの
整数部分より大きい動画を、
エンコーダーの最小解像度を尊重する場合を除き、
送信してはならない(MUST NOT)。
スケーリングされた幅または高さの整数部分がゼロである場合に何を送信するかは、
実装定義である。
MediaStreamTrackの
実際のエンコードと送信は
RTCRtpSenderオブジェクトによって管理されます。
同様に、MediaStreamTrackの受信とデコードは
RTCRtpReceiverオブジェクトによって管理されます。
各RTCRtpSenderは最大1つのトラックと関連し、
受信すべき各トラックは必ず1つの
RTCRtpReceiverに関連付けられます。
各MediaStreamTrackの
エンコードと送信は、その特徴(動画の場合はwidth、
height、frameRate、
音声の場合はsampleSize、sampleRate、
channelCount)がリモート側で作成されるトラックによって
ある程度保持されるようにすべきです。
しかし、必ずそうなるとは限らず、エンドポイントやネットワークのリソース制約や、
RTCRtpSenderの設定によって
実装が異なる動作を指示される場合があります。
RTCPeerConnectionオブジェクトは、
RTCRtpTransceiverの集合
を保持します。これは、ペアになった送信者と受信者の共有状態を表します。
この集合は
RTCPeerConnectionオブジェクトが
作成された時点で空集合に初期化されます。
RTCRtpSenderおよび
RTCRtpReceiverは
常にRTCRtpTransceiverの
作成時に同時に作られ、ライフタイム中ずっと紐付けられます。
RTCRtpTransceiverは、
アプリケーションが
MediaStreamTrack
をRTCPeerConnectionに
addTrack()
メソッドで追加するか、
addTransceiverメソッドで
明示的に追加した時に暗黙的に作成されます。
また、リモート記述に新しいメディア記述が含まれている場合にも作成されます。
さらに、リモート記述がリモートエンドポイントが送信可能なメディアを持っていることを示している場合、
該当するMediaStreamTrack
およびRTCRtpReceiverが
trackイベントを通じて
アプリケーションに公開されます。
RTCRtpTransceiverが
他のエンドポイントとメディアを送受信するには、SDPで交渉される必要があり、
両方のエンドポイントが同じ
RTCRtpTransceiverオブジェクトを
関連付けし、
同じメディア記述と結びつける必要があります。
オファー作成時には、全てのトランシーバーに対応するメディア記述が生成されます。 このオファーがローカル記述として設定されると、未関連のトランシーバーはオファー内のメディア記述と関連付けられます。
オファーがリモート記述として設定された場合、まだトランシーバーと関連していないメディア記述は
新規または既存のトランシーバーと関連付けられます。
この場合、addTrack()
メソッドで作成された未関連のトランシーバーのみが関連付けられます。
addTransceiver()
メソッドで作成された未関連のトランシーバーは、
たとえリモートオファーにメディア記述があっても関連付けられません。
代わりに、十分な
addTrack()
作成のトランシーバーがなければ、新しくトランシーバーが作成・関連付けされます。
これにより、
addTrack()
作成と
addTransceiver()
作成のトランシーバーは、属性を調べても判別できない重要な違いを持つことになります。
アンサー作成時には、オファーに含まれていたメディア記述のみがアンサーに記載されます。
そのため、リモートオファー設定時に関連付けされなかったトランシーバーは、
ローカルアンサー設定後も未関連のままとなります。
この状況は、アンサー側がフォローアップオファーを作成して再度オファー/アンサー交換を行うか、
addTrack()
作成のトランシーバーの場合は、最初の交換で十分なメディア記述がオファーされるようにすることで解消できます。
RTPメディアAPIは、以下のように
RTCPeerConnectionインターフェイスを拡張します。
WebIDL partial interface RTCPeerConnection {
sequence<RTCRtpSender> getSenders();
sequence<RTCRtpReceiver> getReceivers();
sequence<RTCRtpTransceiver> getTransceivers();
RTCRtpSender addTrack(MediaStreamTrack track, MediaStream... streams);
undefined removeTrack(RTCRtpSender sender);
RTCRtpTransceiver addTransceiver((MediaStreamTrack or DOMString) trackOrKind,
optional RTCRtpTransceiverInit init = {});
attribute EventHandler ontrack;
};
ontrack 型 EventHandler
このイベントハンドラーのイベントタイプは
trackです。
getSenders
現在この
RTCPeerConnection
オブジェクトに接続されている、
停止していない
RTCRtpTransceiver オブジェクトに属する
RTP sender を表す
RTCRtpSender オブジェクトのシーケンスを返す。
getSenders メソッドが
呼び出された場合、ユーザーエージェントは
CollectSenders
アルゴリズムを実行した結果を返さなければならない(MUST)。
CollectSenders アルゴリズムを次のように定義する。
CollectTransceivers
アルゴリズムを実行した結果とする。
[[Stopped]]が
falseである場合、
transceiver.[[Sender]]を
sendersに追加する。
getReceivers
現在この
RTCPeerConnection
オブジェクトに接続されている、
停止していない
RTCRtpTransceiver オブジェクトに属する
RTP receiver を表す
RTCRtpReceiver オブジェクトの
シーケンスを返す。
getReceivers メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
CollectTransceivers
アルゴリズムを実行した結果とする。
[[Stopped]]が
falseである場合、
transceiver.[[Receiver]]を
receiversに追加する。
getTransceivers
現在この
RTCPeerConnection オブジェクトに
接続されている RTP transceiver を表す
RTCRtpTransceiver オブジェクトの
シーケンスを返す。
getTransceivers
メソッドは、
CollectTransceivers
アルゴリズムを実行した結果を返さなければならない(MUST)。
CollectTransceivers アルゴリズムを 次のように定義する。
RTCPeerConnection
オブジェクトのトランシーバーの集合内のすべての
RTCRtpTransceiver
オブジェクトから、
挿入順で構成される新しいシーケンスとする。
addTrack
RTCPeerConnectionに新しいトラックを追加し、
それが指定されたMediaStream群に含まれていることを
示す。
addTrack メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
connectionを、このメソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
trackを、メソッドの第1引数で示されるMediaStreamTrack オブジェクト
とする。
kindをtrack.kindとする。
streamsを、メソッドの残りの
引数から構築されたMediaStream
オブジェクトのリストとする。メソッドが
単一の引数で呼び出された場合は空のリストとする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを投げる。
sendersを、
CollectSenders アルゴリズムを
実行した結果とする。
track用のRTCRtpSenderが
senders内にすでに存在する場合、投げる、InvalidAccessErrorを。
以下の手順では、既存の
sender を再利用できるかどうかを判定する方法を説明する。再利用すると、
以後の
createOffer
および
createAnswer
の呼び出しによって、対応するメディア
記述がsendrecvまたはsendonlyとしてマークされ、sender の
ストリームの MSID が追加される。これは[RFC9429]
(5.2.2
節および5.3.2
節)で定義されている。
senders内のいずれかのRTCRtpSender オブジェクトが
次のすべての条件を満たす場合、senderを
そのオブジェクトとし、それ以外の場合はnullとする。
sender のトラックが null である。
sender に関連付けられた
RTCRtpTransceiverの
トランシーバー種別が
kindと一致する。
sender に関連付けられた
RTCRtpTransceiverの
[[Stopping]] スロットが
falseである。
sender が送信に使用されたことが一度もない。より
正確には、sender に関連付けられた
RTCRtpTransceiverの
[[CurrentDirection]]
スロットが、これまで一度も
"sendrecv"
または
"sendonly"
の値になったことがない。
senderがnullでない場合、その sender を使用するために
次の手順を実行する。
sender.[[SenderTrack]]を
trackに設定する。
sender.[[AssociatedMediaStreamIds]]
を空集合に設定する。
streams内の各streamについて、
stream.idがまだ存在しない場合、
[[AssociatedMediaStreamIds]]
に追加する。
transceiverを、
senderに関連付けられた
RTCRtpTransceiver
とする。
transceiver.[[Direction]]が
"recvonly"
である場合、
transceiver.[[Direction]]を
"sendrecv"
に設定する。
transceiver.[[Direction]]が
"inactive"
である場合、
transceiver.[[Direction]]を
"sendonly"
に設定する。
senderがnullである場合、次の
手順を実行する。
track、 kind、およびstreamsを用いて RTCRtpSender を作成し、 その結果を senderとする。
kindを用いて RTCRtpReceiver を 作成し、 その結果をreceiverとする。
sender、receiver、および
値が
"sendrecv"
である
RTCRtpTransceiverDirection
値を用いて
RTCRtpTransceiver を
作成し、
その結果を
transceiverとする。
transceiverをconnectionの トランシーバーの 集合に追加する。
トラックには、アプリケーションからアクセスできない
内容が含まれることがある。これは、トラックを
CORS
クロスオリジンにする任意の要因によって生じ得る。このようなトラックも
addTrack()
メソッドに渡して、
それら用のRTCRtpSenderを作成できるが、
内容を送信してはならない(MUST NOT)。
トラックの内容の代わりに、無音(audio)、黒いフレーム(video)、または
同等の内容なしのデータを送信する。
この特性は時間の経過とともに変化する可能性があることに注意。
connectionについてネゴシエーション必要フラグを 更新する。
senderを返す。
removeTrack
senderからのメディア送信を停止する。
RTCRtpSenderは引き続き
getSendersに現れる。
これを行うと、以後のcreateOfferの呼び出しによって、
対応するトランシーバーのメディア記述が
"recvonly"
または
"inactive"
としてマークされる。これは
[RFC9429]
(5.2.2
節)で定義されている。
他方のピアがこの方法でトラックの送信を停止すると、
そのトラックは、当初track
イベントで公開されたすべてのリモートMediaStreamから削除され、
MediaStreamTrackがまだミュートされていない場合、
トラックでmuteイベントが発火する。
removeTrack()
と同じ効果は、
対応するトランシーバーの
RTCRtpTransceiver.direction
属性を設定し、sender 上で
RTCRtpSender.replaceTrack(null)
を呼び出すことでも得られる。小さな違いの1つは、
replaceTrack()
は非同期であり、
removeTrack()
は同期であるという点である。
removeTrack メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
senderをremoveTrackへの引数とする。
connectionを、メソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを投げる。
senderが
connectionによって作成されたものでない場合、投げる、InvalidAccessErrorを。
transceiverを、senderに対応するRTCRtpTransceiver
オブジェクトとする。
transceiver.[[Stopping]]が
trueである場合、これらの手順を中止する。
sendersを、
CollectSenders アルゴリズムを
実行した結果とする。
senderがsenders内にない場合(これは、
そのトランシーバーが停止されたか、type
"rollback"の
セッション記述を設定することによって
削除されたことを示す)、これらの手順を
中止する。
sender.[[SenderTrack]]が null の場合、
これらの手順を中止する。
sender.[[SenderTrack]]を null に設定する。
transceiver.[[Direction]]が
"sendrecv"
である場合、
transceiver.[[Direction]]を
"recvonly"
に設定する。
transceiver.[[Direction]]が
"sendonly"
である場合、
transceiver.[[Direction]]を
"inactive"
に設定する。
connectionについてネゴシエーション必要フラグを 更新する。
addTransceiver
新しいRTCRtpTransceiverを作成し、
トランシーバーの集合に追加する。
トランシーバーを追加すると、以後の
createOfferの呼び出しによって、
対応するトランシーバー用のメディア記述が
追加される。これは[RFC9429]
(5.2.2
節)で定義されている。
midの初期値は null である。
セッション記述を設定すると、後でこれを
null でない値に変更することがある。
sendEncodings
引数を使用して、
オファーするサイマルキャストエンコーディングの数、
および任意でその RID とエンコーディングパラメーターを指定できる。
このメソッドが呼び出された場合、ユーザーエージェントは 次の手順を実行しなければならない(MUST)。
initを第2引数とする。
streamsを
init.streamsとする。
sendEncodingsを
init.sendEncodingsとする。
directionを
init.directionとする。
第1引数が文字列である場合、kindを 第1引数とし、次の手順を実行する。
第1引数がMediaStreamTrackである場合、
trackを第1引数とし、kindを
track.kindとする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを投げる。
次の
addTransceiver sendEncodings 検証手順を実行して、
sendEncodingsを検証する。ここで、その中の各
RTCRtpEncodingParameters
辞書を「encoding」とする。
sendEncodings内の各
値が、
[RFC8851]の第10節で
規定されている文法に準拠することを確認する。
RID のいずれかが
これらの要件を満たさない場合、投げる、ridTypeErrorを。
TypeErrorを。
いずれかの encoding が、
rid
以外の読み取り専用
パラメーターを含む場合、
投げる、
InvalidAccessErrorを。
いずれかの encoding が、
RTCRtpSender.getCapabilities(kind).codecs
内のどの codec にも一致しない値を持つ
codec
メンバーを含む場合、
投げる、OperationErrorを。
ユーザーエージェントがネゴシエーションなしでの codec の変更をサポートしていないか、
個々の encoding に codec を設定することを
サポートしていない場合、新たに作成された
OperationErrorで
拒否された
Promise を返す。
kindが"audio"である場合、
次のいずれかを含むすべての encoding から、
scaleResolutionDownBy
および
maxFramerate
メンバーを削除する。
いずれかの encoding が、値が1.0未満である
scaleResolutionDownBy
メンバーを含む場合、
投げる、RangeErrorを。
sendEncodings内で定義されている各
maxFramerate
メンバーの値が 0.0 より大きいことを確認する。いずれかの
maxFramerate
値がこの要件を満たさない場合、
投げる、RangeErrorを。
maxNを、このkindについて
ユーザーエージェントがサポートし得る同時エンコーディングの総数の
最大値とし、少なくとも1とする。まだ使用する codec が
不明であるため、これは楽観的な値であるべきである。
いずれかの encoding が
scaleResolutionDownBy
メンバーを含む場合、それを持たない各 encoding に、
値が1.0であるscaleResolutionDownBy
メンバーを追加する。
sendEncodingsに格納されている encoding の数が maxNを超える場合、 長さがmaxNになるまで sendEncodingsを末尾から切り詰める。
kindが"video"であり、どの
encoding もscaleResolutionDownBy
メンバーを含まない場合、各 encoding に、
値が
2^(length of sendEncodings - encoding
index - 1)である
scaleResolutionDownBy
メンバーを追加する。これにより、小さいものから大きいものへという
解像度になり、最後の encoding にはスケーリングが
適用されない。たとえば長さが3なら 4:2:1 となる。
現在sendEncodingsに
格納されている encoding の数が1である場合、
唯一のエントリからrid
メンバーを削除する。
RTCRtpEncodingParameters
を指定すると、
サイマルキャストを使用しない場合でも、アプリケーションは
後から
setParameters
を使用してエンコーディングパラメーターを設定できる。
track、 kind、streams、および sendEncodingsを用いて RTCRtpSender を作成し、 その結果をsenderとする。
sendEncodingsが設定されている場合、以後の
createOffer
の呼び出しは、[RFC9429]
(5.2.2
節および5.2.1
節)で定義されているように、複数の
RTP エンコーディングを送信するよう構成される。
[RFC9429]
(3.7
節)で定義されているように、複数の RTP エンコーディングを
受信できる対応するリモート記述を指定して
setRemoteDescription
が呼び出された場合、
RTCRtpSenderは
複数の RTP エンコーディングを送信でき、トランシーバーの
sender.getParameters()
を介して取得されたパラメーターには、ネゴシエーションされた
エンコーディングが反映される。
kindを用いて RTCRtpReceiver を作成し、 その結果をreceiverとする。
sender、receiver、および directionを用いて RTCRtpTransceiver を 作成し、 その結果をtransceiverとする。
transceiverをconnectionのトランシーバーの 集合に追加する。
connectionについてネゴシエーション必要フラグを 更新する。
transceiverを返す。
WebIDLdictionary RTCRtpTransceiverInit {
RTCRtpTransceiverDirection direction = "sendrecv";
sequence<MediaStream> streams = [];
sequence<RTCRtpEncodingParameters> sendEncodings = [];
};
direction の型 RTCRtpTransceiverDirection、
既定値は「sendrecv」
RTCRtpTransceiver の方向。
streams の型 sequence<MediaStream>
リモートの RTCPeerConnection の
track イベントが、追加される RTCRtpReceiver に対応して発火したとき、
そのイベントに含められるストリーム。
sendEncodings の型 sequence<RTCRtpEncodingParameters>
メディアの RTP エンコーディング送信用パラメータを含むシーケンス。
WebIDLenum RTCRtpTransceiverDirection {
"sendrecv",
"sendonly",
"recvonly",
"inactive",
"stopped"
};
| 列挙値 | 説明 |
|---|---|
sendrecv
|
RTCRtpTransceiver の
RTCRtpSender
sender は RTP の送信を提案し、リモートピアが受け入れ、かつ
sender.getParameters().encodings[i].active
が任意の i について true の場合に RTP を送信する。
また、RTCRtpTransceiver の
RTCRtpReceiver は RTP の受信を提案し、
リモートピアが受け入れた場合に RTP を受信する。
|
sendonly
|
RTCRtpTransceiver の
RTCRtpSender
sender は RTP の送信を提案し、リモートピアが受け入れ、かつ
sender.getParameters().encodings[i].active
が任意の i について true の場合に RTP を送信する。
RTCRtpTransceiver の
RTCRtpReceiver は RTP の受信を提案せず、
RTP を受信しない。
|
recvonly
|
RTCRtpTransceiver の
RTCRtpSender は RTP の送信を提案せず、
RTP を送信しない。
RTCRtpTransceiver の
RTCRtpReceiver は RTP の受信を提案し、
リモートピアが受け入れた場合に RTP を受信する。
|
inactive
|
RTCRtpTransceiver の
RTCRtpSender は RTP の送信を提案せず、
RTP を送信しない。
RTCRtpTransceiver の
RTCRtpReceiver も RTP の受信を提案せず、
RTP を受信しない。
|
stopped
|
RTCRtpTransceiver は
RTP を送信も受信もしない。
オファーではポート 0 を生成する。アンサーでは、
その RTCRtpSender は送信を提案せず、
RTCRtpReceiver は受信を提案しない。
これは終端状態である。
|
アプリケーションは、トランシーバーの direction を
「inactive」に設定して一時的に送受信の両方向を無効化するか、
「sendonly」に設定して受信側のみを拒否することで、
受信するメディア記述を拒否できる。再利用可能な形で m-line を恒久的に拒否するには、
RTCRtpTransceiver の
stop() を呼び出し、
その後自端からネゴシエーションを開始する必要がある。
process remote tracks を、
RTCRtpTransceiver transceiver、
direction、msids、addList、
removeList、および trackEventInits が与えられたときに実行するには、
次の手順を行う:
関連付けられたリモートストリームを設定 し、
transceiver.[[Receiver]]、msids、
addList、removeList を用いる。
もし direction が
「sendrecv」または
「recvonly」であり、
かつ transceiver.[[FiredDirection]] が
「sendrecv」でも
「recvonly」でもない場合、
あるいは直前の手順で addList の長さが増えた場合は、
リモートトラックの追加を処理 し、
transceiver と trackEventInits を用いる。
もし direction が
「sendonly」または
「inactive」なら、
transceiver.[[Receptive]] を
false に設定する。
もし direction が
「sendonly」または
「inactive」であり、
かつ transceiver.[[FiredDirection]] が
「sendrecv」または
「recvonly」のいずれかであるなら、
リモートトラックの削除を処理 し、
対象の media
description に対して
transceiver と muteTracks を用いる。
transceiver.[[FiredDirection]] を
direction に設定する。
process the addition of
a remote track を、RTCRtpTransceiver
transceiver と trackEventInits が与えられたときに実行するには、
次の手順を行う:
receiver を
transceiver.[[Receiver]] とする。
track を
receiver.[[ReceiverTrack]] とする。
streams を
receiver.[[AssociatedRemoteMediaStreams]]
とする。
新しい RTCTrackEventInit 辞書を作成し、
そのメンバーに receiver、track、streams、
transceiver を設定して trackEventInits に追加する。
process the removal of a
remote track を、RTCRtpTransceiver
transceiver と muteTracks を用いて実行するには、
次の手順を行う:
receiver を
transceiver.[[Receiver]] とする。
track を
receiver.[[ReceiverTrack]] とする。
もし track.muted が false なら、
track を muteTracks に追加する。
set the associated
remote streams を、RTCRtpReceiver receiver、
msids、addList、removeList が与えられたときに実行するには、
次の手順を行う:
connection を、receiver に関連付けられた
RTCPeerConnection オブジェクトとする。
msids 内の各 MSID について、この connection に対してその
id を持つ
MediaStream オブジェクトがこれまでに作成されていない場合は、
その id を持つ
MediaStream オブジェクトを作成する。
streams を、この connection のために作成された
MediaStream オブジェクトのリストとし、
その id が msids に対応するものとする。
track を
receiver.[[ReceiverTrack]] とする。
receiver.[[AssociatedRemoteMediaStreams]]
内の各 stream について、それが streams に存在しない場合は、
removeList に stream と track のペアを追加する。
streams 内の各 stream について、それが
receiver.[[AssociatedRemoteMediaStreams]]
に存在しない場合は、addList に stream と track のペアを追加する。
receiver.[[AssociatedRemoteMediaStreams]]
を streams に設定する。
RTCRtpSender インターフェイスは、
アプリケーションが特定のMediaStreamTrackをどのようにエンコードし、
リモートピアに送信するかを制御できるようにします。
setParameters が
RTCRtpSender オブジェクトで
呼び出されると、エンコーディングが適切に変更されます。
MediaStreamTrack、
track、文字列、kind、
MediaStream
オブジェクトのリスト、
streams、およびオプションで
RTCRtpEncodingParameters オブジェクトのリスト、
sendEncodings を指定して
RTCRtpSenderを作成するには、以下の手順を実行します:
senderを新しいRTCRtpSenderオブジェクトとします。
senderに[[SenderTrack]]内部スロットを持たせ、trackで初期化します。
senderに[[SenderTransport]]
内部スロットを持たせ、nullで初期化します。
senderに
[[LastStableStateSenderTransport]]内部スロットを持たせ、
nullで初期化します。
senderに[[Dtmf]]
内部スロットを持たせ、nullで初期化します。
kindが"audio"の場合、
RTCDTMFSenderを作成し、
dtmfとして[[Dtmf]]
内部スロットをdtmfに設定します。
senderに
[[AssociatedMediaStreamIds]]内部スロットを持たせ、
この送信者が関連付けられるMediaStreamオブジェクトのIDリストを表します。
[[AssociatedMediaStreamIds]]
スロットは、senderが
SDPで表される際に[RFC9429] (セクション 5.2.1.)
に記載されるように使用されます。
sender.[[AssociatedMediaStreamIds]]を
空の集合に設定します。
streams内の各streamについて、
そのstream.idを[[AssociatedMediaStreamIds]]
に追加します(すでに存在しない場合)。
senderに[[SendEncodings]]
内部スロットを持たせ、RTCRtpEncodingParameters
辞書のリストを表します。
sendEncodingsがこのアルゴリズムへの入力として与えられ、
空でない場合、[[SendEncodings]]スロットを
sendEncodingsに設定します。そうでない場合は、新しい
RTCRtpEncodingParameters
辞書を一つ含むリストに設定し、
kindが"video"の場合は、
その辞書に1.0の値を持つ
scaleResolutionDownBy
メンバーを追加します。
RTCRtpEncodingParameters
辞書には、デフォルトで値がtrueの
active
メンバーが含まれています。
senderに
[[LastStableRidlessSendEncodings]]内部スロットを持たせ、
nullで初期化します。
senderに[[SendCodecs]]内部スロットを持たせ、
RTCRtpCodecParameters
辞書のリストを表し、空のリストで初期化します。
senderに
[[LastReturnedParameters]]内部スロットを持たせ、
getParametersと
setParametersの
トランザクションを一致させるために使用します。
senderを返します。
WebIDL[Exposed=Window]
interface RTCRtpSender {
readonly attribute MediaStreamTrack? track;
readonly attribute RTCDtlsTransport? transport;
static RTCRtpCapabilities? getCapabilities(DOMString kind);
Promise<undefined> setParameters(RTCRtpSendParameters parameters,
optional RTCSetParameterOptions setParameterOptions = {});
RTCRtpSendParameters getParameters();
Promise<undefined> replaceTrack(MediaStreamTrack? withTrack);
undefined setStreams(MediaStream... streams);
Promise<RTCStatsReport> getStats();
};
track の型 MediaStreamTrack, 読み取り専用,
nullable
track属性は、この
RTCRtpSender
オブジェクトに関連付けられているトラックです。
trackが終了した場合、
またはトラックの出力が無効化されている場合(すなわち、トラックが無効化および/またはミュートされている場合)、
RTCRtpSenderは、
MUST(必須)で黒いフレーム(ビデオ)を送信し、
MUST NOT(禁止)で音声を送信しません。
ビデオの場合、RTCRtpSenderは、
SHOULD(推奨)で1秒に1回黒いフレームを送信する必要があります。
trackがnullの場合、
RTCRtpSenderは送信しません。
取得時、この属性は
MUSTで
[[SenderTrack]]スロットの値を返す必要があります。
transport の型 RTCDtlsTransport,
読み取り専用, nullable
transport属性は、
trackからRTPパケットの形式で送信される
メディアのトランスポートです。
RTCDtlsTransportオブジェクトの
構築前、このtransport属性はnullになります。
バンドリングが使用される場合、複数のRTCRtpSender オブジェクトは
1つのtransportを共有し、
全て同じトランスポート上でRTPとRTCPを送信します。
取得時、この属性はMUSTで
[[SenderTransport]]スロットの
値を返す必要があります。
getCapabilities、静的
静的な RTCRtpSender.getCapabilities()
メソッドは、リソース、ポート、その他の状態を予約することなく、
指定された種類のメディアを送信するためにユーザーエージェントがサポートする
機能の種類を検出する手段を提供する。
getCapabilities
メソッドが呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
kindをメソッドの第1引数とする。
kindが"video"でも"audio"でもない場合、
nullを返す。
新しいRTCRtpCapabilities
辞書を返し、その
codecs メンバーを、
kindについての
実装済み
送信コーデックのリストで初期化し、その
headerExtensions
メンバーを、kindについての
実装済み
送信用ヘッダー拡張のリストで初期化する。
kindが与えられた場合の実装済み送信コーデックのリストは、
指定されたkind(video または audio)のメディアを送信するためにユーザー
エージェントがサポートするコーデックについて最も楽観的な見方を表す、RTCRtpCodec
辞書の実装定義リストである。
kindが与えられた場合の実装済み送信用ヘッダー拡張の
リストは、
指定されたkind(video または audio)のメディアを
送信するためにユーザーエージェントがサポートするヘッダー拡張について最も
楽観的な見方を表す、
RTCRtpHeaderExtensionCapability
辞書の実装定義
リストである。
これらの機能は、デバイスに関する一般に永続的なオリジン横断
情報を提供するため、アプリケーションの
フィンガープリンティング面を増大させる。
プライバシーに敏感な状況では、ユーザーエージェントは
機能の共通サブセットのみを報告するなどの
緩和策を検討してもよい(MAY)。
返されるコーデック機能は、
setCodecPreferences()
アルゴリズムと、
どの入力に対してInvalidModificationError
を投げるかに影響し、
また、プライバシー緩和策が有効になることを保証するため、
createOffer()
およびcreateAnswer()
が送信用にネゴシエーションされたコーデックについて
明らかにする情報とも整合しているべきである。
setParameters
setParameters メソッドは、
trackがどのようにエンコードされ、
リモートピアへ送信されるかを更新する。
setParameters メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
RTCRtpSender オブジェクトのうち、
setParametersが
呼び出されたものとする。
RTCRtpTransceiver オブジェクト
とする(すなわち、senderは
transceiver.[[Sender]]である)。
[[Stopping]]が
trueである場合、新たに作成されたInvalidStateErrorで
拒否された
Promise を返す。
[[LastReturnedParameters]]
が
nullである場合、新たに作成されたInvalidStateErrorで
拒否された
Promise を返す。
encodingsとする。
codecsとする。
choosableCodecsをcodecsとする。
choosableCodecsが空のリストである場合、
choosableCodecs
を transceiver.[[PreferredCodecs]]
に設定し、
実装済み
送信コーデックのリストに含まれないコーデックを除外する。
choosableCodecsが依然として空のリストである場合、 choosableCodecs を transceiver の種別についての実装済み 送信コーデックのリストに設定する。
[[SendEncodings]]に
格納されている
RTCRtpEncodingParameters
の数とする。
InvalidModificationErrorで
拒否された Promise を返す。
encodings.lengthが
Nと異なる。
[[LastReturnedParameters]]
内の対応する
パラメーター値と異なる。
これは
transactionIdにも適用されることに注意。
trueに設定したコーデック辞書
一致
アルゴリズムを使用したときに、
choosableCodecs内に見つからないコーデックを含む。
トランシーバー
種別が"audio"である場合、
次のいずれかを含むすべてのencodingsから、
scaleResolutionDownBy
および
maxFramerate
メンバーを削除する。
トランシーバー
種別が"video"である場合、
encodings内の各エンコーディングのうち、
scaleResolutionDownBy
メンバーを含まないものそれぞれに、
値が1.0である
scaleResolutionDownBy
メンバーを追加する。
トランシーバー
種別が"video"であり、
encodings内のいずれかのエンコーディングが、
値が1.0未満である
scaleResolutionDownBy
メンバーを含む場合、新たに作成されたRangeErrorで
拒否された
Promise を返す。
encodings内の各エンコーディングが、
値が 0.0 以上であるmaxFramerate
メンバーを持つことを確認する。いずれかの
maxFramerate
値がこの要件を満たさない場合、新たに作成されたRangeErrorで
拒否された
Promise を返す。
ユーザーエージェントが、いずれかのエンコーディングにコーデックを設定すること、
または異なるエンコーディング間で異なる
コーデック値を混在させることをサポートしていない場合、新たに
作成された
OperationErrorで
拒否された
Promise を返す。
[[SenderTrack]]を
送信するよう構成する。
[[LastReturnedParameters]]
をnullに設定する。
[[SendEncodings]]
を
parameters.encodings
に設定する。
undefinedで
pを解決する。
errorDetail
が
"hardware-encoder-not-available"
に設定された、新たに作成されたRTCErrorで
pを拒否し、
これらの手順を中止する。
errorDetail
が
"hardware-encoder-error"
に設定された、新たに作成されたRTCErrorで
pを拒否し、
これらの手順を
中止する。
OperationErrorで
pを
拒否する。
setParametersは
SDP の再ネゴシエーションを引き起こさず、
オファー/アンサーによってネゴシエーションされたエンベロープ内で
メディアスタックが送信または受信する内容を変更するためにのみ使用できる。
RTCRtpSendParameters
辞書内の属性は、
これを可能にしないよう設計されているため、
変更できない
cnameなどの属性は
読み取り専用である。ビットレートなどのその他の事項は、
maxBitrate
などの上限を使用して制御される。この場合、
ユーザーエージェントは、
SDP などの他の場所で指定されたビットレートに関する制約も
満たしながら、同時にmaxBitrate
で指定された最大
ビットレートを超えないようにする必要がある。
getParameters
getParameters()
メソッドは、RTCRtpSender
オブジェクトの、trackがどのようにエンコードされ、
リモートRTCRtpReceiverへ送信されるかについての
現在のパラメーターを返す。
getParametersが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
senderを、getter が呼び出されたRTCRtpSender オブジェクトとする。
sender.[[LastReturnedParameters]]
がnullでない場合、
sender.[[LastReturnedParameters]]を返し、
これらの手順を
中止する。
resultを、次のように構築された新しいRTCRtpSendParameters
辞書とする。
transactionId
を新しい
一意の識別子に設定する。
encodings
を
[[SendEncodings]]
内部スロットの値に設定する。
headerExtensions
シーケンスを、
送信用にネゴシエーションされたヘッダー拡張に基づいて
設定する。
codecsを
[[SendCodecs]]内部
スロットの値に設定する。
rtcp.cnameを、
関連付けられたRTCPeerConnectionの
CNAME に設定する。
送信用に reduced-size RTCP が
ネゴシエーションされている場合は、
rtcp.reducedSize
をtrueに設定し、それ以外の場合はfalseに設定する。
sender.[[LastReturnedParameters]]
をresultに設定する。
sender.[[LastReturnedParameters]]
を
nullに設定するタスクをキューに入れる。
resultを返す。
getParametersは、
次の方法でパラメーターを変更するために
setParametersとともに
使用できる。
async function updateParameters() {
try {
const params = sender.getParameters();
// ... パラメーターを変更する
params.encodings[0].active = false;
await sender.setParameters(params);
} catch (err) {
console.error(err);
}
}
setParametersの
呼び出しが完了した後、
以後の
getParametersの呼び出しは、
変更された
パラメーターの集合を返す。
replaceTrack
再ネゴシエーションを行わずに、
RTCRtpSenderの現在のtrackを、
指定された別のトラック(またはnullの
トラック)に置き換えることを試みる。
replaceTrack メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
senderを、replaceTrack
が呼び出されたRTCRtpSender オブジェクトとする。
transceiverを、senderに関連付けられたRTCRtpTransceiver
オブジェクトとする。
connectionを、senderに関連付けられたRTCPeerConnection
オブジェクトとする。
withTrackをこのメソッドへの引数とする。
withTrackが null でなく、
withTrack.kindが
transceiverのトランシーバー種別
と異なる場合、新たに作成されたTypeErrorで
拒否された Promise を返す。
次の手順をconnectionの操作チェーンに連鎖させた 結果を返す。
transceiver.[[Stopping]]が
trueである場合、新たに作成された
InvalidStateErrorで
拒否された
Promise を返す。
pを新しい Promise とする。
transceiver.[[CurrentDirection]]
が "sendrecv"
または
"sendonly"
である場合はsendingをtrueとし、
それ以外の場合は
falseとする。
次の手順を並行して実行する。
sendingがtrueであり、
withTrackがnullである場合、
sender に送信を停止させる。
sendingがtrueであり、
withTrackがnullでない場合、
sender のすでにネゴシエーションされたエンベロープに
違反することなく、withTrackを sender が
直ちに送信できるかどうかを判定し、
できない場合は次を実行する。
InvalidModificationErrorで
pを拒否する。
sendingがtrueであり、
withTrackがnullでない場合、
sender の既存のトラックに代えて
withTrackを送信するよう、
sender にシームレスに切り替えさせる。
次の手順を実行するタスクをキューに入れる。
connection.[[IsClosed]]
がtrueである場合、これらの手順を中止する。
sender.[[SenderTrack]]
をwithTrackに設定する。
現在のレルムのグローバルオブジェクトを
globalとして与え、
ネットワーキングタスク
ソース上にグローバル
タスクをキューに入れ、
undefinedで
pを解決する。
pを返す。
寸法やフレームレートを変更しても ネゴシエーションが必要ない場合がある。ネゴシエーションが必要となり得る例には次がある。
setStreams
この sender のトラックに関連付ける
MediaStream群を設定する。
setStreams メソッドが
呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
senderを、このメソッドが呼び出されたRTCRtpSender オブジェクトとする。
connectionを、このメソッドが呼び出されたRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを投げる。
streamsを、メソッドの引数から構築したMediaStream
オブジェクトのリストとし、メソッドが引数なしで呼び出された場合は
空のリストとする。
sender.[[AssociatedMediaStreamIds]]
を
空集合に設定する。
streams内の各streamについて、
stream.idがまだ
[[AssociatedMediaStreamIds]]
に存在しない場合、そこへ追加する。
connectionについてネゴシエーション必要フラグを 更新する。
getStats
この sender の統計情報のみを収集し、その結果を 非同期に報告する。
getStats()
メソッドが呼び出された場合、ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
selectorを、メソッドが呼び出されたRTCRtpSender オブジェクトとする。
pを新しい Promise とし、次の 手順を並行して実行する。
統計選択 アルゴリズムに従って、selectorによって示される統計情報を 収集する。
現在のレルムのグローバルオブジェクトを
globalとして与え、
ネットワーキングタスクソース上に
グローバルタスクをキューに入れ、
収集された統計情報を含む、結果のRTCStatsReport
オブジェクトで
pを解決する。
pを返す。
WebIDLdictionary RTCRtpParameters {
required sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
required RTCRtcpParameters rtcp;
required sequence<RTCRtpCodecParameters> codecs;
};
RTCRtpParameters のメンバー
headerExtensions 型 sequence<RTCRtpHeaderExtensionParameters>,
必須
RTP ヘッダー拡張のパラメータを含むシーケンス。 読み取り専用パラメータ。
rtcp 型 RTCRtcpParameters,
必須
RTCP に使用されるパラメータ。読み取り専用パラメータ。
codecs
型 sequence<RTCRtpCodecParameters>,
必須
RTCRtpSender が選択するメディアコーデックや、
RTX、RED、FEC メカニズムのエントリを含むシーケンス。
RTX を介した再送が有効になっている各メディアコーデックに対応するエントリが、
codecs に含まれ、
mimeType 属性で
audio/rtx または
video/rtx を介した再送を示し、
sdpFmtpLine 属性("apt"
および "rtx-time" パラメータを提供)を持つ。
読み取り専用パラメータ。
WebIDLdictionary RTCRtpSendParameters : RTCRtpParameters {
required DOMString transactionId;
required sequence<RTCRtpEncodingParameters> encodings;
};
RTCRtpSendParameters
のメンバー
transactionId 型 DOMString, 必須
適用された最後のパラメータセットに対する一意の識別子。
setParameters
が、以前の
getParameters
に基づいてのみ呼び出され、介入する変更がないことを保証する。
読み取り専用パラメータ。
encodings 型 sequence<RTCRtpEncodingParameters>,
必須
メディアの RTP エンコーディングに関するパラメータを含むシーケンス。
WebIDLdictionary RTCRtpReceiveParameters : RTCRtpParameters {
};
WebIDLdictionary RTCRtpCodingParameters {
DOMString rid;
};
RTCRtpCodingParameters
のメンバー
rid 型 DOMString
設定された場合、この RTP エンコーディングは
[RFC9429]
(セクション
5.2.1.) で定義されている RID ヘッダー拡張を使用して送信される。
RID は
setParameters
によって変更することはできない。
送信側では
addTransceiver
の中でのみ設定または変更可能である。
読み取り専用パラメータ。
WebIDLdictionary RTCRtpEncodingParameters : RTCRtpCodingParameters {
boolean active = true;
RTCRtpCodec codec;
unsigned long maxBitrate;
double maxFramerate;
double scaleResolutionDownBy;
};
RTCRtpEncodingParameters
のメンバー
active 型 boolean, デフォルト値
true
このエンコーディングがアクティブに送信されていることを示します。
false に設定すると、このエンコーディングの送信が停止されます。
true に設定すると、このエンコーディングが送信されます。
値を false に設定しても SSRC が削除されることはないため、
RTCP BYE メッセージは送信されません。
codec 型 RTCRtpCodec
このエンコーディングの RTP ストリームに使用されるコーデックを選択するためのオプション値。 存在しない場合、ユーザーエージェントは送信用にネゴシエートされた任意のコーデックを使用することができます。
codec
が設定され、
[[SendCodecs]]
がネゴシエートされている場合、
ユーザーエージェントは、送信用に
codec
に一致する
[[SendCodecs]]
の最初のものを使用する SHOULD。
このマッチングは、
codec
dictionary match
アルゴリズムを使用し、
ignoreLevels を true に設定して行われます。
maxBitrate 型 unsigned long
存在する場合、このエンコーディングを送信するために使用できる最大ビットレートを示します。
ユーザーエージェントは、
maxBitrate
の値を超えない範囲で、エンコーディング間で帯域幅を自由に割り当てることができます。
エンコーディングは、ここで指定された最大値よりもさらに制約を受ける場合もあります(たとえば、トランスポートやセッションごとの帯域幅制限など)。
maxBitrate
は、[RFC3890]
セクション 6.2.2 で定義されているトランスポートに依存しないアプリケーション固有の最大値(TIAS)と同じ方法で計算されます。
これは、IP や TCP、UDP などの他のトランスポートレイヤを含まない最大帯域幅を指します。
maxBitrate
の単位はビット毎秒です。
ビットレートの実現方法は、メディアとエンコーディングに依存します。 ビデオの場合、フレームは常に可能な限り速く送信されますが、ビットレートが十分に低くなるまでフレームがドロップされる可能性があります。 したがって、ビットレートがゼロであっても 1 フレームの送信は可能です。 オーディオの場合、選択したエンコーディングに十分な帯域幅を送信できない場合、再生を停止する必要があるかもしれません。
maxFramerate 型 double
このメンバーは、送信者の kind が
"video" の場合にのみ存在します。
存在する場合、このエンコーディングを送信するために使用できる最大フレームレートを示します(単位は fps)。
ユーザーエージェント
は、
maxFramerate
の値を超えない範囲でエンコーディング間の帯域幅を自由に割り当てることができます。
もし
setParameters()
で変更された場合、新しいフレームレートは現在のピクチャが完了した後に反映されます。
最大フレームレートをゼロに設定すると、次のフレームでビデオがフリーズする効果があります。
scaleResolutionDownBy 型
double
このメンバーは、送信者の kind が
"video" の場合にのみ存在します。
動画の解像度は、送信前に指定された値で各次元をスケールダウンします。
たとえば、値が 2.0 の場合、ビデオは各次元で 2 倍スケールダウンされ、結果として 1/4 サイズのビデオが送信されます。
値が 1.0 の場合、ビデオには影響しません。
値は 1.0 以上である必要があります。
デフォルトでは、スケーリングは逆順で 2 倍の因数を使用して適用され、解像度が小さい順から大きい順に並びます(例: 4:2:1)。
レイヤーが 1 つだけの場合、送信者はデフォルトでスケーリングを適用しません(すなわち
scaleResolutionDownBy
は 1.0 となります)。
WebIDLdictionary RTCRtcpParameters {
DOMString cname;
boolean reducedSize;
};
RTCRtcpParameters のメンバー
cname
型 DOMString
RTCP によって使用されるカノニカル名 (CNAME)(例: SDES メッセージ内)。 読み取り専用パラメータ。
reducedSize 型 boolean
縮小サイズの RTCP [RFC5506] が構成されている場合(true)、または [RFC3550] で指定された複合 RTCP(false)。 読み取り専用パラメータ。
WebIDLdictionary RTCRtpHeaderExtensionParameters {
required DOMString uri;
required unsigned short id;
boolean encrypted = false;
};
RTCRtpHeaderExtensionParameters
のメンバー
uri 型 DOMString, 必須
RTP ヘッダー拡張の URI。[RFC5285] に定義されている。 読み取り専用パラメータ。
id 型 unsigned short, 必須
ヘッダー拡張を識別するために RTP パケットに挿入される値。 読み取り専用パラメータ。
encrypted 型 boolean
ヘッダー拡張が暗号化されているかどうか。 読み取り専用パラメータ。
RTCRtpHeaderExtensionParameters
辞書は、アプリケーションがヘッダー拡張が RTCRtpSender または RTCRtpReceiver
内で構成されているかどうかを確認できるようにします。
RTCRtpTransceiver の
transceiver に対して、
アプリケーションは SDP を解析することなく、以下のようにヘッダー拡張の "direction" パラメータ([RFC5285] セクション 5
で定義)を判断できます。
sender.getParameters().headerExtensions
にのみ含まれます。
receiver.getParameters().headerExtensions
にのみ含まれます。
sender.getParameters().headerExtensions
と
transceiver.receiver.getParameters().headerExtensions
の両方に含まれます。
sender.getParameters().headerExtensions
にも
transceiver.receiver.getParameters().headerExtensions
にも含まれません。
WebIDLdictionary RTCRtpCodec {
required DOMString mimeType;
required unsigned long clockRate;
unsigned short channels;
DOMString sdpFmtpLine;
};
RTCRtpCodec のメンバー
RTCRtpCodec
辞書はコーデックオブジェクトに関する情報を提供します。
mimeType 型 DOMString, 必須
コーデックの MIME メディアタイプ/サブタイプ。 有効なメディアタイプおよびサブタイプは [IANA-RTP-2] に記載されています。
clockRate 型 unsigned long, 必須
コーデックのクロックレート(ヘルツ単位)。
channels 型 unsigned short
存在する場合、チャネルの最大数(モノラル=1、ステレオ=2)を示します。
sdpFmtpLine 型 DOMString
コーデックに対応する SDP 内の a=fmtp 行の "format specific parameters"
フィールド。
存在する場合、以下の定義に従います。
[RFC9429]
(セクション
5.8)。
WebIDLdictionary RTCRtpCodecParameters : RTCRtpCodec {
required octet payloadType;
};
RTCRtpCodecParameters
メンバー
RTCRtpCodecParameters
辞書はネゴシエートされたコーデックに関する情報を提供します。
RTCRtpCodec
から継承されたフィールドはすべて
読み取り専用パラメータ
でなければなりません。
RTCRtpSenderの場合、sdpFmtpLineパラメータは
[[CurrentRemoteDescription]]
から取得され、
RTCRtpReceiverの場合、それらはローカル記述(
[[PendingLocalDescription]]
がnullでない場合はそこから取得され、
[[CurrentLocalDescription]]
それ以外の場合はそこから取得されます)。
payloadType 型 octet, 必須
このコーデックを識別するために使用されるRTPペイロードタイプ。 読み取り専用パラメータ。
WebIDLdictionary RTCRtpCapabilities {
required sequence<RTCRtpCodec> codecs;
required sequence<RTCRtpHeaderExtensionCapability> headerExtensions;
};
RTCRtpCapabilities メンバー
codecs 型 sequence<RTCRtpCodec>,
必須
サポートされているメディアコーデック、RTX、REDおよびFECメカニズムのエントリ。 生成されたSDPオファーで異なるペイロードタイプを利用する組み合わせのみが提供されるべきです。 例:
再送信をRTXで行う場合、codecsには単一のエントリしか存在してはならず、
sdpFmtpLineは存在してはなりません。
headerExtensions 型 sequence<RTCRtpHeaderExtensionCapability>,
必須
サポートされているRTPヘッダー拡張。
WebIDLdictionary RTCRtpHeaderExtensionCapability {
required DOMString uri;
};
RTCRtpHeaderExtensionCapability
のメンバー
uri 型 DOMString, 必須
RTP ヘッダー拡張の URI。[RFC5285] に定義されている。
WebIDLdictionary RTCSetParameterOptions {
};
RTCSetParameterOptions
のメンバーRTCSetParameterOptions は拡張性を考慮して、空の辞書として定義されています。
RTCRtpReceiver インターフェイスは、
アプリケーションが MediaStreamTrack の受信を検査できるようにする。
文字列 kind を用いて RTCRtpReceiver を作成するには、次の手順を実行する:
receiver を新しい RTCRtpReceiver オブジェクトとする。
track を新しい MediaStreamTrack オブジェクト
[GETUSERMEDIA] とする。track のソースは
receiver によって提供される
リモートソース である。
なお、track.id は
ユーザーエージェント によって生成され、リモート側のいかなるトラック ID にも対応しない。
track.kind を kind に初期化する。
文字列 "remote " と kind を連結した結果で
track.label を初期化する。
track.readyState を live に初期化する。
track.muted を true に初期化する。MediaStreamTrack
セクションでは、属性 muted が
MediaStreamTrack がメディアデータを受信しているかどうかを
どのように反映するかについて説明している。
receiver に内部スロット [[ReceiverTrack]] を持たせ、track で初期化する。
receiver に内部スロット [[ReceiverTransport]]
を持たせ、null で初期化する。
receiver に内部スロット
[[LastStableStateReceiverTransport]] を持たせ、
null で初期化する。
receiver に内部スロット
[[AssociatedRemoteMediaStreams]] を持たせる。
これはこのレシーバの MediaStreamTrack オブジェクトが関連付けられている
MediaStream オブジェクトのリストを表し、空のリストで初期化する。
receiver に内部スロット [[LastStableStateAssociatedRemoteMediaStreams]] を持たせ、空のリストで初期化する。
receiver に内部スロット [[ReceiveCodecs]]
を持たせる。これは RTCRtpCodecParameters
辞書のリストを表し、空のリストで初期化する。
receiver に内部スロット [[LastStableStateReceiveCodecs]] を持たせ、 空のリストで初期化する。
receiver に内部スロット [[JitterBufferTarget]]
を持たせ、null で初期化する。
receiver を返す。
WebIDL[Exposed=Window]
interface RTCRtpReceiver {
readonly attribute MediaStreamTrack track;
readonly attribute RTCDtlsTransport? transport;
static RTCRtpCapabilities? getCapabilities(DOMString kind);
RTCRtpReceiveParameters getParameters();
sequence<RTCRtpContributingSource> getContributingSources();
sequence<RTCRtpSynchronizationSource> getSynchronizationSources();
Promise<RTCStatsReport> getStats();
attribute DOMHighResTimeStamp? jitterBufferTarget;
};
track の型
MediaStreamTrack, 読み取り専用
track 属性は、
この RTCRtpReceiver オブジェクト
receiver に関連付けられているトラックである。
track.stop() は最終的な動作であり、
クローンには影響しない点に注意。receiver.track.stop() は
receiver を暗黙的に停止させないため、レシーバレポートは送信され続ける。
取得時、この属性は MUST
[[ReceiverTrack]]
スロットの値を返さなければならない。
transport の型 RTCDtlsTransport,
読み取り専用, nullable
transport 属性は、
レシーバの track のメディアが RTP
パケットの形で受信される
トランスポートである。RTCDtlsTransport
オブジェクトの構築前は、
transport 属性は
null となる。バンドリングが使用される場合、複数の
RTCRtpReceiver オブジェクトは
1 つの transport を共有し、
同じトランスポート上で RTP および RTCP をすべて受信する。
取得時、この属性は MUST
[[ReceiverTransport]]
スロットの値を返さなければならない。
jitterBufferTarget の型 DOMHighResTimeStamp, nullable
この属性により、RTCRtpReceiver のジッタバッファが保持する
メディアの目標時間(ミリ秒)をアプリケーションが指定できる。
これは ユーザーエージェント によるバッファリング量に影響し、
ひいては再送やパケットロス復旧にも影響する。目標値を変更することで、
再生遅延とネットワークジッタにより音声・映像フレームが枯渇するリスクとのトレードオフを制御できる。
ユーザーエージェント は、 許容最小ターゲット と 許容最大ターゲット を持つ MUST。 これらはネットワーク状況やメモリ制約に基づき、 ユーザーエージェント が提供可能または提供意図のある範囲を反映し、 いつでも変化しうる。
これは目標値である。遅延の変化は時間とともに徐々に観測されうる。
レシーバの平均ジッタバッファ遅延は、
jitterBufferDelay
の差分を
jitterBufferEmittedCount
の差分で割ることで測定できる。
DTX を使用している場合でも平均遅延は想定される。例えば DTX 使用時に無音後にパケットが流れ始めると、 目標値を大きくすることで ユーザーエージェント が それらのパケットを再生するのではなくバッファリングするよう影響しうる。
取得時、この属性は MUST
[[JitterBufferTarget]]
内部スロットの値を返さなければならない。
設定時、ユーザーエージェント は次の手順を実行する MUST:
receiver を、セッターが呼び出された
RTCRtpReceiver
オブジェクトとする。
target をセッターへの引数とする。
もし target が負または 4000 ミリ秒を超えるなら、
例外を投げ、
RangeError とする。
receiver の
[[JitterBufferTarget]]
を target に設定する。
track を、receiver の
[[ReceiverTrack]] とする。
並行して、次の手順の実行を開始する:
基盤システムに新しい target を通知する。
ただし target が null の場合はアプリケーションの希望がないことを通知する。
もし track が別の
RTCRtpReceiver
のトラックと
音声/映像の同期
のために同期されている場合、
ユーザーエージェント は両レシーバに対して
2 つの [[JitterBufferTarget]]
のうち大きい方を用いる
SHOULD。
基盤システムがジッタバッファターゲットを適用している間は、 実際のジッタバッファターゲットが常に 許容最小ターゲット と 許容最大ターゲット の範囲内にクランプされるようにする。
ユーザーエージェント が
要求とは異なるターゲット(例: ネットワーク状況や物理メモリ制約による)を最終的に用いたとしても、
これは
[[JitterBufferTarget]]
内部スロットには反映されない。
基盤システムのジッタバッファターゲットの変更は、 ユーザー体験を損なわないよう内部の音声または映像のバッファリングに段階的に影響する SHOULD。 音声サンプルや映像フレームは再生前に加速または減速される SHOULD。 これは 音声/映像の同期 や輻輳制御への対応と同様である。
加速や減速の速度は、ネットワーク状況や受信している音声の種類(例: 音声、背景雑音)に応じて変化しうる。 パケットが受信されていることを前提に、1 秒のバッファリングを達成するまでに数秒かかる MAY が、30 秒を超えるべきではない SHOULD。速度は音声と映像で異なってもよい MAY。
音声については、加速・減速は
insertedSamplesForDeceleration
および
removedSamplesForAcceleration
によって測定できる。映像では、同一フレームを複数回レンダリングしたり、フレームがドロップされることがある。
getCapabilities(静的)
static RTCRtpReceiver.getCapabilities()
メソッドは、リソース、ポート、その他の状態を予約することなく、
指定された種類のメディアを受信するためにユーザーエージェントがサポートする
機能の種類を検出する手段を提供する。
getCapabilities
メソッドが呼び出された場合、ユーザーエージェントは次の
手順を実行しなければならない(MUST)。
kindをメソッドの第1引数とする。
kindが"video"でも"audio"でもない場合、
nullを返す。
新しいRTCRtpCapabilities
辞書を返す。その
codecsメンバーは、
kindについての
実装済み受信
コーデックのリストで初期化し、その
headerExtensions
メンバーは、kindについての
実装済み
受信用ヘッダー拡張のリストで初期化する。
kindを与えた場合の実装済み受信
コーデックのリストは、指定された
kind(video または audio)のメディアを受信するために
ユーザーエージェントがサポートするコーデックについて最も楽観的な見方を表す、
RTCRtpCodec辞書の
実装定義リストである。
kindが与えられた場合の実装済み受信用ヘッダー拡張の
リストは、
kindについての実装定義の
RTCRtpHeaderExtensionCapability
辞書のリストであり、指定されたkind(video または audio)のメディアを受信するために
ユーザーエージェントがサポートするヘッダー拡張についての楽観的な
見方を表す。
これらの機能は、デバイスに関する一般に永続的なオリジン横断
情報を提供するため、アプリケーションの
フィンガープリンティング面を増大させる。
プライバシーに敏感な状況では、ユーザーエージェントは、
機能の共通サブセットのみを報告するなどの
緩和策を検討してもよい(MAY)。
返されるコーデック機能は、
setCodecPreferences()
アルゴリズムと、どの入力に対して
InvalidModificationError
を投げるかに影響する。また、
プライバシー緩和策が有効になることを保証するため、
createOffer()
およびcreateAnswer()
が受信用にネゴシエーションされたコーデックについて
明らかにする情報とも整合しているべきである。
getParameters
getParameters()
メソッドは、RTCRtpReceiver オブジェクトにおける、
track
がどのようにデコードされるかの現在のパラメータを返す。
getParameters
が呼び出されたとき、
RTCRtpReceiveParameters
辞書は次のように構築される:
headerExtensions
シーケンスは、レシーバが現在受信する準備ができているヘッダー拡張に基づいて設定される。
codecs は、
内部スロット
[[ReceiveCodecs]]
の値に設定される。
getParameters
からすべてを返す。
しかしリモートエンドポイントが 2 つだけで回答した場合、欠けているコーデックは
レシーバがもはや受信準備をする必要がないため
getParameters
では返されなくなる。
rtcp.reducedSize
は、レシーバが現在 reduced-size RTCP パケットを受信する準備ができていれば true、
そうでなければ false に設定される。
rtcp.cname は含めない。
getContributingSources
この RTCRtpReceiver が直近 10 秒間に受信した
各一意の CSRC 識別子について、
降順の timestamp 順で
RTCRtpContributingSource
を返す。
getSynchronizationSources
この RTCRtpReceiver が直近 10 秒間に受信した
各一意の SSRC 識別子について、
降順の
timestamp
順で
RTCRtpSynchronizationSource
を返す。
getStats
このレシーバに関する統計のみを収集し、その結果を非同期に報告する。
getStats()
メソッドが呼び出されたとき、ユーザーエージェントは次の手順を実行する
MUST:
selector を、このメソッドが呼び出された
RTCRtpReceiver
オブジェクトとする。
p を新しい Promise とし、次の手順を 並行して実行する:
selector によって示される統計を、 統計選択アルゴリズム に従って収集する。
現在の realm の グローバルオブジェクト を
global として、
ネットワーキングタスクソース 上に
グローバルタスクをキューし、
収集した統計を含む
RTCStatsReport
オブジェクトで
resolve により
p を解決する。
p を返す。
RTCRtpContributingSource および
RTCRtpSynchronizationSource 辞書は、
それぞれ特定の寄与ソース(CSRC)または同期ソース(SSRC)に関する情報を含む。
1 つ以上の RTP パケットからの音声または映像フレームが
RTCRtpReceiver の
MediaStreamTrack に配信されると、
ユーザーエージェントは、そのパケットの内容に基づいて
関連する RTCRtpContributingSource と
RTCRtpSynchronizationSource
の情報を更新するタスクを
キューに入れる MUST。
SSRC 識別子に対応する
RTCRtpSynchronizationSource 辞書に
関連する情報は毎回更新され、RTP パケットが CSRC 識別子を含む場合には、
それら CSRC 識別子に対応する
RTCRtpContributingSource
辞書に関連する情報も更新される。
ユーザーエージェントは RTP パケットを RTP タイムスタンプの昇順で処理する
MUST。ユーザーエージェントは直近 10 秒間に
RTCRtpReceiver の
MediaStreamTrack に配信された RTP パケットからの情報を保持する
MUST。
MediaStreamTrack が再生のためにいかなるシンクにも接続されていなくても、
トラックが終了していない限り、
getSynchronizationSources
および
getContributingSources
は最新の情報を返す。シンクは RTP パケットのデコードの前提条件ではない。
RTCRtpReceiverについて返されるすべての
RTCRtpSynchronizationSourceおよび
RTCRtpContributingSource
辞書が、RTP
ストリーム内の単一の時点からの情報を含むのであれば、
フレームごとに文字どおりタスクをキューに入れる必要はない。
WebIDLdictionary RTCRtpContributingSource {
required DOMHighResTimeStamp timestamp;
required unsigned long source;
double audioLevel;
required unsigned long rtpTimestamp;
};
timestamp の型
DOMHighResTimeStamp, 必須
このソースに由来する RTP パケットからのフレームが最後に
RTCRtpReceiver の
MediaStreamTrack に配信された時刻を示す
timestamp。
timestamp は、
その時点の
Performance.timeOrigin +
Performance.now() と定義される。
source の型 unsigned
long, 必須
寄与ソースまたは同期ソースの CSRC または SSRC 識別子。
audioLevel の型 double
音声レシーバにのみ存在する。これは 0..1(線形)の値で、1.0 は 0 dBov、0 は無音、 0.5 は 0 dBov から約 6 dBSPL の音圧レベルの変化を表す。
CSRC に対しては、RFC 6465 ヘッダー拡張が存在する場合、 [RFC6465] で定義された レベル値から変換される MUST。存在しない場合、このメンバーは 省略される MUST。
SSRC に対しては、[RFC6464] で定義された レベル値から変換される MUST。 受信パケットに RFC 6464 ヘッダー拡張が存在しない場合(相手がユーザーエージェントでない、またはレガシーエンドポイントなど)、 この値は省略される SHOULD。
両 RFC はレベルを 0 から 127 の整数値として定義し、 システムがエンコード可能な最大の信号に対する負のデシベルでの音量を表す。 したがって、0 はシステムがエンコード可能な最大の信号、127 は無音を表す。
これらの値を 0..1 の線形範囲に変換するには、127 を 0 に変換し、
他のすべての値は次の式を用いて変換する: 10^(-rfc_level/20)。
rtpTimestamp の型 unsigned long, 必須
timestamp において再生されたメディアの RTP タイムスタンプ。 [RFC3550] セクション 5.1 に定義される。
WebIDLdictionary RTCRtpSynchronizationSource : RTCRtpContributingSource {};
RTCRtpSynchronizationSource
辞書は、仕様が SSRC にのみ存在するデータを公開するための拡張ポイントとして機能することが期待されている。
RTCRtpTransceiver
インターフェイスは、共通の
メディアストリーム「identification-tag」
を共有する RTCRtpSender と
RTCRtpReceiver の組み合わせを表す。
[RFC9429] (セクション 3.4.1) で定義されるように、
RTCRtpTransceiver
は、その「mid」プロパティが null でなく、
メディア記述内の
メディアストリーム「identification-tag」 と一致する場合、
その メディア記述 に
関連付けられている と言い、
そうでなければ、その メディア記述 と切り離されていると言う。
RTCRtpTransceiver は、現行の記述とは
切り離されたまま、RFC9429 の新しい保留中の記述に関連付けられる場合がある。
これは ネゴシエーションが必要かの確認
において起こりうる。
RTCRtpTransceiver の
トランシーバの kind は、
関連付けられた RTCRtpReceiver の
MediaStreamTrack オブジェクトの kind によって定義される。
RTCRtpTransceiver を作成する ために、
RTCRtpReceiver オブジェクト
receiver、RTCRtpSender オブジェクト
sender、および RTCRtpTransceiverDirection 値
direction を用いて、次の手順を実行する:
transceiver を新しい RTCRtpTransceiver オブジェクトとする。
transceiver に内部スロット [[Sender]] を持たせ、 sender で初期化する。
transceiver に内部スロット [[Receiver]] を持たせ、receiver で初期化する。
transceiver に内部スロット
[[Stopping]]
を持たせ、false で初期化する。
transceiver に内部スロット
[[Stopped]]
を持たせ、false で初期化する。
transceiver に内部スロット [[Direction]] を持たせ、direction で初期化する。
transceiver に内部スロット
[[Receptive]]
を持たせ、false で初期化する。
transceiver に内部スロット
[[CurrentDirection]]
を持たせ、null で初期化する。
transceiver に内部スロット
[[FiredDirection]]
を持たせ、null で初期化する。
transceiver に内部スロット [[PreferredCodecs]] を持たせ、空のリストで初期化する。
transceiver に内部スロット
[[JsepMid]]
を持たせ、null で初期化する。これは
[RFC9429] (セクション 5.2.1 および
セクション 5.3.1)
で定義される
「RtpTransceiver mid property」であり、そこでのみ変更される。
transceiver に内部スロット
[[Mid]]
を持たせ、null で初期化する。
transceiver を返す。
RTCDtlsTransport および
RTCIceTransport
オブジェクトは作成されない。
これは セッション記述の設定
の処理の一部としてのみ行われる。
WebIDL[Exposed=Window]
interface RTCRtpTransceiver {
readonly attribute DOMString? mid;
[SameObject] readonly attribute RTCRtpSender sender;
[SameObject] readonly attribute RTCRtpReceiver receiver;
attribute RTCRtpTransceiverDirection direction;
readonly attribute RTCRtpTransceiverDirection? currentDirection;
undefined stop();
undefined setCodecPreferences(sequence<RTCRtpCodec> codecs);
};
mid 型は DOMString、読み取り専用、nullable
mid 属性は、ローカル
およびリモート記述でネゴシエーションされ、存在するメディアストリーム
「識別タグ」である。取得時、この属性は
[[Mid]] スロットの値を返さなければならない(MUST)。
sender 型は RTCRtpSender、読み取り専用
sender 属性は、
mid =
[[Mid]] で送信される可能性のある RTP メディアに対応する
RTCRtpSender
を公開する。取得時、この属性は
[[Sender]] スロットの
値を返さなければならない(MUST)。
receiver 型は RTCRtpReceiver、読み取り専用
receiver 属性は、
mid
= [[Mid]] で受信される可能性のある RTP メディアに対応する
RTCRtpReceiver
である。取得時、この属性は
[[Receiver]] スロットの
値を返さなければならない(MUST)。
direction 型は RTCRtpTransceiverDirection
[RFC9429]
(4.2.4
節)で定義されているように、
direction 属性はこのトランシーバーの優先
方向を示し、これは
createOffer および
createAnswer
の呼び出しで使用される。
方向性の更新は直ちには有効にならない。代わりに、
以後の createOffer および
createAnswer
の呼び出しは、対応するメディア記述を
[RFC9429]
(5.2.2 節
および 5.3.2
節)で定義されているように、
sendrecv、
sendonly、recvonly または inactive として
マークする。
取得時、ユーザーエージェントは次の手順を実行しなければならない(MUST)。
transceiverを、getter が呼び出されたRTCRtpTransceiver
オブジェクトとする。
transceiver.[[Stopping]] が
trueである場合、
"stopped"
を返す。
それ以外の場合、[[Direction]]
スロットの値を返す。
設定時、ユーザーエージェントは次の手順を実行しなければならない(MUST)。
transceiverを、setter が呼び出されたRTCRtpTransceiver
オブジェクトとする。
connectionを、transceiverに関連付けられたRTCPeerConnection
オブジェクトとする。
transceiver.[[Stopping]] が
trueである場合、
InvalidStateErrorを投げる。
newDirectionを setter への引数とする。
newDirectionが
transceiver.[[Direction]]と等しい場合、これらの
手順を中止する。
transceiver.[[Direction]]を
newDirectionに設定する。
connectionについてネゴシエーション必要 フラグを更新する。
currentDirection 型は RTCRtpTransceiverDirection、
読み取り専用、
nullable
[RFC9429]
(4.2.5
節)で定義されているように、
currentDirection 属性は、このトランシーバーについて現在
ネゴシエーションされている方向を示す。
currentDirectionの値は、
RTCRtpEncodingParameters.active
の値とは独立している。これは、一方から他方を推論できないためである。この
トランシーバーがオファー/アンサー
交換で一度も表現されていない場合、値はnullである。トランシーバー
がstoppedである場合、値
は
"stopped"
である。
取得時、ユーザーエージェントは次の手順を実行しなければならない(MUST)。
transceiverを、getter が呼び出されたRTCRtpTransceiver
オブジェクトとする。
transceiver.[[Stopped]] が
trueである場合、
"stopped"
を返す。
それ以外の場合、
[[CurrentDirection]]
スロットの値を返す。
stop
トランシーバーがすでにstoppedでない限り、
トランシーバーを不可逆的にstoppingとしてマークする。これにより直ちに、
トランシーバーの sender は送信しなくなり、その receiver は
受信しなくなる。stop()を呼び出すと、
ネゴシエーション必要
フラグを更新することにもなり、対象はRTCRtpTransceiverに
関連付けられた
RTCPeerConnectionである。
stopping状態のトランシーバーは、以後の
createOfferの呼び出しにより、
対応するトランシーバーの
メディア記述に
ゼロポートが生成される。これは[RFC9429]
(4.2.1
節)で定義されている(この場合に限り、ユーザーエージェントは
RFC9429 の目的上、stopping
状態のトランシーバーをstoppedとして扱わなければならない
(MUST))。ただし、
[RFC8843]
に関する問題を回避するため、stopping状態ではあるが
stoppedではない
トランシーバーは、
createAnswerには影響しない。
stopped状態のトランシーバーは、以後の
createOfferまたは
createAnswerの呼び出しにより、
対応するトランシーバーの
メディア記述に
ゼロポートが生成される。これは[RFC9429]
(4.2.1
節)で定義されている。
トランシーバーは、リモートのオファーまたはアンサー内の
拒否された m-line をsetRemoteDescription
が処理することによって
stoppedにならない限り、
stopping状態のままとなる。
stopping状態ではあるがstoppedではないトランシーバーは、
常にネゴシエーションを必要とする。実際には、これはトランシーバー上で
stop()
を呼び出すと、両端でネゴシエーションが
完了できる限り、最終的にトランシーバーがstoppedになることを意味する。
stopメソッドが呼び出された場合、
ユーザーエージェントは
次の手順を実行しなければならない(MUST)。
transceiverを、メソッドが呼び出されたRTCRtpTransceiver
オブジェクトとする。
connectionを、transceiverに関連付けられたRTCPeerConnection
オブジェクトとする。
connection.[[IsClosed]]が
trueである場合、
InvalidStateErrorを投げる。
transceiver.[[Stopping]]が
trueである場合、これらの手順を中止する。
transceiverを用いて送信と 受信を停止する。
connectionについてネゴシエーション必要 フラグを更新する。
transceiverと、任意で、デフォルト値が
falseであるdisappearブール値を与えた場合の
送信と受信を停止するアルゴリズムは、
次のとおりである。
senderを
transceiver.[[Sender]]とする。
receiverを
transceiver.[[Receiver]]とする。
並行して、senderによるメディア送信を停止し、 [RFC3550]で規定されているように、 senderによって送信されていた各 RTP ストリームについて RTCP BYE を送信する。
並行して、receiverによる メディア受信を停止する。
disappearがfalseである場合、
receiver.[[ReceiverTrack]]を
終了済みにするための手順を実行する。
これによりイベントが発火する。
transceiver.[[Direction]]を
"inactive"
に設定する。
transceiver.[[Stopping]]を
trueに設定する。
transceiverと、任意で、デフォルト値が
falseであるdisappearブール値を与えた場合の
RTCRtpTransceiver
を停止するアルゴリズムは、
次のとおりである。
transceiver.[[Stopping]]が
falseである場合、transceiverとdisappearを用いて送信と受信を停止する。
transceiver.[[Stopped]]を
trueに設定する。
transceiver.[[Receptive]]を
falseに設定する。
transceiver.[[CurrentDirection]]
をnullに設定する。
setCodecPreferences
setCodecPreferences
メソッドは、ユーザーエージェントが使用するデフォルトの
コーデック優先設定をネゴシエーションへの入力として
上書きする。
セッション記述を
次のいずれかを使用して
次の
いずれかを使用してcreateOffer
または
createAnswerで生成する場合、
ユーザーエージェント
MUST
MUST
direction
に基づいて優先コーデックをフィルタリングし、その結果が
指定されたコーデック空でないリストとなる場合、それらのコーデックを
MUST
指定された順序
codecs
引数の順序で、対応するメディアセクション
セクション、すなわちこのこの
RTCRtpTransceiverに対応するものに使用しなければならない。
このメソッドにより、アプリケーションは
特定のコーデック(RTX/RED/FEC を含む)のネゴシエーションを無効にできる。
また、アプリケーションは
リストの先頭に現れるコーデックをリモートピアが送信時に
優先するようにすることもできる。これは、無効にするもの
以外のすべてのコーデックを列挙することによって行う。
m= セクションが受信用に使用される場合、SDP 内の コーデックの順序(オファーとアンサーの両方)は、 ローカルエンドポイントがどのコーデックで受信することを優先するかを リモートエンドポイントに示す。m= セクションが受信用に使用されない場合でも、 独自のコーデック優先設定を持たないアンサー側は デフォルトで SDP アンサーにも同じ順序を使用する。
RTCRtpSenderはデフォルトで、
リモートエンドポイントが受信を優先すると示したものを
送信するが、アプリケーションはネゴシエーション済みの
codecsのうち、
どのコーデックを送信するかを
setParameters
を呼び出して、
送信する
codec
を指定することで変更できる。
RTCRtpReceiverは、
ネゴシエーションされた任意の
コーデックを受信できるよう準備されている。
コーデック優先設定は、この
createOffer
および
createAnswer
のうち、この
RTCRtpTransceiverを含むすべての呼び出しについて、
このメソッドが再度呼び出されるまで有効なままとなる。
codecsを空のシーケンスに設定すると、コーデック
優先設定が任意のデフォルトシーケンスに設定した場合、または
direction
によるフィルタリング後に空になるシーケンスに設定した場合、
デフォルトの値にリセットされるコーデック優先設定となる。
コーデックのペイロードタイプは SDP 内の各 m= セクションの下に
列挙され、ペイロードタイプと
コーデックの対応関係を定義する。これらのペイロードタイプは、
優先順位に従って m=video または
m=audio 行から参照され、ネゴシエーションされなかったコーデックは、
[RFC8829RFC9429]
の5.2.1節で定義されているとおり、
このリストには現れない。
以前ネゴシエーションされたコーデックが
後で削除された場合、m=video または
m=audio 行から消え、そのコーデックのペイロードタイプは
将来のオファーまたはアンサーで再利用してはならないが、
そのペイロードタイプを SDP 内のペイロードタイプの対応関係から
削除することもできる。
codecsシーケンスは
setCodecPreferences
に渡される際、次のコーデックのみを含めることができるは、codecsを、
一致しない
コーデックに設定しようとする試みを拒否する。
次によって返される
対象は次のいずれかに見つかるものである。
RTCRtpSender.getCapabilities(kind)
または
RTCRtpReceiver.getCapabilities(kind)。
ここでkindは、このメソッドが呼び出される
RTCRtpTransceiverの種類である。
さらに、
辞書の
メンバーを変更することはできない。codecsが
これらの要件を満たさない場合、ユーザーエージェントはMUST 投げる、RTCRtpCodecCapabilityInvalidModificationErrorを。
[SDP]
の推奨事項により、
の呼び出しでは、コーデック優先設定とオファーに現れるコーデックの
共通部分のみを使用することが推奨される(SHOULD)。
たとえば、コーデック優先設定が "C, B, A" で、
オファーされたコーデックが "A, B" のみである場合、アンサーには
"B, A" のコーデックのみを含めるべきである。ただし、[RFC8829]
(5.3.1
節)では、オファーに
含まれていなかったコーデックの追加が許可されているため、
実装は異なる動作をすることがある。
createAnswer
setCodecPreferences()
が呼び出された場合、ユーザー
エージェントは次の手順を実行しなければならない(MUST)。
transceiverを、このメソッドが呼び出されたRTCRtpTransceiver
オブジェクトとする。
codecsを第1引数とする。
codecsが空のリストである場合、
transceiver.[[PreferredCodecs]]
を
codecsに設定し、これらの手順を中止する。
codecs内の重複する値をすべて削除する。 コーデックの優先順位が維持されるようリストの末尾から開始し、 リスト内で最初に出現するコーデックのインデックスが、 この手順の前後で同じになるようにする。
codecs内の重複する値をすべて削除し、 各値の最初の出現箇所がそのまま残るようにする。
kindを、transceiverのトランシーバー 種別とする。
codecsと
.RTCRtpSendergetCapabilities(kind).codecs
の共通部分、またはcodecsと
RTCRtpReceiver.getCapabilities(kind).codecs
の共通部分に RTX、RED、FEC コーデックしか含まれていないか、
空集合である場合、
InvalidModificationError
を投げる。これにより、
transceiver.にかかわらず、
常にオファーできるものが存在することが保証される。
direction
codecCapabilitiesを、
RTCRtpSender.getCapabilities(kind).codecs
と
RTCRtpReceiver.getCapabilities(kind).codecs
の和集合とする。
codecs内の各codecについて、
InvalidModificationError
を投げる。
codecs内の各codecについて、
codecがcodecCapabilities内のどの
コーデックにも一致しない場合、
InvalidModificationError
を投げる。
codecsに RTX、RED、FEC
またはコンフォートノイズのエントリしか含まれていないか、空集合である場合、
InvalidModificationError
を投げる。これにより、
transceiver.directionにかかわらず、
常にオファーできるものが存在することが保証される。
transceiver.[[PreferredCodecs]]
を
codecsに設定する。
2つの
RTCRtpCodec辞書
firstとsecond、および
指定されなかった場合のデフォルト値がfalseである
ignoreLevelsブール値を与えた場合の
コーデック辞書一致
アルゴリズムは次のとおりである。
first.mimeTypeが
second.mimeTypeと
ASCII 大文字小文字不区別で
一致しない場合、falseを返す。
first.channels
とsecond.channelsの
いずれか一方だけが存在しない場合、
または両方が存在し、かつfirst.channels
がsecond.channelsと異なる場合、
falseを返す。
first.sdpFmtpLine
とsecond.sdpFmtpLineの
いずれか一方だけが
存在しない場合、
falseを返す。
first.sdpFmtpLineと
second.sdpFmtpLineの両方が存在する場合、次の
手順を実行する。
first.sdpFmtpLine
と
second.sdpFmtpLine
のいずれかがキー値形式でない場合、
first.sdpFmtpLine
と
second.sdpFmtpLine
の間で等価比較を実行した結果を返す。
firstMediaFormatを、first.sdpFmtpLine
から構築したメディア形式のキー値マップとし、
secondMediaFormatを
second.sdpFmtpLine
から構築したメディア形式のキー値マップとする。
どの FMTP パラメーターがメディア形式を構成するかはコーデック固有である。 場合によっては、 パラメーターを省略しても推論でき、その場合、そのパラメーターも そのコーデックのメディア形式の一部となる。
firstMediaFormatが
secondMediaFormatと等しくない場合、
falseを返す。
ignoreLevelsがfalseであり、
first.sdpFmtpLine
と
second.sdpFmtpLine
から推論された、準拠するビットストリームの最高レベルが
異なる場合、falseを返す。
ignoreLevelsがtrueであっても、
一部のコーデック(H.264 など)は
メディア形式にレベルを含むため、レベルを無視するには
コーデック固有の解析が必要となる。
trueを返す。
設定されている場合、オファー側の受信コーデック優先設定が オファー内のコーデックの順序を決定する。アンサー側が コーデック優先設定を持たない場合、アンサーでも 同じ順序が使用される。ただし、アンサー側もコーデック優先設定を持つ場合、 その優先設定がアンサー内の順序を上書きする。この 場合、オファー側の優先設定はどのコーデックが オファーに含まれるかには影響するが、最終的な順序には影響しない。
サイマルキャスト送信機能は、
addTransceiver メソッドの
sendEncodings
引数を介して、または
setRemoteDescription
メソッドにサイマルキャストを受信するリモート
オファーを指定することで有効になる。これらはいずれも
RTCPeerConnection オブジェクトのメソッドである。
さらに、
各 RTCRtpSender
オブジェクトの setParameters メソッドを使用して、
この機能を検査および変更できる。
RTCRtpSender
の サイマルキャストエンベロープは、
ユニキャストではなくサイマルキャストを送信することを伴う最初の正常なネゴシエーションで
確立され、送信可能なサイマルキャストストリームの最大数と、その
encodings の順序を含む。このサイマルキャストエンベロープは、
後続の再ネゴシエーションで狭める(レイヤー数を減らす)ことはできるが、
再び拡張することはできない。個々のサイマルキャストストリームの特性は、
setParameters
メソッドを使用して変更できるが、
サイマルキャストエンベロープ
自体をこのメソッドで変更することはできない。
サイマルキャストを構成する方法の1つは、
sendEncodings オプションを
addTransceiver()
に指定することである。
addTrack()
メソッドにはサイマルキャストの
構成に必要な
sendEncodings
引数がないが、ユーザーエージェントがアンサー側である場合、
sender をサイマルキャストに昇格させることができる。
サイマルキャストを受信するリモート
オファーを指定して
setRemoteDescription
メソッドを呼び出すと、
指定されたセッション記述に記述されたレイヤーを含むように
提案エンベロープが
RTCRtpSender
上に構成される。この
記述がロールバックされない限り、ネゴシエーションが完了したときに
提案エンベロープは
RTCRtpSender のサイマルキャストエンベロープになる。上記と同様に、このサイマルキャストエンベロープは、
後続の再ネゴシエーションで狭めることはできるが、再び拡張することはできない。
setParametersでは
サイマルキャスト
サイマルキャストエンベロープを変更できないが、を変更できないが、
送信されるストリームの数とそれらのストリームの特性を制御することは
依然として可能である。
setParametersを使用すると、
active メンバー
をfalseに設定することでサイマルキャストストリームを
非アクティブにでき、また
active メンバー
をtrueに設定することで再びアクティブにできる。
[RFC7728](RTP の一時停止/再開)は
サポートされず、SDP オファー/アンサーを介した
一時停止/再開のシグナリングもサポートされない。
setParametersを使用すると、
maxBitrate
などの属性を変更することでストリームの特性を
変更できる。
サイマルキャストは、複数のエンコーディングを SFU に送信するためによく使用され、
SFU はその後、サイマルキャストストリームの1つをエンド
ユーザーに転送する。したがって、ユーザーエージェントは、
すべてのサイマルキャストストリームがそれぞれ単独で
使用可能になるように、エンコーディング間で帯域幅を割り当てることが期待される。
たとえば、2つのサイマルキャストストリームが同じ
maxBitrateを持つ場合、
両方のストリームで同程度のビットレートが
見られることが期待される。帯域幅の制約により
すべてのサイマルキャストストリームを使用可能な形で送信できない場合、
ユーザーエージェントは一部のサイマルキャストストリームの送信を停止することが期待される。
[RFC9429](3.7節)で定義されているように、
ユーザーエージェントからのオファーには、a=simulcast
行に "send" 記述のみが含まれ、
"recv" 記述は含まれない。代替候補および制限
([RFC8853]で説明されている)
はサポートされない。
この仕様では、createOffer、
createAnswer または
addTransceiverを使用して、
複数の RTP エンコーディングの受信を構成する方法を定義していない。ただし、
[RFC9429]で定義されているように
複数の RTP エンコーディングを送信できる対応するリモート記述を指定して
setRemoteDescriptionが
呼び出され、かつ
ブラウザーが複数の RTP エンコーディングの受信をサポートしている場合、
RTCRtpReceiverは
複数の RTP エンコーディングを受信でき、トランシーバーの
receiver.getParameters()
を介して取得されたパラメーターには、ネゴシエーションされたエンコーディングが反映される。
RTCRtpReceiverは、
選択的転送ユニット(SFU)が
ユーザーエージェントから受信したサイマルキャストストリームを切り替えるシナリオで、
複数の RTP ストリームを受信できる。SFU が転送前に、
切り替えられたストリームを単一の RTP ストリームとして構成するよう
RTP ヘッダーを書き換えない場合、
RTCRtpReceiverは、
それぞれ独自の SSRC とシーケンス番号空間を持つ、
異なる RTP ストリームからパケットを受信する。
SFU が任意の時点で転送する RTP ストリームは1つだけであっても、
並べ替えによって複数の RTP ストリームからのパケットが
receiver 側で混在する可能性がある。複数の RTP ストリームを受信できる
RTCRtpReceiverは、
したがって、受信したパケットを正しく並べ替え、
潜在的な損失イベントを認識し、それに対応できる必要がある。この
シナリオでの正しい動作は容易ではないため、この仕様の実装では
任意である。
このセクションは規範的ではありません。
エンコーディングパラメータを用いた Simulcast シナリオの例:
// 解像度が最も低いレイヤーを除き、すべて無効化された3層の空間Simulcastの例
var encodings = [
{rid: 'q', active: true, scaleResolutionDownBy: 4.0}
{rid: 'h', active: false, scaleResolutionDownBy: 2.0},
{rid: 'f', active: false},
];
このセクションは規範的ではありません。
direction 属性と
replaceTrack メソッドを組み合わせることで、
開発者は「保留」シナリオを実装することができます。
ピアに音楽を送信し、受信した音声の再生を停止する(音楽保留)には:
async function playMusicOnHold() {
try {
// audioトランシーバとmusicTrackという名前の音楽トラックがあると仮定します
await audio.sender.replaceTrack(musicTrack);
// 受信音声をミュートする
audio.receiver.track.enabled = false;
// directionをsend-onlyに設定する(ネゴシエーションが必要)
audio.direction = 'sendonly';
} catch (err) {
console.error(err);
}
}
リモートピアの「sendonly」オファーに応答するには:
async function handleSendonlyOffer() {
try {
// まずsendonlyオファーを適用して、
// レシーバーがICE候補に対応できるようにする
await pc.setRemoteDescription(sendonlyOffer);
// 音声の送信を停止する
await audio.sender.replaceTrack(null);
// さらなるネゴシエーションを避けるためにdirectionを調整する
audio.direction = 'recvonly';
// createAnswerを呼び出してrecvonlyのアンサーを送信する
await doAnswer();
} catch (err) {
// シグナリングエラーを処理する
}
}
音楽の送信を停止し、マイクロフォンからキャプチャした音声を送信する。同時に受信音声を再生するには:
async function stopOnHoldMusic() {
// audioトランシーバとmicTrackという名前のマイクトラックがあると仮定します
await audio.sender.replaceTrack(micTrack);
// 受信音声のミュートを解除する
audio.receiver.track.enabled = true;
// directionをsendrecvに設定する(ネゴシエーションが必要)
audio.direction = 'sendrecv';
}
リモートピアから保留解除された場合に応答するには:
async function onOffHold() {
try {
// まずsendrecvオファーを適用して、レシーバーがICE候補に対応できるようにする
await pc.setRemoteDescription(sendrecvOffer);
// 音声の送信を開始する
await audio.sender.replaceTrack(micTrack);
// directionをsendrecvに設定する(アンサーの直前)
audio.direction = 'sendrecv';
// createAnswerを呼び出してsendrecvのアンサーを送信する
await doAnswer();
} catch (err) {
// シグナリングエラーを処理する
}
}
RTCDtlsTransport
インターフェイスにより、
アプリケーションは、RTCRtpSender および RTCRtpReceiver オブジェクトによって
RTP および RTCP パケットが送受信される Datagram Transport Layer Security(DTLS)
トランスポートに関する情報、ならびにデータチャネルによって送受信される SCTP パケットなどの
その他のデータにアクセスできる。
特に、DTLS は基礎となるトランスポートにセキュリティを追加し、
RTCDtlsTransport
インターフェイスにより、
基礎となるトランスポートおよび追加されたセキュリティに関する
情報にアクセスできる。RTCDtlsTransport
オブジェクトは、
setLocalDescription()
および
setRemoteDescription()
の呼び出しの結果として構築される。
各
RTCDtlsTransport オブジェクトは、
特定の
RTCRtpTransceiver の
RTP または RTCP component に対する
DTLS トランスポート層を表すか、または、そのような
グループが [RFC8843] を介してネゴシエーションされている場合は、
RTCRtpTransceiver群の
グループに対する DTLS トランスポート層を表す。
RTCRtpTransceiver のための新しい DTLS アソシエーションは、
既存のRTCDtlsTransport オブジェクトによって表され、
そのstate が適切に更新されることになります。
これは、新しいオブジェクトによって表されるのではありません。
RTCDtlsTransport には、[[DtlsTransportState]]
という内部スロットがあり、初期値として "new" が設定されています。また、
[[RemoteCertificates]] スロットは
空のリストとして初期化されます。
基礎となる DTLS トランスポートで、証明書検証の失敗や致命的なアラート([RFC5246] セクション 7.2 を参照)などのエラーが発生した場合、ユーザーエージェントは以下のステップを実行するタスクをキューに追加しなければなりません。
transport を、状態の更新とエラー通知を受け取る
RTCDtlsTransport オブジェクトとします。
transport の状態がすでに
"failed"
である場合、
これらのステップを中止します。
transport.[[DtlsTransportState]] を
"failed"
に設定します。
イベントを発火し、error という名前を付けます。
このイベントは
RTCErrorEvent
インターフェイスを使用し、errorDetail 属性を
"dtls-failure" または
"fingerprint-failure"
のいずれかに設定します。他のフィールドは RTCErrorDetailType
列挙型の記述に従って設定し、transport で発火します。
イベントを発火し、statechange という名前を付け、
transport で発火します。
基礎となる DTLS トランスポートが、対応する RTCDtlsTransport オブジェクトの状態を他の理由で更新する必要がある場合、
ユーザーエージェントは以下のステップを実行するタスクをキューに追加しなければなりません。
transport を、状態の更新を受け取る
RTCDtlsTransport オブジェクトとします。
newState を新しい状態とします。
transport.[[DtlsTransportState]] を
newState に設定します。
newState が connected の場合、
newRemoteCertificates を、リモート側で使用されている証明書チェーンとし、
各証明書をバイナリの Distinguished Encoding Rules (DER) [X690]
で
エンコードされたものとします。そして、
transport.[[RemoteCertificates]] を
newRemoteCertificates に設定します。
イベントを発火し、statechange という名前を付け、
transport で発火します。
WebIDL[Exposed=Window]
interface RTCDtlsTransport : EventTarget {
[SameObject] readonly attribute RTCIceTransport iceTransport;
readonly attribute RTCDtlsTransportState state;
sequence<ArrayBuffer> getRemoteCertificates();
attribute EventHandler onstatechange;
attribute EventHandler onerror;
};
iceTransport の型は RTCIceTransport で、
読み取り専用
iceTransport
属性はパケットの送受信に使用される基礎トランスポートです。この基礎トランスポートは、複数のアクティブな
RTCDtlsTransport
オブジェクト間で共有されない場合があります。
state の型は RTCDtlsTransportState
で、
読み取り専用
state 属性は、
取得時に
[[DtlsTransportState]]
スロットの値を返さなければ
なりません。
onstatechange の型は EventHandler
statechange です。
onerror の型は EventHandler
error です。
getRemoteCertificates
[[RemoteCertificates]]
の値を返します。
WebIDLenum RTCDtlsTransportState {
"new",
"connecting",
"connected",
"closed",
"failed"
};
| 列挙値 | 説明 |
|---|---|
new
|
DTLS はまだネゴシエーションを開始していません。 |
connecting
|
DTLS は安全な接続をネゴシエートし、リモートフィンガープリントを検証中です。 |
connected
|
DTLS は安全な接続のネゴシエーションを完了し、リモートフィンガープリントを検証しました。 |
closed
|
トランスポートは、close_notify アラートの受信、または
close()
の呼び出しの結果として意図的に終了されました。
|
failed
|
トランスポートは、エラー(エラーアラートの受信やリモートフィンガープリントの検証失敗など)の結果として失敗しました。 |
RTCDtlsFingerprint 辞書には、
[RFC4572]
に記載されているように、ハッシュ関数アルゴリズムと証明書フィンガープリントが含まれます。
WebIDLdictionary RTCDtlsFingerprint {
DOMString algorithm;
DOMString value;
};
algorithm の型は DOMString
'Hash function Textual Names' レジストリ [IANA-HASH-FUNCTION] に定義されている ハッシュ関数アルゴリズムのいずれか。
value の型は DOMString
[RFC4572] セクション5に記載された 'fingerprint' の構文を使用して表現された 小文字の16進文字列形式の証明書フィンガープリントの値。
RTCIceTransport
インターフェイスにより、
アプリケーションは、パケットが送受信される ICE トランスポートに関する
情報にアクセスできる。特に、ICE は、
アプリケーションがアクセスしたい場合のある状態を伴うピアツーピア接続を管理する。
RTCIceTransport オブジェクトは、
setLocalDescription()
および
setRemoteDescription()
の呼び出しの結果として構築される。基礎となる ICE
状態はICE
エージェントによって管理される。そのため、
RTCIceTransportの状態は、
以下に記述するようにICE エージェントがユーザーエージェントに
通知を提供すると変化する。各
RTCIceTransport オブジェクトは、
特定の
RTCRtpTransceiverの
RTP または RTCP componentに対する
ICE トランスポート層を表すか、または、そのような
グループが [RFC8843] を介してネゴシエーションされている場合は、
RTCRtpTransceiver群の
グループに対する ICE トランスポート層を表す。
RTCRtpTransceiver のための ICE 再起動は、
既存のRTCIceTransport オブジェクトによって表され、
そのstate
が適切に更新されることになります。
これは、新しいオブジェクトによって表されるのではありません。
ICEエージェントが世代の候補をRTCIceTransport transport
をRTCPeerConnection
connectionに関連付けて収集し始めたとき、ユーザーエージェントは次のステップを実行するタスクをキューに追加しなければならない:
このICEエージェントに関連付けられた
オブジェクトをconnectionとする。
RTCPeerConnection
もしconnection.[[IsClosed]]が
trueである場合、これらのステップを中止する。
候補収集が始まった
をtransportとする。
RTCIceTransport
transport.[[IceGathererState]]を
gatheringに設定する。
.
connection.[[IceGatheringState]]
をRTCIceGatheringState列挙型によって記述された新しい状態値を導出することで得られる値に設定する。
もし前のステップでconnection.[[IceGatheringState]]
が変更された場合、connectionIceGatheringStateChangedを
trueとし、それ以外の場合はfalseとする。
これ以降、状態を読み取ったり変更したりしてはならない。
イベントgatheringstatechange
をtransportで発火する。
ICE収集状態を更新connectionに対して行う。
もしconnectionIceGatheringStateChangedが
trueである場合、イベントicegatheringstatechange
をconnectionで発火する。
ICEエージェントが世代の候補をRTCIceTransport transportを
RTCPeerConnection
connectionに関連付けて収集を完了し、それらの候補がアプリケーションに提供されたとき、ユーザーエージェントは次のステップを実行するタスクを実行するをキューに追加する:
このICEエージェントに関連付けられた
オブジェクトをconnectionとする。
RTCPeerConnection
もしconnection.[[IsClosed]]が
trueである場合、これらのステップを中止する。
候補収集が完了した
をtransportとする。
RTCIceTransport
もしconnection.[[PendingLocalDescription]]
が
nullでなく、ICE 世代
を表しており、収集が終了した場合、
a=end-of-candidates を
connection.[[PendingLocalDescription]].sdp
に追加する。
もしconnection.[[CurrentLocalDescription]]
が
nullでなく、ICE 世代
を表しており、収集が終了した場合、
a=end-of-candidates を
connection.[[CurrentLocalDescription]].sdp
に追加する。
newCandidateendOfGatheringCandidateをRTCIceCandidateを作成する結果とし、新しい辞書の
sdpMid
と
sdpMLineIndex
をこのRTCIceTransport
に関連付けられた値に設定し、
usernameFragment
を候補が収集された世代のユーザー名フラグメントに設定し、
candidate
を空文字列""に設定する。
イベントicecandidateを
RTCPeerConnectionIceEvent
インターフェイスを使用して候補属性をnewCandidateendOfGatheringCandidateに設定し、connection
で発火する。
もし、別の世代の候補がまだ収集されている場合、これらのステップを中止する。
transport.[[IceGathererState]]を
に設定する。
complete
イベントを発火する名前付き
をtransportで。
gatheringstatechange
ICE収集状態を更新する connectionの。
ICEエージェントが上記のタスクをキューに追加し、他の世代の候補が収集されていない場合、ユーザーエージェントは次のステップを実行するために2番目のタスクをキューに追加しなければならない:
もしconnection.[[IsClosed]]が
trueである場合、これらのステップを中止する。
transport.[[IceGathererState]]
をcompleteに設定する。
connection.[[IceGatheringState]]
をRTCIceGatheringState列挙型で記述される新しい状態値を導出する値に設定する。
前のステップでconnection.[[IceGatheringState]]が変更された場合、connectionIceGatheringStateChangedを
trueとし、それ以外の場合はfalseとする。
これ以降、状態を読み取ったり変更したりしてはならない。
イベントgatheringstatechange
をtransportで発火する。
もしconnectionIceGatheringStateChangedが
trueである場合、イベントicegatheringstatechange
をconnectionで発火する。
イベント名前付きicecandidateを
RTCPeerConnectionIceEvent
インターフェイスを使用して候補属性をnullに設定しconnectionで発火する。
RTCIceTransportおよび/またはRTCPeerConnectionの収集状態を監視する必要があります。
ICEエージェントが、新しいICE候補が
RTCIceTransport
のために利用可能であることを示した場合、ICE候補プールから取得するか、または新たに収集するかに関わらず、
ユーザーエージェントは以下のステップを実行するタスクをキューに追加しなければならない:
candidateを利用可能なICE候補とする。
connectionを、このICEエージェントに関連付けられた
RTCPeerConnection
オブジェクトとする。
もしconnection.[[IsClosed]]が
trueである場合、これらのステップを中止する。
もし
connection.[[PendingLocalDescription]] または
connection.[[CurrentLocalDescription]]のいずれかが
nullでなく、candidateが収集されたICE
世代
を表している場合、候補を表面化する(candidateとconnectionを使用)し、これらのステップを中止する。
それ以外の場合、candidateを
connection.[[EarlyCandidates]]
に追加する。
ICEエージェント が、[RFC8445]
セクション7.3.1.1に基づく役割衝突を含むICEバインディングリクエストによりICE役割が変更されたことを通知した場合、UAはタスクをキューに追加し、
[[IceRole]] の値を新しい値に設定します。
connectionの早期候補を解放するには、以下のステップを実行します:
connection.[[EarlyCandidates]]
内の各候補candidateに対して、candidateと
connectionを使用して
候補を表面化する
タスクをキューに追加します。
connection.[[EarlyCandidates]]を空のリストに設定します。
candidateとconnectionを使用して候補を表面化するには、以下のステップを実行します:
もしconnection.[[IsClosed]]が
trueである場合、これらのステップを中止します。
candidateが利用可能にされるRTCIceTransportを
transportとします。
もしconnection.[[PendingLocalDescription]]が
nullでなく、candidateが収集されたICE
世代
を表している場合、candidateを
connection.[[PendingLocalDescription]].sdp
に追加します。
もしconnection.[[CurrentLocalDescription]]が
nullでなく、candidateが収集されたICE
世代
を表している場合、candidateを
connection.[[CurrentLocalDescription]].sdp
に追加します。
新しい辞書を使用してRTCIceCandidateを作成する結果を
newCandidateとし、
sdpMidと
sdpMLineIndexを
このRTCIceTransport
に関連付けられた値に設定し、
usernameFragmentを
候補のユーザー名フラグメントに設定し、
candidateを
candidate-attribute
文法を使用してcandidateを表現する文字列に設定します。
newCandidateをtransportのローカル候補セットに追加します。
イベント名
icecandidateを使用して、
RTCPeerConnectionIceEvent
インターフェイスを使用し、候補属性をnewCandidateに設定してconnection
で発火します。
RTCIceTransportState は
RTCIceTransportの候補ペアが利用可能な接続を持ち、選択された場合や、選択された候補ペアが変わらないまま変更される可能性があります。
選択されたペアとRTCIceTransportStateは関連があり、同じタスク内で処理されます。
ICEエージェントが
RTCIceTransportの選択された候補ペア、
RTCIceTransportState、またはその両方が変更されたことを示した場合、ユーザーエージェントは
選択された候補ペアと状態を変更する手順を実行するタスクをキューに追加しなければならない:
connectionを、このRTCPeerConnectionオブジェクトであり、
このICE エージェントに関連付けられているものとする。
connection.[[IsClosed]]が
trueである場合、これらの手順を中止する。
transportを、状態が
変化しているRTCIceTransportとする。
selectedCandidatePairChangedを
falseとする。
transportIceConnectionStateChangedを
falseとする。
connectionIceConnectionStateChangedを
falseとする。
connectionStateChangedをfalseとする。
transportの選択された候補ペアが変更された場合、 次の手順を実行する。
newCandidatePairを、localとremoteを使用してRTCIceCandidatePair を
作成する結果とし、ペアが選択されている場合は指定されたペアのローカル候補とリモート
候補を表し、それ以外の場合はnullとする。
transport.[[SelectedCandidatePair]]
を
newCandidatePairに設定する。
selectedCandidatePairChangedを
trueに設定する。
transportのRTCIceTransportStateが変更された場合、
次の手順を実行する。
transport.[[IceTransportState]]を、
新しく示されたRTCIceTransportStateに設定する。
transportIceConnectionStateChangedを
trueに設定する。
connection.[[IceConnectionState]]を、
RTCIceConnectionState
enum で説明されているように新しい状態値を導出した
値に設定する。
connection.[[IceConnectionState]]が
前の手順で変更された場合、connectionIceConnectionStateChangedを
trueに設定する。
connection.[[ConnectionState]]を、
RTCPeerConnectionState
enum で説明されているように新しい状態値を導出した
値に設定する。
connection.[[ConnectionState]]が
前の手順で変更された場合、
connectionStateChangedをtrueに設定する。
selectedCandidatePairChangedがtrueである場合、
transportでイベントを発火し、その名前をselectedcandidatepairchange
とする。
transportIceConnectionStateChangedが
trueである場合、transportでイベントを発火し、その名前をstatechangeとする。
connectionIceConnectionStateChangedが
trueである場合、connectionでイベントを発火し、その名前を
iceconnectionstatechangeとする。
connectionStateChangedがtrueである場合、connectionでイベントを発火し、その名前をconnectionstatechangeとする。
RTCIceTransport
オブジェクトには以下の内部スロットがあります:
new"
new"
null
unknown"
WebIDL[Exposed=Window]
interface RTCIceTransport : EventTarget {
readonly attribute RTCIceRole role;
readonly attribute RTCIceComponent component;
readonly attribute RTCIceTransportState state;
readonly attribute RTCIceGathererState gatheringState;
sequence<RTCIceCandidate> getLocalCandidates();
sequence<RTCIceCandidate> getRemoteCandidates();
RTCIceCandidatePair? getSelectedCandidatePair();
RTCIceParameters? getLocalParameters();
RTCIceParameters? getRemoteParameters();
attribute EventHandler onstatechange;
attribute EventHandler ongatheringstatechange;
attribute EventHandler onselectedcandidatepairchange;
};
role 型 RTCIceRole, 読み取り専用
role属性は、
取得時に[[IceRole]]内部スロットの値を返さなければならない。
component 型
RTCIceComponent, 読み取り専用
component属性は、
トランスポートのICEコンポーネントを返さなければならない。
RTCP mux が使用される場合、単一のRTCIceTransportがRTP
とRTCPの両方をトランスポートし、
componentは
"rtp"に設定される。
state 型
RTCIceTransportState,
読み取り専用
state属性は、
取得時に[[IceTransportState]]
スロットの値を返さなければならない。
gatheringState 型 RTCIceGathererState,
読み取り専用
gatheringState
属性は、取得時に[[IceGathererState]]
スロットの値を返さなければならない。
onstatechange 型 EventHandler
statechange
に属し、RTCIceTransportの
state
が変更されたときに発火しなければならない。
ongatheringstatechange 型
EventHandler
gatheringstatechange
に属し、
RTCIceTransportの
[[IceGathererState]]
が変更されたときに発火しなければならない。
onselectedcandidatepairchange 型
EventHandler
selectedcandidatepairchange
に属し、
RTCIceTransportの選択された候補ペアが変更されたときに発火しなければならない。
getLocalCandidates
このRTCIceTransportのために収集され、
onicecandidate
で送信されたローカルICE候補を記述するシーケンスを返します。
getRemoteCandidates
このRTCIceTransportが
addIceCandidate()
経由で受信したリモートICE候補を記述するシーケンスを返します。
getSelectedCandidatePair
パケットが送信される選択された候補ペアを返します。このメソッドは、
[[SelectedCandidatePair]]
スロットの値を返さなければならない。
RTCIceTransport.stateが
"new" または
"closed" の場合、
getSelectedCandidatePair
はnullを返します。
getLocalParameters
このRTCIceTransportが
setLocalDescription
経由で受信したローカルICEパラメータを返します。パラメータがまだ受信されていない場合はnullを返します。
getRemoteParameters
このRTCIceTransportが
setRemoteDescription
経由で受信したリモートICEパラメータを返します。パラメータがまだ受信されていない場合はnullを返します。
WebIDLdictionary RTCIceParameters {
DOMString usernameFragment;
DOMString password;
};
RTCIceParameters メンバー
RTCIceCandidatePair 辞書
このインターフェイスはICE候補ペアを表し、[RFC8445]セクション4で説明されています。
RTCIceCandidatePairは
ローカルおよびリモートのRTCIceCandidateのペアリングです。
RTCIceCandidatePairを作成するには、
RTCIceCandidateオブジェクトlocalとremoteを使用して、以下のステップを実行します:
RTCIceCandidatePairオブジェクトとします。
dictionary[Exposed=Window] interface RTCIceCandidatePair { [SameObject] readonly attribute RTCIceCandidate local; [SameObject] readonly attribute RTCIceCandidate remote; };
RTCIceCandidatePair
メンバー
local 型 RTCIceCandidateローカルICE候補。
remote 型 RTCIceCandidateリモートICE候補。
remote
属性は、取得時に[[Remote]]内部スロットの値を返さなければならない。
WebIDLenum RTCIceGathererState {
"new",
"gathering",
"complete"
};
| 列挙値 | 説明 |
|---|---|
new
|
RTCIceTransportが
作成されたばかりで、候補の収集をまだ開始していない状態。
|
gathering
|
RTCIceTransportが
候補を収集している最中の状態。
|
complete
|
RTCIceTransportが
候補の収集を完了し、このトランスポートの候補終了指示が送信された状態。
ICE再起動が発生し、再開するまで候補は再収集されない。
|
WebIDLenum RTCIceTransportState {
"closed",
"failed",
"disconnected",
"new",
"checking",
"completed",
"connected"
};
| 列挙値 | 説明 |
|---|---|
closed
|
RTCIceTransport
はシャットダウンしており、もはや STUN 要求に応答しません。
|
failed
|
RTCIceTransport
は収集を完了し、これ以上リモート候補がないことの通知を受け取り、すべての候補ペアの検査を終え、全ペアが接続性チェックに失敗したか同意を失っており、さらにローカル候補が
0 件であったか、PAC タイマーが期限切れになっています [RFC8863]。これは
ICE が再起動されるまでの終端状態です。ICE の再起動によって接続性が回復する可能性があるため、
"failed"
状態に入っても、DTLS トランスポート、SCTP
アソシエーション、またはその上で動作するデータチャネルが閉じられたり、トラックがミュートされたりすることはありません。
|
disconnected
|
ICE エージェント は、この RTCIceTransport
の接続性が現在失われていると判断しました。これは一時的な状態で、品質の不安定なネットワークでは断続的に発生し(対応しなくても自然に解消することがあります)。この状態の判定方法は実装依存です。例としては:
RTCIceTransport
が既存の候補ペアの検査をすべて終えても接続が見つからず(かつ、いったん成功していた同意の鮮度確認 [RFC7675]
が失敗した)、それでもなお収集中である、または追加のリモート候補を待機している場合です。
|
new
|
RTCIceTransport
は候補の収集中またはリモート候補の提供を待機中で、まだ検査を開始していません。
|
checking
|
RTCIceTransport は少なくとも 1
つのリモート候補を受信しており(addIceCandidate()
によるか、STUN Binding
要求の受信時にピア反射候補として発見)、候補ペアの検査を行っていて、まだ接続が見つかっていないか、以前に成功していた候補ペアのすべてで同意の鮮度確認 [RFC7675]
が失敗しています。検査に加えて、引き続き候補の収集中である場合もあります。
|
completed
|
RTCIceTransport
は収集を完了し、これ以上リモート候補がないことの通知を受け取り、すべての候補ペアの検査を終えて接続を見つけました。のちに同意の鮮度確認 [RFC7675]
が成功していたすべての候補ペアで失敗した場合、状態は
"failed"
に遷移します。
|
connected
|
RTCIceTransport
は使用可能な接続を見つけましたが、より良い接続があるか確認するため、他の候補ペアの検査を継続しています。候補の収集中や、追加のリモート候補の待機中である場合もあります。同意の鮮度確認
[RFC7675]
が使用中の接続で失敗し、他に成功している候補ペアがない場合、状態は
"checking"
(検査すべき候補ペアが残っている場合)または
"disconnected"
(検査すべき候補ペアはないが、ピアがまだ収集中または追加のリモート候補を待機中の場合)に遷移します。
|
通常、成功する通話における最も一般的な遷移は new ->
checking -> connected -> completed
ですが、特定の状況(最後に検査した候補だけが成功し、収集完了と「これ以上候補なし」の通知が成功前にどちらも起こる)では、状態が
"checking" から
直接 "completed" に遷移することがあります。
ICE の再起動は候補の収集と接続性チェックを最初からやり直させ、開始時の状態が
"connected"
(開始時に
"completed"
状態だった場合)への遷移を引き起こします。開始時の状態が一時的な
"disconnected"
の場合は、
"checking"
への遷移を引き起こし、以前に接続性が失われていたことを事実上忘れます。
"failed" と
"completed"
の各状態には、追加のリモート候補が存在しないことの示唆が必要です。これは、addIceCandidate を、candidate
プロパティが空文字列に設定された候補値で呼び出すか、canTrickleIceCandidates
が false に設定されることで示すことができます。
状態遷移の例:
RTCIceTransport が初めて作成されたとき(setLocalDescription
または
setRemoteDescription
の結果):
"new"
new"、
リモート候補を受信):
"checking"
checking"、使用可能な接続を発見):
"connected"
checking"、検査は失敗したが収集中):
"disconnected"
checking"、断念):
"failed"
disconnected"、新たなローカル候補):
"checking"
connected"、すべての検査が完了):
"completed"
completed"、接続性を喪失):
"disconnected"
disconnected" または
"failed"、
ICE の再起動が発生):
"checking"
completed"、ICE の再起動が発生):
"connected"
RTCPeerConnection.close():
"closed"
WebIDLenum RTCIceRole {
"unknown",
"controlling",
"controlled"
};
| 列挙値 | 説明 |
|---|---|
unknown
|
[RFC5245]、 セクション 3 に定義されている役割がまだ決定されていないエージェント。 |
controlling
|
[RFC5245]、 セクション 3 に定義されているコントローリングエージェント。 |
controlled
|
[RFC5245]、 セクション 3 に定義されているコントロールドエージェント。 |
WebIDLenum RTCIceComponent {
"rtp",
"rtcp"
};
| 列挙値 | 説明 |
|---|---|
rtp
|
ICE トランスポートは RTP(または RTCP 多重化)に使用されます。これは [RFC5245]、
セクション 4.1.1.1 に定義されています。RTP と多重化されるプロトコル(例: データチャネル)は、そのコンポーネント ID を共有します。これは candidate-attribute
でエンコードされた際の component-id 値 1 を表します。
|
rtcp
|
ICE トランスポートは RTCP に使用されます。これは [RFC5245]、
セクション 4.1.1.1 に定義されています。これは candidate-attribute
でエンコードされた際の component-id 値 2 を表します。
|
track イベントは RTCTrackEvent インターフェイスを使用します。
WebIDL[Exposed=Window]
interface RTCTrackEvent : Event {
constructor(DOMString type, RTCTrackEventInit eventInitDict);
readonly attribute RTCRtpReceiver receiver;
readonly attribute MediaStreamTrack track;
[SameObject] readonly attribute FrozenArray<MediaStream> streams;
readonly attribute RTCRtpTransceiver transceiver;
};
RTCTrackEvent.constructor()
receiver 型は
RTCRtpReceiver, 読み取り専用
receiver 属性は、このイベントに関連付けられた
RTCRtpReceiver オブジェクトを表します。
track 型は MediaStreamTrack, 読み取り専用
track 属性は、このイベントに関連付けられた MediaStreamTrack
オブジェクトを表します。このオブジェクトは、receiver によって識別される RTCRtpReceiver に関連付けられています。
streams 型は FrozenArray<MediaStream>,
読み取り専用
streams 属性は、このイベントの track が一部となる MediaStream オブジェクトの配列を返します。
transceiver 型は
RTCRtpTransceiver,
読み取り専用
transceiver
属性は、このイベントに関連付けられた RTCRtpTransceiver
オブジェクトを表します。
WebIDLdictionary RTCTrackEventInit : EventInit {
required RTCRtpReceiver receiver;
required MediaStreamTrack track;
sequence<MediaStream> streams = [];
required RTCRtpTransceiver transceiver;
};
receiver 型は RTCRtpReceiver, 必須
receiver
メンバーは、このイベントに関連付けられた RTCRtpReceiver オブジェクトを表します。
track 型は MediaStreamTrack, 必須
track
メンバーは、このイベントに関連付けられた MediaStreamTrack
オブジェクトを表します。このオブジェクトは、receiver によって識別される RTCRtpReceiver に関連付けられています。
streams 型は
sequence<MediaStream>,
デフォルト値は []
streams メンバーは、このイベントの
track が一部となる MediaStream オブジェクトの配列を表します。
transceiver 型は RTCRtpTransceiver,
必須
transceiver
属性は、このイベントに関連付けられた RTCRtpTransceiver
オブジェクトを表します。
ピアツーピアデータAPIは、ウェブアプリケーションがピアツーピアで汎用的なアプリケーションデータを送受信できるようにします。データ送受信のAPIは、Web Sockets の動作をモデル化しています。
ピアツーピアデータAPIは、以下に記載されているようにRTCPeerConnectionインターフェイスを拡張します。
WebIDL partial interface RTCPeerConnection {
readonly attribute RTCSctpTransport? sctp;
RTCDataChannel createDataChannel(USVString label,
optional RTCDataChannelInit dataChannelDict = {});
attribute EventHandler ondatachannel;
};
sctp の型は RTCSctpTransport,
読み取り専用、nullable
SCTPデータが送受信されるSCTPトランスポート。
SCTPがネゴシエートされていない場合、この値はnullです。この属性はMUST、RTCSctpTransportオブジェクト([[SctpTransport]]内部スロットに格納)を返さなければなりません。
ondatachannel の型は EventHandler
datachannelです。
createDataChannel
指定されたラベルを持つ新しいRTCDataChannelオブジェクトを作成します。
RTCDataChannelInit辞書を使用して、
データの信頼性など、基盤となるチャネルのプロパティを構成できます。
createDataChannel
メソッドが呼び出されたとき、ユーザーエージェントは以下の手順を実行するMUSTとします。
connectionを、メソッドが呼び出されたRTCPeerConnectionオブジェクトとします。
もしconnection.[[IsClosed]]が
trueなら、throw an
InvalidStateErrorをスローします。
RTCDataChannel を作成し、channelとします。
channel.[[DataChannelLabel]]を
最初の引数の値に初期化します。
[[DataChannelLabel]]の
UTF-8表現が65535バイトを超える場合、throw a TypeErrorをスローします。
optionsを第2引数とします。
channel.[[MaxPacketLifeTime]]を
option.maxPacketLifeTime
に初期化します(存在する場合)。存在しない場合はnull。
channel.[[MaxRetransmits]]を
option.maxRetransmits
に初期化します(存在する場合)。存在しない場合はnull。
channel.[[Ordered]]を
option.orderedに初期化します。
channel.[[DataChannelProtocol]]を
option.protocolに初期化します。
[[DataChannelProtocol]]の
UTF-8表現が65535バイトを超える場合、throw a TypeErrorをスローします。
channel.[[Negotiated]]を
option.negotiatedに初期化します。
channel.[[DataChannelId]]を、
option.idの値に初期化します(それが存在し、かつ
[[Negotiated]]が true
の場合)。それ以外は
null。
もし[[Negotiated]]が
trueで、
[[DataChannelId]]が
nullなら、throw a TypeErrorをスローします。
[[MaxPacketLifeTime]]と
[[MaxRetransmits]]の両属性が設定されている(nullでない)場合、
throw a TypeErrorをスローします。
設定([[MaxPacketLifeTime]]または
[[MaxRetransmits]]のいずれか)が
非信頼モードを示すように設定され、その値がユーザーエージェントでサポートされる最大値を超える場合、その値はユーザーエージェントの最大値に設定されるMUSTとします。
もし[[DataChannelId]]が65535に等しい場合(許可される最大IDである65534を超えるが、それでも
unsigned
shortとしては有効)、throw a TypeErrorをスローします。
[[DataChannelId]]スロットが
null(createDataChannelにIDが渡されていない、または
[[Negotiated]]が false
であるため)で、
かつSCTPトランスポートのDTLSロールがすでにネゴシエートされている場合、[RFC8832]に従ってユーザーエージェントが生成した値で
[[DataChannelId]]を初期化し、次の手順へ進みます。使用可能なIDが生成できなかった場合、または
[[DataChannelId]]スロットの値が既存の
RTCDataChannelによって使用されている場合は、
throw an
OperationError 例外をスローします。
transportを、
connection.[[SctpTransport]]とします。
[[DataChannelId]]スロットが
nullでなく、transportが
"connected"
状態であり、かつ
[[DataChannelId]]が
transport.[[MaxChannels]]以上である場合、
throw an OperationErrorをスローします。
もしchannelがconnection上で作成された最初のRTCDataChannelであるなら、
update the
negotiation-needed flag をconnectionに対して行います。
Append channel を
connection.[[DataChannels]]に追加します。
channelを返し、以下の手順をin parallelで続けます。
channelに関連付けられた基盤となるデータトランスポートを作成し、 channelの関連プロパティに従って構成します。
RTCSctpTransport インターフェイスは、特定の SCTP
アソシエーションに紐付けられた SCTP データチャネルに関する情報へアプリケーションからアクセスできるようにします。
初期状態 initialState を用いて create an
RTCSctpTransport を行うには、次の手順を実行します:
transport を新しい RTCSctpTransport
オブジェクトとします。
transport は内部スロット [[SctpTransportState]] を持ち、initialState で初期化されているものとします。
transport は内部スロット [[MaxMessageSize]] を持ち、これを初期化するために update the data max message size とラベル付けされた手順を実行します。
transport は内部スロット [[MaxChannels]] を持ち、null で初期化されているものとします。
transport を返します。
RTCSctpTransport の
update the data max message size
を行うには、次の手順を実行します:
更新対象の RTCSctpTransport オブジェクトを
transport とします。
remoteMaxMessageSize を、[RFC8841](セクション
6)に記載のとおり、リモート記述から読み取った
max-message-size SDP 属性の値、またはその属性が欠落している場合は 65536 とします。
canSendSize を、このクライアントが送信できるバイト数(すなわちローカル送信バッファのサイズ)とし、実装が任意サイズのメッセージを処理できる場合は 0 とします。
remoteMaxMessageSize と canSendSize の両方が 0 の場合、
[[MaxMessageSize]]
を正の Infinity 値に設定します。
そうでなく、remoteMaxMessageSize または canSendSize のいずれかが 0 の場合、
[[MaxMessageSize]]
を二つのうち大きい方に設定します。
それ以外の場合、
[[MaxMessageSize]] を
remoteMaxMessageSize と canSendSize の小さい方に設定します。
SCTP transport
is connected、つまり RTCSctpTransport の SCTP
アソシエーションが確立されたら、ユーザーエージェントは以下の手順を実行する
タスクをキューに追加MUST します:
transport を RTCSctpTransport オブジェクトとします。
connection を transport に関連付けられた RTCPeerConnection
オブジェクトとします。
[[MaxChannels]] を、交渉済みの受信・送信 SCTP
ストリーム数の最小値に設定します。
connection の各 RTCDataChannel について:
channel を RTCDataChannel
オブジェクトとします。
もし channel.[[DataChannelId]] が
null の場合、[[DataChannelId]] を、
[RFC8832]
に従い、
基盤となる SCTP データチャネルによって生成された値に初期化する。
もし channel.[[DataChannelId]] が
transport.[[MaxChannels]]
以上である、または前の手順で id の割り当てに失敗した場合は、close により失敗として
channel を閉じます。そうでなければ、announce the channel as open
を行います。
Fire an event 名 statechange のイベントを
transport に対して発火します。
このイベントは、open
イベント(announcing the
channel as open により発火)よりも前に発火します。
open
イベントは別のキューに入れられたタスクから発火されます。
WebIDL[Exposed=Window]
interface RTCSctpTransport : EventTarget {
readonly attribute RTCDtlsTransport transport;
readonly attribute RTCSctpTransportState state;
readonly attribute unrestricted double maxMessageSize;
readonly attribute unsigned short? maxChannels;
attribute EventHandler onstatechange;
};
transport の型は RTCDtlsTransport、読み取り専用
データチャネル用のすべての SCTP パケットが送受信されるトランスポートです。
state の型は RTCSctpTransportState、読み取り専用
SCTP トランスポートの現在の状態。取得時、この属性は
[[SctpTransportState]]
スロットの値を返さなければなりません MUST。
maxMessageSize の型は unrestricted double、読み取り専用
RTCDataChannel の send()
メソッドに渡すことができるデータの最大サイズ。取得時、この属性は
[[MaxMessageSize]]
スロットの値を返さなければなりません MUST。
maxChannels の型は unsigned short、読み取り専用、nullable
同時に使用できる RTCDataChannel
の最大数。取得時、この属性は
[[MaxChannels]]
スロットの値を返さなければなりません MUST。
connected"
状態になるまで null です。
onstatechange の型は EventHandler
このイベントハンドラーのイベントタイプは
statechange
です。
RTCSctpTransportState は、SCTP
トランスポートの状態を示します。
WebIDLenum RTCSctpTransportState {
"connecting",
"connected",
"closed"
};
| 列挙値 | 説明 |
|---|---|
connecting
|
|
connected
|
アソシエーションのネゴシエーションが完了すると、[[SctpTransportState]] スロットを
" |
closed
|
次の場合、[[SctpTransportState]] スロットを
"
最後の遷移が論理的であるのは、SCTP アソシエーションには確立済みの DTLS 接続が必要であり([RFC8261] セクション 6.1 では DTLS 上の SCTP はシングルホームであると規定)、この API では代替トランスポートへの切り替え方法が定義されていないためです。 |
RTCDataChannel インターフェイスは、
2つのピア間の双方向データ
チャネルを表す。RTCDataChannel は、
RTCPeerConnection
オブジェクト上のファクトリメソッドを介して作成される。ブラウザー間で送信されるメッセージについては
[RFC8831] および
[RFC8832] で説明されている。
RTCDataChannel
を使用して接続を確立する方法は2つある。
1つ目の方法は、一方のピアで単純にRTCDataChannelを作成し、
negotiated
RTCDataChannelInit 辞書メンバーを未設定のままにするか、
デフォルト値 false に設定する方法である。これにより新しいチャネルがインバンドで通知され、
他方のピアで、対応する
RTCDataChannelEvent と
RTCDataChannel
オブジェクトが発生する。2つ目の方法は、アプリケーションに
RTCDataChannelをネゴシエーションさせる方法である。そのためには、
RTCDataChannel オブジェクトを、
negotiated
RTCDataChannelInit 辞書メンバーを
true に設定して作成し、他方に対してアウトオブバンド(例:Web サーバー経由)で、
negotiated RTCDataChannelInit 辞書
メンバーを true に設定し、同じidを持つ、対応する
RTCDataChannelを作成することが推奨される(SHOULD)と通知する。
これにより、個別に作成された2つのRTCDataChannel オブジェクトが接続される。
2つ目の方法では、非対称な
プロパティを持つチャネルを作成したり、一致する
idを指定することで宣言的にチャネルを作成したりできる。
各 RTCDataChannel
には、他方のピアへ実データを輸送するために使用される、関連付けられた underlying data
transport があります。RTCSctpTransport(SCTP アソシエーションの状態を表す)を利用する
SCTP データチャネルの場合、基盤となるデータトランスポートは SCTP のストリーム・ペアです。underlying data
transport
のトランスポート特性(順序どおり配信の設定や信頼性モードなど)は、チャネル作成時にピアによって構成されます。チャネルのプロパティは、作成後に変更できません。ピア間での実際のワイヤプロトコルは、WebRTC
DataChannel Protocol 仕様 [RFC8831] によって規定されています。
RTCDataChannel
は、異なる信頼性モードで動作するよう構成できます。信頼性のあるチャネルは、再送によってデータが相手のピアへ確実に届くことを保証します。非信頼チャネルは、再送回数を制限する(
maxRetransmits
)か、送信(再送を含む)が許可される時間を設定する(
maxPacketLifeTime
)ように構成されます。これらのプロパティは同時には使用できず、そのようにしようとするとエラーになります。いずれのプロパティも設定しない場合は、信頼性のあるチャネルになります。
RTCDataChannel は、createDataChannel によって作成されるか、
RTCDataChannelEvent を介してディスパッチされるもので、初期状態では
MUST 「connecting」でなければなりません。RTCDataChannel オブジェクトの underlying data transport の準備が整ったら、ユーザーエージェントは MUST
announce the RTCDataChannel as open しなければなりません。
RTCDataChannel を作成するには、 次の手順を実行します:
channel を新しく作成された RTCDataChannel
オブジェクトとします。
channel は、内部スロット [[ReadyState]] を持ち、
初期値は
"connecting" とします。
channel は、内部スロット [[BufferedAmount]] を持ち、
初期値は 0 とします。
channel は、次の名称の内部スロットを持つものとします: [[DataChannelLabel]]、[[Ordered]]、 [[MaxPacketLifeTime]]、 [[MaxRetransmits]]、 [[DataChannelProtocol]]、 [[Negotiated]]、および [[DataChannelId]]。
true とします。[[IsTransferable]] を
false に設定します。
このタスクは、channel に対して receiving messages on a data
channel アルゴリズムによってキューに入れられるいかなるタスクよりも先に実行される必要があります。
これは、RTCDataChannel
の転送中にメッセージが失われないことを保証するためです。
channel を返します。
ユーザーエージェントが RTCDataChannel をオープンとして通知する場合、ユーザーエージェントは MUST 次の手順を実行するタスクをキューに追加します:
関連する RTCPeerConnection オブジェクトの
[[IsClosed]] スロットが
true の場合、これらの手順を中止します。
channel を、通知対象の RTCDataChannel オブジェクトとします。
もし channel.[[ReadyState]] が
"closing" または
"closed" の場合、これらの手順を中止します。
channel.[[ReadyState]] を
"open"
に設定します。
Fire an event 名 open のイベントを channel
に対して発火します。
underlying data transport を通知する必要がある場合(
相手のピアが negotiated
を未設定または false に設定してチャネルを作成した場合)、作成処理を開始しなかった側のピアのユーザーエージェントは MUST
次の手順を実行するタスクをキューに追加します:
connection を、underlying data transport
に関連付けられた
RTCPeerConnection オブジェクトとします。
もし connection.[[IsClosed]] が
true であれば、これらの手順を中止します。
RTCDataChannel を作成し、 channel とします。
configuration を、WebRTC DataChannel Protocol 仕様 [RFC8832] に記載された underlying data transport を確立する過程の一部として、 相手のピアから受け取った情報バンドルとします。
channel の内部スロット
[[DataChannelLabel]]、
[[Ordered]]、[[MaxPacketLifeTime]]、
[[MaxRetransmits]]、[[DataChannelProtocol]]、
および [[DataChannelId]]
を、configuration の対応する値で初期化します。
channel.[[Negotiated]] を
false に初期化します。
Append
により channel を
connection.[[DataChannels]] に追加します。
channel.[[ReadyState]] を
"open"
に設定します(ただし、まだ open
イベントは発火しません)。
datachannel イベントハンドラー内で、
open イベントが発火する前に
メッセージ送信を開始できます。
Fire an event 名 datachannel のイベントを、
RTCDataChannelEvent インターフェイスを用い、
channel 属性を
channel に設定して connection に対して発火します。
RTCDataChannel オブジェクトの
基盤となるデータトランスポートは、クローズ手順 を実行することで、非突発的な方法で解体される場合があります。
その場合、ユーザーエージェントは MUST 次の手順を実行するタスクをキューに追加します:
channel を、その RTCDataChannel オブジェクト(基盤となるデータトランスポート がクローズされたもの)とします。
connection を、channel に関連付けられた RTCPeerConnection
オブジェクトとします。
Remove
により、connection.[[DataChannels]] から
channel を削除します。
channel.close によってこの手順が開始されたのでない限り、
channel.[[ReadyState]] を
"closing" に設定し、イベントを発火して
closing という名前のイベントを
channel に対して発火します。
次の手順を in parallelin
parallel で実行します:
channel の現在保留中のすべてのメッセージ送信を完了します。
channel の 基盤となるデータトランスポート に定義されたクローズ手順に従います:
関連する手順に従って、channel の data transport を Close します
。
closed
RTCDataChannel オブジェクトの
基盤となるデータトランスポート が
クローズ されたとき、ユーザーエージェントは MUST 次の手順を実行するタスクをキューに追加します:
channel を、その RTCDataChannel オブジェクト(基盤となるデータトランスポート がクローズされたもの)とします。
[[ReadyState]] が
"closed"
の場合、
これらの手順を中止します。
channel.[[ReadyState]] を
"closed" に設定します。
まだ存在している場合は、Remove
により connection.[[DataChannels]] から
channel を削除します。
transport が
エラーを伴ってクローズされた場合、イベントを発火して、error という名前のイベントを RTCErrorEvent
インターフェイスを用いて channel に対して発火します。このとき、その errorDetail
属性は
"sctp-failure"
に設定します。
RTCDataChannel の transfer steps は、value と
dataHolder が与えられたとき、次のとおりです。
もし value.[[IsTransferable]] が
false なら、DataCloneError DOMException をスローします。
dataHolder.[[ReadyState]] を value.[[ReadyState]]
に設定します。
dataHolder.[[DataChannelLabel]] を
value.[[DataChannelLabel]] に設定します。
dataHolder.[[Ordered]] を value.[[Ordered]] に設定します。
dataHolder.[[MaxPacketLifeTime]] を
value..[[MaxPacketLifeTime]] に設定します。
dataHolder.[[MaxRetransmits]] を
value.[[MaxRetransmits]] に設定します。
dataHolder.[[DataChannelProtocol]] を
value.[[DataChannelProtocol]] に設定します。
dataHolder.[[Negotiated]] を value.[[Negotiated]]
に設定します。
dataHolder.[[DataChannelId]] を
value.[[DataChannelId]] に設定します。
dataHolder の underlying data transport を value の underlying data transport に設定します。
value.[[IsTransferable]] を
false に設定します。
value.[[ReadyState]] を "closed" に設定します。
RTCDataChannel の transfer-receiving steps は、dataHolder
と channel が与えられたとき、次のとおりです。
channel.[[ReadyState]] を
dataHolder.[[ReadyState]] に初期化します。
channel.[[DataChannelLabel]] を
dataHolder.[[DataChannelLabel]] に初期化します。
channel.[[Ordered]] を dataHolder.[[Ordered]] に初期化します。
channel.[[MaxPacketLifeTime]] を
dataHolder.[[MaxPacketLifeTime]] に初期化します。
channel.[[MaxRetransmits]] を
dataHolder.[[MaxRetransmits]] に初期化します。
channel.[[DataChannelProtocol]] を
dataHolder.[[DataChannelProtocol]]
に初期化します。
channel.[[Negotiated]] を
dataHolder.[[Negotiated]] に初期化します。
channel.[[DataChannelId]] を
dataHolder.[[DataChannelId]] に初期化します。
channel の underlying data transport を dataHolder の underlying data transport に初期化します。
上記の手順では、[[BufferedAmount]]
を転送する必要はありません。値は常に 0 に等しいためです。
理由は、RTCDataChannel は、その send() algorithm が転送前に呼び出されていない場合にのみ転送できるためです。
もし underlying data transport が
transfer-receiving steps の時点でクローズされている場合、
RTCDataChannel オブジェクトは、
announcing a data
channel as closed アルゴリズムを
transfer-receiving steps の直後に実行することでクローズされます。
場合によっては、ユーザーエージェントが unable to create an
RTCDataChannel の underlying
data transport を作成できないことがあります。例えば、データチャネルの id が、SCTP ハンドシェイクにおいて
[RFC8831] の実装によってネゴシエートされた範囲外である場合があります。ユーザーエージェントが
RTCDataChannel の underlying data transport を作成できないと判断した場合、ユーザーエージェントは MUST 以下の手順を実行するタスクをキューに追加します。
channel を、ユーザーエージェントが underlying data transport を作成できなかった対象の RTCDataChannel オブジェクトとします。
channel.[[ReadyState]] を
"closed" に設定します。
イベントを発火して、error という名前のイベントを、
RTCErrorEvent インターフェイスを用い、errorDetail
属性を "data-channel-failure"
に設定して、channel に対して発火します。
RTCDataChannel
のメッセージが、underlying data transport を介して
型 type、データ rawData とともに受信されたとき、ユーザーエージェントは MUST
以下の手順を実行するタスクをキューに追加します。
channel を、ユーザーエージェントがメッセージを受信した対象の RTCDataChannel オブジェクトとします。
connection を、channel に関連付けられた RTCPeerConnection オブジェクトとします。
もし channel.[[ReadyState]] が
"open"
でない場合、
これらの手順を中止し、rawData を破棄します。
type と
channel.binaryType
に応じて、以下のサブ手順を実行します:
type が rawData を
string と示す場合:
data を、rawData を UTF-8 としてデコードした結果を表す DOMString とします。
type が rawData をバイナリと示し、かつ binaryType が "blob" の場合:
data を、新しい Blob オブジェクト(その生データソースとして rawData
を含む)とします。
type が rawData をバイナリと示し、かつ binaryType が "arraybuffer" の場合:
data を、新しい ArrayBuffer オブジェクト(その生データソースとして
rawData を含む)とします。
イベントを発火して、message という名前のイベントを、
MessageEvent インターフェイスを用いて発火します。このとき、その origin 属性は
serialization of an origin of
connection.[[DocumentOrigin]] に初期化し、data 属性は
data に初期化して、channel に対して発火します。
WebIDL[Exposed=(Window,DedicatedWorker), Transferable]
interface RTCDataChannel : EventTarget {
readonly attribute USVString label;
readonly attribute boolean ordered;
readonly attribute unsigned short? maxPacketLifeTime;
readonly attribute unsigned short? maxRetransmits;
readonly attribute USVString protocol;
readonly attribute boolean negotiated;
readonly attribute unsigned short? id;
readonly attribute RTCDataChannelState readyState;
readonly attribute unsigned long bufferedAmount;
[EnforceRange] attribute unsigned long bufferedAmountLowThreshold;
attribute EventHandler onopen;
attribute EventHandler onbufferedamountlow;
attribute EventHandler onerror;
attribute EventHandler onclosing;
attribute EventHandler onclose;
undefined close();
attribute EventHandler onmessage;
attribute BinaryType binaryType;
undefined send(USVString data);
undefined send(Blob data);
undefined send(ArrayBuffer data);
undefined send(ArrayBufferView data);
};
label の型は
USVString、読み取り専用
label 属性は、この
RTCDataChannel オブジェクトを他の
RTCDataChannel
オブジェクトと区別するために使用できるラベルを表します。スクリプトは、同じラベルを持つ複数の
RTCDataChannel
オブジェクトを作成できます。取得時、この属性は
MUST、[[DataChannelLabel]]
スロットの値を返さなければなりません。
ordered の型は
boolean、読み取り専用
ordered 属性は、
RTCDataChannel が順序保証されている場合は
true を、順不同の配信が許可されている場合は false を返します。取得時、この属性は
MUST、[[Ordered]] スロットの値を返さなければなりません。
maxPacketLifeTime の
型は unsigned short、読み取り専用、
nullable
maxPacketLifeTime
属性は、非信頼モードにおいて送信および再送信が行われ得る時間窓(ミリ秒)を返します。取得時、この属性は
MUST、[[MaxPacketLifeTime]]
スロットの値を返さなければなりません。
maxRetransmits
の型は unsigned short、
読み取り専用、nullable
maxRetransmits
属性は、非信頼モードで試行される再送の最大回数を返します。取得時、この属性は
MUST、[[MaxRetransmits]]
スロットの値を返さなければなりません。
protocol の型は
USVString、読み取り専用
protocol 属性は、この
RTCDataChannel
で使用されるサブプロトコル名を返します。取得時、この属性は
MUST、[[DataChannelProtocol]]
スロットの値を返さなければなりません。
negotiated の型は
boolean、読み取り専用
negotiated 属性は、
その RTCDataChannel
がアプリケーションによってネゴシエートされた場合は true を、そうでない場合は false を返します。取得時、この属性は
MUST、[[Negotiated]] スロットの値を返さなければなりません。
id の型は unsigned
short、読み取り専用、nullable
id 属性は、この
RTCDataChannel の ID
を返します。値は初期状態では null であり、これはチャネル作成時に ID が指定されておらず、かつ SCTP トランスポートの DTLS
の役割がまだネゴシエートされていない場合に返される値です。そうでなければ、スクリプトによって選択された ID、または
[RFC8832]
に従ってユーザーエージェントによって生成された ID を返します。ID が null 以外の値に設定された後は、変更されません。取得時、この属性は
MUST、[[DataChannelId]]
スロットの値を返さなければなりません。
readyState の型は
RTCDataChannelState、
読み取り専用
readyState 属性は、
RTCDataChannel
オブジェクトの状態を表します。取得時、この属性は
MUST、[[ReadyState]] スロットの値を返さなければなりません。
bufferedAmount
の型は unsigned long、
読み取り専用
bufferedAmount
属性は、取得時に MUST、
[[BufferedAmount]]
スロットの値を返さなければなりません。この属性は、send()
を使用してキューに入れられたアプリケーションデータ(UTF-8 テキストおよびバイナリデータ)のバイト数を公開します。データ送信はin
parallelで行われ得ますが、競合状態を防ぐため、現在のタスクがイベントループに制御を戻す前に返される値を減少させてはMUST NOTなりません。値には、プロトコルによって発生するフレーミングのオーバーヘッドや、OS
やネットワークハードウェアによるバッファリングは含まれません。
[[BufferedAmount]] スロットの値は、
send()
メソッドの呼び出しごとに、
[[ReadyState]]
スロットが
"open"
である限り増加するだけですが、チャネルが閉じてもスロットは 0 にリセットされません。underlying data transport
がキューからデータを送信したとき、ユーザーエージェントは送信されたバイト数だけ
[[BufferedAmount]]
を減少させるタスクをキューに入れなければなりません MUST。
bufferedAmountLowThreshold の型は
unsigned long
bufferedAmountLowThreshold
属性は、bufferedAmount
が低いと見なされるしきい値を設定します。bufferedAmount
がこのしきい値を上回っている状態から、等しいまたは下回る状態に減少したとき、bufferedamountlow
イベントが発火します。bufferedAmountLowThreshold
は、新しい各 RTCDataChannel で初期値が 0
ですが、アプリケーションはいつでもその値を変更できます。
onopen の型は EventHandler
open です。
onbufferedamountlow の型は EventHandler
bufferedamountlow
です。
onerror の型は EventHandler
このイベントハンドラーのイベントタイプは RTCErrorEvent です。
errorDetail には
"sctp-failure" が含まれ、
sctpCauseCode には SCTP の
Cause Code の値が、
また message
には SCTP の Cause-Specific-Information が、必要に応じて追加のテキストとともに含まれます。
onclosing の型は EventHandler
このイベントハンドラーのイベントタイプは closing です。
onclose の型は EventHandler
このイベントハンドラーのイベントタイプは close です。
onmessage の型は EventHandler
このイベントハンドラーのイベントタイプは message です。
binaryType の型は
BinaryType
binaryType
属性は、最後に設定された値を返します。 RTCDataChannel
オブジェクトが作成されるとき、
binaryType 属性は文字列
"arraybuffer" に初期化されなければなりません MUST。
この属性は、バイナリデータがスクリプトにどのように公開されるかを制御します。Web Socket の binaryType を参照してください。
close()
RTCDataChannelを閉じる。これは、
RTCDataChannelオブジェクトが
このピアによって作成されたか、
リモートピアによって作成されたかにかかわらず呼び出すことができる。
close
メソッドが呼び出されたとき、ユーザーエージェントは MUST
次の手順を実行します:
閉じようとしている RTCDataChannel オブジェクトを
channel とします。
もし channel.[[ReadyState]] が
"closing" または
"closed"
の場合、これらの手順を中止します。
channel.[[ReadyState]] を
"closing"
に設定します。
もし クローズ手順 がまだ開始されていない場合は、開始します。
send
引数の型が string オブジェクトの場合、send()
アルゴリズム に記載の手順を実行します。
send
引数の型が Blob オブジェクトの場合、send()
アルゴリズム に記載の手順を実行します。
send
引数の型が ArrayBuffer オブジェクトの場合、send() アルゴリズム に記載の手順を実行します。
send
引数の型が ArrayBufferView オブジェクトの場合、send() アルゴリズム に記載の手順を実行します。
send()
メソッドは、異なるデータ引数型を扱うようにオーバーロードされています。いずれのバージョンのメソッドが呼び出された場合でも、ユーザーエージェントは MUST 次の手順を実行します:
データを送信しようとしている RTCDataChannel オブジェクトを
channel とします。
channel.[[IsTransferable]] を
false に設定します。
もし channel.[[ReadyState]] が
"open" でない場合、throw し、
InvalidStateError を送出します。
メソッドの引数の型に対応するサブ手順を実行します:
string オブジェクト:
メソッドの引数を UTF-8 としてエンコードした結果を表すバイトバッファを data とします。
Blob オブジェクト:
Blob オブジェクトが表す生データを data とします。
Blob オブジェクトから data
を取得する処理は非同期に行われることがありますが、ユーザーエージェントは
channel の 基盤となるデータトランスポート へデータをキューに入れる順序が
send メソッドの呼び出し順と同じになるようにします。data のバイトサイズは同期的に把握されている必要があります。
ArrayBuffer オブジェクト:
ArrayBuffer
オブジェクトで記述されるバッファに格納されたデータを data とします。
ArrayBufferView オブジェクト:
ArrayBuffer オブジェクトで記述され、ArrayBufferView
オブジェクトが参照しているバッファの区間に格納されたデータを data とします。
data のバイトサイズが、
channel に関連付けられた RTCSctpTransport 上の maxMessageSize
の値を超える場合、throw し、
TypeError を送出します。
channel の 基盤となるデータトランスポート 上で送信のために
data をキューに入れます。
バッファ空き容量が不十分で data をキューに入れられない場合、throw し、
OperationError を送出します。
onerror を通じて通知されます。
[[BufferedAmount]] スロットの値を
data のバイトサイズだけ増加させます。
WebIDLdictionary RTCDataChannelInit {
boolean ordered = true;
[EnforceRange] unsigned short maxPacketLifeTime;
[EnforceRange] unsigned short maxRetransmits;
USVString protocol = "";
boolean negotiated = false;
[EnforceRange] unsigned short id;
};
ordered の型は boolean、既定値は true
false に設定された場合、データは順不同で配信されることが許可されます。既定値の true は、データが順序どおりに配信されることを保証します。
maxPacketLifeTime の型は unsigned short
確認応答がない場合に、チャネルがデータを送信または再送信する時間(ミリ秒)を制限します。この値がユーザーエージェントでサポートされる最大値を超える場合、値は切り詰め(クランプ)られることがあります。
maxRetransmits の型は unsigned short
配信に失敗した場合に、チャネルがデータを再送信する最大回数を制限します。この値がユーザーエージェントでサポートされる最大値を超える場合、値は切り詰め(クランプ)られることがあります。
protocol の型は USVString、既定値は ""
このチャネルで使用されるサブプロトコル名。
negotiated の型は boolean、既定値は
false
既定値の false は、ユーザーエージェントがチャネルをインバンドで通知し、相手のピアに対応する
RTCDataChannel
オブジェクトをディスパッチするよう指示することを意味します。true に設定した場合は、アプリケーション側でチャネルをネゴシエートし、相手のピアで同じ
id を持つ
RTCDataChannel
オブジェクトを作成する必要があります。
id の
型は unsigned short
negotiated が true
のとき、チャネル ID を設定します。
negotiated が false
の場合は無視されます。
WebIDLenum RTCDataChannelState {
"connecting",
"open",
"closing",
"closed"
};
| 列挙値 | 説明 |
|---|---|
connecting
|
ユーザーエージェントは、基盤となるデータトランスポートの確立を試みています。これは、 |
open
|
基盤となるデータトランスポートが確立され、通信が可能です。 |
closing
|
手順に従って 基盤となるデータトランスポートのクローズが開始されています。 |
closed
|
基盤となるデータトランスポートが |
datachannel イベントは、RTCDataChannelEvent
インターフェイスを使用します。
WebIDL[Exposed=Window]
interface RTCDataChannelEvent : Event {
constructor(DOMString type, RTCDataChannelEventInit eventInitDict);
readonly attribute RTCDataChannel channel;
};
RTCDataChannelEvent.constructor()
channel の型は
RTCDataChannel、読み取り専用
channel
属性は、イベントに関連付けられた
RTCDataChannel
オブジェクトを表します。
WebIDLdictionary RTCDataChannelEventInit : EventInit {
required RTCDataChannel channel;
};
channel の型は RTCDataChannel、必須
イベントによって通知される RTCDataChannel オブジェクト。
RTCDataChannel
オブジェクトは、次のいずれかの場合、MUST ガベージコレクションされてはならない。
[[ReadyState]] スロットが
"connecting" であり、少なくとも 1
つのイベントリスナーが
open
イベント、message イベント、
error イベント、closing
イベント、または close イベントに登録されている。
[[ReadyState]] スロットが
"open" であり、
少なくとも 1 つのイベントリスナーが
message イベント、error
イベント、closing イベント、または
close
イベントに登録されている。
[[ReadyState]] スロットが
"closing"
であり、少なくとも 1 つのイベントリスナーが
error イベント、または close
イベントに登録されている。
underlying data transport が確立され、データが送信のためにキューに入っている。
本セクションでは、RTCRtpSender
上のインターフェイスについて説明します。これは、RTCPeerConnection を介して
DTMF(電話のキーパッド)値を送信するためのものです。DTMF が相手ピアにどのように送信されるかの詳細は [RFC7874]
に記載されています。
ピアツーピア DTMF API は、以下のとおり RTCRtpSender インターフェイスを拡張します。
WebIDL partial interface RTCRtpSender {
readonly attribute RTCDTMFSender? dtmf;
};
dtmf の型は RTCDTMFSender、読み取り専用、
nullable
取得時、dtmf 属性は、[[Dtmf]] 内部スロットの値を返します。これは DTMF の送信に使用できる
RTCDTMFSender を表し、未設定の場合は
null を返します。[[Dtmf]] 内部スロットは、RTCRtpSender の
[[SenderTrack]]
の kind が "audio" のときに設定されます。
RTCDTMFSender を作成するために、ユーザーエージェントは MUST 次の手順を実行します:
dtmf を、新しく作成された RTCDTMFSender オブジェクトとします。
dtmf が内部スロット [[Duration]] を持つようにします。
dtmf が内部スロット [[InterToneGap]] を持つようにします。
dtmf が内部スロット [[ToneBuffer]] を持つようにします。
WebIDL[Exposed=Window]
interface RTCDTMFSender : EventTarget {
undefined insertDTMF(DOMString tones, optional unsigned long duration = 100, optional unsigned long interToneGap = 70);
attribute EventHandler ontonechange;
readonly attribute boolean canInsertDTMF;
readonly attribute DOMString toneBuffer;
};
ontonechange の型は EventHandler
このイベントハンドラーのイベントタイプは tonechange です。
canInsertDTMF の型は boolean、読み取り専用
RTCDTMFSender
dtmfSender が DTMF を送信可能かどうか。取得時、ユーザーエージェントは MUST
DTMF
を送信できるかどうかを判定 の結果を
dtmfSender に対して返します。
toneBuffer の型は
DOMString、読み取り専用
toneBuffer
属性は、再生待ちのトーンの一覧を MUST 返します。この一覧の構文、内容、解釈については insertDTMF を参照してください。
insertDTMF
RTCDTMFSender オブジェクトの insertDTMF メソッドは、
DTMF トーンを送信するために使用されます。
tones 引数は文字の並びとして扱われます。文字 0〜9、A〜D、#、* は対応する DTMF トーンを生成します。文字 a〜d は入力時に大文字へ正規化され MUST、A〜D と同等です。[RTCWEB-AUDIO] セクション 3 に記載のとおり、0〜9、A〜D、#、* のサポートは必須です。文字 ',' は MUST サポートされ、tones 引数内の次の文字を処理する前に 2 秒の遅延を示します。その他すべての文字(かつそれらのみ)は MUST 未認識 と見なされます。
duration 引数は、tones 引数で渡された各文字に用いる継続時間(ms)を示します。継続時間は 6000 ms を超えることも 40 ms 未満であることもできません。既定値は各トーン 100 ms です。
interToneGap 引数は、トーン間の間隔(ms)を示します。ユーザーエージェントはその値を少なくとも 30 ms、最大で 6000 ms にクランプします。既定値は 70 ms です。
ブラウザーは MAY、duration と interToneGap の時間を増やし、DTMF の開始・停止時間が RTP パケット境界に整合するようにできますが、どちらも単一の RTP オーディオパケットの継続時間を超えて増加させてはなりません MUST。
insertDTMF()
メソッドが呼び出されたとき、ユーザーエージェントは MUST 次の手順を実行します:
RTCRtpSender とします。
transceiver を、sender に関連付けられた RTCRtpTransceiver
オブジェクトとします。
RTCDTMFSender とします。
false を返す場合、throw し、InvalidStateError を送出します。
未認識 の文字が含まれている場合、throw し、InvalidCharacterError を送出します。
[[ToneBuffer]] スロットを
tones に設定します。
[[Duration]] を
duration の値に設定します。
[[InterToneGap]] を
interToneGap の値に設定します。
[[Duration]] を
40 ms に設定します。
[[Duration]] を
6000 ms に設定します。
[[InterToneGap]] を 30 ms
に設定します。
[[InterToneGap]] を 6000 ms
に設定します。
sendrecv"
nor
"sendonly"false を返す場合、これらの手順を中止します。
[[ToneBuffer]]
スロットが空文字列を含む場合、イベントを発火して tonechange
という名前のイベントを、
RTCDTMFToneChangeEvent
インターフェイスを用い、
tone
属性を空文字列に設定して RTCDTMFSender
オブジェクトに対して発火し、これらの手順を中止します。
[[ToneBuffer]]
スロットから最初の文字を取り除き、その文字を
tone とします。
"," の場合、関連する RTP メディアストリームで
2000 ms のあいだトーン送信を遅延し、今から 2000 ms
後に実行するタスクをキューに入れ、DTMF 再生タスクの手順 を実行します。
"," でない場合、適切なコーデックを用いて関連する RTP メディアストリーム上で
tone の再生を [[Duration]] ms 行い、その後 [[Duration]] + [[InterToneGap]] ms 後に
DTMF
再生タスクの手順 を実行するタスクをキューに入れます。
tonechange
という名前のイベントを、
RTCDTMFToneChangeEvent
インターフェイスを用い、
tone
属性を tone に設定して RTCDTMFSender
オブジェクトに対して発火します。
insertDTMF
はトーンバッファを置き換えるため、再生中の DTMF トーンに追加するには、insertDTMF を、([[ToneBuffer]]
スロットに格納された)残りのトーンと新しいトーンを連結した文字列で呼び出す必要があります。空の tones 引数で insertDTMF
を呼び出すと、現在再生中のトーンの後に再生予定のすべてのトーンをキャンセルできます。
DTMF を送信できるかどうかを判定するために、RTCDTMFSender
インスタンス dtmfSender に対して、ユーザーエージェントは MUST 次の手順を実行します:
RTCRtpSender(dtmfSender に関連付け)とします。
RTCRtpTransceiver(sender
に関連付け)とします。
RTCPeerConnection(transceiver
に関連付け)とします。
RTCPeerConnectionState が
"connected"
でない場合、false を返します。
[[Stopping]] が
true の場合、false を返します。
[[SenderTrack]] が null の場合、
false を返します。
[[CurrentDirection]] が
"sendrecv" でも
"sendonly"
でもない場合、
false を返します。
[[SendEncodings]][0] の active
が false の場合、false を返します。
"audio/telephone-event" のコーデックが、この
sender で送信用にネゴシエートされていない場合、false を返します。
true を返します。
tonechange イベントは、RTCDTMFToneChangeEvent
インターフェイスを使用します。
WebIDL[Exposed=Window]
interface RTCDTMFToneChangeEvent : Event {
constructor(DOMString type, optional RTCDTMFToneChangeEventInit eventInitDict = {});
readonly attribute DOMString tone;
};
RTCDTMFToneChangeEvent.constructor()
tone の型は DOMString、読み取り専用
tone
属性には、再生がちょうど開始されたトーン("," を含む)の文字が含まれます(insertDTMF
を参照)。値が空文字列の場合、[[ToneBuffer]]
スロットが空文字列であり、以前のトーンの再生が完了したことを示します。
WebIDL dictionary RTCDTMFToneChangeEventInit : EventInit {
DOMString tone = "";
};
tone の型は DOMString、既定値は ""
tone
属性には、再生がちょうど開始されたトーン("," を含む)の文字が含まれます(insertDTMF
を参照)。値が空文字列の場合、[[ToneBuffer]]
スロットが空文字列であり、以前のトーンの再生が完了したことを示します。
基本的な統計モデルは、ブラウザーが監視対象オブジェクトに対する統計の集合を、 統計オブジェクトの形で維持する、というものである。
関連するオブジェクト群は、セレクターで参照される場合がある。セレクターは例えば
MediaStreamTrack であってよい。トラックが有効なセレクターであるためには、
MUST
MediaStreamTrack であり、統計要求が発行された
RTCPeerConnection
オブジェクトによって送受信されていることが必要である。
呼び出し元の Web アプリケーションはセレクターを
getStats()
メソッドに渡し、ブラウザーは
統計選択アルゴリズムに従って、そのセレクターに関連する統計の集合を(JavaScript
で)出力する。
なお、このアルゴリズムはセレクターの送信側または受信側を対象とする。
統計オブジェクトで返される統計は、
繰り返しの問い合わせをRTCStatsの
id辞書メンバーで関連付けられるよう設計されている。
したがって、Web アプリケーションは、ある期間の始めと終わりに測定を要求することで、その期間にわたる測定値を得ることができる。
いくつかの例外を除き、監視対象オブジェクトは一度作成されると、
対応するRTCPeerConnectionの存続期間中は存在し続ける。
これにより、対応するピア接続がcloseされた後でも
getStats()
の結果にそれらの統計が含まれることが保証される。
ごく一部の監視対象オブジェクトのみがより短い存続期間を持つ。 これらのオブジェクトの統計は、その後の getStats() の結果には含まれない。 [WEBRTC-STATS] のオブジェクト記述に、これらの監視対象オブジェクトがいつ削除されるかが記載されている。
統計 API は、以下のとおりRTCPeerConnection インターフェイスを拡張する。
WebIDL partial interface RTCPeerConnection {
Promise<RTCStatsReport> getStats(optional MediaStreamTrack? selector = null);
};
getStats
指定されたセレクターの統計を収集し、結果を非同期に報告する。
getStats()
メソッドが呼び出されたとき、ユーザーエージェントは
MUST 次の手順を実行する:
selectorArg をメソッドの第 1 引数とする。
connection を、このメソッドが呼び出された
RTCPeerConnection
オブジェクトとする。
もし selectorArg が null なら、
selector を null とする。
もし selectorArg が MediaStreamTrack なら、
selector を connection 上の、
RTCRtpSender または
RTCRtpReceiver のうち、
そのtrack属性が
selectorArg に一致するものとする。
そのような sender 又は receiver が存在しない場合、または条件に合致する sender 又は receiver が複数存在する場合は、
新たに生成した
InvalidAccessError で
promise をrejectして返す。
p を新しい promise とする。
次の手順を並行して実行する:
統計選択アルゴリズムに従って、 selector により示される統計を収集する。
現在の realm のグローバルオブジェクトを
global として、ネットワーキング タスク
ソース上で
グローバルタスクをキューに入れ、
収集した統計を含む
RTCStatsReport
オブジェクトで
resolve する。
p を返す。
getStats()
メソッドは、成功結果を
RTCStatsReport オブジェクトの形式で返す。
RTCStatsReport オブジェクトは、
調査対象のオブジェクト(id 属性。RTCStats インスタンス内)を識別する文字列と、
それに対応する RTCStats 派生辞書とのマップである。
RTCStatsReport は、
複数の RTCStats 派生辞書で構成されうる。
それぞれが、実装が当該セレクターに関連すると考える 1 つの基盤オブジェクトの統計を報告する。
セレクターの合計値は、特定の型の統計を全て合算することで得られる。
例えば、RTCRtpSender
がネットワーク上でそのトラックを運ぶために複数の SSRC を用いる場合、
RTCStatsReport には
SSRC ごとに 1 つの RTCStats 派生辞書が含まれうる
(これは統計属性 ssrc の値で区別できる)。
RTCStats 辞書は、
特定の監視対象オブジェクトを検査して構築された
統計オブジェクト
を表す。
RTCStats 辞書は基本型であり、
timestamp や
type のような既定属性の集合を規定する。
個別の統計は、この RTCStats 辞書を拡張することで追加される。
統計名は標準化されているが、実装によっては実験的な値、またはWeb アプリケーションがまだ知らない値を使用している場合がある。 したがって、アプリケーションは未知の統計に対処できるようにしておく MUST がある。
統計は計算において妥当な値を得るため、互いに同期している必要がある。
例えば、bytesSent と
packetsSent が共に報告される場合、
「平均パケットサイズ」を「bytes / packets」として計算できるよう、同一の間隔で報告されなければならない。
間隔が異なると誤差を生じる。
したがって実装は、単一の RTCStats 派生辞書内の全ての統計について同期した値を返す
MUST がある。
WebIDLdictionary RTCStats {
required DOMHighResTimeStamp timestamp;
required RTCStatsType type;
required DOMString id;
};
RTCStats のメンバー
timestamp の型は DOMHighResTimeStamp
The タイムスタンプは
,
of type timestampDOMHighResTimeStamp,
associated with this object. The time is relative
to the UNIX
epoch (Jan 1[HIGHRES-TIME] に準拠し、1970,Performance の
timeOrigin UTC)+
Performance.now() (情報収集時点)として定義される。
受信した RTCP パケットなど、リモートソースに由来する統計については、
timestamp
は情報がローカルのエンドポイントに到着した時刻を表す。リモート側のタイムスタンプは、該当する場合、
RTCStats
派生辞書の追加フィールドに含まれる。
type の型は RTCStatsType
このオブジェクトの種類。
id の型は DOMString
この RTCStats
オブジェクトを生成するために調査されたオブジェクトに関連付けられた一意の
id。
2 つの RTCStats オブジェクトが、
2 つの異なる RTCStatsReport から抽出された場合でも、
同じ基盤オブジェクトを調査して生成されたものであれば、同一の id を持つ MUST。
統計の id は、アプリケーションによって予測可能であってはならない MUST NOT。 これは、特定のユーザーエージェントの id 生成方法に依存することを防ぎ、 特定の統計オブジェクトの id を既に読み取っていない限り、アプリケーションが id で統計オブジェクトを取得できないようにするためである。
ユーザーエージェントは、上記要件を満たす限り、任意の形式の id を選択できる。
ユーザーエージェントは、ピア接続ごとに一意なソルトを用いる限り、予測可能に生成された文字列をハッシュ関数で予測不能な文字列に変換できる。 これにより、実装は内部的に予測可能な id を持つことができ、 getStats() 呼び出し間で統計オブジェクトが安定した id を持つことを保証しやすくなる。
RTCStatsType
の有効な値の集合と、それらが示す RTCStats 由来の辞書は、
[WEBRTC-STATS] に記載されている。
統計選択アルゴリズムは次のとおりである:
RTCStatsReport とする。
null なら、
connection 全体の統計を収集して result に追加し、
result を返してこれ以降の手順を中止する。
RTCRtpSender なら、次のオブジェクトの統計を収集して
result に追加する:
RTCOutboundRtpStreamStats オブジェクト。
RTCOutboundRtpStreamStats オブジェクトから、
直接または間接に参照される全ての統計オブジェクト。
RTCRtpReceiver なら、次のオブジェクトの統計を収集して
result に追加する:
RTCInboundRtpStreamStats オブジェクト。
RTCInboundRtpStreamStats から、
直接または間接に参照される全ての統計オブジェクト。
[WEBRTC-STATS] に挙げられている統計は、 幅広いユースケースをカバーすることを意図している。 そのすべてをすべての WebRTC 実装が実装する必要はない。
実装は、対応するオブジェクトが
RTCPeerConnection上に存在する場合、次の
typeについて統計情報を生成することを
サポートしなければならない(MUST)。その際、そのオブジェクトについて有効な場合に
列挙されているフィールドに加えて、
RTCStats 辞書で定義されている汎用フィールドも含める。
実装は、[WEBRTC-STATS] に定義された他の任意の統計を生成することが MAY であり、 文書化されていない統計を生成することも MAY である。
ユーザーが音声品質の低下を体験しており、その原因がパケットロスかどうかをアプリケーションが判定したいケースを考える。 次のサンプルコードが利用できる:
async function gatherStats(pc) {
try {
const [sender] = pc.getSenders();
const baselineReport = await sender.getStats();
await new Promise(resolve => setTimeout(resolve, aBit)); // 少し待機する
const currentReport = await sender.getStats();
// 現在のレポートの要素をベースラインと比較する
for (const now of currentReport.values()) {
if (now.type != 'outbound-rtp') continue;
// ベースラインレポートから対応する統計を取得する
const base = baselineReport.get(now.id);
if (!base) continue;
const remoteNow = currentReport.get(now.remoteId);
const remoteBase = baselineReport.get(base.remoteId);
const packetsSent = now.packetsSent - base.packetsSent;
const packetsReceived = remoteNow.packetsReceived -
remoteBase.packetsReceived;
const fractionLost = (packetsSent - packetsReceived) / packetsSent;
if (fractionLost > 0.3) {
// fractionLost が 0.3 より大きければ、原因である可能性が高い
}
}
} catch (err) {
console.error(err);
}
}
[GETUSERMEDIA] 仕様で定義される MediaStreamTrack
インターフェイスは、通常、音声または映像のデータストリームを表す。1 つ以上の MediaStreamTrack は MediaStream にまとめることができる(厳密には、[GETUSERMEDIA] で定義される MediaStream は 0 個以上の MediaStreamTrack オブジェクトを含みうる)。
MediaStreamTrack
は、(例えばローカルカメラに限らず)リモートピアから来る、またはリモートピアへ送られるメディアフローを表すように拡張されうる。この能力を MediaStreamTrack
オブジェクトで有効にするために必要な拡張について本節で述べる。メディアがピアへどのように送信されるかは、
[RFC8834]、[RFC7874]、および [RFC8835] に記載されている。
他のピアへ送信された MediaStreamTrack は、受信側からはただ 1 つの MediaStreamTrack
として見える。ピアとは、この仕様をサポートするユーザーエージェントと定義される。さらに、送信側アプリケーションは、当該 MediaStream オブジェクト(群)を示すことができる。受信側では対応する
MediaStream
オブジェクト(群)が(未作成であれば)生成され、適宜内容が設定される。
本書の前の節でも述べたとおり、RTCRtpSender および RTCRtpReceiver オブジェクトは、アプリケーションが MediaStreamTrack の送受信をより細かく制御するために利用できる。
Media Capture and Streams 仕様で扱われる最小単位は「チャンネル」である。チャンネルは、例えば RTP
のペイロードタイプとして、送信用にまとめてエンコードされることを意図している。コーデックが共同でエンコードする必要のあるすべてのチャンネルは同じ MediaStreamTrack に含まれていなければならず MUST、コーデックはそのトラック内のすべてのチャンネルをエンコード、または破棄できるべきである SHOULD。
ある MediaStreamTrack に対する入力および出力の概念は、ネットワーク経由で送受信される MediaStreamTrack オブジェクトにも適用される。RTCPeerConnection オブジェクト(本書前節で説明)により作成される MediaStreamTrack
は、リモートピアから受信したデータを入力として受け取る。同様に、ローカルのソース、例えば [GETUSERMEDIA] を介したカメラからの
MediaStreamTrack は、当該オブジェクトを RTCPeerConnection
オブジェクトと共に用いる場合、リモートピアに送信される内容を表す出力を持つ。
[GETUSERMEDIA] で述べられている MediaStream および MediaStreamTrack
オブジェクトの複製の概念も、ここで適用される。この機能は例えばビデオ会議のシナリオにおいて、ユーザーのカメラとマイクからのローカル映像をローカルモニターに表示しつつ、音声のみをリモートピアに送信する(例えばユーザーが「ビデオミュート」機能を使用した場合の応答として)用途に利用できる。異なる
MediaStreamTrack オブジェクトを新たな MediaStream
オブジェクトに組み合わせることは、特定の状況で有用である。
本書では、RTCPeerConnection
と併用される際に関係する以下のオブジェクトの側面のみを規定する。MediaStream
および MediaStreamTrack の一般的な利用方法については、[GETUSERMEDIA] 文書の元の定義を参照のこと。
id 属性(MediaStream にて規定)は、このストリームに固有の id
を返す。これにより、RTCPeerConnection API
のリモート側でストリームを識別できる。
リモートピアから得られたストリームを表すために MediaStream が作成される場合、id 属性は、リモートソースから提供された情報で初期化される。
id
はストリームのソースに対して一意であるが、重複が発生しないことを意味するわけではない。例えば、ローカルで生成されたストリームのトラックが、あるユーザーエージェントからリモートピアへ RTCPeerConnection
を用いて送られ、その後同じ方法で元のユーザーエージェントへ送り返される場合、元のユーザーエージェントは同じ id
を持つ複数のストリーム(ローカル生成のものとリモートピアから受信したもの)を持つことになる。
非ローカルなメディアソース(各 MediaStreamTrack が RTCRtpReceiver に関連付けられている場合の RTP
ソース)における、オブジェクトの MediaStream への参照は、常に強参照である。
RTCRtpReceiver が、対応する MediaStreamTrack がミュート状態で終了していない(muted だが ended ではない)RTP
ソースでデータを受信し、かつ当該 [[Receptive]] スロットを持つ RTCRtpTransceiver オブジェクトで
RTCRtpReceiver がメンバーであるものの値が
true の場合、対応する ミュート状態を設定する タスクをキューに入れ、その MediaStreamTrack のミュート状態を false にしなければならない
MUST。
RTCRtpReceiver が受信する RTP
ソースのメディアストリームに対する SSRC の一つが、BYE の受信またはタイムアウトによって削除された場合、対応する ミュート状態を設定する
タスクをキューに入れ、対応する MediaStreamTrack のミュート状態を true にしなければならない
MUST。なお、setRemoteDescription
によっても、当該 ミュート状態の設定(track の値を true にする)が生じうる。
手続き トラックの追加、トラックの削除、および トラックのミュート状態の設定 は、 [GETUSERMEDIA] に規定されている。
RTCRtpReceiver
receiver によって生成された MediaStreamTrack のトラックが
[GETUSERMEDIA] における ended
状態(例えば
receiver.track.stop の呼び出しにより)になった場合、ユーザーエージェントは、例えば receiver
のデコーダーを停止するなどして、受信ストリームに割り当てられたリソースを解放してもよい MAY。
制約および制約可能プロパティの概念(MediaTrackConstraints(MediaStreamTrack.getConstraints()、MediaStreamTrack.applyConstraints())、および MediaTrackSettings
(MediaStreamTrack.getSettings())を含む)は、[GETUSERMEDIA]
に概説されている。ただし、ピア接続に由来するトラックの制約可能プロパティは、getUserMedia() によって供給されるものとは異なる。MediaStreamTrack が リモートソース
に由来する場合に適用される制約および設定はここで定義する。リモートトラックの設定は、最新に受信したフレームを表す。
MediaStreamTrack.getCapabilities()
は常に空集合を返さなければならず MUST、MediaStreamTrack.applyConstraints()
は、ここで定義する制約について、リモートトラック上では常に OverconstrainedError で reject しなければならない MUST。
次の制約可能プロパティは、MediaStreamTrack(動画)が リモートソース に由来する場合に適用されるものとして定義する:
| プロパティ名 | 値 | 注記 |
|---|---|---|
| width |
ConstrainULong
|
設定としては、最新に受信したフレームの幅(ピクセル)を表す。 |
| height |
ConstrainULong
|
設定としては、最新に受信したフレームの高さ(ピクセル)を表す。 |
| frameRate |
ConstrainDouble
|
設定としては、直近に受信したフレームに基づくフレームレートの推定値である。 |
| aspectRatio |
ConstrainDouble
|
設定としては、最新フレームのアスペクト比(幅ピクセル数を高さピクセル数で割った値)であり、10 桁目に丸めた倍精度小数で表す。 |
本書は、MediaStreamTrack(音声)が リモートソース に由来する場合に適用される制約可能プロパティを定義しない。
このセクションは規範的ではありません。
2 つのピアが相互に接続を確立することを決めたとき、両者とも次の手順を踏みます。STUN/TURN サーバーの設定は、パブリック IP アドレスの取得や NAT 越えの設定に使用できるサーバーを記述します。最初に通信することを確認したのと同じ帯域外のメカニズムを用いて、シグナリングチャネル向けのデータも互いに送信する必要があります。
const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);
// ICE candidate を相手ピアへ送る
pc.onicecandidate = ({candidate}) => signaling.send({candidate});
// 「negotiationneeded」イベントでオファー生成を開始する
pc.onnegotiationneeded = async () => {
try {
await pc.setLocalDescription();
// オファーを相手ピアへ送る
signaling.send({description: pc.localDescription});
} catch (err) {
console.error(err);
}
};
pc.ontrack = ({track, streams}) => {
// リモートトラックのメディアが到着したら、リモート側の video 要素に表示する
track.onunmute = () => {
// 既に設定済みなら srcObject を再設定しない。
if (remoteView.srcObject) return;
remoteView.srcObject = streams[0];
};
};
// start() を呼んで開始する
function start() {
addCameraMic();
}
// カメラとマイクを接続に追加する
async function addCameraMic() {
try {
// ローカルストリームを取得し、自分のビューに表示して送信に追加する
const stream = await navigator.mediaDevices.getUserMedia(constraints);
for (const track of stream.getTracks()) {
pc.addTrack(track, stream);
}
selfView.srcObject = stream;
} catch (err) {
console.error(err);
}
}
signaling.onmessage = async ({data: {description, candidate}}) => {
try {
if (description) {
await pc.setRemoteDescription(description);
// オファーを受け取ったら、アンサーで応答する必要がある
if (description.type == 'offer') {
if (!selfView.srcObject) {
// 権限取得でネゴシエーションをブロックする(本番コードでは非推奨)
await addCameraMic();
}
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
}
} else if (candidate) {
await pc.addIceCandidate(candidate);
}
} catch (err) {
console.error(err);
}
};
2 つのピアが相互に接続を確立し、ICE、DTLS、メディアの接続を「ウォームアップ」して、即座にメディアの送受信を可能にしたい場合、両者とも次の手順を踏みます。
const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
let pc;
let audio;
let video;
let started = false;
// メディア準備前に warmup() を呼び出し、ICE・DTLS・メディアをウォームアップする
async function warmup(isAnswerer) {
pc = new RTCPeerConnection(configuration);
if (!isAnswerer) {
audio = pc.addTransceiver('audio');
video = pc.addTransceiver('video');
}
// ICE candidate を相手ピアへ送る
pc.onicecandidate = ({candidate}) => signaling.send({candidate});
// 「negotiationneeded」イベントでオファー生成を開始する
pc.onnegotiationneeded = async () => {
try {
await pc.setLocalDescription();
// オファーを相手ピアへ送る
signaling.send({description: pc.localDescription});
} catch (err) {
console.error(err);
}
};
pc.ontrack = async ({track, transceiver}) => {
try {
// リモートトラックのメディアが到着したら、video 要素に表示する
event.track.onunmute = () => {
// 既に設定済みなら srcObject を再設定しない。
if (!remoteView.srcObject) {
remoteView.srcObject = new MediaStream();
}
remoteView.srcObject.addTrack(track);
}
if (isAnswerer) {
if (track.kind == 'audio') {
audio = transceiver;
} else if (track.kind == 'video') {
video = transceiver;
}
if (started) await addCameraMicWarmedUp();
}
} catch (err) {
console.error(err);
}
};
try {
// ローカルストリームを取得し、自分のビューに表示して送信に追加する
selfView.srcObject = await navigator.mediaDevices.getUserMedia(constraints);
if (started) await addCameraMicWarmedUp();
} catch (err) {
console.error(err);
}
}
// warmup() の後に start() を呼び、両端からのメディア送信を開始する
function start() {
signaling.send({start: true});
signaling.onmessage({data: {start: true}});
}
// ウォームアップ済みの接続にカメラとマイクを追加する
async function addCameraMicWarmedUp() {
const stream = selfView.srcObject;
if (audio && video && stream) {
await Promise.all([
audio.sender.replaceTrack(stream.getAudioTracks()[0]),
video.sender.replaceTrack(stream.getVideoTracks()[0]),
]);
}
}
signaling.onmessage = async ({data: {start, description, candidate}}) => {
if (!pc) warmup(true);
try {
if (start) {
started = true;
await addCameraMicWarmedUp();
} else if (description) {
await pc.setRemoteDescription(description);
// オファーを受け取ったら、アンサーで応答する
if (description.type == 'offer') {
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
}
} else {
await pc.addIceCandidate(candidate);
}
} catch (err) {
console.error(err);
}
};
クライアントがサーバーへ複数の RTP エンコーディング(シミュルキャスト)を送信したい。
const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const constraints = {audio: true, video: true};
const configuration = {'iceServers': [{'urls': 'stun:stun.example.org'}]};
let pc;
// start() を呼んで開始する
async function start() {
pc = new RTCPeerConnection(configuration);
// 「negotiationneeded」イベントでオファー生成を開始する
pc.onnegotiationneeded = async () => {
try {
await pc.setLocalDescription();
// オファーを相手ピアへ送る
signaling.send({description: pc.localDescription});
} catch (err) {
console.error(err);
}
};
try {
// ローカルストリームを取得し、自分のビューに表示して送信に追加する
const stream = await navigator.mediaDevices.getUserMedia(constraints);
selfView.srcObject = stream;
pc.addTransceiver(stream.getAudioTracks()[0], {direction: 'sendonly'});
pc.addTransceiver(stream.getVideoTracks()[0], {
direction: 'sendonly',
sendEncodings: [
{rid: 'q', scaleResolutionDownBy: 4.0}
{rid: 'h', scaleResolutionDownBy: 2.0},
{rid: 'f'},
]
});
} catch (err) {
console.error(err);
}
}
signaling.onmessage = async ({data: {description, candidate}}) => {
try {
if (description) {
await pc.setRemoteDescription(description);
// オファーを受け取ったら、アンサーで応答する必要がある
if (description.type == 'offer') {
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
}
} else if (candidate) {
await pc.addIceCandidate(candidate);
}
} catch (err) {
console.error(err);
}
};
この例は、RTCDataChannel
オブジェクトを作成し、チャネルを相手ピアへ接続するために必要なオファー/アンサー交換を実行する方法を示します。RTCDataChannel は、input
フィールドを使ったシンプルなチャットアプリケーションの文脈で使用されます。
const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
let pc, channel;
// start() を呼んで開始する
function start() {
pc = new RTCPeerConnection(configuration);
// ICE candidate を相手ピアへ送る
pc.onicecandidate = ({candidate}) => signaling.send({candidate});
// 「negotiationneeded」イベントでオファー生成を開始する
pc.onnegotiationneeded = async () => {
try {
await pc.setLocalDescription();
// オファーを相手ピアへ送る
signaling.send({description: pc.localDescription});
} catch (err) {
console.error(err);
}
};
// データチャネルを作成し、「negotiated」パターンでチャットをセットアップする
channel = pc.createDataChannel('chat', {negotiated: true, id: 0});
channel.onopen = () => input.disabled = false;
channel.onmessage = ({data}) => showChatMessage(data);
input.onkeydown = ({key}) => {
if (key != 'Enter') return;
channel.send(input.value);
}
}
signaling.onmessage = async ({data: {description, candidate}}) => {
if (!pc) start();
try {
if (description) {
await pc.setRemoteDescription(description);
// オファーを受け取ったら、アンサーで応答する必要がある
if (description.type == 'offer') {
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
}
} else if (candidate) {
await pc.addIceCandidate(candidate);
}
} catch (err) {
console.error(err);
}
};
これは 2 つのブラウザー間で想定されるコールフローの一例を示します。ローカルメディアへのアクセス手順や、発火するすべてのコールバックを示すものではなく、主要なイベントとメッセージのみに絞って示します。
以下の例では、sender は RTCRtpSender であると仮定します。
各トーン 500 ms の継続時間で DTMF 信号「1234」を送信する:
if (sender.dtmf.canInsertDTMF) {
const duration = 500;
sender.dtmf.insertDTMF('1234', duration);
} else {
console.log('DTMF function not available');
}
DTMF 信号「123」を送信し、「2」送信後に中止する。
async function sendDTMF() {
if (sender.dtmf.canInsertDTMF) {
sender.dtmf.insertDTMF('123');
await new Promise(r => sender.dtmf.ontonechange = e => e.tone == '2' && r());
// 「2」以降のトーンを再生しないようにバッファを空にする
sender.dtmf.insertDTMF('');
} else {
console.log('DTMF function not available');
}
}
DTMF 信号「1234」を送信し、トーンの再生中に lightKey(key) で押下中のキーを点灯する(lightKey("") が全キーの消灯だと仮定):
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
if (sender.dtmf.canInsertDTMF) {
const duration = 500; // ms
sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '1234', duration);
sender.dtmf.ontonechange = async ({tone}) => {
if (!tone) return;
lightKey(tone); // 再生開始時にキーを点灯
await wait(duration);
lightKey(''); // トーン継続時間後に消灯
};
} else {
console.log('DTMF function not available');
}
トーンバッファへの追加は常に安全です。この例では、再生開始前と再生中の両方で追加しています。
if (sender.dtmf.canInsertDTMF) {
sender.dtmf.insertDTMF('123');
// 再生開始前に、さらにトーンをトーンバッファに追加する
sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '456');
sender.dtmf.ontonechange = ({tone}) => {
// 再生開始後に、さらにトーンを追加する
if (tone != '1') return;
sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '789');
};
} else {
console.log('DTMF function not available');
}
1 秒の「1」のトーンに続けて 2 秒の「2」のトーンを送信する:
if (sender.dtmf.canInsertDTMF) {
sender.dtmf.ontonechange = ({tone}) => {
if (tone == '1') {
sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '2', 2000);
}
};
sender.dtmf.insertDTMF(sender.dtmf.toneBuffer + '1', 1000);
} else {
console.log('DTMF function not available');
}
パーフェクトネゴシエーションは、ネゴシエーションを自動的に管理し、この非対称なタスクをアプリケーション本体から切り離すために推奨されるパターンです。このパターンは、常に片側がオファーを出す方式よりも利点があり、両方のピア接続オブジェクトを同時に操作しても、(「stable」状態の外からオファーが来る)グレアの危険を避けられます。アプリケーションの残りの部分は、シグナリング状態の競合を気にせず、あらゆる変更メソッドや属性を使用できます。
これは 2 つのピアに異なる役割を割り当て、シグナリングの衝突を解決する振る舞いを定義します:
丁寧なピア(polite peer)は、着信したオファーとの衝突を避けるためにロールバックを使用する。
不作法なピア(impolite peer)は、自身のオファーと衝突する場合、着信したオファーを無視する。
これらを組み合わせることで、アプリケーションの残りの部分に対してデッドロックしない方法でシグナリングを管理します。以下の例では、指定された役割を示す真偽値 polite を仮定します:
const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);
// 任意のタイミングで start() を呼び、接続にカメラとマイクを追加する
async function start() {
try {
const stream = await navigator.mediaDevices.getUserMedia(constraints);
for (const track of stream.getTracks()) {
pc.addTrack(track, stream);
}
selfView.srcObject = stream;
} catch (err) {
console.error(err);
}
}
pc.ontrack = ({track, streams}) => {
// リモートトラックのメディアが到着したら、リモート側の video 要素に表示する
track.onunmute = () => {
// 既に設定済みなら srcObject を再設定しない。
if (remoteView.srcObject) return;
remoteView.srcObject = streams[0];
};
};
// - アプリケーション本体と分離されたパーフェクトネゴシエーションのロジック ---
// レースやエラーを防ぐため、いくつかのネゴシエーション状態を追跡する
let makingOffer = false;
let ignoreOffer = false;
let isSettingRemoteAnswerPending = false;
// ICE candidate を相手ピアへ送る
pc.onicecandidate = ({candidate}) => signaling.send({candidate});
// 「negotiationneeded」イベントでオファー生成を開始する
pc.onnegotiationneeded = async () => {
try {
makingOffer = true;
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
} catch (err) {
console.error(err);
} finally {
makingOffer = false;
}
};
signaling.onmessage = async ({data: {description, candidate}}) => {
try {
if (description) {
// 我々が SRD(answer) を処理中にオファーが到着する場合がある。
// この場合、オファーが処理される頃には状態は "stable" になっているため、
// いま Operations Chain に連結しても安全。
const readyForOffer =
!makingOffer &&
(pc.signalingState == "stable" || isSettingRemoteAnswerPending);
const offerCollision = description.type == "offer" && !readyForOffer;
ignoreOffer = !polite && offerCollision;
if (ignoreOffer) {
return;
}
isSettingRemoteAnswerPending = description.type == "answer";
await pc.setRemoteDescription(description); // 必要に応じて SRD がロールバックを行う
isSettingRemoteAnswerPending = false;
if (description.type == "offer") {
await pc.setLocalDescription();
signaling.send({description: pc.localDescription});
}
} else if (candidate) {
try {
await pc.addIceCandidate(candidate);
} catch (err) {
if (!ignoreOffer) throw err; // 無視したオファーに属する candidate のエラーは抑制
}
}
} catch (err) {
console.error(err);
}
}
これはタイミングに敏感であり、意図的に引数なしの setLocalDescription
と、(暗黙のロールバック付きの)setRemoteDescription
のバージョンを使用して、他のシグナリングメッセージ処理との競合を避けています。
ignoreOffer 変数が必要なのは、不作法側(impolite)の RTCPeerConnection
オブジェクトは無視されたオファーについて知らされないためです。そのため、そのようなオファーに属する着信 candidate からのエラーを抑制する必要があります。
いくつかの操作は RTCError をスローまたはイベントとして発火する。これは
DOMException
を拡張したもので、WebRTC 固有の追加情報を保持する。
WebIDL[Exposed=Window]
interface RTCError : DOMException {
constructor(RTCErrorInit init, optional DOMString message = "");
readonly attribute RTCErrorDetailType errorDetail;
readonly attribute long? sdpLineNumber;
readonly attribute long? sctpCauseCode;
readonly attribute unsigned long? receivedAlert;
readonly attribute unsigned long? sentAlert;
};
constructor()
次の手順を実行する:
errorDetail の型は RTCErrorDetailType、読み取り専用
発生したエラーの種類に対する WebRTC 固有のエラーコード。
sdpLineNumber の型は long、読み取り専用、nullable
errorDetail
が
"sdp-syntax-error"
の場合、エラーが検出された行番号(最初の行は 1)を表す。
sctpCauseCode の型は long、読み取り専用、nullable
errorDetail が
"sctp-failure"
の場合、失敗した SCTP ネゴシエーションの SCTP 原因コードを表す。
receivedAlert の型は unsigned long、読み取り専用、nullable
errorDetail が
"dtls-failure" で、致命的な
DTLS アラートを受信した場合、受信した DTLS アラートの値を表す。
sentAlert の型は unsigned
long、読み取り専用、nullable
errorDetail が
"dtls-failure" で、致命的な
DTLS アラートを送信した場合、送信した DTLS アラートの値を表す。
RTCError
で定義されるすべての属性は、実装不足のためリスク付きとされている(errorDetail、
sdpLineNumber、sctpCauseCode、receivedAlert および
sentAlert)。これは、
DOMException から継承される属性は含まない。
WebIDLdictionary RTCErrorInit {
required RTCErrorDetailType errorDetail;
long sdpLineNumber;
long sctpCauseCode;
unsigned long receivedAlert;
unsigned long sentAlert;
};
errorDetail、sdpLineNumber、sctpCauseCode、
receivedAlert
および sentAlert
は、RTCErrorInit
のメンバーであり、RTCError の同名の属性と同じ定義を持つ。
WebIDLenum RTCErrorDetailType {
"data-channel-failure",
"dtls-failure",
"fingerprint-failure",
"sctp-failure",
"sdp-syntax-error",
"hardware-encoder-not-available",
"hardware-encoder-error"
};
| 列挙値 | 説明 |
|---|---|
data-channel-failure
|
データチャネルが失敗した。 |
dtls-failure
|
DTLS ネゴシエーションが失敗したか、致命的なエラーで接続が終了した。message
にはエラーの性質に関する情報が含まれる。致命的な DTLS アラートを受信した場合、receivedAlert
属性に受信した DTLS アラートの値が設定される。致命的な DTLS アラートを送信した場合、sentAlert 属性に送信した DTLS
アラートの値が設定される。
|
fingerprint-failure
|
RTCDtlsTransport のリモート証明書が、SDP
で提供されたいずれのフィンガープリントとも一致しなかった。リモートピアが、提供されたフィンガープリントに対してローカル証明書を一致させられない場合、このエラーは生成されない。その代わりにリモートピアから
"bad_certificate"(42)DTLS アラートが受信されることがあり、その結果として
"dtls-failure" となりうる。
|
sctp-failure
|
SCTP ネゴシエーションが失敗したか、致命的なエラーで接続が終了した。sctpCauseCode
属性には SCTP 原因コードが設定される。
|
sdp-syntax-error
|
SDP の構文が不正である。sdpLineNumber
属性には、構文エラーが検出された SDP の行番号が設定される。
|
hardware-encoder-not-available
|
要求された操作に必要なハードウェアエンコーダーのリソースが利用できない。 |
hardware-encoder-error
|
ハードウェアエンコーダーが指定されたパラメーターをサポートしていない。 |
RTCErrorEvent インターフェイスは、
RTCError
がイベントとして発生した場合のために定義されている:
WebIDL[Exposed=Window]
interface RTCErrorEvent : Event {
constructor(DOMString type, RTCErrorEventInit eventInitDict);
[SameObject] readonly attribute RTCError error;
};
constructor()
新しい RTCErrorEvent を構築する。
error の型は RTCError、
読み取り専用
イベントを引き起こしたエラーを記述する RTCError。
WebIDL dictionary RTCErrorEventInit : EventInit {
required RTCError error;
};
error の型は
RTCError
イベントに関連付けられたエラー(存在する場合)を記述する RTCError。
このセクションは規範的ではありません。
以下のイベントは RTCDataChannel オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| open |
Event
|
RTCDataChannel オブジェクトの 基盤となるデータ輸送
が確立(または再確立)された。
|
| message |
MessageEvent
[html]
|
メッセージが正常に受信された。 |
| bufferedamountlow |
Event
|
RTCDataChannel オブジェクトの bufferedAmount
が、その
bufferedAmountLowThreshold
を上回る値から、
当該 bufferedAmountLowThreshold
以下に
減少した。
|
| error |
RTCErrorEvent
|
データチャネルでエラーが発生した。 |
| closing |
Event
|
RTCDataChannel オブジェクトが
「closing」
状態へ遷移した。
|
| close |
Event
|
RTCDataChannel オブジェクトの 基盤となるデータ輸送
がクローズされた。
|
以下のイベントは RTCPeerConnection オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| track |
RTCTrackEvent
|
特定の
RTCRtpReceiver に対して新しい受信メディアが
ネゴシエートされ、そのレシーバーの track
が関連するリモートの MediaStream に追加された。
|
| negotiationneeded |
Event
|
ブラウザーが、セッションのネゴシエーションが必要であること(すなわち createOffer の呼び出しと それに続く setLocalDescription)をアプリケーションに通知しようとするとき。 |
| signalingstatechange |
Event
|
接続の [[SignalingState]]
が変更された。
この状態変化は、
setLocalDescription
または
setRemoteDescription
の呼び出しの結果である。
|
| iceconnectionstatechange |
Event
|
RTCPeerConnection の [[IceConnectionState]] が
変更された。
|
| icegatheringstatechange |
Event
|
RTCPeerConnection の [[IceGatheringState]] が
変更された。
|
| icecandidate |
RTCPeerConnectionIceEvent
|
新しい RTCIceCandidate が
スクリプトで利用可能になった。
|
| connectionstatechange |
Event
|
RTCPeerConnection の connectionState
が変更された。
|
| icecandidateerror |
RTCPeerConnectionIceErrorEvent
|
ICE 候補の収集中に失敗が発生した。 |
| datachannel |
RTCDataChannelEvent
|
相手ピアがチャネルを作成したことに応じて、新しい RTCDataChannel が
スクリプトにディスパッチされる。
|
以下のイベントは RTCDTMFSender オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| tonechange |
RTCDTMFToneChangeEvent
|
RTCDTMFSender
オブジェクトが、
トーンの再生を開始した直後(tone 属性として返される)
か、toneBuffer 内のトーンの再生を
終了した直後(tone 属性が空値として返される)。
|
以下のイベントは RTCIceTransport オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| statechange |
Event
|
RTCIceTransport の状態が変更された。
|
| gatheringstatechange |
Event
|
RTCIceTransport の gathering 状態が
変更された。
|
| selectedcandidatepairchange |
Event
|
RTCIceTransport の選択された候補ペアが
変更された。
|
以下のイベントは RTCDtlsTransport オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| statechange |
Event
|
RTCDtlsTransport の状態が変更された。
|
| error |
RTCErrorEvent
|
RTCDtlsTransport でエラーが発生した
(「dtls-failure」または
「fingerprint-failure」)。
|
以下のイベントは RTCSctpTransport オブジェクトで発火する:
| イベント名 | インターフェイス | 発火条件 |
|---|---|---|
| statechange |
Event
|
RTCSctpTransport の状態が変更された。
|
このセクションは規範的ではありません。
このセクションは規範的ではなく、新たな動作を規定するものではありません。むしろ、仕様の他の部分に既に含まれている情報を要約します。WebRTC で用いられる API とプロトコルの一般的な集合に関する全体的なセキュリティ考慮事項は [RFC8827] に記述されています。
本書は、他のブラウザーを含むブラウザーや他のデバイス間で、リアルタイムかつ直接の通信を設定する能力で Web プラットフォームを拡張します。
これは、異なるブラウザーで動作するアプリケーション間、あるいは同じブラウザーで動作するアプリケーションとブラウザーではない何かとの間で、データやメディアが共有できることを意味します。これは Web モデルで通常、異なるオリジン間のデータ送信に対して存在する障壁を拡張するものです。
WebRTC 仕様は通信のためのユーザープロンプトやブラウザー UI インジケーターを提供しません。ウェブページがメディアへのアクセスを許可された時点で、そのメディアを任意の相手と自由に共有できるものと仮定しています。そのため、WebRTC のデータチャネル経由でのピアツーピアのデータ交換は、ユーザーの明示的な同意や関与なしに行われ得ます。これは、サーバー仲介の交換(例えば WebSockets 経由)がユーザーの関与なしに起こり得るのと同様です。
WebRTC を用いなくても、Web アプリケーションを提供する Web サーバーは、そのアプリケーションが配信される先のパブリック IP アドレスを知ることができます。通信の確立は、ブラウザーのネットワーク環境に関する追加情報を Web アプリケーションへ露出し得ます。この中には、ブラウザーが WebRTC で使用可能な(プライベートである可能性のある)IP アドレスの集合が含まれる場合があります。こうした情報の一部は、通信セッションの確立を可能にするために、相手側に渡す必要があります。
IP アドレスの露出は、位置情報や接続手段を漏えいさせ得ます。これは機微情報となり得ます。ネットワーク環境によっては、フィンガープリンティングの表面積を増やし、ユーザーが容易に消去できない永続的なクロスオリジン状態を作り出すことにもつながります。
接続は常に、通信に提案された IP アドレスを相手側に露出します。アプリケーションは、RTCIceTransportPolicy
辞書で公開される設定を用いて、特定のアドレスを使用しないことを選択したり、参加者間の直接接続ではなくリレー(例えば TURN サーバー)を使用したりすることで、この露出を制限できます。一般的に、TURN
サーバーの IP アドレスは機微情報ではないと想定されます。これらの選択は、たとえばユーザーが相手とのメディア接続を開始することに同意を示したかどうかに基づいて、アプリケーションが行うことができます。
アプリケーション自体への IP アドレスの露出を軽減するには、使用可能な IP アドレスを制限する必要があり、これはエンドポイント間の最も直接的な経路での通信能力に影響します。ブラウザーは、ユーザーが望むセキュリティ姿勢に基づいて、どの IP アドレスをアプリケーションに利用可能とするかを決定するための適切な制御を提供することが推奨されます。どのアドレスを露出するかの選択はローカルポリシーによって管理されます(詳細は [RFC8828] を参照)。
ブラウザーは信頼されたネットワーク環境(ファイアウォール内)で実行されるアクティブなプラットフォームであるため、ブラウザーがローカルネットワーク上の他の要素に与え得る被害を制限すること、そして信頼できない参加者による傍受・改ざん・変更からデータを保護することが重要です。
緩和策には次が含まれます:
これらの対策は、関連する IETF 文書に規定されています。
ネットワークを観測できる攻撃者に対して、通信が行われているという事実を隠すことはできません。したがって、これは公開情報として扱う必要があります。
将来の必要性を見越して、postMessage(message, options)
を用いて、通信証明書を不透明に共有することができます。ユーザーエージェントは、RTCCertificate
オブジェクトへアクセスできるプロセスから、これらのオブジェクトがハンドルする秘密鍵マテリアルを分離(アイソレーション)し、メモリ攻撃の表面積を減らすことが強く推奨されます。
上述のとおり、WebRTC API によって露出される IP アドレスの一覧は、永続的なクロスオリジン状態として利用され得ます。
IP アドレスに加えて、WebRTC API は基盤となるメディアシステムに関する情報を
RTCRtpSender の getCapabilities および
RTCRtpReceiver の getCapabilities
メソッドを通じて公開します。ここには、システムが生成・消費可能なコーデックに関する詳細で順序付けられた情報が含まれます。その情報のサブセットは、多くの場合、
セッションネゴシエーション 中に生成・公開・送信される SDP
セッション記述に含まれます。これらの情報は、ほとんどの場合、時間やオリジンをまたいで永続的であり、特定デバイスのフィンガープリンティングの表面積を増加させます。
DTLS 接続を確立する際、WebRTC API は、アプリケーションが(例えば IndexedDB に)永続化できる証明書を生成できます。これらの証明書はオリジン間で共有されず、当該オリジンの永続ストレージが消去されると同時に消去されます。
setRemoteDescription
は、例外を投げることで不正な形式や無効な SDP に対しては防御しますが、アプリケーションにとって予期しない SDP
に対しては防御しません。リモート記述を設定すると、(画像バッファやネットワークポートを含む)多大なリソースが割り当てられたり、メディアが流れ始めたり(プライバシーや帯域幅への影響を含む)といった事態が発生し得ます。悪意のある
SDP に対して防御しないアプリケーションは、リソース枯渇のリスクや、相手が送信をネゴシエートしない場合に
ontrack
のような特定のイベントが発火しないリスク、意図せず受信メディアを許容してしまうリスクにさらされ得ます。アプリケーションは、悪意のある SDP に対して警戒する必要があります。
このセクションは規範的ではありません。
WebRTC 1.0 仕様は、リアルタイムの音声・映像・データ交換を確立するために必要なプロトコル(IETF で定義)を制御する API を公開します。
TDD/TTY(Telecommunications Device for the Deaf)は、聴覚・発話に障害のある(他の人々を含む)個人が電話回線上で通信できるようにするものです。リアルタイムテキスト(Real-Time Text)は [RFC4103] で定義され、T.140 を RTP にカプセル化して、TDD/TTY デバイスから IP ベースの通信( Public Safety Access Points (PSAP) を含む緊急通信)への移行を可能にします。
リアルタイムテキストは、ほぼリアルタイムでデータを送受信する能力を必要とするため、WebRTC 1.0 のデータチャネル API によって最もよくサポートできます。IETF によって定義されているように、データチャネルプロトコルは SCTP/DTLS/UDP プロトコルスタックを使用し、信頼的・非信頼的の両方のデータチャネルをサポートします。IETF は、SRTP 鍵管理に依存し、非信頼的通信に重点を置いた RTP データチャネルの提案よりも、SCTP/DTLS/UDP を標準化することを選択しました。
IETF が、WebRTC のプロトコル群の一部として RTP データチャネルとは異なるアプローチを選択したため、本書の公開時点では、IETF で定義され米国(FCC)規制で実装されているリアルタイムテキストを WebRTC API が直接サポートする標準化された方法は存在しません。WebRTC ワーキンググループは、この分野における進行中の IETF プロトコルをブラウザー API で直接公開することが妥当かを評価しており、この潜在的なギャップについて関連ユーザーコミュニティからの意見を求めています。
IETF MMUSIC Working Group においては、 WebRTC データチャネル上でリアルタイムテキストを送信できるようにする 作業が進行中です。これにより、SCTP データチャネルプロトコルと RFC 4103 のリアルタイムテキストの間を相互変換するゲートウェイを展開できるようになります。この作業が完了すれば、ゲートウェイ経由かそれ以外かにかかわらず、WebRTC ユーザーエージェント(ブラウザーを含む)にリアルタイムテキストを統一的かつ相互運用的に統合するアプローチが可能になると期待されています。
本書の公開時点では、WebRTC クライアントで効果的な RTT をサポートするゲートウェイは、例えばカスタムの WebRTC データチャネルを通じて開発できます。これは、将来的に IETF のプロトコル(SCTP データチャネルプロトコルや RFC 4103 のリアルタイムテキストなど)によって標準化されたゲートウェイが有効化されるまでの間、十分であると見なされます。これは、関連する W3C グループでの作業と連携して IETF で定義され、国際的に RTT のサポートを効果的かつ一貫して標準化する必要があります。
2021年1月にW3C 勧告として公開されて以来、以下の候補修正案が本ドキュメントに統合されています。
RTCRtpEncodingParameters メンバー
(PR #2985) -
Web Platform Tests への変更: #47663 編集者は、ワーキンググループ議長ならびにチームコンタクトであるHarald Alvestrand、Stefan Håkansson、Erik Lagerway、Dominique Hazaël-Massieuxのご支援に感謝します。本仕様書の多くの文章は、Martin Thomson、Harald Alvestrand、Justin Uberti、Eric Rescorla、Peter Thatcher、Jan-Ivar Bruaroey、Peter Saint-Andreなど多くの方々によって提供されました。Dan Burnettは、本仕様書の開発にあたりVoxeoおよびAspectから受けた多大な支援に謝意を表します。
RTCRtpSender および RTCRtpReceiver オブジェクトは、
当初 W3C ORTC
CG で記述され、本仕様書への利用向けに調整されました。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: