Crestron Control (CIP / SCIP)
`CIP` is Crestron's proprietary IP control plane for processor-to-endpoint command, feedback, join, and session traffic inside a Crestron system. In practical AV work it is the native messaging path between a Crestron control processor or `VC-4` room and Crestron touch interfaces, control apps, software clients, and other Crestron Ethernet devices. The important firewall and design point is simple: plain `CIP` on `41794` is the legacy insecure path; on any shared or security-reviewed network, the right baseline is `SCIP` on `41796`, with the rest of the room-control web stack treated separately rather than lazily bundled under the word "`CIP`." Current Crestron terminology guidance also says that when `TLS` / `SSL` is used, the plain `41794` path is disabled so `SCIP` is used instead.
other
Network Ports & Requirements
| Port(s) | Transport | Direction | Purpose | DSCP | Multicast | Config. |
|---|---|---|---|---|---|---|
| 41794 | TCP | Both | Plain `CIP` control session between a Crestron control processor / `VC-4` room and a Crestron-native endpoint. Carries the insecure legacy/default control-and-feedback path and may be disabled when secure `CIP` is enabled. | — | — | Yes |
| 41794 | UDP | Both | Crestron `CIP` exposure where the specific Crestron platform / workflow documents `41794` as `UDP` as well as `TCP`; current Crestron network-planning and `VC-4` server-port documentation list this, and IANA registers `crestron-cip` on both transports. Do not add it to every schedule automatically if the actual app/control path documents `TCP` only. | — | — | Yes |
| 41796 | TCP | Both | Secure `CIP` (`SCIP`). Same control role as plain `CIP`, but wrapped in `TLS`. This is the preferred path on shared networks, remote-access designs, and any project likely to face IT review. | — | — | Yes |
| 2221 | EtherNet/IP | Both | Industrial `Common Industrial Protocol` / EtherNet/IP services are a separate OT scope. IANA registers secure EtherNet/IP on `2221`, EtherNet/IP I/O on `2222`, and EtherNet/IP messaging on `44818`; these do not substitute for Crestron `41794` / `41796`. | — | — | No |
| 2222 | EtherNet/IP | Both | Industrial `Common Industrial Protocol` / EtherNet/IP services are a separate OT scope. IANA registers secure EtherNet/IP on `2221`, EtherNet/IP I/O on `2222`, and EtherNet/IP messaging on `44818`; these do not substitute for Crestron `41794` / `41796`. | — | — | No |
| 44818 | EtherNet/IP | Both | Industrial `Common Industrial Protocol` / EtherNet/IP services are a separate OT scope. IANA registers secure EtherNet/IP on `2221`, EtherNet/IP I/O on `2222`, and EtherNet/IP messaging on `44818`; these do not substitute for Crestron `41794` / `41796`. | — | — | No |
Gotchas & IT Notes
- ⚠**Do not write "`open CIP`" and stop there.** State whether the design requires plain `41794`, secure `41796`, or both. Most modern projects should be engineered around `41796` unless there is a hard legacy constraint.
- ⚠State the transport as well as the number. `TCP 41794` is common in endpoint/app documentation, but `UDP 41794` appears in current Crestron network-planning / server-port context and in IANA. A firewall rule that says only "`CIP`" is underspecified.
- ⚠When `TLS` is enabled on the endpoint, current Crestron terminology guidance says plain `41794` is disabled so `SCIP` is used instead. Do not assume secure deployments keep insecure `CIP` alive as a fallback.
- ⚠Crestron's own current port-forwarding guidance says to expose only the secure `CIP` port plus `HTTPS` when mobile apps or `XPanel`-style workflows are used externally. Plain `41794` is the weak answer for internet-facing designs.
- ⚠`VC-4` and hardware control processors are related but not identical firewall conversations. Current `VC-4` documentation also lists adjacent services such as secure `HTML5 Web XPanel` on `49200`; do not mislabel those as "`CIP`."
- ⚠`IP ID`, `IP table`, and `Room ID` mistakes still cause more failures than firewall blocks. If the port is open but the binding is wrong, the system is still dead.
- ⚠Some endpoints allow multiple `IP table` entries, but that is not a free pass to design an unowned multi-master room. Control ownership and registration still need to be explicit.
- ⚠`CIP` is a Crestron-native control protocol, not a third-party API strategy. If the design includes non-Crestron displays, DSPs, cameras, or lighting systems, document their real control transport separately.
- ⚠On supported processors, the Crestron `Control Subnet` is for Crestron / Crestron Connected devices, not a generic device island. Current Crestron guidance says it is `DHCP`-only and warns against connecting third-party devices or another `DHCP` server.
- ⚠In mixed `AV` / `OT` environments, label it clearly as **Crestron `CIP`** to avoid confusion with the industrial `Common Industrial Protocol`.
- ⚠Crestron recommends isolating Crestron devices from unrelated traffic because control response and feedback are latency-sensitive and heartbeat-dependent. Use that as a VLAN / routing / ACL design requirement, not as an excuse for undocumented flat networks.
- ⚠Do not copy the `CIP` rows into an industrial-controls firewall schedule. ODVA Common Industrial Protocol normally arrives in AV-adjacent projects through the building/OT side, most visibly via EtherNet/IP workflows, and it has different governance, conformance, object model, security assumptions, and port/service behavior than Crestron room control.
- ⚠If the scope means ODVA `Common Industrial Protocol`, schedule the actual network adaptation instead. For EtherNet/IP, current IANA data registers `EtherNet/IP I/O` on `2222` and `EtherNet/IP messaging` on `44818` for both `TCP` and `UDP`; that is not interchangeable with Crestron `41794` / `41796`.
- ⚠If the OT scope requires secure EtherNet/IP, treat that as ODVA / controls-engineering territory as well. Current IANA data registers `ethernet-ip-s` on `2221` for `TCP` / `TLS` and `UDP` / `DTLS`; ODVA's CIP Security material ties those secure transports to EtherNet/IP device protection, not to Crestron `SCIP`.
- ⚠Treat `49200` as adjacent `HTML5 Web XPanel` / secure WebSocket infrastructure, not as `CIP` itself. If a room UI needs browser/app control plus native Crestron control, schedule both paths deliberately.
- ⚠Current IANA data registers `crestron-cip` on `41794` for both `TCP` and `UDP`, and `crestron-cips` on `41796` for `TCP` only; `UDP 41796` is reserved, not a secure-CIP service row to add by habit.
- ⚠Crestron control-system configuration pages expose `CIP` and `SCIP` as configurable port settings. Use the installed values from the control system / virtual-control server / app deployment, not just copied defaults, when the project has changed them.
- ⚠A port-open test is not a working-room test. Acceptance should prove the actual `CIP` / `SCIP` registration and control path: endpoint online state in the program, correct `IP ID` / `IP table` / room binding, command and feedback in both directions, recovery after endpoint reboot, recovery after control-engine reboot, and the intended secure/plain mode. If the same acronym is being used for ODVA `Common Industrial Protocol`, stop and produce a separate EtherNet/IP / OT firewall and commissioning schedule; those ports, roles, security assumptions, and ownership boundaries are not Crestron room-control assumptions.
- ⚠Scan the actual loaded program, not just the processor baseline. Crestron's current network-planning guidance notes that user programs can add listeners and recommends a security scan before and after program loading. That matters on real jobs: a documented `CIP` / `SCIP` path can coexist with custom TCP/UDP services created by the program, and those custom listeners need their own ownership, firewall, and security decision.
- ⚠2026-06-03 verification found no port-boundary change in current Crestron, IANA, or ODVA sources. The added tightening is only the acronym-collision side: `SCIP` on `41796` is Crestron secure control; ODVA `CIP Security` / secure EtherNet/IP uses a different industrial protocol stack and IANA service rows. Write the expanded name in every mixed AV / OT firewall schedule.
- ⚠2026-06-08 verification found no port-boundary change in current Crestron, IANA, or ODVA sources. IANA CSV fetched on `2026-06-08` still lists `crestron-cip` as `41794` `TCP/UDP`, `crestron-cips` as `41796` `TCP`, secure EtherNet/IP as `2221` `TCP/UDP`, EtherNet/IP I/O as `2222` `TCP/UDP`, and EtherNet/IP messaging as `44818` `TCP/UDP`; the CSV HTTP header still showed `Last-Modified: Sat, 30 May 2026 01:11:26 GMT`. Do not merge these into one "CIP" firewall line. Crestron `SCIP` and ODVA `CIP Security` are unrelated secure-control stories with different owners, devices, ports, certificates, and commissioning evidence.
- ⚠2026-06-13 verification found no port-boundary change in current Crestron, IANA, or ODVA sources. IANA CSV fetched on `2026-06-13` lists `crestron-cip` as `41794` `TCP/UDP`, `crestron-cips` as `41796` `TCP`, `UDP 41796` as reserved, secure EtherNet/IP as `2221` `TCP/UDP`, EtherNet/IP I/O as `2222` `TCP/UDP`, and EtherNet/IP messaging as `44818` `TCP/UDP`; the CSV HTTP header showed `Last-Modified: Fri, 12 Jun 2026 22:41:24 GMT`. Keep the port schedule split into three different scopes: Crestron plain `CIP`, Crestron secure `SCIP`, and ODVA / EtherNet/IP industrial automation. A firewall line that says only "`CIP`" is not technically acceptable.
- ⚠2026-06-18 verification found no port-boundary change in current Crestron, IANA, or ODVA sources. IANA CSV fetched on `2026-06-18` lists `crestron-cip` as `41794` `TCP/UDP`, `crestron-cips` as `41796` `TCP`, secure EtherNet/IP as `2221` `TCP/UDP`, EtherNet/IP I/O as `2222` `TCP/UDP`, and EtherNet/IP messaging as `44818` `TCP/UDP`; the CSV HTTP header showed `Last-Modified: Wed, 17 Jun 2026 17:11:30 GMT`. The operational rule is still to split the schedule by expanded protocol name: Crestron `CIP` / `SCIP` for Crestron control-engine registration and command/feedback, ODVA Common Industrial Protocol / EtherNet/IP for OT scanner/adapter messaging, and separate web/UI/custom-listener paths where the program or platform creates them.