-
Notifications
You must be signed in to change notification settings - Fork 322
Frequently Asked Questions (FAQ) WebRTC C SDK
See the detailed Step-by-Step guide to get started
KVS WebRTC C SDK offers 7 levels of verbosity.
1. LOG_LEVEL_VERBOSE=1
2. LOG_LEVEL_DEBUG=2
3. LOG_LEVEL_INFO=3
4. LOG_LEVEL_WARN=4
5. LOG_LEVEL_ERROR=5
6. LOG_LEVEL_FATAL=6
7. LOG_LEVEL_SILENT=7
The default log level is LOG_LEVEL_WARN
.
To set a logging level, run: export AWS_KVS_LOG_LEVEL=<LOG_LEVEL>
For example, to set DEBUG
log level, run export AWS_KVS_LOG_LEVEL=2
Run the command: export AWS_ENABLE_FILE_LOGGING=TRUE
. Log file size, rotation index and log file path can be configured in Samples.h
Run this command before starting the application: export DEBUG_LOG_SDP=TRUE
. This will display the remote and local SDPs in the logs. Another way to extract this is to visit the WebRTC internals in the browser:
- Chrome: chrome://webrtc-internals/
- Firefox: about:webrtc
More questions coming soon...
The status code indicates that the connection timed out. Check if the device is in a bad network. To get more information, run debug version of libwebsockets
by running cmake
with -DCMAKE_BUILD_TYPE=DEBUG
option to understand what could be wrong. If you still need assistance, feel free to open a github issue including information about the network set up, the debug logs and how your application is set up.
My application errors out when I delete the signaling channel on the KVS console and restart the application with the same channel name? Why does this happen?
When a new channel is created, the application caches this information in a signaling file cache. The application does not detect if the channel is deleted and when the same channel name is encountered, the SDK attempts to use the cached value and fails. This is a known bug and we will work to resolve it. In the mean time, deleting the cache file should solve the problem. The file .SignalingCache_v0
is available in the build
or the directory from which the application is run.
More questions coming soon...
You can run the discoverNatBehavior with network interface name and STUN host name. The application can be found here.
When a candidate pair is selected, it will remain selected throughout the lifetime of ice session. However, if the ICE agent moves to a failed state, the application can capture this through onConnectionStateChange() callback and invoke restartIce()
which would re-trigger ICE candidate gathering and subsequent steps.
You can use the rtcPeerConnectionGetMetrics()
API and set requestedTypeOfStats
to RTC_STATS_TYPE_LOCAL_CANDIDATE
and RTC_STATS_TYPE_REMOTE_CANDIDATE
. The stock sample includes a sample implementation of gathering this information
More questions Coming soon...
The SDK does not provide any direct API to measure this. One way to do this would be to use RTP timestamp. The SDK uses producer timestamp as RTP timestamp. At the receiver end, the RTP header can be parsed for the timestamp and latency can be measured. Refer to this issue to get more details