RTCPeerConnection: signalingState 属性

Baseline 已广泛支持

此功能已成熟,可跨多种设备和浏览器版本使用。自 2017 年 9 月以来,它已在浏览器中提供。

RTCPeerConnection 接口的只读属性 signalingState 返回一个字符串值,该值描述了连接或重新连接到另一个对等端时,连接本地端的信令过程的状态。请参阅我们 WebRTC 会话生命周期页面上的 信令

由于信令过程是一个状态机,因此能够验证您的代码在消息到达时处于预期状态有助于避免意外和可避免的故障。例如,如果您在 signalingState 不是 "have-local-offer" 时收到应答,您就知道有问题,因为您应该只在创建 offer 之后、但在应答被接收并传递到 RTCPeerConnection.setLocalDescription() 之前收到应答。如果您注意并优雅地处理这种不匹配的状态,您的代码将更可靠。

此值在调试过程中也可能很有用,例如。

此外,当此属性的值发生更改时,会向 RTCPeerConnection 实例发送一个 signalingstatechange 事件。

允许的字符串值是

stable

目前没有正在进行的 offer 和 answer 交换。这可能意味着 RTCPeerConnection 对象是新的,在这种情况下,localDescriptionremoteDescription 都为 null;这也可能意味着协商已完成,并且连接已建立。

have-local-offer

本地对等端已调用 RTCPeerConnection.setLocalDescription(),传递了代表 offer 的 SDP(通常通过调用 RTCPeerConnection.createOffer() 创建),并且 offer 已成功应用。

have-remote-offer

远程对等端已创建 offer,并使用信令服务器将其传递给本地对等端,本地对等端已通过调用 RTCPeerConnection.setRemoteDescription() 将该 offer 设置为远程描述。

have-local-pranswer

远程对等端发送的 offer 已被应用,并且已经通过调用 RTCPeerConnection.setLocalDescription() 创建(通常通过调用 RTCPeerConnection.createAnswer())并应用了一个应答。这个临时应答描述了支持的媒体格式等,但可能不包含完整的 ICE 候选集。后续的候选将稍后单独传递。

have-remote-pranswer

已收到一个临时应答,并成功应用到先前通过调用 setLocalDescription() 发送并建立的 offer 上。

closed

RTCPeerConnection 已关闭。

示例

js
const pc = new RTCPeerConnection(configuration);
const state = pc.signalingState;

规范

规范
WebRTC:浏览器中的实时通信
# dom-peerconnection-signaling-state

浏览器兼容性

另见