Marking the above issue as Untriaged as this is a feature request.

Dev team will take a call on the above request.


Thank you!

Lack of support for CSRC events will require the app to create expensive workarounds involving transmitting this information on the signalling channel. We are currently debating whether to implement this workaround or wait for Chrome to implement this feature. It will be helpful if you can give us some idea on when we can expect this feature to light up. 

If you need a predictable timeline, I recommend doing the workaround.

The feature is on the list of features to support, but since it only affects interoperation with MCUs (meshes, SFUs and transport relays are not affected, since they don't use contributing sources), it has not received a high priority so far, and we have not committed to a schedule for implementation.

The workaround is not very straight forward as signalling channel is not real time and the CSRC information can get stale by the time it reaches the client. 
Workaround is also costly as it involves changing multiple entities in the path. We will start the implementation of the work around but it will be great if you can give this ask a higher priority.

Is it normal for the timestamps to be of an integer type, not a decimal? (see attached screenshot, the last value is from performance.now())

How to compare these timestamps to know how many seconds/milliseconds have passed? From WebRTC 1.0 documentation, the type DOMHighResTimeStamp documentation leads to https://www.w3.org/TR/hr-time-2/ which suggests that the value should be of decimal type, but as you can see on the screenshot, it comes as an integer, and of a completely different scale.

Deleted: sources.PNG 28.4 KB

	sources.PNG 28.4 KB View Download

DOMHighResTimeStamp is in units of milliseconds, and we happen to be using a clock value with only millisecond precision, so it's always an integer (for now).

This timestamp is not guaranteed to be in units relative to "performance.now" or even since Jan 1 1970, it's only guaranteed to use "a local clock". So I think we're standards-compliant here. You can compare the times to see, for example, that audio was received from CSRC 1 180ms more recently than CSRC 8.

I see. How does one determine how much time has passed since this timestamp? I understand it's a local timestamp, but relative to what then? If I want to avoid a nasty unreliable hack for comparing it, it limits its usage quite a lot if I don't know how much time has passed.

Could you explain more about what you're trying to do? Is it not enough to assume that the most recent timestamp represents a packet that arrived pretty recently? I can try raising the issue with the WebRTC working group, but they're pretty resistant to changes at this point, so the more information I have to make a case the better.

What I'm trying to do is make it more reactive - when a participant stops talking, at the moment, it's kept in the list of contributing sources for another 10 seconds (goal is to reduce that). I'd like to compare the timestamp to a current value, to see how many msec ago the source was contributing (so instead of 10 seconds, it can be easily and reliably configured to something lower), which is hard/hacky to do without knowing the reference point of the timestamp (getting current value of the timestamp). I'd like to treat each contributing source individually, not compare the timestamps between each other.

These 2 places are the only references in the WebRTC spec to "clock". How much effort would it take to make these clocks return the same clock as performance.now() (and make the corresponding change to the spec)?

alternatively, make it equivalent with the GetStats() timestamp, which is the DOMHighResTimeStamp version of unix gettimeofday(2).

RTCRtpContributingSources has already landed, but the audioLevel field is missing.
Assigning to hbos@ to complete this.

This bug is a bit old. The spec has changed, it's better to split this up:
- getContributingSources(): Already shipped a long time ago,  https://crbug.com/703122 .
- getSynchronizationSources(): Started,  https://crbug.com/883287 .
- RTCRtpContributingSource.audioLevel: Filed https://crbug.com/883288.
- RTCRtpSynchronizationSource.voiceActivityFlag: Filed https://crbug.com/883289.

I'm going to close this as a duplicate. Do look at the other bugs for updates on the related bugs.