[webrtc-stats] Should we move track/sender/receiver to the obsolete section? (#479)

henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== Should we move track/sender/receiver to the obsolete section? ==
After moving everything significant from `track`/`sender`/`receiver` to `outbound-rtp` and `inbound-rtp` there is little use for track attachment stats, or even sender/receiver stats.

```
track/sender
  // From RTC[Video/Video]SenderStats:
  mediaSourceId
  // No members are defined in RTC[Audio/Video]HandlerStats.
  // From RTCMediaHandlerStats:
  trackIdentifier
  remoteSource
  ended
  kind
  priority

track/receiver
  // No members are defined in RTC[Audio/Video][Receiver/Handler]Stats.
  // From RTCMediaHandlerStats:
  trackIdentifier
  remoteSource
  ended
  kind
  priority
```

"mediaSourceId", "trackIdentifier" and "kind" already exists on `outbound-rtp` and `inbound-rtp`, these are not needed.

Sender-side: "ended" should probably move to `media-source` since this is a stat about the local track.
Receiver-side: "ended" should perhaps move to `inbound-rtp`, though in that case it would be more elegant to define it to reflect that the RTP stream has terminated, it should be equivalent.

"priority" is a feature at risk and probably doesn't hurt to be removed, but if we want to keep it then perhaps it should be added to the parameters stats proposed in #398.

"remoteSource" is only needed to be able to tell a sending `track` from a receiving `track` and is not needed for `sender` or `receiver` or `outbound-rtp` or `inbound-rtp`, i.e. this is not an argument for keeping track attachment stats.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/479 using your GitHub account

Received on Thursday, 29 August 2019 16:21:20 UTC