Industry · IT service providers and MSPs
Voice connectivity you can deploy and support across client sites
When you manage phone systems for many clients, every trunk should be configured, documented and supported the same way. We work with your engineers to make each new client deployment follow the same tested pattern.
- Repeatable configuration
- Documented per client
- SIP traces for diagnosis
Repeatable deployment
A standard process for every client site
Each client is different, but the steps should not be. The same five steps apply to a five-user office and a multi-site client.
-
Step 1: Client survey
Record the PBX platform and version, firewall model, internet connections, numbers in use and the client’s calling pattern.
Output: site survey
-
Step 2: Compatibility review
We review the survey against the trunk configuration and flag issues such as old firmware, SIP ALG or unsupported codecs.
Output: compatibility notes
-
Step 3: Configuration sheet
Authentication, codecs, DTMF, number formats, channels and failover are written down for that client.
Output: configuration sheet
-
Step 4: Configure from your template
Your engineers apply your standard PBX and firewall template, adjusted with the values on the sheet.
Output: configured site
-
Step 5: Test and hand over
Inbound, outbound, DTMF, caller ID and failover are tested against a written plan, and the results go into the client file.
Output: test record
Documentation
Documentation your service desk can rely on
Voice problems are often raised months after installation, by someone who was not involved. Good records shorten every ticket.
What each client file should contain
- Configuration sheet per client: SIP hosts, authentication method, codecs, DTMF and number formats
- Number inventory: which numbers belong to which client and where each one routes
- Firewall and NAT settings: signalling addresses, RTP port range and SIP ALG status
- Failover destinations and the date they were last tested
- Escalation contacts on your side and ours
We supply the trunk-side values for each client. Keeping them in your own documentation system, next to the client’s network records, means any engineer can pick up a ticket.
Compatibility
Compatibility reviewed per client
A template that works on one client’s PBX may fail on another’s because of firmware, firewall or network differences.
Before each client goes live, we review the PBX platform and software version, the firewall and router model, the internet connection and the client’s numbers. Common findings include SIP ALG enabled on a router, a PBX that advertises a private address, an RTP port range that is not open, or firmware too old for the authentication method you have standardised on.
Platforms such as Asterisk, FreePBX, 3CX, FreeSWITCH, Yeastar and Grandstream UCM usually connect using standard SIP. Product names are trademarks of their owners and are listed for compatibility guidance only. The PBX connection guide sets out the vendor-neutral steps.
Support boundaries
Who supports what
Clear boundaries prevent tickets from bouncing between providers. This is the usual division when an MSP manages the client’s phone system.
Typical support responsibilities for an MSP-managed deployment
-
End-user handsets, softphones and users
- Primary responsibility
- Your team
- Our role
- Not involved
-
Client PBX configuration and dial plan
- Primary responsibility
- Your team
- Our role
- Advice and configuration guidance
-
Client firewall, NAT and internet connection
- Primary responsibility
- Your team and the client’s ISP
- Our role
- Diagnosis help from SIP traces
-
SIP trunk, numbers and routing on our platform
- Primary responsibility
- First-line triage
- Our role
- Our team
-
Carrier routes and number provisioning
- Primary responsibility
- Report through us
- Our role
- Our team, with carriers
Monitoring and troubleshooting
Troubleshooting with SIP traces and response codes
Most voice faults can be located from the SIP signalling. A 403 response usually points to authentication or calling permissions; 404 to a number format problem; 486 to a busy destination; 503 to a route or capacity issue. One-way or missing audio almost always means a NAT or firewall problem rather than a trunk fault.
When you raise an issue, include the calling and called numbers, the time of the call with time zone, and a packet capture or PBX log if you have one. We compare it with our side of the call and share what we find, so your engineers can see the cause rather than just the fix.
For ongoing monitoring, watch trunk registration status (where registration is used), failed-call counts and channel usage on each client PBX, and alert your service desk when they change.
Security
A security baseline for every client
Toll fraud on a client’s PBX becomes your incident. Apply the same baseline at every site and record any exceptions.
-
Authentication
IP authentication for clients with a static address; long, unique registration credentials for the rest. No credentials are reused between clients.
-
Network exposure
SIP accepted only from known provider addresses, PBX administration interfaces restricted to your management network, and default accounts removed.
-
Calling permissions
International and premium-rate destinations enabled only where the client needs them, with channel limits per client.
-
Alerts and review
Usage alerts, where available, sent to your service desk, and a periodic review of each client’s limits and enabled destinations.
Recommended services
Services MSPs usually work with
Most MSPs start with SIP trunks and numbers for client PBXs, and use a hosted phone system for clients without one.
SIP Trunking
Trunks for each client PBX, configured from a consistent, documented pattern.
Explore SIP Trunking
Virtual Numbers
New and ported numbers per client, recorded in a clear inventory.
Explore Virtual Numbers
Cloud PBX
A hosted phone system for clients who would rather not run a PBX.
Explore Cloud PBX
Next step
Standardise voice across your client base
Tell us about the PBX platforms you manage and your next client deployment. We will review compatibility and propose a configuration you can repeat.
Helpful to include
- PBX platforms and versions across your clients
- Firewall and router models you standardise on
- Number of client sites and typical channel needs
- Numbers to port for the first client
- Your service desk escalation contacts