- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Jan 2018 14:13:56 +0000
- To: public-webrtc-logs@w3.org
@taylor-b sure you can modify your code. But if you know your peer does not support trickle you don't need canTrickleIceCandidates at all. So I assume that this property is designed for library code that needs to deal with both trickle peers and non-trickle peers (and also peers that may support trickle and where discovery is needed). > (What if it's set to true but the remote answer indicates otherwise? How do the application-set values interact with rollbacks? etc.). What if you call SRD, onicecandidate fires, you rollback? Now you sent the ice candidate already... or what happens with pranswer? This property seem add much complexity for very little gain. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1721#issuecomment-356294972 using your GitHub account
Received on Tuesday, 9 January 2018 14:14:00 UTC