SIP Trunking for Small Business | IT Checklist

SIP Trunking for Small Business: IT Checklist

SIP trunking is how a business connects its phone system or softphones to the public telephone network over the internet using SIP (Session Initiation Protocol) instead of traditional ISDN/PRI lines. A SIP trunk is the service that carries those calls: you buy concurrent call capacity (“channels”), register endpoints or a PBX to the provider, and route inbound DIDs and outbound calls. For roughly 20–100 person companies, good SIP trunking decisions are less about marketing buzzwords and more about how many concurrent calls you really need, what happens when the office internet fails, how softphones register securely, and how you shortlist a provider without locking into a bake-off you cannot unwind. This playbook is a practical SIP trunk checklist for IT managers — sizing, provider questions, failover, and handoff to softphone setup — without inventing vendor rankings or turning the post into a hosted-PBX pitch.

What is SIP trunking (and how is a SIP trunk different from a softphone app)?

SIP trunking is the carrier-side path: SIP signalling and media between your site (or cloud registration) and the public switched telephone network (PSTN). You purchase SIP channels — concurrent call slots — and usually DIDs (phone numbers) from a SIP trunk provider. Registration can be a PBX/SBC, a gateway, or endpoints that register directly, depending on how you design the path.

A softphone is the client on a laptop or phone: audio devices, register/unregister, day-one usability. Softphones may register to your trunk, sit behind a PBX that uses the trunk, or use a different service path entirely. The jobs are related but not the same:

• Trunk = capacity, DIDs, CLI, failover, and provider terms
• Softphone = how people take and place calls on a device

If you are still choosing desk phones or a hybrid hardware path, keep that buyer work separate — see the IP phone system buying checklist. Day-one client setup belongs in the softphone setup checklist, after the trunk path is stable.

PRI vs SIP (short): legacy PRI/ISDN gave fixed physical channels into a PBX. A business SIP trunk replaces that with IP capacity you can often grow in software — still subject to your internet path, firewall, and provider design. “Hosted SIP trunk” marketing does not mean you can skip network quality.

When does a small business need a SIP trunk vs just softphones on a hosted service?

You typically need an explicit SIP trunk decision when:

• You already have (or will keep) a PBX/gateway that must speak SIP to a carrier
• You want to own concurrent capacity and DID routing as a named IT service
• Multiple endpoint classes (desk phones, softphones, meeting rooms) must share one carrier path
• You are leaving PRI/ISDN and need a like-for-like concurrent-call model over IP

Softphones alone on a hosted calling service can be enough when you do not need to operate trunk capacity yourself. This post does not pitch hosted PBX SKUs; it assumes IT is evaluating trunk capacity and provider fit for a 20–100 person voice footprint. If DIDs are moving carriers, use the UK business number porting guide — do not merge porting into trunk sizing.

How many SIP channels / concurrent calls do you actually need?

Size to peak concurrent calls, not headcount.

1. Pull busy-hour evidence: CDRs, hunt-group peaks, or a week of “everyone dials at once” moments.
2. Count classes separately (inbound, outbound, rooms, overflow) — take the overlapping peak, not summed daily averages.
3. Add a small buffer for spikes — not a made-up “channels per seat” formula.
4. Document who can order more channels and how long provisioning takes.

Under-buying shows as busy signals; over-buying as quiet invoices. Quarterly utilisation beats a one-time guess.

What should you ask a SIP trunk provider before you buy?

Write a scorecard before demos. Shortlist 2–3 providers with the same criteria — evaluation method, not a fake “#1 SIP trunk 2026” list. Reuse the discipline in SaaS vendor evaluation for small business.

Must-have questions (adapt to your countries):

1. Concurrent channels — hard cap, burst options, and how busy-hour overage is billed
2. CLI / number presentation — outbound CLI rules, branded calling where relevant, and DID ownership
3. Emergency calling — location handling and your legal obligations for office and remote staff
4. Codecs and media — what you must support on endpoints/PBX; media anchoring behaviour
5. Security — TLS/SRTP options, IP allowlists, credential rotation, fraud controls
6. Support hours and escalation — who you call when the trunk is down at 08:55
7. Exit terms — number portability out, notice periods, and credential handoff

Ask how softphones register: direct SIP vs via your PBX/SBC. Vault trunk/portal credentials and protect admin portals with MFA (password manager, MFA rollout). Score the same sheet — do not invent bake-off winners — and keep exit terms readable.

How do failover, firewall ports, and network quality fit together?

A SIP trunk does not fix bad Wi-Fi, NAT, or blocked media. Treat three layers as linked runbooks:

• Layer: Network / QoS — Job: Bandwidth, Wi-Fi, latency/jitter before you blame the carrier — Link: VoIP network requirements
• Layer: Firewall / NAT — Job: Allow SIP signalling and RTP per current provider docs — Link: VoIP firewall ports checklist
• Layer: Trunk failover — Job: Secondary SBC/IP, SIP OPTIONS monitoring, site-down behaviour — Link: Provider design + your IR runbook

Ask what happens when the office WAN dies: softphones on LTE, inbound DID failover, secondary signalling. Put the answer in a one-page incident path (incident response). Never paste invented port tables — verify against current provider docs.

What does a practical SIP trunk rollout checklist look like?

Week 1 — Demand & inventory

1. Count peak concurrent calls (not headcount): sales dials + inbound support + meeting rooms + “everyone dials once” worst case. Start from observed busy-hour, not seat count × 1.
2. List what will register to the trunk (or sit behind it): softphones, desk phones, existing PBX/gateway, or a hosted connector — name owners for each class.
3. Map numbers: which DIDs stay, which move, who owns the carrier account (porting guide if numbers move — do not rewrite that guide here).
4. Confirm internet capacity and QoS baseline (VoIP network requirements) — a trunk does not fix Wi-Fi jitter.

Week 2 — Provider shortlist (criteria only — no fake “#1 SIP trunk” lists)

1. Write must-haves: concurrent channels, CLI presentation, emergency calling rules for your countries, codec support, TLS/SRTP options, support hours, and exit terms (number portability out).
2. Ask about failover: secondary SBC/IP, SIP OPTIONS ping, and what happens if your office WAN dies (mobile softphone path vs site-down).
3. Ask how softphones register (direct SIP vs via your PBX/SBC) and what credentials you must store in a vault (password manager / MFA).
4. Shortlist 2–3 providers with the same scorecard (SaaS vendor evaluation) — do not invent comparison winners.

Week 3 — Pilot

1. Pilot with IT + a small call-heavy team: inbound DID, outbound CLI, hold music / transfers if you use them, and softphone register/unregister on Wi-Fi and LTE.
2. Confirm firewall allows needed SIP/RTP paths (firewall ports checklist) — verify with your provider’s current docs.
3. Load-test near your channel count once (not a denial-of-service); log one-way audio, failed registers, and busy signals.
4. Document who can order more channels and how long provisioning takes.

Week 4 — Harden & handoff

1. Write a one-page runbook: trunk down, softphone fallback, who to call at the provider, and how to declare an incident (incident response).
2. Add trunk credentials and DIDs to joiner/leaver processes (device onboarding/offboarding).
3. Schedule a quarterly review: channel utilisation, failed calls, and whether you are over-buying concurrent capacity.
4. Optional softphone bridge: once the trunk path is stable, point staff to day-one softphone setup on sessiontalk.io — trunk ≠ app install.

Optional company softphone trials stay on sessiontalk.io — a handoff after the trunk path works, not a hosted-PBX pitch.

SIP trunk vs related phone work

• Topic: SIP trunking — Job: Carrier/path capacity + DIDs over SIP — Not the same as: Softphone app install / UX
• Topic: Softphone setup — Job: Register the client, audio devices, day-one tests — Not the same as: Buying channels from a trunk provider
• Topic: VoIP network requirements — Job: Bandwidth, Wi-Fi, QoS, latency/jitter — Not the same as: Choosing a trunk SKU
• Topic: Firewall / SIP ports — Job: Allow signalling + media through the edge — Not the same as: Provider commercial terms
• Topic: Number porting — Job: Move DIDs between carriers — Not the same as: Sizing concurrent channels

Keep these as linked playbooks — merging them into one vague “phones” doc confuses sizing, firewall, and app-install tickets.

FAQ

What is SIP trunking?

A way to connect business calling to the PSTN over IP using SIP, buying concurrent call capacity (channels) from a provider instead of traditional phone lines.

Is a SIP trunk the same as a softphone?

No. A softphone is the app on a phone or desktop; a SIP trunk is the network/service path that carries calls to and from the public phone network (sometimes your softphones register to it directly, sometimes via a PBX).

How many SIP channels does a small business need?

Size to peak concurrent calls, not employee count — measure busy-hour usage and add a small buffer; do not invent industry “X channels per seat” rules.

Do we still need good Wi-Fi and firewall rules if we buy a SIP trunk?

Yes. Trunks do not fix local Wi-Fi, NAT, or blocked SIP/RTP ports — follow your network and firewall playbooks.

Can we keep softphones if we change SIP trunk providers later?

Often yes if numbers are portable and clients can be re-pointed — check exit terms and credential handoff before you sign.