Association release failure

Dear Marcel, community

I have a Conquest server that receives various objects to be fed into our radiation dose monitoring software OpenREM (http://openrem.org). This has been running without incident for some time.

A new modality is now failing to work correctly. The image is sent from the modality, it is received and processed, but the association is not released. After 300s, Conquest aborts the connection.

The vendors have looked at the logs, and point out that the wrong context ID number is being sent back from Conquest, and therefore the association is not released. In the logs below from the modality side you will see that the context id for message in the C-Store-Rq is 5, whereas the context id for message in the C-Store-Rsp is 3:

Quote

Code

DCF Application: Hologic.DicomStore.6840 Component: cs_lib/DCS Error Code 0
session_name=AETFrom:10.111.222.128:49271==>AETTo:10.111.222.41:104::2014/05/23::10:48:45.093::6840.0
queueing outbound dimse message: (28649262)
context id for message = 5
C-STORE-RQ:
Command:
(0000, 0002) UI( 30) Affected SOP Class UID          1.2.840.10008.5.1.4.1.1.1.2.1 (Digital Mammography X-Ray Image Storage - For Processing)
(0000, 0100) US(  2) Command Field                   1 (0x0001)
(0000, 0110) US(  2) Message ID                      0 (0x0000)
(0000, 0700) US(  2) Priority                        0 (0x0000)
(0000, 0800) US(  2) Data Set Type                   256 (0x0100)
(0000, 1000) UI( 44) Affected SOP Instance UID       1.2.840.113681.181591680.1400839622.4864.490
Data:
(0008, 0005) CS( 10) Specific Character Set          ISO_IR 100
(0008, 0008) CS( 16) Image Type                      ORIGINAL\PRIMARY
(0008, 0016) UI( 30) SOP Class UID                   1.2.840.10008.5.1.4.1.1.1.2.1 (Digital Mammography X-Ray Image
…


DCF Application: Hologic.DicomStore.6840 Component: cs_lib/DCS Error Code 0
session_name=AETFrom:10.111.222.128:49271==>AETto:10.111.222.41:104::2014/05/23::10:48:45.093::6840.0
Received DIMSE message (12036987) from 10.111.222.41:104
context id for message = 3
C-STORE-RSP:
Command:
(0000, 0000) UL(  4) Group Length                    130 (0x00000082)
(0000, 0002) UI( 30) Affected SOP Class UID          1.2.840.10008.5.1.4.1.1.1.2.1 (Digital Mammography X-Ray Image Storage - For Processing)
(0000, 0100) US(  2) Command Field                   32769 (0x8001)
(0000, 0120) US(  2) Message ID Being Responded To   0 (0x0000)
(0000, 0800) US(  2) Data Set Type                   257 (0x0101)
(0000, 0900) US(  2) Status                          0 (0x0000)
(0000, 1000) UI( 44) Affected SOP Instance UID       1.2.840.113681.181591680.1400839622.4864.490

Display More

Do you have any ideas about what may be happening, and whether there is something I can do about it! The current situation is that the image is sent to the dose server (successfully), 5 minute time out, the image is sent again, 5 minutes time out, the image is sent a third time, times out then is marked as failed. Then the next image starts!

I appreciate any help you may be able to give.

Kind regards

Ed

P.S. I tried searching for any previous examples in this forum, but any query I came up with was either ignored for having too short words or too common words, or returned 16 pages (no matter what the search terms).

Thanks Marcel

When we took the logs, I did a successful store to Conquest on Windows before doing the unsuccessful store to Conquest on linux, so I have asked the vendor's engineer to send me the full set of logs so we can take a look.

I'll get back to you as soon as I can get them.

Thanks Marcel.

I have the logs now, and have cleaned them up as best I can (without losing anything useful hopefully).

Can I email them to you? Can you pm me the best email to use please?

Kind regards

Ed

Marcel has worked on this for me, and we think we know what the problem is.

If Conquest offers more than one transfer presentation syntax (eg JPEG or not), then the two systems negotiate as expected on which one to use, with each one being referred to by a Context ID. The problem is that when the transfer successfully completes Conquest doesn't necessarily specify in the associated message the context ID that was actually used. If they don't match, then Hologic won't release the association, leading to Conquest to abort it on timeout. No other system I have used cares whether the context ID matches or not, hence not seeing a problem with any other modality.

Two solutions, that I haven't been able to test due to access to the system (but will on Tuesday):
1/ Reduce the number of presentation syntaxes available by hashing them out in dgatesop.lst, forcing the right context ID to be returned
2/ Marcel has engineered a fix in the latest beta of 1.4.17e that he has shared with me privately. I aim to test this on Tuesday too.

I hope that helps.

Kind regards

Ed

Marcel - thanks for working with me to fix this.

I have now tried the following, with the associated results:

• Linux 1.4.16i, 64 bit, any more than one transfer syntax un-hashed in dgatesop.lst (including just explicit and implicit): Association release fails
• Linux 1.4.16i, 64 bit, just one transfer syntax un-hashed in dgatesop.lst (explicit little endian): Association release successful
• Windows 1.4.17, 32 bit, JPEG support disabled: Association release successful
• Windows 1.4.17, 32 bit, JPEG support enabled: Association release fails
• Windows 1.4.17e1, 32 bit, JPEG support disabled: Association release successful
• Windows 1.4.17e1, 32 bit, JPEG support enabled: Association release successful

So Marcel, from my testing your proposed fix in 1.4.17e1 has worked.

Thank you very much.

I have yet to roll out a fresh install of the Windows client to check the full dgatesop.lst to look for the missing image and report objects - I will when I get a chance.

Thanks again

Ed