Asymmetric payload type negotiation is still not working quite right when we are the offerer
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: bwc, Assigned: bwc)
Details
Attachments
(2 files)
When an answer contains an asymmetric payload type, we attempt to remember it so we can put it in reoffers:
Unfortunately, this does not always work appropriately. If we are the offerer, the payload type is updated for the send track only (because the answerer is not allowed to override our recv track's payload type on that negotiation).
This means that for the recv track, the prototype codec is not updated, leaving the send/recv codecs out of sync with one another. I think we need to be updating the prototype codec's payload type to match |fmt|, not |clone->mDefaultPt|.
When these are out of sync, reoffers will use the old payload type in the rtpmap/m-line, but we will observe the new payload type in fmtp if the send track has format params (since the send track has switched over to the new payload type).
| Assignee | ||
Comment 1•5 years ago
|
||
I've observed this on MS Teams, and it may impact interop there.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 2•5 years ago
•
|
||
| Assignee | ||
Comment 3•5 years ago
•
|
||
| Assignee | ||
Comment 4•5 years ago
|
||
| Assignee | ||
Comment 5•5 years ago
|
||
Depends on D114039
| Assignee | ||
Comment 6•5 years ago
|
||
Try looks fine.
Comment 8•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/1678b35bed45
https://hg.mozilla.org/mozilla-central/rev/a0f39c1b8c5d
Description
•