Issue metadata
Sign in to add a comment
|
WebRTC MediaStreamTrack not created after renegotiation when remote peer adds track to existing stream
Reported by
kher...@gmail.com,
Oct 12 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 1. Have a Chrome instance in an active WebRTC session 2. Add a track to the remote browser (using the existing stream) and initiate a renegotiation What is the expected behavior? The new track should appear in the remote stream's track list (`pc.getRemoteStreams()[0]`) What went wrong? No new track is added to the remote stream, or it doesn't appear accessible in any way. The way I'm performing renegotiation works Chrome --> Firefox or Firefox <--> Firefox, but never when Chrome is on the receiving end of the new track. Did this work before? Yes 60 Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 27.0 r0 This is potentially related to #773613. Chrome seems to be ignoring tracks associated with an SSRC identifier it has already seen. As a workaround, I am creating an entirely new stream to associate with the peer that contains the existing tracks and the newly added ones. I've attached SDP messages from two scenarios: The first case has the same stream used across renegotiations (and fails to create new tracks), and the other creates a new stream before renegotiating. SDP0 is from the initial negotiation where one audio track and one video track are present. In SDP1, a video track is added after having been removed since SDP0 (with ICE candidates omitted). I recommend running a diff of SDP0 and SDP1 for each of the cases to highlight exactly what's changed across the two scenarios.
,
Oct 16 2017
,
Oct 16 2017
hbos@: can you take a look at this?
,
Oct 16 2017
Adding the label 'TE-NeedsTriageFromMTV' as the issue requires remote browser to triage.
,
Oct 16 2017
,
Oct 16 2017
This should be fixed by https://chromium-review.googlesource.com/c/657639/.
,
Oct 16 2017
,
Oct 16 2017
Is it going to be trapped behind the experimental web platform features flag?
,
Oct 16 2017
No, addTrack()/ontrack etc APIs are behind flags but the track-based plumbing affects existing APIs to the extent that this bug is fixed and other behavior should remain the same. :)
,
Oct 17 2017
Thanks! Should I be seeing this working in 62 stable at some point, or will I have to wait until 63 is out? Sorry, I'm not familiar with the release process.
,
Oct 18 2017
You won't see it until stable 64, but it's already in Canary. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by bokan@chromium.org
, Oct 13 2017