In this guide
This guide provides a vendor-neutral diagnostic sequence, evidence to collect, limitations and safe verification steps. Confirm syntax and behavior against the software version and accepted peer specification before production use.
Prerequisites
- Authorization to inspect or change the system.
- A controlled test call and UTC timestamps.
- A rollback path and protected logs or captures.
Control boundary
With a SIP trunk, the customer normally operates PBX call control and connects it to another voice network. With a hosted PBX, the provider operates call control and customer devices register to that platform. The words describe responsibility boundaries, not guaranteed features or quality.
A trunk buyer manages extensions, dialplan, upgrades and often media policy. A hosted-PBX buyer delegates more of those functions but still controls users, credentials, local networks and lawful calling use.
Architecture and failure ownership
A trunk failure can sit in PBX routing, peer authentication, DNS, firewall, SDP, media NAT or the far-end network. A hosted model adds endpoint provisioning and access-network conditions but removes some customer-managed PBX components. In both cases, a SIP response should be attributed to the hop that generated it.
Security follows control: the party operating a component should patch it, restrict administration, retain useful logs and maintain recovery procedures.
Selection questions
Choose a trunk when internal engineering needs direct dialplan and routing control. Choose hosted call control when operational delegation is more valuable than PBX customization. Evaluate emergency calling, numbering, recording, data handling and support separately; none is implied merely by either architecture label.
Expected result and failure handling
Related engineering resources
Migration and continuity evidence
Plan coexistence before cutover: number-routing state, endpoint registration, inbound/outbound test groups, caller identity, voicemail or application dependencies, emergency-service location and rollback. Define who can reverse the routing change and how long the previous platform remains recoverable. A DNS or credential switch without a tested reverse path is not a complete migration plan.
Continuity testing should cover site access failure, platform or PBX unavailability, loss of one route, DNS failure and administrator lockout. Record which functions remain available and which require manual action. Compare both architectures using the same business scenarios and evidence window rather than feature lists alone.
Acceptance criteria
Choose only after the proof of concept meets documented call-flow, media, security, administration, reporting, continuity and support criteria. Record unresolved gaps and their owner. Price comparison without operational ownership, recovery time and migration cost is incomplete.
Evidence review
Have the teams that will operate the chosen model review the proof-of-concept record. They should be able to locate a failed call by UTC time and identifier, determine whether the customer or platform owns the next diagnostic boundary, and execute the documented rollback without undocumented access. Validate administrative audit logs, least-privilege roles and after-hours escalation. A feature demonstrated by a sales workflow but unavailable to operations is not an accepted production capability.
Revisit the decision when call volume, sites, compliance obligations, integration needs or support staffing changes. The better architecture is the one whose risks and responsibilities remain observable and supportable for the current operating model.
Decision model: control boundary and operations
A SIP trunk keeps call-control responsibility with the customer-managed PBX or session border architecture; hosted PBX moves more call-control functions into the service platform. The decision is not simply capex versus opex. Inventory who owns endpoint provisioning, dialplan, upgrades, redundancy, number routing, security monitoring, recording, emergency-service configuration and incident evidence.
| Area | SIP trunk with customer PBX | Hosted PBX |
|---|---|---|
| Call control | Customer operates PBX and dialplan. | Service platform operates core call control. |
| Endpoint lifecycle | Customer or integrator manages compatibility. | Provider-supported endpoint model usually applies. |
| Network boundary | SIP/RTP interconnection plus local LAN/WAN. | Endpoint-to-cloud access plus service edge. |
| Troubleshooting evidence | Customer has PBX logs and trunk boundary captures. | Provider may hold more server-side evidence. |
| Change control | Customer schedules PBX configuration changes. | Platform release and tenant controls are shared. |
| Resilience | Customer designs PBX/SBC/site continuity. | Provider platform plus customer access continuity. |
Neither model removes the need for access-network quality, endpoint security, numbering governance or tested continuity. Hosted service can reduce server administration while increasing dependence on platform controls and WAN reachability. A trunk can maximize control while increasing responsibility for patching, fraud prevention and recovery.
Validate before choosing
Run a proof of concept using representative endpoints, call volumes, codecs, transfers, early media, DTMF, failover and reporting. Define acceptable evidence for registration or device state, call admission, media quality and incident escalation. Test loss of primary internet, DNS failure and credential/certificate rotation. Confirm how each model handles emergency-service location and lawful requests under the applicable agreement.
Control owner:
PBX/platform change window:
Endpoint support boundary:
SIP/RTP evidence available:
Failover test result:
Security monitoring owner:
Rollback owner:Security and exit planning
Document credential/key ownership, administrative roles, logging access, retention, source restrictions, fraud limits and patch responsibility. Also define export and exit: numbers, configuration, recordings or metadata, portability process and deletion obligations. Architecture fit is incomplete without a tested recovery and migration path.
Authoritative references
Planning a wholesale SIP interconnection? Review ARCAMUSA interconnection requirements. Examples here are educational and do not define a service order.
Additional primary reference
Implementation closure
Required call-control features, administrative ownership, evidence access, continuity targets, porting constraints, and exit requirements; map each requirement to the party that will operate it.
Architecture and service-responsibility decision record; configuration is not changed by this comparison.
Approve the responsibility matrix before selecting or migrating a platform. No reload or restart applies.
The selected model has an accountable owner for call control, media, security, logging, resilience, and migration.
If a candidate cannot provide required evidence or exit terms, record the gap and reject or condition the selection.
Stop the selection when regulatory scope, number control, emergency calling, data access, or recovery ownership is ambiguous.
Stakeholders approve the control boundary, acceptance tests, failure ownership, security duties, and rollback or exit plan.