Bypass STI-AS Signature and STI-VS Verification Requests

You can configure the SBC to bypass STI-AS signature requests or STI-VS verification requests for specific scenarios and when specific headers are present in incoming INVITEs.

To bypass specific headers, you set the following parameters within the sti-config element:

• stivs-bypass-header: Specify a SIP header name. The SBC detects SIP INVITEs with that header that are subject to STI-VS verification, and bypasses the entire verification process, instead adding "verstat=No-TN-Validation" and forwarding the egress INVITE.
• stias-bypass-header: Specify a SIP header name. The SBC detects SIP INVITEs with that header that are subject to STI-AS authentication and bypasses the authentication process.

In ATIS deployments, you can bypass scenarios beyond simple headers by setting the following parameters within the sti-config element:

• sti-bypass-token-scenarios: Specify a list of scenario names, separated by a space, for which to bypass STI-AS signature requests. The SBC detects SIP INVITEs that meet the conditions of any of the listed scenarios, bypasses the authentication process, and adds the token configured in sti-static-bypass-token in the P-Identity-Bypass header of the egress INVITE.
  The following scenarios are supported:

  • sti-error-response: For 4xx or 5xx responses, the STI-AS returns SVC or POL.
  • sti-server-timeout: Timeout scenarios.
  • invalid-sti-response: The STI-AS response is meaningless, made up of missing or malformed JSON.
  • tn-missing: The SBC is not sending the request because the TN is missing
  • sti-constraints-exceeded: The SBC is not sending the request because a STI admission control constraint (max-burst-rate, max-sustain-rate, burst-rate-window, sustain-rate-window) has been reached.
  • sti-server-unreachable: The SBC is not sending the request because the STI server is unreachable (the circuit-breaker status is OPEN). In the case of retries, no more STI servers are available.
  • internal-client-error: The SBC fails to send the request because of internal errors, such as overloaded sipd or curld threads.
  • sti-server-bypass: STI-AS is bypassed because the incoming INVITE contains a bypass header.

    Note:

    If stias-bypass-header is also set to P-Identity-Bypass and an ingress INVITE contains the P-Identity-Bypass header, the SBC bypasses the authentication process without adding any new P-Identity-Bypass headers to the egress INVITE.
  • sti-server-disabled: The STI server's state is set to disabled.
  • sti-signaling-attest-info-mandatory: The sti-signaling-attest-info-mandatory parameter is enabled, and the P-Attestation-Info or Attestation-Info header is missing in the incoming INVITE.

  You can only create one sti-bypass-token-scenarios list, to be used globally across the SBC.

• sti-static-bypass-token: Specify a default STI token to use when bypassing. When a call meets the conditions configured in sti-bypass-token-scenarios, the SBC adds this token to the P-Identity-Bypass header of the egress INVITE.

  Note:

  If the ingress INVITE contains the P-Identity-Bypass header, the SBC does not modify it or add a new P-Identity-Bypass header in the egress INVITE, even if you specify a bypass token in this parameter. The SBC relays the received P-Identity-Bypass header in the egress INVITE rather than your configured default token. It does not increment the STI-AS sent INVITEs with bypass token statistic, and the Stir-AS-Bypass-Token CDR field will be empty.

The system tracks and reports on bypassed STIR requests using server, system, STIR realm, session agent and sip interface statistics with the labels "STI-AS ByPass" and "STI-VS ByPass".

Note:

When you configure these parameters, the bypass scenario takes precedence over "TN missing" and "Identity missing" scenarios.