1. Configuration Guide
  2. STIR/SHAKEN Client
  3. HTTP Client Operating Modes
  4. Number Authentication Mechanism Standards Compliance Features
  5. CDR Behavior Changes

CDR Behavior Changes

As with the other behaviors associated with Number Authentication Mechanism 2.0 operations standards, you enable the man-compliance option and the reason-json-sip-translation parameter in the sti-config of your SBC configuration to enable this functionality. The changes implemented by this configuration apply to CDRs delivered within both RADIUS and DIAMETER deployments.

The CDR-related behavioral changes implemented by this compliance option are addressed individually below.

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 both RADIUS and DIAMETER 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:

  • If the STI-VS returns a Full string: 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.), Stir-VS-Verstat is left empty
  • If there is no request to the STI-VS, Sti-VS-Verstat is left 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 and DIAMETER 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 empty.
  • If the HTTP response status is 4xx/5xx, the SBC:
    • For 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.
    • For 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. These behaviors are applicable to both ATIS and 3GPP deployments.

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

  • For 4xx/5xx responses returned by STI-VS, populate with "SVC" or "POL"
  • 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 doesn't send the request due to the Identity header being missing or empty, populate with "Identity missing"
  • If the SBC doesn't send the request due to the absence of a valid TN (Telephone Number), populate with "TN missing"
  • If the SBC doesn't send the request due to STI admission control constraints (e.g., max-burst-rate, max-sustain-rate, burst-rate-window, or sustain-rate-window exceeded), populate with "sti constraints exceeded"
  • If the SBC cannot send the request due to STI server being unreachable (circuit-breaker = open), populate with "sti server unreachable"
  • 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"

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

Exception Reason Exception ID Exception Text Note
If SBC is not sending the request due to Identity header missing or empty SVC4501

"Identity missing"

 Input is missing hence this is case of service exception
If STI-VS answer is meaningless (JSON missing or malformed) SVC4502 “invalid sti response” Invalid response, hence this is case of service exception
timeout SVC4504 “sti server timeout” Timeout is service exception
If SBC not sending the request due to no valid TN SVC4505 "TN missing" Input missing is case of service exception
If SBC failing to send the request to sti server (e.g. sipd threads overloaded or curld overloaded) POL5500 "internal client error" The request failed due to internal error is policy exception
If SBC not sending the request due to sti-server unreachable (circuit-breaker = open) POL5503 "sti server unreachable" sti-server unreachable is policy exception
If SBC not sending the request due to sti admission control (max-burst-rate or max-sustain-rate or burst-rate-window or sustain-rate-window reached) POL5506 "sti constraints exceeded" Constraint exceeded is policy exception

Note:

The case wherein the SBC is not sending the request due to Identity header missing or empty does not apply to the "Stir-Signed-Request-Exception-Id" attribute.