Skip to content

TelVox · Connect

SIP trunks and WebRTC, from one API.

Bring calls in over SIP and connect browser or mobile clients over WebRTC. Your server mints a short-lived access token with a voice grant; the client consumes it — the secret never leaves your backend.

POST/v1/access-tokens
# illustrative — shape may differ at GA
# server-side only — your API secret never reaches the browser
curl https://api.telvox.dev/v1/access-tokens \
  -H "Authorization: Bearer $TELVOX_API_KEY" \
  -d identity="agent-204" \
  -d ttl=900 \
  -d grant="voice"
201 createdgrant: voice

One API, two transports

Existing telephony and in-app calling, side by side.

SIP reaches the carriers, PBXs and softswitches you already run. WebRTC puts a call inside your web and mobile apps. Connect speaks both off the same credentials.

Quality signals

  • MOS
  • codec
  • jitter
  • packet loss
  • RTT
  • transport

What's in the box

Connectivity that meets your stack where it is.

The softphone, SIP registration and live metrics are real and shipped in Dial today. Self-serve trunk configuration is honestly on the roadmap.

SIP trunking, in and out

Bring calls in and send them out over SIP, with registration to your endpoint. Reach existing PBXs, carriers and softswitches without leaving the Connect API.

WebRTC in-app calling

Connect browser and mobile clients over WebRTC for embedded calling — the same softphone engine that powers Dial's in-browser agent client, exposed to your app.

Short-lived access tokens

Your server mints a short-lived JWT carrying a voice grant; the client consumes it to register. The API secret never reaches the browser or device.

Live call-quality metrics

Read live MOS, negotiated codec and transport state straight from the softphone — the same real-time quality signals Dial surfaces on every WebRTC leg.

Secrets encrypted at rest

SIP credentials and signing keys are stored AES-256-GCM-encrypted, and tokens are minted single-use and short-lived — the same secret handling Dial ships.

BYOC — team-assisted today

Bring-your-own-carrier and trunk provisioning happen with the TelVox team today. Self-serve trunk configuration is on the roadmap, not yet shipped.

Honest status

BYOC is team-assisted today; self-serve is roadmap.

The SIP registration, WebRTC softphone and live MOS / codec / transport metrics are real and run in Dial right now. What is not shipped yet is in-API, self-serve trunk configuration — today we provision your trunk and bring-your-own-carrier setup with the TelVox team. We frame that as roadmap rather than implying it already exists.

Talk to the team

Questions

SIP & WebRTC FAQ

Your API key (a SID plus secret) lives only on your server. To put a browser or mobile client on a call, your backend mints a short-lived JWT with a voice grant and hands that token to the client. The token expires quickly and the underlying secret is never shipped to the device, so a leaked token has a tight blast radius.

Yes. Live MOS, the negotiated codec and transport state come straight from the same JsSIP-based softphone that runs in Dial today — these are real, shipped quality signals, not mock data. The REST shape for exposing them to your own app is in developer preview.

Today BYOC and trunk provisioning are team-assisted — we configure your SIP trunk and registration with you. Self-serve, in-API trunk configuration is honestly on the roadmap, not something we ship yet. Tell us your carrier setup and we'll map what's possible now versus at GA.

No — the snippet here is illustrative. Connect is in developer preview, so the exact endpoint, fields and token claims may change before general availability. We'll publish versioned reference docs as the shapes firm up.

Put a call in your app — or your carrier.

Join the developer preview and we'll wire up SIP, WebRTC and the access-token flow for your stack.