- From: Nils Ohlmeier via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jun 2018 19:28:21 +0000
- To: public-webrtc-logs@w3.org
First of all let's start with that I don't think this is an editorial change. If you describe what to do in case of an event which was previously undefined I would say that gets pretty close to a normative change in behavior. Secondly it is worth noting that Firefox does in fact switch to disconnected once a single ICE consent check goes unanswered. The reason is that Firefox respects the consent check spec and send checks only ever 5 seconds. Where Chrome instead floods the network with way more consent requests and then only set to disconnect if a series of consent checks were unanswered. In my opinion consent checks are not intended as a keep alive ping to detect if there is for example really high packet loss. The consent check is suppose to protect against flooding the network and the endpoint if the other side no longer want or can receive media. That is different from detecting network hickups. Since developers thanks to Chrome's implementation choices are expecting to rely on consent check and the disconnected state as a "network if flaky" indication Firefox decided to at least tell the application right away on the first lost consent packet. If you want to give a recommendation for when to initiate ICE restarts I would say it should happen at failed, because that is when the ICE has given up. But that can be quite late, in case of Firefox after 30 seconds. Therefore I personally do recommend developers to take the disconnected event as a signal to invoke code which looks at other factors, e.g. stats, to conclude if it's better to wait or to try an ICE restart right away. -- GitHub Notification of comment by nils-ohlmeier Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1445#issuecomment-398868319 using your GitHub account
Received on Wednesday, 20 June 2018 19:28:23 UTC