A SIP trunk on Asterisk is a virtual phone line that connects your open-source PBX to the public switched telephone network through a VoIP provider, using the Session Initiation Protocol for signaling and RTP for media. Asterisk handles both inbound and outbound trunks through its PJSIP channel driver, giving you full dial-plan control, multi-provider failover, and deep troubleshooting visibility. This guide walks through the full setup, from endpoint definition to security hardening, in plain language. For teams that also need to bridge SIP calls into WebRTC applications, VideoSDK's telephony integration connects SIP trunks directly to real-time rooms.
Asterisk has been the workhorse of open-source telephony for over two decades, and in 2026 it remains one of the most deployed PBX platforms in the world. Pairing it with a SIP trunk replaces physical phone lines with an internet-delivered service, cutting call costs and unlocking programmable call routing. But the setup is where most teams stumble: registration failures, one-way audio, and NAT headaches are the classic rite of passage.
By the end of this article, you will understand how inbound and outbound SIP trunks work on Asterisk, how to configure them conceptually, how to troubleshoot the failures that actually happen in production, and how to secure the whole stack. Everything is explained in natural language, so you can translate the intent into your own configuration files with confidence.
Understanding SIP Trunking with Asterisk
A SIP trunk is a persistent, logical connection between your PBX and a VoIP provider that carries calls in both directions without a physical line. Asterisk is a natural home for SIP trunks because it speaks SIP natively, supports multiple simultaneous providers, and lets you route every call through a dial-plan you fully control. Typical deployments include business phone systems replacing legacy ISDN lines, intercom and door-entry integrations, remote extensions for distributed teams, and call-center backends where Asterisk fronts an IVR before handing calls to agents.
Inbound trunks deliver calls from the outside world into your Asterisk context tree. Outbound trunks carry calls from your extensions out to the PSTN through your provider. Most providers give you a single trunk that does both, but configuring and reasoning about them separately keeps your dial-plan clean.
Core Concepts of SIP Trunking
SIP, the Session Initiation Protocol, is the signaling layer: it sets up, modifies, and tears down calls, but carries no audio. The actual voice media travels over RTP, usually encoded with a codec such as G.711 or Opus. PJSIP is Asterisk's modern SIP channel driver, replacing the older chan_sip driver, and it organizes configuration around endpoints, authentication sections, and registrations. Registration is the process by which Asterisk (or your provider) proves identity and establishes where to send calls. NAT, network address translation, is the router behavior that rewrites addresses and breaks naive SIP setups unless you configure external address awareness. Understanding these five terms covers ninety percent of SIP trunking conversations.
Benefits of Using Asterisk for SIP Trunks
Asterisk's appeal comes from three properties. First, it is open source, so there is no per-seat licensing cost and no vendor lock-in on the PBX side. Second, it supports multiple providers simultaneously, which makes cost-based routing and failover straightforward. Third, its dial-plan engine gives you per-call control over routing, time conditions, announcements, and integration with external systems, something closed PBX products rarely allow at this granularity.
Configuring an Inbound SIP Trunk on Asterisk
An inbound SIP trunk on Asterisk is configured by defining a provider endpoint in the PJSIP configuration, attaching authentication credentials, and pointing incoming calls at a dial-plan context that routes them to extensions or an IVR. The work happens in three stages: defining the endpoint, setting the inbound context, and verifying that the provider's traffic is actually arriving.
Defining the Trunk Endpoint
The endpoint is the core object describing your provider in PJSIP terms. Conceptually, you create a named endpoint that identifies the provider's signaling address, specify the authentication credentials the provider will present (or that you will accept), and define how media flows, including which codecs you allow and whether direct media between endpoints is permitted. For inbound trunks, many providers authenticate by source IP rather than a password, so the endpoint often declares the provider's network as trusted rather than holding a secret. You also decide the transport, plain UDP, TCP, or TLS, at this stage. The endpoint block is where you express intent: this named entity is my provider, it talks on this address, with these codecs, and its calls belong to me.
Setting the Inbound Context
Once the endpoint exists, you assign it a context, which is the section of the dial-plan where incoming calls from that trunk begin their journey. This is the single most important routing decision: a context named for inbound provider calls lets you write rules that send calls to a reception extension, an IVR menu, a ring group, or voicemail outside business hours. Keeping the inbound context separate from your internal extension context prevents outside callers from ever dialing internal-only destinations, which is both a routing and a security practice. A typical pattern routes the main number to an IVR, direct-dial numbers to individual extensions, and anything unmatched to a receptionist or auto-attendant.
Verifying Registration and Call Flow
After configuration, you verify the trunk using Asterisk's command-line monitoring tools. The peer overview command shows whether the provider endpoint is reachable and whether any registration you perform is active; a healthy entry shows the correct address, a recent qualify response, and a status of reachable rather than unmonitored or unavailable. For IP-authenticated inbound trunks, there is no registration to check, so the real test is placing an inbound test call and watching the console output confirm the call entering your inbound context and hitting the intended extension. A successful inbound flow shows the provider's INVITE arriving, the context matching, and the extension ringing.
The overall inbound path looks like this:
Setting Up Outbound SIP Trunking in Asterisk
Outbound trunking is the mirror image: your extensions dial out, Asterisk matches an outbound pattern in the dial-plan, and the call is sent through the provider endpoint toward the PSTN. The three pieces are provider credentials and registration, outbound dial-plan rules, and quality monitoring with failover.
Provider Credentials and Registration
For outbound calling, most providers require Asterisk to register as a client, proving who it is before it may send calls. Conceptually, you define an outbound registration object that holds your provider-assigned username, password, and server address, plus a renewal interval that keeps the registration alive, typically around an hour, with automatic re-registration on expiry. The provider maps your registered identity to your account and allowed outbound caller IDs. Getting the renewal interval right matters: too long and a network blip can leave you silently unregistered; too short and you generate needless signaling traffic. The registration status should be treated as a monitored health signal, not a set-and-forget setting.
Outbound Dial-plan Rules
The outbound side of the dial-plan matches dialed patterns and sends them to the trunk. The common design is a dedicated outbound context where a pattern for external numbers, such as anything starting with a nine or a full national number length, triggers a call through the provider endpoint. Prefix stripping is the detail that bites people: if your users dial a leading access digit to get an outside line, the dial-plan must remove that digit before sending the number to the provider, or the provider rejects the call as an invalid number. Similarly, you may need to rewrite numbers into the full international format your provider expects. The rule of thumb is that what the user dials and what the provider receives are two different strings, and the dial-plan is where the translation happens.
Monitoring Call Quality and Failover
A production trunk needs active health monitoring. Asterisk can send periodic SIP OPTIONS requests to the provider, and a timely response marks the endpoint as reachable; missed responses mark it unavailable, which your dial-plan can use to prefer a secondary trunk. Latency checks to the provider's media servers give early warning of degraded paths before users complain. For failover, the standard pattern is a primary and secondary provider, with the dial-plan attempting the primary and falling back on congestion or unavailability. Even a simple two-trunk arrangement removes the single point of failure that sinks small-business phone systems.
The outbound path in full:
Common Issues and Troubleshooting for SIP Trunk Asterisk
Most SIP trunk problems on Asterisk fall into three families: registration errors, NAT and firewall issues, and audio problems. Each has recognizable symptoms and a standard diagnostic path.
Registration Errors
Registration failures show up as authentication rejections or timeouts. An authentication rejection means the credentials, username, password, or realm, do not match what the provider expects, and the fix is verifying each field against the provider's portal, paying attention to case sensitivity and whether the username is the account number or a separate SIP username. A timeout means the registration request never reached the provider or the reply never came back, which points to network issues: wrong server address, a firewall blocking the signaling port, or DNS resolving to an unreachable node. The console output during a failed registration attempt tells you which of the two you are facing, and that distinction is the whole diagnostic.
NAT and Firewall Challenges
NAT breaks SIP because the addresses inside SIP messages describe your private network, which the provider cannot reach. The remedy is configuring Asterisk with its external public address and the local network ranges, so it rewrites contact and media addresses correctly. Where the router rewrites ports unpredictably, a STUN server can discover the true external mapping, though explicit external-address configuration is more reliable for a server with a stable IP. Firewalls must permit the signaling port in both directions and the RTP media port range, typically a wide range of UDP ports, or you get registration without audio. On cloud deployments, a public IP on the Asterisk host itself sidesteps most of this class of problem entirely.
Audio Problems
One-way audio, where each party hears only the other or neither, is almost always a NAT or firewall media-path issue: signaling found a way through but RTP did not. The diagnostic is confirming that the RTP port range is open and that Asterisk is advertising the correct external address in its media descriptions. Codec mismatch appears as calls that connect but fail to carry voice, or immediate hangups; the fix is ensuring the trunk endpoint allows at least one codec the provider supports, with G.711 as the safe universal fallback. For jitter and choppy audio on unstable links, enabling and tuning the jitter buffer smooths packet-timing variation and is the first lever to pull before blaming the provider.
Security and NAT Considerations for SIP Trunk Asterisk
An internet-facing SIP server is scanned constantly by bots looking for open trunks to abuse, and toll fraud is the expensive consequence of a sloppy setup. Security for a SIP trunk on Asterisk has three layers: encryption, access control, and deployment isolation.
Enabling TLS and SRTP
Plain SIP sends credentials and call signaling in the clear, and plain RTP sends audio in the clear. TLS encrypts the signaling layer, protecting your registration credentials from interception, and SRTP encrypts the media layer, protecting conversation privacy. Enabling both is a high-level three-step process: obtain or generate a certificate for your Asterisk host, define a TLS transport in the PJSIP configuration that references it, and then assign that transport to your trunk endpoint and enable SRTP on it. Your provider must support TLS signaling for the trunk side; most major providers do in 2026, and it is a reasonable selection criterion if yours does not. Internal extensions should use the same encrypted transport so the protected path extends end to end where possible.
IP-Based Access Control
The strongest simple control on an inbound trunk is restricting which addresses may send it calls. If your provider publishes its signaling IP ranges, you configure the endpoint to accept traffic only from those addresses, and your firewall drops SIP traffic from everything else. This eliminates entire attack classes, including credential-guessing scanners, because their requests never reach the dial-plan. Combine it with a dial-plan that never lets inbound context callers reach outbound routes or internal-only features, and the practical attack surface shrinks to your provider's own network.
Deploying Asterisk Behind a Firewall or in a Container
Whether Asterisk runs on a VM, a container, or a bare-metal box, the isolation principles are the same: expose only the ports the trunk actually needs, keep the SIP signaling port and the RTP media range explicitly allowed, and deny everything else. Containerized deployments should run with host networking or a carefully mapped port range, because unmapped RTP ports are the leading cause of container-specific one-way audio. Keep the management interface bound to an internal network or behind a VPN, and treat the operating system firewall as the outer layer with Asterisk's own access control as the inner layer.
Choosing the Right SIP Provider for Asterisk
The provider determines half your trunk experience. Evaluate candidates on five axes. Pricing: compare per-minute rates for the regions you actually call, monthly trunk or channel fees, and whether inbound and outbound are billed differently. Codec support: Opus support improves quality on poor links, while G.711 compatibility is the baseline. Geographic coverage: confirm local number availability and PSTN termination quality in the countries you serve. SIP-URI support: if you want direct internet calling without PSTN termination, the provider must support it. API access: a REST API for provisioning numbers, pulling call detail records, and managing trunks programmatically turns your phone system into a component of your software stack rather than an island.
For teams building modern real-time applications, there is a further consideration: bridging telephony into WebRTC. VideoSDK's telephony and SIP integration routes inbound SIP calls through a gateway into VideoSDK rooms, where browser and mobile participants, or even AI voice agents, join the same conversation. That pattern is increasingly common for support lines that need both phone callers and web users in one session, and it pairs naturally with VideoSDK's AI voice agent capabilities for automated call handling.
Definitions Glossary
SIP Trunk: A logical, always-available connection between a PBX and a VoIP provider that carries inbound and outbound calls over the internet, replacing physical phone lines.
Asterisk PBX: An open-source telephony engine that implements SIP through its PJSIP channel driver and routes calls according to a developer-defined dial-plan.
PJSIP: Asterisk's modern SIP channel driver, organized around endpoints, authentication sections, registrations, and transports, which replaced the legacy chan_sip driver.
Registration: The process by which Asterisk authenticates to a provider and establishes where inbound calls should be delivered, renewed at a configured interval.
NAT Traversal: The set of techniques, including external address configuration, STUN, and port forwarding, that let SIP signaling and RTP media work correctly through network address translation.
SRTP: Secure Real-time Transport Protocol, the encrypted form of RTP that protects voice media from interception on the trunk.
Key Takeaways
- A SIP trunk on Asterisk is configured as a PJSIP endpoint plus a dial-plan context, with inbound and outbound sides best designed as separate concerns.
- Registration failures are credential or network problems, and the console output distinguishes which one you have.
- One-way audio is almost always a NAT or RTP port-range issue, not a provider fault, so verify external address configuration and firewall rules first.
- TLS and SRTP encrypt signaling and media, while IP-based access control removes scanners from the equation entirely.
- Failover across two providers, driven by SIP OPTIONS health checks, removes the single point of failure from small-business telephony.
- Provider choice should weigh pricing, codec support, geographic coverage, SIP-URI support, and API access, with telephony-to-WebRTC bridging available through VideoSDK's SIP integration when phone callers need to join real-time sessions.
Conclusion
Setting up a SIP trunk with Asterisk rewards methodical work: define the endpoint, wire the contexts, verify registration, then harden with TLS, SRTP, and IP allow-listing before you go live. The troubleshooting section of this guide is the part you will revisit most, because registration errors, NAT quirks, and one-way audio are the three problems that account for nearly every production incident on Asterisk SIP trunks. Once your trunk is stable, the natural next step is extending it, whether through multi-provider failover, API-driven provisioning, or bridging phone callers into WebRTC rooms with VideoSDK's telephony integration. You can start experimenting today with a free account at app.videosdk.live, and the VideoSDK docs cover the full SIP-to-room architecture. What are you building with your Asterisk SIP trunk? 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