Query/Retrieve Not Pulling Anything

Google Groups archive
1

Hello Everyone,

I am trying to setup an Orthanc server to be able to pull studies from a remote AE. I went through the FAQ multiple times, and the troubleshooting guide that comes with it, and am fairly certain everything is configured correctly.

I have the remote modality configured and echoing in Orthanc. When I go to “Search Studies”, I can see the Query/Retrieve association on the remote modality but nothing is populating the list, no matter how much I pinpoint the search. I am 100% certain I have the remote modality correctly configured on the other end as well, as I have attempted this on multiple servers.

Does it make any difference if these are MG modalities?

I attached the two logs in which I am seeing but this is repeatable on multiple remote servers.

json.txt (20.4 KB)

LOG.txt (17.2 KB)

2

Hi,

I’ve seen a similar problem that turned out to be a firewall problem.

I see you’re using port 105 for orthanc but the other servers you configured are on 104.
So they might send a reply to the wrong port.
So check your firewalls and make sure all connections use the same port (unsless you have a good reason not to)

Kind regards,
N

3

Windows Firewall is OFF on both DICOM servers. I already have a PACS server listening on port 104 so I installed Orthanc on 105.

4

Hello,

MG images are supported by Orthanc. You might want to set configuration option “UnknownSopClassAccepted” to "true.

If you want support from us, please share your full logs (the DCMTK log is truncated, we don’t know the invoked command from the client computer, and you haven’t provided the full Orthanc logs in “–verbose” mode):
https://book.orthanc-server.com/faq/log.html

Please also provide sample DICOM files (possibly anonymized) together with a minimal working example for us to reproduce your issue:
https://en.wikipedia.org/wiki/Minimal_working_example

Regards,
Sébastien-

5

Hi Sebastien,

It seems I have some similar problem that reported by ONsite Mammography

It’s really strange,
I have no problem making Queries, I got the correct answer.

Then on the retrieve API I have a strange bug that do not happen for all DICOM aets.

When I call the retrieve API “/queries/” + queryID + “/answers/” + answer + “/retrieve/”
I recieve an immediate answer
{ “Description” : “REST API”, “LocalAet” : “KANOUNIX”, “Query” : [ { “0008,0050” : “***", “0008,0052” : “STUDY”, “0010,0020” : “*******”, “0020,000d” : "” } ], “RemoteAet” : “AWS31”}

But nothing is really pulled, the answer comes immediatly.
Then of course when I search for the studyInstanceUID that have should be pulled, it is not existing in Orthanc.

On Orthanc side log I got no error : Driving C-Move SCU on remote modality AWS31 to target modality KANOUNIX (that’s all I get).

In my environement I failed for AwServer but I have kind of a similar issue for another colleague with her pacs (while she also have an AwServer but which working well for her).

I’m stuck I don’t see what is happening.
It is not a firewall issue when I push studies from AWServer to Orthanc it is fine.

I tried to downgrade (I thought it was working with older version but i’m not sure anymore). I see a difference of output, 1.3.0 return me empty json {} while 1.5.7 return me the JSON I put just before

By the way, after a retrieve API call why not retruning the Orthanc Studies / Series ID of the stored DICOM like the anonymize/ Import API ? What should be the expected reason format ?

Do you have any clue what testing I should do ?

6

Hello,

Visibly, the remote PACS “KANOUNIX” does not properly interpret the request from Orthanc.

Maybe it expects additional DICOM tags when it acts as a C-MOVE SCP?

In either case, it is impossible for us to debug such an issue. You should carefully read the log from “KANOUNIX”.

HTH,
Sébastien-

7

Dear Sebastien,

The "kanounix" AET is orthanc itself, the remote AET is AWS31

In short, I make queries on AWS31, I get proper queries answers no problem.
Then when I call retrieve API to move dicom from AWS31 to Orthanc (my orthanc aet is named kanounix) then I got this immidiate answer but nothing is really stored in orthanc. It sounds the c move fails but orthanc dont notice it.

The problem is that AWS server logs are horrible to read, I always failed to find interesting information in it.
In Dijon my colleague has the same problem on her GE pacs, but she also has an AWS server which do not suffer from this problem (I'm just stuck...)

Salim

8

Hello,

If I correctly understand your setup, you have a local Orthanc server that is connected to a remote Orthanc server running on AWS cloud using the DICOM protocol.

The DICOM protocol is focused on the Intranet, and should not be used over Internet for security reasons (no TLS encryption in Orthanc). Your transmission most probably fails either because your local Orthanc is attributed with a dynamic IP address that might change over time, or because some firewall blocks the DICOM communications.

In such a situation, please use either the Orthanc peers, the Orthanc transfers accelerator plugin, or the DICOMweb protocol, that are all built on the top of HTTP/HTTPS:
https://book.orthanc-server.com/faq/features.html#peers

https://book.orthanc-server.com/plugins/transfers.html

https://book.orthanc-server.com/plugins/dicomweb.html

HTH,
Sébastien-

9

Dear Sebastien,

No I have a very common local network,
I have one local orthanc (AET Name= KANOUNIX) that is directly accessing a local AWS (AET Name = AWS31) using the DICOM protocol. (everything in the same LAN)

So to retrieve I pick up the answer number I want, and call /retrieve API with my Orthanc AET “KANOUNIX” as POST parameter.

Am i wrong on my retrieve call ? (the same code is working properly with I call another AET I have in my departement)

Best regards,

Salim

10

Hello,

I don’t understand: Do you mean that you have two instances of Orthanc running on the same Amazon AWS virtual machine?

If you have two instances of Orthanc running on two different Amazon AWS virtual machines, and even if they are on the same LAN, the AWS firewall might block DICOM requests.

S-

11

Dear Sebastien,

I think you are confused by the AET name, “AWS31” is our AET Name for our AW Server provided by GE vendor (it’s the viewer of GE that is named AW Server). There is nothing related to Amazon, it is just a GE DICOM AET like any other DICOM node.
I’m on the same LAN, with two physical DICOM nodes.

I see that you are more convinced in a network issue, I’m going to continue to search in this side.

Best regards,

Salim

12

Sorry, I have been totally confused with the “AWS” wording… I indeed thought you were referring to Amazon, not GE.

Forget my previous answers, I’ll have another look to your question when time

13

No problem,

Small question, when I “push” a study from AWServer to Orthanc, the dicom are properly stored in Orthanc.
Does this fact clear me from network / firewall issues ?
I guess the DICOM comes through the same dicom port that the C move should get dicom from AW Server.

Best regards,

Salim

14

Dear Salim,

After re-reading this thread, there is nothing I can do on my side.

Visibly, the “AWS31” modality by GE does not honor the C-MOVE request from “KANOUNIX” (i.e. Orthanc).

I’m really sorry, but the only possibility is to read the logs of AWS31 to understand why nothing is transferred. You should get in touch with your (paying) support by GE:
https://book.orthanc-server.com/faq/proprietary.html

Please also make sure that:

  • You use the latest version of Orthanc (modifications related to GE were made in 1.5.0)
  • You provide “GE” as the fourth parameter defining the manufacturer in the “DicomModalities” configuration options (which enables some patches for GE modalities)
  • You have tried the different levels of transfers (by studies, series, and instances)
    You could also manually play with DCMTK’s “movescu” in order to find the proper parameters that work with GE modalities, then compare them with the parameters used by Orthanc (cf. “–verbose” mode).

HTH,

Sébastien-

15

Dear Sebastien,

I’m on 1.5.7 and I just turned the manufacturer to “GE”, no change…
I tried the series level retrieve with Orthanc Explorer same issue.

I will try to continue to explore with logs and DCMTK,
Thanks

Salim