在WebRTC中,似乎有一个定义明确的顺序。
在本地我使用getUserMedia
来获取我的本地流,并将流保存到变量。我创建了一个RTCPeerConnection
对象,我将其命名为pc
,然后将本地流添加到其中。我向onaddstream
添加了一个pc
事件处理程序,以便我可以将远程用户的流保存到变量中,并最终将其设置为HTML元素的src
属性,如{{1 }}。我还在audio
上设置onicecandidate
事件处理程序来处理候选冰。
此时,有一个pc
,但没有远程用户“已连接”。这是“提供/回答”开始的地方。假设我正在使用websockets进行信令,并且我收到了一个提议,这是一条名为“offer”并包含SDP对象的消息。我如何拒绝它以及如何在两个端点上处理它?</ p>
例如,我可以发送一条消息“拒绝”,该消息将被转发给其他用户。我的RTCPeerConnection仍然存在,也许我希望能够接收其他电话。按原样,我不需要对我的RTCPeerConnection做任何事情,对吗?发送优惠的其他用户是否必须做任何事情?他必须关闭那个特定的RTCPeerConnection吗?我不这么认为,因为他所做的就是创建一个SDP对象,然后在WebRTC之外,通过websockets将对象发送给另一个用户。他确实使用RTCPeerConnection
添加了优惠。当要约被拒绝时,他是否需要对此做任何事情?
当我创建优惠并将其发送给其他用户时,如果我从未收到回复,我可以向第三位用户发送优惠,然后如果他发送了答案我与他有联系吗? / p>
我还没有找到有关RTCPeerConnection生命周期的任何信息。
答案 0 :(得分:2)
在答案中“拒绝”提供媒体的“正确”方式尚未在任何浏览器中实现:
pc.ontrack = e => e.transceiver.stop();
基本上,WebRTC 1.0规范在此区域中有changed quite significantly。简而言之,收发器是组合一个发送器和一个接收器的对象,每个发送器发送或接收单个磁道。
transceiver.stop()
允许您在发出信号的SDP媒体描述中拒绝单个双向 m-line (协商媒体)。例如。你可以在答案中拒绝部分要约,但不要拒绝整件事。
今天,拒绝个别m-line的唯一方法是手动修改SDP提供/回答。
但听起来像你根本就没有问过这个。相反,听起来你要求如何摆脱不完整的信号并将对等连接恢复到“稳定”状态。
要约/回答谈判周期为state machine。州是pc.signalingState
:
你问过一方是否离开了谈判,是否有任何一方需要做任何事情才能重新使用他们的连接对象进行与同一或不同对等方的新尝试。嗯,这取决于。
如果您只调用createOffer
,则不需要回滚状态,因为createOffer
不在上图中。
如果您已拨打setLocalDescription
,那么您现在处于"have-local-offer"
状态,这意味着 做 需要以某种方式获取在重用连接之前返回"stable"
状态。
您可以选择完成协商,删除连接或 回滚到稳定状态 (目前只有supported中的Firefox,虽然规范中的是:
let pc = new RTCPeerConnection();
pc.onnegotiationneeded = async e => {
try {
await pc.setLocalDescription(await pc.createOffer());
console.log(pc.signalingState); // have-local-offer
await pc.setLocalDescription({type: "rollback"});
console.log(pc.signalingState); // stable
} catch(e) {
console.log(e);
}
}
pc.createDataChannel("dummy");
<script src="https://webrtc.github.io/adapter/adapter-latest.js"></script>
当然,您也应该让对方知道,通常是通过带外信令。
在典型情况下,您拥有两端的JavaScript,因此不会出现这种情况。换句话说,建立连接的愿望通常先于制作连接。