417eebe5dd
According to JSEP, the candidate filter does not affect pooled candidates because they can be filtered once they're ready to be surfaced to the application. So, pooled port allocator sessions will use a filter of CF_ALL, with a new filter applied when the session is taken by a P2PTransportChannel. When the filter is applied: * Some candidates may no longer be returned by ReadyCandidates() * Some candidates may no longer have a "related address" (for privacy) * Some ports may no longer be returned by ReadyPorts() To simplify this, the candidate filtering logic is now moved up from the Ports to the BasicPortAllocator, with some helper methods to perform the filtering and stripping out of data. R=honghaiz@webrtc.org, pthatcher@webrtc.org Review URL: https://codereview.webrtc.org/1998813002 . Cr-Commit-Position: refs/heads/master@{#12856}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others. This page is maintained by the Google Chrome team.
Development
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://chromium.googlesource.com/external/webrtc
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: http://build.chromium.org/p/client.webrtc