Introduction
The SIA DC-09 Internet Protocol Event Reporting Standard outlines how to implement the Contact ID and / or the SIA protocols over TCP/IP Connections.
This protocol allows for the transmission of SIA DC-07 payload messages (such as SIA DC-03 SIA and SIA DC-05 Contact ID) over TCP/IP using optional AES based 128bit and 256bit encryption.
Code Examples
ioBroker has an add on called ioBroker.sia, which implements an SIA protocol based alarm receiver for ioBroker, allowing ioBroker to handle various alarm events transmitted by DC-09 Compliant Alarm Systems.
Another code example by Jacq van Ovost allows the use of Python Libraries, to implement the Dialler (Alarm Panel Transmitter) side of the protocol, using either the SIA or Contact ID standards.
The Github Repository for this can be found here. https://github.com/jvanovost/dc09_spt
And Finally, there is a Python Receiver Example from CreepPork that supports Contact ID as the Protocol.
The Github Repository for this can be found here. https://github.com/CreepPork/py-sia-dc-07
There is also another Python Receiver Module Written by Nimnull, which a python conversion of the ioBroker.sia code
https://github.com/nimnull/sia-server/b ... rv/main.py
TCP / UDP Compatibility
Premises Equipment (PE) and Central Station Receivers (CSRs) shall support either UDP or TCP for event message transmission, and may support both UDP and TCP.
When CSRs support both protocols, the CSR shall automatically use the appropriate protocol for incoming messages without
requiring a configuration setting.
When PE support both protocols, the protocol use may be manually specified, or the manufacturer may implement a method to attempt message delivery with one protocol, and switch to the other as necessary.
When PE or CSRs support only one protocol, UDP is the preferred implementation but TCP may be used.
UDP Source Port Number
When UDP is used, the transmitter may set the source port number in the UDP header to the desired port at which replies from the central station receiver will be accepted.
This transmitter behavior is recommended.
Marking
Equipment capable of using UDP/IP for communication shall be marked as compatible with "SIA IP Reporting (UDP-2013)".
Equipment capable of using TCP/IP for communication shall be marked as compatible with "SIA IP Reporting (TCP-2013)". Equipment capable of using UDP/IP or TCP/IP for communication shall be marked as compatible with "SIA IP Reporting (UDP/TCP-2013)".
Additionally, equipment shall be marked to show the list of DC-07 tokens (protocols) that are supported.
When PE and CSRs implementing this standard share at least one protocol (UDP or TCP), they are intended to be interoperable.
DC-09 Internet Protocol Event Reporting
Requirements
Media
This standard can be implemented on any media that carries Internet protocol (IP), including but not limited to Ethernet, 802.11x, CDMA 1x or GPRS.
The ability of the network to perform media conversion and provide limited protection for message integrity is assumed.
IP Addresses
The central station receiver (CSR) shall be hosted on a static IP address.
The premises equipment (PE) may be hosted on a dynamic or static IP address and shall be capable of being programmed
with the IP address to which events are to be sent.
The PE may have an option to use DNS to obtain the address of the CSR, however the installation is not compliant with this standard when the DNS option is enabled.
Media
This standard can be implemented on any media that carries Internet protocol (IP), including but not limited to Ethernet, 802.11x, CDMA 1x or GPRS.
The ability of the network to perform media conversion and provide limited protection for message integrity is assumed.
IP Addresses
The central station receiver (CSR) shall be hosted on a static IP address.
The premises equipment (PE) may be hosted on a dynamic or static IP address and shall be capable of being programmed
with the IP address to which events are to be sent.
The PE may have an option to use DNS to obtain the address of the CSR, however the installation is not compliant with this standard when the DNS option is enabled.
Encryption
PE may indicate use of AES encryption to transmit events. Encryption support is optional for PE.
Encryption support is mandatory for CSRs
Encryption Standard
For the AES requirements, refer to Federal Information Processing Standards Publication 197
that is available from the National Institute of Standards and Technology.
Additionally, encrypted messages shall use Cipher Block Chaining, as described in section 6.2 of
NIST Special Publication 800-38A (2001 Edition).
Identifying Encrypted Messages
Encrypted messages shall be identified with an asterisk as described in section 0 of this standard.
Encrypted Elements
When encryption is used, only the data, timestamp and padding content of a message are encrypted.
Encryption begins on the byte after the opening bracket "[" on the data element, and
ends just before the terminating <CR>.
The encrypted elements are shaded in the frame, below:
PE may indicate use of AES encryption to transmit events. Encryption support is optional for PE.
Encryption support is mandatory for CSRs
Encryption Standard
For the AES requirements, refer to Federal Information Processing Standards Publication 197
that is available from the National Institute of Standards and Technology.
Additionally, encrypted messages shall use Cipher Block Chaining, as described in section 6.2 of
NIST Special Publication 800-38A (2001 Edition).
Identifying Encrypted Messages
Encrypted messages shall be identified with an asterisk as described in section 0 of this standard.
Encrypted Elements
When encryption is used, only the data, timestamp and padding content of a message are encrypted.
Encryption begins on the byte after the opening bracket "[" on the data element, and
ends just before the terminating <CR>.
The encrypted elements are shaded in the frame, below:
You do not have the required permissions to view the files attached to this post.
Padding
Only when encryption is used, messages shall be padded with pseudo-random data (pad) so that the byte count of the encrypted region is an even multiple of 16.
Padded Region
The characters counted for padding and encryption begin after the opening bracket "[" on the data element, and include the pad field (pad), data, and timestamp field. The final <CR> is not included in the count for padding and is not encrypted.
Pad Data
Pad data shall be pseudo-random bytes which vary from one message to the next.
This data will consist of binary values 0-255, except that it shall not contain the ASCII values for the character "|" (124, x7C), "[" (91, x5B) or "]" (93, x5D).
pad (Pad Data Field)
When a message is encrypted, padding is inserted between the open bracket character "[" and the pad termination character "|". The number of characters in the pad field shall be such that the total number of encrypted characters (from the first pad character up to and including the last timestamp character is an even multiple of 16.
When a message is already an even multiple of 16 bytes, 16 pad bytes shall be added to the message.
The "|" character immediately following the pad field shall appear in all encrypted messages.
This pad termination "|" character shall not appear in unencrypted messages, though the "|" character that typically separates the account number from the rest of the data may appear.
Only when encryption is used, messages shall be padded with pseudo-random data (pad) so that the byte count of the encrypted region is an even multiple of 16.
Padded Region
The characters counted for padding and encryption begin after the opening bracket "[" on the data element, and include the pad field (pad), data, and timestamp field. The final <CR> is not included in the count for padding and is not encrypted.
Pad Data
Pad data shall be pseudo-random bytes which vary from one message to the next.
This data will consist of binary values 0-255, except that it shall not contain the ASCII values for the character "|" (124, x7C), "[" (91, x5B) or "]" (93, x5D).
pad (Pad Data Field)
When a message is encrypted, padding is inserted between the open bracket character "[" and the pad termination character "|". The number of characters in the pad field shall be such that the total number of encrypted characters (from the first pad character up to and including the last timestamp character is an even multiple of 16.
When a message is already an even multiple of 16 bytes, 16 pad bytes shall be added to the message.
The "|" character immediately following the pad field shall appear in all encrypted messages.
This pad termination "|" character shall not appear in unencrypted messages, though the "|" character that typically separates the account number from the rest of the data may appear.
Encryption Key
When encryption is selected, the PE may use a key length of 128, 192 or 256 bits.
A matching key value (and therefore matching key length) must be programmed at the PE and the CSR.
Central Station Receiver Requirements
A CSR shall support all three key lengths, as well as messages using no encryption.
Other key lengths may be incorporated into the standard in the future, but are currently non-compliant.
Each port in the CSR that receives events shall be configurable with at least one encryption key, to be used for all PE reporting to that IP address/port. Optionally, each port may be configurable with multiple encryption keys, to be used with individual accounts or groups of accounts.
Premises Equipment Requirements
When the PE supports encryption, it shall be able to store a private key of 128, 192 or 256 bits in length, at the option of the manufacturer.
Key Contents
When private or session keys are created, a pseudo-random process shall be used.
Each bit shall have an equal probability of being 0 or 1 as the key is created. The use of a binary-encoded ASCII phrase as the key is specifically discouraged.
When encryption is selected, the PE may use a key length of 128, 192 or 256 bits.
A matching key value (and therefore matching key length) must be programmed at the PE and the CSR.
Central Station Receiver Requirements
A CSR shall support all three key lengths, as well as messages using no encryption.
Other key lengths may be incorporated into the standard in the future, but are currently non-compliant.
Each port in the CSR that receives events shall be configurable with at least one encryption key, to be used for all PE reporting to that IP address/port. Optionally, each port may be configurable with multiple encryption keys, to be used with individual accounts or groups of accounts.
Premises Equipment Requirements
When the PE supports encryption, it shall be able to store a private key of 128, 192 or 256 bits in length, at the option of the manufacturer.
Key Contents
When private or session keys are created, a pseudo-random process shall be used.
Each bit shall have an equal probability of being 0 or 1 as the key is created. The use of a binary-encoded ASCII phrase as the key is specifically discouraged.
Cipher Block Chaining
The encrypted blocks of a message implement cipher block chaining as described in section 6.2 of NIST Special Publication 800-38A (2001 Edition).
For this protocol, the initialization vector (IV) will be all zeros, as the padding characters provide the variability needed for message confidentiality.
Refer to Annex A for a copy of the cipher block chaining method to be used.
Encoding
In the encrypted region of the message, each byte shall be encoded for transmission as two ASCII characters (0-9, A-F) representing the hexadecimal value of the encrypted byte.
For example, the message:
When encrypted, might (depending on the encryption key used) be transmitted using the following ASCII characters:
The encrypted blocks of a message implement cipher block chaining as described in section 6.2 of NIST Special Publication 800-38A (2001 Edition).
For this protocol, the initialization vector (IV) will be all zeros, as the padding characters provide the variability needed for message confidentiality.
Refer to Annex A for a copy of the cipher block chaining method to be used.
Encoding
In the encrypted region of the message, each byte shall be encoded for transmission as two ASCII characters (0-9, A-F) representing the hexadecimal value of the encrypted byte.
For example, the message:
Code: Select all
<LF>B3680040"ADM-CID"0001L000000#1234[#1234|1140 00 007]_22:49:34,01-22-2012<CRC>
Code: Select all
<LF>4B89007B"*ADM-CID"0001L000000#1234
[371baac130fe81508f556e6fd2ccfd8826e9ba186f0fb67
4bb87c079484e546dff35532aa285936a00c27b6feb053f68
<CR>
Messages
PE may send two types of messages: events and link supervision.
CSRs send only one type of message, acknowledgment, which may have three types: ACK, NAK, or DUH.
Event Messages (PE)
The format used for the events is based on SIA protocol (DC-07-2001.04) outlined in SIA Digital Communications Standards – Receiver-to-Computer Interface Protocol (Type 2).
The template for each event:
LF
This is the ASCII linefeed character, transmitted as a binary value 0x0A.
crc
The portion of the message starting with the first quote character of the ID and ending with the character before the terminating CR, are included in the CRC calculation.
This is the middle line in the frame shown above. Refer to DC-07-2001.04 for the detailed CRC implementation.
When messages are encrypted, the CRC shall be applied after the encryption is applied.
The CRC shall be transmitted as four ASCII characters.
0LLL
This length element consists of the character "0" (ASCII zero) followed by 3 hex digits (in ASCII) giving the length of the message.
The characters counted are the same as are included in the CRC calculation, as described in section 5.5.1.2.
"id" (ID Token)
The <"id"> field contains an ASCII token to indicate the format used in the data field of the message, and whether or not encryption is used.
The quote characters are included in the message.
A CSR compliant with this standard shall support at least the SIA-DCS and ADM-CID tokens (protocols) shown in Annex H, based on the token definition in DC-07-2001.04.
PE shall support at least one of the tokens SIA-DCS and ADM-CID, and may support any others shown in Annex H.
Encryption Flag
When the data and timestamp of a message are encrypted, the ID Token is modified to insert an ASCII "*" after the quotation character and before the first character of the token.
For example, an unencrypted SIA DCS packet would use the token "SIA-DCS" and an encrypted SIA DCS packet would use the token "*SIA-DCS".
seq
The PE applies a sequence number to each message as it is queued.
The CSR shall echo the sequence number of the message to which it is replying in its acknowledgement messages.
The PE shall not increment the sequence number when repeating a message due to a communication failure or no response from a CSR.
The PE shall increment the sequence number to be used as each new message is queued.
When the sequence number is 9999, the next sequence number is 0001. Refer to section 7.1.5 of DC-07-2001.04 for additional information.
The sequence number shall be transmitted as four ASCII characters.
Segment numbers, as described in DC-07, are not used in this protocol.
PE may send two types of messages: events and link supervision.
CSRs send only one type of message, acknowledgment, which may have three types: ACK, NAK, or DUH.
Event Messages (PE)
The format used for the events is based on SIA protocol (DC-07-2001.04) outlined in SIA Digital Communications Standards – Receiver-to-Computer Interface Protocol (Type 2).
The template for each event:
Code: Select all
<LF><crc><0LLL>
<"id"><seq><Rrcvr><Lpref><#acct>[<pad>|...data...][x...data...]<timestamp>
<CR>
This is the ASCII linefeed character, transmitted as a binary value 0x0A.
crc
The portion of the message starting with the first quote character of the ID and ending with the character before the terminating CR, are included in the CRC calculation.
This is the middle line in the frame shown above. Refer to DC-07-2001.04 for the detailed CRC implementation.
When messages are encrypted, the CRC shall be applied after the encryption is applied.
The CRC shall be transmitted as four ASCII characters.
0LLL
This length element consists of the character "0" (ASCII zero) followed by 3 hex digits (in ASCII) giving the length of the message.
The characters counted are the same as are included in the CRC calculation, as described in section 5.5.1.2.
"id" (ID Token)
The <"id"> field contains an ASCII token to indicate the format used in the data field of the message, and whether or not encryption is used.
The quote characters are included in the message.
A CSR compliant with this standard shall support at least the SIA-DCS and ADM-CID tokens (protocols) shown in Annex H, based on the token definition in DC-07-2001.04.
PE shall support at least one of the tokens SIA-DCS and ADM-CID, and may support any others shown in Annex H.
Encryption Flag
When the data and timestamp of a message are encrypted, the ID Token is modified to insert an ASCII "*" after the quotation character and before the first character of the token.
For example, an unencrypted SIA DCS packet would use the token "SIA-DCS" and an encrypted SIA DCS packet would use the token "*SIA-DCS".
seq
The PE applies a sequence number to each message as it is queued.
The CSR shall echo the sequence number of the message to which it is replying in its acknowledgement messages.
The PE shall not increment the sequence number when repeating a message due to a communication failure or no response from a CSR.
The PE shall increment the sequence number to be used as each new message is queued.
When the sequence number is 9999, the next sequence number is 0001. Refer to section 7.1.5 of DC-07-2001.04 for additional information.
The sequence number shall be transmitted as four ASCII characters.
Segment numbers, as described in DC-07, are not used in this protocol.
Account Identification (Rrcvr, Lpref, #acct)
Each set of PE may be provided with up to three complementary identifying tokens.
#acct (Account Number)
The account number is the most specific token, and is always programmed into the premises equipment to identify it.
The account token appears both in the header of the message (which is never encrypted) and in the data of the message (which may be encrypted).
This element consists of an ASCII "#", followed by 3-16 ASCII characters representing hexadecimal digits for the account number. There is no corresponding element in the DC-07 protocol.
In certain special applications, the information provided in the #acct element may not match the account number contained within the message data (see paragraph 5.5.1.7).
For example, a manufacturer may choose to transmit a MAC address as an identifier.
Lpref (Account Prefix)
The account prefix can be programmed into the PE to extend the identification provided by the account number.
This element is required, and consists of an ASCII "L", followed by 1-6 HEX ASCII digits for the account prefix. When the PE does not need to transmit an account prefix, "L0" shall be transmitted for this element.
This element corresponds with the receiver line number element in the DC-07 protocol.
Rrcvr (Receiver Number)
In some cases, PE may be programmed to further extend the identification provided by the account number and account prefix by providing a receiver number.
This element is optional, and consists of an ASCII "R", followed by 1-6 HEX ASCII digits for the receiver number.
When the PE does not need to transmit a receiver number, nothing shall be transmitted for this element (i.e. "R" or "R0" are not to be transmitted in this case).
This element corresponds with the receiver number element in the DC-07 protocol.
Each set of PE may be provided with up to three complementary identifying tokens.
#acct (Account Number)
The account number is the most specific token, and is always programmed into the premises equipment to identify it.
The account token appears both in the header of the message (which is never encrypted) and in the data of the message (which may be encrypted).
This element consists of an ASCII "#", followed by 3-16 ASCII characters representing hexadecimal digits for the account number. There is no corresponding element in the DC-07 protocol.
In certain special applications, the information provided in the #acct element may not match the account number contained within the message data (see paragraph 5.5.1.7).
For example, a manufacturer may choose to transmit a MAC address as an identifier.
Lpref (Account Prefix)
The account prefix can be programmed into the PE to extend the identification provided by the account number.
This element is required, and consists of an ASCII "L", followed by 1-6 HEX ASCII digits for the account prefix. When the PE does not need to transmit an account prefix, "L0" shall be transmitted for this element.
This element corresponds with the receiver line number element in the DC-07 protocol.
Rrcvr (Receiver Number)
In some cases, PE may be programmed to further extend the identification provided by the account number and account prefix by providing a receiver number.
This element is optional, and consists of an ASCII "R", followed by 1-6 HEX ASCII digits for the receiver number.
When the PE does not need to transmit a receiver number, nothing shall be transmitted for this element (i.e. "R" or "R0" are not to be transmitted in this case).
This element corresponds with the receiver number element in the DC-07 protocol.
[Data] or [<pad>|Data] (Message Data)
All data is in ASCII characters and the bracket characters "[" and "]" are included in the transmitted message.
Its format is dependent upon the ID token of the message.
Where an account number is associated with a message (most message types), the account number data appears at the start of the data, preceded by the "#" character and followed by the field separator "|".
The account number is 3-10 ASCII characters representing hexadecimal digits.
Note that the data element and timestamp in a message may be encrypted
Refer to the Padding section for a description of the <pad> field that appears within the data field of encrypted messages.
All data is in ASCII characters and the bracket characters "[" and "]" are included in the transmitted message.
Its format is dependent upon the ID token of the message.
Where an account number is associated with a message (most message types), the account number data appears at the start of the data, preceded by the "#" character and followed by the field separator "|".
The account number is 3-10 ASCII characters representing hexadecimal digits.
Note that the data element and timestamp in a message may be encrypted
Refer to the Padding section for a description of the <pad> field that appears within the data field of encrypted messages.