Could someone verify whether a Slicer DICOM storage listener should respond to a C-ECHO request? When I try, I do not get a response, instead it immediately aborts (A-ABORT with Abort Source: service-user).
# Minimal C-ECHO test
from pynetdicom import AE, debug_logger
debug_logger() # make logging messages verbose
storage_addr = "127.0.0.1" # localhost
storage_port = 11112 # port slicer dicom storage listener is on
ae = AE()
ae.add_requested_context("1.2.840.10008.1.1") # echo verification context
assoc = ae.associate(storage_addr, storage_port)
if assoc.is_established:
print('Association successful')
status = assoc.send_c_echo()
assoc.release()
else:
print('Association failed!')
In various guides around the internet, getting a successful C-ECHO response is the first step in troubleshooting because the requirements are minimal (e.g. no search parameters, just a successfully open communication channel), so I expected this to work. In this case, the successful association suggests that the communication channel is open, but the C-ECHO request somehow triggers the connection aborting. There is an idle network timeout which can also trigger a connection abort, but this happens much faster than that 60 second timeout.
For background, I am working with @ezgimercan and our hospital networking team to get DICOM networking communication from Slicer working. Configuration has proceeded to the point that we are able to successfully query the clinical PACS, but retrieval fails (we get a “Success” message, but 0 images/files are transferred). I am trying to figure out exactly where the breakdown is occurring. Using pynetdicom and verbose logging, I can see that association is successful, but sub-operations are failing.
Also, for reference, the same code above with the remote PACS IP address and port works returns a success status to the send_c_echo() call and does not abort. Using an incorrect IP address yields a TCP connection error (as expected), and using an incorrect port yields a TCP connection actively refused error (as expected). Both of those results are distinct from the results for the local Slicer storage listener (and for the clinical PACS).
I would appreciate any help or suggestions anyone can offer.
Following the very helpful troubleshooting guide at Troubleshooting Query/Retrieve SCU **Start Here** · Issue #419 · pydicom/pynetdicom · GitHub, one of the steps is to verify that connecting to the storage provider (SCP), the one running from Slicer, is working. The simplest check is to send a C-ECHO and make sure that it responds. However, when I try this, the communication aborts (A-ABORT with Abort Source: service-user). This seems very odd to me because there are no errors shown in the association process (Verification SOP Class is accepted), only when the C-ECHO is sent. Also, to be clear, the listener I am testing here is the Slicer DICOM storage listener, not the clinical PACS; there is no communication off of the local machine in this test.
The full verbose log of the association, request, and abort from running the code above in Slicer’s python interactor:
