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.
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.
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.