rtcp-fb is not negotiated when asymmetric payload types are used
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox96 | --- | fixed |
People
(Reporter: bwc, Assigned: bwc)
Details
Attachments
(2 files)
Passing mDefaultPt on these lines does not work when there is payload-type asymmetry:
mDefaultPt is the payload type that is in our SDP (since this is the receive codec description), but we are examining the remote description, which may have a different payload type for the same thing. We should instead be passing the remote payload type that matches the current codec.
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
Remote rtcp-fb is something that the receive codec negotiates, and the pt of
the receive codec can be different than the pt in the remote SDP. So, we need
to first determine which remote pt corresponds to the receive codec, and then
look for something that matches it.
Depends on D132827
Assignee | ||
Comment 4•2 years ago
|
||
Try looks good.
Pushed by bcampen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0d3b98f5a71c Test-case for bug. r=mjf https://hg.mozilla.org/integration/autoland/rev/147a02da501d Compare pt in remote rtcp-fb against remote pt, not local pt. r=mjf
Comment 6•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0d3b98f5a71c
https://hg.mozilla.org/mozilla-central/rev/147a02da501d
Description
•