1. Configuration Guide
  2. STIR/SHAKEN Client
  3. STIR/SHAKEN Client Alarms, Traps and Logs

STIR/SHAKEN Client Alarms, Traps and Logs

The SBC provides for standard tools to evaluate, track and troubleshoot client operations.

Alarms

The SBC generates alarms for STI server connection failure and failed REST responses. The SBC raises the trap when the circuit-breaker trips and clears it when the circuit-breaker closes again. Examples of events that would trigger the alarm include:

  • Invalid credentials with STI-AS or STI-VS
  • Cannot resolve host
  • REST API response time out
  • Internal REST API query time-out

This alarm name is STIR SERVER UNREACHABLE, generated by the system using a dynamic alarm ID. An example of this alarm is shown below.

ORACLE# display-alarms
1 alarms to show
ID      Task    Severity        First Occurred          Last Occurred
4114305 2759    1           2020-10-01 01:02:03     2020-10-01 01:02:03
Count   Description
1	STIR Server 'stirTest1' connection timeout

Note:

The SBC sends a corresponding SNMP trap in addition to the alarm when the circuit breaker trips, which happens whenever the server does not reply, and for whatever reason.

You configure the sti-config with the circuit-breaker settings from which the SBC determines the status of servers, including when it is unavailable. When unavailable, the SBC raises this alarm and issues the trap. When raised, the alarm contains the IP address or FQDN of the server within a message indicating the issue with the STI and a count number for each time the server has experienced that issue, such as a connection timeout.

When a server goes out of service, the SBC sends the retry requests to verify whether or not the server is back in service. When the server responds, the SBC clears the alarm and issues the clear trap, indicating the condition cleared. You can also clear the alarm manually with the clear-alarm command.

The system alarms and SNMP traps are tied together and the SBC raises them at the same time. Whenever the SBC processes a new STIR-enabled call, if the resulting state of the circuit breaker changes, it triggers a new alarm or clears it. This is not executed for every call, but for every circuit breaker status change. So, if an alarm is cleared manually via ACLI or GUI, but the circuit breaker is still in ‘open’ state, the SBC does not raise any new alarms for this sti-server. The SBC can only raise a new alarm for an sti-server when the circuit breaker closes.

Major and Minor Alarms

When configured to a single IP address, the system raises a major alarm any time it finds that address unavailable.

If you have configured a server with an FQDN, resulting in multiple server resolutions, the system creates a circuit breaker for each server. When there are multiple server resolutions, the SBC implements a major/minor alarm distinction based on the availability of backup servers.

The system generates a major alarm:

  • When there is only one address associates with the server, due to a single FQDN resolution, and that address has its circuit-breaker go into the Open state
  • When the last available address out of multiple FQDN resolutions has its circuit breaker go into the Open state

The system generates a minor alarm:

  • When one of the IP addresses out of multiple FQDN resolutions has its circuit breaker go into the Open state, but there is at least one IP address in the resolution list that still has a circuit breaker in the Close state

Both the alarm and SNMP trap follow these rules.

SNMP Traps

In the event of repeated sequential REST STI server response timeouts the SBC generates an SNMP trap containing the same information as the associated alarm. These objects include:

  • apStirServerUnreachableTrap (1.3.6.1.4.1.9148.3.16.2.2.5.0.1 )
  • apStirServerUnreachableClearTrap (1.3.6.1.4.1.9148.3.16.2.2.5.0.2)

SNMP traps and alarms are generated by the same system processes. You can disrupt this synchronization if you make manual changes to these objects during operation.

Note:

The SBC does not send an SNMP clear if you close the alarm manually. In this state, the SBC cannot raise a STIR server trap again, despite new alarms, without you rebooting the system. Exercise great care when clearing alarms manually.

Applicable Logs

The SBC logs operational functions performed for the STIR/SHAKEN client to the sipd log. You can find these log entries using the following tips:

  • Set the sipd log level to debug, and search for lines containing 'STIR', or 'STIR:' for SPL Logic.
  • Logs starting with "[SPL]" originate from SPL scripts,
  • Logs from STIR scripts contain the prefix "STIR:".