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.