| commit | 3427f538de4fce254ae6625d57b87aa4c6f66f5c | [log] [tgz] |
|---|---|---|
| author | deadbeef <deadbeef@webrtc.org> | Wed Jul 26 23:09:33 2017 |
| committer | Commit Bot <commit-bot@chromium.org> | Wed Jul 26 23:09:33 2017 |
| tree | d30c2b2a8b92dd545b8dfbdab61b4db6ec867f27 | |
| parent | 58f1725ff1feeb665aaa1bc222e6d36148d8fcb7 [diff] |
Relanding: Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting. Relanding because the broken chromium test has been fixed: https://chromium-review.googlesource.com/582196 This CL moves the responsibility for restricting the number of IPv6 interfaces used for ICE to BasicPortAllocator. This is the right place to do it in the first place; it's where all the rest of the filtering occurs. And NetworkManager shouldn't need to know about ICE limitations; only the ICE classes should. Part of the reason I'm doing this is that I want to add a "max_ipv6_networks" API to RTCConfiguration, so that applications can override the default easily (see linked bug). But that means that PeerConnection would need to be able to call "set_max_ipv6_networks" on the underlying object that does the filtering, and that method isn't available on the "NetworkManager" base class. So rather than adding another method to a place it doesn't belong, I'm moving it to the place it does belong. In the process, I noticed that "CompareNetworks" is inconsistent with "SortNetworks"; the former orders interfaces alphabetically, and the latter reverse-alphabetically. I believe this was unintentional, and results in undesirable behavior (like "eth1" being preferred over "eth0"), so I'm fixing it and adding a test. BUG=webrtc:7703 Review-Url: https://codereview.webrtc.org/2983213002 Cr-Original-Commit-Position: refs/heads/master@{#19112} Committed: https://chromium.googlesource.com/external/webrtc/+/ad9561404c0cc007574eaedade581928aa3d24ef Review-Url: https://codereview.webrtc.org/2983213002 Cr-Commit-Position: refs/heads/master@{#19159}
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.
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.