Intent to implement: RTCRtpSendParameters.transactionId

[Byron Campen]

TL;DR: Currently, Firefox does not enforce the transactionId mechanic in RTCRtpSender.setParameters as specified in webrtc-pc. This means that right now, content code is able to call setParameters without calling getParameters first. However, once transactionId is implemented, this type of code will no longer work.

Spec summary:
https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-setparameters
https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-getparameters

webrtc-pc specifies that RTCRtpSender.setParameters and RTCRtpSender.getParameters use RTCRtpSendParameters.transactionId to implement a transaction mechanism. The idea is that content calls getParameters to get the current parameters, which will contain a new unique transactionId. Content then modifies those parameters, and calls setParameters with the modified parameters, which will include the unique transactionId. If the transactionId does not match the value from the most recent call to getParameters, the setParameters call fails with an InvalidModificationError.

Current state:
Currently, our implementation of RTCRtpSender.setParameters does not enforce this transaction mechanic, which allows setParameters to be called with an entirely content-created RTCRtpSendParameters. Any content code that does this will stop working.

Best regards,
Byron Campen

[Byron Campen]

   Bug 1401592 is now in the home stretch, which means these changes will be landing soon. Since these changes seem to break numerous web-conferencing services, these changes will be landing with a compatibility mode that lets a handful of types of error slide, and sends warnings to the JS console instead. These errors include:

- Calling RTCRtpSender.setParameters() when there is not a recent (ie; in the same crank of the event loop) call to RTCRtpSender.getParameters().

- Calling RTCRtpSender.setParameters() with an RTCRtpSendParameters with no transactionId (many web-conferencing services do this).

- Calling RTCRtpSender.setParameters() with a stale RTCRtpSendParameters.transactionId (should be uncommon, but could still happen).

- Calling RTCRtpSender.setParameters() with an RTCRtpSendParameters.encodings array of a different size than currently configured (many web-conferencing services do this).

- Calling RTCRtpSender.setParameters() with an RTCRtpSendParameters.encodings containing an encoding whose rid is different than currently configured (should be uncommon).

   For services that have special handling of setParameters() for Firefox, I strongly recommend that you avoid User-Agent sniffing, and instead use feature detection, based on support for RTCRtpTransceiverInit.sendEncodings (which bug 1401592 adds). An example of this can be found in the adapter.js polyfill:

https://github.com/webrtcHacks/adapter/blob/b4d1e734381e1034126c489b183c88691edf7b1c/src/js/firefox/firefox_shim.js#L221

   Once bug 1401592 lands, we will be monitoring glean to see how often this compatibility mode is letting these errors slide, and will gradually phase out the use of this compatibility layer based on this data. Because this change brings us roughly in line with what other browsers do, I do not anticipate that web conferencing services will have much difficulty adjusting to the new behavior.

Best regards,

Byron Campen

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/4d0b74dc-0c30-4e9d-a9bb-47236743d5c7n%40mozilla.org.