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

Issue 3149 link

Starred by 20 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Add network type to libjingle network interface

Reported by, Apr 2 2014

Issue description

Libjingle doesn't capture information about network interface type(like WIFI/WAN/LTE), which can be used in improving the call quality.

WIFI/WAN detection is available for Windows/OSX in M36. Next step is add this information for Android.

Comment 2 by, Jun 6 2014

Summary: Add network type to libjingle network interface (was: Add network type to libjingle network interface)
Jiayang to look into how to determine this for Linux/ChromeOS. 

Will also need to figure out how to deal with this for Android.

Comment 3 by, Oct 14 2014

Labels: Area-Network

Comment 4 by, Nov 3 2014

Labels: EngTriaged Mstone-42
Project Member

Comment 5 by, Feb 19 2015

Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member

Comment 6 by, Feb 1 2016

Labels: -Mstone-44 Mstone-51
Reassigning to Honghai.
Project Member

Comment 7 by, Mar 1 2016

Need clarification on this. 
I think we already have network type on Android and IOS, but I have not checked the network type on Windows/Linux/ChromOS. 
So is the goal here to get network types on Chrome Windows/Linux/ChromeOS and Mobile Windows?
Project Member

Comment 8 by, Apr 25 2016

Labels: -Mstone-51 Mstone-52
Project Member

Comment 9 by, May 27 2016

The following revision refers to this bug:

commit 63ab810ce2e81c1e5ca0e8fa91d02958f0bda147
Author: Honghai Zhang <>
Date: Fri May 27 03:30:15 2016

Set IOS Wifi interface type based on the interface name.


Review URL: .

Cr-Commit-Position: refs/heads/master@{#12939}


Project Member

Comment 10 by, Oct 5 2016

Labels: M-52
Project Member

Comment 11 by, Oct 17 2016

Is this finished? If not, is it expected to be finished before the next release (M56)? If so, please update the milestone accordingly.
Project Member

Comment 12 by, Oct 17 2016

Labels: -Mstone-52 -M-52 M-56 Mstone-56
Project Member

Comment 13 by, Oct 20 2016

 Issue 4288  has been merged into this issue.

Comment 14 by, Oct 21 2016

Since this is complex to get right for every platform, should there be one sub-bug for each platform?

Project Member

Comment 15 by, Oct 21 2016

Good points. I will break this into sub-bugs per platform. 
Project Member

Comment 16 by, Oct 21 2016

By the way, Network type has been determined on Android using NetworkMonitor. 
Project Member

Comment 18 by, Nov 8 2016

Labels: Pri-3
Project Member

Comment 19 by, Nov 11 2016

honghaiz@ are we going to keep this bug open to track the sub-bugs listed in #17? Should we make this one blocked on them in such case?
Project Member

Comment 20 by, Nov 11 2016

It makes sense to make this one blocked on them. 
Project Member

Comment 21 by, Nov 11 2016

Blockedon: 6589 6586 6587 6588
Project Member

Comment 22 by, Nov 11 2016

Labels: -Mstone-56 -M-56 Mstone-57 M-57
Project Member

Comment 23 by, Nov 28 2016

Labels: -Mstone-57 -M-57
Project Member

Comment 24 by, Jul 27 2017

The following revision refers to this bug:

commit 4cd599f02504e32224a688434db6d43f5c892167
Author: deadbeef <>
Date: Thu Jul 27 22:05:29 2017

If adapter type is unknown and interface name is "ipsec", treat as VPN.

This will result in the ipsec interfaces being prioritized below Wi-Fi
and cell interfaces. This makes the most difference when we hit the
default limit for IPv6 interfaces (5), and there are lots of ipsec
interfaces for whatever reason, resulting in the "real" interfaces that
would actually succeed not being used. See the linked  bug 7703 .

BUG= webrtc:7703 , webrtc:3149

Cr-Commit-Position: refs/heads/master@{#19175}


Project Member

Comment 25 by, Sep 4 2017

Is this finished?
Project Member

Comment 26 by, Sep 6 2017

Not finished; this is a master bug for providing network types on various platforms, see the "blocked on" bugs.
Proposed CL with network interface recognition for Windows:
Project Member

Comment 28 by, May 21 2018

The following revision refers to this bug:

commit 0ce868c60e2405845608b552c43c37d256e6523f
Author: Yura Yaroshevich <>
Date: Mon May 21 18:03:26 2018

Recognize additional adapter types on Windows

Specifically, Ethernet, Wi-Fi and cellular interfaces.

Note that this only affects native applications, as chromium already
has its own code for this:

Which WebRTC accesses through "IpcNetworkManager".

Bug: webrtc:3149, webrtc:6588
Change-Id: I347f2734d95ea24cea3f89e6ed5bf2d135a9fc77
Reviewed-by: Taylor Brandstetter <>
Commit-Queue: Taylor Brandstetter <>
Cr-Commit-Position: refs/heads/master@{#23332}

Sign in to add a comment