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}
And move related files into api/transport/ and api/transport/media/.
The moved files are unchanged, except that
congestion_control_interface.h and datagram_transport_interface.h
no longer include media_transport_interface.h, instead, they forward
declare the few MediaTransport* types they reference.
Bug: webrtc:8733
Change-Id: I4f4000d0d111f10d15a54c99af27ec26c46ae652
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152482
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29178}
This reverts commit 487f9a17e426fd14bb06b13e861071b3f15d119b.
Reason for revert: speculative revert
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}
TBR=steveanton@webrtc.org,mellem@webrtc.org,benwright@webrtc.org
Change-Id: Ibd1a7f30931c114212c90824fec414d276d3f915
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152421
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29141}
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}
This is a canary CL to check if using c++14 feature breaks any webrtc user.
Bug: webrtc:10945
Change-Id: Iabaf8c06414c1ac960791bcb7cc46f5f5a5e1f14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151600
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29119}
Bug: webrtc:10139
Change-Id: I6803f4325e7c34915a9ae79e3360a787a7a9df5c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149173
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29105}
Bug: None
Change-Id: I0e7e76ec2d61a1e2719975701a32c1cfc04f97d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151960
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Alex Drake <alexdrake@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29103}
I gave up on removing proxy_info, user_agent and tcp_options. I don't
think it's feasible to remove them without removing all the proxy code.
The assumption that you can set the proxy and user agent long after
you have created the factory is entrenched in unit tests and the code
itself. So is the ability to set tcp opts depending on protocol or
endpoint properties.
It may be easier to untangle proxy stuff from the factory later,
when it becomes a more first-class citizen and isn't passed via
the allocator.
Requires https://chromium-review.googlesource.com/c/chromium/src/+/1778870
to land first.
Bug: webrtc:7447
Change-Id: Ib496e2bb689ea415e9f8ec1dfedff13a83fa4a8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150799
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29091}
And moved declaration into a new api directory, as
api/transport/rtp/rtp_source.h.
Bug: webrtc:8733
Change-Id: Ia73b7b0630e6065de4707a37633adddfa00a2b8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150880
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29039}
This reverts commit 4c85828ab272d9bd58789bad7b135b6287395f97.
Reason for revert:
Speculatively reverting this because it makes several web platform tests relating to RTCDataChannel flaky, see first failing roll:
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: I0d3151c48c1a511368277981fc4cf818a9f8ebb4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150341
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Benjamin Wright <benwright@webrtc.org>
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29012}
TBR=steveanton@webrtc.org,mellem@webrtc.org,benwright@webrtc.org
Change-Id: I074b9e68f298d20d0cabb4239084b4843e76e910
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150944
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29025}
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: I0d3151c48c1a511368277981fc4cf818a9f8ebb4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150341
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29012}
There are a few reasons for making this test only:
* The code is only used by tests and utilities.
* The pure interface has only a single implementation so an interface isn't really needed.
(a followup change could remove it altogether)
* The implementation always incorporates locking regardless of how the class gets used.
See e.g. previous use in the Packet class.
* The implementation is a layer on top of RtpUtility::RtpHeaderParser which is
sufficient for most production cases.
Change-Id: Ide6d50567cf8ae5127a2eb04cceeb10cf317ec36
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150658
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29010}
The new target does not depend on libjingle_peerconnection_api, and to
do this, the named "audio" and "video" string literals had to be moved from
media_stream_interface.cc to media_types.cc.
In this cl, the dependency on libjingle_peerconnection_api can be
dropped from a few targets.
No-Presubmit: True
Bug: webrtc:8733
Change-Id: Icc675280d5c3c537f2255a9389ff18a482049921
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/53861
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28998}
This was an oversight when integrating datagram-based data channels into
JsepTransportController. If a DatagramTransport exists, but only to be
used for data channels, JsepTransportController will still create an RTP
transport for it and use it for RTP.
Bug: webrtc:9719
Change-Id: I93cdb8bfc03159882a83a9f5097d3ef99fed215f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150241
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28993}
This patch adds accounting and reporting needed for
newly added RTCTransportStats.selectedCandidatePairChanges,
https://w3c.github.io/webrtc-stats/#dom-rtctransportstats-selectedcandidatepairchanges
a) P2PTransportChannel counts everytime selected_connection_
is modified and reports this counter in the GetStats()-call.
b) RTCStatsCollector puts the counter into the standardized
stats object.
Bug: webrtc:10900
Change-Id: Ibaeca18706b8edcbcb44b0c6f2754854bcb545ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149830
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28987}
The |frames_dropped| statistics contain not only frames that are dropped
but also frames that are in internal queues. This CL changes that so
that |frames_dropped| only contains frames that are dropped.
Bug: chromium:990317
Change-Id: If222568501b277a75bc514661c4f8f861b56aaed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150111
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28968}
This patch adds a new (optional) attribute to TURN_ALLOCATE_REQUEST,
TURN_LOGGING_ID (0xFF05).
The attribute is put into the comprehension-optional range
so that a TURN server should ignore it if it doesn't know if.
https://tools.ietf.org/html/rfc5389#section-18.2
The intended usage of this attribute is to correlate client and
backend logs.
Bug: webrtc:10897
Change-Id: I51fdbe15f9025e817cd91ee8e2c3355133212daa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149829
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28966}
It's propagated from ReceiveStatistics up to VoiceReceiverInfo,
and then not used. It's not part of the standard stats.
Bug: None
Change-Id: I90ce6a72e3ca846adbbba5d3023fef18a2169018
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149164
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28933}
PeerConnection now has a new setting in RTCConfiguration to enable use of
datagram transport for data channels. There is also a corresponding field
trial, which has both a kill-switch and a way to change the default value.
PeerConnection's interaction with MediaTransport for data channels has been
refactored to work with DataChannelTransportInterface instead.
Adds a DataChannelState and OnStateChanged() to the DataChannelSink
callbacks. This allows PeerConnection to listen to the data channel's
state directly, instead of indirectly by monitoring media transport
state. This is necessary to enable use of non-media-transport (eg.
datagram transport) data channel transports.
For now, PeerConnection watches the state through MediaTransport as well.
This will persist until MediaTransport implements the new callback.
Datagram transport use is negotiated. As such, an offer that requests to use
datagram transport for data channels may be rejected by the answerer. If the
offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data
channels with an extra x-opaque parameter for datagram transport. If the
opaque parameter is rejected (by an answerer without datagram support), the
offerer may fall back to SCTP.
If DTLS is not enabled, there is no viable fallback. In this case, the data
channels are negotiated as media transport data channels. If the receiver does
not understand the x-opaque line, it will reject these data channels, and the
offerer's data channels will be closed.
Bug: webrtc:9719
Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28932}
silentConcealedSamples, insertedSamplesForDeceleration and
removedSamplesForAcceleration were implemented in M76, but we forgot to
add them to the WEBRTC_RTCSTATS_IMPL list, meaning the "iterate all
members" method, RTCStats::Members(), did not contain these metrics.
As a consequence, Chrome did not pick up these members for exposure to
JavaScript.
Also fix the test coverage in rtc_stats_integrationtest.cc where code
paths that did not apply to audio track stats were not explicitly
asserting that they must be undefined in those cases.
Bug: chromium:996146, webrtc:10903
Change-Id: I00e7ddee600818ee4d561b88e005391830adcf3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149816
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28925}
DatagramDtlsAdaptor wraps a DatagramTransport in a DtlsTransport. This
is only used by wrapping it again, in an RtpTransport. It is simpler to
just wrap DatagramTransport directly into an RtpTransport.
DatagramTransport is never used as a DtlsTransport, and doesn't support
most of the functionality exposed by the DtlsTransport interface.
However, it supports *all* the functionality of the RtpTransport, making
this a much cleaner fit.
Bug: webrtc:9719
Change-Id: I699e8124ee4cb6c8c187162f9b444ff0431a4902
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149400
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28921}
This is a reland of 7c6f74ab0344e9c6201de711d54026e9990b8e6c
Compared to the previous commit, new bits are added to log calls of
AddIceCandidate, and the gathering and reception of IPv6 candidates.
Original change's description:
> Set the usage pattern bits for adding remote ICE candidates from SDP.
>
> Currently these bits are only set when a remote ICE candidate is
> successfully added via addIceCandidate. For non-trickled sessions in
> which the remote candidates are added via the remote description, these
> bits are lost. This also happens for trickled sessions, though a rare
> case, when addIceCandidate does not succeed because the peer connection
> is not ready to add any remote candidate.
>
> Bug: webrtc:10868
> Change-Id: Ib2f199f9ffc936060473934d25ba397ef31131a3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148880
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28844}
Bug: webrtc:10868
Change-Id: Ifac0593dcfb64d88619fd24b4ab61c14a0810beb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149024
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28904}
This is a reland of 2b9fa09fa3e3379fd8e76490c394f25670352ef2.
It got reverted because I forgot to whitelist the new metrics in chromium,
which has now been done:
https://chromium-review.googlesource.com/c/chromium/src/+/1760209
Relanding requires no changes to the CL.
Original change's description:
> [GetStats] Expose video codec implementation in standardized metrics.
>
> Spec issue: https://github.com/w3c/webrtc-stats/issues/445
> Spec PR: https://github.com/w3c/webrtc-stats/pull/473
>
> Now that the spec's RTCCodecStats.implementation has moved to
> RTCOutboundRtpStreamStats.encoderImplementation and
> RTCInboundRtpStreamStats.decoderImplementation, this CL implements them
> using the same string that the legacy getStats() API used.
>
> Bug: webrtc:10890
> Change-Id: Ic43ce44735453626791959df3061ee253356015a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149168
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28877}
TBR=ilnik@webrtc.org
Bug: webrtc:10890
Change-Id: Ib874b608856c2795b1ca08f6af43c61dd859ea21
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149800
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28887}
Media transport (or, equivalently, datagram transport) may only be
created for data channels. In this case, it's not appropriate to
consider ICE not-yet-connected or failed due to the media transport's
state. If the media transport disconnects or fails, it will signal data
channels separately.
Bug: webrtc:9719
Change-Id: Ieb7cb307116e479d01616559d8bafdfc650a78c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149420
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28884}
This reverts commit 2b9fa09fa3e3379fd8e76490c394f25670352ef2.
Reason for revert: speculative revert since it seems to break Chrome FYI bots. See https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Linux%20Tester/4206
Original change's description:
> [GetStats] Expose video codec implementation in standardized metrics.
>
> Spec issue: https://github.com/w3c/webrtc-stats/issues/445
> Spec PR: https://github.com/w3c/webrtc-stats/pull/473
>
> Now that the spec's RTCCodecStats.implementation has moved to
> RTCOutboundRtpStreamStats.encoderImplementation and
> RTCInboundRtpStreamStats.decoderImplementation, this CL implements them
> using the same string that the legacy getStats() API used.
>
> Bug: webrtc:10890
> Change-Id: Ic43ce44735453626791959df3061ee253356015a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149168
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28877}
TBR=ilnik@webrtc.org,hbos@webrtc.org
Change-Id: Ia0b7f9806564cf28881c50d6371b8141a22e3431
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10890
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149175
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28879}
Spec issue: https://github.com/w3c/webrtc-stats/issues/445
Spec PR: https://github.com/w3c/webrtc-stats/pull/473
Now that the spec's RTCCodecStats.implementation has moved to
RTCOutboundRtpStreamStats.encoderImplementation and
RTCInboundRtpStreamStats.decoderImplementation, this CL implements them
using the same string that the legacy getStats() API used.
Bug: webrtc:10890
Change-Id: Ic43ce44735453626791959df3061ee253356015a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149168
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28877}
This reverts commit 7c6f74ab0344e9c6201de711d54026e9990b8e6c.
Reason for revert: Need to merge with stacked changes on bits in a single patch to avoid disruption.
Original change's description:
> Set the usage pattern bits for adding remote ICE candidates from SDP.
>
> Currently these bits are only set when a remote ICE candidate is
> successfully added via addIceCandidate. For non-trickled sessions in
> which the remote candidates are added via the remote description, these
> bits are lost. This also happens for trickled sessions, though a rare
> case, when addIceCandidate does not succeed because the peer connection
> is not ready to add any remote candidate.
>
> Bug: webrtc:10868
> Change-Id: Ib2f199f9ffc936060473934d25ba397ef31131a3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148880
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28844}
TBR=hta@webrtc.org,qingsi@webrtc.org
Change-Id: Ia0d24b345f04e6c83199d7692bb55a440e6ff464
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10868
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149023
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28845}
Currently these bits are only set when a remote ICE candidate is
successfully added via addIceCandidate. For non-trickled sessions in
which the remote candidates are added via the remote description, these
bits are lost. This also happens for trickled sessions, though a rare
case, when addIceCandidate does not succeed because the peer connection
is not ready to add any remote candidate.
Bug: webrtc:10868
Change-Id: Ib2f199f9ffc936060473934d25ba397ef31131a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148880
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28844}
Bug: webrtc:10419
Change-Id: I18528bf2526e933568bf052de76a434f012161da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148320
Commit-Queue: Alex Drake <alexdrake@google.com>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Alex Glaznev <glaznev@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28838}
There aren't any tests for this and the code isn't currently
active except for the fact that it adds complexity to the Call
class, synchronization into the active code path and makes future
improvements to the class more complex or impossible.
Bug: webrtc:9719
Change-Id: Ia41af0b2186b8a36ca70a07858990b6af7f3a5c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148078
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28807}
This is a reland of 0a88ea050cda58de81d624cf2764d46929447ed5.
The new stat will not be reported unless it is GT 0.
Reporting of decoding_codec_plc events
Bug: webrtc:10838
Change-Id: Ic8585b4eeae9a2643374f15bc2578d1141e59683
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148448
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Alex Narest <alexnarest@google.com>
Cr-Commit-Position: refs/heads/master@{#28797}
In order to be able to detect and measure context around candidate pair changes.
Bug: webrtc:10419
Change-Id: Iab0d7e7c80d925d1aa44617fc35975fdc6bbc6b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147340
Commit-Queue: Alex Drake <alexdrake@google.com>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28779}
This reverts commit add7ef974ee2642a3b55a36ec80be50a615bc60a.
Reason for revert: Cause regression in pc_full_stack_tests.cc
Original change's description:
> Sanitize the codec list before sending it to the media engine
>
> The SDP can assign the same codec to two different payload types
> which gets represented as two separate codecs in the SDP structure.
> The media engine assumes that the client does not pass down
> duplicate codecs. This change adds logic to BaseChannel to filter
> out codecs of the same name with different payload types, picking
> the one which is listed first in the m= line.
>
> Bug: chromium:987598
> Change-Id: I6fa813db1769e572ff7c3f322dc9b1de39817ea2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147602
> Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
> Commit-Queue: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28726}
TBR=steveanton@webrtc.org,amithi@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:987598
Change-Id: I4ffbfcd90c81c6c6c8ee8f872f7e217d8291c857
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147864
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28744}
The SDP can assign the same codec to two different payload types
which gets represented as two separate codecs in the SDP structure.
The media engine assumes that the client does not pass down
duplicate codecs. This change adds logic to BaseChannel to filter
out codecs of the same name with different payload types, picking
the one which is listed first in the m= line.
Bug: chromium:987598
Change-Id: I6fa813db1769e572ff7c3f322dc9b1de39817ea2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147602
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28726}
The ID of stats was based on the datachannel's "id"
attribute, but that could change - it was -1 before ID
allocation, and a number afterwards.
This CL changes the stats ID to depend on a monotonically
increasing counter for allocated datachannels.
Bug: webrtc:10842
Change-Id: I3e0c5dc07df8a7a502396de06bbedc9f676994a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147642
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28720}
