How to Test a SIP Trunk: Acceptance Checklist

You test a SIP trunk (a SIP connection from a provider to your phone system) by running a short acceptance sequence: authenticate, confirm keepalives, place inbound and outbound calls, check audio and DTMF, then force a failover. By the end you’ll have a pass/fail SIP trunk testing checklist with captures you can send to support. Plan 45–60 minutes with a PBX (your phone system), a PBX CLI (command line), a mobile phone, and a packet-capture tool. This is how to test a SIP trunk in a clean, ordered way that saves you days of back-and-forth.

What to prepare before you start

Decide your authentication type up front: SIP registration (your PBX logs in with a username/password) or IP authentication (the provider allows your static public IP). Collect the exact credentials, FQDNs (provider hostnames), SIP domain/realm, and any outbound proxy. Know if you’ll use UDP 5060, TCP 5060, or TLS 5061. If you use TLS (encrypted SIP), install the trust chain on the PBX.

Open your firewall for signaling and media. Allow outbound and inbound to the provider’s SIP hosts and ports (as they document). Allow the provider’s RTP (audio packets) UDP range to and from your PBX. If you filter by IP, include all A records that the FQDN resolves to.

Disable SIP ALG (the router “helper” that rewrites SIP). It often breaks NAT (your router translating private to public IP) and Contact headers. Set the correct NAT on your PBX: external/public IP, local network ranges, and enable symmetric RTP if your PBX supports it. Avoid double NAT if you can.

Sync time on the PBX and firewall with NTP (network time, keeps clocks in sync). Large time skew can break digest authentication and TLS.

Have one test DID (an inbound telephone number mapped to your trunk) for inbound and one regular mobile or PSTN number for outbound. Know your codec plan; in the US, G.711 µ-law is the safe default. If you plan to use other codecs, make sure both sides agree.

Set up your tools. From the PBX side: CLI commands (Asterisk “pjsip show registrations” / “pjsip show aor ”, or your platform’s status page), and a softphone or test desk phone on an internal extension. For captures, use sngrep or tcpdump on the PBX or SBC (session border controller), so you can read SIP and track media IPs/ports. If you’re new to trunks, skim SIP Trunking Basics: How It Works and What You Need.

Brief aside: CallFlow can route inbound to a SIP endpoint on your PBX and can provision US numbers from a prepaid wallet, but this guide stays vendor-neutral.

How to test a SIP trunk (acceptance order)

1) Register the trunk or confirm IP authentication

If you use SIP registration (PBX logs in), the PBX should show Registered/OK and keep that state. On Asterisk, “pjsip show registrations” should say Registered, and “pjsip show aor ” should show the current contact. On Cisco IOS, “show sip-ua status” shows registration state. Many GUIs (FreePBX, 3CX) also show green/OK next to the trunk.

A pass means the PBX shows Registered and stays there. The provider should see your public IP and the correct Contact. Common failures: a 401/403 loop (wrong authentication user [often the auth_user field] vs username, or password), wrong domain/realm, NAT not rewriting the Contact, or a TLS trust/cipher mismatch. Fix the authentication user vs username field (often they differ), set the outbound proxy if provided, verify DNS, and pin to UDP while testing to remove TLS/TCP variables.

On IP authentication, send a test INVITE. You should see 100 Trying, 180 Ringing, then 200 OK. A 403 means your source IP isn’t allowed. No reply usually means a DNS target or firewall issue.

2) Enable and confirm SIP OPTIONS keepalives

Turn on SIP OPTIONS (keepalive messages) on the PBX trunk. Set SIP OPTIONS pings to 30–60 seconds. This is your SIP OPTIONS ping test. Watch sngrep or your PBX logs for OPTIONS going out and 200 OKs coming back with capability headers (for example, Allow/Supported).

A pass means steady 200 OK replies at your interval without gaps. Fails: 408 or 503 (path blocked or DNS issue), 403 (your IP not authorized for IP-auth trunks), or asymmetric routing (OPTIONS go out one way, replies come back another and get dropped). Check your firewall rules and session timers, and allow all provider IPs/FQDNs you were given.

3) Test inbound calls on a DID

Point your test DID to the trunk and route it on your PBX to a known extension or a simple IVR. From a mobile, dial the DID. The call should reach your PBX and the target should start ringing within about 2–4 seconds of dialing (post-dial delay). In SIP, you’ll see 100 Trying, 180 Ringing, then 200 OK toward your PBX. Start RTP (audio packets) both ways.

A pass means the right phone rings, two-way audio works, and the call connects cleanly. Fails: 404 Not Found (the DID isn’t mapped to your trunk yet or has the wrong SIP user/URI), 603/607 (blocked upstream or a screening rule), or the DID is still provisioning. Also check that the Request-URI user part matches your inbound route on the PBX. If the call lands but there’s no audio, skip to the NAT/audio section below.

4) Test outbound calls

From your internal phone, dial a 10-digit or 11-digit number. The call should complete with ringback or early media (audio before answer), and you should see your planned caller ID number at the far end. Focus on number presentation first; CNAM (caller name display) is a separate lookup and may not show during tests.

A pass means quick post-dial delay, ringback or early media, and a clean connect. Fails: 403 Forbidden (not authorized or wrong trunk), 488 Not Acceptable Here (codec/SDP [the media/codec part of SIP] mismatch), 503 Service Unavailable (upstream route down or DNS), or the PBX dial plan blocks the pattern. Normalize your dial plan (E.164 [international +1… format] or 10D) and make sure your test prefix selects the trunk. Many providers require the caller ID TN (telephone number) to be verified; if the number doesn’t present, use a verified TN to test.

5) Verify codec negotiation and DTMF

On the SIP/SDP, confirm the answer includes G.711 µ-law (or your agreed codec), and that it’s first. Keep exotic codecs off the trunk while testing. Make a call and listen for clean audio with no clipping or delay jumps. For DTMF (touch tones), use an IVR and press several digits. RFC2833 (RTP events) is the common method; check the payload type, often 101.

A pass means audio is clear, the codec match is as planned, and the IVR hears your digits every time. Fails: 415 or 488 errors (codec offer/answer mismatch), or choppy audio due to transcoding load. Fix by prioritizing G.711, turning off low-bitrate codecs on the trunk, and ensuring the PBX and provider both use RFC2833 for DTMF. Avoid in-band DTMF if you use compressed codecs.

6) Fix NAT and one-way audio risks

One-way audio on a SIP trunk almost always points to NAT or RTP filtering. Check that your PBX advertises its public IP in SDP, not its private IP. Set the PBX’s external media address and local networks. Enable symmetric RTP so the PBX sends media back to the source port it saw. Ensure the firewall allows the full RTP UDP range both ways. Keep SIP ALG off.

A pass means as soon as you answer, you hear the far end within 1–2 seconds, and they hear you. If audio works in only one direction, the RTP isn’t getting hairpinned through NAT. Fix the external IP on the PBX, confirm no double NAT, and test again. If you still have no audio, capture with sngrep or tcpdump to see where RTP is flowing and which IPs/ports are in the SDP.

7) Prove failover works

Whatever you configured—PBX route priorities, DNS SRV (DNS records that point the PBX to the right host/port) across provider edges, or a secondary trunk—actually test it. Induce a safe failure by blocking the primary trunk IP/FQDN at the firewall or stopping the primary endpoint on the PBX. Do this in a lab or during a maintenance window so you don’t drop live calls. Your OPTIONS status should flip to down within one keepalive interval. Place new inbound and outbound calls and watch them use the alternate path.

A pass means new calls route over the backup within the expected delay (typically within your OPTIONS interval or DNS timeout). Fails: health checks not enabled, DNS SRV not honored by your PBX, or the secondary trunk mis-provisioned. Record the extra post-dial delay you observe and how calls behaved during the switchover.

If the trunk won’t register or OPTIONS fail

Start with the basics for registration. Many platforms separate “username” and “authentication user” (the credential used in the Authorization header, often named auth_user). If these differ, set both fields as required. Match the digest realm (the domain the provider expects for auth). If the provider requires an outbound proxy, set it; some won’t accept requests sent directly to their registrar. If they publish DNS SRV/NAPTR (DNS records that point the PBX to the right host/port), enable SRV lookup on the PBX so you hit the right host and port without hardcoding IPs. For TLS, install and trust the provider’s CA chain, and match the SIP domain in the Server Name.

NAT-specific fixes solve most registration loops. Enable rewrite-contact and rport so the PBX puts the public IP and the correct source port in Contact and Via. Set the external/public IP and local nets on the PBX. If the Contact shows a private IP on the provider side, the binding will break when NAT changes. Pin to UDP while you debug, and add TLS/TCP later when the path is stable.

Set SIP OPTIONS pings to 30–60 seconds. You should get steady 200 OKs. If replies stop after a few minutes, raise UDP session timers on the firewall or allow all IPs that the FQDN resolves to.

A pass here looks like this: Registered/OK stays solid for 10 minutes or more, OPTIONS round-trips are steady at your interval, and you see no 401/407 loop in sngrep. At that point, move on to call testing.

Inbound or outbound fails: read SIP codes and fix fast

Map the SIP code to an action and you’ll fix most issues quickly.

• 404 Not Found: The DID isn’t mapped to your trunk or the PBX route. Check the inbound number format and the PBX DID rule.
• 403 Forbidden: Authentication or IP not allowed. For registration trunks, check credentials. For IP-auth, whitelist your public IP.
• 407/401 Proxy/Auth Required: Wrong username/password, wrong authentication user, or wrong realm.
• 480 Temporarily Unavailable, 486 Busy Here: Callee status; the far end declined or didn’t answer.
• 488 Not Acceptable Here: Codec/SDP mismatch. Offer G.711 µ-law first, and disable unsupported codecs.
• 503 Service Unavailable: Upstream route down, DNS problem, or maintenance. Try the alternate host if you have one.

Use live logs and packet capture. In sngrep, filter by Call-ID to follow the call and see where it fails (PBX, provider edge, or upstream). Confirm your dial plan normalizes to one format (E.164 [international +1… format] like +1NPANXXXXXX or 10D), and that your test patterns actually select the trunk you’re testing. For a deeper look at what codes imply about upstream handling, see How SIP Response Codes (603, 607, 486) Reveal If Your Toll-Free Number Is Being Flagged as Spam.

One-way audio and DTMF: NAT, RTP, and PBX settings

Run this one-way audio SIP trunk checklist:

• Open the provider’s RTP UDP range both directions.
• Set the PBX external IP and local subnets so it advertises the right media address.
• Enable symmetric RTP and, if available, media relay/proxy on the PBX.
• Remove double NAT, or put the PBX/SBC at the edge.
• Turn off SIP ALG in your router/firewall. If you can’t, try TLS/TCP so the ALG leaves SIP alone, but the best practice is ALG off.

For DTMF reliability, prefer RFC2833 (RTP events) on trunks. Avoid in-band if you use compressed codecs. If your PBX uses SIP INFO (DTMF sent as SIP messages), confirm the provider supports it. Test an IVR and press a string of at least five digits; the IVR should read them exactly. If digits miss or double, confirm the RFC2833 payload type matches on both sides (often 101), and that transcoding isn’t clipping tones.

A pass here looks like this: both parties hear each other within 1–2 seconds after answer. No random audio drops. The IVR accepts 5 or more consecutive digits without errors.

Record your pass and failover timings

Decide which failover you rely on and test that exact mode:

• PBX-side trunk priorities or route lists.
• DNS SRV across provider edges (PBX must honor SRV).
• A secondary provider trunk for outbound or inbound overflow.

Induce a safe failure: block the primary trunk’s IP/FQDN at the firewall, or stop the primary endpoint on the PBX. Do this in a lab or during a maintenance window so you don’t drop live calls. Watch the OPTIONS status flip to down. Place inbound and outbound calls and confirm the alternate path takes over. Measure the extra post-dial delay. It should be within one keepalive interval for OPTIONS-based checks or within a DNS timeout if you rely on SRV.

Document the acceptance so handover is painless. Take screenshots of the Registered state and OPTIONS graphs, save an sngrep trace of a good inbound and outbound call, and note the exact codec and DTMF settings you used. Draw a simple call path diagram (PBX IPs, SBC, firewall). End with a pass/fail table per step: authentication, OPTIONS, inbound, outbound, audio/DTMF, failover. These artifacts save time if anything drifts later.

Next steps: monitor and harden routing

After you pass acceptance, set up light monitoring. Enable alerts or scheduled email reports for trunk status and call failures. Keep an eye on real-time call logs to catch odd spikes or repeated error codes.

Plan capacity. Estimate your concurrent calls and test with multiple simultaneous calls to confirm media and CPU headroom. If you need a primer on sizing, read Simultaneous Calls: How to Plan Concurrent Call Capacity.

If you use a call-routing platform, add overflow rules and time windows so calls never dead-end. Basic IVR, ring strategies, queues with hold music, and buyer/target caps help smooth spikes. For ideas, see Failover Call Forwarding: Build Redundant Inbound Routing.

If you want direct numbers and inbound routing to a SIP endpoint on your PBX, you can try CallFlow’s usage-based setup with a prepaid wallet—no contract. You can get started at /register.

Finally, keep your SIP trunk testing checklist handy for adds and changes. Any time you touch authentication, firewall, codecs, or dial plans, rerun this acceptance in order. It takes under an hour and saves many more.