Extending the SHAKEN framework to TDM networks

The SHAKEN framework is defined for SIP networks. Unfortunately, much the telephone traffic on the Public Switched Telephone Network (PSTN) does not use SIP signaling. Fortunately, the SHAKEN framework can be easily extended to accommodate TDM networks by transmitting the SHAKEN PASSporT Out-of-Band (OOB). This paper explains how.

In the PSTN, network signaling is based on Time Division Multiplexing or TDM. The telephone calls in TDM networks are transmitted via SS7 (Signaling System 7) signaling using ISUP (Integrated Services User Part) messages. ISUP signaling cannot transmit the SHAKEN PASSporT, the digitally signed PASSporT that prevents caller ID spoofing.

An ISUP-SIP gateway enables TDM networks to participate in the SHAKEN trust network. An ISUP-SIP gateway may be a network appliance, but is more commonly software running on a virtual machine. The following diagram presents the SHAKEN architecture defined in ATIS 1000074 with the addition of an ISUP-SIP gateway to enable signaling integration with TDM switches.

The following diagram is adapted from the SHAKEN standard. The boxes in light gray are defined in the SHAKEN architecture. The boxes in dark grey are the new network elements that enable SHAKEN for TDM. The ISUP-SIP Gateway converts ISUP messages into SIP messages, and vice versa. This enables the TDM switch to communicate with the SHAKEN Authentication Service (STI-AS) and SHAKEN Verification Service (STI-VS). The CPS (Call Placement Server) is a simple new network element that forwards the SHAKEN PASSporT from the originating network to the terminating network. A CPS may be service shared by many terminating service providers or each terminating service provider may run their own CPS.

SHAKEN architecture with TDM

SHAKEN architecture with TDM
Extending the SHAKEN Framework to TDM networks

Call Signing (Authentication) for outbound calls to the PSTN

  1. In the TDM switch, the first route for every call that should be signed is to the STI-AS via a trunk to the ISUP-SIP Gateway. The originating service provider’s TDM switch sends an Initial Answer Message (IAM) to the ISUP-SIP Gateway.
  2. The ISUP-SIP Gateway converts the message to a SIP INVITE sent to the STI-AS.
  3. STI-AS creates a SHAKEN PASSporT and sends it to the CPS of the terminating network.
  4. STI-AS returns a SIP 503 message to the ISUP-SIP IWF device.
  5. ISUP-SIP IWF device returns a Call Release (REL) message, with cause code 34 (No circuit available) to the TDM switch.
  6. The TDM switch route advances to the next trunk group in its local routing table to complete the call.

Call Verification for inbound calls from the PSTN

Valid PASSporT use case

  1. The first route for every inbound call that should be verified is the trunk to the ISUP-SIP Gateway. The terminating service provider’s TDM switch sends an Initial Answer Message (IAM) to the ISUP-SIP Gateway.
  2. ISUP-SIP Gateway converts the message to a SIP INVITE sent to the STI-VS.
  3. STI-VS compares the calling number, called number and time stamp of the SIP INVITE to the SHAKEN PASSporT received from the CPS.
  4. If the PASSporT is valid and matches the SIP INVITE, STI-VS returns a SIP 503 message to the ISUP-SIP Gateway.
  5. ISUP-SIP Gateway returns a Call Release (REL) message, with cause code 34 (No circuit available) to the TDM switch.
  6. The TDM switch recognizes from the cause code 34 that it should route advance to the next trunk group in its local routing table to complete the call.

Invalid PASSporT use case

Steps 1–3 are same as above:

  1. If the PASSporT is invalid, STI-VS returns a SIP 603 message to the ISUP-SIP Gateway.
  2. ISUP-SIP Gateway returns a Call Release (REL) message, with cause code 21 (Call Reject) to the TDM switch.
  3. The TDM switch recognized cause code 21 and returns the REL message the originating service provider’s TDM switch and blocks the call.

SHAKEN for TDM call ladders

SHAKEN for TDM use case — PASSporT is valid

The following call ladder provides an example of SHAKEN verified call between TDM networks:

SHAKEN verified with TDM call ladder

SHAKEN verified with TDM call ladder

Call flow details:

  1. Call Setup to TDM Switch from Calling Party.
  2. TDM Switch sends IAM call setup to ISUP-SIP gateway.
  3. ISUP-SIP Gateway converts IAM to SIP INVITE sent to STI-AS.
  4. STI-AS uses the calling number, called number and time stamp to create SHAKEN PASSporT which is sent to the CPS of the terminating service provider via HTTPS.
  5. STI-AS returns a SIP 503 (Service Unavailable) message to the ISUP-SIP IWF device. Steps 4 and 5 occur simultaneously.
  6. The CPS verifies digital signature of the PASSport and, if valid, immediately forwards the PASSporT to the STI-VS of the terminating service provider.
  7. ISUP-SIP gateway device returns an ISUP REL message with cause code 34 (no circuit available) to the TDM switch.
  8. TDM switch route advances to the next route choice in its local routing table and sends and IAM call setup message the TDM switch that will transport the call to the terminating service provider serving the called number. In the call ladder above, the call is shown to interconnect directly to the TDM switch of the terminating service provider. However, a direct interconnect between source and destination switch is not required for OOB SHAKEN. OOB SHAKEN will work when there are multiple TDM switches between the originating and terminating service providers.
  9. When the call reaches the TDM switch of the terminating service provider, it is routed to the STI-VS via an IAM message to the ISUP-SIP Gateway.
  10. ISUP-SIP Gateway converts the IAM message to a SIP INVITE that is sent to the STI-VS.
  11. STI-VS finds a SHAKEN PASSporT received from the CPS that matches the calling number, called number and time stamp of the SIP INVITE to verify the call. STI-VS returns a SIP 503 message to the ISUP-SIP gateway.
  12. ISUP-SIP Gateway sends an ISUP REL message with cause code 34 (no circuit available) to the TDM switch.
  13. TDM switch route advances to the next route in its local routing table to complete the call to the Called Party.

SHAKEN for TDM use case — call is blocked

The following call flow ladder is an example of a SHAKEN enabled call, between TDM networks, that is blocked. Call blocking is not a requirement for SHAKEN for TDM, but is a local policy that can be enabled by the information provided by OOB SHAKEN. The terminating service may use the following reasons to determine that a call should be blocked.

  1. PASSporT is invalid. Verification of the digital signature using the public certificate fails.
  2. PASSporT cannot be validated because the certificate needed to validation cannot be retrieved from the Certificate Repository (STI-CR).
  3. No PASSporT is available from the CPS that matches the calling number, called number or time stamp of the SIP INVITE received at the STI-VS.
  4. The PASSporT is too old. Sixty seconds is the default lifetime of SHAKEN PASSporTs, but terminating service providers may expires SHAKEN PASSporTs sooner.
  5. Call Analytics, coupled with the STI-VS, may determine that the call should be blocked.

SHAKEN blocked with TDM call ladder

SHAKEN blocked with TDM call ladder

Call flow details:

1–10. The call flow details for steps 1-10 are identical to a call with a valid PASSporT, above.

  1. STI-VS determines the call should be blocked, based on one of the five reasons listed above, and returns a SIP 603 Decline message to the ISUP-SIP Gateway.
  2. ISUP-SIP Gateway sends an ISUP REL message with cause code 21 (Call Rejected) to the TDM switch.
  3. The TDM switch blocks the call and sends an ISUP REL message with cause code 21 (Call Rejected) to the TDM switch of the originating service provider.
  4. The TDM switch sends a Call Release message to the Calling Party.

TransNexus STIR/SHAKEN solutions

We offer production-ready STIR/SHAKEN solutions in our ClearIP and NexOSS software products. These solutions are unique in their capabilities to combine complete STIR/SHAKEN services with flexible policy controls and a comprehensive portfolio of other services, including fraud prevention, least cost routing and much more.

Contact us today to explore how we can help you implement SHAKEN quickly and easily.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.

More on TransNexus.com

June 16, 2021

TransNexus at ITEXPO 2021

June 15, 2021

May 2021 STIR/SHAKEN statistics

June 11, 2021

Webinar recording — Preparing for SHAKEN in Canada

June 9, 2021

Robocall Mitigation Database filing statistics

June 7, 2021

U.S. — Canada cross-border SHAKEN

June 2, 2021

Webinar — TDM to SIP network transformation best practices

June 1, 2021

Webinar — Robocall mitigation filing essentials

May 26, 2021

Webinar — Preparing for SHAKEN in Canada

May 25, 2021

Press release — New Out-of-Band SHAKEN whitepaper available

May 13, 2021

FCC — Service providers must now diligently pursue SHAKEN certificates

May 11, 2021

STI Governance Authority changes effective date of new SPC token access policy

May 3, 2021

Out-of-Band SHAKEN goes to letter ballot

April 30, 2021

Webinar recording — Robocall mitigation filing essentials

April 26, 2021

Robocall mitigation certification filing begins

April 7, 2021

Canadian regulator postpones STIR/SHAKEN deadline

March 31, 2021

FCC STIR/SHAKEN deadline extension petitions denied or withdrawn

March 29, 2021

Robocall mitigation compliance strategy

March 26, 2021

Webinar recording — Prepare for the FCC robocall deadline

March 3, 2021

Why you might use a Centralized SHAKEN Server, and how

February 23, 2021

Webinar — What is STIR/SHAKEN, and how to comply

February 23, 2021

TransNexus works with DigiCert to provide SHAKEN certificates

February 17, 2021

ClearIP Out-of-Band SHAKEN enhancements

February 8, 2021

FCC to telcos—You cannot be dumb pipes for robocalls

February 4, 2021

U.S. SHAKEN Governance Authority issues year-end report for 2020

February 1, 2021

Webinar — TRACED Act compliance — everything you need to know

January 27, 2021

Service provider STI fee changes for 2021

January 18, 2021

Webinar recording — Complying with the TRACED Act made simple

January 15, 2021

FCC proposes rules on SHAKEN certificate revocation for noncompliance

January 4, 2021

FCC issues further restrictions on robocalls