1. Configuration Guide
  2. STIR/SHAKEN Client
  3. HTTP Client Operating Modes
  4. Operating Under the 3GPP Mode
  5. 3GPP Behaviors Related to Configuration

3GPP Behaviors Related to Configuration

The SBC includes configuration parameters that apply to 3GPP STIR/SHAKEN operation only. Your settings for these parameters generate important behaviors to consider.

The scenarios below assume you have configured the SBC for STIR/SHAKEN authentication on the egress interface or for verification on the ingress interface. In addition, you must have set the associated STI-AS or STI-VS server's http-rest-type to 3GPP.

Behaviors Based on verstat-comparison Configuration

You can set the verstat-comparison parameter, within the sti-config, to TN-Validation-Passed (default), empty, No-TN-Validation or TN-Validation-Failed. The verstat-comparison parameter accepts a single or multiple values:

  • When the received INVITE has a SHAKEN PASSporT, a DIV PASSporT, and the verstat-comparison value is empty, the SBC:
    1. Does a base64URL decode of the last (outermost) DIV PASSporT. If this decode fails, the SBC does not perform any SHAKEN or DIV authentication, instead passing the existing passport to the egress INVITE. If this decode succeeds, the SBC proceeds to step 2.
    2. Checks to see that the {dest} value from the last DIV PASSporT is NOT equal to the Request-URI TN value
    3. If so, the SBC:
      1. Makes div authentication request to the STI-AS
      2. Adds div PASSporT to the outgoing INVITE as a SIP Identity header
      3. Passes the existing DIV PASSporT(s) to the outgoing INVITE
      4. Passes the existing SHAKEN PASSporT to the outgoing INVITE
  • Consider the scenario above, changing it such that the {dest} value from the last DIV PASSporT is equal to the Request-URI TN value. In this case, the SBC:
    1. Passes the existing DIV PASSporT(s) to the outgoing INVITE
    2. Passes the existing SHAKEN PASSporT to the outgoing INVITE

    The SBC recognizes that no diversion has occurred.

  • When configured for STIR/SHAKEN authentication on the egress interface, the received INVITE has SHAKEN and DIV PASSporTs, and the verstat-comparison value is not empty, the SBC:
    1. Does a base64URL decode of the received div PASSporT
    2. Determines the last (outermost) div PASSporT.
    3. Checks to see that:
      • The {dest} value from the last div PASSporT is not equal to the Request-URI TN value, and
      • The verstat value from the received INVITE does matches a value from verstat-comparison
    4. If so, the SBC:
      1. Makes DIV authentication request to the STI-AS
      2. Adds the DIV PASSporT to the outgoing INVITE as a SIP Identity header
      3. Passes the existing DIV PASSporT(s) to the outgoing INVITE
      4. Passes the existing SHAKEN PASSporT to the outgoing INVITE
  • Consider the scenario above, changing it such that the verstat value from the received INVITE does NOT match a value from verstat-comparison. In this case, the SBC:
    1. Passes the existing DIV PASSporT(s) to the outgoing INVITE
    2. Passes the existing SHAKEN PASSporT to the outgoing INVITE

    In this case, the SBC recognizes that a diversion has occurred.

  • When the received INVITE has a SHAKEN PASSporT, no DIV PASSporT, and the verstat-comparison value is not empty, the SBC checks to see that:
    • The {dest} value from the SHAKEN PASSporT is not equal to the dest-comparison AND
    • The verstat value from the received INVITE matches a value from verstat-comparison. If so, the SBC:
    1. Makes DIV authentication request to the STI-AS
    2. Adds DIV PASSporT to the outgoing INVITE as a SIP Identity header
    3. Passes the existing SHAKEN PASSporT to the outgoing INVITE
  • Consider the scenario above, changing it such that the verstat value in the received INVITE does NOT match a value in the verstat-comparison. In this case the SBC passes the existing SHAKEN PASSporT to the outgoing INVITE. In addition, the SBC does not perform DIV authentication.
  • When the received INVITE has a SHAKEN PASSporT, no DIV PASSporT, and the verstat-comparison value is empty, the SBC:
    1. Does a base64URL decode of the SHAKEN PASSporT. If this decode fails, the SBC does not perform any SHAKEN or DIV authentication, instead passing the existing passport to the egress INVITE. If this decode succeeds, the SBC proceeds to step 2.
    2. Checks to see that the {dest} value from the SHAKEN PASSporT is NOT equal to the dest-comparison value.
    3. If so, the SBC:
      1. Makes DIV authentication request to the STI-AS
      2. Adds DIV PASSporT to the outgoing INVITE as a SIP Identity header
      3. Passes the existing SHAKEN PASSporT to the outgoing INVITE
  • Consider the scenario above, changing it such that the {dest} value from the SHAKEN PASSporT is or is not equal to the dest-comparison value. In this case, the SBC passes the existing SHAKEN PASSporT to the outgoing INVITE.

    The SBC recognizes that no diversion has occurred. In addition, the SBC does not perform DIV authentication.

Behaviors Based on dest-comparison Configuration

When presented with a received INVITE that has a SHAKEN PASSporT, but does not have DIV PASSporT, and the verstat-comparison value is empty, the SBC:

  1. Does a base64URL decode of the received SHAKEN PASSporT
  2. Checks to see that the {dest} value from the last SHAKEN PASSporT is not equal to the dest-comparison. If not, the SBC:
    • If the {dest} value is not the same as the dest-comparison, the SBC:
      1. Makes a DIV authentication request to the STI-AS
      2. Adds the DIV PASSporT to the outgoing INVITE as a SIP Identity header
      3. Passes the existing SHAKEN PASSporT to the outgoing INVITE
    • If the {dest} value is the same as the dest-comparison, the SBC passes the existing SHAKEN PASSporT to the outgoing INVITE

Behaviors Based on tn-retargeting Configuration

You can set the tn-retargeting parameter to enabled (default) or disabled.

  • When the egress interface is configured for STIR/SHAKEN authentication, the received INVITE does not have a SHAKEN PASSporT, and you have set the tn-retargeting parameter set to:
    • disabled—The SBC performs SHAKEN PASSporT authentication by sending a SHAKEN authentication request to the STI-AS. Additionally, after receiving a successful response, the SBC adds the SHAKEN PASSporT to the outgoing INVITE as a SIP Identity header
    • enabled—The SBC checks to see if “To” header TN value is not the same as the Request-URI TN value.
      • If so, the SBC makes separate SHAKEN and DIV authentication requests to the STI-AS. Additionally, the SBC adds both the SHAKEN and DIV PASSporTs to the outgoing INVITE as two separate SIP Identity headers in the outgoing INVITE.
      • If the values are the same, the SBC only makes a SHAKEN authentication request to the STI-AS. The system also add a SHAKEN PASSporT to the outgoing INVITE as a SIP Identity header in the outgoing INVITE.

Behaviors Based on check-duplicate-passports Configuration

You can enable or disable the check-duplicate-passports parameter.

  • When presented with a request that has multiple PASSporTs and you have enabled check-duplicate-passports, the SBC checks whether they are all the same. If so, the SBC removes the duplicate passports and handles the remaining passport normally.

    When presented with a request that has multiple PASSporTs and you have check-duplicate-passports is disabled, the SBC checks whether they are all the same. If so, the SBC does not perform STIR/SHAKEN verification, instead passing all the PASSporTs through, and sets the verstat to “No-TN-Validation” in the outgoing INVITE). In addition, the SBC includes a SIP REASON header with the code of 436 and the text “Bad Identity Info” in the reverse direction, in both provisional and final responses.

Behaviors Based on use-identity-header Configuration

When you enable use-identity-header, if the received INVITE doesn't contain an Identity header and the SBC is configured to perform STI verification, the system adds a Reason header and sends it in the reverse direction in 18x, 2xx as well as final responses (3xx, 4xx, 5xx, 6xx) to the originator with a cause value of “428” and the text “Use Identity Header”.

If a SIP Reason header is already present, the system appends the existing Reason header with the new data at the end after a semi-colon.