Chrome Windows identifies different ICE candidates depending on whether microphone permission is already pre-given or whether it is given during the call setup
Reported by
st...@connection-telecom.com,
Jan 30 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299 Steps to reproduce the problem: 1. Run chrome with webrtc debugging 2. Open WebRTC-using application 3. In Settings remove existing permission for application to use microphone 4. Initiate call, ALLOWing microphone access 5. Examine chrome_debug.log - See that FilteringNetworkManager got "denied" [18088:12416:0130/103923.178:VERBOSE1:filtering_network_manager.cc(114)] FilteringNetworkManager received permission status: denied [18088:12416:0130/103923.178:VERBOSE1:filtering_network_manager.cc(114)] FilteringNetworkManager received permission status: denied - See that Network manager looks at 2 networks: [18088:12416:0130/103930.984:INFO:basicportallocator.cc(781)] Network manager has started [18088:12416:0130/103930.984:INFO:basicportallocator.cc(696)] Allocate ports on 2 networks (actually one interface with an ipv4 and ipv6 address) 6. Now call again (permission was already given) [14900:19368:0130/112510.821:VERBOSE1:filtering_network_manager.cc(114)] FilteringNetworkManager received permission status: granted [14900:19368:0130/112510.821:VERBOSE1:filtering_network_manager.cc(114)] FilteringNetworkManager received permission status: denied - See that 5 networks are looked at: [14900:19368:0130/112512.601:INFO:basicportallocator.cc(696)] Allocate ports on 5 networks What is the expected behavior? Since permission was given in both cases - first time as the call was setup, and second time there was pre-existing permission - then my view is that the same networks should be looked at in both cases - that the ICE process should not end up different. What went wrong? Some interfaces excluded from ICE process because the microphone permission wasn't pre-existing and was actually asked for during the call setup. Did this work before? Yes Before the introduction of the FilteringNetworkManager ? Chrome version: Version 66.0.3334.0 (Official Build) canary (64-bit) Channel: canary OS Version: 10.0 Flash Version:
,
Feb 2 2018
,
Feb 5 2018
,
Feb 5 2018
isn't this a consequence of the candidate filtering described in https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-04 -- without GUM permission you only get candidates from the default route, not the full list.
,
Feb 5 2018
Yes, though the issue being described here is "I get the full list the second time, just not the first time." What's the relative ordering between allowing microphone access and setting the local description? If setLocalDescription came first, this would be expected behavior. The decision to enumerate all network interfaces or not is made when candidate gathering begins.
,
May 22 2018
Marking it as WontFix since there are no feedback from user more than a month.Feel free to raise a new issue if still facing. Thank You! |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, Jan 30 2018