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

It is an error only because this document defines it as such, if the document changes it isn't an error anymore. Developers have enough problems to worry about, why make them suffer from a death by a thousands cuts on stuff like this?


With this we require
* Either people put logic in their Client code to cache candidates
* Make their signaling servers smarter, making them cache ice candidates. This prevents people from using simple pub/sub code.

If I am a new developer and I open the [firebase example]( I see that we have this event handler after `setRemoteDescription`, why not just move it before? There is nothing explicit about this.  


If we removed this assert and moved the 'candidate caching' into the Clients all this would go away. This restriction also may not show up during local development, then when they go to prod they are stuck debugging this.

GitHub Notification of comment by Sean-Der
Please view or discuss this issue at using your GitHub account

Received on Sunday, 26 April 2020 20:04:47 UTC