Docker crash after sending dicom files via dicomWeb

General
1

*Hello! I hope you are all doing well, and thank you in advance.

I am experiencing an issue that I cannot understand because it is not reproducible locally. I have an Orthanc Docker image running on Digital Ocean, and it works correctly. However, when I send DICOM files via DICOMweb from “K-PACS,” it crashes and does not allow me to upload them (the ECHO connection test works fine).

We suspect it is a database issue since we have been facing some difficulties in that area recently. We tried to reproduce the error locally for debugging, but we are unable to build the image (even though it is running fine on Digital Ocean).

Below, I provide all the relevant information:

**Ports (enabled through the firewall):
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http
104/tcp filtered acr-nema
443/tcp open https
4242/tcp open vrml-multi-use?

Orthanc.json:
{
//! General configuration
“HttpsCACertificates”: “/etc/orthanc/certs/amazonrootca1.pem”,
“RemoteAccessAllowed”: true,
“RestApiWriteToFileSystemEnabled”: true,
“TransferSyntaxAccepted”: true,
“DicomAssociationCloseDelay”: 0,
“DicomModalities”: {},
“DicomAssociationMaximumLength”: 16777216,
“DicomCheckCalledAet”: false,
“DicomCheckModalityHost”: false,
“DicomAlwaysAllowEcho”: true,
“DicomAlwaysAllowFind”: true,
“DicomAlwaysAllowStore”: true,
“DicomAlwaysAllowGet”: true,

//! Servers
“DicomPort”: 4242,
“DicomServerEnabled”: true,
“HttpEnabled”: false,
“DicomAet”: “ORTHANC”,
“StrictDicom”: false,
“HttpsEnabled”: false,

//! Server configuration
“HttpServer”: {
“Enabled”: false,
“Port”: 8042,
“AllowOrigin”: [
“http://localhost:3000”,
“https://medconnectback-staging.up.railway.app”,
“https://medconnectfront-staging.up.railway.app”
]
},

“DicomWeb”: {
“Enable”: true,
“Root”: “/dicom-web/”,
“EnableWado”: true,
“WadoRoot”: “/wado”,
“Ssl”: false,
“QidoCaseSensitive”: false,
“Host”: “”,
“port”: 4242,
“StudiesMetadata”: “Full”,
“SeriesMetadata”: “Full”,
“EnableMetadataCache”: true,
“MetadataWorkerThreadsCount”: 4,
“PublicRoot”: “/dicom-web/”
},

//! Plugins
“Plugins”: [“/usr/local/share/orthanc/plugins”],

“PostgreSQL”: {
“EnableIndex”: true,
“EnableStorage”: false,
“ConnectionUri”: “”,
“UnixSocket”: “”,
“EnableSsl”: true,
“MaximumConnectionRetries”: 10,
“ConnectionRetryInterval”: 5,
“IndexConnectionsCount”: 50,
“TransactionMode”: “ReadCommitted”,
“EnableVerboseLogs”: false,
“HousekeepingInterval”: 1
},

“AwsS3Storage”: {
“Enable”: true,
“BucketName”: “orthanc-dicom-database”,
“Region”: “us-east-2”,
“AccessKey”: “”,
“SecretKey”: “”,
“ConnectionTimeout”: 30,
“RequestTimeout”: 1200,
“RootPath”: “”,
“MigrationFromFileSystemEnabled”: false,
“StorageAccessOnFind”: true,
“StorageStructure”: “flat”,
“EnableLegacyUnknownFiles”: true,
“VirtualAddressing”: true,
“HybridMode”: “Disabled”,
“UseTransferManager”: false,
“EnableAwsSdkLogs”: false,
“StorageClass”: “STANDARD”
},

“PythonScript”: “/etc/orthanc/meddream.py”,
“JobsEngineThreadsCount”: {
“ResourceModification”: 1
},

//! Users
“RegisteredUsers”: {
“admin”: “ServerAdmin”,
“user1”: “UserAccess”
},

//! Just in case
// “Servers”: {
// “OrthancLocal”: {
// “Url”: “http://localhost:8042/dicom-web/”,
// “Username”: “orthanc”,
// “Password”: “orthanc”
// }
// }

“Authorization”: {
“Enabled”: true,
“CheckedLevel”: “studies”
}
}

Latest error logs:
HTTP-18 dicom-web:/Configuration.cpp:643] Unsupported return MIME type: application/dicom+json, multipart/related; type=application/octet-stream; transfer-syntax=*, will return DICOM+JSON
E0214 18:12:58.990031 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 47
E0214 18:12:59.314033 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0214 18:12:59.637836 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0214 18:12:59.928604 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 80
E0214 18:13:00.270005 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0214 18:13:00.614706 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0214 18:13:00.945515 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 48
E0214 18:13:08.581460 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 16
E0214 18:13:09.260214 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 16
E0214 18:13:09.553061 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0214 18:13:09.878847 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0214 18:13:10.203281 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 6c
E0214 18:13:10.492928 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 47
E0214 18:13:10.783388 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: A-ASSOCIATE PDU too large
E0214 18:13:11.109281 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 30
E0214 18:13:11.402539 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 30
E0214 18:13:11.713621 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0214 18:13:12.007566 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 54

2

Hi,

You are mentioning DICOMWeb but the errors you are receiving are on the DICOM Server → check you are not mixing up DicomPort and HttpPort.

In most cases, when Orthanc crashes, that’s because it does not have enough RAM → check the memory usage of your VM/container before the crash.

HTH,

Alain.

3

Hi Alain, thank you very much for your reply, I´m simplified the Orthanc.json for testing and the problem was the RAM, I´m updated the droplet and works perferct

1 Like
4

Hi Alain, right now i´m testing out the dicom transfer via dicomWeb, and I have the PDU error, do you know why it´s can happend?

E0217 16:51:43.612267 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 47
E0217 16:51:43.935054 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0217 16:51:44.223262 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0217 16:51:44.545169 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 80
E0217 16:51:44.884871 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:45.172277 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:45.460797 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 48
E0217 16:51:53.120260 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 16
E0217 16:51:53.743738 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 16
E0217 16:51:54.032121 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:54.320585 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:54.610821 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 6c
E0217 16:51:54.901487 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 47
E0217 16:51:55.195686 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: A-ASSOCIATE PDU too large
E0217 16:51:55.502196 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 30
E0217 16:51:55.792290 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 30
E0217 16:51:56.082359 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4f
E0217 16:51:56.371226 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 54
E0217 16:51:56.990966 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 44
E0217 16:51:57.313315 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 3a
E0217 16:51:57.636080 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 4a
E0217 16:51:57.925713 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: A-ASSOCIATE PDU too large
E0217 16:51:58.214825 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:58.521996 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 12
E0217 16:51:58.815456 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 0
E0217 16:51:59.107568 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 47
E0217 16:52:00.764804 DICOM-SERVER CommandDispatcher.cpp:285] Receiving Association failed: Unrecognized PDU type: 80

5

Hi Emiliano,

It really looks like a protocol mismatch, as Alain said.

DICOMWeb uses HTTP while DICOM is another protocol entirely, listening on another port.

You need to make sure to target the HttpPort defined on your configuration (8042 by default).

If you are still confused, please share your configuration file and explain what exact commands you are executing.

Pay attention to this sentence in the documentation:

Note that the DICOMweb server will share all the parameters of the Orthanc HTTP server, notably wrt. authentication and HTTPS encryption. For this reason, you will most probably have to enable the remote access to the Orthanc HTTP server:

HTH

Benjamin

6

Hi Benjamin, how are you? Thank you very much for your help. I still can’t fix the problem; if you can help me, I would appreciate it! This is my configuration file and my command:

docker run -d -p 80:8042 -p 443:8042 -p 4242:4242 orthanc
I use this command because otherwise, DigitalOcean does not allow me to access the Orthanc interface, since if the container does not use the ports, they are closed.

And this is my config file:
{
//! General configuration
“HttpsCACertificates”: “/etc/orthanc/certs/amazonrootca1.pem”,
“RemoteAccessAllowed”: true,
“RestApiWriteToFileSystemEnabled”: true,
“TransferSyntaxAccepted”: true,
“DicomAssociationCloseDelay”: 0,
“DicomModalities”: {},
“DicomAssociationMaximumLength”: 16777216,
“DicomCheckCalledAet”: false,
“DicomCheckModalityHost”: false,
“DicomAlwaysAllowEcho”: true,
“DicomAlwaysAllowFind”: true,
“DicomAlwaysAllowStore”: true,
“DicomAlwaysAllowGet”: true,

//! Servers
“DicomPort”: 4242,
“DicomServerEnabled”: true,
“HttpEnabled”: false,
“DicomAet”: “ORTHANC”,
“StrictDicom”: false,
“HttpsEnabled”: false,

//! Server configuration
“HttpServer”: {
“Enabled”: false,
“Port”: 8042,
“AllowOrigin”: [
“http://localhost:3000”,
“https://medconnectback-staging.up.railway.app”,
“https://medconnectfront-staging.up.railway.app”
]
},

“DicomWeb”: {
“Enable”: true,
“Root”: “/dicom-web/”,
“EnableWado”: true,
“WadoRoot”: “/wado”,
“Ssl”: false,
“QidoCaseSensitive”: false,
“Host”: “”,
“port”: 4242,
“StudiesMetadata”: “Full”,
“SeriesMetadata”: “Full”,
“EnableMetadataCache”: true,
“MetadataWorkerThreadsCount”: 4,
“PublicRoot”: “/dicom-web/”
},

//! Plugins
“Plugins”: [“/usr/local/share/orthanc/plugins”],

“PostgreSQL”: {
“EnableIndex”: true,
“EnableStorage”: false,
“ConnectionUri”: “”,
“UnixSocket”: “”,
“EnableSsl”: true,
“MaximumConnectionRetries”: 10,
“ConnectionRetryInterval”: 5,
“IndexConnectionsCount”: 50,
“TransactionMode”: “ReadCommitted”,
“EnableVerboseLogs”: false,
“HousekeepingInterval”: 1
},

“AwsS3Storage”: {
“Enable”: true,
“BucketName”: “orthanc-dicom-database”,
“Region”: “us-east-2”,
“AccessKey”: “”,
“SecretKey”: “”,
“ConnectionTimeout”: 30,
“RequestTimeout”: 1200,
“RootPath”: “”,
“MigrationFromFileSystemEnabled”: false,
“StorageAccessOnFind”: true,
“StorageStructure”: “flat”,
“EnableLegacyUnknownFiles”: true,
“VirtualAddressing”: true,
“HybridMode”: “Disabled”,
“UseTransferManager”: false,
“EnableAwsSdkLogs”: false,
“StorageClass”: “STANDARD”
},

“PythonScript”: “/etc/orthanc/meddream.py”,
“JobsEngineThreadsCount”: {
“ResourceModification”: 1
},

//! Users
“RegisteredUsers”: {
“admin”: “ServerAdmin”,
“user1”: “UserAccess”
},

//! Just in case
// “Servers”: {
// “OrthancLocal”: {
// “Url”: “http://localhost:8042/dicom-web/”,
// “Username”: “orthanc”,
// “Password”: “orthanc”
// }
// }

“Authorization”: {
“Enabled”: true,
“CheckedLevel”: “studies”
}
}

Thanks you so much!

7

Hello Emiliano

  1. remove port from the DicomWeb section. This is not allowed or relevant. The port that Orthanc uses as a DicomWeb server is HttpPort (at the global level)

  2. you need to enable remote access, most probably (RemoteAccessAllowed to true, at global level) (BEWARE: this will expose your server… with RestApiWriteToFileSystemEnabled set to true, this is a lethal combination… Is it really required?)

  3. use 8042 instead of 4242 in K-Pacs when targeting your Orthanc container (you’ll need to open the port in your firewall, NAT rules or whatever you’re using)

HTH

8

Emiliano,

Have you generated parts of your config with sth like chatgpt?

I am wondering about this HttpServer block you’re using… I am not familiar with it (and, actually, after verification, it is not valid)

I would say that LLMs must be a last resort, after the official documentation, which should be the #1 source of info when trying to configure basic settings like the HttpServer. Allocating some time to reading it will not be a waste.

It should not impact our discussion above (since it is not recognized, it has no impact… thankfully because you want to disable it, it seems)

Please carefully compare your configuration with:

–B

9

Hi Benjamin, thank you so much for your help! I really appreciate it. This is my first time working with Orthanc and DICOM files, and at some point, I used ChatGPT or something like that. I’m going to read everything again and configure the server properly.

10

Hi Emiliano, no worries. I am using ChatGPT too :slight_smile:

But, indeed, please carefully review your various configuration settings and, when done, get back to us and we’ll try to review the remaining issues.

Good luck!

11

Hi Benjamin, how are you?

I’ve made a lot of changes to my server, and it’s working much better now. However, I’m having an issue with the DICOM port. I reviewed both the HTTP server configuration and the DICOM plugin settings. Here’s my current configuration:

“StrictDicom”: false,
“HttpServerEnabled”: true,
“HttpPort”: 8042,
“DicomAet”: “ORTHANC”,
“DicomWeb”: {
“Enable”: true,
“Root”: “/dicom-web/”,
“EnableWado”: true,
“WadoRoot”: “/wado”,
“Ssl”: false,
“QidoCaseSensitive”: false,
“Host”: “”,
“StudiesMetadata”: “Full”,
“SeriesMetadata”: “Full”,
“EnableMetadataCache”: true,
“MetadataWorkerThreadsCount”: 4,
“PublicRoot”: “/dicom-web/”
},

But I have two issues. First, K-PACS doesn’t recognize the DICOM port, and Orthanc itself reports that the DICOM port is set to 4242. Do you have any idea what might be causing this problem?

MAIN ServerContext.cpp:590] Disk compression is enabled
W0220 13:26:36.333403 MAIN ServerIndex.cpp:395] No limit on the number of stored patients
W0220 13:26:36.333751 MAIN ServerIndex.cpp:415] No limit on the size of the storage area
W0220 13:26:36.618221 MAIN ServerContext.cpp:284] Reloading the jobs from the last execution of Orthanc
W0220 13:26:36.618877 MAIN JobsEngine.cpp:276] The jobs engine has started with 2 threads
W0220 13:26:36.619359 MAIN main.cpp:300] Security risk in DICOM SCP: C-FIND requests are always allowed, even from unknown modalities
W0220 13:26:36.619632 MAIN main.cpp:310] Security risk in DICOM SCP: C-GET requests are always allowed, even from unknown modalities
W0220 13:26:36.620353 MAIN main.cpp:1346] DICOM server listening with AET ORTHANC on port: 4242
W0220 13:26:36.620870 MAIN HttpServer.cpp:2046] HTTP compression is disabled
W0220 13:26:36.621273 MAIN main.cpp:1081] Remote access is allowed but “AuthenticationEnabled” is not in the configuration, automatically enabling HTTP authentication for security
W0220 13:26:36.621631 MAIN main.cpp:1195] Remote LUA script execution is disabled
W0220 13:26:36.621965 MAIN main.cpp:1207] REST API cannot write to the file system because the “RestApiWriteToFileSystemEnabled” configuration is set to false. The URI /instances/…/export is disabled. This is the most secure configuration.
W0220 13:26:36.623663 MAIN HttpServer.cpp:1804] HTTP server listening on port: 8042 (HTTPS encryption is disabled, remote access is allowed)
W0220 13:26:36.625116 MAIN main.cpp:946] Orthanc has started

12

Hi Emilio,

Just to make sure : you are well aware that DICOM and DICOMweb are two completely different things (with respect to network), right?

So, do I infer correctly that, for now, you are trying to use DICOM, not DICOMweb anymore, correct?

You should know that DICOM is not designed to be used on the Internet, for it is not encrypted unless you use TLS (which requires its own specific configuration).

I will therefore assume that you are using TLS or a VPN to connect to the cloud Orthanc, or that you are connecting to it from another cloud machine.

I assume that K-PACS will then be the SCU (Service Class User), from which you want to execute commands to the Orthanc SCP (Provider), like C-Find or C-Store (I assume you can reach the cloud machine from your laptop but perhaps not the opposite)

In order to configure this, you need to make sure:

  • That you correctly expose port 4242 in your Docker container
  • That you configure the Docker host so that port 4242 is reachable.
  • (that your local network allows for outgoing connections on port 4242 → normally not an issue with normal IT people)
  • That you configure K-PACS with the following info:
    • Orthanc AET (look in the configuration - default: ORTHANC)
    • Orthanc IP address
    • Orthanc port (4242 in this case)

Then, you should probably execute a C-Echo from K-PACS to Orthanc to check if it responds.

What I would first do would be to try a C-Echo with dcmtk from the cloud machine , so that you can tell the network issues from the Orthanc configuration issues.

  • Install dcmtk:
    • sudo apt update && sudo apt install dcmtk Debian/Ubuntu
    • sudo yum install dcmtk / sudo dnf install dcmtk CentOS/Fedora
    • etc…
  • Execute:
echoscu -aec MyOrthanc localhost 4242

This of course requires that you replace MyOrthanc with the AET defined in the configuration file, and also that you make sure that 4242 is exposed. If you also expose 8042 in the same fashion and curl localhost:8042/system works, then 4242 is probably also correctly exposed.

Once you make this work, you can try the same from your local machine, but replace localhost with the VPN IP of Orthanc.

Again, I repeat, this is not secure on the public Internet and I think that DICOMweb is a better fit (since it can rely on HTTPS). More info in this link in the Orthanc book

Edit : I did not know KPACS and googled a little, but it looks like a rather old application and I can’t find any mention of DICOMweb support? Am I mistaken? It seems that your early tests were indeed made with DICOMweb…

Let us know how it goes

HTH

13

Hello Benjamin,

I am currently able to send files from K-PACS to the Orthanc server. What I am trying to achieve is to deploy Orthanc remotely and use it as an online PACS. However, medical equipment and K-PACS, in this case, send files using the traditional DICOM protocol, requiring an IP address.

As I understand it, I wouldn’t be able to use both DicomWeb and traditional DICOM, and you mentioned that using traditional DICOM remotely is insecure. Am I correct?

P.S.: I was also able to send files from a Chison C-BIT8 ultrasound machine without any issues, which is why I have these questions.

14

Emiliano,

You can use both DICOM and/or DICOMweb on an Orthanc instance, this is not a problem (they use different ports)

The raw DICOM protocol is not encrypted, thus insecure.

If you need to use DICOM on an insecure network (the Internet), you need to use TLS encryption, as described in the Orthanc Book.

If you already have HTTPS support for Orthanc, then DICOMweb can take advantage of it. DICOMweb provides other advantages too, such as less networking friction (since it uses HTTPS, it will be routed like normal web traffic), ability to perform bulk retrievals, …)

I understand you are now able to send files to Orthanc : what are your remaining issues, apart from this TLS one?

–B

15

Thank you, Benjamin! I am going to try the TLS configuration. I think I don’t have any more issues.

1 Like
16

How’s it going? It’s been a while! I was able to make many improvements to the server, and it works much better now, but I have a question about handling SSL certificates and HTTPS.

I have Certbot and Nginx installed to generate the certificates, and then I mount the certificate folder to the container. What caught my attention is that to enable HTTPS, I have to run this command:
docker run -d
-v /etc/letsencrypt/live:/etc/letsencrypt/live
-v /etc/letsencrypt/archive:/etc/letsencrypt/archive
-v $(pwd)/orthanc.json:/etc/orthanc/orthanc.json
–env-file .env
-p 443:8042
-p 4242:4242
orthanc

This way, it works correctly, but shouldn’t Nginx be responsible for redirecting the traffic? I already tried setting it up that way, but it didn’t work correctly. Right now, I’m only using it for certificate generation.

17

Hi Emiliano,

It’s difficult to reply as we do not really know what architecture you want to deploy and what you currently have.

Two methods are available in your situation:

  • You can use Nginx as a reverse proxy, so that it deals with TLS termination, and Orthanc does not have to be concerned with certificates or HTTPS (you should let these settings disabled in the configuration).

    • Pros: you can reverse proxy other services as needed, you can use the certbot nginx system to automatically renew the certificates, etc.
    • Cons: you need an extra service
    • There’s an example of a reverse proxy setup here (this example does not use HTTPS and simply shows how to reverse-proxy requests)

  • You can enable HTTPS in Orthanc and configure it with the required certificates . In that case, you do not need Nginx at all : you only need certificates. There is a complete example here where multiple mechanisms are demonstrated.

I advise you to carefully study the second example above, that demonstrates all the features you are currently concerned with (both Nginx and Orthanc).

Please note that all this is strictly about HTTP and HTTPS and is not related to DICOM TLS, which is another thing entirely

HTH

–Benjamin

18

Hello, it’s a pleasure once again.

I greatly appreciate all your help and support with my many questions. I’m sharing how I was able to resolve the PDU error in case someone encounters it in the future.

Initially, when I started the server and couldn’t communicate with it, I realized it was a port issue. To check them, I used the command:
nmap -sV -p

Later, when I switched to Digital Ocean to manage the ports, I kept using that practice.

Today, I realized that I was causing the error myself because Orthanc (logically) does not recognize the packets sent by the command. So, if someone faces the same issue, they should either avoid using nmap on Orthanc or be aware that it will generate this error.

I was finally able to send files via DICOM Server and read them in the viewer that uses DICOMweb without any issues or errors.

Once again, thank you, Benjamin and Alain!

1 Like