New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 759536 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
█ krajshree@chromium.org
█ emadomara@chromium.org
webrtc-network-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug


Previous locations:
webrtc:8152


Sign in to add a comment

Resuming video fails on Windows when VirtualBox is installed

Reported by ebun...@cafex.com, Aug 24 2017 
What steps will reproduce the problem?
1. Run Chrome Beta (61) or Dev (62) on a Windows machine with VirtualBox installed (no instances need to be running, VirtualBox simply needs to be installed so that the network interface is up)
2. Make a call from Chrome Beta or Dev with audio and video.
3. Create a new offer with audio and video inactive (if calling to another Chrome then the test needs to be mangled to the other chrome is set to something other than inactive due to an old bug which has never been fixed).
4. Renegotiate again with audio and video set to sendrecv.

What is the expected result?
Audio and video resumes in both direction.

What do you see instead?
Video does not render on the side which held.

Our software is a gateway so if calling to another Chrome it (receiving the hold offer) will see sendonly in this case and our gateway will stream hold media to work around the bug where receiving an offer with inactive m-lines means media cannot resume. This does not happen on a Linux machine with VirtualBox installed, and does not happen on windows without VirtualBox.

I eliminated our software with a sample app that exhibits the same behaviour which I have attached. Due to the receiving inactive m-lines bug there are two buttons to allow testing of the hold and resume which makes up the remote answers so the remote end does not receive and offer with inactive m-lines. The steps for use of it are:
1 - On Chrome A (Beta or Dev) click call and copy SDP from the left hand text box.
2 - On browser B (I've only tested with Chrome) paste SDP in the right hand text box and click "Apply Remote SDP" then copy SDP from left text box.
3 - On Chrome A paste SDP in right hand text box and click "Apply Remote SDP". Audio and video should now flow.
4 - Click "Mangled Hold". Audio and video will stop flowing and the remote video on A will go black.
5 - Click "Mangled Resume". On Windows machines without VirtualBox, and on Linux, audio and video will resume. On Windows with VitualBox installed video will not resume.

I noticed the onTrack callback gets some events without a stream array on machines with the problem, and after resume the video is resized to 2x2. I have not been able to check if this affects all Windows machines that have non-routable interfaces, or if it just something about the VirtualBox interface. This works in Chrome 60 and earlier on all machines.



What version of the product are you using? On what operating system?


Please provide any additional information below.
PeerConnection_new.html
9.4 KB View Download
adapter_3.2.6.js
170 KB View Download

Comment 1 by ebun...@cafex.com, Aug 24 2017 

Annoyingly The mangled hold and resume code in that sample page appears to not reliably work in Chrome dev (and possibly beta) and linux either. It was working, but doing some more tests to see if I could find a workaround it stopped doing so. It works fine in Chrome 60. This means the longer method has to be done to do the appropriate negotiation without offering inactive. One the call is setup (after step 3 from the original description of the use of the page) you need to:
1 - Change the drop downs on the caller (Chrome A) from sendrecv to inactive.
2 - Click renegotiate and copy the SDP from the left hand text box.
3 - On the callee (Chrome B) paste the SDP in the right hand text box, change both appearances of "a=inactive" to "a=recvonly", change both drop downs to sendonly, then click "Apply remote sdp".
4 - Copy the SDP from the left hand text box.
5 - Paste the SDP in the right hand text box on Chrome A and change both appearances on "a=sendonly" to "a=inactive", then click "apply remote SDP". The remote video will now have stopped on both endpoints.
6 - On A change both dropdowns from inactive to sendrecv.
7 - Click renegotiate and copy the SDP from the left hand text box.
8 - On Chrome B paste the SDP in the right hand text box, change both drop downs to sendrecv, then click "apply remote SDP".
9 - Copy the SDP from the left hand text box.
10 - Paste the SDP in the right hand text box on Chrome A and click "apply remote SDP"

Only on Windows with VirtualBox (or possibly some other non-routable interface) with video not resume.

Comment 2 by ebun...@cafex.com, Aug 25 2017 

Somehow I managed to miss the trigger behind this. I hadn't realised the laptop without virtual box installed only had one network card (no functioning wired NIC). It turned out that any machine with more than one network interface causes this, which suddenly makes it a major issue for us.

Comment 3 by ebun...@cafex.com, Aug 25 2017 

Our SV department apparently had seen this with Beta (61) and Dev (62), but I had only tested with Dev, and now it seems this issue is only affecting Dev, not Beta. I assume our SV department saw something different with Beta which I'll track down separately. The mangle SDP function on my test page not functioning on either beta or dev, but working on stable threw me off, and makes me suspect a compound of issues resulting in the dev behaviour.

Comment 4 by kjellander@chromium.org, Aug 28 2017

Project: chromium
Moved issue webrtc:8152 to now be  issue chromium:759536 .

Comment 5 by kjellander@chromium.org, Aug 28 2017

Components: Blink>WebRTC>PeerConnection
Labels: OS-Windows

Comment 6 by guidou@chromium.org, Aug 29 2017

Components: -Blink>WebRTC>PeerConnection Blink>WebRTC>Network

Comment 7 by ebun...@cafex.com, Sep 1 2017 

This appears to now be happening on all OSs, The change being a newer release on non-windows. On Linux it was working with 62.0.3178, but updating to 62.0.3198 broke it.

Comment 8 by ebun...@cafex.com, Sep 1 2017 

This seems to now be working in the very 62.0.3202

Comment 9 by krajshree@chromium.org, Sep 12 2017

Cc: krajshree@chromium.org
Labels: Needs-Milestone Needs-Feedback
ebunyan@ - Could you please confirm if the issue can be closed as per comment #8.

Thanks...!!

Comment 10 by ebun...@cafex.com, Sep 12 2017 

Yes, it works on the 3202 release on both Windows and Linux so can be closed.

Thanks.
Project Member

Comment 11 by sheriffbot@chromium.org, Sep 12 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 12 by deadbeef@chromium.org, Sep 12 2017

Status: WontFix (was: Unconfirmed)
Closing as "not reproducible".
►

Sign in to add a comment