DICOM C-ECHO: Verification and connectivity testing

When network engineers test connectivity between two servers, they typically run an ICMP ping or inspect a TCP handshake. If packets flow and the port answers, the connection is considered healthy.

In medical imaging, that assumption regularly breaks. A hospital scanner can establish a TCP socket to an archive, yet every imaging transfer still fails. DICOM operates as a stateful, application-layer protocol with its own rules for identity, capability negotiation, and security.

To confirm that two medical imaging systems can actually communicate, the standard defines DICOM C-ECHO, formally known as the Verification SOP Class. It acts as an application-level ping: confirming routing, security handshakes, and identity negotiation without transmitting patient data.

Why ICMP ping and TCP checks are not enough

In general enterprise IT, network tests work against lower layers of the OSI stack:

• ICMP ping verifies Layer 3 IP routing. It confirms that the destination host is powered on and that routers can deliver packets. However, hospital firewalls often drop ICMP traffic entirely.
• TCP port checks verify Layer 4 socket reachability. Tools like nc or telnet prove that a process is listening on the standard DICOM port (typically port 104 for unencrypted traffic or port 11112 for encrypted sessions).

Neither check tells you whether a medical imaging transfer will succeed. A DICOM receiver can accept a TCP connection and immediately reject the transfer for several application-level reasons:

1. Unrecognized AE titles: The destination may not authorize the sender’s identifier.
2. Transfer syntax mismatch: The systems may disagree on byte ordering or image compression.
3. TLS or certificate validation failure: The client certificate may be expired, untrusted, or missing.
4. Service denial: The receiver may support image storage (C-STORE) but refuse requests during maintenance windows.

A successful network connection only proves that the wires work. DICOM C-ECHO proves that the software applications on both ends understand and trust each other.

How the Verification SOP Class works

The DICOM standard defines C-ECHO in PS3.4 Annex A under the Verification SOP Class, identified by the standard Unique Identifier (UID):

1.2.840.10008.1.1

Unlike storage or query services, the Verification SOP Class has no corresponding Information Object Definition (IOD). It does not transfer image headers, pixel data, or study records. It is a pure protocol probe.

The two roles: SCU and SCP

DICOM assigns distinct roles to the systems participating in any exchange:

• Service Class User (SCU): The client that initiates the network request. When an engineer tests a connection from a modality or laptop, that tool acts as the Verification SCU.
• Service Class Provider (SCP): The server listening for incoming connections that processes and answers the request. The hospital PACS, archive, or cloud gateway acts as the Verification SCP.

The lifecycle of a C-ECHO exchange

A C-ECHO exchange follows three sequential phases over a single TCP connection:

sequenceDiagram
    autonumber
    participant SCU as DICOM Client (SCU)
    participant SCP as DICOM Server (SCP)
    
    Note over SCU,SCP: Phase 1: Association Negotiation
    SCU->>SCP: A-ASSOCIATE-RQ (Calling AE, Called AE, Verification SOP Class)
    SCP-->>SCU: A-ASSOCIATE-AC (Accepted)
    
    Note over SCU,SCP: Phase 2: DIMSE Verification
    SCU->>SCP: C-ECHO-RQ (Message ID: 1)
    SCP-->>SCU: C-ECHO-RSP (Status: 0000H Success)
    
    Note over SCU,SCP: Phase 3: Association Release
    SCU->>SCP: A-RELEASE-RQ
    SCP-->>SCU: A-RELEASE-RP (Connection Closed)

1. Association negotiation: The SCU opens a TCP connection (or completes a TLS handshake) and transmits an A-ASSOCIATE-RQ packet. This packet contains the Calling AE title (the client identity), the Called AE title (the target service), and a list of proposed presentation contexts. For verification, the presentation context proposes the Verification SOP Class UID (1.2.840.10008.1.1) paired with one or more transfer syntaxes, such as Implicit VR Little Endian or Explicit VR Little Endian. To learn how transfer syntaxes control byte ordering, read our guide on DICOM SOP Classes and Transfer Syntaxes explained.
2. Association acceptance: The SCP inspects the requested Called AE title and verifies the Calling AE title against its configuration. If the identities and presentation contexts are valid, the SCP responds with A-ASSOCIATE-AC. At this point, the DICOM association is established.
3. DIMSE exchange: The SCU sends a DICOM Message Service Element command: C-ECHO-RQ (Command Field 0030H). Because verification carries no patient attributes, the Command Data Set Type is set to 0101H, indicating that no dataset follows. The SCP evaluates the request and returns C-ECHO-RSP (Command Field 8030H) with a Status Code of 0000H (Success).
4. Association release: The SCU sends an A-RELEASE-RQ packet. The SCP acknowledges with A-RELEASE-RP, and the underlying TCP connection closes cleanly.

The entire exchange typically takes tens of milliseconds. Because zero clinical bytes change hands, C-ECHO introduces no storage footprint, leaves no orphaned records, and creates no compliance exposure under HIPAA or GDPR.

Testing connectivity with echoscu

Engineers test and troubleshoot DICOM connections from the command line using open-source toolkits. The most widely used tool is echoscu, part of the OFFIS DCMTK suite.

Basic unencrypted test

To send a basic verification request to a local PACS listening on port 104:

echoscu -v \
  -aet MY_MODALITY \
  -aec PACS_ARCHIVE \
  pacs.hospital.internal 104

In this command:

• -v: Enables verbose output to print each association step.
• -aet MY_MODALITY: Sets the Calling AE title (up to 16 characters).
• -aec PACS_ARCHIVE: Sets the Called AE title of the remote service.
• pacs.hospital.internal 104: The target hostname and TCP port.

If the exchange succeeds, DCMTK displays:

I: Requesting Association
I: Association Accepted (Max Send PDV: 16372)
I: Sending Echo Request (MsgID 1)
I: Received Echo Response (Success)
I: Releasing Association

Encrypted test over mutual TLS

When medical imaging travels across the internet, connections must use mutual TLS (mTLS) to encrypt the stream and verify identities with x509 certificates. For an in-depth review of certificates in healthcare networking, see our guide on mutual TLS for DICOM connections.

With DCMTK, you test an encrypted endpoint on port 11112 by supplying your client private key, client certificate, and trusted Certificate Authority (CA) bundle:

echoscu -v \
  -aet MY_GATEWAY \
  -aec DICOMLY \
  +tls client.key client.crt \
  +cf ca-bundle.crt \
  gateway.example.com 11112

In this mode, echoscu validates the server certificate before initiating the DICOM association. If the TLS handshake fails, the tool stops immediately, pinpointing certificate problems before any DICOM packets are sent.

Interpreting errors and failure modes

When C-ECHO fails, the error message indicates exactly which layer of the connection broke down.

Diagnosing association rejections (A-ASSOCIATE-RJ)

The most common DICOM error is an association rejection. When an SCP rejects an association, its A-ASSOCIATE-RJ packet includes three diagnostic fields:

• Result: Indicates whether the rejection is permanent (1) or transient (2).
• Source: Identifies which layer rejected the call (Service-User, Service-Provider ACSE, or Service-Provider Presentation).
• Reason/Diagnostic: Explains the cause.

In practice, over 90% of rejections stem from AE title misconfigurations:

• Called AE title not recognized: The client connected to the right IP and port, but asked for an AE title the server does not host. This frequently happens when an AE title has an accidental typo, an incorrect case, or trailing spaces. Learn how character formatting impacts negotiation in what is a DICOM Application Entity (AE) title?.
• Calling AE title not recognized: The server requires pre-configured client allowlists. The incoming connection presented an unrecognized calling identifier, and the server rejected it.

C-ECHO as an automated health check

Because C-ECHO executes in milliseconds without touching storage or modifying PACS records, it serves as the standard operational health check for healthcare infrastructure.

1. Pre-flight verification: Modalities run a C-ECHO check before transmitting a large CT or MRI study. If the destination is unreachable, the scanner retains the study in its local queue rather than failing mid-transfer.
2. Synthetic uptime monitoring: Infrastructure monitoring agents run scheduled C-ECHO queries every minute to track archive availability, network latency, and TLS certificate expiration.
3. Deployment verification: When provisioning new network routes or cloud endpoints, running C-ECHO verifies firewall traversal, DNS resolution, and reciprocal AE title configuration within seconds.

For cloud ingestion architectures that deliver imaging directly to HTTPS webhooks via DICOMweb STOW-RS, C-ECHO provides immediate feedback. Senders can verify their mTLS certificates and association parameters against cloud endpoints using native modality tools before streaming clinical studies. For a deeper look at modern ingestion workflows, explore receiving DICOM from a hospital over the internet.