1. Configuration Guide
  2. STIR/SHAKEN Client
  3. Changing the Precedence for Handling orig and verstat Values

Changing the Precedence for Handling orig and verstat Values

By default, the SBC uses incoming PAI headers as a vehicle to retrieve information, create an orig value and to convey verstat values. If PAI headers are not present or sufficient, the system uses incoming FROM headers for these purposes. Some regions, however, require that the FROM header be the first source of this information. To accommodate these deployments, you can configure the SBC to use the FROM as the primary caller id source for information used to determine a SHAKEN orig claim and the verstat value. This behavior is applicable to both ATIS and 3GPP based implementations.

The SBC refers to the URIs in PAI and FROM headers for the presence of telephone numbers (TNs) as identifying information during authentication and verification procedures:

  • To support authentication, when the SBC receives an out-of-dialog INVITE with no identification header or verstat value, it searches for an appropriate TN in the request and, if it finds one, creates an 'orig' key and initiates a signing request.
  • To support verification procedures, meaning the initial request did have an identity header, the SBC :
    • Searches for an appropriate TN in the request and, if it finds one, creates an 'orig' key and initiates a verification request.
    • Obtains verification and populates the header from which it selects TNs with verstat values indicating verification success or failure.

The presence of multiple TNs as well as URIs that are not TNs in the initial request adds some complexity with respect to the use of the information and the population of the verstat result. In addition to changing the preferred source of TNs, this feature also results in the TN URI and SIP URI parsing and selection behaviors covered below.

You can enable this functionality on a global basis using the flip-tn-lookup-order parameter within the sti-config. The default is disabled. 

ORACLE(sti-config)#flip-tn-lookup-order enabled

If preferred, you can enable this functionality on a per-server basis by enabling the flip-tn-lookup-order value as an option within the sti-server. 

ORACLE(sti-server)#options +flip-tn-lookup-order=enabled

The sti-server option setting, when enabled, takes precedence over the global configuration. This allows you to, for example, use the default behavior across the device, while preferring the FROM header for the STI servers that you configure with the option.

When enabled, the SBC changes behaviors to the following:

  • Prioritizes the selection of URIs in FROM headers to populate the “orig” shaken passport claim.
  • Prioritizes the selection of URIs in FROM headers for population of the “verstat” received from Verification Server.
  • Applies precedence to any sti-server option setting over the global setting.

When you enable the feature, detailed SBC authentication behavior includes checking the URI in the FROM and PAI headers for the presence of a TNs and creating an orig key using that TN. Regardless of the TN selection, the SBC always performs the signing request, and continues to process the call:

  • If a TN is present in the FROM, the SBC uses that TN to create the "orig" key.
  • If there is no TN in the FROM, and there is a tel PAI, the SBC uses the tel PAI to create the "orig" key.
  • If there is no TN in the FROM, there is no tel PAI and there is a SIP PAI, the SBC uses the SIP PAI to create the "orig" key.
  • If there is no TN in any header, the SBC does not send a validation request to the STI servers and sets the verstat to No-TN-Validation in the FROM and PAI headers.

Detailed SBC verification behavior also begins with checks for the presence of TNs. Regardless of the TN selection, the SBC performs the same procedure for selecting a TN and creating an "orig" key it performs for authentication, initiates the verification request, and continues processing the call. Results of the TN check includes:

  • If there is a TN in the FROM, the SBC applies the verstat to the FROM header.
  • If there is a TN in the FROM, and there is a PAI header with a TN (either SIP or Tel PAI), where the values of the TNs match, the SBC adds the verstat parameter to both the From and PAI headers.
  • If there is not a TN in the From, and there is a PAI header with a TN (either SIP or Tel PAI), the SBC adds the verstat parameter to the PAI header.

Additional verstat population behavior when there are multiple PAI headers includes:

  • If there is a TN in the From, and two PAI headers:
    • Tel URI and SIP URI with matching TNs, the system adds the verstat to all headers.
    • One PAI matches and the other does not, the system adds the verstat to the From and the matching PAI.
    • Neither PAI has a TN, the system adds the verstat to the From only.
  • If there is not a TN in the From, but there are Tel and SIP PAIs that have TNs, the system adds the verstat to the Tel PAI.

    The system also compares the Tel PAI TN with the SIP PAI. If the TNs match, the system also adds the verstat to the SIP PAI.

  • If there is a From Header with no TN, and the PAI headers also have no TNs, the system adds the verstat to all headers.