The bugreporting capability is designed for high detailed logs which can decrease investigation time and help us to resolve any issue in your environment.
It is recommended to provide the bugreporting capability for your end-users.

There are few settings where the bugreporting should be configured:

1. flashphoner.xml


The setting allows sending of browser logs to server.
The browser logs which are available via browser debug console will be buffered and pushed to the WCS server via RTMFP or Websockets.
Therefore, using the Secure Websockets this operation will be fully secure and save.

2. Server logs are structured with the following organization:
– client_logs
– server_logs
– bug_reports

When you create a bugreport, the bugreport file will be placed in the bug_reports directory.
The bugreport file at the top of file points to a directory which keeps all necessary logs for this session where the bugreport was created by user.

Another debug capability is tcpdump usage. WCS is able to dump particular client session for SIP, RTP and SRTP and ICE (WebRTC traffic).
You can set the following settings to setup the traffic dump verbosity.


0 – write only WCS server log for this client session
1 – write WCS server log and SIP pcap log by tcpdump program.
2 – write WCS server log, SIP log by tcpdump and media traffic dump by tcpdump. The media traffic dump includes ICE and RTCP traffic captured from the same media ports.

So, client_dump_level=2 is option for most detail traffic dumps.


info – INFO level
debug – DEBUG level
trace – TRACE level

Each user session has a context with a set of server loggers.
When the user sends a bug report, the set of loggers will be switched to mode defined in the client_log_level setting.

And finally, Flashphoner client side API function sendBugReport();
Please use the function to leave detail bugreport on the server.

Brief description, how to swith server to the bugreporting mode:

Client flashphoner.xml:  <push_log>true</push_log>