W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2020

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

From: Sean DuBois via GitHub <sysbot+gh@w3.org>
Date: Sun, 26 Apr 2020 20:04:20 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-619617136-1587931459-sysbot+gh@w3.org>
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](https://github.com/webrtc/FirebaseRTC/blob/solution/public/app.js#L173-L183) 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 https://github.com/w3c/webrtc-pc/issues/2519#issuecomment-619617136 using your GitHub account
Received on Sunday, 26 April 2020 20:04:47 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC