This is the same as the existing version, except it uses the Operations
Chain. As such, if an asynchronous operation that uses the chain is
currently pending, such as CreateOffer() or CreateAnswer(),
AddIceCandidate() will not happen until the previous operation
completes.
Bug: chromium:1019222
Change-Id: Ie6e5fc386fa9c29b5e2f8e3f65bfbaf9837d351c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158741
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29704}
These two annotations are now needed to correctly compile Chromium
with is_component_build=true and the WebRTC component.
TBR: kwiberg@webrtc.org
Bug: webrtc:9419
Change-Id: Id5603cf747357c0c2a4b41684eb4fd607cccfdea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158881
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29686}
Injecting both a custom NetEqFactory and an AudioDecoderFactory is not
supported, in that case the AudioDecoderFactory should be wrapped inside
the NetEqFactory.
Bug: webrtc:11005
Change-Id: I4e311eb1bfa03c91bca587d70540e81829f881c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158720
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29673}
Move the GCM srtp cipher suites below the default SRTP_AES128_CM_SHA1_80 one.
This will not negotiate them by default since they have an impact on packet overhead for audio-only calls.
GCM can still be negotiated if the peer offers it as preferred cipher suite or answers with just that cipher suite.
BUG=chromium:713701
Change-Id: I79bd4ab827e5c7f55f5550d14db3f4217a7eff86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158404
Reviewed-by: Justin Uberti <juberti@google.com>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Justin Uberti <juberti@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29672}
This is a reland of 1dddaa1a84
The regression that caused the original CL to be reverted was the fact that
invoking SetLocalDescription() inside of the CreateOffer() callback was no
longer executing synchronously and immediately.
In this CL, the original CL is patched so that the CreateOffer() operation
is marked as completed just before invoking the CreateOffer() callback
(versus doing it just afterwards). This ensures that the OperationsChain is
popped before the callback runs. The same applies for CreateAnswer().
See diff between Patch Set 1 (Original CL) and the latest Patch Set.
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a WeakPtr to the PC to ensure
> use-after-free does not happen.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org
Bug: webrtc:11019
Change-Id: I57b4496e63378c91c24679ee496e21f5cb6a0e59
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158524
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29630}
Bug: chromium:1018077
Change-Id: I585d4064f39e5f9d268b408ebf6ae13a056c778a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158403
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@{#29628}
This reverts commit 1dddaa1a84.
Reason for revert: Breaks downstream projects :(
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a raw pointer to the PC that is
> ensured not to be used-after-free using an "IsAlive" object.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org,hbos@webrtc.org
Change-Id: Ie540dcc8ecdc48ad0c65d23645fbc3ad5f99592b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11019
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158405
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29611}
For background, motivation, requirements and implementation notes, see
https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
Using the OperationsChain will unblock future CLs from chaining multiple
operations together such as implementing parameterless
setLocalDescription().
In this CL, the OperationsChain is used in existing signaling operations
with little intended side-effects. An operation that is chained onto an
empty OperationsChain will for instance execute immediately, and
SetLocalDescription() and SetRemoteDescription() are implemented as
"synchronous operations".
The lifetime of the PeerConnection is not indended to change as a result
of this CL: All chained operations use a raw pointer to the PC that is
ensured not to be used-after-free using an "IsAlive" object.
There is one notable change though: CreateOffer() and CreateAnswer() will
asynchronously delay other signaling methods from executing until they
have completed.
Drive-by fix: This CL also ensures that early failing
CreateOffer/CreateAnswer operation's observers are invoked if the
PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
is pending.
Bug: webrtc:11019
Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29605}
Static libraries don't guarantee that an exported symbol gets linked
into a shared library (and in order to support Chromium's component
build mode, WebRTC needs to be linked as a shared library).
Source sets always pass all the object files to the linker.
On the flip side, source_sets link more object files in release builds
and to avoid this, this CL introduces a the GN template "rtc_library" that
expands to static_library during release builds and to source_set during
component builds.
See: https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set
Bug: webrtc:9419
Change-Id: I4667e820c2b3fcec417becbd2034acc13e4f04fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157168
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29525}
Video and audio senders are missing mid, rid and rrid extensions in
their GetCapabilities call.
Bug: chromium:1007894
Change-Id: Ie9edba28ae32fda5e501913cac694f43bfb185ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156560
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29493}
This is a reland of 16d4c4d4fb after
downstream project was updated to be prepared for the new SdpType.
Original change's description:
> Implement rollback for setRemoteDescription
>
> Bug: chromium:980875
> Change-Id: I4575e9ad1902a20937f9812f49edee2a2441f76d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153525
> Commit-Queue: Eldar Rello <elrello@microsoft.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29422}
TBR=steveanton@webrtc.org
Bug: chromium:980875
Change-Id: Iba8d25bf2dc481b25a03eeae9818bd5f4c3eaa2d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156569
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29460}
Merge GlobalLock and GlobalLockPod, make member private.
annotate creation of all GlobalLocks with ABSL_CONST_INIT
Bug: None
Change-Id: I29abcc86796ec0e45b15df7d26392309d1bf7324
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156303
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29447}
RTCP is no longer handled by channels as of
https://webrtc-review.googlesource.com/c/src/+/152668. The tests for
RTCP in channel_unittest.cc are flaky and now only cover the logic of
passing RTCP through a transport to a fake on the other side.
Bug: webrtc:10983
Change-Id: Ib85b79adf79ee1524460b906b93b3a0e085ca8c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156324
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29438}
Bug: chromium:980875
Change-Id: I4575e9ad1902a20937f9812f49edee2a2441f76d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153525
Commit-Queue: Eldar Rello <elrello@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29422}
This enables creation and removal of receive streams with SSRC 0.
Several related methods, for example SetOutputVolume, still use 0 as a
special value.
Bug: webrtc:8694
Change-Id: I341e6bd6c981c9838997510d8d712ad2948f6460
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152780
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Saurav Das <dinosaurav@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29398}
The header files
api/congestion_control_interface.h
api/data_channel_transport_interface.h
api/datagram_transport_interface.h
api/media_transport_config.h
api/media_transport_interface.h
have been moved into the api/transport/ and api/transport/media
subdirectories.
Bug: webrtc:8733
Change-Id: I98752c4d1306b54559bafa71712b105932c08834
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153522
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29357}
The plugin transport parameters (a=x-opaque: lines) relate to how to create and
set up a plugin transport. When SDP bundle is used, the x-opaque line needs to
be copied into the bundled m= section. This means x-opaque can appear on a
section even if the offerer does not intend to use the transport for the media
described by that section. Consequently, the answerer cannot currently tell
whether the caller is offering an alternate transport for media, data, or both.
This change adds an a=x-alt-protocol: line to SDP. The value following this
line matches the <protocol> part of the x-opaque:<protocol>:<params> line.
However, alt-protocol is not bundled--it only ever applies to the m= section
that contains the line. This allows the offerer to express which m= sections
should actually use an alternate transport, even in the case of bundle.
Note that this is still limited by the available configuration options:
datagram transport can be used for media (audio + video) and/or data. It is
still not possible to use it for audio but not video, or vice versa.
PeerConnection places an alt-protocol line in each media (audio/video) m=
section if it is configured to use a datagram transport for media. It places
an alt-protocol line in each data m= section if it is configured to use a
datagram transport for data channels. PeerConnection leaves alt-protocol in
media (audio/video) m= sections of the answer if it is configured to use a
datagram transport for media, and in data m= sections of the answer if it is
configured to use a datagram transport for data channels.
JsepTransport now negotiates use of the datagram transport independently for
media and data channels. It only uses it for media if the m= sections for
bundled audio/video have an alt-protocol line matching the x-opaque protocol,
and only uses it for data channels if a bundled m= section for data has an
alt-protocol line matching the x-opaque protocol.
Bug: webrtc:9719
Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29351}
Adds a field trial and configuration parameter to control whether
datagram transport may be used for data channels in a receive-only
manner. By default, if use_datagram_transport_for_data_channels is
enabled, PeerConnection will create a datagram transport and offer its
use for outgoing calls as well as accept incoming offers with compatible
datagram transport parameters.
With this change, a receive_only mode is added for datagram transport
data channels. When receive_only is set, the PeerConnection will not
create or offer datagram transports for outgoing calls, but will accept
incoming calls that offer compatible datagram transport parameters.
Bug: webrtc:9719
Change-Id: I35667bcc408ea4bbc61155898e6d2472dd262711
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154463
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29327}
This fixes a DCHECK during teardown in the case when the primary
DataChannelTranspot (eg. DatagramTransport) is successfully negotiated.
DatagramTransport expects the DataSink to be unset before it's deleted.
This was not caught by existing tests because the fallback transport
(SctpDataChannelTransport) does not have the same DCHECK.
Also adds a regression test for the issue, in which SCTP is available
as a fallback but DataChannelTransport is negotiated successfully.
Bug: webrtc:9719
Change-Id: I414d964d3c85d3d01cdb5e34d6b248659a613c39
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154365
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29292}
This is a reland of 487f9a17e4
Original change's description:
> Reland "Refactor SCTP data channels to use DataChannelTransportInterface."
>
> Also clears SctpTransport before deleting JsepTransport.
>
> SctpTransport is ref-counted, but the underlying transport is deleted when
> JsepTransport clears the rtp_dtls_transport. This results in crashes when
> usrsctp attempts to send outgoing packets through a dangling pointer to the
> underlying transport.
>
> Clearing SctpTransport before DtlsTransport removes the pointer to the
> underlying transport before it becomes invalid.
>
> This fixes a crash in chromium's web platform tests (see
> https://chromium-review.googlesource.com/c/chromium/src/+/1776711).
>
> Original change's description:
> > Refactor SCTP data channels to use DataChannelTransportInterface.
> >
> > This change moves SctpTransport to be owned by JsepTransport, which now
> > holds a DataChannelTransport implementation for SCTP when it is used for
> > data channels.
> >
> > This simplifies negotiation and fallback to SCTP. Negotiation can now
> > use a composite DataChannelTransport, just as negotiation for RTP uses a
> > composite RTP transport.
> >
> > PeerConnection also has one fewer way it needs to manage data channels.
> > It now handles SCTP and datagram- or media-transport-based data channels
> > the same way.
> >
> > There are a few leaky abstractions left. For example, PeerConnection
> > calls Start() on the SctpTransport at a particular point in negotiation,
> > but does not need to call this for other transports. Similarly, PC
> > exposes an interface to the SCTP transport directly to the user; there
> > is no equivalent for other transports.
>
> Bug: webrtc:9719
> Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981
> Reviewed-by: Benjamin Wright <benwright@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Benjamin Wright <benwright@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29120}
Bug: webrtc:9719
Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29290}
Passing an empty arg is working at the moment but it is not
guaranteed to continue to work in the future.
This CL has been generated with:
git grep -l "INSTANTIATE_TEST_SUITE_P(," | xargs sed -i \
"s/INSTANTIATE_TEST_SUITE_P(,/INSTANTIATE_TEST_SUITE_P(All,/g"
Bug: None
Change-Id: Icd2fb9d9d29aed5d692a234124bd990d0f097db4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153890
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29282}
Only the ISAC codec had an non-trivial implementation, for its unused
adaptive mode. This cl deletes that implementation, and the call
from NetEq, and the interface method.
Bug: webrtc:10098
Change-Id: Iaf7667e0ae867fc9d64286dff4c01a8ce0b6e2a4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153882
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29279}
https://webrtc-review.googlesource.com/c/src/+/152740 changed the way
OnRtcpPacketReceived is invoked, so that Channel no longer handles the
hop to the worker thread internally. This change updates the test to
hop to the worker thread before calling channel, which fixes a test-only
tsan failure.
Bug: webrtc:10983
Change-Id: Ia31920791fc6eeee86c0d59aa091d708d706bcf0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154244
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29271}
PeerConnection now watches when data channels become ready to send
through its implementation of DataChannelSink, and no longer needs to
monitor the MediaTransport state.
Bug: webrtc:9719
Change-Id: I3e17747eb03926a3791c204bf5a1d2dc67855c09
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154001
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29261}
Previously, each RTCP packet was handled several times in a row, once
per m-section. This caused various weirdness and log warning spam, in
particular when using unified plan.
The cause was that the packets were wired trough each BaseChannel
instance up to the Call class. With this fix, the RTCP packets are wired
once per RtpTransportInternal via the common peer connection class.
Bug: chromium:1002875
Change-Id: I41c4eb3b68e215ebe0f2c6fb93ae0ee73335b89a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152668
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29226}
Keeping default implementations only for methods involved in
ongoing transitions.
Intended to catch inconsistencies between the interface and the
PeerConnectionProxy class, at compile time.
Bug: webrtc:10716
Change-Id: I4cb126c353855f7288ba09273fa6f87aaa0f32eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140860
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29224}
Changes Rtp Receivers to use a null value of ssrc to mean a default
receive stream.
Bug: webrtc:8694
Change-Id: I835199345f7add993b9078c8b0e7988d5cdd6646
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152425
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Saurav Das <dinosaurav@chromium.org>
Cr-Commit-Position: refs/heads/master@{#29201}
Intended as a utility base class for tests, to make it easier to
delete default implementations of PeerConnectionInterface methods.
Bug: webrtc:10716
Change-Id: Ie125747ad88d209c4797cc13253aef61275ed7b5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152820
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29184}
This makes it easier to follow the flow in a debugger and reduces
the number of methods.
Bug: webrtc:9883
Change-Id: If485ff08a223a3986ff24b29ebf4d37c325f0f26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152669
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29180}
The integration test sets up a loopback call, verifies media is flowing,
and then asserts which metrics should be available.
One of the things it asserted was that audioLevel is positive. This
could flake in rare circumstances because audioLevel requires a certain
number of samples to have been received before it is updated or else it
would have its default value zero.
This test is a broad asserting things about 150+ metrics; it's not worth
adding a dependency on the "implementation detail" about how long you
have to wait before this specific metric is non-zero. The fix for the
flake is to only require the metric to have been set, but zero is also
an acceptable value.
We don't lose much test coverage; we're still asserting that other
audio metrics originating from the same class have positive values.
Bug: webrtc:10962
Change-Id: I5def9193da7150492d89ea62031858bac5c41646
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152821
Reviewed-by: Yves Gerey <yvesg@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29179}
