Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
getStats on "closed" objects #214
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 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.