Retrieve of Images Fails

[magnotta]

I mahe setup imagectn on a RedHat 9 system. I am able to push images to the machine running imagectn and query the studies on the imagectn server. However, whenever the images are retrieved from a remote system, the retrieval fails. The error message reported is "moveSCP: Sub-Association Request Failed". This error message results from both GE and Siemens systems requesting image retrievals.

[Marco Eichelberg]

A failed sub-association request usually means that ImageCTN is unable to create the second DICOM connection from ImageCTN to the target machine that is used in DICOM to deliver the images requested through a C-MOVE command. ImageCTN uses a configuration file to resolve the symbolic network address (Move AE Title) communicated as part of the C-MOVE request into a real network address (i.e., IP address and port number). Most likely this configuration is not correct. The configuration file is described in "ctnconf.txt".

[magnotta]

The same machines that I am using to query and send images fail on the Retrieve requests. I don't believe that the problem is with the Move AE Title. I ran imagectn with the -v and -d options and here is some summary information.


Move SCP Request Identifiers:

# Dicom-Data-Set
# Used TransferSyntax: LittleEndianImplicit
(0008,0000) UL 26 # 4, 1 IdentifyingGroupLength
(0008,0001) UL 138 # 4, 1 ACR_NEMA_IdentifyingGroupLengthToEnd
(0008,0052) CS [SERIES] # 6, 1 QueryRetrieveLevel
(0020,0000) UL 112 # 4, 1 ImageGroupLength
(0020,000d) UI [1.3.12.2.1107.5.2.13.20594.4.0.1524337018432476] # 48, 1 StudyInstanceUID
(0020,000e) UI [1.3.12.2.1107.5.2.13.20594.4.0.1531548454472172] # 48, 1 SeriesInstanceUID
Host and Port: adw3:2100
Request Parameters:
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.5.2
Our Implementation Version Name: OFFIS_DCMTK_352
Their Implementation Class UID:
Their Implementation Version Name:
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: MR_Storage
Called Application Name: ADW
Responding Application Name: resp AP Title
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
imagectn: moveSCP: Sub-Association Request Failed:
0006:031b Failed to establish association
0006:0317 Peer aborted Association (or never connected)
0006:031c TCP Initialization Error: Connection refused
imagectn: moveSCP: Sub-Association Release Failed:
0006:0106 ASC Caller passed in a NULL key
Requesting Sub-Association 165813456 165882896
Releasing Sub-Association
Move SCP Response 1 [status: Refused: OutOfResourcesSubOperations]
DIMSE Command To Send:

Is there any information that will help debug my problem here? I understand most of the information, but does the value for "Responding Application Name" incorrect or NULL.

[Marco Eichelberg]

I think the error message is very clear:

Code: Select all

imagectn: moveSCP: Sub-Association Request Failed:
0006:031b Failed to establish association
0006:0317 Peer aborted Association (or never connected) 

This means that imagectn has tried to establish the second DICOM connection to the receiving system, but the receiving system has not accepted the connection under the IP address and port number configured in imagectn's configuration file. This might be due to a firewall/packet filter or to an incorrect configuration of imagectn.

[magnotta]

Based on some additional debugging here is what I have been able to determine:

1) No firewall exists between the two machines
2) imagectn will store images and respond to requests from the same machine. Therefore the port and machine are configured properly in the configuration file.
3) The sub association port request occurs on the same port used to send data to imagectn. I have tested both ports 104 and 2100.

I have put some additional debugging statements in scemove.cc in buildSubAssociation() and verified point 3. In ASC_requestAssociation I have printed out the network structure information that reoprts the following:
Role = 2, Port=104, Network=KEY NETWORK
This is the case when I have configured both imagectn anhd the GE Advantage workstation to use port 104.

Is their a straightforward method to debug this issue and determine why imagectn is unable to send images in response to a moveSCP request?

[Marco Eichelberg]

The fact that imagectn stores images and responds to requests does not mean that the port and machine are correctly configured - this is a frequent misconception and this is what I'm trying to explain. Within the C-MOVE protocol, the client sends a request to the server asking to send certain images to a certain place. This "certain place" may be the client itself or a totally different system and is only identified by a symbolic AETITLE. The server now tries to establish a second DICOM assocition from the server to the image receiver which may or may not be identical to the requesting system. In your case this second association setup from imagectn to the image receiver fails.

If you believe to have everything correctly configured, try echoscu or storescu on the machine that runs imagectn, using the same calling/called AETITLE and port number that you have configured for imagectn and try to "manually" push an image to the GE machine. If this works, imagectn should also work because it is internally using the same code.