Who Owns the Trunk, PBX, Network, CRM and Dialer?

Business calling crosses systems owned by different people. The SIP trunk carries calls to and from the public network. The PBX controls internal telephony and call routing. The office network carries signalling and audio. The CRM owns customer and work records. The dialer owns campaign workflow and attempt state. Reliable operation depends on keeping those ownership boundaries explicit.

When every symptom is called “a phone-system issue,” teams change the wrong component, expose credentials and delay recovery. This guide maps each authority, the evidence it can provide and the handoffs required for an end-to-end service.

The SIP trunk and public numbers

The telecom provider owns the external trunk service, number activation, permitted caller IDs, channel allocation, supported authentication and its network routing. The customer owns the account relationship and must order the correct service, keep it active, provide authorised details and raise provider cases.

The provider can confirm whether it delivered an inbound call, accepted an outbound attempt or rejected signalling. It may impose number formats, codecs, source-address restrictions or concurrency limits. The PBX cannot create capacity that the provider did not supply.

SIP usernames, passwords, tokens and provider network details are sensitive. They should enter the system through a protected administrative flow, not be copied into public tickets, articles or AI prompts. A provider reference document can explain expected setup but does not prove the current account state.

The PBX and live call execution

The PBX—Asterisk in the MYLO appliance model—is the authority for loaded trunks, endpoints, routes, dialplan and live call events. It decides how a received call is matched and where it goes, or how an outbound call is constructed within configured rules.

The telephony administrator owns supported changes. Before changing production, observe the loaded state, prepare a scoped proposal, obtain approval, back up affected configuration, validate syntax, reload safely and verify with a real call. A database row or saved form does not override what the PBX has actually loaded.

The PBX can show that it attempted a destination, received a response or created a media channel. It cannot prove that a human understood the audio, that a CRM case was correct or that the carrier’s wider network is healthy.

The network and machine

Linux and network devices are the authorities for interfaces, addresses, routes, DNS, processes, ports and reachability. The customer’s network owner manages Internet service, routers, switches, VLANs, NAT, firewall policy, Wi-Fi or wired access, and power for local equipment.

SIP signalling may work while RTP audio fails because they use different paths and ports. One-way audio, intermittent registration or poor quality often requires evidence from both PBX and network. Do not infer current topology from an old diagram or application record. Inspect live state, packet paths and time-correlated logs.

Network changes can remove management access as well as calls. Require complete information, recovery access, a bounded plan and validation. A MYLO appliance’s physical ports do not automatically configure the customer router or provide redundant Internet.

The CRM

The CRM owns customer identities, accounts, cases, leads, consent or preference records when designed for that purpose, and the business workflow around them. Its application owner defines who may view or update those records and how integrations authenticate.

A telephony integration may read a contact, request a call or write an outcome. It should use stable identifiers and an explicit contract. Decide what happens when the CRM is slow, returns duplicate requests, changes a field or is unavailable after a call completes. Telephony must not invent a successful CRM update, and CRM state must not masquerade as proof of a live call.

Keep data minimal. Do not duplicate all CRM content into telephony simply because an API makes it possible. Define retention, reconciliation and deletion for the fields that are genuinely needed.

The dialer and campaign state

The dialer owns campaign configuration, eligible leads, pacing, approved caller-ID choices, attempt state, pause and resume, results and operational reporting within its supported model. It coordinates call legs but relies on the PBX for live execution and the provider for public connectivity.

Campaign capacity depends on provider channels, PBX resources, connection pattern and agent availability. A dialer setting cannot guarantee connections. Before production, run a functional test that follows the real pattern: customer-first or agent-first, extension or mobile, human or IVR. Verify both legs, bridge, audio, hang-up and result classification.

Keep failure meanings distinct. Customer no-answer, provider rejection, agent no-answer and system failure need different treatment. Retrying a customer because an employee failed to answer can create poor customer experience and misleading reports.

MYLO’s role across the boundaries

MYLO provides guided management and application workflow around supported telephony operations. It may explain evidence, ask for missing information and prepare a proposal. Its deterministic services enforce roles, approvals, allowed scope, validation, backup, execution and verification. MYLO’s database owns its users, permissions, approvals, campaign records and application history.

MYLO is not the SIP provider, the customer router or the CRM. It does not turn external account status into an internal setting. It also is not identical to the broader MyLineHub open-source platform or to custom development. An unsupported integration requires separate discovery and ownership.

Use a source-of-truth map

Handoffs must be explicit

For inbound calling, the provider receives the public call and delivers signalling to the agreed customer boundary. The network permits that traffic to reach the PBX. The PBX matches the called number and executes the approved route. An endpoint or queue handles the call. A CRM integration may display or record business context.

For outbound calling, the dialer or authorised user requests a call within approved rules. The PBX creates and connects legs. The network carries signalling and media. The provider accepts the authorised caller ID and delivers the public leg. The dialer records operational outcomes; the CRM may receive a mapped business result.

At every handoff, define identifiers, timestamps, security, timeout, retry and failure ownership. Shared correlation IDs help evidence from different systems tell one story without collapsing their authorities.

Diagnose by narrowing the boundary

Begin with a precise example: direction, source and destination, public number, time with timezone, affected user, expected route and observed result. Protect sensitive values when sharing evidence. Determine whether the failure affects all calls, one provider, one route, one endpoint or one integration.

1. Confirm the provider account and public service where relevant.
2. Check current network reachability and paths.
3. Inspect PBX loaded configuration and time-correlated events.
4. Check endpoint or agent availability.
5. Inspect dialer or CRM records only for the state they own.
6. Reproduce safely and collect end-to-end evidence.

Avoid making broad changes while evidence is incomplete. Several simultaneous “fixes” can hide the original cause.

Example: an outbound call is not recorded in CRM

The customer and agent spoke successfully, but the CRM shows no outcome. The provider and PBX evidence confirm the call. The dialer has a completed attempt with a correlation ID. The integration log shows that the CRM API timed out.

This is not a trunk or PBX failure. The application owner should determine whether the integration can retry safely or reconcile the completed attempt without duplicating business actions. The telephony result should remain intact even while CRM synchronization is pending.

If the call had never left the PBX because the provider rejected caller ID, the carrier and telephony owners would investigate instead. Precise ownership prevents a CRM symptom from causing an unrelated trunk rewrite.

Govern changes that cross systems

A change to caller ID may require provider authorization, PBX configuration, dialer eligibility and CRM display updates. One approval does not give every component unrestricted write access. Plan the sequence, responsible owner, rollback boundary and acceptance test.

Back up what can actually be restored. A PBX configuration snapshot cannot restore a CRM database or reactivate a carrier account. Each system owner maintains its recovery process. After restoration, verify the end-to-end journey again because external dependencies may still differ.

Operational checklist

• Maintain current inventories of numbers, trunks, routes, endpoints, campaigns and integrations.
• Name a primary and backup owner for each authority.
• Store credentials only in approved protected systems.
• Use one authoritative source for each kind of state.
• Correlate events without copying unnecessary customer data.
• Monitor outcomes as well as component health.
• Test representative inbound and outbound journeys regularly.
• Document provider, network, PBX, CRM and dialer escalation paths.
• Review access and retention when staff or policy changes.
• Run incident and restore exercises before a real emergency.

The bottom line

The provider owns public telecom service; the PBX owns loaded call behaviour; Linux and network devices own current connectivity; the CRM owns customer workflow data; and the dialer owns campaign orchestration. MYLO guides supported operations without replacing those authorities.

Assign people to each boundary, define the handoffs and test the whole journey. Clear ownership turns a complex chain into a manageable business service and makes faults faster to locate, explain and resolve.