Simple SIA over TCP Protocol

This document describes how to integrate your device or application with CallOnAlarm using the SIA DC-09 protocol over TCP. This is the recommended method for hardware manufacturers and IoT device developers.

Note: This low-level TCP protocol is designed for manufacturers and developers who prefer direct socket communication over HTTP. If you're looking for a simpler integration using standard HTTP requests, see the Public API documentation instead.

Simplified Integration: This guide presents a simplified implementation of the SIA DC-09 protocol. We use the SIA-DCS message format exclusively, which is the most straightforward and widely supported format. Contact ID (ADM-CID) is not covered in this documentation.


Overview

CallOnAlarm accepts alarm messages using the SIA DC-09 protocol, an industry standard used by most professional alarm panels worldwide. Your device connects via TCP, sends a formatted message, and receives an acknowledgment (ACK).

Why SIA over TCP?

Feature
Benefit

Industry standard

Compatible with existing alarm infrastructure

TCP reliability

Guaranteed delivery with ACK confirmation

Low bandwidth

Minimal data transfer (~100 bytes per message)

Simple workflow

Connect, send, receive ACK, disconnect

Firewall friendly

Single outbound TCP connection


Connection Details

Parameter
Value

Host

sia.callonalarm.io

Port

5001

Protocol

TCP

Encryption

Not supported at this time due to inconsistent implementation across different manufacturers.

Connection Lifecycle

Timeouts

Server-side timeouts are subject to change. These values are provided for reference only and should not be hardcoded in your implementation.

Timeout
Current Value
Description

First data

10 seconds

Must send data within 10s of connecting

Idle

60 seconds

Connection closed after 60s of inactivity

Max connection

5 minutes

Maximum duration for a single connection

Note: Client-side timeouts are at your discretion. We recommend a 5-10 second timeout for ACK reception.


Message Format

Structure

All messages follow this structure:

Field
Size
Description

LF

1 byte

Line Feed character (0x0A)

CRC

4 chars

CRC-16 checksum in uppercase hex (e.g., A4FE)

LENGTH

4 chars

Content length in uppercase hex (e.g., 0052)

CONTENT

Variable

The SIA message payload

CR

1 byte

Carriage Return character (0x0D)

CRC-16 Calculation

The CRC is calculated on the CONTENT portion only, using polynomial 0x8005 (CRC-16-IBM).

C implementation:

Test Vectors

Use these examples to validate your CRC implementation before connecting to CallOnAlarm.

Content
Length
CRC

"SIA-DCS"0001L0#12345678[#12345678|BA001]

41 (0x0029)

0xEB87

"SIA-DCS"0042L0#12345678[#12345678|FA002]

41 (0x0029)

0x9DC1

"NULL"0001L0#12345678[]

23 (0x0017)

0x480A

"ACK"0001L0#[]

14 (0x000E)

0xE77D

Tip: If your CRC values don't match these examples, check that you're using the correct polynomial (0x8005) and that your table is properly initialized.


Message Types

SIA-DCS (Alarm Events)

The simplest format for sending alarm events.

Format:

Or with optional timestamp:

Field
Description
Example

SEQ

4-digit sequence number (0001-9999)

0001

ACCOUNT

Your account number from CallOnAlarm

12345678

EVENT_CODE

2-letter SIA code

BA (Burglary Alarm)

ZONE

3-4 digit zone number

001 or 0001

TIMESTAMP

Optional. Format: HH:MM:SS,MM-DD-YYYY

12:38:20,01-30-2026

Example - Burglary Alarm on Zone 1:

Example - With timestamp (optional):

Complete message with framing:

NULL (Heartbeat)

Keep the connection alive and verify connectivity.

Format:

Example:

Note: NULL messages do not trigger alerts. Use them for periodic connectivity checks (recommended: every 30-60 seconds for persistent connections).


ACK Response

After receiving a valid message, CallOnAlarm responds with an ACK.

Format:

Example:

If you sent sequence 0001, you will receive:

Validating the ACK:

1

Extract sequence number

Extract the sequence number from the ACK message.

2

Verify match

Ensure the sequence matches the sequence you sent.

3

Optional CRC check

Optionally verify the CRC of the ACK payload.

Important: Always wait for the ACK before sending the next message or closing the connection.


Complete Examples

circle-info

You can test the ESP32 CallOnAlarm integration in the playground here: https://wokwi.com/projects/457058213945128961arrow-up-right


Best Practices

Sequence Numbers

  • Increment the sequence number (0001-9999) for each message

  • Roll over from 9999 to 0001

  • Use the sequence to match ACKs to sent messages

Error Handling

Scenario
Action

No ACK received

Retry after 5 seconds (max 3 retries)

Connection refused

Retry after 30 seconds

Invalid ACK

Log and retry with new sequence

Timeout

Close connection, reconnect, retry

Persistent Connections

1

Heartbeats

Send a NULL heartbeat every 30-60 seconds.

2

Connection drops

Handle connection drops gracefully.

3

Reconnection

Implement automatic reconnection with exponential backoff.

Security Recommendations

  • Store account numbers securely

  • Implement rate limiting on your device

  • Validate ACK responses before proceeding


Troubleshooting

Common Issues

Problem
Cause
Solution

No ACK received

CRC mismatch

Verify CRC calculation

Connection closed immediately

Invalid first byte

Ensure message starts with LF (0x0A)

ACK received but no event in dashboard

Wrong account number

Verify account number matches your connection

Timeout

Network issue

Check firewall, verify host/port

Note: CallOnAlarm always sends an ACK for valid SIA messages, even if the account number doesn't exist. The only way to confirm your integration is working correctly is to check the Events section of your connection in the dashboard.

Testing Your Integration:

1

Create account

Create an account on CallOnAlarm.

2

Create connection

Create a connection but do not activate it β€” allows testing without triggering real alerts.

3

Connect device

Connect your device and send test messages.

4

Verify events

Check the Events tab in your connection dashboard to verify messages are received correctly.

5

Activate

Activate your connection only when testing is complete and everything works.


Security & Rate Limiting

CallOnAlarm implements server-side protections against abuse and misconfigured devices. Ensure your implementation follows best practices to avoid being banned.

Active Protections

Please, see this IP Banned by CallOnAlarm

Avoiding Bans

Cause
Solution

CRC calculation error

Verify your CRC implementation against test vectors

Missing framing bytes

Ensure messages start with LF and end with CR

Reconnection loop

Implement exponential backoff on connection failures

Excessive NULL heartbeats

For persistent connections only: send heartbeats every 30-60 seconds (30s min, 60s max)

Design Philosophy

  • Buffer Overflow = Attack β†’ Immediate ban, no tolerance

  • Invalid Messages = Configuration Error β†’ 10 attempts tolerance, then 1h ban

  • Rapid Connections = Port Scan/Flood/Brute-force β†’ Detection and 1h to 24h ban

  • Automatic Reset β†’ A valid message resets the error counter

Important: If your device gets banned, it will be automatically unbanned after the ban duration. Check your implementation before reconnecting.


Event Codes Reference

The EVENT_CODE field uses standard SIA (Security Industry Association) codes.

Complete event codes list in the API v1 section : Event Codes Reference


Support

For integration support, contact us at:


Changelog

v1.0.0 (2026-01-30)

  • Initial release

  • SIA-DCS and NULL message support

  • CRC-16 ASCII format

  • C examples (POSIX and ESP32/Arduino)

Last updated