Skip to main content
RevDesk gives you three ways to connect a person to a live phone call. They share a common security baseline; they differ in where the audio lives, whether the destination is locked by construction, and whether you can add AI to the call.
On a phone (cellular, no browser), use the bridge path (C): you call the API and RevDesk rings both parties, then bridges them. There is no proxy number you dial that forwards you onward — RevDesk always places the call. Paths A and B run the audio through the browser (WebRTC) instead.

​
What every path enforces (the baseline)

No matter which path you choose:
  • Scoped, single-use tokens. Each calling token is issued for exactly one call and is invalidated when that call ends; it can’t be reused.
  • You can only call as a number you own. Caller ID is validated at issuance against your verified numbers.
  • Per-call attribution. Every call is logged to your org + the issuing user + the from/to. Reconcile via GET /v1/calls.
  • Account guardrails. A destination allowlist, a daily spend cap, a concurrency cap, and a max per-minute rate. This bounds the blast radius even if a token were leaked.
The paths differ in the last mile: whether the destination is merely scoped-and-bounded, or impossible to change because the browser never dials at all.

​
The three paths

​
Path A: Call from your browser

Available today. Staff click Call and talk through their browser, no phone line needed. The browser is handed a scoped, single-use token for that one call. Quickest to launch and proven-stable.
Browser calling runs on WebRTC, the open web standard for live audio that lets a web page place and receive calls with no plugin and no phone line. Paths A and B are both WebRTC; path C uses a regular phone.
The destination is declared, attributed, and guardrail-bounded, but the browser is what dials, so this path does not lock the destination by construction the way B and C do.

​
Path B: Browser call, placed by RevDesk

Available (beta). Same in-browser experience, but the browser never dials. RevDesk places the call and the browser simply joins it, using a room-join token from POST /v1/room-token and the RevDesk browser SDK. Because the destination is set server-side, it can’t be changed by the client or replayed to reach a different number, and because the call lives in a room you can add an AI voice to the call (mid-call assist, AI voicemail, AI follow-ups; on the roadmap).

​
Path C: Bridge — connect on your own phone (cellular)

Available today. This is the path for a regular phone, no browser or SDK involved. Staff click Call; their own phone rings; when they answer, the other party is already on the line. RevDesk places both legs, so the destination is locked server-side and the other party only ever sees your RevDesk number, never the staff member’s personal number. There is no proxy number to dial that forwards onward: a number anyone could dial can’t authenticate the caller, lock the destination, or mask caller ID per call. Placing both legs from the server is what makes per-call attribution and number masking possible.

​
Which should I use?

Your situationUseWhy
Internal staff dialing; simplest, fastest setupA: Browser (today)Proven, quick to ship; scoped tokens + guardrails are enough for trusted internal users.
Security- or privacy-sensitive / regulated (e.g. healthcare), and the person can answer on a phoneC: Connect your phone (today)Server-placed, hard destination lock, masked end-to-end. The available option that meets a strict bar today.
You want the hard lock in the browser (no phone), or you want AI voicemail / follow-upsB: Browser, RevDesk-placed (beta)Same hard lock as C, but in-browser, and the path that enables AI on the call.
For a hard destination lock, use B or C. Because RevDesk places the call, the destination can’t be changed by the client and the token can’t be replayed to reach a different number. Path A scopes and bounds the destination but does not lock it by construction.
AI on a live call (inject an AI voice, AI voicemail, AI follow-ups) requires a RevDesk-placed path (B or C). The direct browser path (A) connects the audio straight from the browser, so there’s no room for an agent to join. These AI capabilities are on the roadmap for B and C.

​
Reliability and UX tradeoffs

Beyond security, the paths differ in how the call actually behaves:
A: BrowserB: Browser, RevDesk-placedC: Connect your phone
Audio pathWebRTC (data)WebRTC (data)Cellular voice
Depends on the user’s networkYes; needs a healthy connection + micYes; needs a healthy connection + micNo; it’s a normal phone call
Connect latencyInstant (browser dials)Short delay (RevDesk places it, browser joins)Short delay (RevDesk rings both legs)
Mic / browser permissionsRequiredRequiredNone
In-app controls (mute, transfer)YesYesLimited (it’s a phone call)
AI on the callNoYes (roadmap)Yes (roadmap)
A and B are best when staff live in the app on a solid connection. C is the most resilient: it falls back to the cellular network and needs no mic or browser permissions.

​
Same surface, swap the path

Paths B and C expose the same client surface. Issue a token, attach a callUpdate handler, and switching paths is close to a one-line change: 
import { RevDesk } from "@revdesk/sdk";
import { RevDeskRoom } from "@revdesk/webrtc";

const revdesk = new RevDesk({ apiKey: process.env.REVDESK_API_KEY! });

// Path B: browser joins a RevDesk-placed call
const { token, room_url, call_id } = await revdesk.webrtc.getRoomToken({ from_number, to_number });
const call = new RevDeskRoom({ token, roomUrl: room_url, callId: call_id });
call.on("callUpdate", render);
await call.join();

// Path C: bridge to a real phone. RevDesk rings connect_number; the destination
// still only ever sees from_number.
await revdesk.calls.dial({ from_number, to_number, connect_number });

​
How they work

In A, the browser places the call itself. In B and C, RevDesk places the call and the client only joins it, so the destination is fixed and can’t be changed. See WebRTC security for the token model, caller-ID handling, the guardrails, and concern-by-concern answers.