← Back to How-To Guides

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 as user
  • Contact center - call ID or ticket number as conference, agent/customer ID as user
  • Telehealth - appointment ID as conference, patient/doctor ID (or a hashed version) as user

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 conference and user identifiers so the sessions are correlated, but use a new session identifier.
  • Use human-readable IDs where possible - standup-2024-01-15 is 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 session identifier alongside your own call logs, so you can cross-reference in either direction.

See also

Was this page helpful?