New issue
Advanced search Search tips

Issue 774164 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



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 description

UserAgent: 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.
 
same-stream-sdp0.txt
3.2 KB View Download
same-stream-sdp1.txt
3.2 KB View Download
new-stream-sdp0.txt
3.2 KB View Download
new-stream-sdp1.txt
3.2 KB View Download

Comment 1 by bokan@chromium.org, Oct 13 2017

Components: -Blink Blink>WebRTC
Labels: Needs-Bisect Needs-Triage-M61

Comment 3 by guidou@chromium.org, Oct 16 2017

Components: -Blink>WebRTC Blink>WebRTC>PeerConnection
Owner: hbos@chromium.org
Status: Assigned (was: Unconfirmed)
hbos@: can you take a look at this?
Labels: TE-NeedsTriageFromMTV
Adding the label 'TE-NeedsTriageFromMTV' as the issue requires remote browser to triage.

Comment 5 by hbos@chromium.org, Oct 16 2017

Cc: hbos@chromium.org ajha@chromium.org
 Issue 773613  has been merged into this issue.

Comment 6 by hbos@chromium.org, Oct 16 2017

Status: Fixed (was: Assigned)
This should be fixed by https://chromium-review.googlesource.com/c/657639/.

Comment 7 by hbos@chromium.org, Oct 16 2017

Labels: -TE-NeedsTriageFromMTV -Needs-Triage-M61 M-64

Comment 8 by kher...@gmail.com, Oct 16 2017

Is it going to be trapped behind the experimental web platform features flag?

Comment 9 by hbos@chromium.org, 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. :) 

Comment 10 by kher...@gmail.com, 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.

Comment 11 by hbos@chromium.org, Oct 18 2017

You won't see it until stable 64, but it's already in Canary.

Sign in to add a comment