This section describes the sequence of events involved when there is an
alarm on a CCS trunk with trunk alarm capability.
Figure 1. Fault condition (alarm) on a CCS trunk with trunk
alarm capability
![The graphic is a very simplified representation of the process described in detail in the next section.](./yesalarm.gif)
- If a signaling process has registered with the capability SL_SIGPROC_CAPABILITY_TRUNK_ALARM, Blueworx Voice Response assumes that the signaling process is able to handle alarms
(fault conditions).
- When a fault condition occurs on a trunk controlled by the signaling process
the notification is sent to the signaling daemon. Blueworx Voice Response sends the appropriate
response to the network to acknowledge the alarm signal. See Trunk alarms.
Note: In this example we use the Remote Alarm Indication
(RAI) alarm.
- The signaling daemon sends the SL_TRUNK_ALARM_REQ primitive
to the signaling process to inform it of the fault condition.
- The signaling process notes that a fault condition has occurred. The signaling
process is responsible for taking any protocol-specified actions.
- The signaling process sends the SL_TRUNK_ALARM_CNF primitive
back to the signaling daemon.
Note: If the signaling process fails
to send back a reply to the SL_TRUNK_ALARM_REQ primitive,
an error will be added to the Blueworx Voice Response error log. This is a programming error
in the signaling process.
- The signaling daemon sends the alarm to the Blueworx Voice Response system manager using
the SL_TRUNK_ALARM_IND primitive.
- The system manager logs an error.
When the fault condition clears, the same flow is used to report this to
the signaling process. In this case both the SL_TRUNK_ALARM_REQ and SL_TRUNK_ALARM_CNF primitives specify slAlarm equal to SL_ALARM_CLEAR.