Handle reception of early media
Categories
(Core :: WebRTC, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: bwc, Assigned: dbaker)
References
(Blocks 1 open bug)
Details
Attachments
(7 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
This is likely to interact with bug 1004510. It is also possible that the spec or test is just broken here.
https://wpt.live/webrtc/rtp-stats-lifetime.https.html?interop-2026
|
Assignee | |
Comment 1•1 month ago
|
||
When a transceiver is bundled onto a transport that was already negotiated
by an earlier m-section, that transport's ICE/DTLS is already live, so
packets can arrive before this transceiver's own answer exists. Previously
we would not start receiving (or report inbound-rtp stats) until this
transceiver reached kJsepStateStable, so such early packets were dropped.
Add RTCRtpReceiver::CanTentativelyReceive(), which is true only for a
recvonly/sendrecv transceiver, offered locally, with no real negotiated
details yet, whose transport was inherited from an already-negotiated
bundle owner (JsepTransceiver::mTransport.mIce is only set by
FinalizeTransport() after a real prior negotiation, so this excludes a
transport that has never gone through ICE/DTLS). When true,
UpdateVideoConduit()/UpdateAudioConduit() configure the conduit from the
codecs we offered (via new RTCRtpTransceiver::PrototypeCodecsTo{Audio,
Video}CodecConfigs() helpers, mirroring the existing NegotiatedDetailsTo*
helpers but reading JsepTrack's own offered codecs instead of negotiated
ones), and UpdateConduit() ORs it into mReceiving alongside the existing
IsReceiving() check. currentDirection and getParameters() are untouched,
since those still come from IsReceiving()/GetNegotiatedDetails() alone.
PeerConnectionImpl::OnSetDescriptionSuccess already had a carve-out for
this bundled/local-offer case to prime the MediaPipelineFilter
(UpdateTransport()); this adds the matching UpdateConduit() call so the
conduit itself gets configured, not just the transport-level filter.
|
||
Updated•1 month ago
|
|
|
Assignee | |
Comment 2•1 month ago
|
||
Extend CanTentativelyReceive() to also apply when a transceiver that
was already negotiated is reoffered (e.g. setting the recv bit,
widening codecs), not just when it's never been negotiated at all.
Gate on having a pending local offer whose own recv-relevant content
actually changed (JsepSession::LocalOfferedRecvParamsChanged()), so an
unrelated, unchanged transceiver elsewhere in the bundle keeps using
its real negotiated details instead of getting reset on every reoffer.
Resolve the bundle group via the new
JsepSession::GetLocalBundleGroupLevels(), checking every member for a
prior negotiated round instead of just the offerer's suggested
transport owner, which JSEP can clear mid-reoffer and which the
answerer isn't required to honor anyway.
|
|
Assignee | |
Comment 3•1 month ago
|
||
Adds test_peerConnection_earlyMediaReoffer.html, covering reoffers that
set the recv bit, add a recv codec, add an RTP extension, add RTX, add
an rtcp-fb type, or add a new bundled m-section.
|
|
Assignee | |
Comment 4•1 month ago
|
||
RTCRtpReceiver::SyncToJsep() already applies the transceiver's
preferred codecs to the recv track via PopulateCodecs(). Do the same
for the send track in RTCRtpSender::SyncToJsep(), so the negotiation
accounting for what we send matches what setCodecPreferences()
actually restricted our own offer/answer to, instead of the full,
unrestricted codec set.
|
|
Assignee | |
Comment 5•1 month ago
|
||
The demux filter used GetNegotiatedDetails(), which is stale during a
pending offer, so a newly-restored extension (e.g. MID) wasn't
recognized until the real answer landed. Read the pending offer's own
extmap instead in that window.
|
|
Assignee | |
Comment 6•1 month ago
|
||
reofferAddsRtpExtension only has one transceiver, so it never proves an
extension is actually used to demux between candidates. Add
reofferRestoresMidDemuxing: 3 bundled recvonly transceivers, no SSRC
information at all, so receiving early media on the right one depends
entirely on the restored MID extension.
|
|
Assignee | |
Comment 7•1 month ago
|
||
GatherIfReady() unconditionally cleared the shared ICE-ctx operation
queue, which could also be holding an already-queued but not-yet-run
StartIceChecks.
Track the gathering request in its own slot so a newer one still
supersedes an older one without discarding unrelated queued
operations.
|
||
Comment 9•10 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ce0f8ab66b9d
https://hg.mozilla.org/mozilla-central/rev/42950592289c
https://hg.mozilla.org/mozilla-central/rev/73c57cfca8ab
https://hg.mozilla.org/mozilla-central/rev/f8f8b651d820
https://hg.mozilla.org/mozilla-central/rev/950142e0b1b3
https://hg.mozilla.org/mozilla-central/rev/46c8bcb47692
https://hg.mozilla.org/mozilla-central/rev/5d1169150368
https://hg.mozilla.org/mozilla-central/rev/7bf0964c8119
Description
•