Stir-VS-Verstat Attribute

This compliance feature enhances the behavior for populating the Stir-VS-Verstat attribute based on STI-VS HTTP responses. These behaviors apply to RADIUS, DIAMETER and CSV CDR deployments, and are applicable to both ATIS and 3GPP SHAKEN passports.

Based on STI-VS HTTP response, the SBC populates the "Stir-VS-Verstat" field as follows:

• Use the full string returned by the STI-VS, including No-TN-Validation, TN-Validation-Passed, TN-Validation-Failed, or anything custom up to 30 bytes
• If there is no verstat returned by STI-VS (whatever the reason: timeout, unavailable, missing body, etc.), leave the Stir-VS-Verstat empty
• If there is no request sent to the STI-VS, leave the Sti-VS-Verstat empty

Stir-VS-Reason Attribute

This compliance feature enhances the behavior for populating the Stir-VS-Reason attribute based on STI-VS HTTP Responses. These behaviors apply to both RADIUS, DIAMETER and CSV CDR deployments, and are applicable to both ATIS and 3GPP SHAKEN passports.

Based on STI-VS HTTP response, the SBC populates the "Stir-VS-Reason" field as follows:

• If the HTTP response status is 200 OK, the SBC:
  • Populates the "Sti-VS-Reason" field with the concatenation of the "reasoncode" and "reasontext" obtained from the JSON body.
  • If there is no reason returned within the JSON body, sets the "Sti-VS-Reason" field to be empty.
• If the HTTP response status is 4xx/5xx, the SBC:
  • ATIS—If the HTTP response status falls within the 4xx or 5xx range (client or server errors), populates the "Sti-VS-Reason" field with the HTTP response code and its associated response phrase.
  • 3GPP—If the HTTP response status falls within the 4xx or 5xx range (client or server errors), populates the "Sti-VS-Reason" field with the HTTP response code and its associated response phrase.
• No Answer from STI-VS—If there is no response received from the STI-VS service, sets the "Sti-VS-Reason" field to be empty.
• No Request to STI-VS—If no request has been made to the STI-VS service, meaning there was no interaction with the service, sets the "Sti-VS-Reason" field to be empty.

Enhancement for the Stir-Verified-Request-Exception-Id and Stir-Signed-Request-Exception-Id Attributes

The Case list and Exception table for these attributes are the same, with equivalent functions using either service (SVC) or policy (POL) exceptions. These behaviors are applicable to both ATIS and 3GPP deployments and are applicable to RADIUS, Diameter and CSV CDRs.

When the SBC fails to verify a request, the system populates the "Stir-Verified-Request-Exception-Id" and "Stir-Signed-Request-Exception-Id" attributes with the SVC or POL Exception IDs that are hard coded values mapped to each case. Based on event case, the SBC:

• For 4xx/5xx responses returned by STI-VS, populate with "SVC" or "POL" exceptions
• In case of a timeout, populate with "sti server timeout"
• When the STI-VS response is meaningless (JSON missing or malformed), populate with "invalid sti response"
• If the SBC does not send the request because the Identity header is missing or empty, populate with "Identity missing"

  Note:

  The case where the SBC does not send the request because the Identity header is missing or empty does not apply to the "Stir-Signed-Request-Exception-Id" attribute.
• If the SBC doesn't send the request due to the absence of a valid caller TN (From or PAI), populate with "TN missing"
• If the SBC refrains from sending the request due to STI admission control constraints, such as max-burst-rate, max-sustain-rate, burst-rate-window, or sustain-rate-window exceeded, populate with "sti constraints exceeded"

  Note:

  If no server is available from the sti-server-group, the system checks the STI admission control constraints of the last selected STI server.
• When the SBC is unable to send the request to the STI server (e.g., due to overloaded SIPD threads or overloaded CURLD), populate the field with "internal client error"
• If the SBC cannot send the request because the STI server is unreachable (circuit-breaker = open): populate with "sti server unreachable"
  • If no server in a sti-server-group is available, the system checks for the server unreachable status of the last selected STI server, and marks the CDR with the exception ID mapped to "sti server unreachable"
  • If you configured the server with an FQDN and the DNS IP list is empty, the system marks the CDR with the exception ID mapped to "sti server unreachable"
  • If the server is in Half Open State, the system does not send a request for that server. For this case also, the system marks the CDR with the exception ID mapped to "sti server unreachable"

The following table maps exception ID information based on the reason for the exception.

Additional AS case considerations, when configured to 3GPP mode, include:

• Both SHAKEN and DIV servers are running and sending the invalid response.

  In this case, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4502, which signifies an “invalid sti response”

• When the SHAKEN server is up and the DIV server is down:
  • If the response received from the SHAKEN server is invalid response, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4502, which signifies an “invalid sti response”
  • If the response received from the SHAKEN server is valid, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4504, which signifies a “sti server timeout”
• When the SHAKEN server is down and the DIV server is up:
  • If the response from the DIV server is invalid, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4502, which signifies an “invalid sti response”
  • If the response from the DIV server is valid, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4504, which signifies a “sti server timeout”
• When both the SHAKEN and DIV servers are down, the system fills the "Stir-Signed-Request-Exception-Id” CDR field with SVC4504, which signifies a “sti server timeout”