07563732f6
This can happen with the following sequence of API calls: 1) AddTrack(track) + offer/answer 2) RemoveTrack(track's sender) + offer/answer 3) AddTrack(same track) Since the first transceiver had already been used to send, it will not get re-used by the second call to AddTrack. Another RtpSender will be created with its ID = the track ID. But the code hits a DCHECK when CreateOffer is later called since both m= sections will offer the same track ID component of the MSID. The fix implemented here is to randomly generate a sender ID if there is already an RtpSender with the track's ID. Bug: webrtc:8734 Change-Id: Ic2dda23d66e364e77ff7505e1c37e53105a17dae Reviewed-on: https://webrtc-review.googlesource.com/84249 Commit-Queue: Steve Anton <steveanton@webrtc.org> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#23748}
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.
Development
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.
More info
- Official web site: http://www.webrtc.org
- Master source code repo: https://webrtc.googlesource.com/src
- Samples and reference apps: https://github.com/webrtc
- Mailing list: http://groups.google.com/group/discuss-webrtc
- Continuous build: http://build.chromium.org/p/client.webrtc
- Coding style guide
- Code of conduct