A call trunk is a virtual communication channel that carries voice calls between your application and the public phone network (PSTN) over the internet, typically using SIP. VideoSDK's telephony integration lets developers bridge these call trunks into real-time WebRTC rooms, so phone callers, web participants, and AI voice agents can all join the same conversation. You can read the full telephony documentation at VideoSDK Telephony.
Every phone call your app makes or receives rides on a call trunk, and most developers never think about it until something breaks. A call drops mid-conversation, a caller ID shows up wrong, or an outbound campaign silently fails because the trunk rejected authentication. At that point, the trunk stops being invisible infrastructure and becomes your most urgent debugging problem.
This guide explains what a call trunk actually is, how SIP trunking routes calls in both directions, and how VideoSDK's telephony integration lets you connect PSTN callers directly into WebRTC rooms, including AI voice agents. By the end, you'll understand the full call path from a desk phone to your application and back, plus the pitfalls that catch most teams in production.
What Is a Call Trunk?
A call trunk is defined as a logical channel that carries a single voice call between two endpoints in a telephony network. The term comes from the old circuit-switched world, where a trunk was a physical wire pair connecting a private branch exchange (PBX) to the telephone company's central office. Each simultaneous call occupied one trunk, so a business with eight trunks could handle at most eight concurrent calls.
In modern VoIP systems, the physical wire is gone, but the concept survives. A call trunk is now a virtual channel negotiated over the internet using the Session Initiation Protocol (SIP), which handles call signaling: setting up, modifying, and tearing down sessions. The actual voice media travels separately, usually as RTP packets encoded with a codec like Opus or G.711.
A call trunk works by establishing a negotiated session between your system and a carrier's SIP infrastructure. When a call starts, the two sides exchange signaling messages that agree on codecs, addressing, and media endpoints. Once agreed, audio flows for the duration of the call, and the trunk is released when either side hangs up.
For developers, the practical unit is the SIP trunk: a persistent, authenticated connection between your application (or your provider's gateway) and a carrier that can reach any phone number on the PSTN. Providers like Twilio, Vonage, Telnyx, and Plivo all sell SIP trunking in slightly different flavors, but the underlying model is the same. VideoSDK provides call trunking through its telephony and SIP integration, which bridges SIP trunks into VideoSDK rooms where WebRTC participants, including AI voice agents, can interact with the caller.
Core Components of a Call Trunk
Every call trunk, regardless of provider, is built from the same four pieces. The signaling layer uses SIP to negotiate call setup and teardown between endpoints. The media layer carries the actual audio, typically as encrypted RTP streams. The codec set defines how audio is compressed, with Opus and G.711 being the most common defaults. Finally, the routing rules decide where a call goes: which inbound call reaches which room or agent, and which outbound call uses which caller ID and number pool. Understanding these four components makes almost every trunk configuration problem diagnosable, because every failure traces back to one of them.
How Call Trunks Work in SIP Telephony
SIP telephony separates call control from call media, and understanding that split explains nearly all trunk behavior. Signaling messages travel between SIP endpoints over a persistent, authenticated relationship, while audio flows directly between the negotiated media endpoints. This is the same architectural split WebRTC uses, which is why bridging SIP trunks into WebRTC rooms is a natural fit.
When your application connects a call trunk, three things happen in sequence. First, both sides authenticate, usually via SIP digest authentication, IP allow-listing, or transport-layer security with mutual certificates. Second, the carrier and your system exchange capabilities, including which codecs each side supports and where media should be sent. Third, calls flow in either direction for as long as the trunk relationship stays active. The trunk itself is not per-call; it is the standing connection that individual calls ride on.
VideoSDK's implementation adds a translation layer. Its inbound and outbound gateways convert between SIP signaling on the PSTN side and WebRTC media inside a VideoSDK room. That means a caller on a physical desk phone and a participant in a browser-based app share the same room, the same audio stream, and the same event model. An AI voice agent built with the VideoSDK Agent SDK can join that same room and hold a conversation with the phone caller.
Inbound Call Flow
An inbound call starts when someone dials a phone number that your carrier routes to your SIP trunk. The carrier sends a SIP invitation toward your configured endpoint, which in a VideoSDK deployment is the Inbound Gateway. The gateway authenticates the request, applies your routing rules, and creates or joins a VideoSDK room based on how you've mapped numbers to rooms.
Once the room exists, the gateway bridges the caller's PSTN audio into the room as a participant stream. Any WebRTC participants, AI agents, or other SIP callers already in the room receive that audio in real time, and their audio is mixed back out to the phone caller. From the caller's perspective, it's just a phone call. From your application's perspective, the caller is a participant with a stream you can transcribe, record, or feed into an AI pipeline. DTMF keypresses, like menu selections, arrive as events your logic can act on.
Outbound Call Flow
Outbound calls reverse the direction. Your application requests a call through the telephony API or the Outbound Gateway, specifying the destination number and which caller ID from your number pool to present. The gateway translates that request into SIP signaling toward the carrier, the carrier places the call over the PSTN, and when the callee answers, their audio is bridged into the VideoSDK room your application designated.
This pattern powers outbound AI phone agents: your agent worker initiates the call, and once the callee answers, the agent's speech pipeline (speech-to-text, LLM, text-to-speech) processes the conversation in the room. Call transfer, including warm transfer to a human agent, is handled through the same session lifecycle. The key detail is that the outbound call is a room participant like any other, so all your existing room logic, recording, and analytics apply unchanged.
VideoSDK's Telephony Integration
VideoSDK's telephony integration is built around three pieces: an Inbound Gateway that accepts calls arriving from SIP trunks, an Outbound Gateway that places calls into the PSTN, and a routing rules engine that maps phone numbers and call patterns to VideoSDK rooms. The design goal is that a phone caller becomes a first-class room participant, not a second-class audio source bolted onto the side of your app.
This matters for developers because it collapses two worlds that usually require separate stacks. Traditionally, you'd build a WebRTC application for in-app users and a separate VoIP integration for phone users, then stitch them together with conferencing hardware or fragile media bridges. With VideoSDK, both populations land in the same room, share the same events, and can be recorded, transcribed, and analyzed through one API surface. The REST APIs let you manage rooms, participants, and recordings programmatically from your backend.
The integration works with any major SIP trunk provider, including Twilio, Vonage, Telnyx, and Plivo, so you can keep your existing carrier relationships and number inventory. VideoSDK sits between your trunk and your rooms, handling the SIP-to-WebRTC translation, DTMF event delivery, call transfer, and secure media relay. Geo-fencing and IP whitelisting are available for organizations with regional compliance requirements.
Setting Up a Call Trunk with VideoSDK
Setting up a call trunk with VideoSDK follows a clear sequence. First, you connect your SIP trunk provider by pointing your carrier's SIP registration or peer configuration at VideoSDK's gateway endpoints, which you'll find in the telephony documentation. Second, you define routing rules that map inbound numbers to rooms, deciding whether each number always lands in the same room, spawns a new room per call, or routes based on schedules or caller attributes. Third, for outbound calling, you configure your number pool and caller ID preferences so the right identity is presented on each call. Once configured, a test call to one of your numbers should land as a participant in the expected room, with audio flowing in both directions. That end-to-end test is the fastest way to validate that signaling, media, and routing are all correct.
Authentication and Security
Call trunk authentication happens at two layers, and you need both. At the SIP layer, VideoSDK supports digest authentication, secure SIP with TLS-encrypted signaling, and IP whitelisting so only your carrier's known addresses can send calls to your gateway. At the application layer, room access is controlled by VideoSDK meeting tokens, generated server-side with your API credentials, which determine what a phone participant can do once bridged into a room. Never expose your API secret in client-side code. For sensitive deployments, end-to-end encryption for WebRTC participants and geo-fencing for telephony traffic add further controls. Treat your trunk credentials like database passwords: rotate them, scope them, and monitor for unexpected call patterns.
Managing Caller ID and Number Pools
Caller ID management is where outbound calling earns or loses trust. Carriers enforce strict rules about presenting numbers you own or are authorized to use, and violations get your numbers flagged or blocked. Best practice is to maintain a number pool organized by region and use case, then select the caller ID per call so it matches the callee's area where possible. This improves answer rates significantly for outbound campaigns. In VideoSDK, you specify the caller ID when initiating an outbound call through the telephony API, and you can maintain multiple numbers across regions within the same integration. Track answer rates per number, because carriers and carriers' spam filters treat numbers differently over time.
Common Pitfalls and Best Practices
Most call trunk failures in production trace back to a small set of recurring causes. Teams that handle these upfront avoid the majority of 2 a.m. incidents.
IP Allow-Lists and NAT
SIP was designed before NAT was ubiquitous, and it shows. When your carrier allow-lists your egress IP but your traffic leaves through a different address due to NAT or load balancing, signaling gets silently dropped. The fix is to pin your SIP egress to known, static addresses and register those with both your carrier and VideoSDK's IP whitelisting. Also verify that media ports aren't being rewritten by middleboxes, which causes one-way audio, the classic symptom of a NAT traversal problem.
Codec Compatibility
A call fails to connect or connects with no audio when the two sides can't agree on a codec. Most carriers support G.711 and G.729; most WebRTC stacks prefer Opus. VideoSDK's gateway performs transcoding between these worlds, but you should still confirm your carrier's supported codec list and avoid forcing exotic codecs at the trunk level. Keep the trunk configuration on widely supported defaults and let the gateway handle translation.
Rate Limits and Capacity Planning
SIP trunks have concurrent call limits, and carriers also enforce calls-per-second limits on outbound bursts. A campaign that fires a thousand calls simultaneously will get throttled unless you've negotiated higher limits. Plan capacity by measuring peak concurrent calls, not total calls, and add headroom of at least 30 percent. Monitor rejection responses from the carrier and back off automatically rather than retrying aggressively, which can trigger temporary blocks.
Comparing VideoSDK Call Trunking to Other Providers
Comparing call trunking options is really comparing integration models, because the underlying SIP mechanics are similar everywhere. Twilio excels at programmable voice with a massive ecosystem but keeps phone calls in its own silo unless you build custom bridging. Telnyx offers strong raw SIP trunking with competitive pricing for high volume. Vonage and Plivo sit in similar territory with different regional strengths. LiveKit and other WebRTC-first platforms generally require you to bring your own SIP gateway.
VideoSDK's differentiator is that the call trunk lands directly in the same room model as your video and audio calling, with AI voice agents as first-class participants. If your product mixes in-app users, phone callers, and AI agents in one conversation, that unified model removes an entire layer of integration work.
Comparison Table
[LINKABLE ASSET — comparison table]
| Provider | Trunk Model | WebRTC Room Bridging | AI Agent Support | Best For |
|---|---|---|---|---|
| VideoSDK | SIP gateway into rooms | Native, same room model | Built-in via Agent SDK | Mixed web, phone, and AI conversations |
| Twilio | Programmable voice | Requires custom bridging | Via separate integrations | Broad telephony ecosystem needs |
| Telnyx | Raw SIP trunking | Bring your own gateway | DIY pipeline | High-volume, cost-sensitive outbound |
| Vonage | SIP trunk + APIs | Partial, separate products | Via Voice API | Enterprise communications suites |
| Plivo | SIP trunk + APIs | Requires bridging | DIY pipeline | Regional coverage and pricing flexibility |
The most important row distinction is the second column: only VideoSDK bridges the trunk natively into the same room model used for video calling, which is decisive when phone callers must interact with in-app participants or AI agents.
Real-World Use Cases
Customer Support Centers
A support center typically receives calls from three channels: phone, web, and in-app chat. With a call trunk bridged into VideoSDK rooms, a phone caller and a web visitor can be handled by the same agent console, with the same recording, transcription, and analytics. When a phone conversation needs escalation, warm transfer moves the caller to a specialist without dropping the session, and the AI agent can handle after-hours calls entirely, collecting context before a human joins in the morning.
Telehealth Platforms
Telehealth has a hard requirement that many patients, especially older ones, join by phone rather than an app. A call trunk lets the patient dial a number and land in the same consultation room as the doctor's video participant. The session is recorded and transcribed through the same APIs as the video visit, so clinical documentation works identically regardless of how the patient connected. Post-call summaries generated from the transcript cover both channel types.
Call Trunk Architecture Diagram
The diagram below shows the full call path for a bridged trunk: a PSTN caller reaches the carrier, the carrier hands the call to VideoSDK's Inbound Gateway over SIP, and the gateway bridges the caller into a room alongside WebRTC participants and an AI voice agent.
Definitions Glossary
Call Trunk: A logical channel that carries one voice call between two telephony endpoints, originally a physical circuit between a PBX and the central office, now a virtual SIP-negotiated session.
SIP Trunking: A persistent, authenticated connection between an application and a carrier that carries call signaling over the internet, letting VoIP systems place and receive PSTN calls without physical lines.
PSTN Gateway: A translation layer that converts between traditional circuit-switched phone signaling and internet-based VoIP protocols, bridging phone networks with applications.
DTMF: Dual-tone multi-frequency signaling, the tones generated when a caller presses phone keypad digits, delivered as events your application can use for menus and input collection.
Warm Transfer: A call transfer where the transferring agent briefs the receiving agent before handing off the caller, keeping the session alive so the caller never hears dead air.
Key Takeaways
- A call trunk is a virtual channel that carries a single voice call between your application and the PSTN, negotiated over SIP with media flowing separately as encoded RTP audio.
- VideoSDK's telephony integration bridges SIP trunks directly into WebRTC rooms, so phone callers, browser participants, and AI voice agents share one conversation with unified recording and transcription.
- Inbound calls arrive through the Inbound Gateway and routing rules; outbound calls are placed through the Outbound Gateway with caller IDs drawn from your number pool.
- Most production trunk failures come from NAT and IP allow-list mismatches, codec disagreements, or exceeded concurrent-call and calls-per-second limits.
- Caller ID discipline matters: present only numbers you own, match region where possible, and monitor per-number answer rates to keep outbound campaigns healthy.
Conclusion
Call trunks are the quiet backbone of every voice feature that touches the phone network, and understanding them turns mysterious call failures into diagnosable configuration issues. For developers building products where phone callers must meet web users and AI agents in the same conversation, VideoSDK's telephony integration removes the bridging work entirely. Start with the VideoSDK Telephony docs, explore the AI Agents guide for voice agents, and grab a free API key at app.videosdk.live to place your first bridged call. What are you building with call trunks and VideoSDK? Drop a comment, I'd love to hear what kind of telephony use case you're working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ