Malformed JSON in webrtc-internals
Reported by
mond...@gmail.com,
Jun 29 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Connect to webrtc endpoint 2. Open chrome://webrtc-internals 3. Select the proper tab/item for your endpoint connection 4. Review the peer connection information, it will look malformed as shown: http://localhost:5080/live/broadcast.jsp?host=10.0.0.5, { iceServers: [stun:stun2.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: negotiateiceCandidatePoolSize: 0 }, {advanced: [{enableDtlsSrtp: {exact: true}}, {enableRtpDataChannels: {exact: false}}, {googCpuOveruseDetection: {exact: true}}]} What is the expected behavior? Display should be properly formed/formatted like so: http://localhost:5080/live/broadcast.jsp?host=10.0.0.5, { iceServers: [stun:stun2.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: negotiate, iceCandidatePoolSize: 0 }, {advanced: [{enableDtlsSrtp: {exact: true}}, {enableRtpDataChannels: {exact: false}}, {googCpuOveruseDetection: {exact: true}}]} What went wrong? The rtcpMuxPolicy and iceCandidatePoolSize are not comma separated as they should be. Did this work before? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: Ubuntu 16.04 Flash Version: Shockwave Flash 26.0 r0
,
Jun 30 2017
While I cannot provide a link to our servers, the malformed information can be reproduced using webrtc examples here: https://webrtc.github.io/samples/src/content/peerconnection/multiple-relay/ 1. Start 2. Call 3. Insert relay 4. Open chrome://webrtc-internals Result: https://webrtc.github.io/samples/src/content/peerconnection/multiple-relay/, { iceServers: [], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: requireiceCandidatePoolSize: 0 },
,
Jun 30 2017
Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 5 2017
Tested the issue on Mac os 10.12.5 , windows 7 and ubuntu 14.04 using chrome M59 #59.0.3071.115 and issue is reproduced. Issue is fixed in latest bet ,dev and canary channels. Issue is fixed in M60 . Using the per-revision bisect providing the reverse bisect results, Good build:60.0.3082.0(Revision: 466837). Bad build:60.0.3080.0 (Revision: 467534). You are probably looking for a change made after 467266 (known good), but no later than 467267 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/4b844c79e013f783d7154c8d7692f78d5c380496..fb4604d257703df68c8865db1a5d27f3059c2920 From the CL above, assigning the issue to the concern owner @deadbeef- Could you please merge the fix into M59. Review-Url: https://codereview.chromium.org/2832263004 Thanks!
,
Jul 5 2017
M59 is already stable, and this isn't a critical issue so I don't think there's any chance of getting approval to merge it. Sorry... |
||||
►
Sign in to add a comment |
||||
Comment 1 by sandeepkumars@chromium.org
, Jun 30 2017