Apprtc calls not getting established due to failed ICE connection state |
||||||||
Issue descriptionOS: Chrome OS and Linux Linux: Chrome Version : 52.0.2743.82 stable Network: Wired Chrome OS: Chrome Version : 54.0.2819.0 / 8676.0.0 dev Network: Google Guest What steps will reproduce the problem? Start a two-way apprtc call by joining the same room from both Linux and Chrome OS using https://appr.tc/r/roomname Expected result: The call should be connected successfully, with no audio/video freeze and ICE state breakage Actual: 1. Apprtc call does not get connected on both sides: Linux and Chrome OS 2. Js logs show: "37.262: ICE connection state changed to: failed apprtc.debug.js:4084 37.265: Callstats status: success msg: autoFabricSetupFailed sent to the backend." Note: a)This issue is observed across different networks(Google Guest/Google-A/Wired) b) This issue is not reproducing consistently (observed 50% of the times)
,
Aug 5 2016
ICE state disconnected happens in apprtc calls b/w Mac & CrOS, and Win & CrOS JS Console logs from Mac - https://x20.corp.google.com/users/sr/srnarayanan/www/no_crawl/crbug635033 Mac & Win: Chrome Version : 54.0.2820.0 Canary Network: Google-A
,
Aug 9 2016
This could be a local network issue, hard to know since in the logs it just looks like its not able to connect with the provided candidates. Could you try to disable ipv6 on both sides and see if the issue remains? https://appr.tc/?ipv6=false
,
Aug 10 2016
This issue was not observed after disabling ipv6 on both sides. As mentioned in initial bug report, ICE state disconnections were seen only 50% of the times and could not be reproduced consistently.
,
Aug 10 2016
,
Aug 10 2016
ICE state dropped in an ipv6-disabled apprtc call session b/w Linux (wired network) and CrOS. Happened 3/3 times that we tried JS logs, webrtc-internal dump, and testrtc report here - https://x20.corp.google.com/users/sr/srnarayanan/www/no_crawl/crbug635033/Logs%20from%20Linux%20(wired%20network)
,
Aug 11 2016
Just to be clear, when you write wired, do you mean both machines are connected using an ethernet cable? That's the only way we can rule out the Wifi network behaving badly (it could also the wifi driver/hardware on the CrOS device). I think it might be something to do with relay candidates not being generated for the callee side. When you try to repro, can you try to figure out if it correlates to which machine initiate the call? E.g. does it happen every time CrOS starts the call first etc.
,
Aug 11 2016
Actually there is nothing you can do, I spoke to the backend team and this is most likely a turn server issue. Will keep you updated.
,
Aug 12 2016
srcv@ could you try this again? The backend team have fixed the issue that hopefully caused this.
,
Aug 17 2016
No ICE state disconnections were observed during recent AppRTC calls (from 08/15-08/17/2016). |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by srcv@chromium.org
, Aug 5 2016855 KB
855 KB View Download