When planning on using watchRTC, there will be several steps you should follow to make the most out of the service.
Below are the suggested best practices you should consider and take care of before placing the watchRTC SDK in your production system.
Here, the steps are mandatory. Without them, you won’t be collecting any WebRTC metrics from your application.
- Create a watchRTC API Key:
To use watchRTC, you’ll need a special API key. You must use the API key you created when initializing the watchRTC SDK. Make sure to create a watchRTC API key
- Install the watchRTC SDK:
For watchRTC to be able to collect data for analysis, you will first need to install its SDK. The SDK acts as a silent and passive agent residing inside your application, collecting WebRTC related metrics and sending them to the watchRTC server.
watchRTC SDKs are available for multiple platforms. Based on what your WebRTC application is using, you will need to integrate with one or more of our watchRTC SDKs. Please choose the correct SDK based on the platform you will be using.
- Assign rooms and peers:
Now that your service can connect to watchRTC, it is time to decide what roomId and peerId mean to you. Make sure to Decide what are your rooms and peers.
- Don’t take this decision lightly – how data gets collected and cataloged will determine how useful the results will be to you.
- That said, you can modify this yourself at any given point in time. All new data will adhere to your newer approach, while older data will stick to the old configuration.
These are optional steps that are highly suggested you do. You can leave them for later, but make sure you have this added to your list of tasks.
- Define custom keys
Custom keys are a powerful tool that enables you to customize the service further.
- Think about what additional metadata will be useful for you and see if you can define these as key-value pairs
- For each key, see if it should be aggregable or only searchable
- The definition of keys is done by our support engineers. So while changing them from time to time is possible, it is a bit more cumbersome (by design)
- Define custom alerts
You can decide when to be notified of certain session behavior.
- This helps you focus on areas that require your attention more easily
- Decide what thresholds you want for certain metrics and configure them in your account settings
- As sessions will be analyzed by watchRTC, they will be tagged based on your definitions
- Configure console logs collection
If your account has console logs collection enabled, then this can be quite useful.
- Check what messages your application writes into the browser’s console log
- If anything there is useless, remove it. If things are needed, add them
- Instruct watchRTC what to collect to the server for better visibility and debugging
These are optional steps you might need to do. They are specific, dealing with certain requirements or issues you might “bump into”.
- Explicitly connect the SDK
If you want to collect information prior to a peer connection being created, then this may come in handy.
- It means manually controlling when the SDK connects and disconnects from our servers
- Using it can catch more failures and edge cases, along with more information (errors, logs, and custom events)
- Set up your proxy server
If your clients are trigger-happy with their firewall rules, then this one’s a thing you should consider.
- You can set up your own proxy servers so that instructing your clients what IP addresses or FQDN rules to open up in the firewall is easier
- Once done, all data will be routed through your own servers to the testRTC backend instead of directly
- Integrate deeper into the watchRTC platform:
There are many additional ways in which you can increase the worth of watchRTC and deepen the analysis and insights you get from it. Here are some additional actions you can take, either when you start using watchRTC or later along the way:
- With the SDK:
- On the backend: