メインコンテンツまでスキップ

3. Procedures (手順)

本セクションは, [W3C-WebRTC] で定義されるとおり, MediaStream 内の MediaStreamTrack を表すメディア記述を関連付ける手順を述べる.

その仕様で記述される Javascript API では, 各 MediaStream と MediaStreamTrack は id 属性を持ち, 型は DOMString である.

MSID の msid-id フィールドの値は, MediaStream の WebIDL 仕様 [WEBIDL] で定義される MediaStream の id 属性からなる. 特殊値 - は「MediaStream なし」を示す.

MSID の msid-appdata フィールドが存在する場合, その値は MediaStreamTrack の WebIDL 仕様で定義される MediaStreamTrack の id 属性からなる.

SDP セッション記述が更新されると, 特定の msid-id 値は同じ MediaStream を指し続け, 特定の msid-appdata は同じ MediaStreamTrack を指す. 現在有効な SDP 記述以外に記憶はない. MSID の「識別子」値が SDP から消え, 後のネゴシエーションで再現れた場合, 新しい MediaStream を指すものとみなされる.

msid 属性がここで与えた ABNF に適合しない場合, それは無視すべきである (SHOULD).

以下は SDP 更新を扱う規則の高レベルな説明である. 詳細な手順はセクション 3.2 にある.

  • セッション記述に新しい MSID「識別子」値が現れ, それが - でない場合, 受信者はアプリケーションに新しい MediaStream が追加されたことを通知できる.

  • セッション記述が更新され, ある MSID「識別子」値を持つメディア記述に, 1 つ以上の異なる appdata 値がある場合, 受信者はアプリケーションに新しい MediaStreamTrack が追加されたこと, およびどの MediaStream に追加されたかを通知できる. これは対応する MediaStream がない MediaStreamTrack が追加されたことを示す特殊値 - を含め, 異なる MSID「識別子」値ごとに行う.

  • appdata 値のない MSID「識別子」値が現れた場合, 送信者は受信者に MediaStreamTrack の希望識別子を伝えなかったことを意味し, 受信者は作成した MediaStreamTrack の id 値を自ら割り当てる. appdata 値のないメディアセクション内のすべての MSID は, 同じ MediaStreamTrack を指すとみなされる.

  • セッション記述が更新され, 特定のメディア記述に msid 属性が一切列挙されなくなった場合, 受信者はアプリケーションに対応する MediaStreamTrack が終了したことを通知できる.

SDP から msid 属性が消えたときにトラックが終了したことを通知するほか, 関連するすべての SSRC が [RFC3550] のセクション 6.3.4 (BYE パケット受信) および 6.3.5 (タイムアウト) の規則で消えたとき, またはポート番号をゼロに設定して対応するメディア記述が無効化されたときにも, トラックは終了したと通知される. メディア記述の方向を (sendonly, recvonly, inactive 属性により) 変更しても MediaStreamTrack は終了しない.

SSRC とメディア記述の関連付けは [RFC8829] で規定される.

3.1. Handling of Nonsignaled Tracks (シグナルなしトラックの取り扱い)​

本ドキュメントのメカニズムを用いないエンティティは msid 属性を送らないため, RTP パケットを MediaStream にマッピングする情報を送らない. つまり受信者が事前定義された MediaStream ID 値を持たない着信 RTP パケットが存在する.

以下で述べる取り扱いは SDP ネゴシエーションではなく着信 RTP パケットによって起動されることに注意すること.

MSID メカニズムを用いるエンティティとの通信では, 初期ネゴシエーションの後, 応答者が確立済み接続に MediaStreamTrack を追加し, オファラーがアンサーを受信する前にデータ送信を開始するネゴシエーションが行われた場合に限り, 関連 MediaStream ID 値なしで着信 RTP パケットを受信し得る. 初期ネゴシエーションでは, Interactive Connectivity Establishment (ICE) の候補とフィンガープリントが交換されるまでパケットは流れないため, 問題にならない.

それらのパケットの受信者は次のステップを実行する:

  • RTP パケットを最初に受信したとき, メディアの種類 (PayloadType で運ばれる) に基づいて適切な MediaStreamTrack を作成し, MID RTP ヘッダ拡張 [RFC8843] (存在すれば) を用いて RTP パケットを特定のメディアセクションに関連付ける.

  • 接続が RTCSignalingState stable でない場合, ここで待つ.

  • 接続が RTCSignalingState stable になったら, ID 値を割り当てる.

ID 値の割り当てでは次を行う:

  • msid 属性があれば, 上で述べたとおりその属性を用いて MediaStreamTrack および関連 MediaStreams の id フィールドを設定する.

  • msid 属性がなければ, MediaStreamTrack の識別子はランダムに生成された文字列に設定され, WebIDL の label 属性が Non-WebRTC stream の MediaStream の一部であると通知される.

  • MediaStreamTrack に適用する id フィールドを決めた後, トラックをユーザーに通知する.

上記のプロセスは stable 状態に入るまで相当なバッファリングを伴い得る. 実装がこのバッファリングを制限したい場合, メディアが破棄されたことをユーザーに通知しなければならない (MUST).

上記から, 「デフォルト」MediaStream 内の MediaStreamTrack は msid 属性を削除して閉じることはできない. アプリケーションは代わりに SSRC が消えたとき ([RFC3550] のセクション 6.3.4 および 6.3.5 の規則に従うか, ポートをゼロに設定してメディア記述を無効化して) これらを閉じたと通知しなければならない.

3.2. Detailed Offer/Answer Procedures (Offer/Answer の詳細手順)​

これらの手順は [RFC3264] が推奨するセクションに沿って与えられる. MediaStream と MediaStreamTrack に関して取るべき動作を記述する. アプリケーション内部のイベント通知は含まない. それは JavaScript Session Establishment Protocol (JSEP) [RFC8829] で記述される.

3.2.1. Generating the Initial Offer (初期オファーの生成)​

オファー内の各メディア記述について, 関連する発信 MediaStreamTrack があれば, オファラーはその MediaStreamTrack が関連付けられる各 MediaStream について, そのセクションに 1 つ a=msid 属性を追加する. 属性の identifier フィールドは MediaStream の WebIDL id 属性に設定する. 送信者が MediaStreamTrack の識別子を通知したい場合は appdata フィールドを MediaStreamTrack の WebIDL id 属性に設定し, そうでなければ省略する.

3.2.2. Answerer Processing of the Offer (オファーに対する応答者の処理)​

オファー内の各メディア記述およびそのメディア記述内の各 a=msid 属性について, オファーの受信者は次を実行する:

  • a=msid 属性の appdata フィールドを, 存在すれば抽出する.

  • appdata フィールドが存在する場合: appdata フィールドと同じ WebIDL id 属性を持つ MediaStreamTrack が既に存在し, かつ ended 状態でないか確認する. そのような MediaStreamTrack が見つからなければ, 作成する.

  • appdata フィールドが存在せず, このメディアセクションに MediaStreamTrack が関連付けられていない場合, MediaStreamTrack を作成し, 将来の使用のためにこのメディアセクションに関連付ける.

  • a=msid 属性の identifier フィールドを抽出する.

  • 同じ WebIDL id 属性を持つ MediaStream が既に存在するか確認する. なければ作成する.

  • MediaStreamTrack を MediaStream に追加する.

  • ユーザーに新しい MediaStreamTrack が利用可能であることを通知する.

3.2.3. Generating the Answer (アンサーの生成)​

アンサーはオファーとまったく同じ方法で生成される. オファー内の a=msid 値はアンサーに影響しない.

3.2.4. Offerer Processing of the Answer (アンサーに対するオファラー側の処理)​

アンサーはオファーとまったく同じ方法で処理される.

3.2.5. Modifying the Session (セッションの変更)​

以降の交換では, 初期 offer/answer とまったく同じ手順に従うが, オファーとアンサーの解析に 1 ステップ追加する:

  • 以前の offer/answer 交換の結果として作成され, ended 状態にない各 MediaStreamTrack について, 現在の SDP にまだ appdata フィールドがトラックの WebIDL id 属性と同じ a=msid 属性があるか確認する.

  • そのような属性が見つからなければ, MediaStreamTrack を停止する. これにより状態が ended になる.

3.3. Example SDP Description (SDP 記述の例)​

次の SDP 記述は, それぞれが音声とビデオトラックを 1 つずつ持つ 2 つの MediaStream を持つ WebRTC PeerConnection の表現を示す. MSID に関連する部分のみ示す.

明確化のための折り返し, 空行, コメントが追加されている. これらは SDP の一部ではない.

# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
       f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9

m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
       b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       b94006c5-cade-4e0a-9ed9-d3e6747be7d9

m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       f30bdb4a-1497-49b5-3198-e0c9a23172e0
に最終更新