STIR/SHAKEN Client Alarms, Traps and Logs

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

Alarms

The SBC generates an alarm 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

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 realm name associated with the server, the IP address or FQDN of the server, and a message indicating that the STI server has repeatedly not responded to requests.

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, the alarm is cleared (If still present) and the SBC sends a clear trap.

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.12)

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:".