> The change that makes the most sense to me is to signal prflx via icecandidate exactly like we do srflx. I agree that in some cases, a prflx candidate could have been a srflx candidate, should the web app provide a STUN server. I do not see the advantage of trying to manage prflx as srflx (but I see some complexity in doing that). We need to do signaling of srflx candidates through the web app. On the other hand, signaling of prflx candidates through the web app is not needed since this is done through STUN requests/responses. And signaling of prflx candidates can actually leak private information. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2124#issuecomment-475337045 using your GitHub accountReceived on Thursday, 21 March 2019 17:52:46 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC