Trunk Configuration and Inbound Routing

The MSP's Guide to VoIP: Part 9 of 20

Disclaimer: This post is educational content about SIP trunk configuration and deployment practices. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

You've got the network sorted, the phones are provisioned, and the PBX is configured. Now comes the piece that connects everything to the outside world: the SIP trunk. This is where your client's phone system meets the public telephone network, and getting it right determines whether calls actually work once you flip the switch.

Trunk configuration isn't conceptually difficult, but it has enough moving parts that skipping a step or making an assumption about a default setting can leave you troubleshooting one-way audio or failed outbound calls on go-live day. Let's walk through the whole process from trunk provisioning to inbound routing to the E911 setup that absolutely must happen before anyone makes a call.

Choosing a trunk provider

If you're deploying a hosted PBX platform, the trunk is usually bundled. The platform provider handles the SIP connectivity to the PSTN, and you configure routing within their portal. You still need to understand how it works, but you're not selecting a separate trunk provider.

For on-premises PBX deployments (FreePBX, 3CX, Asterisk, or similar), you're choosing a SIP trunk provider separately. The major considerations are geographic coverage, pricing structure (per-minute vs. unlimited channels), number porting support, and how well they work with your specific PBX platform. Some trunk providers have known compatibility issues with certain PBX platforms, and discovering that after you've ported numbers is not a situation you want to be in.

Ask other MSPs what they use. Check the PBX vendor's documentation for tested trunk providers. If the provider offers a trial with temporary DIDs, set one up and test it with your PBX before committing. An hour of testing now saves a day of troubleshooting later.

IP authentication vs. registration authentication

SIP trunks authenticate in one of two ways, and which one you use depends on the deployment scenario.

IP authentication ties the trunk to a specific public IP address. The trunk provider's system says "if SIP traffic comes from 203.0.113.50, it's authorized for this account." No username or password is exchanged in the SIP messages. This is the standard approach for on-premises PBX deployments where the PBX sits behind a static public IP. It's simpler (no credentials to manage), slightly more efficient (no registration overhead), and generally more reliable since there's no registration that can expire or fail.

The catch is that you need a static public IP, and if the IP changes (ISP change, office move), you need to update the trunk provider's configuration before calls will work again. If you've read the SIP registration post, you know how registration-based auth works in detail.

Registration authentication uses a username and password. The PBX registers with the trunk provider periodically (typically every 60-120 seconds), and the provider authenticates each registration and call attempt using SIP digest authentication. This is the right choice when the PBX doesn't have a static IP (rare for business, but it happens), when the PBX is behind a NAT that changes the source port unpredictably, or when the deployment is in a cloud environment with elastic IP addressing.

Registration auth adds a small amount of overhead and introduces the possibility of registration failures, but it works regardless of the source IP. If your client's ISP provides a dynamic IP and won't sell them a static one, registration auth is your only option.

For most on-premises MSP deployments with a business-grade internet connection that includes a static IP: use IP authentication. It's one less thing that can break.

Codec selection on the trunk

Here's where a lot of MSPs leave performance on the table. The codec used on the SIP trunk should match what the phones are using internally. If your phones are using G.711 internally and the trunk is configured for G.729, every call that crosses the trunk gets transcoded. Transcoding adds latency, uses CPU on whatever device is doing the transcoding (usually the PBX), and can introduce subtle audio quality degradation. The SDP media negotiation post covers how codec selection works at the protocol level.

G.711 (a-law or u-law) is the standard choice for quality. It uses about 87 kbps per call with overhead, sounds excellent, and requires zero transcoding when talking to the PSTN (which natively uses G.711). If the internet connection has sufficient bandwidth for the expected number of concurrent calls, use G.711 everywhere: on the phones, on the PBX internally, and on the trunk. Consistency eliminates transcoding entirely.

G.729 compresses voice to 8 kbps at the codec level, which works out to approximately 24 to 32 kbps per call with IP, UDP, RTP, and Layer 2 overhead. The audio quality is noticeably lower than G.711 (though still acceptable for business calls), but if bandwidth is constrained, it lets you fit more concurrent calls on the connection. Some trunk providers charge extra for G.729, and some don't support it at all.

Opus is the modern codec that offers excellent quality at variable bitrates. Support on SIP trunks is still spotty as of this writing, but it's becoming more common. If your PBX and trunk provider both support Opus, it's worth testing. The quality at equivalent bitrates is superior to both G.711 and G.729.

The rule is simple: match the trunk codec to the internal codec. If phones use G.711, configure the trunk for G.711. If you must use a different codec on the trunk than internally, make sure the PBX has the CPU headroom to handle the transcoding load for all concurrent calls, not just the two test calls you tried during setup.

Configuring the trunk on the PBX

The specific steps vary by PBX platform, but the information you need from the trunk provider is the same:

The SIP server address (or addresses, if they provide primary and failover). The port (usually 5060 for UDP/TCP, 5061 for TLS). The authentication credentials (if using registration auth). The allowed codecs and their priority order. Any specific SIP headers the provider requires (some need a specific domain in the From header, some need a P-Asserted-Identity header for caller ID).

Enter this information in the PBX's trunk configuration. For IP auth, you'll also need to give the trunk provider your public IP address (and update it if it ever changes). For registration auth, watch the PBX's registration status after saving the configuration. It should show as registered within a few seconds. If it doesn't, check the credentials, check that the PBX can reach the provider's SIP server (firewall rules, DNS resolution), and check for NAT traversal issues.

Once the trunk is connected, make a test outbound call to a mobile phone. If it connects and you have two-way audio, the trunk is fundamentally working. If you get one-way audio (you can hear them but they can't hear you, or vice versa), you have a NAT or media routing issue that needs to be resolved before going further. If the call fails outright, check the SIP Response Codes reference to interpret the error, and use SIP Call Stories to walk through what a healthy call exchange should look like compared to what you are seeing.

Inbound routing: DIDs to destinations

With the trunk connected, inbound calls need to go somewhere. This is where DIDs (Direct Inward Dialing numbers) get mapped to internal destinations. The concept is straightforward: when a call comes in on a specific DID, send it to the configured destination. The destination can be an extension, a ring group, an auto attendant, a call queue, or a voicemail box.

Direct extension mapping. The simplest case: DID 555-0100 rings extension 100. DID 555-0101 rings extension 101. One DID per person, one destination per DID. This is common for executives or key staff who need direct lines.

Main number to auto attendant. The company's main number routes to an auto attendant (also called an IVR) that plays a greeting and offers options. "Press 1 for sales, 2 for support, 3 for billing." Each option routes to a ring group, queue, or specific extension. Design the auto attendant menu with the client. Keep it to three or four options at most. Nobody wants to listen to nine options, and the people who call most frequently already know which number to press.

Ring groups. A set of extensions that ring together when a call hits the group. Useful for departments: the sales ring group rings all five sales people simultaneously (or sequentially, or in a hunt pattern). Configure the ring strategy (simultaneous, sequential, round-robin), the ring time before moving to the next step, and the failover destination (usually voicemail for the group, or the receptionist, or back to the auto attendant).

Call queues. For teams that handle high call volumes and need calls held in order until an agent is available. Queues play hold music or periodic announcements while the caller waits. Configure the queue strategy, the hold music, the maximum wait time, and what happens when the queue is full or the wait time is exceeded.

Get the routing plan from the client in writing before configuring anything. Draw it as a flow chart if that helps. "When someone calls the main number, what happens? If nobody answers sales after 30 seconds, where does the call go? What happens after hours?" Walk through every path a call can take, including the edge cases. What happens at lunch? What happens on holidays? What happens if all lines are busy?

Outbound routing and caller ID

Outbound calls need rules too. The PBX needs to know which trunk to use for outbound calls (if there's more than one), and the calling number presentation needs to be correct.

Caller ID configuration. When your client's staff make outbound calls, the caller ID displayed to the recipient should show the company's number, not some random number from the trunk provider's pool. Configure the outbound caller ID on the trunk to use the appropriate DID. Some companies want all outbound calls to show the main number. Some want each user's direct DID to show when they call out. Some want department-specific numbers. Ask the client, configure it, and test it by calling a mobile phone and checking what shows up.

CNAM (Caller Name) is the name that displays alongside the caller ID number. CNAM registration is a separate process from number assignment. Your trunk provider should be able to register the CNAM for your DIDs, but it can take days to propagate through the various databases that carriers query. Start this process early. A call from "WIRELESS CALLER" or "UNKNOWN" looks unprofessional. The caller ID problems post covers the full picture of what can go wrong here.

Dialing rules. Configure how the PBX handles different types of outbound calls. Local calls (7 or 10 digits depending on the region), long distance (1 + 10 digits), international (011 + country code + number), and emergency calls (911). Some PBX platforms handle this automatically based on the trunk provider's expectations. Others need explicit outbound route patterns.

If the client needs to restrict certain call types (block international dialing for most extensions, for example), configure those restrictions in the outbound routes. It's easier to set this up during deployment than to explain a surprise $800 international call charge a month later.

Emergency calling rules deserve their own configuration check. The PBX must be configured so that 911 calls are never blocked by any restriction, class of service, or routing rule. Test this explicitly. Every extension should be able to dial 911 regardless of any other outbound restrictions. (Test with your trunk provider's designated test number, not actual 911.)

Testing every path

Before moving on to E911 configuration, test every inbound and outbound path systematically. This isn't "make a couple of calls and call it done." This is a checklist:

Outbound call from a desk phone to a mobile number. Verify two-way audio, verify caller ID shows correctly. Outbound call from a softphone (if applicable). Same checks. Inbound call to the main number. Verify the auto attendant answers, every menu option routes correctly, and the timeout behavior works as expected. Inbound call to each DID that's mapped directly to an extension. Verify the correct phone rings.

Ring group test: call a ring group, verify the configured ring pattern (do all phones ring simultaneously? do they ring in sequence?). Let it ring past the timeout and verify the failover works. Queue test if applicable: call into the queue, verify hold music plays, verify the call routes to an available agent. After-hours test: change the time condition to after-hours mode and call in, verify the after-hours greeting and routing.

Voicemail: call an extension, let it go to voicemail, leave a message, verify the message shows up in the right mailbox. If voicemail-to-email is configured, verify the email arrives.

Document each test and its result. If something doesn't work, fix it now. Every path you don't test is a path that might fail on go-live day in front of the client and their staff.

E911 configuration: this is not optional

E911 (Enhanced 911) is the part of VoIP deployment that has life-or-death consequences if you get it wrong. When someone at your client's office dials 911, the call needs to reach the correct PSAP (Public Safety Answering Point), and the correct physical address needs to be transmitted to the dispatcher. With traditional phone lines, the address was tied to the physical line. With VoIP, the address is configured in software, which means it can be wrong.

Every VoIP deployment must have E911 configured with the correct physical address before anyone makes a call from the system. This is not a "we'll get to it after go-live" item. This is a "we don't go live until this is confirmed working" item.

Address registration. Your trunk provider or hosted PBX platform has an E911 configuration section. Enter the physical street address of the client's office. This address must be the actual location where the phones are, not the client's billing address, not their PO Box, not their headquarters if the phones are at a branch office. The address must be validated (the provider will check it against the MSAG database, which is the master street address guide used by 911 systems). If the address doesn't validate, you may need to adjust the format (Street vs. St., Suite vs. Ste.) until it matches what the MSAG expects.

Per-location configuration. If the client has multiple locations, each location needs its own E911 address. If the PBX serves all locations, each location's trunk or DID range needs to be associated with the correct address. A call from the downtown office must send the downtown address, not the warehouse address.

Remote workers. If employees use softphones or desk phones at home, their E911 address should be their home address, not the office address. Some platforms support dynamic E911 where the address is associated with the user's current location. If the platform doesn't support this, remote workers need to be aware that 911 calls from their VoIP phone may not send the correct address, and they should use their mobile phone for 911 calls.

Testing E911. Most trunk providers have a way to test E911 routing without actually calling 911. Some provide a test number. Some have a validation tool in their portal that confirms the address is registered and routes correctly. Use whatever testing method is available. If none is available, call the trunk provider's support and ask them to verify the E911 configuration for each address.

Do not skip E911 configuration. Do not defer it. Do not assume it was set up automatically. Verify it yourself, document it, and include it in the go-live checklist. If an employee has a medical emergency and dials 911, and the call doesn't connect or connects with the wrong address, that's on whoever deployed the system.

Regulatory position check

If you are configuring your own SIP trunks for client voice service, you may now be operating as a voice service provider under FCC rules. This is true whether you think of yourself as an MSP, a reseller, or an IT consultant. The FCC classifies providers based on what they do, not what they call themselves.

Before going live with client traffic on your own trunks, verify your regulatory position. Do you need FCC registration? An Operating Company Number (OCN)? STIR/SHAKEN compliance? A filing in the Robocall Mitigation Database? The answers depend on the specifics of your arrangement with the trunk provider and how your service is structured, but the questions are not optional.

See Parts 17 through 20 of this series for the full picture of voice service provider obligations, and consult a telecom attorney before going live with client traffic on trunks you contract for directly.

Multi-site trunk considerations

If the client has multiple locations sharing a centralized PBX (common with cloud-hosted platforms), each location's calls should egress with the correct local caller ID and route to the correct local PSAP for 911. This usually means having DIDs from each location's local rate center and configuring the system so outbound calls from each location use that location's DIDs.

Some trunk providers offer location-aware trunking where you can tag traffic from different locations and have different caller ID and E911 settings per location on the same trunk account. Others require separate trunk configurations per location. Either approach works; just make sure every location has the right outbound caller ID and the right E911 address.

SIP trunk security

SIP trunks are a target for toll fraud. If someone gains access to your trunk credentials or can send SIP traffic from an authorized IP, they can make international calls on your client's account. A weekend of fraudulent calls to premium-rate numbers can generate thousands of dollars in charges.

IP authentication provides inherent protection since only traffic from the authorized IP is accepted. But if the PBX itself is compromised, the attacker can make calls through the trunk.

Registration authentication requires the credentials to be protected. Don't use weak passwords. Don't reuse credentials across clients. Don't store credentials in plain text in documentation that's shared widely.

Rate limiting on the trunk provider side. Most providers offer fraud protection features: concurrent call limits, per-minute spending caps, international call blocking, and alerts for unusual call patterns. Enable all of them. Set the concurrent call limit to slightly above the client's expected maximum (if they normally have 10 concurrent calls, set the limit to 15, not unlimited). Block international destinations the client doesn't call. Set a daily spending cap that would catch a fraud attempt before it gets expensive.

PBX-side protections. Use strong passwords for all SIP extensions. Disable unused extensions. Use a firewall or SBC (Session Border Controller) in front of the PBX to limit SIP access to known sources. Monitor call detail records for unusual patterns (calls at 3 AM, calls to premium-rate numbers, sudden spikes in concurrent calls).

The trunk configuration checklist

Before moving to go-live, verify each of these:

Trunk is connected and authenticated (registration status shows active, or IP auth is confirmed). Codec on the trunk matches internal codec (no unnecessary transcoding). Every DID routes to the correct internal destination. Auto attendant menus work correctly with proper timeouts and failovers. Ring groups ring in the configured pattern with correct failover. After-hours routing works correctly. Outbound caller ID shows the correct number for each extension or department. CNAM is registered and propagating. International dialing restrictions are in place if needed. E911 address is registered, validated, and correct for each location. Emergency calls route correctly from every extension. Fraud protection settings are enabled on the trunk provider's account. Concurrent call limit is set appropriately. The client has the trunk provider's support contact information.

That's a lot of items. It's a lot of items because getting the trunk right is what makes the whole deployment work. The prettiest phone system in the world is useless if calls don't connect, caller ID is wrong, or 911 doesn't work. Take the time, test every path, verify every setting.

Next up: Go-Live Day and the First Week