Bug 35

Summary:	AET name is not transferred to Orthanc using dcmtk 3.6.0 (but ok in 3.6.1) [Fix included]
Product:	Orthanc	Reporter:	Sébastien Jodogne <s.jodogne>
Component:	Orthanc Core	Assignee:	Sébastien Jodogne <s.jodogne>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	---
Version:	unspecified
Hardware:	All
OS:	All

Description Sébastien Jodogne 2020-06-29 15:12:04 CEST

[BitBucket user: asch99]
[BitBucket date: 2017-03-13.19:04:29]

Actually this bug was reported already in https://groups.google.com/forum/#!topic/orthanc-users/3qaTYZn77zI but was not resolved. It appears that (at least for Philips EPIQ7 and IU22) that the calling AE title is not reported.

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

This is seen when compiling orthanc from bitbucket sources on Ubuntu 16.04 as:

cmake -DSTATIC_BUILD=ON  -DCMAKE_BUILD_TYPE=Release Build 

Adding -DUSE_DCMTK_361=ON to this cmake command resolves the error.

Installing Orthanc through apt-get also does not have this error, but then that one is dynamically linked to dcmtk 3.6.1.

Comment 1 Sébastien Jodogne 2020-06-29 15:19:32 CEST

[BitBucket user: asch99]
[BitBucket date: 2017-03-14.15:27:35]

As extra information, running a storescp instead of Orthanc does not give rise to this error. I tried the binary versions of 3.6.0 and 3.6.1 as well as compiling myself from the dcmtk-3.6.0 sources used in the compilation of Orthanc. Somehow the error already originates in the ASC_receiveAssociation() call in acceptAssociation() of CommandDispatcher.cpp, which results in an assoc with empty DULparams.

Comment 2 Sébastien Jodogne 2020-06-29 15:19:33 CEST

[BitBucket user: asch99]
[BitBucket date: 2017-03-14.18:09:56]

OK, turns out a time-out occurs in dul.cc: DUL_ReceiveAssociationRQ()

The issue can be solved by patching the dul.cc file of dcmtk-3.6.0, just replace line 627 with the corresponding line in dcmtk-3.6.1:
old: cond = PRV_NextPDUType(association, block, timeout, &pduType);
new: cond = PRV_NextPDUType(association, DUL_NOBLOCK, PRV_DEFAULTTIMEOUT, &pduType);

Comment 3 Sébastien Jodogne 2020-06-29 15:19:38 CEST

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2017-03-17.15:09:19]

fix issue #35

→ https://hg.orthanc-server.com/orthanc/changeset/bfcf5a7f92e7

Comment 4 Sébastien Jodogne 2020-06-29 15:19:39 CEST

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2017-03-17.15:12:38]

Thanks for your great investigation!

In order to benefit from the fix, you'll will have to compile the mainline version of Orthanc entirely in static mode (add the `-DSTATIC_BUILD=ON` flag to cmake), or statically link against DCMTK (add the `-DUSE_SYSTEM_DCMTK=OFF` flag to cmake).

Unfortunately, I have no way to test this fix by myself.