C-ECHOthe DICOM ping, and what it really tests

C-ECHO is the first thing to try when two DICOM devices will not talk. It is more than a network ping: a successful echo proves the network path, the AE titles and the DICOM software on the other side, all in one go.

  • DICOM
  • Network (TCP)
  • Dashed = reply
DICOM C-ECHO sequenceThe SCU opens an association proposing the Verification SOP Class, the SCP accepts, the SCU sends C-ECHO-RQ, the SCP replies C-ECHO-RSP with status 0000, and the association is released.SenderSCU, e.g. a PACS admin toolTarget nodeSCP, e.g. a modalityTCP connect1A-ASSOCIATE-RQ (Verification)2A-ASSOCIATE-AC3C-ECHO-RQ4C-ECHO-RSP (status 0000)5A-RELEASE-RQ / RP6

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 6

TCP connection

Core step

What happens

The sender opens a TCP connection to the target IP address and port.

Why it is needed

This is the first thing a C-ECHO checks. "Connection refused" or a timeout means a wrong port, a firewall, a stopped service or a routing problem.

Technical details

  • Connection refused: host is up, nothing listens on that port
  • Timeout: usually a firewall or a wrong IP address
  • Tip: test the port first with a plain TCP check

All steps at a glance

Glossary

AE / AE title
Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
SCU
Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP
Service Class Provider. The side that provides the service, such as a PACS that stores images.
SOP Class
Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Association
A negotiated DICOM connection between two AEs, set up on top of a TCP connection. All DIMSE messages travel inside one.
Status
A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.

Summary

  • C-ECHO uses the Verification SOP Class 1.2.840.10008.1.1 and carries no data set. PS3.2 requires every DIMSE implementation that accepts associations to accept it as SCP, so it should always be there.
  • A successful echo proves: TCP path, AE titles accepted, DICOM service answering. It does not prove that CT, MR or any other SOP Class is accepted.
  • To test a real workflow, send a small test image (C-STORE) or run a C-FIND after the echo succeeds.
  • Failures map to layers: connection refused or timeout = network; A-ASSOCIATE-RJ = AE title, access list or limits; echo works but store fails = SOP Class or transfer syntax.
  • C-ECHO is symmetrical in practice: test both directions, because each side keeps its own list of known AE titles.

The 6 steps in plain text

  1. TCP connection

    The sender opens a TCP connection to the target IP address and port.

    Why: This is the first thing a C-ECHO checks. "Connection refused" or a timeout means a wrong port, a firewall, a stopped service or a routing problem.

  2. A-ASSOCIATE-RQ with the Verification SOP Class

    The sender proposes a single presentation context: the Verification SOP Class with the default transfer syntax. It sends its own AE title as Calling AE and the target AE title it was told to use as Called AE.

    Why: This is where the AE titles are checked for the first time. Most real-life C-ECHO failures are a wrong or missing AE title in the target configuration.

  3. A-ASSOCIATE-AC: the target accepts

    The target accepts the association and the Verification context. If it does not know the sender or the AE titles do not match, it sends an A-ASSOCIATE-RJ instead.

    Why: An accepted association already shows that the DICOM software is running and the AE titles line up. Many devices only talk to senders that are registered in their configuration, so a rejection here usually means "add this AE title on the target".

  4. C-ECHO-RQ

    The sender sends the C-ECHO request. It is a command only: there is no data set, no patient and no image.

    Why: This confirms that the target's DICOM service handles requests, not only that it opens connections.

  5. C-ECHO-RSP with status 0000

    The target answers with status 0000 (success). The echo has worked.

    Why: The sender now knows the whole path works. It does not know whether other SOP Classes will work, because only Verification was negotiated.

  6. A-RELEASE

    The sender releases the association. The target confirms with A-RELEASE-RP.

    Why: The echo is short-lived. Closing it keeps the target free for real work.

Common questions

What does a successful C-ECHO prove?

That the network path and port are open, that the target knows the sender (AE title and often IP address) and that its DICOM service answers a DIMSE request. It does not prove that any storage, query or worklist SOP Class is supported.

C-ECHO works, but my images are not accepted. Why?

C-ECHO only negotiates the Verification SOP Class. A C-STORE needs a presentation context for each image SOP Class, in a transfer syntax the target accepts. Look at the A-ASSOCIATE-AC of the failing store: result 3 or 4 on a context names the cause. Also check the target conformance statement for the SOP Classes it accepts as SCP.

Why does the echo work from one device but not from another?

Many DICOM nodes keep an access list of AE titles (and sometimes IP addresses) they accept. A new device must be registered on the target, and the target must be registered on the sender if the sender also receives.

Can a DICOM device refuse C-ECHO?

It can reject an unknown caller like any other association, but it may not leave out the Verification SOP Class. PS3.2 (section 7.1.1) says an implementation that accepts any DICOM association request shall accept a Presentation Context for the Verification SOP Class as SCP.

Is C-ECHO the same as ping?

No. Ping (ICMP) only tests that the host answers at network level and is often blocked. C-ECHO tests TCP on the DICOM port and the DICOM application, which is what actually matters.

Which C-ECHO status codes exist?

In practice 0000 (success). A node that cannot process the request may answer with a failure status such as 0110 (processing failure) or 0211 (unrecognized operation). Most problems appear earlier, as a TCP error or an A-ASSOCIATE-RJ.

Try it yourself

  • Dicommunication: send a C-ECHO and test DICOM connectivity between your PACS and other nodes.
  • DICOM Tag Compare: compare the tags of two DICOM dumps, such as StudyInstanceUID (0020,000D) and AccessionNumber (0008,0050).

← All lessons