Per Call Availability of STI Servers

In addition to circuit breakers, which prevent the SBC from continually trying to communicate with a non-responsive server, you can configure maximum retries and SIP transaction timeout responses that determine how the SBC behaves with individual calls when there are problems reaching STI servers. This feature is applicable for both authentication as well as verification.

STI Servers can become unreachable due to connection issues and problems, meaning they may not respond or generate timeouts. The SBC includes processes for determining how to handle unresponsive servers on an ongoing basis as well as during a call.

With respect to the ongoing process, the system does not attempt to access any server with a circuit breaker in the Open state.
During a call, the SBC creates a server list and attempts to access servers in that list based on either your sti-server or sti-server-group configuration. Having generated a list of servers for a call, the SBC iterates through the list each time an attempt to reach a server times out. This process, which you enable by setting a max-retry-attempts parameter to a non-zero value, is used if a request sent to a STIR server does not get a response or the response times out. If the system does not send the request itself successfully, the system does not perform any retry.

When a call triggers a sti-server-group or a single server configured with an FQDN, and you have configured the max-retry-attempts parameter in the sti-config, the SBC adds your number of retries to its criteria for accessing servers. Failure to reach a server after reaching the max-retry-attempts is one of the reasons the system may determine that the STIR/SHAKEN infrastructure is not able to authenticate or verify that call.

A sti-server-group is basically a list of sti-servers. Whether you have configured a stir-server with an IP address or an FQDN, the system cycles through the server list established by those configurations:

When all servers in the group use an IP address, the system cycles though servers using the group's strategy.
When all servers in the group use an FQDN, the system creates a list using the strategy and cycles through each resolved address using round robin before proceeding with the original list.
When cycling through a sti-server-group that has both addresses and FQDNs, the system cycles through the group list using your configured strategy, and cycles through all resolved addresses using round-robin when it reaches an FQDN in the group list.

For a single server configured with an FQDN, the system cycles through all resolved addresses using round-robin.

You consider each server's timeout value in conjunction with your max-retry-attempts value when applying this feature to your environment. Each server's timeout value determines when the system tries the next server in the list for individual calls. The max-retry-attempts defines the total number of servers the system attempts to reach for a call.

As a simple calculation for determining retry count, consider that a standard SIP transaction timeout is 32 seconds and you have configured the timeout for the applicable sti-server to its minimum of 100 milliseconds. This results in 10 retries in 1 second, and 30 retries in 3 seconds. Applicable values for max-retry-attempts are zero, which disables this feature, to 30, which would accommodate the scenario above.

Ultimately, the SBC stops trying to access servers recursively for this call when:

The SIP transaction timeout expires.
The system reaches your max-retry-attempts value.
The system has tried to reach all the servers in the applicable sti-server-group.
This remains true even if the SIP transaction timeout has not expired and the process has not reached your max-retry-attempts count.

The action the system takes after it stops trying to access servers depends on the reason for stopping:

For verification processes, when process reaches your max-retry-attempts count, the system proceeds with the call without verification, adding the “verstat=No-TN-Validation” parameter and continuing with the SIP transaction.
If the SIP transaction has timed out, SIP logic ends the call. The system performs these processes for each call, regardless of whether a previous call was not able to reach the STI server.

The SBC honors standard SIP operation and any other configuration you establish at any point within these recursions:

If you have configured any of your stir-servers with verstat=No-TValidation-Timeout in its sti-response-treatment-entry and that server times out, the system rejects the call without any further retries.
The SBC stops recursion if any server responds with a failure or exception. These responses are considered valid, ending the retry logic.
The system rejects calls if the results of the overall call process meets the criteria for rejection.
The max-retry-attempts feature interacts with the sti-response-treatment-config feature:
- If max-retry-attempts = 0 (recursion disabled), then call rejection shall apply as soon as sti-vs answer
- If max-retry-attempts > 0 (recursion enabled), then call rejection shall apply based on the verstat value configured for call rejection for each server. If you have configured any stir-server with verstat=No-TN-Validation-Timeout in the sti-response-treatment-entry and a timeout occurs for that server, the SBC rejects the call and does not make any further retry attempts.
- If you have not configured any applicable stir-server with verstat = No-TN-Validation-Timeout in sti-response-treatment-entry, the SBC retries all the servers until it reaches either the max-retry-attempt count or a SIP transaction timeout occurs.
- If you have configured the server with a sti-response-treatment-entry that has a verstat value other than No-TN-Validation-Timeout, and max-retry-attempts is greater than 0, the system applies call rejection logic based on the last attempted server that responds.

Consider the following example, wherein you have two servers configured in a sti-server-group using the round robin strategy. In addition, you have configured your max-retry-attempts to 2. These servers include:

server1 – stirDemo1.tryfqdn.com:9001, resolving to two addresses, 10.199.240.155 and 10.198.240.157
server2 – stirDemo2.tryfqdn.com:9002, resolving to two addresses, 10.146.134.180 and 10.196.136.185

Note:

Each Curl POST request includes the following:

"{"verificationRequest":{"identity":"..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj","time":1672646120,"to":{"tn":["1a23"]},"from":{"tn":"123"}}}"

The process proceeds with the SBC performing the following steps:

Resolves the FQDN for server1 and selects 10.199.240.155 using round robin on the DNS resolutions.
Sets its retry count to zero.
POSTs a Curl POST request to server1, address 10.199.240.155:
Times out this request, having not received a response from 10.199.240.155.
Initiates its first retry by selecting 10.198.240.157 from the list of untried IPs for server1.
Sets its retry count to one.
POSTs a Curl POST request to server1, address 10.199.240.157.
Times out this request, having not received a response from 10.199.240.157.
Resolves the FQDN for server2 and selects 10.146.134.180 using round robin on the DNS resolutions.
Initiates its second retry by selecting 10.146.134.180 from the list of untried IPs for server2.
Sets its retry count to two.
POSTs a Curl POST request to server2, address 10.146.134.180.
Times out this request, having not received a response from 10.146.134.180.
Terminates the retry process. The max-retry-attempt is now equal to the retry count.
Continues with the SIP Transaction.

Reporting

This feature affects the show stir command output by including the retries made to a server in its query count. When examining this output, you need to consider these retries:

If you are not using this feature, you can expect one SIP INVITE to generate a single query to the STI servers.
If you are using this feature and have set max-retry-attempts to three, an unsuccessful attempt to reach a single server would record four queries (1 request + 3 retries).

Applicable commands include:

show stir stats
show stir agents all
show stir agents <identifier>
show stir interface all
show stir interface <identifier>
show stir realm all
show stir realm <identifier>
show stir all

With respect to this feature, the system does not include a specific field for displaying retry count. Instead, you can derive retries from the commands above by referring to the STI-AS and STI-VS Queries, Success Responses, and Unsuccessful Responses rows. As such, the number of STI-AS or STI-VS queries is based on the total number of Retry to sti-servers and the number of response counts, accordingly.