commit | 4ea80f35f1b6a74fcba182a1d769abe94b8513ca | [log] [tgz] |
---|---|---|
author | Henrik Boström <hbos@webrtc.org> | Wed Jun 09 08:29:50 2021 |
committer | WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Jun 09 09:25:59 2021 |
tree | 7a9d7700cae55dae75e3dc5a1345d642ce28307b | |
parent | 33e75bb874cca556c657be70a7ed9892295d66a0 [diff] |
Disable PT based demuxing if MID header extension is present. We want to turn off PT based demux because SSRC-based endpoints that send media prematurely (which is a popular non-standard behavior still heavily in use) can otherwise get incorrect mappings and unsignalled ssrc issues because of the PT demux path. This CL disables PT based demuxing when the MID header extension is present on all m= sections in the SDP for that kind (audio/video), not caring if it was in the offer or answer. However if PT demuxing has been used in the past then it is always allowed. This ensures PT is off by default but that either offer or answer can enable PT and once it has been on it is also possible to get early media with PT. - Want PT-based demux? The MID header extension has to be removed in either the offer or the answer. Follow-up O/As allow PT demuxing if possible. - Want to use MID or SSRC demuxing? Great, you don't need PT-based demux and won't mind that we turned it off for you. The reason for disabling PT demux at offer time (if MID is present) instead of waiting for the SDP answer is because by the time the SDP answer arrives, early media could have triggered PT demux and caused incorrect mappings. The safe thing is to assume a spec-compliant endpoint until proven otherwise. However if PT demux is ever enabled, then from that point on we always allow PT-based demux in follow-up O/A exchanges. This ensures we don't drop packets in follow-up exchanges. The fact that PT-based demux is disabled during the initial offer should not matter because before the initial O/A exchange we don't have fingerprints. This change only affects Unified Plan and bundled groups. Existing test coverage ensuring we do not break legacy endpoints: [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/pc/peer_connection_integrationtest.cc;l=1156 [2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/rtp-demuxing.html;l=59 UnsignaledStreamTest is also updated to test the interesting setups. A kill-switch is added in case we want to disable this change. Bug: webrtc:12814 Change-Id: I807a82a543325753633aaef698e06cb4c9dfebaa Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221101 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34251}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
See here for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.