LiveKit vs Agora vs a gateway RTC API for support calls

For a support-call feature the deciding factor is how much call UI and in-call control you need. An honest split, including when to buy the specialist.

Adding a support call to an existing product is mostly a front-end problem. All three options give you rooms and tokens; what differs is how much of the call interface and in-call control comes with them. Infrai’s RTC surface is seven endpoints — POST /v1/rtc/room/create, POST /v1/rtc/token/issue, GET /v1/rtc/participant/list/{room} and four more — on the same key as your storage, queues, email and inference.

If you need a call UI, buy one. If you need call primitives beside the rest of your stack, keep reading.

What the gateway version is

curl -sS -X POST "https://api.infrai.cc/v1/rtc/room/create" \
  -H "Authorization: Bearer ${INFRAI_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"name": "support-4821", "max_participants": 2, "empty_timeout_s": 120}'
{
  "ok": true,
  "data": {
    "room_id": "rtcr_2fVc8nRqLmT4xBzY",
    "name": "support-4821",
    "vendor": "tencent_rtc",
    "state": "active",
    "max_participants": 2,
    "num_participants": 0,
    "created_at": "2026-09-21T03:25:19Z",
    "metadata": {}
  }
}

Then a token per participant, carrying the permission flags and the websocket URL the client connects to. The browser side uses the vendor’s own client library — there’s no platform-neutral SDK here, which is the first thing to weigh.

The comparison

What you needLiveKitAgoraInfrai RTC
Rooms and server-minted tokensyesyesyes
Prebuilt call UI componentsyes, extensiveyesno
Update participant permissions mid-callyesyesno — kick and re-mint
Track-level state (muted, speaking)yesyesnot exposed
Server-side recordingyesyesnot in these routes
Self-hosting optionyesnono
Global low-latency networkyesyes, its strengthone vendor, one region set
Same credential as storage, queues, email, AInonoyes

Rows two to five are where a specialist earns its price, and they’re genuine limitations here rather than a matter of taste. No UI components, no mid-call permission changes, no media state, no recording endpoint.

When to buy the specialist

LiveKit if the call is a significant feature. Its component library gets you a working call UI in an afternoon, its server API can mute and re-permission participants without disconnecting them, and self-hosting is available if data residency is a hard requirement. For a product where video is a headline capability, that’s the right purchase.

Agora if global reach and call quality under poor networks are the requirement. That network is what you’re paying for, and it’s difficult to replicate.

Either way, you’d be better off buying than assembling — and a support-call feature that becomes a core part of the product should migrate.

When the gateway is the better call

The case is narrower and real: a support call is an occasional escalation path, not your product.

A customer clicks “talk to someone”, you create a room with max_participants: 2 and an empty timeout, mint two tokens, and the call happens. Afterwards the ticket needs the transcript stored, a follow-up email sent, and the whole thing attributed to a tenant for cost. Those three are already on the key:

#!/usr/bin/env bash
# Escalate a ticket to a live call, on one credential.
set -euo pipefail
API="https://api.infrai.cc"
TICKET="${1:?ticket id}"
AUTH=(-H "Authorization: Bearer ${INFRAI_API_KEY}" -H "Content-Type: application/json")

# 1. the room
curl -sS -X POST "${API}/v1/rtc/room/create" "${AUTH[@]}" \
  -d "{\"name\": \"support-${TICKET}\", \"max_participants\": 2, \"empty_timeout_s\": 120, \"metadata\": {\"ticket_id\": \"${TICKET}\"}}"

# 2. a token for the agent
curl -sS -X POST "${API}/v1/rtc/token/issue" "${AUTH[@]}" \
  -d "{\"room\": \"support-${TICKET}\", \"identity\": \"agent-7\", \"display_name\": \"Support\", \"ttl_s\": 900, \"can_publish\": true, \"can_subscribe\": true, \"can_publish_data\": true, \"is_admin\": true}"

# 3. tell the customer it's ready
curl -sS -X POST "${API}/v1/email/send" "${AUTH[@]}" \
  -d "{\"to\": \"customer@example.com\", \"subject\": \"Your support call is ready\", \"html\": \"<p>Join from your ticket page.</p>\"}"

Three services, one secret, one invoice. With a specialist that’s a second vendor account, a second token in your backend, a second dashboard when something breaks, and a second line in your monthly reconciliation — for a feature used a few times a day.

Cost, compared honestly

LiveKit and Agora price on participant-minutes, which is the right model for a video product and means an idle room costs nothing. Here token issue is a small per-call charge and room management reports billing_class: free, with the underlying vendor minutes flowing through your account — read the live figures from GET /v1/discovery/rtc.token.issue and your actual spend from GET /v1/account/usage, both free reads, both verified 2026-09-21.

Which is cheaper depends on call volume and duration, so measure with your own numbers rather than either vendor’s example. The structural point that survives repricing: a feature used a few times a day is dominated by the fixed cost of having another vendor at all, not by the per-minute rate — and platform rates here drift downward as vendor contracts improve.

How to decide in an afternoon

Build one call end to end on your real product with whichever you’re leaning toward, then count what you had to write: the join UI, the permission handling, the reconnection path, the “call ended” state. If that list was short because the vendor gave you components, you’ve found your answer, and it’s probably LiveKit.

If the list was short because the call is two people talking for four minutes and then never again, the gateway is enough — and the transcript, the email and the cost attribution afterwards were already handled.

References

Browse more rtc developer guides