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 of things 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.
- Install watchRTC SDK. First things first – start by installing the watchRTC SDK
- Decide what are your rooms and peers. Now that your service can connect to watchRTC, it is time to decide what roomId and peerId means to you
- Don’t take this decision lightly – the way 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 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 on 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)
- Setup your proxy server. If your clients are trigger happy with their firewall rules, then this one’s a thing you should consider
- You can setup 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