STIR/SHAKEN and the Programmable SBC: How Configurable Routing Puts Attestation Control Where It Belongs

STIR/SHAKEN call authentication through a programmable SBC

STIR/SHAKEN is no longer optional for most US voice service providers. The FCC’s implementation mandate, strengthened by the September 2025 own-certificate rule, means every originating provider needs infrastructure that signs calls with their own certificate, assigns the correct attestation level per call, and fails gracefully when the signing service is unavailable.

The Session Border Controller (SBC) is where all of this happens. It sits at the originating edge of the network, the last point of control before a call leaves your domain. But SBCs differ significantly in how they handle STIR/SHAKEN. Some offer a static, proprietary integration tied to a single signing partner. Others expose a configurable routing engine that gives the provider full control over attestation logic, partner selection, and fallback behavior.

This page explains what happens at the SBC layer during STIR/SHAKEN signing and verification, why configurable routing matters for compliance, and how ProSBC’s open architecture handles it.

Key Terms and Concepts
A quick-reference glossary for terms used throughout this article.
STIR/SHAKENAn industry framework (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENS) for cryptographically verifying caller identity to prevent spoofing. The SBC acts as both a signing point (originating side) and a verification point (terminating side).
STI-AS (Authentication Service)The external signing service that uses the provider’s certificate to generate a cryptographic signature and return a signed Identity header to the SBC.
STI-VS (Verification Service)The external service that validates the signature in an inbound Identity header against the originating provider’s certificate and returns the verification result to the terminating SBC.
STI-CA (Certificate Authority)The authority that issues the digital certificates used by STI-AS and STI-VS to sign and verify Identity headers.
PASSporTThe JSON Web Token carried inside the SIP Identity header. It contains the orig (originating number), dest (destination number), iat (timestamp), and attestation claim used by STIR/SHAKEN.
Identity HeaderThe SIP header that carries the signed PASSporT token. The originating SBC injects it into the outbound INVITE, and the terminating SBC passes it to the STI-VS for validation.
Attestation Level (A/B/C)A per-call indicator of how confident the originating provider is in the caller’s identity. A = Full, B = Partial, C = Gateway. The level affects how downstream providers treat the call.
P-Identity-BypassA fallback SIP header appended by the SBC when the signing service is unreachable after retries. It signals to downstream providers that signing was unavailable for that specific call, so the call can still complete.
Configurable Routing EngineThe Ruby-based routing engine inside ProSBC that evaluates each call against operator-defined logic and decides attestation level, signing partner, and fallback behavior per call, rather than applying a blanket rule per trunk.
FCC Own-Certificate RuleThe September 18, 2025 FCC requirement that voice service providers sign calls using their own STIR/SHAKEN digital certificate rather than relying on a third party’s. Attestation-level decisions must stay with the provider.

How STIR/SHAKEN Works at the SBC Layer

The STIR/SHAKEN framework assigns two distinct roles to service providers: the originating provider signs the call, and the terminating provider verifies the signature. The SBC is the enforcement point for both.

Signing (Originating Side)

When a call enters the SBC from a customer trunk, the SBC collects the call details it needs for the PASSporT token: the originating number (from the P-Asserted-Identity or From header), the destination number (from the To header), and the timestamp (from the Date header). It determines the appropriate attestation level for the call, then sends a signing request to an external STIR/SHAKEN Authentication Service (STI-AS). The STI-AS uses the provider’s certificate to generate a cryptographic signature, wraps it in a PASSporT token, and returns a signed Identity header. The SBC injects that Identity header into the outbound SIP INVITE before forwarding the call.

Verification (Terminating Side)

When the SBC receives an inbound call carrying an Identity header, it forwards that header to a STIR/SHAKEN Verification Service (STI-VS). The verification service validates the cryptographic signature against the originating provider’s certificate, checks that the token has not expired, and confirms the calling and called numbers match the PASSporT claims. The result comes back to the SBC, which routes the call accordingly.

Attestation Levels

Every signed call carries one of three attestation levels, determined by the originating provider:

  • A (Full Attestation): The provider authenticates the calling party and confirms they are authorized to use the calling number.
  • B (Partial Attestation): The provider can authenticate the call’s origin but cannot verify the caller’s authorization to use the specific number.
  • C (Gateway Attestation): The call entered the network from an external source the provider cannot authenticate.

The attestation level is not decorative. It directly affects how downstream providers and analytics platforms treat the call. A-level calls pass through, while C-level calls get flagged or blocked. Getting this wrong has real consequences for call completion rates.

STIR/SHAKEN call flow through the originating and terminating SBC showing signing and verification paths

STIR/SHAKEN signing and verification flow through ProSBC. The originating SBC sends SIGNING requests to the STI-AS and injects the returned Identity header into the outbound INVITE. The terminating SBC sends VERIFICATION requests to the STI-VS and routes on the result. Primary and secondary signing URLs provide failover, and a P-Identity-Bypass header lets the call complete if the signing service is unreachable. Click to enlarge.

Why Attestation Control Belongs at the Routing Layer

Attestation is a per-call decision. It depends on what you know about the call source, and that knowledge lives in your routing logic.

Consider an ISP running a single SBC that handles three types of traffic: retail SIP trunking customers (you issued the numbers, you authenticate the subscriber), wholesale transit from a regional carrier (you know where it came from but cannot verify the caller), and gateway traffic from an international partner (untrusted source). The correct attestation level is A for the first, B for the second, and C for the third. All three pass through the same SBC.

An SBC that only supports a blanket attestation level per trunk forces you to choose one. Assign A to everything and you are making false attestation claims, which violates FCC rules. Assign C to everything and your retail customers’ calls get flagged as unverified, damaging their completion rates.

This is where configurable routing becomes a compliance requirement, not just a convenience. The routing engine evaluates each call against your business logic and assigns the attestation level dynamically. Retail customer on a trunk you provision? A-level. Wholesale transit where you know the originating carrier? B-level. Gateway traffic from an untrusted international peer? C-level.

The FCC’s own-certificate rule, effective September 18, 2025, reinforces this. Your organization must make the attestation-level decisions. A signing service can perform the technical act of signing, but it cannot assign attestation independently. For a detailed breakdown of the own-certificate rule and what it requires, see our page on the FCC STIR/SHAKEN Own Certificate Rule.

If your SBC treats attestation as a static configuration rather than a routing decision, you will struggle to stay compliant as your traffic mix evolves.

Open Partner Model vs. Proprietary STIR/SHAKEN

Not all SBC vendors handle STIR/SHAKEN integration the same way. Some, including Ribbon and AudioCodes, offer proprietary STIR/SHAKEN implementations that constrain which signing service you can use. The integration is built into the SBC firmware, which simplifies initial setup but limits your options if you want to switch signing partners, add fraud scoring, or integrate additional compliance services.

ProSBC takes a different approach. Its configurable routing engine integrates with any HTTP-based signing service through Ruby API modules. TransNexus ClearIP, Neustar, or any other STI-AS that accepts standard HTTP signing requests: the integration is at the routing layer, not embedded in firmware.

How this works in practice: the StirShakenSapi module sends an HTTP signing request to your configured signing service URL, carrying your authorization token and the call details (originating number, destination, timestamp, attestation level). The signing service returns a signed Identity header, and the SBC injects it into the outbound INVITE. The same approach underpins ProSBC’s broader REST and routing API, which is why the STIR/SHAKEN integration behaves the same way as any other external call the routing engine makes.

Three architectural advantages come from this approach:

Redundancy

ProSBC supports both a primary and secondary signing service URL. If the primary is unreachable, the request automatically fails over to the secondary. If both are down, a P-Identity-Bypass header is appended to the call, signaling to downstream providers that signing was unavailable for that specific call. The call still completes.

Partner Flexibility

Switching signing services means updating a URL and authorization token in the routing configuration. No firmware update, no vendor engagement, no service window. If TransNexus raises prices or Neustar adds a feature you need, the migration is a configuration change.

Composability

Because the signing request is an HTTP call within the routing script, you can combine it with other API integrations in the same call flow. TransNexus ClearIP, for example, supports LCR (Least Cost Routing), fraud scoring, and STIR/SHAKEN signing in a single query. ProSBC’s routing engine can evaluate the fraud score, make a routing decision, and sign the call in one pass.

ProSBC’s STIR/SHAKEN Implementation

ProSBC supports three STIR/SHAKEN request types through its Ruby API modules:

Signing

The SBC sends a SIGNING request to the configured STI-AS. It populates the PASSporT claims from the SIP message: orig from the P-Asserted-Identity or From header, dest from the To header, and iat from the Date header. The signing service returns a signed Identity header containing the digital signature and attestation level, which the SBC injects into the outgoing INVITE.

Attestation

For deployments that separate the attestation decision from the signing operation, the SBC can send an ATTESTATION request. This allows the provider’s attestation logic to run independently of the signing service, which keeps the own-certificate requirement satisfied even when signing is delegated.

Verification

On the terminating side, the SBC sends a VERIFICATION request, passing the inbound Identity header to the STI-VS. The verification result informs routing decisions downstream.

Reliability and Compliance Features

The implementation includes several reliability and compliance features:

  • Configurable timeout: Each HTTP query to the signing service has a configurable timeout. This prevents signing latency from blocking call setup when the signing service is slow or unresponsive.
  • Primary and secondary URLs: Both signing and verification services support dual URLs for automatic failover.
  • P-Identity-Bypass fallback: If the signing service is unreachable after retries on both URLs, the SBC appends a P-Identity-Bypass header rather than blocking the call. The call completes, and the header provides transparency about why the Identity header is absent.
  • Domain-based routing: For networks handling both Mobile Origination (MO) and Mobile Termination (MT) traffic, the implementation supports domain-based routing to apply different STIR/SHAKEN behavior per call direction.
  • Validated partner integrations: ProSBC has documented integrations with TransNexus ClearIP (combined LCR, fraud scoring, and STIR/SHAKEN) and Neustar (authentication, verification, and 302 redirect processing). These are validated, production-tested integrations, not generic API claims.
Configuration prerequisite: The Publish raw SIP to Routing Script setting must be enabled under SIP Stack for the iat (timestamp) parameter to be available to the signing module. This is a one-time configuration step.

Getting Started

If you are evaluating how your SBC handles STIR/SHAKEN, or deploying STIR/SHAKEN for the first time, ProSBC offers several paths.

ProSBC Lab

ProSBC Lab is a free, permanent 3-session license for lab and testing use. It is self-serve and takes roughly 20 minutes to set up. You can configure STIR/SHAKEN signing and verification in a lab environment before committing to production.

30-Day Free Trial

The 30-day free ProSBC trial gives you 500 concurrent sessions for production evaluation. If your STIR/SHAKEN implementation needs testing at scale before going live, the trial covers it.

Managed Service

ProSBC Managed Service is available for providers who want TelcoBridges to handle STIR/SHAKEN configuration, monitoring, and ongoing compliance management. The managed service can be deployed on your own infrastructure (AWS, Azure, VMware, KVM, on-premises) or hosted by TelcoBridges. Your organization retains full access.

For providers already running an SBC with proprietary STIR/SHAKEN integration and looking for more flexibility, or for those deploying STIR/SHAKEN for the first time under regulatory pressure, the combination of configurable attestation control, open partner selection, and built-in redundancy is what makes this approach work.

Frequently Asked Questions

How does an SBC handle STIR/SHAKEN?
The SBC is the enforcement point for both STIR/SHAKEN signing and verification. On the originating side, it collects call details (originating number, destination, timestamp), determines the attestation level, sends a SIGNING request to an external STIR/SHAKEN Authentication Service (STI-AS), and injects the signed Identity header into the outbound INVITE. On the terminating side, it forwards inbound Identity headers to a STIR/SHAKEN Verification Service (STI-VS) for signature validation and routing decisions. The SBC supports configurable failover, P-Identity-Bypass for unavailable signing services, and per-call attestation logic.
What is the difference between STIR/SHAKEN attestation levels?
STIR/SHAKEN defines three attestation levels. A (Full Attestation) means the provider authenticates the calling party and confirms they are authorized to use the calling number. B (Partial Attestation) means the provider can authenticate the call’s origin but cannot verify the caller’s authorization to use the specific number. C (Gateway Attestation) means the call entered the network from an external source the provider cannot authenticate. The attestation level directly affects how downstream providers and analytics platforms treat the call: A-level calls pass through, while C-level calls get flagged or blocked.
Why does attestation need to be a per-call decision?
A single SBC often handles multiple traffic types at once: retail customers you provision and authenticate, wholesale transit from known carriers, and gateway traffic from untrusted peers. Each traffic type warrants a different attestation level (A, B, and C respectively). Assigning a blanket level per trunk either results in false attestation claims (FCC violation) or downgrades legitimate calls to C-level, hurting completion rates. Per-call attestation lets the routing engine pick the right level for each call based on the source context.
What happens if the STIR/SHAKEN signing service is unavailable?
ProSBC first tries the primary signing service URL, then automatically fails over to the secondary URL. If both are unreachable after retries, the SBC appends a P-Identity-Bypass header to the SIP INVITE rather than blocking the call. The header signals to downstream providers that signing was unavailable for that specific call, allowing the call to complete while preserving transparency about why no Identity header is present.
Can ProSBC work with any STIR/SHAKEN signing service?
Yes. ProSBC’s configurable routing engine integrates with any HTTP-based STI-AS through Ruby API modules. Documented, production-tested integrations exist for TransNexus ClearIP (combined LCR, fraud scoring, and STIR/SHAKEN) and Neustar (authentication, verification, and 302 redirect processing). Switching signing partners is a configuration change (URL plus authorization token), not a firmware update.

Test Your STIR/SHAKEN Configuration with ProSBC

Ready to see how a configurable SBC handles per-call attestation, open partner integration, and P-Identity-Bypass fallback? Start in a lab with ProSBC Lab, or evaluate at production scale with the 30-day free trial. Both paths let you configure STIR/SHAKEN signing and verification end-to-end with your preferred signing partner.

Request a Demo
Start Your 30-Day Free Trial

Explore ProSBC documentation and technical resources

✕