RTCP SDES/CNAME is blank (0-length) for WebRTC audio stream
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Tracking
()
People
(Reporter: kevin, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Steps to reproduce:
Initiated a WebRTC session with audio (Opus) and video (VP8).
Actual results:
In the SDP, the audio and video both indicate the CNAME is a guid (same used for both, as expected). In the RTCP packets for each stream, I received this GUID in the SDES/CNAME field for the video stream, but in the RTCP packets for the RTCP stream, there is an SDES/CNAME field, but it is an empty, zero-length string.
Expected results:
The RTCP for both the audio stream and the video stream should be using the same SDES/CNAME string.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Byron, can you help triage this? Is it related to bug 1584318?
Comment 3•3 years ago
|
||
So, the JSEP engine is definitely passing this down to libwebrtc (right where we set the mid), I wonder why libwebrtc is ignoring it?
Encoding an empty string for the CNAME is obviously wrong, although it seems to have not been a huge problem in practice. I think we wait until bug 1654112 lands, and revisit.
So, the JSEP engine is definitely passing this down to libwebrtc (right where we set the mid), I wonder why libwebrtc is ignoring it?
I think I left out a key detail in the original report. When doing a typical audio and video WebRTC session, the RTCP packets for the video stream contain the correct SDES/CNAME, but the RTCP packets for the >>AUDIO<< stream contain the blank SDES/CNAME. So, I think a more interesting question would be why is libwebrtc ignoring it for audio streams and not video streams?
Comment 5•3 years ago
|
||
Interesting. I know that libwebrtc's API surface is very different for audio, so I guess that a difference like this is not particularly surprising.
Comment 6•3 years ago
|
||
Do we have a binary with the newer libwebrtc that the reporter can try out?
Comment 7•3 years ago
|
||
Here is the last large build push I did: https://treeherder.mozilla.org/jobs?repo=try&revision=9d3cf26ac13b4697d0186d8d5c09d0c62e1310c9&selectedTaskRun=K-zABCP1SmWASuwPjDfn5g.0
I have not tried installing on windows from a try push, so I can't lend additional advice.
Comment 8•3 years ago
|
||
Could you try to reproduce this with the binary here?
Comment 9•3 years ago
|
||
Closing as inactive, let us know if you can reproduce with a Firefox Nightly build, that has received significant changes in the area.
Description
•