Protocols About 2 min read

Alarm monitoring protocols

Follow alarm reports from the premises through the receiver to monitoring software. Check message acceptance, supervision and the operator response at each stage.

Overview#

Alarm communication has several distinct interfaces. Confusing them produces brittle integrations:

text
protected premises                  monitoring centre

panel / communicator  ── DC-09 ──> receiver ── DC-07 ──> automation
        │                 │            │
        └─ DC-03 or       │            └─ acknowledgement, receiver status
           Contact ID     └─ IP transport of event content

operator telephone ── DTMF / voice ──> premises audio-verification system
                         AV-01
Reference Interface Status note
SIA DC09 Premises equipment to central station receiver over IP Current ANSI/SIA edition is DC09 2026
SIA DC03 SIA format alarm communicator to receiver Current public SIA listing is DC03 2017
Contact ID / SIA DC05 DTMF alarm communicator to receiver Legacy but widely encountered; public listing is DC05 2016
SIA DC07 Receiver to monitoring automation computer SIA's public index and store expose conflicting edition labels; verify the purchased copy
SIA AV01 Monitoring operator to premises audio verification equipment Public listing is AV01 2014; DTMF command set standard
IEC 60839 alarm transmission Alarm transmission systems, equipment, and network requirements IEC 60839-5-1/-5-2/-5-3 baselines plus separately labelled IEC TS 60839-7-8 IP message protocol context

Shared engineering concerns#

  • Preserve account, receiver, line/channel, partition, zone/user, qualifier, event, and timestamp semantics without silently coercing unknown values.
  • Treat transport acceptance, protocol acknowledgement, automation ingestion, operator presentation, and response as different milestones.
  • Make duplicate detection and replay handling explicit. Alarm networks intentionally retry; duplicate delivery is normal, while duplicate operator action may not be.
  • Record occurrence time, transmitter time, receiver time, and ingest time separately.
  • Fail closed on malformed control messages, but don't discard the raw evidence required to diagnose a field incompatibility.
  • Never infer restoration merely because a fault event stops arriving. Use an explicit restore event or authoritative state query when the protocol and product support one.

Safety boundary#

Monitoring path work can suppress, delay, duplicate, or falsely generate dispatch relevant events. Keep development on synthetic accounts and isolated receiver/automation paths. Never use real subscriber identifiers or exercise panic, duress, fire, medical, hold up, lockdown, or dispatch workflows without the monitoring centre's written authorisation and operational controls.

Primary source#

Section overview · Wiki home