chrome://webrtc-logs/ just for Google Hangouts?

[Iñaki Baz Castillo]

Dear Google,

As far as I see entries in chrome://webrtc-logs/ are just generated
for Google Hangouts sessions.

Is that terribly true?

And if so, is there any googleXXXXXX custom and secret Chrome flag,
PeerConnection flag, or HTML metadata to enable it in any another
website?

--
Iñaki Baz Castillo
<i...@aliax.net>

[Iñaki Baz Castillo]

2016-05-17 10:57 GMT+02:00 Iñaki Baz Castillo <i...@aliax.net>:
> Dear Google,
>
> As far as I see entries in chrome://webrtc-logs/ are just generated
> for Google Hangouts sessions.
>
> Is that terribly true?
>
> And if so, is there any googleXXXXXX custom and secret Chrome flag,
> PeerConnection flag, or HTML metadata to enable it in any another
> website?

Let's see what happens...

b={iceServers:b};
c={mandatory:{RtpDataChannels:!0,DtlsSrtpKeyAgreement:!1},optional:[]};

c.optional.push({googLog:a.Na}) // opps

a.qf=new webkitRTCPeerConnection(b,c)

[Philipp Hancke]

you probably also want 

googLog:something

as an optional constraint.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfkDHVvvj-GT5mKg55x2bzDed21FJQT3wLxhkL9jTRM%2BVg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Iñaki Baz Castillo]

2016-05-17 11:21 GMT+02:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:

> you probably also want
>
> googLog:something
>
> as an optional constraint.

That's exactly what I'm about to test right now :)

[Iñaki Baz Castillo]

Nop, passing optional: [ { googLog: 1 } ] in pcConstraints is not enough...

[bl...@webrtc.org]

On Tuesday, May 17, 2016 at 10:58:08 AM UTC+2, Iñaki Baz Castillo wrote:

Dear Google,

As far as I see entries in chrome://webrtc-logs/ are just generated
for Google Hangouts sessions.

This is a diagnostic feature for Hangouts very much like stats gathering and crash dump gathering 

Is that terribly true?

The code is open source, there nothing secret about this. tommi@ can point you to the code in case of interest.

And if so, is there any googleXXXXXX custom and secret Chrome flag,
PeerConnection flag, or HTML metadata to enable it in any another
website?

Generally, this kind of log is used to improve the WebRTC platform in Chrome. It's meant to be understood by developers that work on Chrome and specifically WebRTC in Chrome.  It's purpose has never been to troubleshoot web application development. I would be happy to understand your use case a bit better and for what you would like to use such logs. We could think about including such a feature into chrome://webrtc-internals. 

Thanks, Niklas

[Iñaki Baz Castillo]

2016-05-17 15:54 GMT+02:00 <bl...@webrtc.org>:
> The code is open source, there nothing secret about this. tommi@ can point
> you to the code in case of interest.

Open source, but undocumented ;)

>> And if so, is there any googleXXXXXX custom and secret Chrome flag,
>> PeerConnection flag, or HTML metadata to enable it in any another
>> website?
>
>
> Generally, this kind of log is used to improve the WebRTC platform in
> Chrome. It's meant to be understood by developers that work on Chrome and
> specifically WebRTC in Chrome. It's purpose has never been to troubleshoot
> web application development. I would be happy to understand your use case a
> bit better and for what you would like to use such logs.

Well, I do work with WebRTC in Chrome, but that does not mean that I'm
a Chrome developer nor that I just debug Google Hangouts.

This is not about troubleshooting any web application development, but
about having the proper tools to debug WebRTC issues when it comes to
interop with 3rd party endpoints (such as WebRTC media servers, etc).
To be clear: within my company we handle our WebRTC app and our own
MCU server, and sometimes we need to check what happens in Chrome
WebRTC internals. I consider that a reasonable use case.

> We could think
> about including such a feature into chrome://webrtc-internals.

Not sure if I understand. There are both chrome://webrtc-internals and
chrome://webrtc-logs. The latter just works for Hangouts so it's clear
that it depends on some undocumented and custom parameter somewhere.
What I ask for is a way to activate it so I can see the WebRTC logs of
my own WebRTC application under chrome://webrtc-logs.

Thanks a lot.

[Philipp Hancke]

from what I can tell, the log you get is not different from what you get with --enable-logging --v=4. Arguably, sometimes it would be nice to get that from a user without having to explain how to start chrome from the command line but... even I never had the opportunity to do explain that to anyone so far.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfm335X8o5Ty6FajFF%3DVp7zJZtiFcC51cc8ADE9SXicdRw%40mail.gmail.com.

[Iñaki Baz Castillo]

2016-05-17 17:15 GMT+02:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:

> from what I can tell, the log you get is not different from what you get
> with --enable-logging --v=4.

I know that, but here in the office people complains that it does no
longer work in Windows (no idea). Anyhow I'd feel more comfortable by
having chrome://webrtc-logs working for also non Google apps (so I
don't need to close Chrome and open it from the command line).

> Arguably, sometimes it would be nice to get
> that from a user without having to explain how to start chrome from the
> command line but... even I never had the opportunity to do explain that to
> anyone so far.

The point here is that Chrome *already* has the capability of
providing cool and organized WebRTC logs for every WebRTC developer
regarding he works at Google or not, but it just works for Hangouts
due to some undocumented options.

[Tommi]

A while ago we did discuss making a standard API for delivering the native log to the application for troubleshooting.  However, that conversation never got anywhere and I'm not familiar with details why.

As with some other features that we've been working on standardizing (e.g. audio device selection), we've implemented workaround solutions (e.g. chromeRenderToAssociatedSink) while the standards process is being worked out.  For Hangouts, we've had an extension for audio device selection as an example and will soon be deprecating that extension since we've now implemented that API in the web platform.  Anyway, I digress. See more replies below.

On Tue, May 17, 2016 at 5:05 PM Iñaki Baz Castillo <i...@aliax.net> wrote:

2016-05-17 15:54 GMT+02:00  <bl...@webrtc.org>:
> The code is open source, there nothing secret about this. tommi@ can point
> you to the code in case of interest.

Open source, but undocumented ;)

As are many things, but it's not entirely undocumented.  As an example, you mention chrome://webrtc-logs in your first email. :)

 

>> And if so, is there any googleXXXXXX custom and secret Chrome flag,
>> PeerConnection flag, or HTML metadata to enable it in any another
>> website?
>
>
> Generally, this kind of log is used to improve the WebRTC platform in
> Chrome. It's meant to be understood by developers that work on Chrome and
> specifically WebRTC in Chrome.  It's purpose has never been to troubleshoot
> web application development. I would be happy to understand your use case a
> bit better and for what you would like to use such logs.

Well, I do work with WebRTC in Chrome, but that does not mean that I'm
a Chrome developer nor that I just debug Google Hangouts.

What Niklas means is that we, the WebRTC engineers that implement WebRTC features in Chrome, use feedback that we get from this log, to improve WebRTC itself - and not just for Hangouts of course, but for all apps with comparable feature sets.  The format of the log and what it contains, can and will also change at any time (i.e. we would want to avoid any assumptions made by applications about its contents).

 

This is not about troubleshooting any web application development, but
about having the proper tools to debug WebRTC issues when it comes to
interop with 3rd party endpoints (such as WebRTC media servers, etc).
To be clear: within my company we handle our WebRTC app and our own
MCU server, and sometimes we need to check what happens in Chrome
WebRTC internals. I consider that a reasonable use case.

> We could think
> about including such a feature into chrome://webrtc-internals.

Not sure if I understand. There are both chrome://webrtc-internals and
chrome://webrtc-logs. The latter just works for Hangouts so it's clear
that it depends on some undocumented and custom parameter somewhere.

The way log gathering is started is done via a Google extension in Chrome (not a part of Chromium).  Access to the extension is limited to google.com.

 

What I ask for is a way to activate it so I can see the WebRTC logs of
my own WebRTC application under chrome://webrtc-logs.

 

That's what Niklas is proposing: We can implement a feature in chrome://webrtc-internals that allows you to start gathering this log and make it show up in chrome://webrtc-logs (and not uploaded to Google servers of course).  Would that work?

[Christoffer Jansson]

On Tue, May 17, 2016 at 5:34 PM Iñaki Baz Castillo <i...@aliax.net> wrote:

2016-05-17 17:15 GMT+02:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:
> from what I can tell, the log you get is not different from what you get
> with --enable-logging --v=4.

I know that, but here in the office people complains that it does no
longer work in Windows (no idea).

https://bugs.chromium.org/p/chromium/issues/detail?id=401963

It does work now if you use --no-sandbox as well. Sawbuck is a nice windows logging tool, with that I do not think you need the command line flag, not sure though.

 

Anyhow I'd feel more comfortable by
having chrome://webrtc-logs working for also non Google apps (so I
don't need to close Chrome and open it from the command line).

> Arguably, sometimes it would be nice to get
> that from a user without having to explain how to start chrome from the
> command line but... even I never had the opportunity to do explain that to
> anyone so far.

The point here is that Chrome *already* has the capability of
providing cool and organized WebRTC logs for every WebRTC developer
regarding he works at Google or not, but it just works for Hangouts
due to some undocumented options.




--
Iñaki Baz Castillo
<i...@aliax.net>

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfkXZnxdj8Ns5CMOx15WqhfBP4PV6s%2BMi9JMq4DoGGcV8w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

/Chris

[Iñaki Baz Castillo]

2016-05-17 17:41 GMT+02:00 Tommi <to...@webrtc.org>:
> What Niklas means is that we, the WebRTC engineers that implement WebRTC
> features in Chrome, use feedback that we get from this log, to improve
> WebRTC itself - and not just for Hangouts of course, but for all apps with
> comparable feature sets. The format of the log and what it contains, can
> and will also change at any time (i.e. we would want to avoid any
> assumptions made by applications about its contents).

Nobody is requesting a "standardized" file format for custom
applications to consume them. But if someone knows something about
Chrome WebRTC internals, those logs (regardless how they look exactly)
can be very useful.

>> Not sure if I understand. There are both chrome://webrtc-internals and
>> chrome://webrtc-logs. The latter just works for Hangouts so it's clear
>> that it depends on some undocumented and custom parameter somewhere.
>
>
> The way log gathering is started is done via a Google extension in Chrome
> (not a part of Chromium). Access to the extension is limited to google.com.

Opps...

>> What I ask for is a way to activate it so I can see the WebRTC logs of
>> my own WebRTC application under chrome://webrtc-logs.
>
>
> That's what Niklas is proposing: We can implement a feature in
> chrome://webrtc-internals that allows you to start gathering this log and
> make it show up in chrome://webrtc-logs (and not uploaded to Google servers
> of course). Would that work?

Sure! :)

[Sergio Garcia Murillo]

On 17/05/2016 17:43, 'Christoffer Jansson' via discuss-webrtc wrote:

On Tue, May 17, 2016 at 5:34 PM Iñaki Baz Castillo <i...@aliax.net> wrote:

2016-05-17 17:15 GMT+02:00 'Philipp Hancke' via discuss-webrtc
<discuss...@googlegroups.com>:
> from what I can tell, the log you get is not different from what you get
> with --enable-logging --v=4.

I know that, but here in the office people complains that it does no
longer work in Windows (no idea).

https://bugs.chromium.org/p/chromium/issues/detail?id=401963

It does work now if you use --no-sandbox as well. Sawbuck is a nice windows logging tool, with that I do not think you need the command line flag, not sure though.

 

If I add --no-sandbox I get a warning in chrome canary saying that it is not allowed because stability and security will suffer, and no webrtc logs are present on log file.

Best regards
Sergio

[Tommi]

Sawbuck is what I use on Windows.  Btw --v=4 is probably more verbose than what actually goes to the webrtc log.  If you search the Chromium code base for WebRtcLogMessage, that should give you an idea about what makes it there and how.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/56d591f5-a6c7-aba7-af51-0c54a56a0bb3%40gmail.com.

[Justin Uberti]

This seems like a reasonable solution.