Re: [webrtc-pc] addIceCandidate may not need to throw an error when no remoteDescription (#2519)

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]( It
 1. complicates negotiation & renegotiation
 2. covers up signs of browser and/or application bugs
 3. defeats Trickle ICE in [some cases](, slowing down connection

The spec says `onicecandidate` [cannot fire]( 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 using your GitHub account

Received on Thursday, 30 April 2020 19:24:47 UTC