getStats on "closed" objects #214

Closed
aboba opened this Issue Jun 17, 2015 · 3 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Jun 17, 2015

From Philipp Hancke:

  1. page 6, section 2.3.2

Stops and closes the DTLS transport object. Since stop() is final, if
start() is called afterwards, throw an InvalidStateError exception.

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.

@aboba aboba added 1.1 1.0 labels Jun 17, 2015
@robin-raymond
Contributor

getStats returns a promise, so (to me) the promise should return but trigger the failed state... ?

@robin-raymond
Contributor

Or it returns last state...

@aboba
Contributor
aboba commented Jun 20, 2015

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:

getStats
Gathers stats for the given object and reports the result asynchronously. If the object has not yet begun to send or receive data, the returned stats will reflect this. If the object is in the closed state, the returned stats will reflect the stats at the time the object transitioned to the closed state.

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.

No parameters.
Return type: Promise

@robin-raymond robin-raymond pushed a commit that referenced this issue Jun 22, 2015
Robin Raymond Addressed Philipp Hancke's review comments, as noted in: Issue #198
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
894b08b
@aboba aboba closed this Jun 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment