A caller ID may be authenticated when a call leaves one network yet lose that authentication information before reaching its destination. This is one of the major challenges facing modern telecommunications as legacy non-IP infrastructure continues to connect with newer IP-based voice networks.
Caller authentication through STIR/SHAKEN has improved how providers validate calling-number information. However, the framework relies on SIP-based IP networks and cannot operate in the same way across traditional non-IP technologies. For telecom operators and enterprise communication providers, this creates important questions about interoperability, network modernisation and the future of caller ID security.
Understanding this limitation is essential for building voice infrastructure that can support authentication across increasingly complex network environments.
Understanding the Difference Between IP and Non-IP Networks
How IP Networks Support Caller Authentication
Internet Protocol (IP) networks transmit voice communications using digital data packets. In modern VoIP environments, Session Initiation Protocol (SIP) is commonly used to establish, manage and terminate calls.
STIR/SHAKEN operates within this environment. It allows an originating provider to attach digitally signed caller identity information to a SIP call through an Identity header. The receiving provider can then retrieve the associated certificate and validate the signature.
This process helps establish whether the calling-number information has been authenticated by the originating provider.
What Are Non-IP Networks?
Non-IP networks use different technologies and signalling methods to carry voice calls. Traditional Time Division Multiplexing (TDM) infrastructure is a common example.
Unlike SIP-based systems, conventional TDM networks do not natively carry the STIR/SHAKEN Identity header and its associated authentication information.
Consider a call travelling through three stages:
An originating VoIP provider authenticates the caller ID.
The call passes through an intermediate network using traditional TDM infrastructure.
The call reaches a destination provider operating an IP network.
The call may still reach its destination but the original authentication information may have been lost during the non-IP transition.
This is the fundamental interoperability challenge. The issue is not necessarily that the caller ID itself disappears but that the cryptographic information used to authenticate it may no longer accompany the call.
The FCC's discussion of non-IP network limitations explains why STIR/SHAKEN authentication information can be lost when calls traverse non-IP infrastructure.
Why Non-IP Networks Create Challenges for STIR/SHAKEN
Authentication Information Can Be Lost Across Network Boundaries
STIR/SHAKEN depends on information carried within SIP signalling. When a call moves into a network that cannot preserve or process that information, the authentication chain can be interrupted.
This creates a visibility problem for downstream providers. A receiving network may not have access to the original authentication information even when the originating provider correctly signed the call.
For example, an enterprise may place an authenticated customer service call through its VoIP provider. If the call crosses a traditional TDM interconnection before reaching another IP network, the receiving provider may be unable to verify the original signature.
The result is an authentication gap rather than proof that the call is fraudulent.
Why This Matters for Robocall Mitigation
Caller ID spoofing remains a concern because fraudulent callers can imitate legitimate telephone numbers. STIR/SHAKEN helps providers identify authenticated caller identity information but its effectiveness depends partly on that information surviving the call path.
Non-IP transitions can make it harder for receiving providers to distinguish between calls carrying valid authentication information and calls where that information is unavailable.
This limitation can create opportunities for bad actors to exploit gaps between networks.
It also demonstrates why caller authentication cannot depend solely on the originating and terminating providers. Intermediate networks and interconnection arrangements matter as well.
The Impact on Telecom Providers and Enterprise Communications
More Complex Call Verification
Telecom providers must manage calls that may travel across different technologies and service environments. A call can move through several operators before reaching its destination and each transition introduces potential interoperability requirements.
When authentication information is lost, the receiving provider may need to consider other available information and apply its own call-handling policies.
Importantly, missing authentication should not automatically be interpreted as evidence of fraud. A call may have crossed a non-IP network where the framework could not preserve its original authentication data.
Business Communication and Customer Trust
For enterprises, the consequences can extend beyond network engineering.
Businesses depend on telephone calls for customer support, financial communication, appointment reminders and service notifications. If authentication information is unavailable at the receiving end, providers may have less information to support their call-handling decisions.
Imagine a healthcare organisation contacting a patient about a scheduled appointment. The originating provider may have authenticated the calling number, but a non-IP transition could prevent the destination network from receiving the associated authentication information.
The call may still be legitimate. However, the receiving network has less authentication evidence available to evaluate it.
This is why enterprises need to consider caller authentication as part of a broader voice communication strategy rather than assuming that every call will retain the same verification status across all networks.
How the Industry Is Addressing Non-IP Authentication
Network Modernisation and the Transition to IP
One approach is to upgrade legacy infrastructure so that calls can be originated, carried, processed and terminated using SIP-based IP networks.
This allows providers to implement STIR/SHAKEN across more of their network and reduces the number of non-IP transitions where authentication information could be lost.
The FCC has established requirements for providers to implement STIR/SHAKEN in applicable IP portions of their networks. Under 47 CFR § 64.6303, covered providers have also been required to either upgrade their networks or maintain documented evidence of participation in a working group, industry standards group or consortium developing non-IP caller ID authentication solutions or actively testing such a solution.
The regulation established different implementation deadlines for voice service providers, gateway providers and certain intermediate providers. Applicability and exemptions depend on the provider's role and circumstances.
For details, see 47 CFR § 64.6303.
Developing Authentication Methods for Non-IP Environments
Replacing every legacy network component is not always immediate or commercially practical. As a result, industry organisations have also explored ways to support caller authentication across non-IP environments.
The Alliance for Telecommunications Industry Solutions (ATIS) has published technical work addressing TDM call authentication. Its 2021 announcement described standards and approaches using underlying TDM capabilities or alternative IP capabilities.
These developments are important because they recognise that network modernisation and non-IP compatibility may need to progress together.
However, these approaches should not be treated as a universal solution for every legacy network or call scenario. Different signalling environments present different technical limitations.
Read more about ATIS work on non-IP call authentication.
What Could the Future of Caller Authentication Look Like?
Greater Interoperability Across Network Technologies
The future of caller authentication will depend on how effectively different network environments exchange and preserve trusted caller identity information.
A more interoperable ecosystem could reduce authentication gaps between originating, intermediate and terminating providers.
This may involve wider IP adoption, further development of non-IP authentication methods and improved procedures for handling calls that move between different signalling technologies.
The objective is not simply to authenticate more calls at their origin. It is to make authentication information useful throughout the call journey.
Stronger Network-Level Coordination
Caller authentication is a shared responsibility across the telecommunications ecosystem. Originating providers authenticate applicable calls while receiving providers verify authentication information. Intermediate providers also have important responsibilities for handling and passing authenticated information.
For example, a provider that receives an authenticated SIP call should preserve the relevant authentication information when passing the call onward, subject to applicable technical and regulatory requirements.
Better coordination between network operators can help reduce unnecessary breaks in the authentication process.
A Continued Role for Legacy Infrastructure
The transition to IP will not necessarily happen at the same pace for every operator. Some networks may continue to use legacy technologies while modernising selected parts of their infrastructure.
This means non-IP authentication research and interoperability planning will remain relevant.
The likely direction is a combination of IP network expansion, improved interconnection practices and technical approaches designed to address authentication limitations in legacy environments.
How PeeringHub Supports the IP-Based Caller Authentication Ecosystem
Reliable Certificate Infrastructure for STIR/SHAKEN
Although non-IP authentication requires broader industry-level solutions, the IP-based STIR/SHAKEN framework still depends on reliable certificate issuance and management.
PeeringHub supports this technical foundation through its STI-ACME Certificate Authority service. Its ACME server is compliant with RFC 8555 and supports automated STIR/SHAKEN certificate issuance for eligible service providers.
Providers must have their own Operating Company Number (OCN) and approved STIR/SHAKEN Service Provider status from the STI Policy Administrator before using the certificate issuance service.
Certificate Hosting and Developer Tools
Certificate issuance is only one part of the process. Certificates must also be hosted and made available through the appropriate certificate URLs.
PeeringHub provides a Certificate Repository for certificate hosting alongside its STI API and developer tools.
Its supporting capabilities include:
STI-ACME: Automates certificate issuance through the ACME protocol.
Certificate Repository: Hosts certificates for retrieval by the relevant network infrastructure.
STI API: Supports authentication token generation, private key generation and certificate requests.
Identity Header Parser: Helps technical teams decode and inspect SIP Identity header information.
Certificate Inspector: Supports examination of STIR/SHAKEN certificate details.
Python Tools: Provide additional options for developers managing certificate-related workflows.
These tools support providers implementing and maintaining the IP-based certificate infrastructure required for STIR/SHAKEN workflows.
It is important to distinguish this role from non-IP network conversion or end-to-end authentication. PeeringHub's documented services focus on certificate issuance, hosting, lifecycle management and technical inspection. They do not independently convert TDM signalling into SIP or preserve authentication information across non-IP network segments.
Explore the PeeringHub STI-ACME documentation for further details.
Conclusion: Closing the Gap Between Legacy Networks and Modern Caller Authentication
Non-IP networks present a significant challenge to the future of caller authentication because traditional signalling technologies cannot natively preserve the SIP-based authentication information used by STIR/SHAKEN. When calls cross these environments, the authentication chain can be interrupted even if the originating provider has correctly signed the call.
Addressing this challenge requires more than certificate deployment. Network modernisation, non-IP authentication research and better coordination between service providers will all influence how caller identity verification evolves.
For providers building their IP-based STIR/SHAKEN infrastructure, reliable certificate management remains an essential part of the process.
PeeringHub supports this foundation through its STI-ACME Certificate Authority service, Certificate Repository, STI API and developer tools.
Preparing your network for the next stage of caller authentication?
Visit https://www.peeringhub.io/ to explore certificate infrastructure and developer solutions that support your STIR/SHAKEN implementation.
Regulatory scope: This article discusses the U.S. FCC framework. Requirements and exemptions depend on provider classification, network configuration and applicable rules. It is an operational overview rather than legal advice.
Sources used: FCC non-IP caller authentication framework and regulations; ATIS technical work on TDM authentication; PeeringHub STI-ACME documentation. The article distinguishes existing requirements from broader industry development and does not claim that PeeringHub provides a non-IP authentication bridge.
Post a Comment