ICE connected or not…

n Firefox 49 we released support for ICE Consent Freshness as a first way to detect that an ICE transport is no longer working. What does ICE Consent Refresh do, you ask?
With plain ICE

Lets start with what we had before. Without Consent Refresh the ICE standard requires us to send so called Keepalives to keep the ports in the NAT open. But these Keepalives had a couple of issues. First of all the Keepalives only send traffic. They do not require a response nor do they expect any response. So as the sender, you basically try your best to keep the NAT ports open, but you have no idea if it works or not.
Adding Consent timeouts

To improve that experience, in Firefox 49 we released support for ICE Consent Freshness. With plain ICE you stop sending STUN binding requests once both parties have identified and agreed on a working transport path. The idea behind ICE Consent Freshness is that once connected you continue to send STUN binding requests. And the other side needs to answer.

So every 5 seconds Firefox (version >= 49) sends another binding request no matter if the ICE transport is in use or not, and it expects the other side to reply with a binding response. If it hasn’t received a binding response for 6 consecutive binding requests, in other words no reply within the last 30 seconds, it will give up and mark the transport as failed. This results in switching the ICE connection state to ‘failed‘ and stop sending any packets over that transport.

This also protects the network from unnecessary traffic as Firefox before would have continued to send RTP (assuming the application logic had not closed the PeerConnection by now). By the way, as a receiver of these Consent Freshness binding requests, you can also revoke the consent by responding with a 403 binding response error.

Now when your WebRTC application watches the ICE connection state it at least knows when the transport layers have given up. However, 30 seconds is quite a long time for an inpatient human who was just enjoying a thrilling conversation. And it is not advisable to try an ICE restart at this point.
Utilizing Consent to detect connection problems

The new feature, which utilizes the previous ICE Consent Freshness work, is that Firefox (version >= 52) switches the ICE connection state even earlier. Basically, when not receiving a reply for one of the binding requests within 5 seconds, the ICE connection state is going to switch to ‘disconnected‘. At this point the senders can still send packets. And more binding requests are going to be sent. If one of the subsequent binding requests gets a binding response, the ICE connection state switches back to ‘connected‘. And if no binding responses are received at all, approximately 25 seconds later the ICE connection state switches to ‘failed‘ and no further packets are sent.

So it’s up to the application to decide what to do when the ICE connection state switches from ‘connected‘ to ‘disconnected‘. One option is to try an ICE restart right then. But since the stun binding requests for ICE Consent Freshness are not being retransmitted, it could also mean that just the binding response packet got dropped by the network. The better alternative is to wait for a couple of more seconds to see whether the ICE connection state switches back to ‘connected‘, and if not, try the ICE restart prior to the connection state changing to ‘failed‘.

Picture By Brocken Inaglory (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html), CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/) or CC BY-SA 2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/2.5-2.0-1.0)], via Wikimedia Commons

from:https://blog.mozilla.org/webrtc/ice-disconnected-not/

阅读更多
个人分类: 移动开发
上一篇snmp4jGet demo
下一篇少走弯路,给Java 1~5 年程序员的建议
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭