This patch adds support for manually setting subnets that
should be handled as VPN, i.e be subject to VpnPreference,
in case webrtc fails to auto-detect VPNs.
Bug: webrtc:13097
Change-Id: I42514f0677a35cfe30ad053570fa9c2a5b4a856b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230122
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34852}
This patch adds a vp preference field to RTCConfig.
DEFAULT, // No VPN preference.
ONLY_USE_VPN, // only use VPN connections.
NEVER_USE_VPN, // never use VPN connections
PREFER_VPN, // use a VPN connection if possible, i.e VPN connections sorts higher than all other connections.
AVOID_VPN, // only use VPN if there is no other connections, i.e VPN connections sorts last.
Bug: webrtc:13097
Change-Id: I3f95bdfa9134e082c7d389f803bd08facfb70262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229591
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34842}
This is a private method, and the `prepare_address` argument was
constant true at all call sites.
Bug: None
Change-Id: Id4714ee7c154a729a6e106c29895fc760e9d0455
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228527
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34739}
AllocationSequence uses legacy rtc::Thread message handling. In order
to cancel callbacks it uses rtc::Thread::Clear() which uses locks and
necessitates looping through all currently queued (unbounded) messages
in the thread. In particular, these Clear calls are common during
negotiation and the probability of having a lot of queued messages is
high due to a long-running network thread function invoked on the
network thread.
Fix this by migrating AllocationSequence to task queues.
Bug: webrtc:12840, webrtc:9702
Change-Id: I42bbdb59fb2c88b50e866326ba15134dcc6ce691
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221369
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34241}
Removes dependence on rtc::Thread APIs from BPAS, which removes
the need to remove callbacks via rtc::Thread::Clear().
Bug: webrtc:12840
Change-Id: I0bcc1828c5ab38f521b583f52707174961f28e8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221366
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34239}
All Post() calls are made to the network thread which the class already
clears up explicitly. 'AutoCleanup' scans all thread instances, which is
not needed for this class.
Bug: webrtc:11988
Change-Id: Ieefbdc87683dc62b6156c5df72e87d404242170f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194339
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32662}
As documented in webrtc:11908 this cleanup is fairly invasive and
when a part of a frequently executed code path, can be quite costly
in terms of performance overhead. This is currently the case with
synchronous calls between threads (Thread) as well with our proxy
api classes.
With this CL, all code in WebRTC should now either be using MessageHandlerAutoCleanup
or calling MessageHandler(false) explicitly.
Next steps will be to update external code to either depend on the
AutoCleanup variant, or call MessageHandler(false).
Changing the proxy classes to use TaskQueue set of concepts instead of
MessageHandler. This avoids the perf overhead related to the cleanup
above as well as incompatibility with the thread policy checks in
Thread that some current external users of the proxies would otherwise
run into (if we were to use Thread::Send() for synchronous call).
Following this we'll move the cleanup step into the AutoCleanup class
and an RTC_DCHECK that all calls to the MessageHandler are setting
the flag to false, before eventually removing the flag and make
MessageHandler pure virtual.
Bug: webrtc:11908
Change-Id: Idf4ff9bcc8438cb8c583777e282005e0bc511c8f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183442
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32049}
This was an ICE configuration experiment added a couple years ago that did not end up being used.
Bug: webrtc:11316
Change-Id: Iafb7e1c4f7b4598815f045808dbf6e470172f119
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167680
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30395}
This is part of a CL series merging rtc::MessageQueue into rtc::Thread.
Bug: webrtc:9883
Change-Id: I3cb857cc707d5e897759366d1478cc1ec19bce9a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165344
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30180}
There's a similar member in the base class, PortAllocator, which
appears to be in use.
Bug: None
Change-Id: Ie82801a7d0ae62f1e2758b6f434485bd5f78e8ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/164520
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30145}
If a stun server is already there, the benefit of adding turn servers as stun servers is small,
and it may create unnecessary stun candidates.
Bug: webrtc:11059
Change-Id: Ia37b43b787180af4d91c1c07c866ccbf1db80262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158680
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29644}
Mainly an update of the BasicPortAllocator tests. Other code related
to gturn may be deleted in a followup cl.
Bug: None
Change-Id: I72146c8faf30c1a9d03d320d75af91984f797a7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153485
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29275}
The new constructor takes a NetworkManager and a list of turn servers.
Intended to aid migration away from using the constructor with
additional relay addresses.
Bug: webrtc:10947
Change-Id: If8dcdc24090cc35b929646bc78aa646e8135e4cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151641
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29095}
Per the latest WebRTC stats spec
(https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats)
the address field of a peer-reflexive remote candidate should be concealed
until the same address is learnt via addIceCandidate.
This CL also refactors the sanitization-related code paths.
Bug: chromium:968161
Change-Id: I74c5da78232b2f604689867bda2937b8af827c4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149381
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28909}
This is a reland of 9469c784db
Original change's description:
> Added OnIceCandidateError to API and implementation
>
> Bug: webrtc:3098
> Change-Id: I27ffd015ebf9e8130c1288f7331b0e2fdafb01ef
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135953
> Commit-Queue: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
> Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28173}
TBR=steveanton@webrtc.org
Bug: webrtc:3098
Change-Id: I77af2065fc1479273f399e2b3d919f98fe8ac23d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140641
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28179}
Bug: webrtc:3098
Change-Id: I27ffd015ebf9e8130c1288f7331b0e2fdafb01ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/135953
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28173}
This is a reland of cd8d1cf68e
Original change's description:
> Surface ICE candidates that match an updated candidate filter.
>
> After this change an ICE agent can surface candidates that do not match
> the previous filter but are allowed by the updated one. The candidate
> filter, as part of the internal implementation in the ICE transport,
> manifests the RTCIceTransportPolicy field in RTCConfiguration.
>
> This new feature would allow an ICE agent to gather new candidates when
> the transport policy changes from e.g. 'relay' to 'all' without an ICE
> restart.
>
> A caveat in the current implementation remains, and a candidate can
> surface multiple times if the transport policy, or the candidate filter
> directly, performs multiple transitions from a value that disallows to
> one that allows the underlying candidate type. For example, if the
> transport policy is updated by 'all' -> 'relay' -> 'all', the same host
> candidate can surface after the second update.
>
>
> Bug: webrtc:8939
> Change-Id: I92c2e07dafab225c702c5de28f47958a0d3270cc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132282
> Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
> Reviewed-by: Jeroen de Borst <jeroendb@webrtc.org>
> Reviewed-by: Seth Hampson <shampson@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27674}
Bug: webrtc:8939
Change-Id: I9c32b1ea05028ecd937ab4912779dd958faf734f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133582
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Jeroen de Borst <jeroendb@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27694}
This reverts commit cd8d1cf68e.
Reason for revert: breaks an internal project
Original change's description:
> Surface ICE candidates that match an updated candidate filter.
>
> After this change an ICE agent can surface candidates that do not match
> the previous filter but are allowed by the updated one. The candidate
> filter, as part of the internal implementation in the ICE transport,
> manifests the RTCIceTransportPolicy field in RTCConfiguration.
>
> This new feature would allow an ICE agent to gather new candidates when
> the transport policy changes from e.g. 'relay' to 'all' without an ICE
> restart.
>
> A caveat in the current implementation remains, and a candidate can
> surface multiple times if the transport policy, or the candidate filter
> directly, performs multiple transitions from a value that disallows to
> one that allows the underlying candidate type. For example, if the
> transport policy is updated by 'all' -> 'relay' -> 'all', the same host
> candidate can surface after the second update.
>
>
> Bug: webrtc:8939
> Change-Id: I92c2e07dafab225c702c5de28f47958a0d3270cc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132282
> Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
> Reviewed-by: Jeroen de Borst <jeroendb@webrtc.org>
> Reviewed-by: Seth Hampson <shampson@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27674}
TBR=shampson@webrtc.org,qingsi@webrtc.org,jeroendb@webrtc.org,sukhanov@webrtc.org
Change-Id: Idd51a640e55a612b42fe8b69e05dff57a22d021a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8939
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133581
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27677}
After this change an ICE agent can surface candidates that do not match
the previous filter but are allowed by the updated one. The candidate
filter, as part of the internal implementation in the ICE transport,
manifests the RTCIceTransportPolicy field in RTCConfiguration.
This new feature would allow an ICE agent to gather new candidates when
the transport policy changes from e.g. 'relay' to 'all' without an ICE
restart.
A caveat in the current implementation remains, and a candidate can
surface multiple times if the transport policy, or the candidate filter
directly, performs multiple transitions from a value that disallows to
one that allows the underlying candidate type. For example, if the
transport policy is updated by 'all' -> 'relay' -> 'all', the same host
candidate can surface after the second update.
Bug: webrtc:8939
Change-Id: I92c2e07dafab225c702c5de28f47958a0d3270cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132282
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Jeroen de Borst <jeroendb@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27674}
