Fresh out of the box, ICTPBX is perfectly happy talking to itself. Internal extensions can call each other all day long. What it can’t do yet is reach a single phone number out in the real world, and for that you need a SIP trunk, the on-ramp that connects your system to the public phone network. The good news is this isn’t a big project. With your provider’s credentials sitting in front of you, you’ll be done in roughly ten minutes. I’ll walk through every setting you touch and, just as importantly, tell you what each one is actually for, so you’re configuring the thing instead of blindly pasting in values and hoping for the best.
Before you start
Round up a few things first, because nothing stalls a setup faster than getting halfway in and realizing you’re missing a password. You’ll want ICTPBX installed and running (that’s the ICTCore, FreeSWITCH, and Angular stack), admin access to the web interface, and an active SIP trunk account with a VoIP provider. From that provider specifically, you need their SIP server hostname or IP, your SIP username and password, and at least one DID, which is just industry shorthand for an inbound phone number.
On the network side, know your server’s public IP address and make sure UDP port 5060 (that’s the SIP signaling) and the RTP port range (usually 10000 to 20000) are open in your firewall. One last thing worth nailing down now: ask whether your provider uses registration-based or IP-based authentication, because the steps diverge a little depending on the answer.
Step 1: Collect your provider credentials
Don’t open ICTPBX just yet. First, go dig through your provider’s portal or that welcome email and write everything down, because grabbing it all now is exactly what saves you from a trunk that looks fine but silently refuses to connect. You’re after the SIP server (the proxy, usually something like sip.providername.com or a bare IP), your SIP username (often your account number or a trunk-specific name), and the matching SIP password. Note the authentication type too, registration-based or IP-based.
A couple more. Codecs: nearly every provider supports G.711 ulaw and alaw, and some throw in G.729, so jot down which ones yours offers. And your DID numbers, written in E.164 format, meaning with the country code and a leading plus sign, like +14085551234. Got all of it? Good. Trying to wing this with partial credentials is the single most common reason people end up troubleshooting a dead trunk for an hour.
Step 2: Add the trunk in ICTPBX
Now log in to the admin interface and find Trunks > Add Trunk. The menu wording drifts a little between ICTPBX versions, but it always lives under a Trunks or Gateway section somewhere. Most of the form is straightforward once you know what each field is asking for. Give the trunk a name you’ll actually recognize later in your dial rules, something like “Twilio-US-Main” rather than “trunk1”. Drop in the SIP server hostname or IP your provider handed you, and leave the SIP port at 5060 unless they told you otherwise, since a handful use 5080 for TLS. Username and password go in exactly as supplied, and the From User and From Domain fields are usually just the username and SIP server again, though some providers insist you set them so your outbound caller ID comes through right.
The one field that catches people out is Registration. Switch it to Yes for registration-based auth, where your server logs in to the provider. Switch it to No for IP-based auth, where you instead whitelist your server’s IP on the provider’s side. Get that backwards and the trunk will never come up, no matter how perfect your password is. Fill it in, hit save, and ICTPBX tries to register on the spot.
Step 3: Confirm it registers
Head to Trunks > Status (or the trunk list view). Your new trunk should flip to Registered within 30 to 60 seconds. If it stubbornly sits on Unregistered or Failed, stop right there, because a broken trunk won’t carry a single call. Work through these in order: re-type the username and password by hand (copy-paste slip-ups are the usual villain), confirm the SIP server hostname actually resolves from your server, check that UDP port 5060 is open outbound on the firewall, and double-check whether the provider expects IP-based auth, since if they do and you’ve set Registration to Yes, no amount of correct credentials will ever get it to register.
One wrinkle to keep in mind: with IP-based authentication, the trunk can read “Unregistered” even when it’s working perfectly, because the provider routes calls straight to your IP without any registration handshake. So don’t trust the status light here, just prove it with a real call in Step 5.
Step 4: Pick your codecs
Open the trunk’s settings and find the codec section, then add the ones your provider supports in your order of preference. For most deployments, lead with G.711 ulaw (PCMU), the safe default that works with practically every provider and phone. Follow it with G.711 alaw (PCMA) if you’re in Europe or a region where that’s standard. Add G.729 only if your provider supports it and you genuinely need the bandwidth savings, and be aware it needs a license on some FreeSWITCH builds.
Strip out anything your provider doesn’t support. Leaving dead codecs in the list won’t break the connection, but it piles on pointless negotiation overhead and can trip up the stricter providers. Since ICTPBX rides on FreeSWITCH, whatever you set here flows straight into the FreeSWITCH SIP profile for this trunk, so if you’ve got SSH access and want to be certain, peek at the generated gateway XML after saving.
Step 5: Route your inbound DIDs
A registered trunk still won’t answer inbound calls on its own. You have to tell ICTPBX what to do when a call lands on each DID. Go to Inbound Routes (sometimes labeled DID Management), click Add Inbound Route, and set three things: the DID number exactly as your provider sends it in the SIP INVITE (usually E.164 without the plus sign, like 14085551234), the trunk you just built, and the destination, whether that’s an extension, a ring group, an IVR, a queue, or voicemail.
That DID format trips people up constantly, so watch it: some providers prepend a 1, some don’t, and ICTPBX needs an exact match. Got more than one number? Create a separate inbound route for each. They can all point at the same destination or scatter to different ones, whatever suits you. The ICTPBX features overview lists every routing destination available, and in a multi-tenant deployment you can route DIDs straight to sub-accounts, which is precisely what white-label and managed-service operators are after.
Step 6: Add an outbound dial rule
Outbound calls need a rule that tells ICTPBX which trunk to use and how to format the number before handing it off. Go to Outbound Routes, click Add Route, and give it a descriptive name like “All US Outbound via VoIP.ms”. Then set a dial pattern that catches the numbers you want on this trunk, for US calls 1NXXNXXXXXX covers the standard 10-digit-plus-1 format, while 011. catches anything international starting with 011. Pick the trunk in the trunk sequence, and list more than one if you want failover, so ICTPBX rolls to the next when the primary can’t complete a call.
One more knob worth knowing: prepend and strip digits. If your users dial 10 digits but the provider expects 11, prepend the “1” automatically. If they dial 9 for an outside line and the provider doesn’t want it, strip it off. Save the route, and remember ICTPBX matches dial rules top to bottom, so put your most specific patterns first.
Step 7: Test both directions
Don’t declare victory until you’ve tested both ways. For outbound, log into a SIP softphone registered to ICTPBX and dial your own mobile. Check that the call connects, audio runs cleanly in both directions, and the caller ID on your phone matches what you set in the trunk’s From User field. For inbound, call your DID from an outside phone and confirm it rings the destination you configured. Listen closely, and compare it to a plain mobile-to-mobile call. Noticeable jitter or delay almost always points at your network rather than the trunk itself. If both directions sound clean, you’re live. Our IP PBX guide digs into how trunks fit into the wider ICTPBX architecture if you want the bigger picture.
Troubleshooting
A few failures show up again and again, so here’s how to read them. If the trunk registers but outbound calls die instantly with a “403 Forbidden” or “401 Unauthorized”, the provider is bouncing your calls even though login worked. Usually that’s a caller ID they haven’t verified, or outbound calling that’s switched off on your account. Open the provider portal, confirm outbound is enabled, and make sure your caller ID number is verified, because plenty of providers won’t carry a thing until you’ve whitelisted it.
If inbound calls never reach the destination you set, the DID in your route almost certainly doesn’t match what the provider sends. They might send 4085551234 while your rule waits for 14085551234, or the reverse. With SSH access, run ngrep or tcpdump on port 5060, read the To: header on the incoming INVITE, and match your pattern to that exact format.
One-way audio, where one side can’t hear the other, is a NAT problem nearly every time. The call connects (signaling is fine) but the RTP media stream is blocked one way. Set your server’s external IP correctly in the FreeSWITCH SIP profile’s ext-sip-ip and ext-rtp-ip settings, and make sure the RTP range (10000-20000 UDP) is open both directions on the firewall. And if calls connect but sound jittery or robotic, suspect the network path, not your config, check the server’s bandwidth during a live call, watch for noisy neighbors on a shared VPS, and pin G.711 ulaw as the required codec so negotiation can’t quietly slide to a compressed one.
Frequently Asked Questions
Can I add multiple SIP trunks for redundancy? Absolutely, and you should if uptime matters. Add each provider as its own trunk, then list them in order on your outbound routes, primary first. When the primary can’t complete a call, ICTPBX quietly rolls to the next.
Does ICTPBX support encrypted calls with SIP TLS and SRTP? FreeSWITCH underneath it does, both encrypted signaling (TLS) and encrypted media (SRTP). Whether that’s surfaced in the admin panel or needs FreeSWITCH-level config depends on your build, so if encryption is non-negotiable, for healthcare or legal clients say, confirm it with ICT Innovations at service.ictinnovations.com before you deploy.
My provider uses IP authentication instead of registration. Now what? Set Registration to No when you build the trunk, then add your server’s public IP to the provider’s allowed list. The trunk may read “Unregistered” on your side, which is normal here, so prove it with a live call instead of staring at the status light.
Do I need a separate trunk per DID? No. One trunk happily carries dozens or hundreds of numbers, since it’s just an authenticated connection to your provider. You’ll add one inbound route per DID, but they all share the same trunk. More trunks only come into play for multiple providers, redundancy, or tenant separation.
How do tenants get their own trunks in a white-label setup? ICTPBX assigns trunks per tenant rather than system-wide, so each one runs their own provider, DIDs, and dial rules, fully isolated from everyone else on the box. That isolation is a big part of why operators choose it for managed-service work. Configure it from the tenant admin view, not the global panel.
ICTPBX is white-label, multi-tenant PBX software built on ICTCore and FreeSWITCH for service providers and enterprises. Learn more about ICTPBX and explore your deployment options.