如何在不刷新页面的情况下重置Chrome / node-webkit中的WebRTC状态？

本文介绍了如何在不刷新页面的情况下重置Chrome / node-webkit中的WebRTC状态？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 问题： 如何在Chrome中重置WebRTC组件的状态 - 无需重新加载页面 - 当它们被踢入无效状态时？有关我如何复制这种状态的更多详细信息，以及为什么我问这个问题： 问题描述： 在尝试设置Ice Candidates时，Chrome 35 / node-webkit 0.10.0中出现以下错误： 现在，我知道为什么会发生。我正在制作一个可以处理一些普通用户滥用的ROBUST WebRTC应用程序。要复制这个状态，我基本上必须做几个WebRTC调用，然后真正快速地杀掉它们，然后立即尝试另一个调用。我猜测这必须将PeerConnection和其他组件踢到它期望B发生的不同状态，但是我再次用A重新开始。这通过以下错误消息来证明： 现在，大多数我们在Internet上看到的WebRTC演示，例如 http://apprtc.appspot.com ，是无状态的，并且浏览器经常刷新，这会导致重置DOM状态。所以，对于那些开发者来说，答案很简单。只需重新加载页面并调用它即可。 目前，当DOM进入此状态时，我必须重新加载应用程序。然而，这不是一个可接受的解决方案，因为我正在构建单页应用程序，而不是网站， 我想知道是否有一种方法可以调用API来告诉它重置抛出这些错误的状态？ 一些故障排除步骤： 我尝试了以下方法，从node-webkit（Chrome 35）中的JavaScript控制台，以查看是否可以手动重置PeerConnection的状态，但这不是帮助： var properties = {}; properties.pcConfig = {iceServers：[{url：stun：stun.l.google.com：19302}] }; properties.pcConstraints = {可选：[] }; peerConn = new RTCPeerConnection（properties.pcConfig，properties.pcConstraints）; peerConn.close（）; 以下是一些peerConnection属性的输出： peerConn.signalingState - > closed peerConn.iceConnectionState - > closed peerConn.iceGatheringState - > complete 解决方案您应该能够回滚更改。这只能在角色没有改变时发生，即当第一个呼叫中的主叫方仍然是后续呼叫中的主叫方时，并且可能不适合您的情况，因为您收到的错误消息与对等连接接收有关在发出要约之前的回答（例如，调用者/被调用者之间不匹配）。 请注意，关闭状态是最终的，并且应该删除一个封闭的对等连接，因为它不能成为重复使用。 在您的情况下，删除原始对等连接并创建新连接是必须的，但还不够。您需要重新启动握手，并确保定位到原始对等连接的消息不被其他对等连接捕获和使用。多方客户有相同的设计问题。解决问题的一种方法，也是解决眩光问题的方法之一是增加提供，回答，离线交换潜在客户和潜在客户字段的候选消息。您必须自己生成ID，因为默认情况下，对等连接对象没有唯一的ID。 这是普通舞蹈（使用滴流ICE）： A正在联机，创建对等连接，并在索引A_0处将其刻录到映射中 B正在上线，与上面的B_0相同（确保ID是唯一的） A正在调用B 发送提供附加字段origin：A_0和target：B_0B收到offer，setLocalDescription（开始ICE收集），发送原始答案：B_0 ，目标：A_0，完成。 接收答案，设置本地描述（开始ICE收集），完成。目标和来源字段设置得当。 现在是有问题的情况： p> B在收到B的回答之前删除其A_0对等连接。 B发送答案和ICE A_0被A作为A_0丢弃的候选人不存在。 重新与A_1跳舞 眩光案例： A和B同时向对方发送要约 比较ID并根据可重复的任意规则选择一个（更大的数字，更大的字符串，使用字母顺序，...）。 函数handleGenericMsg（MSG）{如果（msg.origin ===用户名）{跟踪（ 'MAIN - [' +用户名+ ']忽略自信息：' + msg.type +'。'）; return; } switch（msg.type）{'offer'： offerHandler（msg）; 休息; 默认值： trace（'MAIN - ['+ targetMid +']收到不支持的消息：'+ JSON.stringify（msg））; 休息; } }; 函数offerHandler（msg）{ var targetMid = msg.origin; offer = new RTCSessionDescription（msg）; trace（'PC - ['+ targetMid +'] Received offer。'） var pc = peerConnections [targetMid]; if（！pc）{ openPeer（targetMid，false）; pc = peerConnections [targetMid]; } else { //我们已经有了一台PC，让我们重新使用它} pc.setRemoteDescription（offer）; doAnswer（targetMid）; }; Question:How does one go about resetting the state of WebRTC components in Chrome -- without reloading the page -- when they're kicked into an invalid state? See below for more details about how I'm replicating this state, and why I'm asking this:Problem description:I'm getting the following error in Chrome 35/node-webkit 0.10.0 when trying to set Ice Candidates when making a call:Now, I know why it's happening. I'm working on making a ROBUST WebRTC application that can handle some normal user abuse. To replicate this state, I basically have to make a couple WebRTC calls and then kill them real fast and then immediately try another call. I'm guessing this must kick the PeerConnection and other components into a different state where it's expecting B to happen, but I'm starting over again with A. This is evidenced by the following error message:Now, Most of the WebRTC demos we see on the Internet, like http://apprtc.appspot.com, are stateless, and the browser is refreshed often, which results in resetting the DOM state. So, for those developers, the answer is easy. Just reload the page and call it good.Currently, I have to reload the application when the DOM enters this state. However, that's not an acceptable solution, since I'm building a single page application, not a website, I'm wondering if there is a way to make a call to the API to tell it to reset the state of whatever it is that is throwing these errors?Some troubleshooting steps:I tried the following, from the JavaScript console in node-webkit (Chrome 35), to see if I can manually reset the state of the PeerConnection, but it isn't helping: var properties = {}; properties.pcConfig = { "iceServers": [{ "url": "stun:stun.l.google.com:19302" }] }; properties.pcConstraints = { "optional": [] }; peerConn = new RTCPeerConnection(properties.pcConfig, properties.pcConstraints); peerConn.close();Here's the output of some of the peerConnection properties:peerConn.signalingState --> "closed"peerConn.iceConnectionState --> "closed"peerConn.iceGatheringState --> "complete" 解决方案 You are supposed to be able to rollback changes. That can only happen when roles are not changed, i.e. when the caller in the first call is still the caller in the subsequent calls, and might not be appropriate in your case, as the error message you are getting is related to a peer connection receiving an answer before emiting an offer (i.e. a mismatch between caller/callee).Note that close states are final, and a closed peer connection should be deleted as it cannot be reused.In your case, deleting the original peer connection and making a new one is a must, but not enough. You would need to reinitiate the handshake, and to make sure that the messages targeted to the original peer connection is not captured and used by other peer connections. Multiparty clients have the same design problem. One way to solve it, and also to solve the glare problem, is to add to the "offer", "answer", "candidate" messages that you exchange offline an "origin" and potentially a "target" field. You must generate IDs yourself, as the peer connection object does not have unique ID by default.here is the normal dance (with trickle ICE):A is coming online, creating a peer connection and sore it in a mapat the index A_0B is coming online, same as above with B_0 (make sure IDs are unique)A is calling BA send an offer, with an additional field "origin":"A_0" and a "target":"B_0"B receive offer, setLocalDescription (starts ICE gathering), send answer with origin:B_0, target:A_0, Done.A receive answer, set local description (starts ICE gathering), Done.ICE candidates are being exchanged with the target and origin field set appropriately.now the problematic case:A deletes its A_0 peer connection before receiving B's answer.B sends answers and ICE candidates for A_0, that are discarded by A as A_0 does not exist.A restart the dance with A_1glare case:A and B send simultaneously an offer to each othercompare the IDs and chose one according to a reproducible arbitrary rule (the bigger number, the bigger string, use alphabetical order, ….)Note that this design also allow for multiparty calls, as each call would be isolated by the map, and routed by the messaging logic.function handleGenericMsg(msg){ if( msg.origin === username ) { trace( 'MAIN - [' + username + '] Ignoring self message: ' + msg.type + '.' ); return; } switch(msg.type){ case 'offer': offerHandler(msg); break; default: trace( 'MAIN - [' + targetMid + '] Unsupported message received: ' + JSON.stringify(msg)); break; }};function offerHandler( msg ){ var targetMid = msg.origin; offer = new RTCSessionDescription(msg); trace( 'PC - [' + targetMid + '] Received offer.' ) var pc = peerConnections[ targetMid ]; if( !pc ) { openPeer( targetMid, false ); pc = peerConnections[ targetMid ]; } else { // we already had a PC, let's reuse it } pc.setRemoteDescription( offer ); doAnswer( targetMid );}; 这篇关于如何在不刷新页面的情况下重置Chrome / node-webkit中的WebRTC状态？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！