Looks like a tracking bug - should probably not be triaged.

 Issue 463916  has been merged into this issue.

I think this is a bit strange, the name webrtc-internals indicate that this page should show the guts and inner workings of webrtc but instead we show stats based on the old non spec compliant getStats which has lots of things meant for both debugging and stats about the ongoing call, going the spec compliant route will make this less useful as a debugging tool. 

Correct me if I'm wrong but getStats is first and foremost meant for web applications and their developers using WebRTC, not debugging the internal state of WebRTC and thus when enforcing that all stats on webrtc-internals must be spec compliant, it looses value as a debugging tool.

IMHO webrtc-internals should be able to have non standard stats (perhaps from a lower level than getStats) and other logs that are useful to debug calls

I think we should create a separate page like webrtc-stats for spec compliant getStats graphs etc.

To clarify, there are things on webrtc-internals that indicate the state of webrtc (setLocalDescription etc), I was mainly talking about the stats.

Webrtc-internals needs some love!

The current webrtc-internals is a hack - it takes the nonstandard "ssrc" stat (which mixes track data and rtp data and more) and more or less graphs anything that looks like a number.

We need to change it in such a way that you can look at transport stats, track stats and other stats independently from each other (or together); the first part of that is transitioning to the right object model - which is the new stats.

We want to eventually strip out the old stats code altogether, but of course we can't do that while webrtc-internals uses it. (Not while most customers are using it either, for that matter)

Agree that there are stats that make sense to display in webrtc-internals when they're not shown in getStats - experimental stats and stats hidden behind an origin trial (when that happens) are examples. If they're generically useful, they should be standardized and returned.

Fippo's got an extension called "webrtc-externals" that shows many of the same things, based on (I think) the new getStats.

This for background.

getStats(), along with any other API exposed to the web platform, should be publicly documented and on a path towards standardization.

It is true that the legacy getStats() contains a lot of metrics that are not in standard and that some of them are useful, this is a PROBLEM, not a FEATURE. The reason legacy getStats() looks the way it does is it was wired up in such a way that it completely BYPASSED the Chrome release processes FOR YEARS. I've had to manually hunt people down based on git blame to figure out what a metric is doing (and sometimes when it comes to the details the answer is "I don't know") or if it is useful for applications and should be standardized (again, often "I don't know" or even in one case "This is useful" and you find out the implementation is "return 0;").

Now JavaScript applications (such as Hangouts) are depending on an API that we need to deprecate and remove. This is a problem for cross-browser compatibility, and there is a lot of wasting resources putting all your eggs in a legacy basket and then trying to get away from that (see above), we're digging a deeper pit for ourselves the more we postpone this work. The web is bigger than just Chrome.

It's on my OKRs this quarter to formalize the stats process, i.e. write up a document to guide people on how to proceed with adding stats, and to look into how we can make the process more efficient so that things don't get stuck in spec limbo. We must not continue to make the mistake of relying on non-compliant legacy APIs. When we have a working process I will ban anything other than "maintenance mode" for legacy getStats(), which I'm already half-doing.

If...
- There's a useful stat in legacy that's not in the spec and does not have something equivalent? Let's add it to the spec.
- There's a stat that is only useful for evaluating an experiment? Let's support Experimental Stats in Origin Trials (design doc WIP).
- There's a stat only useful for debugging? Put it behind a flag.
- There's a stat that is useful but implementation-specific? See if there is a way to generalize it, i.e. what are you really trying to determine based on the stat. In edge cases where this is not possible, let's add it to "provisional stats document" - a Google owned spec. This at least documents publicly what we're doing and if it gains traction other browsers can look at the definition and perhaps add it or something similar.
- There is debugging stats that we want in webrtc-internals but not in getStats()? I'd question why such a stat - demonstrated to be useful - shouldn't be standardized, but assuming this is the case: Let's wire it up so that it is only exposed in webrtc-internals and not in the public API.
- In other cases not listed above, and you don't want the stat standardized in any way, the answer is probably don't add it in the first place, and stop relying on it if already exists as a legacy "goog" stat.

Getting webrtc-internals to use spec-compliant getStats() should definitely be on the road map and it would signify a maturity of the new API. Deprecating legacy getStats() is necessary for incentive and progress.

  When the sun rises in the west and sets in the east.
  When the seas go dry and mountains blow in the wind like leaves.
  Then we will delete legacy getStats().

given the overall usefulness of webrtc-internals for developers I am in general disappointed with the almost complete lack of resources put into it.
It has been in maintenance mode since... jiayl switched teams in 2015?

I think the approach taken by webrtc-externals could allow removing large parts  of the functionality from chrome which would be great since it allows a different release cycle.

But I do not have the cycles to maintain webrtc-externals without any support.

actually before anything else there should be a linting step added.

Stats guidelines doc:
https://docs.google.com/document/d/1q1CJVUqJ6YW9NNRc0tENkLNny8AHrKZfqjy3SL89zjc/edit?usp=sharing

I think we should bump the priority on this one.