Port 1733: SIIPAT — The Alarm That Never Rang

What This Port Is

Port 1733 sits in the registered port range (1024-49151), meaning the Internet Assigned Numbers Authority has given it an official assignment. The assigned service is SIIPAT: Security Industry Internet Protocol for Alarm Transmission, developed by Security Information & Management Systems, Inc. (SIMS).

It is assigned. It is not meaningfully used.

The Problem It Was Trying to Solve

In the mid-1990s, commercial alarm monitoring worked like this: your motion sensor trips, your alarm panel seizes your phone line, dials a long-distance number, waits for the monitoring center to answer, handshakes, then transmits a few bytes of data. The actual signal might take two seconds. The whole process — dialing, connecting, waiting — might take forty.

Large monitoring companies handled thousands of these calls every day. The phone bills were real. The inefficiency was real.

Steven M. Ryckman at SIMS saw the obvious answer: the Internet. If you could route alarm signals over TCP/IP, you'd eliminate the long-distance charges, reduce latency, and use infrastructure that was already paid for. Port 1733 was where those alarm signals would arrive.

How the Protocol Worked

SIIPAT used a simple client-server model:

1. The subscriber device (the alarm panel or its network-connected controller) opens a TCP connection to the monitoring center on port 1733
2. The server responds with a readiness message: 1RDY
3. The subscriber authenticates with an ID and password
4. The alarm signal transmits in a structured format with start/end markers and length fields
5. The server acknowledges with a response code — 1xxx for success, 3xxx for authentication failure, 4xxx for protocol errors, 8xxx for network errors

The protocol included encryption for the transmission, which was thoughtful for 1996. It also emphasized immediate acknowledgment — the monitoring center had to confirm receipt, so you'd know the signal actually arrived rather than vanishing into the network.

Why You've Never Heard of It

The IETF draft expired in 1997. The company behind it left no visible trace in the modern record. The alarm industry eventually did move to IP-based monitoring — but on different protocols, through different paths, with different players.¹

SIIPAT was correct about the problem. It was early enough that the Internet wasn't yet reliable enough for life-safety systems, and established enough that the incumbents (companies built around dial-up monitoring infrastructure) had little incentive to adopt it. The window between "technically possible" and "industrially practical" is where good ideas often die.

Port 1733 got its IANA registration and became a monument to a protocol that was right about the future but couldn't get there.

What's Actually Listening on Port 1733 Today

Almost certainly nothing related to SIIPAT. If you see traffic on this port, it's more likely to be:

• Port scanning (automated reconnaissance touching all registered ports)
• Misconfigured applications that picked an arbitrary port
• Custom internal software using an uncontested port number

To check what's listening on your system:

# macOS / Linux
sudo lsof -i :1733
sudo ss -tlnp | grep 1733

# Windows
netstat -ano | findstr :1733

If something is listening here and you don't know what it is, that's worth investigating.

The Registered Range

Port 1733's range — 1024 to 49151 — is where the port system gets interesting. Below 1024, ports are "well-known": HTTP on 80, SSH on 22, DNS on 53. These require root/administrator privileges to bind on most systems, which signals their seriousness.

Registered ports (1024-49151) are more like reservations at a restaurant that may or may not show up for their booking. IANA takes the request, assigns the port, and that's largely where the story ends. No one enforces the assignment. No one verifies the protocol shipped. Port 1733 proves the point.