Mercurial > hg > orthanc-book
view Sphinx/source/faq/dicom.rst @ 1013:ab270400aae1
python: overriding core API
author | Alain Mazy <am@osimis.io> |
---|---|
date | Tue, 09 Jan 2024 11:50:17 +0100 |
parents | 46e2941b57dd |
children |
line wrap: on
line source
.. _dicom: Troubleshooting DICOM communications ==================================== In general, communication problems between two DICOM modalities over a computer network are related to the configuration of these modalities. As preliminary debugging actions, you should: * Make sure you use the `most recent version <https://www.orthanc-server.com/download.php>`_ of Orthanc. * Make sure the two computers can "ping" each other. * Turn off all the firewalls on the two computers (especially on Microsoft Windows). * Make sure the remote computer has `DICOM TLS encryption <https://www.dicomstandard.org/using/security/>`__ turned off. * Write down on a paper the following information about each modality: * its IP address (avoid using symbolic names if possible to troubleshot any DNS problem), * its TCP port for DICOM communications (for Orthanc, cf. the ``DicomPort`` option), and * its AET (Application Entity Title - for Orthanc, cf. the ``DicomAet`` option). * Carefully re-read all your configuration files. As far as Orthanc is concerned, the most important section is ``DicomModalities``: Make sure its content matches what you wrote on the paper at the step above. * In the ``DicomModalities`` configuration section of Orthanc, have a look at the fourth parameter that can activate some patches for specific vendors. * Have a look at the following options of Orthanc to enable the more fault-tolerant DICOM support: * ``DicomServerEnabled`` must be set to ``true``. * ``DicomCheckCalledAet`` should be set to ``false``. * All the transfer syntaxes should be set to ``true`` (see the options with a ``TransferSyntaxAccepted`` suffix). * Temporarily disable any Lua script and any plugin, i.e. set the options ``LuaScripts`` and ``Plugins`` both to the empty list. * ``DicomAssociationCloseDelay`` should be set to ``0``. * Restart Orthanc with the ``--verbose --trace-dicom`` options at command line, and carefully inspect the log (the ``trace-dicom`` option is new in Orthanc 1.8.1 and provides low-level information from DCMTK). This might provide immediate debugging information. Make sure to read :ref:`how to generate an exploitable log <log>`. * Issue a :ref:`DICOM C-Echo <dicom-echo>` from each modality to make sure the DICOM protocol is properly configured (sending a C-Echo from Orthanc Explorer is possible starting with Orthanc 0.9.3, in the "Query/Retrieve" page). * If the two modalities succeed with C-Echo, but query/retrieve does not succeed, please carefully read the :ref:`dicom-move` section. * Check out the :ref:`more generic troubleshooting guide <troubleshooting>`. As a last resort, please contact the `Orthanc Users discussion forum <https://discourse.orthanc-server.org>`__ by sending a detailed description of your problem, notably: * What fails: The sending of a file (aka. C-Store SCU), the searching of a patient/study (aka. C-Find SCU), or the retrieve of a file (aka. C-Move SCU)? Is Orthanc acting as a client or as a server? * Describe your network topology, as written above on your paper (IP address, port number, and AET for both modalities). * Specify the operating system, the vendor, the DICOM software, and the version of each modality. * Attach sample DICOM files, possibly anonymized. * Attach the log of the two modalities. The :ref:`log must be generated <log>` with the ``--trace`` command-line option as far as Orthanc is concerned. * Attach any screenshot that is useful to understand the problem.