跳到主要内容

5.2.1. Initial Offers (初始提议)

5.2.1. Initial Offers (初始提议)

当第一次调用 createOffer 时, 其结果称为初始提议。

生成初始提议的第一步是生成会话级属性, 如 [RFC4566] 第 5 节中所指定。具体来说:

  • 第一行 SDP 必须是 "v=0", 如 [RFC4566] 第 5.1 节中定义。

  • 第二行 SDP 必须是 "o=" 行, 如 [RFC4566] 第 5.2 节中定义。<username> 字段的值应该是 "-"。<sess-id> 必须可以用 64 位有符号整数表示, 且值必须小于 2^(63)-1。推荐通过生成一个 64 位数量来构造 <sess-id>, 其中最高位设置为零, 其余 63 位为加密随机数。<nettype> <addrtype> <unicast-address> 元组的值应该设置为无意义的地址, 例如 IN IP4 0.0.0.0, 以防止在此字段中泄露本地 IP 地址; [RFC8828] 中讨论了这个问题。如 [RFC4566] 中所述, 整个 "o=" 行需要是唯一的, 但为 <sess-id> 选择一个随机数就足以实现这一点。

  • 第三行 SDP 必须是 "s=" 行, 如 [RFC4566] 第 5.3 节中定义; 为了与 "o=" 行匹配, 应该使用单个短横线作为会话名称, 例如 "s=-"。请注意, 这与 [RFC4566] 中的建议不同, 后者建议使用单个空格, 但由于 "o=" 和 "s=" 在 JSEP 中都是无意义的, 使用相同的无意义值似乎更清晰。

  • 会话信息 ("i="), URI ("u="), 电子邮件地址 ("e="), 电话号码 ("p="), 重复时间 ("r=") 和时区 ("z=") 行在此上下文中不实用, 不应该包含。

  • 加密密钥 ("k=") 行不提供足够的安全性, 绝对不能包含。

  • 必须添加 "t=" 行, 如 [RFC4566] 第 5.9 节中指定; <start-time> 和 <stop-time> 都应该设置为零, 例如 "t=0 0"。

  • 必须添加带有 "trickle" 和 "ice2" 选项的 "a=ice-options" 行, 如 [RFC8840] 第 4.1.1 节和 [RFC8445] 第 10 节中指定。

  • 如果正在使用 WebRTC 身份, 则必须添加 "a=identity" 行, 如 [RFC8827] 第 5 节中所述。

下一步是生成 "m=" 段, 如 [RFC4566] 第 5.14 节中指定。为已添加到 PeerConnection 的每个 RtpTransceiver 生成一个 "m=" 段, 不包括任何已停止的 RtpTransceiver; 这按照 RtpTransceiver 添加到 PeerConnection 的顺序完成。

每个 "m=" 段, 只要它没有被标记为仅捆绑, 就必须包含一组唯一的 ICE 凭据和一组唯一的 ICE 候选。仅捆绑的 "m=" 段绝对不能包含任何 ICE 凭据, 也绝对不能收集任何候选。

对于 DTLS, 所有 "m=" 段必须使用为 PeerConnection 指定的任何和所有证书; 因此, 它们必须都具有相同的指纹值或多个值 [RFC8122], 或者这些值必须是会话级属性。