Landing when last remaining usage in Chrome has been removed.
Bug: webrtc:11943
Change-Id: I62817e2cc0b67113126b82424b6f843c77e66f31
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341001
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42157}
This avoids problems with the Chrome component build.
Bug: webrtc:11943
Change-Id: I120628ee7829aa0255e60e2f21ac0608374340b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348723
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42146}
This allows both the signal and the callback to be used.
Bug: webrtc:11943
Change-Id: I89460126d415520295c7e7d4ee440156a6e9e5ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329140
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41282}
SdpOfferAnswerHandler now hands over most of the work of adding a
remote candidate over to PeerConnection where the work will be
carried out asynchronously on the network thread (was
synchronous/blocking).
Once added, reporting (ReportRemoteIceCandidateAdded) continues on the
signaling thread as before. The difference is though that we don't
block the UseCandidate() operation which is a part of applying the
local and remote descriptions.
Besides now being asynchronous, there's one behavioural change:
Before starting the 'add' operation, the validity of the candidate
instance to be added, is checked. Previously if such an error occurred,
the error was silently ignored.
Bug: webrtc:9987
Change-Id: Ic1bfb8e27670fc81038b6ccec95ff36c65d12262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206063
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33230}
