Alarmbridge Service - Calling Back & Provisioning

Modern alarm systems span both analogue and IP-based technologies, often coexisting within the same deployment. The Alarmbridge Service provides a unified interface to establish voice communication back to alarm units when an ARC operator needs to speak to a user, regardless of the underlying connectivity or protocol.

A key capability of Alarmbridge Service is callback handling—allowing an alarm receiving center or application to initiate a voice call back to an alarm device. This is used to follow up on previous alarm events and establish direct communication with the end user.

Alarmbridge Service supports both dispersed alarm units and group scheme alarm systems. Importantly, the callback procedure is consistent from an application perspective regardless of the device type or alarm protocol used by the device. The differences are handled internally by the service based on device provisioning and configuration.

The alarm receiving application can initiate a callback to a device using either a registered SIP connection or a phone number routed via a SIP trunk. Alarmbridge Service abstracts the underlying transport and signalling differences, ensuring a consistent calling model.

There are two primary categories of alarm endpoints:

• Dispersed alarm units
• Group scheme voice units (via a controller)

Dispersed alarm units

Dispersed alarm units are standalone devices with a direct mapping between the alarm event controllerId and the physical endpoint.

For these devices:

• The alarm receiving center initiates a call to the SIP URI or phone number of the dispersed alarm device
• For SIP-based devices, Alarmbridge Service resolves the device via the location service and routes the call accordingly
• For PSTN-connected devices, the call is placed via a SIP trunk toward the public telephone network

From the application perspective, the same addressing format is used regardless of whether the device is SIP-based or connected via PSTN.

Group scheme alarm units

Group scheme systems consist of a central controller managing multiple voice units. These are typically used in environments such as care facilities or multi-residence deployments.

For these systems:

• The alarm receiving center initiates a call to the SIP URI or phone number of the group scheme controller
• Once the call reaches the controller, Alarmbridge Service communicates with it using the protocol configured for that device (for example TT92 or NOW-IP)
• The signalling protocol of the device is used to select and connect to the specific voice unit associated with the alarm event with the calling party.

Although the call is addressed to the controller, the service ensures that the correct voice unit is reached regardless of whether the system is connected via direct SIP or via PSTN using a SIP trunk and signalling protocol.

Correct provisioning is essential for callback handling to work as expected.

When configuring devices in Alarmbridge Service:

• Each device must be assigned the appropriate deviceType to indicate its type.

The relevant device types are:

• Alarmbridge Alarm Unit (alarmbridgeAlarmUnit) Used for dispersed alarm units.

• Alarmbridge Group Scheme Controller (alarmbridgeGroupSchemeController) Used for group scheme controllers, whether connected via direct SIP registration or via PSTN using a SIP trunk.

• Alarmbridge Connect Gateway (alarmbridgeConnectGateway) Used for analogue group schemes connected via an Alarmbridge Connect Gateway device for PSTN service replacement.

• Alarmbridge Group Scheme Unit (alarmbridgeGroupSchemeUnit) Used for individual voice units behind a group scheme controller.

• For group scheme controllers, the signalling protocol must be specified in the serviceData object (for example TT92 or NOW-IP).

This configuration enables Alarmbridge Service to apply the correct routing and control logic during callback operations.

The relevant serviceData object property for defining the protocol used when calling into a group scheme voice unit is serviceData.alarmBridge.alarmProtocol, for example:

serviceData: {
  alarmBridge: {
    alarmProtocol: "tt92"
  }
}

• The deviceCLI property must be provisioned for group scheme controllers connected via the public telephone network and accessed through a SIP trunk. It must be set to the telephone number used to call the group scheme controller.

Before routing a callback via a SIP trunk, Alarmbridge Service resolves the destination number against provisioned alarmbridgeGroupSchemeController devices to determine which alarm protocol to use for voice unit selection.

If a service is set up to serve multiple customers, there is a risk that several customers may use the same controllerId in their deployments. To avoid identifier collisions, an optional customerSiteId property may be configured on an Alarmbridge event receiver.

Normally, the deviceId property in device provisioning matches the controllerId value sent in alarm events from a group scheme or dispersed alarm device.

When an event receiver is provisioned with customerSiteId, this value is prepended to the incoming identifier using colon-separated notation:

customerSiteId:controllerId

In this case, devices calling into that event receiver must be provisioned using the same composite identifier in their deviceId.

Example:

An event receiver is provisioned with:

customerSiteId: 1234

An alarm device sends:

controllerId: 9999

The corresponding provisioned device must use:

deviceId: 1234:9999

Group scheme unit device identities

Devices behind a group scheme controller must also be pre-provisioned using the same hierarchical identity model.

The controller identifier is used as a prefix for the voice unit identifier:

controllerId:voiceUnitId

Example:

Voice unit 123 behind controller 9999 is provisioned as:

9999:123

If the deployment also uses customerSiteId, the full provisioned identity becomes:

1234:9999:123

For devices behind a controller, the deviceType property should be set to:

alarmbridgeGroupSchemeUnit

Normally, a voice call is established from an alarm device to the alarm receiving center in conjunction with an alarm event. The device is provisioned with the address of the alarm receiving center, and the alarm protocol handles the logic required to establish the voice session.

Calling back to an alarm device refers to initiating a voice call from the alarm receiving center toward the alarm device. This is typically done when an operator needs to follow up on a previous alarm event or when a call has been disconnected.

Alarmbridge Service provides a consistent mechanism for callback handling regardless of the alarm protocol used by the device or whether the device uses SIP or analogue PSTN connectivity.

Calling a dispersed alarm device

Dispersed alarm devices contain a single voice unit and behave like standard telephony endpoints. When a call is received, the device rings and the user answers the call.

For SIP-based dispersed alarm devices:

• The device is registered with Alarmbridge Service using a SIP registration
• The alarm receiving center initiates a call to the SIP URI of the device

Example:

sip:alarmdevice12@customer.prod-eu-north-1.iotcomms.io

The service resolves the registration and connects the call to the device.

For analogue dispersed alarm devices:

• The device is reachable via the public telephone network
• The alarm receiving center initiates a call to a SIP URI that routes via a SIP trunk

Example:

sip:+46123456@customer.prod-eu-north-1.iotcomms.io

The call is routed via the SIP trunk to the PSTN-connected device.

Calling a voice unit behind a group scheme controller

Calling a voice unit behind a group scheme controller differs from calling a dispersed alarm device, as multiple voice units share a single SIP URI or phone number.

Once the group scheme controller answers the call, the configured alarm protocol is used to select the correct voice unit. Alarmbridge Service automates this process using the protocol defined in the controller’s serviceData.

For SIP-based group scheme controllers:

• The controller is registered with Alarmbridge Service via SIP
• The alarm receiving center initiates a call to the controller’s SIP URI
• Additional URI parameters specify which voice unit to connect

Required parameters:

• originatingProtocol — set to voicecall for standard ARC initiated calls
• deviceId — the provisioned deviceId of the target group scheme unit to connect

Example:

sip:groupschemecontroller14@customer.prod-eu-north-1.iotcomms.io;originatingProtocol=voicecall;deviceId=1234

The service connects the call to the controller and selects voice unit 1234.

For analogue group scheme controllers:

• The controller is reachable via a phone number through the PSTN
• The alarm receiving center initiates a SIP call routed via a SIP trunk
• The same URI parameters identify the target voice unit

Example:

sip:+46123457@customer.prod-eu-north-1.iotcomms.io;originatingProtocol=voicecall;deviceId=1235

The service routes the call via the SIP trunk and uses the configured alarm protocol to select the correct voice unit.

Note: A device of type alarmbridgeGroupSchemeController must be provisioned with:

• matching deviceCLI value (for example +46123457)
• configured serviceData.alarmBridge.alarmProtocol

Otherwise the service cannot determine which protocol to use for voice unit selection and the callback will fail.

The SIP user part when calling back to a SIP device is the deviceId used when provisioning the device.

Since colon (:) is not valid in the SIP user part, it must be URI encoded as %3A when constructing the SIP URI.

If a group scheme controller or dispersed alarm device is provisioned with:

1234:9999

where:

• 1234 is customerSiteId
• 9999 is controllerId

then the SIP user part becomes:

1234%3A9999

Note: Callbacks to devices connected via the public telephone network through a SIP trunk must not use the customerSiteId prefix in the SIP URI. This applies only to SIP registered devices.

Example — dispersed alarm device with customerSiteId

sip:1234%3A9999@customer.prod-eu-north-1.iotcomms.io

Example — group scheme controller with customerSiteId

If the target voice unit is provisioned as:

1234:9999:123

the callback URI becomes:

sip:1234%3A9999@customer.prod-eu-north-1.iotcomms.io;originatingProtocol=voicecall;deviceId=1234:9999:123