- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 19:24:45 +0000
- To: public-webrtc-logs@w3.org
Hi @Sean-Der I worry this is covering up a bug somewhere. Does your signaling guarantee order? WebRTC relies on a serialized signaling channel, so queuing ICE candidates is an [anti-pattern](https://github.com/web-platform-tests/wpt/issues/19866). It 1. complicates negotiation & renegotiation 2. covers up signs of browser and/or application bugs 3. defeats Trickle ICE in [some cases](https://stackoverflow.com/a/36851163), slowing down connection The spec says `onicecandidate` [cannot fire](https://w3c.github.io/webrtc-pc/#ref-for-dfn-release-early-candidates-1) before SLD, guaranteeing this signaling order: ``` offer candidate candidate candidate ``` and in the reciprocal direction ``` answer candidate candidate candidate ``` This becomes important during rapid re-negotiation and ICE restarts, where we might see: ``` offer candidate candidate offer candidate candidate candidate ``` Does the second candidate belong to the first or second offer? Also, most queuing I've seen only works on initial negotiation, which may lead to missed candidates and intermittents if it was wallpapering a real timing hole in a browser or application. Negotiation being an async state machine, strict state management is one of the few guide-rails we offer, so I don't think we should relax them. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-622055440 using your GitHub account
Received on Thursday, 30 April 2020 19:24:47 UTC