SIP Trunking & WebRTC
Trunks that size themselves.Calls that live in your app.
SIP trunking carries calls between TelVox and your PBX or carrier over the internet; WebRTC puts a real call inside your browser or mobile app. Connect speaks both from one API, and dynamic trunking means you configure and scale trunks yourself, live today.
Dynamic SIP trunking · live
Configure your own trunks. Capacity follows your traffic.
Trunk provisioning used to run through the TelVox team. It no longer has to: dynamic SIP trunking is shipped, so you create trunks, register endpoints and bring your own carrier without a ticket. Connect's REST API, SDKs and self-serve signup remain versioned v0.x; trunk configuration itself is live.
Elastic capacity
Trunk capacity follows your traffic. Lanes grow as call volume climbs and release when it falls, with no provisioning ticket in the loop.
Self-serve trunk configuration
Create, configure and resize trunks yourself, from the dashboard or straight through the API. This is shipped and live today, not a roadmap line.
Bring your own carrier
Point an existing carrier, PBX or softswitch at TelVox and keep the contracts and rates you already have. BYOC is part of the same self-serve flow.
Registration, 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.
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.
One API, two transports
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.
WebRTC
A real call, inside the browser.
The WebRTC leg runs on the same softphone engine that answers calls in Dial every day. Your server mints a short-lived access token with a voice grant, the client registers with it, and the secret never leaves your backend.
WebRTC in-app calling
Connect browser and mobile clients over WebRTC for embedded calling. It is 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.
Quality signals
- MOS
- codec
- jitter
- packet loss
- RTT
- transport
Every signal here is read live from the softphone on the call, not sampled after the fact.
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 created · grant: voice · shape may differ at GA
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.
Put a call in your app, or your carrier.
Sign up, spin up a trunk yourself and wire the WebRTC access-token flow into your stack.