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 info about our products and services

* 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

October 21, 2020

SHAKEN benefits for enterprise callers

October 19, 2020

PASSporTs used with STIR/SHAKEN

October 19, 2020

How to register with the STI Policy Administrator to authenticate calls with STIR/SHAKEN

October 14, 2020

Should US service providers file for the voluntary SHAKEN exemption?

October 14, 2020

International SHAKEN — how that might work

October 7, 2020

Best practices for call authentication – first proposal

October 5, 2020

Three requirements from the FCC SHAKEN orders that will apply to most U.S. providers

October 5, 2020

What changed in the final version of the FCC SHAKEN second order

September 30, 2020

FCC approves second order on SHAKEN

September 28, 2020

SHAKEN, robocall mitigation, or both?

September 22, 2020

Initial reactions to FCC Second Order on SHAKEN

September 16, 2020

Robocall mitigation program mandate

September 9, 2020

FCC issues further rules on SHAKEN and robocall blocking

September 2, 2020

Comments filed on FCC robocalling fourth FNPRM

August 26, 2020

Update to SHAKEN standard improves authentication of forwarded and diverted calls

August 24, 2020

Robocalls trending up again in the U.S.

June 29, 2020

FCC issues staff report on robocall blocking tools

June 25, 2020

Open source Call Placement Service advances SHAKEN call authentication for all

April 7, 2020

Who may authenticate calls for STIR/SHAKEN

April 1, 2020

FCC issues STIR/SHAKEN mandate

January 20, 2020

NTCA discusses barriers to SHAKEN faced by rural carriers

January 2, 2020

STIR/SHAKEN mandate signed into U. S. law

October 1, 2019

FCC filings calling for Out-of-Band STIR

August 15, 2019

ClearIP now supports Rich Call Data in STIR/SHAKEN

April 29, 2019

ClearIP now supports out-of-band STIR/SHAKEN