Contact ID y SIA DC-09 para integración de alarmas y monitoreo

Informe ejecutivo

Para proyectos profesionales de integración, Contact ID y SIA DC-09 no compiten exactamente en el mismo plano: Contact ID sigue siendo el lenguaje de señalización más extendido en paneles legados y en muchos DACT/capturadores de discador, mientras que DC-09 es el marco IP moderno para transportar eventos desde el predio protegido hacia la central de monitoreo con supervisión y mecanismos de seguridad considerablemente mejores. La Security Industry Association define hoy ambos mundos en su familia DC: DC-05-2016 para Ademco Contact ID y DC-09-2026 como revisión vigente del transporte IP; además, la edición 2026 de DC-09 incorpora autocomisionamiento, rotación de claves y mejoras de seguridad, manteniendo compatibilidad hacia atrás.

En términos de ingeniería de proyecto, la regla práctica es simple: si el panel y el receptor soportan DC-09 nativo, conviene priorizarlo; si el parque instalado depende de salidas PSTN/DTMF, Contact ID sigue siendo plenamente viable, sobre todo mediante soluciones de dialer capture que toman la trama DTMF local y la reenvían por IP/celular. Ese segundo escenario, sin embargo, no debe confundirse con “DC-09 nativo”: puede haber payload Contact ID encapsulado o traducido por un gateway, con temporizaciones, supervisión, cifrado y fallback definidos por el fabricante del comunicador.

El mayor error de diseño no suele estar en el “protocolo”, sino en asumir interoperabilidad donde solo hay compatibilidad parcial. En la práctica hay que validar, como mínimo, transporte (POTS, TCP, UDP, IP/celular), token o formato interno (ADM-CID, SIA-DCS), longitud/uso de cuenta, firmware de receptor, ventanas de supervisión, política de ACK/NAK, gestión de claves y comportamiento de failover. Eso explica por qué dos equipos que “soportan DC-09” o “soportan Contact ID” pueden aun así requerir trabajo de homologación.

Contexto y evolución

La evolución pública que hoy puede documentarse con fuentes oficiales muestra una transición clara desde formatos telefónicos DTMF/FSK hacia transporte IP supervisado. Contact ID nació como formato Ademco y fue normalizado por SIA para adopción interoperable; en paralelo, la familia SIA mantuvo y actualizó su propio “SIA Format” y, más adelante, construyó DC-09 para llevar eventos sobre IP tomando como base conceptual el protocolo receptor‑a‑computadora DC-07.

Una precisión importante para proyectistas: CP-01 no reemplaza ni modifica el transporte; su aporte está en la calidad de operación del panel y la reducción de falsas alarmas. En otras palabras, un proyecto moderno debería especificar “panel conforme a CP-01 + transporte DC-09 o Contact ID según el caso”, no una cosa en lugar de la otra.

Contact ID

Contact ID es, en su forma normalizada, un formato para comunicación de alarmas que usa tonos DTMF, busca compatibilidad transversal entre transmisores y receptores, y en implementaciones típicas envía una cuenta de 4 dígitos. En documentación de paneles y comunicadores oficiales sigue apareciendo como formato de referencia para receptores multiservicio y para capturadores de discador.

En equipos de fabricante, el transporte clásico de Contact ID sigue el flujo PSTN habitual: toma de línea, estado off‑hook/on‑hook, detección de tono de discado, marcado, reconocimiento de handshake y kissoff según el formato. En el manual de la 5104B de Honeywell, Contact ID aparece como formato DTMF, con acuse a 1400 y 2300 Hz; en otros paneles de la misma familia se indica expresamente que el control ajusta el reconocimiento de ACK y kissoff según frecuencia y duración del tono del receptor.

La estructura más clara encontrada en documentación pública de fabricante para la trama Contact ID es la siguiente:

AAAA MM QEEE GG CCC S

donde AAAA es el número de cliente, MM el tipo de mensaje, Q el calificador del evento, EEE el código de evento, GG el grupo o partición, CCC la zona o usuario, y S el dígito de validación de trama. En documentación de DMP además se indica que un reporte Contact ID está compuesto por 18 dígitos DTMF. Cuando no se publique el valor exacto de MM o el checksum final para un caso concreto, debe tratarse como no especificado hasta homologarlo con panel y receptor reales.

Un ejemplo ilustrativo, con el checksum dejado explícitamente como campo pendiente de implementación, sería:

1234 MM 1 110 00 001 [S]

Interpretación: cuenta 1234, nuevo evento (Q=1), código 110 (fuego), partición 00, zona 001, y [S] como dígito de validación de trama. El código 110 está documentado en tablas de fabricantes como código Contact ID de incendio, y la documentación pública revisada confirma el rol del dígito final de validación.

En cuanto a ACK/NAK y temporización, la documentación pública de Contact ID revisada habla sobre todo de handshake y kissoff por tonos, más que de mensajes NAK explícitos a nivel PSTN. En la 5104B se documentan 3 a 5 intentos por cuenta y 15 intentos totales antes de declarar fallo del discador; en una pasarela IPDACT, el kissoff local hacia el panel se retiene hasta recibir el acuse desde el receptor IP, y si ese acuse no llega en 2 segundos el equipo reintenta el envío un número configurado de veces antes de devolver el tráfico al camino telefónico.

Desde el punto de vista de seguridad, Contact ID es fuerte en simpleza e interoperabilidad, pero débil en protección criptográfica. En la estructura publicada no aparecen campos de cifrado o autenticación criptográfica; lo que sí aparece es el uso de DTMF y un dígito de validación de trama. Por eso, cuando se mantiene Contact ID en proyectos actuales, la seguridad suele depender del medio físico, del comunicador intermedio o de la red superpuesta, no del formato en sí. Esta conclusión es una inferencia técnica directa a partir de la estructura y alcance publicados.

SIA DC-09

DC-09 es el estándar de SIA para reportar eventos desde el predio protegido a la central usando Internet Protocol, incluso a través de Internet pública. La propia SIA aclara que el estándar usa como fundamento el protocolo receptor‑a‑computadora SIA, pero está pensado específicamente para el tramo premises equipment → central station receiver. La revisión 2026 agrega autocomisionamiento, rotación de claves, mejoras de seguridad y ejemplos adicionales, manteniendo compatibilidad hacia atrás.

Una implementación de fabricante muy útil para visualizar la estructura de mensaje es la de ABUS, que documenta los campos presentes conforme al capítulo 5.5.1 del estándar en este orden: LF, CRC, 0LLL, ID, Seq, Rrcvr, Lpref, #acct, Pad, Data, Timestamp, CR. En esa misma implementación, Rrcvr no se envía, Lpref se fija como L0, Pad y Data van dentro de corchetes, y el Timestamp aparece solo en mensajes cifrados. Además, ABUS exige una diferencia máxima de tiempo de +20/-40 segundos entre panel y receptor para esos mensajes.

Un esqueleto genérico legible para ingeniería sería:

<LF><CRC><0LLL><ID><Seq>L0#<acct>[<pad><data>]<timestamp?><CR>

donde ID puede tomar, según la implementación publicada, valores como "ADM-CID" para Contact ID encapsulado y "SIA-DCS" para payload SIA. Una interpretación formal de SIA sobre el campo CRC aclara además que, aunque el CRC subyacente sea de 16 bits, en el mensaje transmitido DC-09 el CRC debe viajar como cuatro caracteres ASCII hexadecimales, no como dos bytes binarios.

Eso conduce a una observación clave de interoperabilidad: DC-09 es un contenedor/transporte IP, no un vocabulario único de eventos. Puede cargar SIA-DCS, pero también ADM-CID; por tanto, es perfectamente posible tener Contact ID sobre DC-09, lo cual no es lo mismo que “Contact ID PSTN clásico” ni lo mismo que “SIA Format”. Para diseño de integración, esta distinción debe quedar escrita en la matriz de compatibilidad.

En transporte, la documentación pública de fabricantes muestra que DC-09 no aparece en un único sabor comercial. ABUS documenta TCP y uso de puerto 9999 en su implementación; la documentación de Bosch Building Technologies publica soporte para SIA DC09 UDP y SIA DC09 TCP; y un receptor SG‑System IV de Johnson Controls describe explícitamente la recepción de mensajes en tramas UDP/IP y la devolución de una respuesta ACK o NAK al transmisor/panel. En consecuencia, “soporta DC-09” no basta: hay que pedir DC-09 sobre qué transporte y contra qué receptor.

En seguridad, la diferencia frente a Contact ID es material. ABUS publica opciones de cifrado 128/192/256 bits con clave hexadecimal y señala que el cifrado aparece desde cierto nivel de firmware; Johnson Controls documenta AES‑128 en su línea de comunicadores; y SIA afirma que DC-09-2026 incorpora rotación de claves y mejoras adicionales de ciberseguridad. En otras palabras, DC-09 ya no es solo “alarmas por IP”, sino un marco de supervisión + integridad + cifrado mucho más alineado con requisitos actuales.

Los tiempos típicos publicados en documentación de producto para ecosistemas DC-09/IP son útiles como referencia de ingeniería, pero deben leerse como valores de implementación, no como constantes universales del estándar:

Compatibilidad, fortalezas y debilidades

La siguiente tabla resume los atributos más relevantes para una decisión de diseño. Cuando el dato exacto no aparece en las fuentes públicas revisadas, se marca como no especificado.

El punto más importante para interoperabilidad real es este: el soporte comercial existe, pero no es uniforme. Un panel Honeywell 6700, por ejemplo, declara compatibilidad de SIA y Contact ID con receptores Honeywell, Ademco, Sur‑Gard y Osborne Hoffman; un panel ABUS puede encapsular ADM-CID o SIA-DCS en DC-09; Bosch publica soporte DC09 TCP/UDP; y los comunicadores DSC/Johnson Controls dependen de familias y versiones concretas de receptores Sur‑Gard. Eso habla bien del ecosistema, pero obliga a especificar versiones y matrices de prueba, no solo nombres de protocolo.

Arquitecturas, secuencias y ejemplos

Una arquitectura muy común en modernización conserva el panel legado hablando Contact ID por TIP/RING y delega la salida IP/celular a un capturador de discador. Ese patrón aparece de forma muy clara en la documentación de CLSS Pathway y de IPDACT: el panel sigue “creyendo” que llama por PSTN, mientras que el gateway captura la señalización y la reenvía digitalmente a la central.

La secuencia típica de ese escenario, cuando el gateway “retiene” el kissoff local hasta conseguir el ACK remoto, puede modelarse así:

Ese comportamiento está documentado de forma explícita: el IPDACT no entrega el kissoff al panel hasta que el receptor remoto confirma la recepción, espera 2 s por ACK, reintenta, y si la conectividad IP se considera perdida deja al panel usar la línea telefónica. Es una pieza de ingeniería sumamente útil cuando se quiere migrar a IP sin cambiar paneles.

En una arquitectura nativa DC-09, en cambio, el panel o comunicador ya transmite directamente una trama IP con secuencia, CRC y payload encapsulado, y el receptor responde con ACK/NAK. La supervisión se maneja con heartbeats y ventanas temporales configurables, algo más cercano a una ingeniería de red que a una simple ingeniería de discador telefónico.

Para payloads de ejemplo, conviene distinguir entre payload interno y frame IP externo. Un payload SIA clásico que ABUS muestra para “fuego en zona 2 de la partición 4 a las 10:15” es:

#000010|Nti10:15|ri4|FA2|AFire Zone 2

Ese string puede viajar encapsulado en DC-09 si el token es SIA-DCS. Del mismo modo, un payload Contact ID puede viajar encapsulado si el token es ADM-CID. Esta separación conceptual ayuda mucho a diseñar adaptadores, parsers y reglas de automatización.

Recomendaciones, checklist y tendencias

Para proyectos nuevos, la recomendación práctica más robusta es especificar DC-09 nativo siempre que panel, comunicador, receptor y automatización lo soporten de forma homogénea, porque ofrece supervisión, seguridad y una hoja de ruta vigente. Para migraciones, Contact ID sigue siendo totalmente válido cuando el objetivo es preservar paneles legados y usar dialer capture o gateways IP/celulares. En ambos casos, lo correcto es diseñar end-to-end y no por dispositivo aislado.

Checklist mínimo para un proyecto de integración:

• Definir por escrito si el transporte será Contact ID PSTN, Contact ID capturado y reenviado, o DC-09 nativo. No son equivalentes aunque compartan semántica de evento.
• Confirmar el payload interno que espera el receptor: ADM-CID, SIA-DCS u otro token soportado.
• Verificar transporte exacto: TCP, UDP, puerto(s), direccionamiento, NAT/firewall y si hay una exigencia de puertos concretos como 9999 en implementaciones documentadas.
• Homologar firmware y receptor con matriz de compatibilidad real. “Soporta el protocolo” no reemplaza una prueba con versiones concretas.
• Si hay cifrado DC-09, definir longitud de clave, método de carga, rotación, y asegurar sincronización horaria confiable.
• Parametrizar supervisión en ambos extremos: intervalo de heartbeat, ventana del receptor, reintentos y condición de trouble/fallback.
• Documentar el comportamiento de ACK/NAK y de fallback: quién retiene el kissoff, cuánto espera, y cuándo se conmuta a ruta secundaria.
• Incluir pruebas FAT/SAT con eventos reales: alarma, restore, trouble, pérdida de red, pérdida de energía, prueba periódica y retorno a servicio. Poner la cuenta “en test” antes de intervenir.
• Especificar, aparte del transporte, el cumplimiento funcional de CP-01 cuando el proyecto tenga sensibilidad por falsas alarmas o normativa local alineada con buenas prácticas.

En tendencias, la lectura más sólida de las fuentes revisadas es la siguiente. Primero, DC-09 sigue consolidándose como estándar IP abierto e interoperable para transmisión de alarmas, y la revisión 2026 va claramente en dirección de despliegue simplificado + seguridad reforzada. Segundo, el parque instalado mantiene vivo a Contact ID mediante captura de discador y comunicadores dual‑path. Tercero, la resiliencia se está desplazando hacia esquemas IP + celular, incluso con doble SIM y servidores redundantes en equipos comerciales.

Sobre MQTT, TLS y JSON, conviene ser riguroso. En arquitectura de integración moderna son tecnologías muy relevantes, pero no aparecen en las fuentes revisadas como sustituto estandarizado de DC-09 para el tramo central‑station. Lo razonable es tratarlas como capa de integración superior: MQTT como mensajería pub/sub liviana para IoT, JSON como formato de intercambio de datos, y TLS como mecanismo transversal de confidencialidad e integridad entre aplicaciones. Mi inferencia de proyecto es que son excelentes para puentes hacia nube, BMS, analítica, APIs y repositorios de eventos, pero no deben introducirse como reemplazo implícito de la señalización central sin una especificación formal adicional.

Fuentes

• Security Industry Association — DC-05-2016-DCS Ademco Contact ID Protocol
• Security Industry Association — SIA DC-09 2021
• Security Industry Association — DC-09-2026 Scope and Benefits
• Security Industry Association — comunicado de la revisión 2026 de DC-09
• Security Industry Association — ANSI/SIA CP-01-2019
• Security Industry Association — Request for Interpretation sobre CRC en DC-09
• Honeywell — Model 5104B Installation Manual
• Honeywell — CLSS Pathway Installation and Operation Manual
• Honeywell — 6700 Installation Manual
• Johnson Controls — SG-System IV Operating Manual
• Johnson Controls — documentación de comunicadores TL280LE y afines
• ABUS — Secvest Installer Manual v3.01.01
• Bosch Building Technologies — ficha técnica AMAX con soporte SIA DC09 UDP/TCP
• Digital Monitoring Products — guías CellCom con referencia a SIA DC-05-1999.09-DCS
• NIST — definición de TLS
• MQTT.org — definición oficial de MQTT
• JSON.org — introducción oficial a JSON