[webrtc-pc] `ssrc` in `RTCRtpEncodingParameters` is inconsistent with ORTC

taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc:

== `ssrc` in `RTCRtpEncodingParameters` is inconsistent with ORTC ==
My assumption is that `sender.getParameters` will return the SSRC identifier that's currently being used for sending. It's described as:

> The SSRC of the RTP source stream of this encoding (non-RTX, non-FEC RTP stream).

However, in ORTC it's a bit more complex, and an unset `ssrc` has a special meaning:

> If ssrc is unset in a RTCRtpEncodingParameters object passed to the send() method, the browser will choose, and the chosen value is not reflected in RTCRtpEncodingParameters.ssrc. If the browser chooses the ssrc, it may change it due to a collision without firing an RTCSsrcConflictEvent. If ssrc is set in an RTCRtpEncodingParameters object passed to the send() method and an SSRC conflict is detected within the RTP session, then an RTCSsrcConflictEvent is fired (see Section 5.4).

So basically: when `ssrc` is set, the application must explicitly handle SSRC conflicts by listening to an event. But when it's unset, it's like a wildcard, and can change automatically due to SSRC conflicts.

WebRTC 1.0 always behaves in the latter way. So, if the ORTC API were mapped directly to WebRTC, the `ssrc` field would always be unset. Does WebRTC really need to expose the current SSRC here? What is it expected to be used for?

Also, one very corner-casey problem that could occur if `getParameters` returns the current SSRC:

1. `getParameters` called, returns SSRC A.
2. SSRC conflict suddenly occurs, it's changed to SSRC B.
3. `setParameters` called with modified parameters. Fails with `InvalidModificationError` since it's interpreted as trying to change the SSRC from B to A.

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

Received on Monday, 8 May 2017 00:00:42 UTC