RTCPeerConnection：createOffer() 方法

options 可选

一个对象，提供 offer 所需的以下选项

iceRestart 可选

要在活动连接上重新启动 ICE，请将其设置为 true。这将导致返回的 offer 具有与已有的不同的凭据。如果随后应用返回的 offer，ICE 将重新启动。指定 false 以保留相同的凭据，从而不重新启动 ICE。默认值为 false。

offerToReceiveAudio 可选 已弃用

提供对音频方向性的额外控制。例如，它可以用于确保可以接收音频，而不管是否发送音频。

offerToReceiveVideo 可选 已弃用

提供对视频方向性的额外控制。例如，它可以用于确保可以接收视频，而不管是否发送视频。

在旧代码和文档中，您可能会看到此函数的基于回调的版本。此版本已弃用，强烈建议不要使用。您应该更新任何现有代码，以改为使用基于 Promise 的 createOffer() 版本。下面描述了旧版 createOffer() 的参数，以帮助更新现有代码。

successCallback 已弃用

一个 回调函数，它将被传递一个描述新创建的 offer 的 RTCSessionDescription 对象。

errorCallback 已弃用

一个 回调函数，它将被传递一个解释创建 offer 请求失败原因的 DOMException 对象。

options 可选

一个可选对象，提供 offer 所需的选项。

一个 Promise，其 fulfilled 处理程序将接收一个符合 RTCSessionDescriptionInit 字典的对象，该字典包含描述生成的 offer 的 SDP。接收到的 offer 应通过信令服务器传递给远程对等方。

这些异常通过拒绝返回的 promise 来返回。您的拒绝处理程序应该检查接收到的异常以确定发生了哪种异常。

InvalidStateError DOMException

如果 RTCPeerConnection 已关闭，则返回此异常。

NotReadableError DOMException

如果未提供任何证书或证书集来保护连接，并且 createOffer() 无法创建新的证书，则返回此异常。由于所有 WebRTC 连接都需要受到保护，因此会导致错误。

OperationError DOMException

如果出于某种原因检查系统状态以确定资源可用性以生成 offer 失败，则返回此异常。

这里我们看到一个处理 negotiationneeded 事件的处理程序，该处理程序创建 offer 并将其通过信令通道发送到远程系统。

myPeerConnection
  .createOffer()
  .then((offer) => myPeerConnection.setLocalDescription(offer))
  .then(() => {
    sendToServer({
      name: myUsername,
      target: targetUsername,
      type: "video-offer",
      sdp: myPeerConnection.localDescription,
    });
  })
  .catch((reason) => {
    // An error occurred, so handle the failure to connect
  });

在此代码中，创建 offer，一旦成功，本地 RTCPeerConnection 端会通过将 offer（使用符合 RTCSessionDescriptionInit 的对象表示）传递给 setLocalDescription() 来配置以匹配。完成后，offer 将通过信令通道发送到远程系统；在本例中，使用名为 sendToServer() 的自定义函数。信令服务器的实现独立于 WebRTC 规范，因此无论如何发送 offer 都没关系，只要调用方和潜在的接收方都使用相同的服务器即可。

使用 Promise.catch() 来捕获和处理错误。

请参阅 信令和视频通话 以获取此代码段派生的完整示例；这将帮助您了解此处信令代码的工作原理。