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

Issue 741224 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue webrtc:7844
Owner: ----
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression in ICE Checking timeout with multiple network interfaces

Reported by warren.m...@gmail.com, Jul 12 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.50 Safari/537.36

Steps to reproduce the problem:
1. Start peerconnection to media server from a PC with multiple active network interfaces or VPN installed (with code that does not have any ICE Checking Timeout implemented) 
2. Ice checking times out at 40 seconds
3. Connection proceeds but other code has given up expecting sub 15 seconds call connection timing.

What is the expected behavior?
With Chrome 59 stable release and previous versions for over a year, ice checking completes almost immediately on the same PC with same active network interfaces.

What went wrong?
This seems like a regression in Beta 60 to previously reported and resolved issues with multiple network interfaces. 
Installing the WebRTC Network Limiter and configuring to: "Use only my default public IP address" restores the timing behaviour to similar to what we see in 59 and previous for at least 18 months.

Did this work before? Yes Chrome 59 stable

Does this work in other browsers? N/A

Chrome version: 60.0.3112.50  Channel: beta
OS Version: 10.0
Flash Version:
 
I have just tested with IPv6 active on the PC and this induces the same behaviour regardless of whether googIPv6: false is set on the connection. 


 Issue 741223  has been merged into this issue.
Labels: TE-NeedsTriageHelp
This issue seems to be out of TE-scope. Hence, adding label TE-NeedsTriageHelp for further investigation.

Thanks!

Comment 4 by guidou@chromium.org, Jul 31 2017

Components: -Blink>WebRTC Blink>WebRTC>Network
Mergedinto: webrtc:7844
Status: Duplicate (was: Unconfirmed)
The change in timeout was intentional. See linked bug for more info.

Sign in to add a comment