Carrier vs Hosted VoIP: Who Handles What?

When people talk about “VoIP,” they often lump everything together: the phone, the voice quality, the dial tone, the system admin, the outages. In practice, VoIP (Voice over Internet Protocol) is a stack of responsibilities split across different providers. One part is the carrier side, another part is the hosted side, and the boundaries between them matter when something goes wrong.

I learned that the hard way during a busy week at a small service company. We had a hosted phone system for call routing and extensions, and we were also using a carrier for call connectivity. Everything worked perfectly until a single change triggered a rash of failed inbound calls. The hosting vendor insisted the issue was “upstream,” and the carrier insisted it was “application configuration.” The next two hours were spent tracing settings that looked correct on paper, until we finally found that a trunk provisioning detail had rolled back. The voice system itself was fine, but the connection layer was not. That event made the division of “who handles what” feel less like trivia and more like the difference between calm triage and a chaotic scramble.

This is what this article is for: a practical way to think about carrier vs hosted VoIP, what each side typically owns, where accountability can get blurry, and how to avoid the classic failure mode where both vendors say, “Not our problem.”

The simplest mental model: two contracts, two layers

A Hosted VoIP setup usually combines:

A hosted call control platform (where your extensions, call flows, voicemail, routing, and features live)
Carrier connectivity (where your calls enter and leave the public phone network)

If that sounds obvious, it still helps to picture it as a layered system. The hosted side handles how calls are treated once they arrive at your tenant or account. The carrier side handles how calls reach that point, and how telephone numbers connect to the network.

In day-to-day operations, you feel both layers at once. In troubleshooting, you want to separate them quickly, because the evidence points differently depending on where the problem lives.

What “carrier” usually includes

In most implementations, the carrier is responsible for the parts of the experience that behave like traditional telephony, including:

inbound call delivery to your provisioned service
outbound call termination to the destination network
the continuity of your direct connectivity (the trunking and interconnection)
certain regulatory and network-level behaviors, depending on the carrier’s approach

The key phrase is “network-level” and “interconnection-level.” If customers can place or receive calls at all, the carrier layer is often involved. If inbound calls ring nowhere, or if outbound calls fail for some destinations, that often starts in the carrier zone.

What “hosted” usually includes

The hosted provider typically controls the parts that look like a phone system to the business, such as:

extension accounts and authentication
call routing rules (including time conditions and paging)
voicemail boxes and greetings
call queues, hunt groups, ring groups, and similar behaviors
the way your system answers (direct to extension, IVR menu, auto attendant)
the configuration of features that make the phone system feel “yours”

The hosted layer is where the business logic lives. If inbound calls reach your system but get sent to the wrong place, loop, land in voicemail unexpectedly, or never follow the intended greeting, the hosted layer is where you look first.

Who is responsible for what, when everything is working

Before anything breaks, it helps to understand the normal flow of a call, because that flow reveals the handoff points.

Let’s say a customer dials your main number.

The carrier receives the call from the broader telephone network.
The carrier delivers that call over the provisioned connection to your hosted VoIP service.
The hosted service decides how to handle the call, based on your configuration, and where to send it next.
The hosted service then interacts with endpoints like desk phones, softphones, or mobile apps, and provides audio pathing for the call content.

Outbound is the mirror image. Your employees dial via an extension in the hosted system, the hosted system requests call placement, and the carrier handles the network route to the destination. If you experience “no dial tone” or “can’t reach outside numbers,” hosted and carrier both can be implicated, but the symptom tends to point to one side sooner.

The “who handles what” answer is often straightforward when you phrase the question precisely:

Who makes sure the phone number is reachable from the outside world?
Who decides what happens after the call arrives (ring, queue, voicemail, IVR)?
Who maintains the network transport and interconnection?
Who configures the call logic and endpoint registration?

Your job as a buyer is to ensure the two vendors each have clear obligations in those areas.

When calls fail: symptoms that point to carrier vs hosted

In the real world, you rarely get a clean “this is only carrier” or “this is only hosted” error message. Still, there are patterns. Here are common scenarios I’ve seen, along with how they usually sort out.

Inbound calls never arrive

If the phone number rings for nobody, the first suspect is almost always the carrier path or number provisioning. Think about what has to be true for a call to arrive:

the number must be correctly provisioned for service
the carrier must route inbound calls toward your service
the hosted service must have the right status to accept them

When inbound calls fail consistently for all callers, that often means the issue is not “your call routing.” The carrier may be misrouting, the trunk may not be associated with the number, or the interconnection may be down. Hosted call logic cannot run if the call never reaches it.

Inbound calls reach the system, but go to voicemail or the wrong place

If callers can ring your main line, hear your greeting, or trigger an IVR prompt, then the call is reaching hosted control. At that point, hosted configuration becomes the prime suspect.

Examples include:

time condition rules that think it is “after hours”
a ring group that doesn’t include the active extensions
a queue setting that sends callers to voicemail when agents are not available
an IVR path that sends to a default branch

These are hosted problems, even though the symptom starts as “inbound calling is broken” in the business’s perspective.

Outbound calls fail or certain destinations fail

Outbound failures can involve both layers, but they often split by type.

If no outbound calls work at all, it could be hosted call permission settings, carrier trunk status, or even endpoint authentication. If outbound works for some destinations but not others, it can be carrier routing policies, number normalization issues, or destination blocking. In hosted systems, you can also see calling pattern restrictions, but those tend to be explicit and consistent rather than destination specific.

A practical tip: ask your team to capture exact examples. “It fails when calling an 800 number” is more useful than “it fails sometimes.” Vendors can only correlate what they can reproduce or trace.

Quality problems: audio drops, one-way audio, choppiness

Quality issues are the messiest category because the root cause can be anywhere between caller and your endpoints, and the carrier-hosted division is not the only variable.

Still, there is a way to narrow it down:

If calls to one set of numbers are consistently worse, suspect carrier routing or interconnection quality.
If calls to all destinations degrade similarly, suspect your network path to endpoints, endpoint settings, or codec negotiation behaviors.
If only internal employees on the same Wi-Fi network experience issues, your local network is a more likely culprit.

Hosted providers often have tools to see signaling events and call leg behavior, and carriers often see trunk and network behaviors. Neither will fully own your internal internet link unless it’s part of the contracted scope, but they can still help you narrow where the problem begins.

The boundary is the real product

Here’s the uncomfortable truth: you are not only buying “phone service.” You are buying a system whose reliability depends on the seam between the carrier and the hosted provider.

That seam includes:

how calls are handed off
how identifiers map (numbers, authentication tokens, trunk associations)
what happens during failover
what information is logged, and how quickly support can access it
what each vendor considers “their layer” when diagnosing an incident

Two vendors can both be competent and still create a dead zone where each assumes the other side has already confirmed the prerequisite.

I’ve seen this most in number porting and trunking migrations. A hosted system might be configured correctly after migration, but if the carrier hasn’t fully completed propagation, inbound calls behave like they are going nowhere. The hosted team waits for the carrier to fix the path. The carrier waits for the hosted team to confirm the tenant status and routing. Meanwhile, the business experiences missed calls and escalations.

The fix is not “better blaming.” The fix is clarity before the migration and a shared troubleshooting approach when something drifts.

A concrete way to define ownership before you need it

You can reduce a lot of friction by writing down responsibilities in plain language, then aligning them with what each vendor can actually produce during support. When we do this internally, I focus on questions that lead to evidence, not guesses.

Below is a short list of questions that consistently separate carrier vs hosted accountability. It’s not a contract substitute, but it forces the conversation into operational reality.

For inbound calls, which vendor confirms that your dialed number is provisioned to reach the hosted platform?
For inbound call treatment (IVR, ring groups, voicemail), which vendor confirms the active call flow and time conditions?
Who provides the call detail records or call-leg logs that show whether the call reached the hosted service?
When you open a ticket, what identifiers do both sides require, caller ID, dialed number, timestamp, and any unique call ID?
During an outage, who owns the first-line assessment, and how do you escalate when both sides are involved?

If a vendor can’t answer these questions with specifics about their own tooling and workflow, that’s a red flag. Competent support can usually explain how they verify each layer.

Troubleshooting in practice: how we stop the ping-pong

In a real incident, you want to avoid the “we’ll wait for the other team” loop. Here’s a workflow that tends to work, because it maps to the layered model without pretending you can force perfect separation.

Start by identifying whether the problem occurs before or after hosted call control would be engaged.

If callers cannot reach your service at all, that points upstream.
If callers reach the system and experience incorrect behavior, that points to hosted configuration.

Then, ask for evidence aligned to the layer. Carrier support can often confirm trunk status, inbound routing behavior, and whether call attempts were received. Hosted support can confirm whether the call arrived, how it was routed, and what endpoint it was sent to.

What helps most is a shared time window and consistent call samples. If you can provide “five calls between 10:12 and 10:17, from these caller numbers, to this dialed number,” you shorten the hunt drastically. Without those samples, each team becomes forced into broad assumptions.

One episode sticks with me. We had a situation where a single department line started timing out. The hosted side eventually found a routing rule that pointed to an off-hours condition. But carrier logs suggested the calls did arrive. The carrier and hosted vendors both had pieces. The breakthrough happened when we aligned on the exact dialed number and the minute-level timestamps, so the hosted system’s call leg logs matched the carrier’s receipt record. That synchronization mattered as much as the root cause.

The most common “it depends” moments

Even with a good mental model, there are places where responsibility depends on how the service is packaged.

Ported numbers and transitional states

Number porting involves both carrier and hosted systems, because the number must be associated with the correct service provider on the outside network and then mapped correctly within your hosted environment. During a transition, inbound calls can behave inconsistently. If you are planning a migration, require a cutover window that includes enough staff coverage to watch the behavior, because the “in-between” period is where missed calls happen.

Failover and redundancy

Some systems provide multiple trunk routes, or the carrier offers redundant paths, or the hosted provider offers failover logic. Who “handles” failover depends on what is configured and what each vendor guarantees.

If a hosted provider offers the ability to reroute within the tenant during an interconnection disruption, that is hosted capability. But if your carrier contract includes specific redundancy or upstream route monitoring, the carrier is owning part of the failover story. The practical question is: what do they do during a carrier outage, and how is it triggered?

Endpoint registration and the edge between enterprise and provider

Your employees might use desk phones connected through your office network, or they might use the hosted system via mobile apps on cellular. Endpoint registration and connectivity can be affected by your local internet quality, router behavior, DNS, and firewall policies.

Hosted support can often tell you whether endpoints registered and whether call legs connected. Carrier support can tell you whether the trunk leg was attempted and completed. But neither vendor will always control your Wi-Fi or your ISP. That’s why “carrier vs hosted” is still only part of the total equation. The network between you and the hosted provider, and between endpoints and their internet, matters too.

What to ask vendors to provide during support

You don’t need proprietary tools to ask for the right outputs. You do want to know what each side can share.

Carrier support should ideally be able to show whether inbound call attempts were accepted and how they were routed. Hosted support should ideally be able to show the call progression after arrival, such as which rule was triggered and which extension or voicemail box received the call.

Also ask about time zone handling. If your hosted system logs in one time zone and your incident report uses another, you can https://getvoip.com/blog/virtual-phone-number/ lose hours. I’ve seen this happen enough that I now insist on specifying the time zone in every ticket update.

Finally, ask about how they handle call detail records. Many businesses rely on call logs for operational reporting. If you run into an outage, you want to know whether logs will continue filling in consistently, and whether partial records are available to support reconciliation.

A quick comparison you can use with your team

Here’s a simple comparison that helps align expectations. It is not a universal rule, but it reflects how most deployments are structured.

| Topic | Carrier side typically owns | Hosted side typically owns | |---|---|---| | inbound path to your service | number routing, trunk reachability, network delivery | acceptance and first-handling once the call arrives | | outbound call completion | network routing to destinations, interconnection | authorization and dial plan behavior in your tenant | | call handling logic | usually not | IVR, auto attendant, routing rules, queues, voicemail | | monitoring and evidence | trunk status, call attempt indicators | call legs, flow selection, endpoint results | | “why did my call go to voicemail” | only if call never reaches hosted | most often, yes, hosted config and availability logic |

Where the confusion usually starts

Confusion often comes from how incidents are described internally.

An employee hears, “The phones are down,” which is true from the customer’s perspective. That statement mixes together:

the ability for callers to connect to a number
the ability for the system to route that call
the ability for endpoints to ring and answer
the ability for audio to remain stable

When those are treated as a single issue, everyone scrambles. When they are separated, the right vendor can focus on their layer, and the business gets answers faster.

A helpful habit is to train your team to record three things in every incident report:

did the call reach the greeting or IVR?
did it ring any internal endpoints?
did it produce a voicemail, and if so which greeting and when?

Even basic answers like “callers heard the auto attendant” versus “callers got a fast failure tone” reduce ambiguity immediately.

Contract scope and escalation: make the seam actionable

If you are selecting or renewing services, do not stop at pricing and features. Ask about operational scope.

For carrier-managed pieces, clarify:

what constitutes an incident
expected response and escalation paths
how they handle number provisioning and changes
whether they provide proactive monitoring for trunk reachability

For hosted-managed pieces, clarify:

how configuration changes are tracked
what tenant-level monitoring exists for call routing failures
how feature behavior is validated during updates
what the support model looks like when multiple departments are affected

Then, focus on escalation mechanics when both layers are involved. Many vendors do support handoffs, but the best ones have a defined process for when to pull in the other team, what logs to attach, and how quickly they confirm whether the call ever reached the hosted platform.

If you can get that in writing, even informally, you will save days over the life of the system.

Edge cases worth planning for

Most organizations never hit these, until they do.

One edge case is partial failure. For instance, inbound calls to one number work while calls to another number fail, even though both numbers are in your account. That can be a trunk association detail or a number-to-tenant mapping issue, and it can involve both carrier provisioning and hosted configuration.

Another edge case is configuration drift after changes. A hosted provider can apply updates or you can modify routing rules. Meanwhile, the carrier layer might also be making behind-the-scenes updates. When both happen around the same time, the investigation becomes messy. That’s why change windows and change logs matter.

Finally, consider what happens when endpoints are offline. If your office internet is down, the hosted system may still be “up,” but endpoints might not register. In that scenario, you will see behavior that looks like a hosted failure to the business, even though the root cause is network connectivity. This is where “who handles what” must include the reality that your site and endpoints sit between your business and the hosted platform.

The takeaway: clarify handoffs, not just technology

Carrier vs hosted VoIP is less about which vendor has a bigger name and more about where accountability sits when a call fails.

In general terms:

Carrier handles reachability and interconnection, the path for calls to arrive at your service and to leave it reliably.
Hosted handles how calls are processed once they arrive, including routing logic, voicemail, and the behavior your users experience inside the tenant.

But the seam matters. The best setups are the ones where both vendors share a troubleshooting narrative, where logs line up to the same timestamps, and where your team can quickly answer whether calls reached hosted control or failed upstream.

If you take one action after reading this, make it the same action I pushed after that stressful inbound outage: define your responsibilities and evidence targets before you need them. A phone system is supposed to disappear into the background. The moment it doesn’t, the only way to bring it back fast is to know exactly who is responsible for each layer of the journey.