5.3.1. Initial Answers (初期Answer)

リモート記述が提供された後で初めて createAnswer が呼び出されたとき, その結果を初期アンサーと呼びます。リモート記述がインストールされていない場合, アンサーは生成できず, エラーを返さなければなりません (MUST)。

リモート記述の SDP は JSEP エンドポイントによって作成されていない可能性があり, 第 5.2 節に列挙されたすべての要件に適合しない場合があります。多くの場合これは問題になりません。ただし, 必須の SDP 属性が欠落している, または上で必須使用とされた機能が存在しない場合は, これをエラーとして扱わなければならず (MUST), 影響を受ける "m=" セクションを拒否としてマークしなければなりません (MUST)。

初期アンサーを生成する最初の手順は, セッションレベル属性を生成することです。ここでの手順は上記の第 5.2.1 節で示したものと同一ですが, [RFC8840] の第 4.1.3 節で指定される "trickle" オプションおよび [RFC8445] の第 10 節で指定される "ice2" オプションを含む "a=ice-options" 行は, オファーにそのようなオプションが存在する場合にのみ含めます。

次の手順は, [RFC5888] の第 7 節で定義されるセッションレベルのリップシンク (LS) グループを生成することです。オファーに存在するタイプ "LS" の各グループについて, 指定されたグループ内の MID 値によって参照されるローカル RtpTransceiver を選び, それらのうち作成時の addTrack/addTransceiver 呼び出しで指定された共通のローカル MediaStream を参照するもの, または addTrack/addTransceiver によって作成されていないため参照する MediaStream がないものを判定します。このような RtpTransceiver が少なくとも 2 つ存在する場合, これらの RtpTransceiver の MID 値を持つタイプ "LS" のグループを追加しなければなりません (MUST)。そうでなければ, 提示された "LS" グループは無視し, アンサーに対応するグループを生成してはなりません (MUST)。

単純な例として, 同一 MediaStream 内に単一の音声トラックと単一のビデオトラックを含む次のオファーを考えます。本例に関係のない SDP 行は明瞭さのため省略しています。第 5.2 節で説明したとおり, 各トラックの RtpTransceiver を参照するタイプ "LS" のグループが追加されています。

        a=group:LS a1 v1
        m=audio 10000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms1
        m=video 10001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms1

アンサー側がトラック追加時に単一の MediaStream を使う場合, 両方のトランシーバがそのストリームを参照するため, 後続のアンサーにはオファーと同一の "LS" グループが含まれます。次のとおりです。

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2

一方, アンサー側がトラックを別々の MediaStream に分ける場合, トランシーバは異なるストリームを参照するため, 後続のアンサーには "LS" グループは含まれません。

        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=msid:ms2a
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=msid:ms2b

最後に, アンサー側がトラックを追加しない場合, トランシーバはいずれの MediaStream も参照せず, オファー側の設定が維持されるため, 後続のアンサーには同一の "LS" グループが含まれます。

        a=group:LS a1 v1
        m=audio 20000 UDP/TLS/RTP/SAVPF 0
        a=mid:a1
        a=recvonly
        m=video 20001 UDP/TLS/RTP/SAVPF 96
        a=mid:v1
        a=recvonly

第 7.2 節の例は, "LS" グループ生成のより複雑なケースを示しています。

次の手順は, リモートオファーに存在する各 "m=" セクションについて "m=" セクションを生成することです。[RFC3264] の第 6 節に指定のとおりです。本議論の目的では, オファー内のメディアレベル属性としても有効なセッションレベル属性は, 各 "m=" セクションに存在するとみなします。提示された各 "m=" セクションには, 第 5.10 節で説明するように関連する RtpTransceiver があります。RtpTransceiver の数が "m=" セクションの数より多い場合, 一致しなかった RtpTransceiver は後続のオファーで関連付ける必要があります。

提示された各 "m=" セクションについて, 次のいずれかが真であれば, アンサー内の対応する "m=" セクションは, "m=" 行の <port> をゼロに設定して拒否としてマークしなければなりません (MUST)。[RFC3264] の第 6 節に示すとおりです。この "m=" セクションに対する以降の処理は省略できます。

関連する RtpTransceiver が停止している。
サポートされており, 該当する場合はコーデック設定によって許可されている, 提示されたメディア形式が存在しない。
バンドルポリシーが "max-bundle" であり, かつこれが最初の "m=" セクションでない, または最初の "m=" セクションと同一のバンドルグループにない。
バンドルポリシーが "balanced" であり, かつこれが当該メディアタイプの最初の "m=" セクションでない, または当該メディアタイプの最初の "m=" セクションと同一のバンドルグループにない。
当該 "m=" セクションがバンドルグループ内にあり, かつグループのオファー側タグ付き "m=" セクションが上記いずれかの理由で拒否されている。バンドルグループ内のすべての "m=" セクションを拒否する必要があります。[RFC8843] の第 7.3.3 節に指定のとおりです。

そうでなければ, アンサー内の各 "m=" セクションは [RFC3264] の第 6.1 節に指定のとおり生成しなければなりません (MUST)。"m=" 行自体については, 次の規則に従わなければなりません (MUST)。

<port> は通常この "m=" セクションのデフォルト ICE 候補のポートに設定されますが, まだ候補がないため, デフォルトの <port> 値 9 (Discard) を使わなければなりません (MUST)。[RFC8840] の第 4.1.1 節に示すとおりです。
<proto> フィールドは, オファー内の対応する "m=" 行の <proto> フィールドと正確に一致させなければなりません (MUST)。
関連トランシーバにコーデック設定がされている場合, 提示内容に関わらず対応する順序でメディア形式を生成しなければならず (MUST), 設定にないコーデックは除外しなければなりません (MUST)。
そうでない場合, "m=" 行上のメディア形式は, 現在サポートされていない形式を除き, 現在のリモート記述で提示された順序と同じ順序で生成しなければなりません (MUST)。現在のリモート記述に存在しない利用可能なメディア形式は, 既存の形式のすべての後に追加しなければなりません (MUST)。
いずれの場合も, アンサーのメディア形式にはオファーに存在する形式を少なくとも 1 つ含めなければなりませんが (MUST), ローカルでサポートされているがオファーにない形式を含めてもよいです (MAY)。[RFC3264] の第 6.1 節に言及があります。共通形式が存在しない場合, 上記のとおり "m=" セクションは拒否されます。

"m=" 行の直後に "c=" 行を続けなければなりません (MUST)。[RFC4566] の第 5.7 節に指定のとおりです。ここでも候補がまだないため, "c=" 行にはデフォルト値 "IN IP4 0.0.0.0" を含めなければなりません (MUST)。[RFC8840] の第 4.1.3 節で定義されます。

オファーがバンドルをサポートする場合, バンドルされるすべての "m=" セクションは同一の ICE クレデンシャルと候補を使わなければなりません (MUST)。バンドルされないすべての "m=" セクションは, 一意の ICE クレデンシャルと候補を使わなければなりません (MUST)。各 "m=" セクションには, 次の属性を含めなければなりません (IDENTICAL でも TRANSPORT でもない属性タイプです)。

オファーに存在する場合に限り, "a=mid" 行。[RFC5888] の第 9.1 節に指定のとおりです。MID 値はオファーで指定されたものと一致しなければなりません (MUST)。
方向属性。[RFC3264] の第 6.1 節で指定される提示方向に関する規則を適用し, 続いて関連 RtpTransceiver の方向と交差させて決定します。例えば, "m=" セクションが "sendonly" で提示され, ローカルトランシーバが "sendrecv" に設定されている場合, アンサーでは "recvonly" 方向になります。
"m=" 行上の各メディア形式について, "a=rtpmap" 行および "a=fmtp" 行。[RFC4566] の第 6 節および [RFC3264] の第 6.1 節に指定のとおりです。
オファーに "rtx" がある場合, RTP 再送を用いる各プライマリコーデックについて, プライマリコーデックのクロックレートで "rtx" を示す対応する "a=rtpmap" 行, およびプライマリコーデックのペイロードタイプを参照する "a=fmtp" 行。[RFC4588] の第 8.1 節に指定のとおりです。
サポートする各 FEC メカニズムについて, "a=rtpmap" 行および "a=fmtp" 行。[RFC4566] の第 6 節に指定のとおりです。サポートしなければならない FEC メカニズムは [RFC8854] の第 7 節で指定され, メディアタイプごとの具体的な用法は第 4 節および第 5 節に概説があります。
当該 "m=" セクションがパケットあたりのメディア持続時間を設定可能なメディア (例: 音声) 向けの場合, 第 5.2 節で説明する "a=maxptime" 行。
当該 "m=" セクションがビデオメディア向けで, デコード可能な画像サイズに既知の制限がある場合, 第 3.6 節で指定のとおり "a=imageattr" 行。
オファーに存在するサポートする各 RTP ヘッダ拡張について, "a=extmap" 行。[RFC5285] の第 5 節に指定のとおりです。サポートすべき/しなければならないヘッダ拡張の一覧は [RFC8834] の第 5.2 節で指定されます。暗号化を要するヘッダ拡張は [RFC6904] の第 4 節に示すとおり指定しなければなりません (MUST)。
オファーに存在するサポートする各 RTCP フィードバックメカニズムについて, "a=rtcp-fb" 行。[RFC4585] の第 4.2 節に指定のとおりです。サポートすべき/しなければならない RTCP フィードバックメカニズムの一覧は [RFC8834] の第 5.1 節で指定されます。
RtpTransceiver の方向が sendrecv または sendonly の場合:
- addTrack または addTransceiver による作成時にトランシーバに関連付けられた各 MediaStream について, "appdata" フィールドを省略した "a=msid" 行。[RFC8830] の第 2 節に指定のとおりです。

別の "m=" セクションにバンドルされていない各 "m=" セクションには, 次の属性を含めなければなりません (カテゴリ IDENTICAL または TRANSPORT です)。

"a=ice-ufrag" 行および "a=ice-pwd" 行。[RFC8839] の第 5.4 節に指定のとおりです。
望む各ダイジェストアルゴリズムについて, エンドポイントの各証明書に対する 1 本以上の "a=fingerprint" 行。[RFC8122] の第 5 節に指定のとおりです。
"a=setup" 行。[RFC4145] の第 4 節に指定され, DTLS-SRTP シナリオでの利用は [RFC5763] の第 5 節で明確化されています。アンサー内のロール値は "active" または "passive" でなければなりません (MUST)。オファーに "actpass" 値が含まれる場合 (JSEP エンドポイントでは常にそうです), アンサー側は "active" ロールを使うべきです (SHOULD)。非 JSEP エンドポイントからのオファーは "a=setup" に他の値を送ってもよく (MAY), その場合アンサーはオファー内の値と整合する値を使わなければなりません (MUST)。
"a=tls-id" 行。[RFC8842] の第 5.3 節に指定のとおりです。
オファーに存在する場合, "a=rtcp-mux" 行。[RFC5761] の第 5.1.3 節に指定のとおりです。存在しない場合は, "a=rtcp" 行。[RFC3605] の第 2.1 節に指定のとおり, デフォルト値 "9 IN IP4 0.0.0.0" を含めます (候補はまだ収集されていないため)。
オファーに存在する場合, "a=rtcp-rsize" 行。[RFC5506] の第 5 節に指定のとおりです。

データチャネルの "m=" セクションが提示されている場合, データ用の "m=" セクションも生成しなければなりません (MUST)。<media> フィールドは "application" に設定しなければなりません (MUST)。<proto> および <fmt> フィールドはオファー内のフィールドと正確に一致させなければなりません (MUST)。

データ "m=" セクション内では, 上記のとおり "a=mid" 行を生成して含めなければなりません (MUST)。さらに [RFC8841] の第 5.1 節で定義される SCTP ポート番号を参照する "a=sctp-port" 行, および適切な場合 [RFC8841] の第 6.1 節で定義される "a=max-message-size" 行を含めます。

上で述べたとおり, 次の IDENTICAL または TRANSPORT カテゴリの属性は, データ "m=" セクションが別の "m=" セクションにバンドルされていない場合にのみ含めます。

"a=ice-ufrag"
"a=ice-pwd"
"a=fingerprint"
"a=setup"
"a=tls-id"

メディア "m=" セクションがデータ "m=" セクションにバンドルされている場合, 本来メディア "m=" セクションにのみ適切な特定の TRANSPORT および IDENTICAL 属性 (例: "a=rtcp-mux") が, データ "m=" セクションにも現れてよいことに注意してください。

意味が "BUNDLE" の "a=group" 属性が提示されている場合, [RFC5888] に指定のとおり対応するセッションレベルの "a=group" 属性を追加しなければなりません (MUST)。これらの属性の意味は "BUNDLE" でなければならず (MUST), 拒否されていない提示バンドルグループからのすべての mid 識別子を含めなければなりません (MUST)。オファーに "a=bundle-only" があってもなくても, アンサー内のすべての "m=" セクションに "a=bundle-only" 行を含んではなりません (MUST NOT)。

すべての "m=" セクション間で共通の属性は, セッションレベルで有効と明示的に定義されている場合, セッションレベルに移してもよいです (MAY)。

オファー作成で禁止されている属性は, アンサー作成でも禁止されます。

5.3.1. Initial Answers (初期Answer)​

5.3.1. Initial Answers (初期Answer)