The Business Phone System & SIP Trunk Checklist

This is the checklist we work from on voice installs and SIP faults. It is written so you can use it with any provider, including one that isn't us.

Phone systems fail differently from everything else in IT. When email breaks, everyone knows. When a phone system half-breaks — outbound works but inbound has no audio, or the first call connects and the next one doesn't — it can run like that for months, because each person assumes it was a one-off and hangs up.

Nearly all of it comes down to one thing: voice signalling and voice audio travel separately, and anything in the middle that helpfully rewrites the signalling will break the audio. That is where most of this checklist lives.

• How many extensions, and how many people are on calls at the same time — these are different numbers and only the second one sizes the trunk
• Desk phones, softphones on laptops, mobiles, or a mix
• Do you need calls to follow people off-site, or is this desks only
• Reception behaviour: a receptionist, an auto-attendant menu, or a hunt group
• Call recording — needed, and for how long. It changes storage and it may change your obligations
• Do you have existing numbers to keep, and who currently holds them
• Existing hardware: make and model of the phone system and the handsets, and whether the handsets are locked to a vendor
• Internet: which carrier, what speed, and is there a second line
• Who supports it after go-live, and what happens at 6pm on a Thursday

• Registration or IP-authenticated trunk — and if IP-authenticated, whether your public IP is static
• The exact hostnames for registrar and proxy, in writing. They are not always the same and a wrong one fails silently
• Credentials delivered securely, not in the body of an email
• Which codecs are permitted, and which one is preferred
• Whether the carrier expects your equipment to be reachable from the internet, and what that implies for your firewall
• Number of channels, and what happens to call 11 if you bought 10
• Whether the carrier will demonstrate calls working at handover, and get that in writing
• Fault process: who you call, what reference you quote, and what they will need from you
• Contract term, notice period, and whether the numbers are portable out

If you read one section, read this one.

• SIP ALG / SIP inspection / SIP helper — find out whether it is on. On most business firewalls it is on by default, and on most SIP trunks it needs to be off
• Understand what it does: it rewrites the addresses inside your call signalling because it thinks it is helping. When it gets it wrong, the call connects and the audio goes nowhere
• Check the same setting on every device in the path — the router, the firewall, and sometimes the carrier's own box
• Confirm whether changing it requires a reboot. On a firewall pair carrying a whole business, that is a scheduled change, not a Tuesday afternoon
• RTP audio port range opened as the carrier specifies, not guessed
• Session timers and NAT keep-alive set so registration does not silently expire
• Quality of service marking voice ahead of everything else, especially if the office shares one line
• Voice on its own VLAN where the network supports it
• Two firewalls in a failover pair: confirm the voice path behaves the same on both

• List every number you use, including the fax line nobody admits to and the one on your printed signage
• Which numbers are moving and which are being replaced
• Who legally holds each number today — this is sometimes not who you think
• Porting lead time confirmed in writing, with a date
• What happens to calls during the port window
• Main number tested first and separately — it is the one on your invoices, your vehicles and your website
• Caller ID presented correctly on outbound, checked by calling a mobile and looking at the screen
• Emergency calling works and presents an address the emergency service can use
• Numbers updated everywhere afterwards: Google profile, website, invoices, signage, email signatures

• What happens to a call at 3am, on a Friday, and during a public holiday — decided rather than defaulted
• Where an unanswered call ends up, and whether anybody checks that mailbox
• Auto-attendant menu written down and read aloud before it is recorded. Menus that make sense internally often confuse customers
• Hunt groups and ring order agreed with the people who will actually be ringing
• Voicemail-to-email, if wanted
• Recording announcement in place if calls are recorded
• Directors' and finance extensions not reachable straight from a public menu, if that matters to you

A compromised phone system does not stop working. It quietly makes expensive international calls, usually at the weekend, and you discover it on the bill.

• Every default password changed, on the system and on every handset
• Management interface not reachable from the internet
• International dialling disabled by default and enabled only for extensions that need it
• Premium and unusual destination ranges barred unless there is a reason
• A spend or duration cap agreed with the carrier, so a runaway weekend has a ceiling
• Alerting on unusual call volume or out-of-hours activity
• Extension registration restricted to your own network or a known range where possible
• Who at the carrier you call to stop calls immediately, found before you need it
• Firmware current on the system and the handsets

• PoE budget on the switch actually calculated for the number of handsets, not assumed
• UPS covering the phone system, the switch and the internet router. All three, or the phones die anyway
• Cable runs within distance limits, and tested rather than trusted
• What the system does when the internet drops — and whether calls can divert to mobiles automatically
• A second internet path if losing the phones for a day would genuinely hurt
• Config backup of the phone system taken and held by you

Do these yourself, on the day, before signing anything.

• Call out to a mobile. Then wait three minutes and call out again. If the second call fails, the job is not finished
• Call in from a mobile and confirm audio in both directions
• Call the main published number specifically
• Ring an extension that is not answered and confirm where the call lands
• Test the auto-attendant end to end, pressing every option
• Transfer a call between two people
• Place a call on hold for a minute and take it back — hold is where one-way audio shows up
• Check caller ID as seen by the person you called
• Test a call from a softphone or mobile app on mobile data, not office wifi
• Leave it a week, then ask reception what has been odd. They will know before any monitoring does

• Admin login to the phone system, in your company's name
• The carrier account and the numbers registered to your company, not your installer
• Extension list with names, and the dial plan written down
• Trunk settings recorded — hostnames, codecs, channel count
• Configuration backup, held by you
• Handset admin passwords
• The support arrangement, in writing, including out-of-hours

SIP ALG. The single most common cause of "the phones are strange". Left on by default, breaks audio intermittently, and gets blamed on the phone system for months.

The second call. Everyone tests one call, it works, everyone goes home. Test the second call three minutes later — that is the one that exposes the fault.

Channels sized to headcount. Paying every month for concurrent capacity nobody has ever used.

The number nobody owns. Discovered on porting day, registered to a company that dissolved, and now it is a three-week problem.

Default handset passwords. Every handset, not just the system. This is how toll fraud usually starts.

The UPS that covers the server only. Phone system up, switch down, phones dead.

Nobody checks the shared voicemail. Six weeks of customers who thought they had left a message.

We install and support phone systems, configure SIP trunks, and fix the firewall and network side that most voice faults actually live in. We do not sell you channels you will not use, and we will tell you when your existing system is fine and only the network needs attention — which happens more often than the industry admits.