BUG - WebRTC connection fail when Google chrome is idle for a while
Reported by
sha...@companysocia.com,
Apr 21 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36 Example URL: https://apprtc.appspot.com Steps to reproduce the problem: 1. go to https://apprtc.appspot.com/r/test007 2. run it for 24/7 without any activity on the system 3. then remotely connect to that url after several hours later https://apprtc.appspot.com/r/test007 What is the expected behavior? 24/7 Google should let this url https://apprtc.appspot.com/r/test007 to be connected when-ever other side open it. What went wrong? Version 46 till 49 was working, since 50 its broken. if the webrtc url is idle for a while and the webrtc call connection does not start unless chrome see activity in the browser manually. Did this work before? Yes Version 46 till 49 Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 50.0.2661.86 Channel: stable OS Version: 8.1 Flash Version: Please rollback to version 46 to 48, which is working.
,
Apr 26 2016
shamun@ - the next time this happens, can you attach the javascript logs from the first participant in the room? I suspect some sort of server side timeout may be at play here since apprtc isn't designed to provide calls that run indefinitely. If you really need that functionality, can you run your own local instance of apprtc or similar service? jansson@ - is there anything else shamun@ should look at or be aware for this scenario?
,
Apr 27 2016
This is most likely not a chrome bug, just that the turn credentials have expired. We did change the turn service quite recently and we do not have any logic to check for this and request new credentials. Could you recheck and see that it actually works with 49 now?
,
Apr 27 2016
Please note it was a Google Chrome BUG. its now working since last release "50.0.2661.87", it was completely broken when we used "50.0.2661.75". Also it works if we go back to Chromium (46, 47, 48, 49) or SlikJet custom Google chrome version 49
,
Apr 27 2016
> its now working since last release "50.0.2661.87", it was completely broken when we used "50.0.2661.75". Closing per #4, but the results are a bit strange because there were no WebRTC changes between 50.0.2661.75 and 50.0.2661.87. That is, if you look at each release's DEPS file, you'll see that they have the same talk.git and webrtc.git hashes: https://chromium.googlesource.com/chromium/src/+/50.0.2661.75/DEPS https://chromium.googlesource.com/chromium/src/+/50.0.2661.87/DEPS There were quite a few other Chromium changes between those builds, but I don't know enough about Chromium overall to be able to pinpoint a possible fix: https://chromium.googlesource.com/chromium/src/+log/50.0.2661.75..50.0.2661.87?pretty=fuller&n=10000 In any case, if this happens again, please you attach the javascript logs from the first participant in the room so we can debug further. Thanks!
,
Apr 27 2016
,
Apr 28 2016
OK - Thank you. Please, Let us keep this issue open for a while to see in some next stable release if this same problem restarts at-least till "Version 52.0.2718.0 canary" becomes stable. This is very critical problem and very annoying once it happen. It never happened from my experience between versions 38 till 49, we need to find out if it again happens what changes exactly causing it
,
Apr 28 2016
FTR it cannot be a critical problem if you only see this in AppRTC, it's not intended for that use case and it's a demo app, not covered by production SLA's. Also since there are no logs and no concrete info it's not actionable. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by yini...@chromium.org
, Apr 22 2016