New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users
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 Back to list
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
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
Is this finished?
Project Member Comment 26 by, Sep 6
Not finished; this is a master bug for providing network types on various platforms, see the "blocked on" bugs.
Sign in to add a comment