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

5.11. Applying an Answer (アンサーの適用)

5.11. Applying an Answer (アンサーの適用)​

ローカルまたはリモート記述を処理する際の上記の手順に加えて, タイプが "pranswer" または "answer" である記述を処理するときに以下の手順が実行される.

各 "m=" セクションについて, 以下の手順を実行しなければならない (MUST):

  • "m=" セクションが拒否された場合 (すなわちアンサーで port フィールドの値がゼロに設定されている), このセクションのメディアの受信または送信を停止する. 拒否されていない "m=" セクションがこのセクションとバンドルされていない限り, [RFC8839] セクション 4.4.3.1 に記載のとおり関連する ICE コンポーネントを破棄する.

  • リモート DTLS フィンガープリントが変更されたか, "a=tls-id" 属性の値が変更された場合, DTLS 接続を解体する. PeerConnection の状態が "have-remote-pranswer" の場合も含む. DTLS 接続の解体が必要だが, アンサーが ICE 再起動を示さないか, "have-remote-pranswer" の場合に新しい ICE 資格情報がない場合, エラーを生成しなければならない (MUST). tls-id 値またはフィンガープリントの変更なしに ICE 再起動が行われた場合, 新しい ICE チャネル上で同じ DTLS 接続が継続される. JSEP ではオファー側が変更した場合に限りアンサー側が tls-id を変更することが要求されるが, 非 JSEP アンサーはオファーに ICE 再起動が含まれていれば tls-id を変更してよい. したがって, アンサーを受信する前に DTLS データを処理する JSEP 実装は, ClientHello または以前の DTLS 接続からのデータのいずれかを受信する可能性に備えなければならない (MUST).

  • 有効な DTLS 接続が存在しない場合, 指定されたロールとフィンガープリントを用いて, 下位の ICE コンポーネントがアクティブになったら DTLS 接続を開始する準備をする.

  • 当該 "m=" セクションの proto フィールドの値が RTP の使用を示す場合:

    • "m=" セクションが, 対応するオファー内の "m=" セクションに存在しなかった RTCP フィードバック機構を参照している場合, これは協商上の問題を示し, エラーとならなければならない (MUST). ただし, [RFC3264] セクション 7 および [RFC5285] セクション 6 に記載のとおり, アンサーでは新しいメディアフォーマットと新しい RTP ヘッダ拡張値が許可される.

    • "m=" セクションで RTCP mux が有効な場合, RTCP ICE コンポーネントが存在すれば破棄し, [RFC5761] セクション 5.1.3 に従い RTP ICE コンポーネント上での RTCP の mux を開始または継続する. そうでない場合, RTCP ICE コンポーネント経由で RTCP を送信する準備をする. 以前 RTCP mux が有効だったため RTCP ICE コンポーネントが存在しない場合, エラーとならなければならない (MUST).

    • "m=" セクションで Reduced-Size RTCP が有効な場合, [RFC5506] に従い, この "m=" セクションの RTCP 送信を Reduced-Size RTCP を使用するよう構成する.

    • アンサー内の direction 属性が, JSEP 実装がメディアを送信すべきであることを示す場合 (ローカルアンサーでは "sendonly", リモートアンサーでは "recvonly", いずれかのタイプのアンサーでは "sendrecv"), [RFC3264] のセクション 6.1 および 7 で論じられるとおり, 送信するメディアフォーマットを, リモート記述のうちローカルでもサポートされる最も優先度の高いものとして選択し, 下位のトランスポート層が確立され次第そのフォーマットで RTP メディアの送信を開始する. この発信 RTP ストリーム用に SSRC がまだ選ばれていない場合, 一意の乱数を選ぶ. すでにメディアを送信している場合, 新しいコーデックのクロックレートが異ならない限り同じ SSRC を使用すべきである (SHOULD). クロックレートが異なる場合, [RFC7160] セクション 4.1 に従い新しい SSRC を選ばなければならない (MUST).

    • リモート記述のペイロードタイプ対応付けを用いて, 上で選んだ送信メディアフォーマットを含む発信 RTP ストリームのペイロードタイプを決定する. 協商された RTP ヘッダ拡張はすべて, リモート記述の拡張対応付けを用いて発信 RTP ストリームに含めるべきである (SHOULD). MID ヘッダ拡張が協商されていれば, [RFC8843] セクション 15 に示すとおり発信 RTP ストリームに含める. RtpStreamId または RepairedRtpStreamId ヘッダ拡張が協商され rid-id が確立されていれば, [RFC8851] セクション 4 に示すとおりこれらのヘッダ拡張を発信 RTP ストリームに含める.

    • "m=" セクションのタイプが "audio" であり, (1) リモート記述の処理の結果として送信メディアフォーマットに無音抑制が構成され, かつ (2) ローカル記述でもそのフォーマットで無音抑制が有効になっている場合, セクション 5.2.3.2 の指針に従い発信メディアに無音抑制を使用する. これらの条件が満たされない場合, 発信メディアに無音抑制を使用してはならない (MUST NOT).

    • simulcast が協商されている場合, [RFC8853] セクション 5.3.3 に指定されるとおり適切な数のソース RTP ストリーム (Source RTP Streams) を送信する.

    • 上で選んだ送信メディアフォーマットに対応する "rtx" メディアフォーマットがあるか FEC 機構が協商されている場合, 各ソース RTP ストリームについて一意の乱数 SSRC を持つ冗長 RTP ストリーム (redundancy RTP stream) を確立し, 必要に応じて RTX/FEC パケットの送信を開始または継続する.

    • 上で選んだ送信メディアフォーマットに同一クロックレートの対応する "red" メディアフォーマットがある場合, [RFC8854] セクション 3.2 で論じられるとおり回復力のために指定フォーマットによる冗長エンコーディングを許可する. RTX または FEC メディアフォーマットとは異なり, "red" フォーマットは冗長 RTP ストリームではなくソース RTP ストリーム上で送信されることに注意する.

    • 指定されたメディアフォーマットを用いるすべてのソース RTP ストリームについて, メディアセクションで参照される RTCP フィードバック機構を有効にする. 具体的には, [RFC4585] セクション 4.2 に従い, 要求されたフィードバックタイプの送信と受信フィードバックへの反応を開始または継続する. RTCP フィードバックを送信する際は, どの SSRC を使用するか選ぶために [RFC8108] セクション 5.4.1 の規則と推奨に従う.

    • アンサー内の direction 属性が, JSEP 実装がメディアを送信すべきでないことを示す場合 (ローカルアンサーでは "recvonly", リモートアンサーでは "sendonly", いずれかのタイプのアンサーでは "inactive"), すべての RTP メディアの送信を停止するが, [RFC3264] セクション 5.1 に記載のとおり RTCP の送信は継続する.

  • 当該 "m=" セクションの proto フィールドの値が SCTP の使用を示す場合:

    • SCTP 関連が存在しリモート SCTP ポートが変更された場合, 既存の SCTP 関連を破棄する. PeerConnection の状態が "have-remote-pranswer" の場合も含む.

    • 有効な SCTP 関連が存在しない場合, [RFC8841] セクション 10.2 に記載のとおり, 関連する ICE コンポーネントと DTLS 接続上で SCTP 関連を開始する準備をする. ローカル記述のローカル SCTP ポート値とリモート記述のリモート SCTP ポート値を使用する.

アンサーに有効なバンドルグループが含まれる場合, 各バンドル内のプライマリ ICE コンポーネントにバンドルされる "m=" セクションの ICE コンポーネントを破棄し, [RFC8843] セクション 7.4 に記載のとおりこれらの "m=" セクションの mux を開始する.

記述のタイプが "answer" で ICE 候補プールにまだ候補が残っている場合, それらを破棄する.

に最終更新