Reason for revert:
Hitting DCHECK in chromium's WebrtcTransportTest.TerminateDataChannel and WebrtcTransportTest.DataStreamLate. Will investigate and reland.
Original issue's description:
> Separating SCTP code from BaseChannel/MediaChannel.
>
> The BaseChannel code is geared around RTP; the presence of media engines,
> send and receive streams, SRTP, SDP directional attribute negotiation, etc.
> It doesn't make sense to use it for SCTP as well. This separation should make
> future work both on BaseChannel and the SCTP code paths easier.
>
> SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
> directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
> doesn't get confused with webrtc::DataChannel any more.
>
> Beyond just moving code around, some consequences of this CL:
> - We'll now stop using the worker thread for SCTP. Packets will be
> processed right on the network thread instead.
> - The SDP directional attribute is ignored, as it's supposed to be.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2564333002
> Cr-Commit-Position: refs/heads/master@{#15906}
> Committed: 67b3bbe639TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2614813003
Cr-Commit-Position: refs/heads/master@{#15908}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15906}
State and priority added to ConnectionInfo. The Connection::State enum
is replaced by IceCandidatePairState enum class.
At P2PTransportChannel::GetStats, Connection::stats is called, producing
ConnectionInfo for the connection that is then filled in with additional
values from the Connection. This is refactored so that all values are
set by Connection::stats.
RTCStatsCollector is updated to surface the ConnectionInfo stats.
BUG=webrtc:6755, chromium:633550, chromium:627816
Review-Url: https://codereview.webrtc.org/2597423003
Cr-Commit-Position: refs/heads/master@{#15870}
No stats are collected by it, remove to reduce unnecessary thread hops.
BUG=webrtc:6875, chromium:627816
Review-Url: https://codereview.webrtc.org/2583193002
Cr-Commit-Position: refs/heads/master@{#15862}
Previously it was allowed to call AddStats with stats of the same ID
multiple times.
This revealed a few things:
- Local and remote streams can have the same label.
RTCMediaStreamStats's ID is updated to include "local"/"remote".
- The same certificate can show up multiple times (e.g. for local and
remote in a loopback), so we skip creating RTCCertificateStats for the
same certificate multiple times
BUG=chromium:627816
Review-Url: https://codereview.webrtc.org/2593503003
Cr-Commit-Position: refs/heads/master@{#15730}
RTCStatsCollector relies on PeerConnection and its WebRtcSession. If the
PeerConnection is destroyed, reference counting keeps the
RTCStatsCollector alive until the request has completed. But the request
is using PeerConnection/WebRtcSession resources that are destroyed in
~PeerConnection().
To get around this problem, RTCStatsCollector::WaitForPendingRequest()
is added, which is invoked at ~PeerConnection().
Integration test added, it caused a segmentation fault before this
change / EXPECT failure.
BUG=chromium:627816
Review-Url: https://codereview.webrtc.org/2583613003
Cr-Commit-Position: refs/heads/master@{#15674}
(This is a re-upload of https://codereview.webrtc.org/2567243003/, the
CQ stopped working there.)
The previously used WebRtcSession::GetTransportStats did a synchronous
invoke per channel (voice, video, data) on the signaling thread to the
network thread - e.g. 3 blocking invokes.
It is replaced by WebRtcSession::GetStats[_s] which can be invoked on
the signaling thread or on any thread if a ChannelNamePairs argument is
present (provided by WebRtcSession::GetChannelNamePairs on the signaling
thread).
With these changes, and changes allowing the getting of certificates
from any thread, the RTCStatsCollector can turn the 3 blocking thread
invokes into 1 non-blocking invoke.
BUG=webrtc:6875, chromium:627816
Review-Url: https://codereview.webrtc.org/2583883002
Cr-Commit-Position: refs/heads/master@{#15672}
Underlying stats gatherers may otherwise default it to -1.
BUG=chromium:669877, chromium:627816
Review-Url: https://codereview.webrtc.org/2562703007
Cr-Commit-Position: refs/heads/master@{#15625}
RTCIceCandidatePairStats.transport_id is set to the related
RTCTransportStats' id.
Unittest for RTCIceCandidatePairStats is updated to do EXPECT_EQ
between actual and an expected hardcoded dictionary. The previous way of
testing, ExpectReportContainsCandidatePair, is removed.
(ExpectReportContainsCandidate still exist, we might want to replace
this by EXPECT_EQ testing in a follow up.)
Unittest for RTCTransportStats is similarly updated and
ExpectReportContainsTransportStats is removed. A bug was uncovered where
the "rtcp_connection_info.best_connection = true" case was not tested
(a copy of rtcp_connection_info was used in the test, modifying that had
no affect on the test) - fixed.
rtcstats_integrationtest.cc updated to take transport_id into account.
In order to reuse an updated version of expected_rt[c]p_transport in the
unittest, timestamps are ignored by RTCStats::operator==.
BUG=chromium:627816, chromium:653873, chromium:653873, webrtc:6755
Review-Url: https://codereview.webrtc.org/2527113002
Cr-Commit-Position: refs/heads/master@{#15316}
RTCStatsCollector supports "payloadType", "codec" and "clockRate".
"channels", "parameters" and "implementation" need to be supported
before closing crbug.com/659117.
[1] https://w3c.github.io/webrtc-stats/#codec-dict*
BUG=chromium:659117, chromium:627816, chromium:657854
NOTRY=True
Review-Url: https://codereview.webrtc.org/2509803004
Cr-Commit-Position: refs/heads/master@{#15207}
Previously this was only collected for RTCOutboundRTPStreamStats video,
with no comment saying it was missing for Inbound. (nack_count should be
collected vor audio as well but this is currently not available - there
is already an existing comment about this in rtcstats_objects.h.)
BUG=chromium:657855, chromium:657854, chromium:627816
Review-Url: https://codereview.webrtc.org/2515293002
Cr-Commit-Position: refs/heads/master@{#15185}
DataChannel.SignalOpened and unittests added.
PeerConnection.SignalDataChannelCreated added and wired up to
RTCStatsCollector.OnDataChannelCreated on RTCStatsCollector
construction.
RTCStatsCollector.OnSignalOpened/Closed added and wired up on
OnDataChannelCreated.
rtcstatscollector_unittest.cc updated, faking that channels are opened
and closed.
I did not want to use DataChannelObserver because it is used for more
than state changes and there can only be one observer (unless code is
updated). Since DataChannel already had a SignalClosed it made sense to
add a SignalOpened.
Having OnSignalBlah in RTCStatsCollector is new in this CL but will
likely be needed to correctly handle RTPMediaStreamTracks being added
and detached independently of getStats. This CL establishes this
pattern.
(An integration test will be needed for this and all the other stats to
make sure everything is wired up correctly and test outside of a
mock/fake environment, but this is not news.)
BUG=chromium:636818, chromium:627816
Review-Url: https://codereview.webrtc.org/2472113002
Cr-Commit-Position: refs/heads/master@{#15059}
Not all members are collected by RTCStatsCollector and detached tracks
are not visible in the returned stats. This needs to be addressed before
closing crbug.com/660827 and crbug.com/659137
BUG=chromium:660827, chromium:659137, chromium:627816
Review-Url: https://codereview.webrtc.org/2467873005
Cr-Commit-Position: refs/heads/master@{#14978}
Reason for revert:
Dependend cl Breaks Chrome FYI.
peerconnection_unittest anropar RTCStatsReport::Create without parameters.
Original issue's description:
> RTCInboundRTPStreamStats[1] added.
>
> Not all stats are collected in this CL, this must be addressed before
> closing the issue.
>
> [1] https://w3c.github.io/webrtc-stats/#inboundrtpstats-dict*
>
> BUG=chromium:627816, chromium:657855, chromium:657854
>
> Committed: https://crrev.com/0d7bf169402ea9345d163998f4f7df89229ac470
> Cr-Commit-Position: refs/heads/master@{#14861}
TBR=hta@webrtc.org,deadbeef@webrtc.org,hbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:627816, chromium:657855, chromium:657854
Review-Url: https://codereview.webrtc.org/2470683002
Cr-Commit-Position: refs/heads/master@{#14862}
Simple refactoring.
Moved ProduceCertificateStatsFromSSLCertificateStats_s and
ProduceIceCandidateStats_s from member section of RTCStatsCollector
to the anonymous namespace of rtcstatscollector.cc.
The thread check is removed as a result, which makes sense because
the helper function does not know about which thread its input
parameter lives on, that is up to the calling place (which has a thread
check already).
This makes rtcstatscollector.h cleaner, and all ProduceBlahStats
functions are starting points of collecting various stats. (Call all
of them and you get a complete set of stats.)
(Not moving PrepareTransportCertificateStats_s because it is using a
private struct of RTCStatsCollector.)
BUG=627816
Review-Url: https://codereview.webrtc.org/2462573002
Cr-Commit-Position: refs/heads/master@{#14818}
or not being collected correctly.
These TODOs are already documented and in greater detail in
rtcstatscollector.cc, but if every discrepency is listed in
rtcstats_objects.h it is easier to get an overview of the progress of
the new GetStats API.
BUG=chromium:627816
TBR=hta@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2443163002
Cr-Commit-Position: refs/heads/master@{#14749}
The RTCStatsCollector collects candidates from candidate pairs. Note
that there may be other candidates that are not paired with anything,
stats for these should also be produced before closing crbug.com/632723.
[1] https://w3c.github.io/webrtc-stats/#icecandidate-dict*
BUG=chromium:627816, chromium:632723
Review-Url: https://codereview.webrtc.org/2384143002
Cr-Commit-Position: refs/heads/master@{#14565}
New file structure and targets:
rtc_stats_api
webrtc/api/stats/rtcstats.h
webrtc/api/stats/rtcstats_objects.h
webrtc/api/stats/rtcstatsreport.h
rtc_stats (dep on rtc_stats_api)
webrtc/stats/rtcstats.cc
webrtc/stats/rtcstats_objects.cc
webrtc/stats/rtcstatsreport.cc
libjingle_peerconnection (dep on rtc_stats)
webrtc/api/rtcstatscollector.cc
webrtc/api/rtcstatscollector.h
Placing rtc_stats_api headers in this separate target instead of
libjingle_peerconnection avoids a circular dependency
libjingle_peerconnection -> rtc_stats -> libjingle_peerconnection
Code changes:
PeerConnectionInterface::GetStats(RTCStatsCollectorCallback*) added for
the new stats collection API. Implemented by PeerConnection.
BUG=chromium:627816
Review-Url: https://codereview.webrtc.org/2331373004
Cr-Commit-Position: refs/heads/master@{#14246}
