No presentation context proposed

We have a strange situation where a certain study is taking a lot longer than other studies. Enabling trace logging, there appears to be a correlation of “No presentation context” messages with increased transfer times for dicom instances.

As you can see below, the times between consecutive instances varies, and appears related to these messages. In contrast, when transferring other studies, we seem to see fewer of these messages, and each instance takes ~300ms to be received.

MicrosoftTeams-image (2).png

We have tried increasing the number of concurrent jobs (to 20), but this did not appear to make a difference.

I’ve read the relevant paragraph in the Orthanc documentation, and would like to understand this a bit more. Is it possible to view the protocol negotiation, to understand the reason for this message more? Or does this message indicate that the upstream system is somehow skipping this step, and trying to send the raw data, somehow?

Thanks for your insights.


While the upstream system is proprietary, I am hoping that by understanding


In forthcoming release 1.8.1 of Orthanc, it will be possible to get the full debug messages from DCMTK (the library that is used by Orthanc for the DICOM communications), including the negotiation of the presentation contexts.

This is done by starting Orthanc with the “–verbose --trace-dicom” command-line options, as explained in the Orthanc Book:

To try this feature before 1.8.1 is officially released, you’ll have to compile Orthanc from the mainline sources, or to use precompiled LSB (Linux Standard Base) binaries:


Thanks a lot for that information. Using the above, I have patched the Osimus docker image with a freshly-build Orthanc static binary, making it much easier to debug and isolate the problem. In case others also can’t wait and wish to try it out, I am building the dockerfile here. (I will remove this once the 1.8.1 --trace-dicom feature is available from the official Osimus hub).

The “no presentation context received” was a false alarm: it was just a check from the load balancer that the TCP connection was still OK, which of course was not a valid DICOM session.

Attached is a small extract of the dicom log, showing how helpful it is. In this case, we can see that a single association is being used for a study transfer, so the slow transfer speeds we see are not related to that - and that there is a 1 second delay sometimes being added during the upload. This helps to indicate the problem is upstream, while waiting for data to arrive, rather than anything else. Without this, I would still be thinking the problem was association-related.


dicom-trace.log (3.3 KB)

Great, thanks for your positive feedback regarding the improvements to DICOM-related logging!