Split getContributingSources into two methods, for CSRCs and SSRCs.

[taylor-b]

Fixes #1101.

There's now getContributingSources and getSynchronizationSources,
which return RTCRtpContributingSources and
RTCRtpSynchronizationSources, respectively. These interfaces are
slightly different, in that only RTCRtpSynchronizationSource has
voiceActivityFlag, and non-nullable audioLevel.

[taylor-b]

I liked Harald's suggestion to just call it getSsrcs, but that seemed inconsistent with getContributingSources (which could just as easily be getCsrcs).

Another naming thing I don't like is that the CSRC or SSRC identifier is called source, as opposed to just ssrc/csrc, or even identifier. Is it too late to change this?

Naming gripes aside, I don't think there are any real issues with this.

[henbos]

nit: weird line-break

[taylor-b]

Did this to make the diff cleaner, will rely on auto-formatting tool at some point in the future.

[henbos]

SSRC and CSRC numbers are independent of each other? You could have one RTP packet (ssrc:1, csrc:[1,...]) and then another one (ssrc:2, csrc:[1,...])? Does it make sense to have a reference to the most recent RTCRtpSynchronizationSource from an RTCRtpContributingSource?

Hmm actually that could be misleading because the SSRC could be updated and so a CSRC's SSRC could represent a different state and time than the CSRC. But what about a source id? Or is this not useful?

It would seem the SSRC's audioLevel would be enough (CSRC's audioLevel being a copy) if it wasn't for the reference representing a different state and time. Copy needed to have audioLevel for that state/time.

[taylor-b]

You could have one RTP packet (ssrc:1, csrc:[1,...]) and then another one (ssrc:2, csrc:[1,...])?

I don't think this is a scenario we need to worry about. Technically the IDs might share the same space ("CSRC identifier" is just shorthand for "SSRC identifier of the CSRC") but I can't imagine how a CSRC could also be a primary SSRC in the same session.

The intention is basically that RTCRtpContributingSource represents "information from CSRC list and RFC 6465 extension" and RTCRtpSynchronizationSource represents "information from SSRC field and RFC 6464 extension".

[henbos]

My bad, I wasn't thinking about CSRC and SSRC namespaces colliding but rather if different SSRCs transport the same CSRCs at different points in time. I'll update the example to:

"You could have one RTP packet (ssrc:1, csrc:[10,...]) and then another one (ssrc:2, csrc:[10,...])?"

Would the CSRC information be copies of the latest SSRC packet information that contained that CSRC?

[taylor-b]

I understand your question now, sorry for my mixup.

Anyway: I was thinking of each RTCRtpContributingSource object as being tied to a particular RTCRtpReceiver. That seems more sensible given how the API is expected to be used.

So, if the same source is contributing to two different streams, I'd suggest having two different RTCRtpContributingSource objects, one for each stream it's contributing to.

If the application really does need to know "which stream did this source most recently contribute to?," it still can do this by comparing timestamps.

[henbos]

Yes that sounds good to me.

[henbos]

Is there a significant cost to making computing audioLevel non-optional per RTP packet?

[taylor-b]

Hopefully not, since it's already computed for stats. Though I'm not changing that in this PR, just moving it around.

[henbos]

Chrome having shipped (M59, in Canary) with names getContributingSources and RTCRtpContributingSource.source I don't think it is worth changing the name.

[stefhak]

Decided to merge at the May 2nd VI.