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

Global 3GPP Behaviors

Behavior when you set http-rest-type to 3GPP on a sti-server includes:

  • When a received INVITE has a PASSporT that is not a SHAKEN or DIV PASSporT, the SBC ignores them and passes them through to the subsequent INVITE.
  • When a received INVITE has a single PASSporT/Identity header with no ppt parameter, the SBC assumes it is a SHAKEN PASSporT and does not decode it.
  • When a received INVITE has a SHAKEN and/or DIV PASSporT in addition to other PASSporTs that are not SHAKEN or DIV, the SBC attempts to verify the SHAKEN and DIV PASSporT(s), ignoring the others.
  • When a received INVITE has multiple PASSporTs/Identity headers, and has no ppt parameter, the SBC performs a base64URL decode of each PASSporT to determine their PASSporT type.
  • If a received INVITE has multiple verstat parameters that are not the same value, the SBC uses the following priority order for selecting the verstat value:
    1. Verstat value from the “P-Asserted-Identity” header with TEL-URI
    2. Verstat value from the “P-Asserted-Identity” header with SIP-URI
    3. Verstat value from the “From” header
  • When configured for STIR/SHAKEN verification on the ingress interface and upon receiving an INVITE with a SHAKEN PASSporT and one or more DIV PASSporT(s), the SBC makes a SHAKEN and a DIV verification request to the STI-VS.

    When the STI-VS verifies PASSporTs, it sends the SBC a verstat response for the SHAKEN PASSporT and one or more verstat responses for the DIV PASSporT(s), referred to as verstatValue.

    • If any returned verstat values = “TN-Validation-Failed” then the SBC sets the outbound verstat in INVITE to “TN-Validation-Failed”.

      Note:

      The reason for this behavior is that that “TN-Validation-Failed” is a more severe error that “No-TN-Validation”, and if “TN-Validation-Failed” appears for any verstat response, the system uses that for the outgoing verstat value.
    • If any returned verstat value = “No-TN-Validation” then the SBC sets the outbound verstat in the egress INVITE to “No-TN-Validation”.
    • Under all other conditions, the received verstat values would be “TN-Validation-Passed”. In these cases, the SBC sets the outbound verstat in the egress INVITE to “TN-Validation-Passed” and:
      • Retains the existing SHAKEN PASSporT in the outgoing INVITE
      • Retains the existing DIV PASSporT(s) in the outgoing INVITE
  • When configured for STIR/SHAKEN verification on the ingress interface, and the received INVITE has one or more DIV PASSporT(s) but no SHAKEN PASSporT, the SBC behaves the same as it does when it receives no PASSporTs. In this situation, the SBC:
    1. Increments the STI-VS with DIV PASSporT(s) counter.
    2. Does not send a DIV PASSporT verification request to the STI-VS.
    3. Sets outgoing verstat value to “No-TN-Validation”.
    4. Retains the existing DIV PASSporT(s) in the outgoing INVITE
    5. Includes the SIP REASON header with the code of 436 and the text “Bad Identity Info” in provisional and final responses it sends in the reverse direction.

      The reason for this behavior is that this is an error scenario. The SBC, therefore, sends this reason in the reverse direction regardless of the use-identity-header parameter setting.

CDR Behaviors

The SBC uses information specific to STIR/SHAKE traffic and results to populate CDR fields, including:

  • Stir-TN-Used-For-AS-VS-Request—During verification procedures, the SBC captures the TN number within the Stir-TN-Used-For-AS-VS-Request CDR field. the SBC uses for STIR-AS/STIR-VS, as a CDR attribute for STIR/SKAKEN only. The SBC uses the following priority order for selecting the TN it uses in the CDRs:
    1. From the Tel PAI, if present
    2. From the SIP PAI, if present and Tel PAI is not present
    3. From the “From” header if both Tel and SIP PAI are not present.
  • Stir-Div-Signed-Request—After the SBC receives a 200 OK to a DIV signing request from the STIR-AS, the SBC populates this CDR field with:
    • 0, indicating the STIR-AS is not signed
    • 1, indicating the STIR-AS is signed
    • 2, indicating signing is not applicable
  • Stir-Div-Verified-Request—After the SBC receives a 200 OK to a DIV verification request from the STIR-VS, the SBC populates this CDR field with:
    • 0, indicating the STIR-VS did not verify the DIV
    • 1, indicating the STIR-VS verified the DIV
    • 2, indicating verification is not applicable

The SBC inserts these fields within START, INTERIM and STOP CDR records for STI-VS requests, and within INTERIM and STOP CDR records for STI-AS requests. When you configure the generate-start parameter to OK in the account-config, the SBC generates CDRs that also include the STI-AS fields for START events.