How to associate your call ID and meeting ID with an rtcstats record
Map your application's call and meeting identifiers to rtcStats sessions so you can find and correlate data.
When a user reports an issue, you need to quickly find the right rtcStats session. By associating your application's session, conference and user identifiers with the rtcStats record at collection time, you can look up any session instantly.
Overview
rtcStats uses three identifiers for correlating data: session, conference, and user (see How to use session, conference and user identifiers for background). Your application's call ID and meeting ID map naturally to these.
The typical mapping is:
| Your application | rtcStats identifier | rtcstats database field |
|---|---|---|
| Meeting/room ID | conference |
rtcstats_conference |
| Call or session ID | session |
rtcstats_session |
| User or participant ID | user |
rtcstats_user |
Step 1: Identify your IDs
Before integrating, decide which identifiers from your application to pass. Common examples:
- Meeting platform - room name or meeting UUID as
conference, participant UUID asuser - Contact center - call ID or ticket number as
conference, agent/customer ID asuser - Telehealth - appointment ID as
conference, patient/doctor ID (or a hashed version) asuser
Step 2: Pass IDs when generating the rtcstats token
Passing these parameters from your backend via the client to rtcstats-server is done via a signed JSON Web Token (JWT).
Your backend generates the token as:
// Backend code
import { generateAuthToken } from '@rtcstats/rtcstats-server/utils.js';
const token = await generateAuthToken({
user: 'user_def456',
session: 'sess_abc123',
conference: 'room_meeting-42',
}, config.authorization.jwtSecret);
And passes it to the JavaScript client which uses it in the connect call:
// Frontend JavaScript
// trace is the RTCStats tracing object instance
trace.connect('wss://your-domain.example.com/?rtcstats-token=' + token);
See the rtcstats example for the end-to-end flow.
Step 3: Verify in rtcstats-server
Once data flows in, verify your identifiers are being stored correctly in the SQL database.
SELECT
session_start,
session_end,
rtcstats_user,
rtcstats_conference,
rtcstats_session,
blob_url
FROM "rtcstats-server"
ORDER BY session_start DESC
LIMIT 10;
Step 4: Look up sessions
Now you can find sessions from support tickets, logs, or your own dashboard:
Find all sessions for a specific user
SELECT
session_start,
session_end,
rtcstats_conference,
rtcstats_session,
blob_url
FROM "rtcstats-server"
WHERE rtcstats_user = 'user_def456'
ORDER BY session_start DESC;
Find all participants in a specific conference
SELECT
session_start,
session_end,
rtcstats_user,
rtcstats_session,
blob_url
FROM "rtcstats-server"
WHERE rtcstats_conference = 'room_meeting-42'
ORDER BY session_start DESC;
Tips
- Keep IDs stable - if a user reconnects, pass the same
conferenceanduseridentifiers so the sessions are correlated, but use a newsessionidentifier. - Use human-readable IDs where possible -
standup-2024-01-15is easier to search for than a UUID. That said, be sure to maintain privacy by not leaking sensitive information in the ID itself. - Hash sensitive IDs - if your user IDs contain PII (emails, phone numbers), hash them before passing to rtcStats. This preserves correlation while protecting privacy.
- Log the session identifier - have your application log the rtcStats
sessionidentifier alongside your own call logs, so you can cross-reference in either direction.
See also
Was this page helpful?