The Regulatory Landscape: What the FCC Considers a Voice Service Provider

The MSP's Guide to VoIP: Part 17 of 20

Disclaimer: This post is educational content about telecommunications regulatory classification and Voice Service Provider obligations. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

Back in Post 2, we walked through the spectrum of voice service models (referral, white-label resale, co-managed, and full stack), and at each level, we flagged that your regulatory exposure increases as you move deeper into the stack. We said we would come back to this. Here we are.

This is the part of the series where a lot of MSPs start to get uncomfortable, because the regulatory landscape around voice services in the United States is not something most IT professionals were trained on, and it does not map cleanly onto the way MSPs think about their business. You think of yourself as a managed services provider. You sell IT services. Maybe you resell some cloud subscriptions. The idea that you might be a telecommunications provider subject to FCC oversight feels like it belongs to a different industry.

But the FCC does not care what you call yourself. It cares what you do. And depending on how you have structured your voice offering, what you do might make you a Voice Service Provider in the regulatory sense, with all the obligations that come with it.

What is a Voice Service Provider

The term "Voice Service Provider" as used by the FCC has a specific meaning that extends well beyond what most people think of as a phone company. In the context of the rules around robocall mitigation and STIR/SHAKEN (which we will cover in the next two posts), a voice service provider is generally any entity that originates, terminates, or transmits voice calls over the public telephone network. The definition has been interpreted broadly, and it encompasses entities that might not traditionally think of themselves as telecommunications carriers.

The FCC's key term here is "interconnected VoIP," meaning VoIP service that connects to the PSTN. Interconnected VoIP is the trigger for provider classification. If you are offering a VoIP service that can place calls to and receive calls from regular phone numbers on the public telephone network, you are offering interconnected VoIP, and the obligations that come with that classification apply regardless of your company's size or how you describe your business.

The traditional telecom world had relatively clear boundaries. You were either a carrier or you were not. You either had switching equipment and interconnection agreements and tariffs, or you were a customer. VoIP blurred those boundaries significantly, because the cost of originating and terminating calls dropped to near zero, and the technical barrier to entry collapsed. Suddenly, any company with a SIP trunk and a PBX could originate calls onto the PSTN. And the regulatory framework has been evolving to catch up with that reality.

For MSPs, the critical question is not "am I a phone company" in the traditional sense. The question is "am I doing things that the FCC considers voice service provision." Those are different questions, and the second one catches more entities than you might expect.

The spectrum of involvement

Not every MSP that touches voice is a VSP. Your regulatory exposure depends on where you sit on the spectrum of involvement, and the boundaries are not always crisp. Let's walk through the range.

Referring clients: not a VSP

If your voice involvement consists of introducing clients to a hosted VoIP provider, collecting a referral fee, and stepping back, you are not providing voice services. You are making an introduction. The provider handles everything: provisioning, billing, support, trunking, regulatory compliance. Your regulatory exposure is effectively zero.

This is one of the genuinely nice things about the referral model, as we discussed in Post 2. Whatever its limitations in terms of margin and client control, it keeps you cleanly on the IT services side of the line.

Reselling under a provider's authority: it depends

The white-label resale model is where the picture gets murkier. When you resell a hosted VoIP platform under your brand, the question of who is the voice service provider depends on how the arrangement is structured.

In many white-label arrangements, the wholesale provider retains the role of provider of record. They hold the FCC filings, they manage the trunking, they handle E911 provisioning, they contribute to the Universal Service Fund. You are their sales channel and support front-end, but from a regulatory perspective, they are the entity providing voice services to the end user. Your agreement with them spells this out (or should).

In other arrangements, particularly as you move toward greater independence and higher margins, the regulatory responsibility may shift partially or fully to you. If you are the entity that bills the end customer for voice services, if you control the customer relationship, if you make representations to the customer that you are their phone provider, regulators may view you as a voice service provider regardless of who operates the underlying infrastructure.

The key factors that regulators and courts have considered include: who the end customer believes their provider is, who bills the customer, who controls the service, and who has the ability to make changes to the customer's service. If the answers to those questions point to you, the fact that someone else runs the platform may not insulate you from VSP classification.

Originating traffic on your own trunking: almost certainly a VSP

If you operate your own PBX infrastructure and contract directly with SIP trunk providers for PSTN connectivity, you are originating voice calls onto the public telephone network. This is the full-stack model from Post 2, and it is the scenario with the clearest regulatory implications.

When you are the entity that sends an INVITE through a SIP trunk to connect a call to the PSTN, you are originating that call. The trunk provider may handle the actual interconnection with the telephone network, but you are the entity that decided to place the call, selected the caller ID, and sent it on its way. In the context of robocall mitigation and STIR/SHAKEN, the originating provider has specific obligations that we will cover in the next two posts.

Even if you are using a trunk provider that handles STIR/SHAKEN signing and has its own FCC filings, your role as the entity that originates traffic creates regulatory surface area. The trunk provider's compliance does not automatically extend to cover you. You may have independent obligations.

The gray zone

Real-world arrangements often do not fit neatly into these categories. You might resell a hosted platform for most clients but have a few clients on a PBX you manage with your own trunking. You might use a wholesale provider for most trunking but have a direct trunk with a carrier for a specific use case. You might operate in a co-managed model where the line between your responsibilities and the provider's is defined by a contract that was written by a sales team, not a compliance team.

The gray zone is exactly where you do not want to be when the FCC comes asking questions. And the FCC has been asking more questions in recent years, particularly around robocall mitigation, because the political pressure to address robocalling has driven aggressive enforcement.

What comes with VSP classification

If you are classified as a Voice Service Provider, a set of obligations generally follows. The specifics depend on the exact nature of your service and the regulatory framework that applies, but the major categories include:

FCC registration and filings

Voice service providers in the United States are generally required to register with the FCC. This includes filing a Form 499-A (Telecommunications Reporting Worksheet) annually, which is used to determine your contribution obligations to the Universal Service Fund, Telecommunications Relay Services Fund, and other federal programs. The filing is based on your revenue from telecommunications services.

Providers operating as facilities-based voice service providers also need an Operating Company Number (OCN). An OCN is a unique identifier assigned to voice service providers that is used for billing, routing, and regulatory tracking across the telephone network. If you are operating your own trunking infrastructure and originating traffic onto the PSTN, you need one. The OCN is how the rest of the telephone network identifies your company in billing records, Local Exchange Routing Guide (LERG) entries, and regulatory filings.

If you have not been filing and you should have been, this creates a back-liability problem. The obligation existed whether you knew about it or not, and the FCC can assess contributions retroactively.

Universal Service Fund contributions

Providers of interstate and international telecommunications services are required to contribute to the Universal Service Fund. The contribution is calculated as a percentage of your interstate and international telecommunications revenues, and the percentage changes quarterly based on FCC calculations. As of recent quarters, the contribution factor has been in the range of 30 to 35 percent of applicable revenues, though this figure fluctuates.

Note that the contribution is on applicable revenue, not on all revenue. The determination of what portion of your revenue is "interstate and international telecommunications" versus other categories requires analysis that a telecom attorney or compliance consultant can help with.

A common source of confusion: many MSPs see USF surcharges on their own business VoIP bills and assume they are already handling USF. That is a consumer obligation. Your VoIP provider is passing through a portion of its USF contribution to you as a line item on your invoice. Paying USF surcharges as a consumer of voice services does not make you compliant as a provider of voice services. The moment you begin offering interconnected VoIP to clients, your USF obligation shifts from the consumer side to the provider side, and the mechanics are entirely different. You are no longer paying a surcharge passed through by someone else. You are calculating and remitting contributions based on your own telecommunications revenue.

CPNI compliance

Customer Proprietary Network Information (CPNI) rules govern how you handle information about your customers' telecommunications usage. This includes call records, calling patterns, and other data generated by their use of your service. CPNI rules require you to implement safeguards to protect this information, obtain customer consent before using it for marketing, and file an annual CPNI certification with the FCC.

If you are already handling client data under MSP agreements with appropriate security controls, the CPNI requirements may not require dramatic changes to your operations. But they are specific to telecommunications data and have their own certification requirements that are separate from any security frameworks you already comply with.

E911 obligations

If you provide voice services that can be used to call 911, you have obligations around Enhanced 911 (E911). This means ensuring that when a user dials 911, the call is routed to the appropriate Public Safety Answering Point (PSAP) and that the caller's location information is delivered with the call. For fixed locations, this means maintaining accurate address information for each endpoint. For nomadic users (employees who take their phone home or to a different office), this means having processes to update location information when users move — a requirement that most remote softphone deployments get wrong.

E911 is one of the areas where getting it wrong has consequences beyond regulatory fines. If someone calls 911 from a VoIP phone and the call goes to the wrong PSAP or arrives without location information, the delay in emergency response can have life-safety implications. This is not a theoretical concern. It has happened, and the FCC takes E911 compliance seriously for that reason.

Robocall mitigation and STIR/SHAKEN

This is the area where FCC enforcement has been most aggressive in recent years, and it is directly relevant to MSPs who originate calls. We are dedicating the next two posts entirely to STIR/SHAKEN and the Robocall Mitigation Database, so we will not go deep here. The short version: if you are a voice service provider, you are generally required to either implement STIR/SHAKEN call authentication or have a robocall mitigation program in place, and you are required to file a description of your compliance in the FCC's Robocall Mitigation Database. Failure to file can result in your traffic being blocked by downstream carriers.

State-level obligations

Federal FCC obligations are only part of the picture. Many states have their own telecommunications regulatory requirements, including state-level registration, taxation, and reporting obligations. The specifics vary significantly by state. Some states have minimal requirements for VoIP providers. Others require state-level certification of authority to provide telecommunications services. And the state-by-state variation extends beyond provider obligations to how your clients use the service: call recording consent laws differ between one-party and all-party consent states, which matters for any client recording calls across state lines.

If you have clients in multiple states, which most MSPs do, you potentially have obligations in each state where you have customers. State compliance is a separate workstream from federal compliance, and it adds meaningful complexity, particularly for smaller providers who may not have the administrative infrastructure to track and comply with requirements across dozens of jurisdictions.

"I'm just an MSP" is not a defense

The most common mistake MSPs make in this area is assuming that because they think of themselves as IT services companies, telecommunications regulations do not apply to them. This assumption is understandable but dangerous.

The FCC has been clear that the obligations around voice services apply based on what you do, not what you call yourself. If you originate voice calls onto the PSTN, you are providing a voice service. If you provide voice service to end users who rely on it for their business communications, you have the obligations that come with that. The fact that you also manage their firewalls and patch their servers does not create an exemption. If you need to verify the carrier status of numbers you manage or numbers flagged in a compliance inquiry, a Carrier Lookup can confirm the current serving carrier and number type.

This is not about the FCC targeting MSPs specifically. It is about the FCC closing gaps in the regulatory framework that robocallers and bad actors have exploited. The broad definition of Voice Service Provider is intentional, designed to ensure that every entity in the call chain has responsibilities for the calls that flow through its systems.

FCC enforcement actions against voice service providers for compliance failures have resulted in penalties exceeding six figures. For a small MSP, a single enforcement action can erase years of profit. And because USF contributions can be assessed retroactively, an MSP that has been operating a voice business for several years without proper filings could face a back-assessment covering every year of non-compliance, landing as a single bill. The financial exposure is not proportional to the size of the provider. It is proportional to the duration and scope of the non-compliance.

The distinction between what your upstream carrier handles and what falls on you

One of the most common sources of confusion is the assumption that if your SIP trunk provider is compliant, you are compliant by extension. This is not generally how it works.

Your trunk provider has its own obligations. It files its own FCC reports, makes its own USF contributions, and manages its own STIR/SHAKEN implementation. Those filings cover the trunk provider's operations. They do not automatically extend to cover yours.

Think of it this way. Your trunk provider is responsible for the calls from the perspective of a transit or terminating carrier. You are responsible for the calls from the perspective of an originating provider. These are different roles in the call chain, and each role has its own set of obligations.

That said, the specifics depend heavily on the contractual arrangement between you and the trunk provider. Some trunk providers explicitly take on certain compliance responsibilities on behalf of their customers. Others explicitly disclaim those responsibilities. The contract matters, and so does the actual operational reality.

If your trunk provider's agreement says they handle STIR/SHAKEN signing for calls originating from your trunks, and they actually do it correctly, that may satisfy your STIR/SHAKEN implementation requirement. But it may not satisfy your requirement to file in the Robocall Mitigation Database, which is a separate obligation. The layers are distinct, and each one needs to be addressed.

How to figure out where you stand

If you have been operating a voice business without thinking about regulatory classification, the right move is not to panic. It is to assess your situation methodically.

Map your involvement. For each client, trace the call path. Where does the SIP signaling originate? Who operates the PBX? Who holds the trunk? Who selected the caller ID? Who bills the client for voice service? The answers to these questions determine your role in the call chain.

Read your agreements. Look at your wholesale provider agreements, your trunk provider agreements, and your client-facing service agreements. Who is identified as the provider of record? What compliance obligations are allocated to each party? Are the allocations explicit or ambiguous?

Identify the gaps. Compare your operational reality against the obligations described above. Are you filing with the FCC? Are you making USF contributions? Do you have CPNI processes? Is your E911 provisioning current? Have you filed in the Robocall Mitigation Database?

Talk to a telecom attorney. This is the step that most MSPs skip because they do not have an existing relationship with a telecom attorney, or because they assume the cost is not justified. Both assumptions are usually wrong. Telecom attorneys who work with small providers and resellers are not rare, and the cost of a consultation to assess your situation is trivial compared to the cost of an FCC enforcement action or the operational disruption of having your traffic blocked because your Robocall Mitigation Database filing lapsed.

Why this conversation should happen before you launch, not after

If you are reading this series because you are evaluating whether to add voice to your MSP, you have an advantage: you can build compliance into your plan from the beginning. It is dramatically easier and cheaper to set up the right structure from the start than to retrofit compliance after you are already operating.

Before you sign a wholesale agreement, before you provision your first trunk, before you make your first sale, sit down with a telecom attorney and walk through your planned service model. Tell them exactly what you intend to do: what platform you plan to use, who will provide trunking, how you will bill clients, what brand name will appear on invoices. Let them tell you what obligations attach to that structure and what filings you need to make.

If the answer is "your wholesale provider handles everything and you have no independent obligations," that is great. Get it in writing. If the answer is "you need to file with the FCC, register in the Robocall Mitigation Database, and set up CPNI procedures," that is also fine, but you need to do those things before you start, not three years into operating when someone notices you have not filed.

The worst position is the one where you have been operating for years, you have hundreds of clients on voice, and you discover that you should have been filing all along. The obligations do not disappear because you were unaware of them. Back-filing is possible, but it is more complex and more expensive than getting it right from the start.

The practical reality

Let's be honest about how this plays out in practice. The vast majority of MSPs reselling white-label hosted VoIP under a wholesale provider's umbrella have limited independent regulatory obligations, because the wholesale provider is structured to be the provider of record. If you are in that category and your wholesale agreement clearly allocates compliance responsibilities to the provider, your exposure is relatively contained.

But "relatively contained" is not the same as "zero," and the landscape shifts as you move along the spectrum. If you are in a co-managed arrangement with your own trunking, or if you are operating full stack, the obligations are real and the consequences of non-compliance are material.

The next two posts cover the two areas where FCC enforcement has been most active and where the consequences of non-compliance are most immediate: STIR/SHAKEN call authentication and the Robocall Mitigation Database. These are not theoretical compliance exercises. They directly affect whether your clients' calls get completed or get blocked. Understanding them is essential regardless of where you sit on the service model spectrum.

Next up: STIR/SHAKEN: Why Your Clients' Calls Are Getting Flagged, the call authentication framework that determines whether your outbound calls show up as legitimate business or get slapped with a spam label.