Closed Bug 1718798 Opened 3 years ago Closed 3 years ago

RTCP SDES/CNAME is blank (0-length) for WebRTC audio stream

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Firefox 89
defect

Tracking

()

RESOLVED INACTIVE

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.

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.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

Byron, can you help triage this? Is it related to bug 1584318?

Flags: needinfo?(docfaraday)

So, the JSEP engine is definitely passing this down to libwebrtc (right where we set the mid), I wonder why libwebrtc is ignoring it?

https://searchfox.org/mozilla-central/rev/9c9f2f85d00aef1943cb521ac95c72bae932ebc5/dom/media/webrtc/jsapi/TransceiverImpl.cpp#248

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.

Severity: -- → S3
Depends on: 1654112
Flags: needinfo?(docfaraday)
Priority: -- → P3

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?

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.

Do we have a binary with the newer libwebrtc that the reporter can try out?

Flags: needinfo?(na-g)
Flags: needinfo?(mfroman)

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.

Flags: needinfo?(na-g)
Flags: needinfo?(mfroman)

Closing as inactive, let us know if you can reproduce with a Firefox Nightly build, that has received significant changes in the area.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(kevin)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.