5.2.1. Initial Offers (初期オファー)

5.2.1. Initial Offers (初期オファー)

createOffer が初めて呼び出されたとき, その結果は初期オファーとして知られています。

初期オファーを生成する最初のステップは, [RFC4566] のセクション 5 で指定されているように, セッションレベルの属性を生成することです。具体的には:

• 最初の SDP 行は, [RFC4566] のセクション 5.1 で定義されているように "v=0" でなければなりません。

• 2番目の SDP 行は, [RFC4566] のセクション 5.2 で定義されているように "o=" 行でなければなりません。<username> フィールドの値は "-" であるべきです。<sess-id> は 64 ビット符号付き整数で表現可能でなければならず, 値は 2^(63)-1 未満でなければなりません。<sess-id> は, 最上位ビットをゼロに設定し, 残りの 63 ビットを暗号的にランダムにした 64 ビット量を生成することで構築することが推奨されます。<nettype> <addrtype> <unicast-address> タプルの値は, このフィールドでローカル IP アドレスが漏洩するのを防ぐため, IN IP4 0.0.0.0 などの無意味なアドレスに設定されるべきです; この問題は [RFC8828] で議論されています。[RFC4566] で述べられているように, "o=" 行全体は一意である必要がありますが, <sess-id> に乱数を選択すれば十分です。

• 3番目の SDP 行は, [RFC4566] のセクション 5.3 で定義されているように "s=" 行でなければなりません; "o=" 行に合わせて, セッション名として単一のダッシュを使用すべきです, 例えば "s=-"。これは [RFC4566] のアドバイスとは異なることに注意してください, 後者は単一のスペースを提案していますが, "o=" と "s=" の両方が JSEP では無意味であるため, 同じ無意味な値を持つ方が明確に思えます。

• セッション情報 ("i="), URI ("u="), 電子メールアドレス ("e="), 電話番号 ("p="), 繰り返し時間 ("r="), およびタイムゾーン ("z=") 行は, この文脈では有用ではなく, 含めるべきではありません。

• 暗号化キー ("k=") 行は十分なセキュリティを提供せず, 含めてはなりません。

• [RFC4566] のセクション 5.9 で指定されているように, "t=" 行を追加しなければなりません; <start-time> と <stop-time> の両方をゼロに設定すべきです, 例えば "t=0 0"。

• [RFC8840] のセクション 4.1.1 と [RFC8445] のセクション 10 で指定されているように, "trickle" と "ice2" オプションを持つ "a=ice-options" 行を追加しなければなりません。

• WebRTC アイデンティティが使用されている場合, [RFC8827] のセクション 5 で説明されているように, "a=identity" 行を追加しなければなりません。

次のステップは, [RFC4566] のセクション 5.14 で指定されているように, "m=" セクションを生成することです。PeerConnection に追加された各 RtpTransceiver に対して "m=" セクションが生成されます, 停止した RtpTransceiver を除きます; これは RtpTransceiver が PeerConnection に追加された順序で行われます。

各 "m=" セクションは, バンドル専用とマークされていない限り, 一意の ICE 認証情報セットと一意の ICE 候補セットを含まなければなりません。バンドル専用の "m=" セクションは, いかなる ICE 認証情報も含んではならず, いかなる候補も収集してはなりません。

DTLS については, すべての "m=" セクションは PeerConnection に指定されたすべての証明書を使用しなければなりません; その結果, それらはすべて同じフィンガープリント値または複数の値 [RFC8122] を持つ必要があります, またはこれらの値はセッションレベルの属性でなければなりません。