AET name is not transferred to Orthanc (or not accepted by Orthanc)

Google Groups archive
1 
Hello,

(i was a silent watcher of this Newsletter and until now, the postings in this Newsletter helped with my issues.....
Orthanc ist a fascinating Project, i learnt a lot about DICOM ans also about Linux, thanks a lot for your work)

But now, i have a weird Problem, i cannot find any solution for.

i have been running our two Philips Ultrasound Systems (EPIQ7 and IU22) with Orthanc scince 02/2014, finally ver 0.9.4 (0.9.4+dfsg-1with embedded SQLite) on a Linux Mint System (Release 17.1 which ist based on Ubuntu 14.04). The System was working fine.

Now, i moved on a new System (Linux Mint 18 Sarah, based on Ubuntu 16.04) with Orthanc 1.1 (self compiled) and PostgreSQL Server. Our first Modality (EPIQ) is working fine, but the second ohne (iu22) cannot Store on Orthanc. When starting Orthanc with -- verbose, i get the following errormessage, if sending Dicom-Images to Orthanc or Testing the archive-server:

I0926 09:14:25.185831 CommandDispatcher.cpp:491] Association Received from AET  on IP 192.x.x.x
I0926 09:14:25.185909 CommandDispatcher.cpp:620] Association Rejected: Bad Application Context Name: 
I0926 09:14:25.186015 CommandDispatcher.cpp:624] DUL Finite State Machine Error: No action defined, state 1 event 7

Testing the old Orthanc 0.9.4 works fine, i receive correct answers:

... Association Received from AET iu22 on IP 192.x.x.x
... Association Acknowledged (Max Send PDV: 32756)
... Received Echo Request
... CommandDispatcher.cpp:860] DUL Peer Requested Release
... CommandDispatcher.cpp:867] Association Release

It seems like if the AET name is not transferred to Orthanc (or not accepted by Orthanc) on the new System. I don't understand, why it works wir 0.9.4 but not with 1.1. Can the PostgreSQL database be a factor?

i've also tried different AET names and IP-Adresses. Also tried "DicomCheckCalledAet" : true, (without knowing, what it ist)

Do you have any idea, whats wrong?. I was so close to an almost perfect System, but now my project ist stucked. Thank you
Mark
2

Hello,

There was no important change in the DICOM SCP part of Orthanc between releases 0.9.4 and 1.1.0. As a consequence, this rather looks like a low-level compatibility issue between your Philips US modality and DCMTK (the DICOM toolkit that is built in Orthanc).

I would advise you to statically link Orthanc against DCMTK. This can be done by setting the option “-DUSE_SYSTEM_DCMTK=OFF” flag while invoking CMake:
https://bitbucket.org/sjodogne/orthanc/src/default/LinuxCompilation.txt

This flag will make Orthanc use DCMTK 3.6.0 instead of the 3.6.1 version that is still in development but that is used by Ubuntu 16.04:
http://packages.ubuntu.com/search?keywords=dcmtk

If you are unable to compile Orthanc by yourself, you can give a try to the official Docker image (this images is built on the top of Ubuntu 14.04, where DCMTK 3.6.0 was still used):
https://github.com/jodogne/OrthancDocker

Let us know whether using DCMTK 3.6.0 instead of DCMTK 3.6.1 helps.

Sébastien-

3

Thank you for the answer. I hope to finde some time the next days and i promise to report the results here. Mark

4

Hello,
sorry for late answer. Now i compiled with DCMTK 3.6.0 the way you suggested. Unfortunately this didn’t solve my problem. It’s working fine with epiq but not with iu. Do you have any other idea?
kind regards
Mark

5

From the Orthanc log you sent, it seems that your Philips UI modality does not properly set the “Application Context Name” when it opens its DICOM connection to Orthanc:
http://dicom.nema.org/dicom/2013/output/chtml/part07/sect_A.2.html

As you have compiled Orthanc 1.1.0 from source, I would advise you to remove the lines from 607 to 628 in the file “Orthanc-1.1.0/OrthancServer/Internals/CommandDispatcher.cpp”, then compile Orthanc again:
https://goo.gl/s3lp8P

These lines only implement a safety check, and are thus not necessary.

Please let us know whether this actually solves your issue. If this is the case, you should as well get in touch with your commercial support of Philips to warn them about this non-compliance.

6

i compiled again after bracketing out the lines. The problem still remains.

7

As a last resort, try and replace Orthanc by the “storescp” command-line tool from the DCMTK distribution.

If Orthanc listens on its default port 4242 and its AET is “ORTHANC”, you can replace Orthanc by storescp by typing:

storescp -d -aet ORTHANC 4242

This way, you will only get a basic C-Store server, but you will be able to check whether DCMTK works properly against your Philips UI modality.

8

Hi, this procedure worked. The iu22 could store dicom-files (i installed dcmtk 3.6.1 and typed “storescp -d -aet ORTHANC 4242”), so DCMTK seems to work fine.

9

OK, so this seems to indicate that the issue is actually inside Orthanc.

Unfortunately, there is not much I can do without having access to your modality: You will have to figure out the issue by yourself, or ask your paying support of Philips to dig into the issue.

As Orthanc is free and open-source, please release the patch in the public domain so that I can integrate it back to the benefit of the community.

Regards,
Sébastien-

10

Hello, meanwhile i’ve found some time to try some actions and solved the Problem. I installed a precompiled Version of Orthanc 1.1 from an Ubuntu 17.04 (Zesty) repository and now everything is fine. Thus this strange issue must have been caused during compilation of orthanc. This ist a quick and dirty solution, not my favorite one, but it seems to work. I hope, i won’t have any other issues with the Zesty build.
Thank you for your help

11

I encountered the same issue and found that it is actually a time-out problem. The reason that is does not occur in the Zesty build, is that that package is linked to dcmtk-3.6.1. You can compile it yourself with dcmtk-3.6.1 by adding -DUSE_DCMTK_361=ON to the cmake line (works on Ubuntu 16.04).

Alternatively, if you want to use dcmtk-3.6.0, you can fix line 627 in Build/dcmtk-3.6.0/dcmnet/libsrc/dul.cc:
old: cond = PRV_NextPDUType(association, block, timeout, &pduType);
new: cond = PRV_NextPDUType(association, DUL_NOBLOCK, PRV_DEFAULTTIMEOUT, &pduType);

12

Many thanks for providing a solution to this issue!

You fix has been merged into the Orthanc mainline. Details are available in the following BitBucket issue:
https://bitbucket.org/sjodogne/orthanc/issues/35/aet-name-is-not-transferred-to-orthanc

Regards,
Sébastien-

13

any chance someone could compile & build this solution & post somewhere for install on a windows box?

have had orthanc happily humming along for ages now, but an IU22 has turned up & left me dead in the water.

Have no idea about compiling, git, repos, visual studio etc etc etc.

Have followed the links below to the letter & up to building in VS but getting nothing but a string of errors from there i have no idea about.
https://goo.gl/kswKQ6
https://bitbucket.org/sjodogne/orthanc/commits/bfcf5a7f92e7

(or can this fix be a orthanc.json configurable option in a future release?)

cheers

14

Oh wow. Sorry guys. Just realised there's a new version where this is fixed.

Long day!