henbos

Any objections, @alvestrand?

And @jan-ivar

PR exists: #669

TPAC: This is already available as https://w3c.github.io/webrtc-pc/#dom-rtcrtpcodecparameters, no objection to remove codecs not currently in use from getStats.

The way to do this now is to listen to "RTCPeerConnection.ontrack". But if it is useful to tell this from a getStats call, we could add them like @alvestrand said...

Proposal: add streamIdentifiers (DOMString array) to "sender" and "receiver"

@alvestrand @vr000m

Edited the description with a correction: It is not the RTP timestamp that is rewritten by the server to account for the Sender->Server delay - it is the RTP->NTP mapping...

I think JS can calculate the "estimatedNtpDelta" this using RTCRemoteInboundRtpStreamStats.roundTripTime (or totalRoundTripTime/rotalRoundTripTimeMeasurements), RTCRemoteOutboundRtpStreamStats.remoteTimestamp and RTCRemoteOutboundRtpStreamStats.timestamp. Chrome would need new metrics and some bug fixes for this to fly. playoutTimeInReceiverNtp should...

Hmm yeah I think you're right, a separate metric makes more sense to make it explicit and not force implementations to have everything match to the millisecond.