murillo128
commented
3 years ago note that cbr useinbandfec and usedtx usage on SDP only expresses that the decoder on the receiver prefers cbr, fec or dtx, but in no way controls what the encoder on any of both sides must use:
cbr: specifies if the decoder prefers the use of a constant bitrate
versus a variable bitrate. Possible values are 1 and 0, where 1
specifies constant bitrate, and 0 specifies variable bitrate. If
no value is specified, the default is 0 (vbr). When cbr is 1, the
maximum average bitrate can still change, e.g., to adapt to
changing network conditions.
useinbandfec: specifies that the decoder has the capability to take
advantage of the Opus in-band FEC. Possible values are 1 and 0.
Providing 0 when FEC cannot be used on the receiving side is
RECOMMENDED. If no value is specified, useinbandfec is assumed to
be 0. This parameter is only a preference, and the receiver MUST
be able to process packets that include FEC information, even if
it means the FEC part is discarded.
usedtx: specifies if the decoder prefers the use of DTX. Possible
values are 1 and 0. If no value is specified, the default is 0.
So the SDP mungling that is allowed by current implementation is just a hack due to the lack of APIs and in no way is backed up by any standard.
Moved from https://github.com/w3c/webrtc-pc/issues/2301
Do we need RTCCbrStatus for opus cbr? The description would be somewhat similar to the dtx one (which is marked as at-risk?!)
Since @aboba asked: even without an API it is still possible to munge the SDP to enable this. This is second form munging, i.e. on the signaling channel before setRemoteDescription. Like for dtx we don't have an actual API to tell the sender to create an offer and negotiate it.