Retrive Problem

General
1

Hello,
I have configured the Orthanc PACS and it works without problems. I have also configured other DicomModalities so that I can query and obtain studies and save in my Orthanc PACS.
I can perform the query without problems and I obtain the list of exams, but when I click to obtain the study I receive an error as per the attached log.

I have configured 3 DicomModalities and with all of them I get the same error.
I should point out that I have already checked the firewall in case it blocked the port but this is not the problem because the ports are open.
What could be the problem?

Thanks.

I0517 18:01:22.456450 HTTP-0 HttpServer.cpp:1263] (http) POST /modalities/GEPACS1/move
I0517 18:01:22.457661 HTTP-0 JobsRegistry.cpp:805] New DicomMoveScu job submitted with priority 0: 5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:22.457767 JOBS-WORKER-1 JobsEngine.cpp:138] (jobs) Executing DicomMoveScu job with priority 0 in worker thread 1: 5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:22.457858 JOBS-WORKER-1 DicomAssociation.cpp:272] (dicom) Opening a DICOM SCU connection without DICOM TLS from AET “MH_PACS1” to AET “GEPACS1” on host 10.200.200.16:4100 (manufacturer: GE, timeout: 20s)
I0517 18:01:22.478021 HTTP-0 HttpServer.cpp:1263] (http) GET /jobs/5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:22.560930 DICOM-SERVER CommandDispatcher.cpp:334] (dicom) Association Received from AET GEPACS on IP 10.200.200.16
I0517 18:01:22.562576 DICOM-SERVER main.cpp:323] Incoming connection from AET GEPACS on IP 10.200.200.16, calling AET MH_PACS1
I0517 18:01:22.562704 DICOM-SERVER CommandDispatcher.cpp:675] (dicom) Association Acknowledged (Max Send PDV: 28660) to AET GEPACS on IP 10.200.200.16
I0517 18:01:22.903853 HTTP-0 HttpServer.cpp:1263] (http) GET /jobs/5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:23.526386 HTTP-0 HttpServer.cpp:1263] (http) GET /jobs/5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:24.313900 DICOM-6 CommandDispatcher.cpp:940] (dicom) Finishing association with AET GEPACS on IP 10.200.200.16: DUL Peer Requested Release
I0517 18:01:24.313930 DICOM-6 CommandDispatcher.cpp:948] (dicom) Association Release with AET GEPACS on IP 10.200.200.16
I0517 18:01:24.357372 HTTP-0 HttpServer.cpp:1263] (http) GET /jobs/5cf251d3-1da8-495c-8dd7-0b96991f6826
E0517 18:01:24.549550 JOBS-WORKER-1 OrthancException.cpp:62] Error in the network protocol: C-MOVE SCU to AET “GEPACS1” has failed with DIMSE status 0xA702
I0517 18:01:24.549662 JOBS-WORKER-1 DicomAssociation.cpp:112] (dicom) Closing DICOM association
I0517 18:01:24.550205 JOBS-WORKER-1 JobsRegistry.cpp:511] Job has completed with failure: 5cf251d3-1da8-495c-8dd7-0b96991f6826
I0517 18:01:25.458425 HTTP-7 HttpServer.cpp:1263] (http) GET /jobs/5cf251d3-1da8-495c-8dd7-0b96991f6826

2

Hi,

This error is generated by the GEPACS1, you should check logs from there.

Alain

3

I tried with another dicom node.
I have two servers with Orthanc on the network and I can’t retrieve on this server either so I assume that the problem is in the local node and not in the remote nodes.
I always get the same error.
I checked the log files but I can’t figure out where the problem could be

Attachment my LOG file with remote AET SMARTPACS, equal problem.

Orthanc.log.txt (67.0 KB)

4

Hello

What I would do in your situation is to launch another Orthanc on your network (not on the same machine) and check if you can perform query/retrieve against it from your main Orthanc.
At least, this will make it easier to troubleshoot if the same problem occurs.
Do not forget to use different AET for both Orthancs and configure them correctly.
While you’re at it, enable --trace-dicom on the 2nd Orthanc. too.

5

I have already installed a second server with orthanc and in all the cases I tried I can query but I can’t retrieve.

I can try to enable the --trace-dicom parameter, how do I enable this option?

Thanks.

6

Sorry for the confusion : you are already using trace mode. I did not know --trace (that you’re using) implies --trace-dicom . Apologies

First of all, note that query/retrieve requires both ends to know about each other. So Orthanc needs to be known by the PACS, and the other way round.

An incomplete configuration where Orthanc knows about the PACS but not the other way round would result in an error similar to what you experience (C-Find working, but C-Move failing)

If you hadn’t done that, give it a try and , if it still does not work, what I would suggest is for you to :

  • post both configuration files here, too (Orthanc A and B). Maybe there’s something special in there.
  • post both Orthanc SCU and SCP logs (keeping trace enabled) when performing the C-Find/C-Move.

Another option would be to try with DCMTK to check if there’s something weird on the network :

  • Try to query GEPACS/SMARTPACS with dcmtk
  • Try to query Orthanc with dcmtk

(As explained in the Orthanc Book, this is bi-directional and, in the case of DCMTK, this implies that the party running the Query/Retrieve must run both findscu and storescp)

7

Note: the reason why the connection is bidirectional is explained in the Orthanc Book

8

I tried it and it seems to work now.
I didn’t realize that both nodes had to be configured to see each other.

Thanks.

1 Like