# Recipient media telemetry and revocation guarantees **URL:** \ **Category:** Cloud Dashboard\ **Tags:** livekit-cloud\ **Created:** [October 8, 2026, 4:41am UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207 "2026-10-08T04:41:46Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Mehmet\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/mehmet_c/32/2727_2.png) [@Mehmet\_C](https://community.livekit.io/u/Mehmet_C)\ **Post date:** [October 8, 2026, 4:41am UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207/1 "2026-10-08T04:41:46Z")
Subject: Recipient media telemetry and revocation guarantees — VibeLive Staging (Build) Hi LiveKit team, Project: VibeLive Staging, p\_2wpsw3nxf7c Hostname: vibelive-staging-wwy40udt.livekit.cloud Plan: Build. Project data region: European Union (Frankfurt). The hostname is verified against our staging runtime. For paid calls, is there a supported server-origin API/stream exposing per-subscriber, per-camera/microphone-track actual-media RTP progression, excluding padding/retransmissions/FEC, with participant/track IDs, generation, sequence, timestamps and fresh transport feedback? Our target is ≤2-second sampling and ≤5-second data age. We need transmission evidence, not proof of screen playback. Analytics requires Scale+, but its documented response does not include these counters. Please identify the exact supported interface, actual freshness, disconnect/reconnect behavior and plan availability; if unavailable, please confirm. Separately, a Cloud v1.13.7 /rtc probe observed JOIN 26 ms after successful RemoveParticipant with explicit revoke\_token\_ts \> token nbf. The JOIN payload was not retained; later attempts were rejected. What revocation completion guarantee applies across /rtc and /rtc/v1, and what supported test verifies it? Please confirm capabilities before recommending an upgrade or infrastructure change. ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [October 8, 2026, 9:25am UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207/2 "2026-10-08T09:25:06Z")
Hi, no, the short answer is that our Analytics API does not provide the granularity of data you are asking for and, even if it did, we don’t offer any guarantees to meet your target of 2-5 secs for data age. I’ll be honest, I found it hard to parse the first part of your original question so fed it into our docs AI - I stand behind what it returned, so I’ll copy it below: > LiveKit Cloud does not document or expose a supported server-origin interface that provides per-subscriber, per-track RTP “actual media progression” counters at the granularity you described (excluding padding, retransmissions, and FEC, with RTP sequence/timestamp progression and fresh transport feedback). The documented Analytics API exposes session-, participant-, and aggregate publish-rate metrics only, and is available only on Scale+ plans. It does not expose subscriber-level RTP progression telemetry or freshness guarantees. See [Analytics API](https://docs.livekit.io/deploy/admin/analytics-api/) and [Room service API](https://docs.livekit.io/reference/other/roomservice-api). > [@Mehmet\_C](#): > > Separately, a Cloud v1.13.7 /rtc probe observed JOIN 26 ms after successful RemoveParticipant with explicit revoke\_token\_ts \> token nbf. The JOIN payload was not retained; later attempts were rejected. What revocation completion guarantee applies across /rtc and /rtc/v1, and what supported test verifies it? I assume that 26ms is propagation delay, but to answer your specific question there are no specific published guarantees around that. ---
**Author:** ![Mehmet\_C](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/mehmet_c/32/2727_2.png) [@Mehmet\_C](https://community.livekit.io/u/Mehmet_C)\ **Post date:** [October 8, 2026, 10:50am UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207/3 "2026-10-08T10:50:41Z")
Hi Darryn, Thank you for clarifying the Cloud limitations. I’ll simplify the use case: we have paid one-to-one video sessions. We need to stop billing when the viewer disconnects and prevent removed users from accessing a closed session. I understand that the Analytics API cannot provide the per-viewer media-progression evidence or 2–5 second freshness we requested. Connection state is not proof that video was delivered or played. Could you point us to the supported approach for these two questions? 1. Which server-side Cloud signals would you recommend for detecting an active media connection and a disconnect? Are participant webhooks plus GetParticipant/ListParticipants appropriate, and what blind spots should we account for before using them in our application’s billing decisions? If Cloud offers only connection status rather than media-delivery evidence, please confirm that distinction. 2. The documentation describes token revocation as immediate, but your reply says there is no published completion-time guarantee. With an explicit revoke\_token\_ts later than the token’s nbf, is there a supported way to verify that revocation has taken effect? What test and mitigation do you recommend for possible propagation delay across /rtc and /rtc/v1? The earlier JOIN observation alone does not prove media access, since its payload was not retained. A short explanation or relevant documentation links would be very helpful. Best regards, Mehmet Ç ---
**Author:** ![darryncampbell](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/darryncampbell/32/20_2.png) [@darryncampbell](https://community.livekit.io/u/darryncampbell)\ **Post date:** [October 8, 2026, 12:25pm UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207/4 "2026-10-08T12:25:44Z")
> [@Mehmet\_C](#): > > 1. Which server-side Cloud signals would you recommend for detecting an active media connection and a disconnect? Are participant webhooks plus GetParticipant/ListParticipants appropriate, and what blind spots should we account for before using them in our application’s billing decisions? If Cloud offers only connection status rather than media-delivery evidence, please confirm that distinction. The [webhooks](https://docs.livekit.io/intro/basics/rooms-participants-tracks/webhooks-events/#webhook-events) for participant joined and left would be suitable, they give you an indication of when the participant joined and left the room, as well as the tracks that were active. For ‘media-delivery’ evidence, if this was a legal requirement, or you are worried about folks claiming ‘I joined the call but couldn’t hear anything’, then you could use LiveKit egress to record the calls as additional evidence. > The documentation describes token revocation as immediate, but your reply says there is no published completion-time guarantee. With an explicit revoke\_token\_ts later than the token’s nbf, is there a supported way to verify that revocation has taken effect? What test and mitigation do you recommend for possible propagation delay across /rtc and /rtc/v1? You mad mentioned 26ms so my answer was framed as it being the time to process the request across a globally distributed network. In practice, I would expect you to use individual, unique rooms for each paying subscriber video session, so if someone does rejoin, they are just joining an old session. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\ **Post date:** [October 23, 2026, 12:26pm UTC](https://community.livekit.io/t/recipient-media-telemetry-and-revocation-guarantees/2207/5 "2026-10-23T12:26:05Z")
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.