Contact ID is a standard format for describing alarm events. It gives a receiving system a consistent way to read the account, event code, event state and point information in a report.
For an installer, Contact ID answers the what of a report. The network or other connection used to carry that report answers the how. Keeping those two questions separate makes system selection and fault finding clearer.
What does a Contact ID report tell the receiver?
When a protected site creates an event, the Hub prepares a report for the configured receiving setup. The receiver uses the report fields to identify the account, event and point. The exact event set depends on the supported system and project configuration.
| Information | What it tells the receiving side | Why the installer checks it |
|---|---|---|
| Account reference | Which customer or site sent the report | Confirms the report is associated with the intended account |
| Event code | What condition is being reported, such as an intrusion alarm | Confirms the message matches the test or service requirement |
| Event qualifier / event state | Whether the message is a new event, restore or other supported state | Keeps a restore separate from a new alarm in the event history |
| Partition or area | Which configured section of the system the event belongs to, when used | Helps the receiver apply the right account and operating context |
| Point or zone reference | Which device or protected area is associated with the event | Lets the receiver and site records use the same location name |
These fields are useful because they connect a received message to a real place. “Point 6” is only useful when the project record says which door, room or device that point represents.
A report at a glance
Contact ID carries separate fields, not a sentence such as “someone opened the rear door.” Read those fields together to understand the event:
| Account | Event code | Qualifier / state | Partition | Point |
|---|---|---|---|---|
| Which site? | What happened? | New event or restore? | Which section? | Which point? |
This is a reading guide, not the full message layout or field order. The site record connects the numbers to names such as “Shop A” and “Rear door.”
A simple example: one rear-door event
Imagine a small shop after closing. The rear-door contact changes state. The Hub forms the configured event and sends a report. The receiving side should identify the same shop account and rear-door point for each message.
The installer can use this example to check three things:
- A new alarm message identifies the shop account, the rear-door point and the alarm event code.
- A later restore message uses that same account and point but a different qualifier or event state.
- The receiving side can therefore distinguish the start of the condition from the restore message; a restore message alone does not say that a person has attended or that the site is safe.
Right account, wrong point
Suppose the installer tests the rear door. The ARC receives the alarm under the correct shop account, but its screen identifies the stockroom PIR.
Ask the ARC for the point number it received. Compare that number with the rear-door reference in the installation record, then check the location assigned to it at the ARC.
| What you find | What to do |
|---|---|
| The received number matches the rear door, but the ARC shows the wrong name | Correct the location description in the ARC record. |
| The received number does not match the rear-door reference | Check the device/point assignment and any conversion used in the selected reporting setup. |
After correcting it, repeat the rear-door test. The ARC should now identify the intended point. Start with the point reference—not device pairing—because the report has already reached the receiver.
Traditional Contact ID and IP reporting
Contact ID describes the event information and, in the traditional DC-05 specification, the signaling format used to carry it. The transport available in a particular project is a separate integration choice.
The historical Contact ID specification describes a signaling format using DTMF tones for alarm communicators and central-station receivers. The SIA DC-05 Contact ID overview provides that public description. Public Contact ID format references describe the qualifier as the part that distinguishes a new event from a restore, alongside the account, event code, partition and zone or user reference. Modern products may carry Contact ID event content over a different supported path.
IP event reporting is a different transport approach. The SIA DC-09 overview describes carrying event content from protected premises to a central station using Internet Protocol. A project therefore needs to confirm both the report format and the receiving path; one does not automatically identify the other.
What Roombanker support means for project planning
Roombanker supports ADM-CID/Contact ID and SIA DC-09 reporting options. The applicable receiving setup, connection path and account details still need to be confirmed for the project. Support for a report format does not mean that every receiver or ARC can accept every configuration.
For the RB Link ARC configuration path, the installer enters the ARC-provided Main Address, Port Number and Account Number. RB Link is used for configuration and local event visibility; it does not show whether the Hub-to-ARC report was received. Ask the ARC to confirm the account and event at the receiving side.
What to confirm before choosing or configuring Contact ID
Keep the check practical:
- Ask the ARC which receiving method and receiver are supported for the project.
- Confirm the account reference supplied for the site.
- Agree which event types and points will be checked.
- Match each point reference to a clear site location.
- During a joint test, compare the local event with the account, event code, qualifier or event state, and point shown at the receiving side.
If the account is correct but the point is wrong, review the point mapping. If the local event is present but nothing is visible at the receiver, check the configured connection path with the ARC and technical support. For the complete two-sided test and handover sequence, use the ARC monitoring centre integration planning guide.
Contact ID in one sentence
Contact ID tells the receiver what happened and where; the selected transport path determines how the report travels. A reliable project confirms both sides with the ARC and keeps the account and point references tied to the real installation.
For the ARC service role itself, see What Is an Alarm Receiving Centre?.