This updates behavior to be aligned with the WebRTC spec.
Bug: chromium:948055
Change-Id: Id3bbf05b3df084c9b7f7d12598c09187679d60fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130493
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27394}
And delete corresponding dependencies on :webrtc_common. After this
change, common_types.h is included directly only from code in the
following directories:
api/
api/video/
api/video_codecs/
common_video/libyuv/include/
media/base/
modules/remote_bitrate_estimator/
modules/rtp_rtcp/source/
modules/video_coding/codecs/vp9/
There remains plenty of indirect dependencies on the types declared in
common_types.h, but the fewer direct dependencies should make it
easier to find the proper place for each type.
Bug: webrtc:5876
Change-Id: I93e8f214025ecb613c19fdec2015bd3f96c59aae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130501
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27376}
Previously, legacy GetStats would look up the track ID by querying the
local/remote SDP by SSRC. This doesn't work with Unified Plan since the
RtpSender/RtpReceiver track IDs may not correspond to the track ID
stored in the SDP.
This CL changes legacy GetStats to pull the track ID directly from the
RtpSenders and RtpReceivers as it generates the stats. This has a few
additional benefits:
1) Unsignaled receive SSRC stats should now get correctly matched to
the unsigneled RtpReceiver track ID for both Plan B and Unified
Plan.
2) Removes a couple methods on PeerConnection that were only used by
the legacy StatsCollector.
3) Keeps the SSRC -> track ID mapping more localized which should make
the code easier to understand.
Bug: chromium:943493
Change-Id: I43ecde8c3a3d1c5f9c749ba6c8dfb11e8c4950fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129782
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27324}
This is exercised by WPT test RTCDataChannel-id.
Bug: chromium:945256
Change-Id: I53781dc874134f8c68a49c201848377b93b8858f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128871
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27300}
Plus all the annotations that were necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: I452c17f52302fb28d37d9b570ef3b7ab3d023f77
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129443
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27289}
Earlier CLs assumed that the object pointed to by call_ had to be
accessed on the worker thread. While this is generally the case,
Call::MediaTransportChange is explicitly thread safe, so
PeerConnection::OnTransportChanged doesn't have to run on the worker
thread for that reason.
Which is fortunate, because it actually runs on the network thread.
The RTC_RUN_ON(worker_thread()) annotation on the method declaration
was ineffective because this method is being called via a base class
pointer; replacing it with a call to
RTC_DCHECK_RUN_ON(worker_thread()) in the function body immediately
triggered assertions in the unit tests.
Bug: webrtc:9987
Change-Id: I08cf558a74f4ca2b2eff8ef4810ebbd1287a9726
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129442
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27287}
The raw pointer would have leaked if the task was ever destroyed
without being run.
Bug: webrtc:9987
Change-Id: Iddeb1adf0f836b8fec3056eab89bce7b9f034ca7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128865
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27284}
Plus all the annotations that were necessary to make things compile
again.
We needed a special twist for call_. The value it points to is owned
by the worker thread, but the signal thread needs to read the pointer.
We could have made the pointer const, except that we explicitly reset
it in the destructor (in an invoke to the worker thread).
Bug: webrtc:9987
Change-Id: I31f024547f4be0e50967133b0d452c80ae38d7ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128863
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27278}
Plus all the annotations that were necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: Ia421e4dc0e1bbc81c3976cc7530d44de934d33bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128882
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27257}
Plus all the annotations that were necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: Ieb363d9ebb47658ecf9138552f44c5bcba6b9b80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128775
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27256}
Plus all the annotations that were necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: I7bd9793eb2d474f2ac7ce9e1ed590e67cc2e0a93
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128881
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27255}
Plus all the annotations that were necessary to make things compile
again.
port_allocator_flags_ was accessed on both the signaling and the
network thread, but I was able to replace it with a return value.
Bug: webrtc:9987
Change-Id: Iab977a49d6588ce2240487475ec3588ae579caa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128772
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27254}
updates the timestamp on the local and remote candidate stats for consistency
with other places. This also makes the graphs on chrome://webrtc-internals
work (even though most values don't update so showing graphs is not meaningful)
BUG=chromium:937833
Change-Id: I3267dd7a5f5a887dcd0756137077b8f02c201905
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128765
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27248}
std::not2 is deprecated in C++17, and that starts failing on C++17 mode
of ios_simulator build. This CL replaces it with a lambda to avoid the
warning.
Bug: chromium:752720
Change-Id: Id7ef847df0fbe0c44583ef3320e06f44644de929
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128620
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27198}
This change fixes some inefficiencies and quirks in the code that
originates in RtpTransport leading up to the demux.
This work is in preparation for more refactoring of the Demux stage
onwards.
Bug: webrtc:10297
Change-Id: I7b8f00134657d62c722939618a55a91a2b6040bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128220
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27185}
Main change is deleting support for @userinfo in turn urls. This was
specified in early internet drafts, but never made it into RFC 7065.
Bug: webrtc:6663, webrtc:10422
Change-Id: Idd315a9e6001326f3104be62be3bd0991adc7db4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128423
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27171}
(so far SetBitrate did not do anything for media transport)
Bug: webrtc:9719
Change-Id: I48e669341ffe6c9e4697ff9146c314be7796a209
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/127980
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27169}
MediaChannel accepted the RtpPacket buffers through non-const pointer.
This is both unclear and introduces questions regarding if the buffer is
actually copied or not.
This change modifies the method to accept by value to reduce ambiguity.
Usage of the non-const data() method which could potentially copy the
buffer contents is also reduced in favor of cdata() which never copies.
Bug: None
Change-Id: I3b2daef0d31cb6aacceb46c86da3a40ce836242b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/127340
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27090}
This is not used in practice as there's functionality on
other levels that serves the same purpose.
Bug: None
Change-Id: I0488dc42459b07607363eba0f2b06f4c50f7cda4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125520
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27061}
Call DataChannelObserver::OnBufferedAmountChange on each successful send.
Previously, the observer would get notified of buffered amount changes only when
queued send data is consumed. Data gets queued only if it cannot be sent right
away. According to the WebRTC standard[1], bufferedamount should be increased
before each sent and decreased after each successful sent. Update implementation
to be standard compliant.
Design doc: http://doc/1lorHBn-GMn5U0T0RQANxrsW0pXhw8XGZM-xZyVUOW90
[1] https://w3c.github.io/webrtc-pc/#dom-datachannel-bufferedamount
Bug: chromium:878682
Change-Id: Ife009d30c4a18dced9a54cf600a445bb1f02561d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/123237
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27057}
The previous URI was a placeholder and is not valid. The URI
https://webrtc.org/experiments/rtp-hdrext/transport-wide-cc-02/
must be used instead.
Bug: webrtc:10264
Change-Id: Ibabde599b5bbd116c1c5e86ba0c9c64019bf7026
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/126360
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27051}
Metrics are added to measure:
1. The number of send encodings in calls to AddTransceiver.
2. The number of times that simulcast is disabled because there is no
support from remote peer.
3. The number of times simulcast is indicated in ApplyLocal and
ApplyRemote and with which API surface (no simulcast, legacy munging,
spec-compliant).
Bug: webrtc:10372
Change-Id: I84717a1911efdf8aaf43cd6c04c7f09fcf2c58f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125482
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26979}
Currently, tests that verify metrics use a combination of
metrics::NumSamples and metrics::NumEvents to assert which samples
were recorded and how many times they were recorded. This means
that a comprehensive tests has n + 1 assertions for n distinct
samples.
The new metrics::Samples function returns a map of sample --> num
events which can be asserted against using gmock matchers,
achieving better coverage and better test failure messages in just
one line.
Bug: None
Change-Id: I07d4a766654cfc04e414b77b6de02927683a361f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/125486
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26974}
The old iceConnectionState only becomes completed on the controlling side, and only if we're not configured to continually gather ICE candidates. This change makes the new ICE connection state do the same thing.
Bug: webrtc:10356
Change-Id: I82ca854a638a52674e4ca43364cf454dacb0cf1e
Reviewed-on: https://webrtc-review.googlesource.com/c/124360
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26950}
Simulcast is disabled if the RIDs are not negotiated.
This change addresses the scenario in which RIDs are negotiated but
support for the RID extension is not negotiated.
In such cases, the RID extension cannot be used, so support for
simulcast should be turned off, as if RIDs were not negotiated.
A similar case can be made for MIDs, however MIDs are not explicitly
specified in simulcast. RIDs are only guaranteed to be unique within
a media section so it would seem that MIDs should be required.
However, applications supply RID values and can guarantee their
uniqueness, so unlike RIDs, the use of MIDs is not enforced as mandatory.
Bug: webrtc:10075
Change-Id: Ic1b27878ea152eaee43a38bbfda11144307766fe
Reviewed-on: https://webrtc-review.googlesource.com/c/125176
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26934}
We already support decoding of the x-mt line. This change adds the
a=x-mt line to the SDP offer. This is not a backward compatible change
for media transport (because of the changes in pre-shared key handling)
1) if media transport is enabled, and SDES is enabled, generate the
media transport offer.
2) if media transport generated the offer, add that offer to the x-mt
line.
3) in order to create media transport, require an x-mt line (backward incompatible).
The way it works is that
1) PeerConnection, on the offerer, asks jsep transport for the
configuration of the media transport.
2) Tentative media transport is created in JsepTransportController when
that happens.
3) SessionDescription will include configuration from this tentative
media transport.
4) When the LocalDescription is set on the offerer, the tentative media
transport is promoted to the real media transport.
Caveats:
- now we really only support MaxBundle. In the previous implementations,
two media transports were briefly created in some tests, and the second
one was destroyed shortly after instantiation.
- we, for now, enforce SDES. In the future, whether SDES is used will be
refactored out of the peer connection.
In the future (on the callee) we should ignore 'is_media_transport' setting. If
Offer contains x-mt, media transport should be used (if the factory is
present). However, we need to decide how to negotiate media transport
for data channels vs data transport for media (x-mt line at this point
doesn't differentiate the two, so we still need to use app setting).
This change also removes the negotation of pre-shared key from the
a=crypto line. Instead, media transport will have its own, 256bit key.
Such key should be transported in the x-mt line. This makes the code
much simpler, and simplifies the dependency / a=crypto lines parsing.
Also, adds a proper test for the connection re-offer (on both sides: callee and caller).
Before, it was possible that media transport could get recreated, based on the offer.
The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test.
This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even
when there is a re-offer.
Bug: webrtc:9719
Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01
Reviewed-on: https://webrtc-review.googlesource.com/c/125040
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26933}
Since there is no way to enable/disable these diagnostics at runtime,
this CL moves the suppression into the rtc_* templates in order to
remove the need to explicitly add the snippet of code needed to
suppress it (currently copy/pasted in 144 locations).
The diagnostic that causes the most problems is the one about "complex
class/struct explicit ctor/dtor" [1] because WebRTC doesn't find
it useful enough.
Other diagnostics are good (for example the one that warns about
using "virtual" instead of "override", but that will be covered by
this clang-tidy check [2]) while others are Chromium related so
they have never triggered.
[1] - https://cs.chromium.org/chromium/src/tools/clang/plugins/FindBadConstructsConsumer.cpp?l=147-167&rcl=b4bebe1aa15dba7ca5fcc6456a81a55665327c3a
[2] - https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html
Bug: webrtc:163
Change-Id: Icbf27efa5b369100a31e6a32df1a0913729b3b34
Reviewed-on: https://webrtc-review.googlesource.com/c/125088
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26918}
This CL applies clang-tidy's bugprone-argument-comment [1] to the
WebRTC codebase.
All changes in this CL are automatically generated by both clang-tidy
and 'git cl format'.
[1] - https://clang.llvm.org/extra/clang-tidy/checks/bugprone-argument-comment.html
Bug: webrtc:10252
Change-Id: I77fec17509311275f18e730e482fb9f3fb2998ad
Reviewed-on: https://webrtc-review.googlesource.com/c/124989
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26900}
This is a reland of 05d43c6f7fe497fed0f2c8714e2042dd07a86df2
The original CL got reverted because Chrome did not support IsQuitting() which
triggered a NOTREACHED() inside of a DCHECK. With
https://chromium-review.googlesource.com/c/chromium/src/+/1491620
it is safe to reland this CL.
The only changes between this and the original patch set is that this is now
rebased on top of https://webrtc-review.googlesource.com/c/src/+/124701, i.e.
rtc::PostMessageWithFunctor() has been replaced by rtc::Thread::PostTask().
Original change's description:
> Fix getStats() freeze bug affecting Chromium but not WebRTC standalone.
>
> PeerConnection::Close() is, per-spec, a blocking operation.
> Unfortunately, PeerConnection is implemented to own resources used by
> the network thread, and Close() - on the signaling thread - destroys
> these resources. As such, tasks run in parallel like getStats() get into
> race conditions with Close() unless synchronized. The mechanism in-place
> is RTCStatsCollector::WaitForPendingRequest(), it waits until the
> network thread is done with the in-parallel stats request.
>
> Prior to this CL, this was implemented by performing
> rtc::Thread::ProcessMessages() in a loop until the network thread had
> posted a task on the signaling thread to say that it was done which
> would then get processed by ProcessMessages(). In WebRTC this works, and
> the test is RTCStatsIntegrationTest.GetsStatsWhileClosingPeerConnection.
>
> But because Chromium's thread wrapper does no support
> ProcessMessages(), calling getStats() followed by close() in Chrome
> resulted in waiting forever (https://crbug.com/850907).
>
> In this CL, the process messages loop is removed. Instead, the shared
> resources are guarded by an rtc::Event. WaitForPendingRequest() still
> blocks the signaling thread, but only while shared resources are in use
> by the network thread. After this CL, calling WaitForPendingRequest() no
> longer has any unexpected side-effects since it no longer processes
> other messages that might have been posted on the thread.
>
> The resource ownership and threading model of WebRTC deserves to be
> revisited, but this fixes a common Chromium crash without redesigning
> PeerConnection, in a way that does not cause more blocking than what
> the other PeerConnection methods are already doing.
>
> Note: An alternative to using rtc::Event is to use resource locks and
> to not perform the stats collection on the network thread if the
> request was cancelled before the start of processing, but this has very
> little benefit in terms of performance: once the network thread starts
> collecting the stats, it would use the lock until collection is
> completed, blocking the signaling thread trying to acquire that lock
> anyway. This defeats the purpose and is a riskier change, since
> cancelling partial collection in this inherently racy edge-case would
> have observable differences from the returned stats, which may cause
> more regressions.
>
> Bug: chromium:850907
> Change-Id: Idceeee0bddc0c9d5518b58a2b263abb2bbf47cff
> Reviewed-on: https://webrtc-review.googlesource.com/c/121567
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26707}
TBR=steveanton@webrtc.org
Bug: chromium:850907
Change-Id: I5be7f69f0de65ff1120e4926fbf904def97ea9c0
Reviewed-on: https://webrtc-review.googlesource.com/c/124781
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26896}
This involves inserting an extra layer between jsep_transport_controller
and the cricket::SctpTransportInternal layer. The objects at this layer
are reference counted.
Bug: chromium:818643
Change-Id: Ibed57c4a538de981cee63e0f7f1f319f029cab39
Reviewed-on: https://webrtc-review.googlesource.com/c/123884
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26889}
If x-mt line is present (one or more), and the first line is dedicated
for the media transport that we support, pass the config down to this
media transport.
In the future we will do 3 changes:
1) Add MediaTransportFactory::IsSupported(config) to let the
implementation decide whether the current factory can support a given
setting
2) Add support for multiple x-mt lines. Right now the support is
minimal: we only look at the first line (because we only allow single
media transport factory). In the future, when RtpMediaTransport is
introduced, this may and will change.
3) Allow multiple MediaTransportFactories and add fallback to RTP if
media transport is not supported.
Current solution provides backward compatibility for the 2 above
extensions.
Bug: webrtc:9719
Change-Id: I82a469fecda57effc95d7d8191f4a9e4a01d199c
Reviewed-on: https://webrtc-review.googlesource.com/c/124800
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26882}
