watchRTC collects metrics from WebRTC sessions to make them easy to analyze and review. Towards that end, you will need to tell watchRTC for each user joining, where it belongs to. This is done using the peerId and roomId configuration variables that you pass when using the watchRTC SDK.
A peerId represents a user on a device in a session.
- A peerId should not include any PII. This means you shouldn’t place a name or an email address as your peerId, as these are identifiable and may be considered as privacy breach. It is preferable to use a different identifier here
- The same peerId used inside the same roomId more than once will be defined as a single entity
- If a user rejoins a session from the same device, it is advisable to assign him the same peerId
- If a user joins a session from tow different devices, it is advisable to assign him different peerId values for each device
- If you have multiple WebRTC peer connections being opened from the same device by the same user then it is advisable to associate them all with the same peerId
- When using a 3rd party CPaaS vendor, it might make sense to use the associated identifier of the 3rd party connection with watchRTC’s peerId – this can make it simpler to troubleshoot and correlate between the two. You can also use a searchable custom key to achieve this
- peerId’s aren’t exactly unique. You can reuse them across rooms
The roomId represents the session that holds multiple users in it.
- A roomId should not include any PII. This means you shouldn’t place names that make this identifiable
- The roomId represents a session and not a static room. If there is a static room where meetings are conducted one after the other, then each will be considered as a different entry in watchRTC and should probably have a different roomId
- roomId’s aren’t exactly unique. You can reuse them. That said, our advice is to make roomId’s unique and to treat them more like sessions than rooms in your implementation logic
Selecting linkable names for rooms and peers
You can (and should) select room and peer names that make sense in your application. Be sure to select privacy adhering names and not use emails as peer names for example – this will make sure privacy is maintained by watchRTC.
If you choose names correctly, you will also be able to deep link into watchRTC and from watchRTC to your other systems.
Room closure and analysis
watchRTC collects the data from your used in realtime via the SDK. Once it deems a session as complete, it will “close” the room, analyze the results and make them available in the testRTC dashboard.
A “room” is created and starts collecting data once a user is assigned its peerId and a roomId and that roomId isn’t open.
As long as there are peers connected to the room, the room is considered open and active.
By default, once the last user disconnects from the room, the room is automatically “closed” and its data analyzed. If a peer will join the room at this point, then a new “room” entry will be created with the same roomId and it will start collected data from this new peer.
If needed, this logic can be modified so that rooms will stay open for a period of time (measured by minutes) before being closed and processed.
Configuring virtual spaces
There is a rather new concept of virtual spaces these days, where users traverse a 2D or 3D metaverse representing an office, event space or similar, conducting ad-hoc meetings as needed.
In such a concept, a room or a space is usually a static virtual location where many parallel conversations can take place.
To make the most of watchRTC for this use case, our suggestion is to follow this best practice:
- Configure your peerId to represent a user on a specific device
- Different users will have a different peerId (make the peerId unique per user)
- Different devices for the same user should have a different peerId, maybe with a simple way to associate different devices of the same user
- Configure your roomId on watchRTC to represent a specific ad-hoc conversation taking place in a virtual space
- Different conversations within the same virtual space should have a different roomId
- Make it simple to correlate the roomId to a virtual space if needed. You can achieve this by using a searchable or aggregable custom key called “space” which denotes the virtual space itself for example