Orthanc refuses Echo

[salim....@gmail.com]

Hi there,

I have a question about Orthanc behaviour regards to Echo that I found to be more restrictive than commercial DICOM workstation.

We have a program that send DICOM images, we want to implement an Echo before the sending process to be sure that the DICOM station is alive.

When I send a DICOM echo to Orthanc, its refuse the connexion because Orthanc check AET name in the Echo connection so In my log I have :
W0807 17:20:41.039473 CommandDispatcher.cpp:812] Rejected Echo request from remote DICOM modality with AET "storescu" and hostname "127.0.0.1"

While Other commercial DICOM nodes (Xeleris and AWserver) don't care so much about the calling AET for an Echo.

So Here is my problem :

- I have to run an Echo before sending my DICOM file through a DCM4CHE storescu library, it is important for me because if the AET is not responding our program crashes (if the server refuse due to a missing declaration it will not crash but the server have to answer something).

- My Echo function correctly Echo commercial workstation, my usual DICOM nodes responds to the Echo even if the calling AET is unknown.

- Only Orthanc (in my network) refuses the Echo because the calling AET is unknown.

So my question is : Is it a normal behavior to reject Echo because of an unknown calling AET ?

Are the commercial workstation too permissive by responding to an unknown called AET for DICOM Echo ?
Or Is Orthanc to restrictive for rejecting a DICOM Echo from unknown called AET ?

Thanks for your help,

Salim

[Thibault Nélis]

Hello,

Have you tried the DicomCheckCalledAet setting?

  // Check whether the called AET corresponds to the AET of Orthanc
  // during an incoming DICOM SCU request
  "DicomCheckCalledAet" : false,
--
Thibault Nélis <t...@osimis.io>
Osimis

[salim....@gmail.com]

Hi Thibault,

Yes it is already in false (which is the default value) and Orthanc correclty accept DICOM for unknown AET without problem (which is that I want in my case).

I think it may be something to correct here, it is pretty curious to accept data without AET matching (which is very well handled by the json parameter) and rejecting echo which is just a connection check.

I don't know if there are official recommendations about C-ECHO, in my experience all workstations I tried to work with are permissive about the C-ECHO. DICOM acceptance needs AET declaration in both way but not C-ECHO.

Best regards,

Salim

[Sébastien Jodogne]

Hello,

Indeed, Orthanc 1.3.0 will refuse any DIMSE association from modalities whose AET is unknown, thus preventing C-Echo. Previous versions of Orthanc (<= 1.2.0) were more permissive, allowing DIMSE associations from unknown modalities, but restricting allowed commands on such associations to C-Echo.

The related commit is the following:

https://bitbucket.org/sjodogne/orthanc/commits/3ab96768d1445679d17e3fe0174ff35ebe761983?at=default#chg-OrthancServer/Internals/CommandDispatcher.cpp

To reproduce the behavior of Orthanc 1.2.0 into Orthanc 1.3.0, one would always return "true" in the "OrthancApplicationEntityFilter::IsAllowedConnection()" method, and return "true" if the "type" argument equals "DicomRequestType_Echo" in the "OrthancApplicationEntityFilter::IsAllowedRequest()" method at the following location:

https://bitbucket.org/sjodogne/orthanc/src/Orthanc-1.3.0/OrthancServer/main.cpp#main.cpp-151

IMHO, the behavior of Orthanc 1.3.0 is more "correct", because C-Echo is at the same level as C-Move, C-Store or C-Find in the standard:

http://dicom.nema.org/medical/dicom/current/output/html/part07.html

Indeed, I think the rationale of C-Echo consists in going further than a simple "ping", effectively checking all the DICOM parameters (including the AET of the calling modality). This is however my own understanding, and I have no formal proof about this.

I suggest you to ask this question to the "comp.protocol.dicom" mailing list, and let us know your findings:

https://groups.google.com/forum/#!forum/comp.protocols.dicom

Regards,

Sébastien-

[salim....@gmail.com]

Hi Sebastien,

Thank you for your answer, now I understand why I didn't found that issue before while i was using Orthanc 1.2.0.

I opened a question in comp.protocols.dicom : https://groups.google.com/forum/#!topic/comp.protocols.dicom/taxQM9TClgI

I will keep you updated when I will get an answer,

Best regards,

Salim

[salim....@gmail.com]

Hi Sebastien,

We got one answer apparently there is no real consenssus. (https://groups.google.com/d/msg/comp.protocols.dicom/taxQM9TClgI/6fAi-lcMAgAJ)

I wonder if the C-ECHO souldn't follow the DicomCheckCalledAet setting defined in the Orthanc.json.

if DicomCheckCalledAet is false it is a bit strange to reject C-Echo while DICOM transfers will be accepted no matter of the calling AET.

if the DicomCheckCalledAet is true then the C-Echo could check the calling AET and will act as a predictive test to notifiy if the communication will be allowed between both AET.

What do you think ?

Best regards,

Salim

[Sébastien Jodogne]

Dear Salim,

Given the lack of consensus, I have decided to introduce a new configuration option "DicomAlwaysAllowEcho" in the following changset:

https://bitbucket.org/sjodogne/orthanc/commits/3ec85ff48374803e0e796ba8bf0923f53f591e4b

If this option is set to "true" (the default), Orthanc will behave as in releases <= 1.2.1 (i.e. always accept C-Echo, even from unknown modalities).

If this option is set to "false", Orthanc will behave as in release 1.3.0 (i.e. refuse any C-Echo arising from an unknown modality).

HTH,

Sébastien-

[Salim Kanoun]

Wondefull !

Thank you so much,

Salim