Carrier identity — OCN, RespOrgID, Filer ID, and the SHAKEN identifier stack

A single US voice provider is named by several different identifiers at once. The same company might carry a four-character OCN in number-assignment and routing records, a RespOrgID against its toll-free records, a Service Provider Code embedded in its STIR/SHAKEN certificate, a Form 499 Filer ID in the FCC’s contributor systems, and an FCC Registration Number that ties its filings together. Each was minted by a different administrator for a different purpose, at a different point in the history of US telephony, and most of the time they coexist without anyone needing to line them up. They are not interchangeable, and they are not redundant — they answer different questions about the same entity.

The glossary defines each of these in isolation. This page does the other half of the job: it connects them. The reason the connection matters is that caller authentication — STIR/SHAKEN — is the one place in the modern network where these identifiers have to converge. A signed call carries a claim about who originated it and what authority they held over the calling number, and answering that claim means walking from a certificate, through a Service Provider Code, back to a real legal entity with a regulatory filing on record. The identifiers are the rungs of that ladder.

OCN — the company code for the geographic-number world

The Operating Company Number is the oldest and most load-bearing of the carrier identifiers. It is a four-character alphanumeric code assigned by NECA — the National Exchange Carrier Association — that uniquely identifies a telecommunications company in the numbering and routing infrastructure of the North American Numbering Plan. Historically OCNs distinguished operating companies for inter-carrier settlement and access billing; in the modern network they are the backbone identifier for number assignment and routing records.

When a service provider obtains numbering resources — a block of numbers from the Pooling Administrator, a full NXX from the numbering plan administrator — those resources are recorded against its OCN. Routing data that tells the network where a number lives, including the records maintained for number portability, is keyed on OCN. So the OCN is, in practice, the identifier that answers “which carrier holds this geographic number?” It is the provenance record for a local (non-toll-free) telephone number, sitting underneath the more visible business of dialing and routing described on the telephone numbers page.

A company can hold more than one OCN — large carriers commonly do, reflecting historical acquisitions, distinct operating entities, or separate service categories. That is the first hint of why the identifier stack does not collapse into a single number: the mapping between a legal entity and its codes is many-to-one in several places at once.

RespOrg and RespOrgID — the toll-free parallel

Toll-free numbers live in an entirely separate administrative world from geographic numbers, and they have their own identity layer. A toll-free number (8XX) is not assigned through the geographic numbering plan; it is a record in the SMS/800 registry administered by Somos. The entity responsible for that record is the Responsible Organization, universally shortened to RespOrg, and each RespOrg is identified by a RespOrgID.

The RespOrg is the party with control over a toll-free number’s record — it reserves the number, manages its routing, and is accountable for it in the registry. The RespOrgID is the identifier for that party. This is deliberately analogous to the OCN’s role in the geographic world, but it is a distinct identifier issued by a distinct administrator (Somos rather than NECA) governing a distinct class of numbers. A company that originates from both geographic and toll-free numbers will carry both an OCN and a RespOrgID, and the two are not derivable from one another.

The distinction matters for caller authentication because the “who holds this number” question has two different answers depending on whether the number is geographic or toll-free, and the authoritative record lives in two different systems. Any mechanism that wants to verify right-to-use a number — including the Do-Not-Originate machinery and the emerging know-your-customer proposals — has to reach into the correct registry for the number type in question.

SPC and SPID — the identifier SHAKEN actually binds to

In STIR/SHAKEN the relevant identifier is the Service Provider Code, the SPC, sometimes rendered as a Service Provider Identifier (SPID). For most US providers the SPC is the OCN — the same four-character NECA code, reused as the provider’s identity in the authentication framework. This reuse is convenient and intentional: the framework did not invent a new namespace where a serviceable one already existed.

What makes the SPC consequential is what it is bound to. When a provider is authorized to sign calls, it obtains a STIR/SHAKEN signing certificate from a certificate authority within the governance hierarchy. That certificate carries a TNAuthList — a field that asserts the provider’s authority, expressed in terms of its Service Provider Code (and, in the more granular cases, telephone-number ranges). The certificate is, in effect, a cryptographic statement that “this key belongs to the provider holding this SPC.” When a terminating provider verifies a signed call, it checks the signature against that certificate and reads the SPC out of it.

The right to obtain such a certificate is itself gated. A provider proves its entitlement to a Service Provider Code to the policy administrator and receives an SPC token — a short-lived credential that authorizes the provider to request a certificate bound to that code. The token is the proof of right-to-use the SPC, and the certificate authority will not issue a certificate without it. So the chain at the technical layer runs: the provider holds an SPC (usually its OCN), proves that holding to obtain an SPC token, and uses the token to obtain a certificate whose TNAuthList names the SPC. The SHAKEN page treats this machinery in operational detail; the point here is that the identifier the whole apparatus is built around is the same company code that started life as a settlement-and-routing identifier.

Form 499 Filer ID — the FCC’s contributor identity

The identifiers above describe a provider’s place in the numbering and authentication infrastructure. The FCC maintains its own identity layer for regulatory purposes, and the principal entry point is the Form 499 Filer ID. Telecommunications carriers and interconnected VoIP providers that contribute to federal universal service and other programs register with the FCC by filing Form 499-A, the annual Telecommunications Reporting Worksheet. The registration produces a Filer ID — sometimes called the 499 ID or 499 Filer ID — that identifies the contributor in the FCC’s systems.

The Filer ID is a regulatory identity rather than a routing or numbering one. It does not tell the network where a number lives; it tells the FCC and its administrators which legal entity is the filer of record for a given set of obligations. Because the 499 registration carries entity information — legal name, contact details, the categories of service the filer provides — it is one of the anchors that ties an abstract code to a real company. Where the OCN answers “which carrier holds this number,” the Filer ID answers “which registered entity is this, in the FCC’s books.”

FRN — and how the RMD ties filing to identity

Underneath the FCC’s various filing systems sits the FCC Registration Number, the FRN, issued through the Commission’s CORES registration system. The FRN is the common key that links an entity’s filings across FCC systems — a single registration handle that the Commission’s databases use to recognize the same party in different contexts. A provider’s 499 registration, its various license and authorization records, and its robocall-mitigation filing all attach to the same FRN.

This is the hinge that connects technical identity to regulatory accountability. Every provider whose traffic enters the US network must file in the Robocall Mitigation Database, and that filing is created against the provider’s FRN through CORES. The RMD record states the provider’s STIR/SHAKEN implementation status and its robocall-mitigation practices, and because it is keyed on the FRN it is bound to the same regulatory identity as the provider’s 499 filing. The RMD is therefore the place where a provider’s regulatory identity, its self-asserted authentication posture, and its right to have traffic accepted on the US network all meet in one record — and the chain-of-trust rule that makes RMD listing a precondition for downstream acceptance gives that record operational teeth.

Do-Not-Originate runs alongside this from the number side. Where the RMD ties a provider’s filing to its identity, DNO protects the numbers themselves — unused, unallocated, and inbound-only numbers that should never appear as a calling party. The DNO page treats the mechanism in full; the relevant point here is that DNO and the carrier-identity stack are complementary halves of the same provenance question. DNO asks whether a number can legitimately originate a call at all; the identity stack asks who, if anyone, holds the authority to assert it.

The throughline — feeding STIR/SHAKEN authorization

Pull the identifiers into a single line and the structure becomes clear. A provider holds an OCN (and a RespOrgID for any toll-free numbers) that records which numbers it controls. That OCN, as the Service Provider Code, is what its STIR/SHAKEN certificate is bound to via the TNAuthList. The provider’s right to that code is proven by the SPC token before any certificate issues. The same provider holds a Form 499 Filer ID and an FCC Registration Number that identify it as a real legal entity in the FCC’s systems, and its RMD filing — created against that FRN — connects the regulatory entity to its place on the network.

When a terminating provider verifies a signed call, it is, in effect, reading this chain backward. The signature points to a certificate; the certificate names a Service Provider Code; and the registry data — the RMD filing, the 499 registration behind the same FRN — is what lets that code be connected back to a real legal entity with obligations on record. Attestation, in the STIR/SHAKEN sense, is a claim layered on top of this identity scaffolding: the originating provider asserts not only that it signed the call but that it has a known relationship to the calling number.

The connective tissue across all of it is the question of right-to-use — the matter at the center of the recent know-your-customer debate in US caller-authentication policy. An OCN or RespOrgID records which provider holds a number; an SPC token proves a provider’s right to a code; an attestation asserts a relationship between provider and calling number. Each is a different facet of the same underlying claim: that the party signing a call actually has the authority over the number it is asserting. Knowing the number’s right-to-use is the thread that runs through the entire identifier stack, and it is precisely the thread the policy debate is trying to pull tighter.

Why it matters

Carrier identity is the substrate that STIR/SHAKEN attestation stands on. A signature is only as meaningful as the chain that connects it to an accountable entity, and that chain is built out of the OCN bound into the certificate, the SPC token that proved the right to it, and the FRN-keyed RMD and 499 records that tie the code to a real company. Without that scaffolding, an attestation is a cryptographic assertion with nothing behind it; with it, the assertion becomes traceable to a party that can be held to account. This is why the carrier-identity stack sits in trust governance alongside the RMD and DNO pages — those describe the enforcement and provenance machinery, and this page describes the identifiers that machinery operates on.