Network
DICOM Protocol
DICOM is a layered network protocol. Physical/TCP is at the bottom, DUL (DICOM Upper Layer) framing sits above it, DIMSE (DICOM Message Service Element) primitives ride on DUL, and everything gets negotiated up-front by A-ASSOCIATE. Understanding the layers makes tcpdump output readable and turns most "it won't connect" tickets into five-minute fixes.
The stack
| Layer | Role | Defined in |
|---|---|---|
| TCP/IP | Transport; default port is 104 (IANA-registered) but 11112 is far more common in practice | PS3.8 |
| DICOM Upper Layer (DUL) | Frames byte streams into PDUs — A-ASSOCIATE-RQ, P-DATA-TF, A-RELEASE-RQ, A-ABORT | PS3.8 |
| DIMSE-C / DIMSE-N | Service primitives — C-STORE, C-FIND, C-MOVE, N-CREATE, N-SET, N-EVENT-REPORT | PS3.7 |
| Service Classes | Contracts that group primitives — Storage SCU/SCP, Q/R SCU/SCP, Modality Worklist, MPPS | PS3.4 |
Port 104 vs 11112: 104 is privileged (< 1024) so every vendor defaults to 11112 or 4242 or a vendor-specific port to avoid running as root. Always check the destination AE's configured port — assuming 104 is a 10-minute debugging detour.
A-ASSOCIATE — the handshake
Every DICOM session begins with an A-ASSOCIATE exchange. The SCU (Service Class User — the requester) sends an A-ASSOCIATE-RQ listing:
- Its AE Title (Application Entity Title — a 16-character identifier)
- The destination AE Title it wants to talk to
- A list of Presentation Contexts — each a (SOP Class UID, list of Transfer Syntax UIDs) tuple
- User Identity (optional — kerberos, JWT, basic)
- Maximum PDU length
The SCP (Service Class Provider) replies with A-ASSOCIATE-AC, either accepting or rejecting each Presentation Context. If even one presentation context is accepted, the association is up. If none are accepted, the SCP sends A-ASSOCIATE-RJ and the session dies.
Presentation Contexts — where interoperability lives and dies
A Presentation Context answers: "for SOP Class X, what transfer syntax can we use?" An SCP can accept only one transfer syntax per Presentation Context. If the SCU offers CT Image Storage with (Explicit VR Little Endian, JPEG 2000 Lossless) and the SCP accepts only Explicit VR LE, every future CT image on this association must be encoded that way. This is where "device A and device B both support DICOM but can't talk" comes from — their Presentation Context lists don't overlap.
See the full list: 320 SOP classes · 63 transfer syntaxes
P-DATA-TF — the actual message carrier
Once associated, both sides exchange P-DATA-TF PDUs. Each carries a Command Set (DIMSE command) and optionally a Data Set. The Command Set says "this is a C-STORE-RQ for SOP Instance UID X with Priority Medium"; the Data Set carries the actual DICOM object. Large objects get fragmented across multiple P-DATA-TF PDUs respecting the negotiated Maximum PDU length.
A-RELEASE and A-ABORT
Graceful termination uses A-RELEASE-RQ / A-RELEASE-RP. Both sides must agree. A-ABORT is unilateral — either side can yank the association with an A-ABORT PDU carrying a reason code. Common reasons: protocol error (0x01), unrecognized PDU (0x02), DIMSE failure (0x04). If you're debugging and seeing A-ABORT instead of A-RELEASE-RQ, your client is violating the protocol somewhere.
DICOMweb — DICOM over HTTP
For web-based access, DICOMweb (PS3.18) exposes three REST-style services:
- WADO-RS — retrieve studies, series, instances, frames over HTTP GET
- QIDO-RS — query for studies matching criteria over HTTP GET
- STOW-RS — store studies via HTTP POST (multipart/related)
DICOMweb doesn't replace DIMSE — most enterprise deployments run both. DIMSE for device-to-PACS bulk transfer; DICOMweb for browser viewers, FHIR servers, and cloud bridges.