- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 04 May 2020 14:54:07 +0000
- To: public-webrtc-logs@w3.org
> Something like this? That example was correctly written until you added a 1 second delay after SLD. Again, from [SO](https://stackoverflow.com/a/36851163/918910): > 1. Send pc.localDescription no later than in the setLocalDescription success callback. > 2. Expect pc.onicecandidate to start firing immediately after that callback. Send them. Signaling is implicit & immediate in local-loop demos, and you never "sent" your offer (by not calling answerer.SRD(offer)) before your 1 second delay, while still sending candidates without delay, thus breaking order. E.g. it's as if you'd signaled: ``` candidate candidate candidate (1 second pause) offer ``` Note it still connects, since local candidates get inserted into the local offer as well, so this is just error spam from unnecessary trickling. IOW, if you're going to delay initial connection by 1 second, do it anywhere else, since Trickle ICE exists solely to save that second. > > I add the `setTimeOut` just to make it happen everytime. > > If it happens without the setTimeout... please file a bug! Yes please, and test multiple browsers. Without your `setTimeout`, even the local-loop case should be air tight, thanks to peer connection's [operations chain](https://w3c.github.io/webrtc-pc/#dfn-operations-chain) (once SRD() is on that chain, addIceCandidate cannot race it). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-623512760 using your GitHub account
Received on Monday, 4 May 2020 14:54:08 UTC