Invalid offer SDP after disabling codec(s) on a transceiver with `setCodecPreferences`
Categories
(Core :: WebRTC: Signaling, defect)
Tracking
()
People
(Reporter: windicted, Assigned: dbaker)
References
Details
Steps to reproduce:
If we disable one or a few of the codecs by calling setCodecPreferences method on a RTCRtpTransceiver object, then the subsequent call of createOffer method on RTCPeerConnection object would produce an SDP which includes rtcp-fb attributes referencing the payload(s) which correspond to the disabled codec(s).
Here is a short code snippet which you can use to reproduce the issue (you can copy-past it to the browser's console):
let pc = new RTCPeerConnection();
let t = pc.addTransceiver("video");
// Disable VP8 codec/payload for the transceiver
t.setCodecPreferences(RTCRtpSender.getCapabilities("video").codecs.filter(codec => codec.mimeType !== "video/VP8"));
let offer = await pc.createOffer();
console.log("Offer SDP:\n" + offer.sdp);
After running the snippet you will see that offer SDP contains rtcp-fb attributes referencing the disabled VP8 payload:
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
Actual results:
We got an SDP which contains rtcp-fb attributes referencing the disabled payloads.
Expected results:
We got an SDP which contains rtcp-fb attributes referencing the enabled payloads only.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Signaling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
Thank you for your report! I can confirm the behavior, and that those rtcp-fb lines should be omitted. We should remove those when the payload type is no longer used in the offer. Dan, I'll move this to your queue.
|
||
Comment 4•1 year ago
|
||
Making sure we don't lose track of the wrinkle described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1953506#c1
In brief, rtcp-fb is for both directions, which does not mesh at all with asymmetric payload types. I think we ought to try using a=rtcp-fb:* <value> instead of having pt specific attrs. If that interops ok, that solves this issue and the asymmetric pt one as well.
|
||
Comment 5•1 year ago
|
||
Well, this bug only mentions the existence of the a=rtcp-fb field, but in reality, Firefox also creates an unnecessary a=fmtp. I originally mentioned this in 1953506, but since it was closed as a duplicate, I am bringing it up here.
|
Assignee | |
Comment 6•1 year ago
|
||
I think both of those were overlooked when I implemented setCodecPreferences and will resolve.
|
||
Comment 7•1 year ago
|
||
A similar issue occurs when Firefox first creates an offer and then when adding another track (eg. screen sharing) where a new offer is created. If setCodecPreferences() is used on the transceiver to change the codec priority (like putting all H264 codecs first), since the fmt numbers are dynamic, the m= line for mid=1 as well as the a=fmtp and rtpmap lines can change. What I've observed is that when this happens, it seems that the rtcp-fb lines will retain some of the old entries, resulting in rtcp-fb lines that does not exist in the m= line or have corresponding rtpmap. Goolge Chrome has quite strict SDP parsing and if this offer is sent to Chrome, it will throw an exception if it receives any rtcp-fb lines without corresponding fmt in m= line or rtpmap, thus fails with error:
OperationError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to parse SessionDescription. Failed to parse codecs correctly.
See the comment in the Chromium SDP parser code here: https://chromium.googlesource.com/external/webrtc/+/master/pc/webrtc_sdp.cc#3354
Description
•