From Philipp Hancke:
Stops and closes the DTLS transport object. Since stop() is final, if
what happens when calling getStats after this? There was some discussion of that case for the PC -- see w3c/webrtc-stats#3 and https://bugzilla.mozilla.org/show_bug.cgi?id=1056433 for some implementation rationale.
The text was updated successfully, but these errors were encountered:
The May ORTC Editor's draft says the following:
"For RTCDtlsTransport.getStats(), check whether RTCDtlsTransport.start() has been called; if not, reject p with an InvalidStateError. For RTCIceTransport.getStats(), check whether RTCIceTransport.start() has been called; if not, or if RTCIceTransport.stop() has been called, if not, reject p with an InvalidStateError. For RTCRtpSender.getStats(), check whether RTCRtpSender.send(parameters) has been called; if not, if not, reject p with an InvalidStateError. For RTCRtpReceiver.getStats(), check whether RTCRtpReceiver.receive(parameters) has been called; if not, if not, reject p with an InvalidStateError."
[BA] I don't understand why these error conditions are needed. If an object has not yet been configured to send or receive data, can't the stats returned reflect this (e.g. octets sent/received = 0)? Similarly, if the object has been closed, why can't the stats reflect the last stats prior to the closure?
An alternative that would be compatible with the proposed WebRTC 1.0 PR:
When the getStats() method is invoked, the user agent must queue a task to run the following steps:
Let p be a new promise.
Return, but continue the following steps in the background.
Start gathering the stats.
When the relevant stats have been gathered, return a new RTCStatsReport object, representing the gathered stats.
Added the "failed" state to RTCIceTransportState, as noted in: Issue #199 Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue #200 Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in: Issue #207 Updated the description of RTCIceGatherer.close() and the "closed" state, as noted in: Issue #208 Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue #214 Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue #215 Clarified state transitions due to consent failure, as noted in: Issue #216 Added a reference to [FEC], as noted in: Issue #217