DIMSE Failed to receive message (line=653)

[ArnaudIS]

Dear OFFIS forum users,

I am Arnaud, from the support team of an advanced radiology visualization software.
Sorry if my English is not perfect, I am not a native English speaker.

Our software's DICOM reception service is based on DCMTK StoreSCP/SCU.
With one of our customer's PACS, we encounter the following issue : some of the series that are getting pushed from their PACS to our DICOM reception service are not received (from what I've been able to reproduce, it seems that it only happens with CR and DX modalities, not with CT and MR ones).
The error we get is the following : 0006:020d DIMSE Failed to receive message (line=653)

Our software initially accepts any kind of transfer syntax (by default, it automatically accepts the first one proposed by the PACS).
The workaround we found is to only accept the following transfer syntax (instead of the first of the list) : Little Endian Implicit (though, it seems it causes issues with certain other studies, so it's not a 100% reliable workaround, sadly).


To help you, here is a sample of logs I got from these associations :

• Logs without forced transfer syntax (error, series not received):

11:28:39.72|DEB|qrscp |0000|5208| Association Acknowledged (3) (Max Send PDV: 32750)
11:28:39.72|DEB|logoutput |0000|5208| Presentation context: 15, Transfer syntaxes -> Abstract: 1.2.840.10008.5.1.4.1.1.1.1, Syntax: Little Endian Explicit(1.2.840.10008.1.2.1)
11:28:39.72|DEB|logoutput |0000|5208| Presentation context: 15, Transfer syntaxes -> Abstract: 1.2.840.10008.5.1.4.1.1.1.1, Syntax: Little Endian Implicit(1.2.840.10008.1.2)
11:28:39.72|DEB|logoutput |0000|5208| Accepted Presentation context: 15 using Transfer syntax: (Little Endian Explicit)1.2.840.10008.1.2.1
11:28:39.72|DEB|qrscp |0000|5208| Waiting for command on 0x0000000001F1C3F0 (3)
11:28:39.72|DEB|qrscp |0000|5208| Received STORE on 0x0000000001F1C3F0 (3)
11:28:39.72|DEB|storescp |0000|5208| Received C-STORE (Presentation Context used: 15)
11:28:39.72|DEB|storescp |0000|5208| Store Begin (3): CBCount(1), 0/8388608
11:28:39.72|ERR|storescp |0000|5208| Response to C-STORE failed
11:28:39.72|ERR|storescp |0000|5208| 0006:020d DIMSE Failed to receive message (line=653)
11:28:39.72|DEB|qrscp |0000|5208| Command handled on 0x0000000001F1C3F0 (3)
11:28:39.72|ERR|qrscp |0000|5208| DIMSE Failure (aborting association (3))
11:28:39.72|DEB|qrscp |0000|5208| QRSCP Thread 3 Ended
11:28:39.84|DEB|qrscp |0000|5988| About to start a new QRSCP Thread
11:28:39.85|DEB|qrjobs |0000|5988| New QR job slot used (created new slot). 4 slots in memory right now.
11:28:39.85|DEB|qrscp |0000|5988| Starting new QRSCP Thread(4)
11:28:39.85|DEB|qrscp |0000|5988| New QRSCP Thread(4) started (ID:0x08X; H:0x00000000000003B8)
11:28:39.85|DEB|qrscp |0000|4EC0| QRSCP Thread 4 started (OK)

• Logs with forced transfer syntax to Little Endian Implicit (no error, series received)

11:31:05.30|DEB|qrscp |0000|5130| QR Association Received (2) from DIAM4(192.9.102.100)
11:31:05.31|DEB|qrscp |0000|5130| Association Acknowledged (2) (Max Send PDV: 32750)
11:31:05.31|DEB|logoutput |0000|5130| Presentation context: 45, Transfer syntaxes -> Abstract: 1.2.840.10008.5.1.4.1.1.1.1, Syntax: Little Endian Explicit(1.2.840.10008.1.2.1)
11:31:05.31|DEB|logoutput |0000|5130| Presentation context: 45, Transfer syntaxes -> Abstract: 1.2.840.10008.5.1.4.1.1.1.1, Syntax: Little Endian Implicit(1.2.840.10008.1.2)
11:31:05.31|DEB|logoutput |0000|5130| Accepted Presentation context: 45 using Transfer syntax: (Little Endian Implicit)1.2.840.10008.1.2
11:31:05.31|DEB|qrscp |0000|5130| Waiting for command on 0x00000000DA15C310 (2)
11:31:05.32|DEB|qrscp |0000|5130| Received STORE on 0x00000000DA15C310 (2)
11:31:05.32|DEB|storescp |0000|5130| Received C-STORE (Presentation Context used: 45)
11:31:05.32|DEB|storescp |0000|5130| Store Begin (2): CBCount(1), 0/8388608
11:31:05.34|DEB|storescp |0000|5130| Store End (2): CBCount(135), 2176882/8388608
11:31:05.34|DEB|storescp |0000|5130| _ProcessBeginSeries (2)
11:31:05.35|DEB|qrscp |0000|5130| Command handled on 0x00000000DA15C310 (2)
11:31:05.35|DEB|qrscp |0000|5130| Waiting for command on 0x00000000DA15C310 (2)
11:31:05.35|DEB|qrscp |0000|5130| Association Released (2)
11:31:05.40|DEB|qrscp |0000|5130| QRSCP Thread 2 Ended
11:31:05.40|DEB|storescp |0000|5130| _ProcessEndSeries (2)
11:31:05.45|DEB|qrscp |0000|11C0| About to start a new QRSCP Thread
11:31:05.45|DEB|qrjobs |0000|11C0| New QR job slot used (created new slot). 3 slots in memory right now.
11:31:05.45|DEB|qrscp |0000|11C0| Starting new QRSCP Thread(3)
11:31:05.45|DEB|qrscp |0000|11C0| New QRSCP Thread(3) started (ID:0x08X; H:0x00000000000003C0)
11:31:05.45|DEB|qrscp |0000|5094| QRSCP Thread 3 started (OK)

To me, it looks like the PACS is not able to properly send the images as soon as the transfer syntax is set to Little Endian Explicit.
What do you think about that ? I told myself : "Maybe the CR and DX images are stored in Little Endian Implicit syntax (while MR and CT are stored in Little Endian Explicit, so that would explain why it works) and when the PACS tries converting them into Little Endian Explicit, an error occurs ?"

The problem is that the PACS owner rejects the fault on us without helping much, but honestly, I do not understand how this issue could be caused by our solution. Though, if you think I am wrong, please let me know

If anyone could help me, would be really appreciated, since we've been discussing this topic for several months with the PACS owner and the client, and no one has a reliable solution.

Thank you very much !
Arnaud

[Michael Onken]

Hi Arnauld,

I agree with you that probably the conversion at the PACS side fails. Maybe your client could at least check the PACS logs to see how the PACS experiences this error. Also, if possible, get one of the affected DICOM files in original format (as it is stored in the PACS), if possible, by email or temp folder or anything. If that is not possible, investigate the DICOM sample file after receiving it in one of the working transfer syntaxes. Sometimes there is an issue is with encoding of private sequences which has some caveats.

In order "free yourself from fault", you could maybe replace your own DCMTK-based received by another tool. However, if we assume that it is already the PACS that does not start sending at all, it probably makes sense to record the DICOM communication using Wireshark (having superb DICOM parsing support) and see whether the PACS actually starts sending the C-STORE-RQ to you. If replacing the DICOM implementation for testing on your side + Wirehsark sniffing shows the problem at the PACS, then it should be clear that you cannot do something about this error on your side.

BR Michael

[ArnaudIS]

Dear Michael,

Thank you very much for your explanations.
I will try setting up Wireshark on the server that receives studies, so I can clearly understand this behaviour. That's a good tip .
I tried with the DCMTK native app instead of our service and had the same results, but I will try checking if I can find another reception service that could make it.

Really helpful. If I finally find an answer to this, I will let you know, just in case it could help anybody else !

Kind regards,
Arnaud

[ArnaudIS]

Hi Arnauld,

I agree with you that probably the conversion at the PACS side fails. Maybe your client could at least check the PACS logs to see how the PACS experiences this error. Also, if possible, get one of the affected DICOM files in original format (as it is stored in the PACS), if possible, by email or temp folder or anything. If that is not possible, investigate the DICOM sample file after receiving it in one of the working transfer syntaxes. Sometimes there is an issue is with encoding of private sequences which has some caveats.

In order "free yourself from fault", you could maybe replace your own DCMTK-based received by another tool. However, if we assume that it is already the PACS that does not start sending at all, it probably makes sense to record the DICOM communication using Wireshark (having superb DICOM parsing support) and see whether the PACS actually starts sending the C-STORE-RQ to you. If replacing the DICOM implementation for testing on your side + Wirehsark sniffing shows the problem at the PACS, then it should be clear that you cannot do something about this error on your side.

BR Michael

Michael,

Sorry for bothering again. There are lots of information to check, so I tried finding something inconsistent.
According to you, could this be the reason why the data might not be received ?

Source : 192.9.102.100 Destination : 192.168.101.100 Protocol : DICOM Length : 224 Info : P-DATA, Command ID=42169 (Success)
>Frame 6207: 224 bytes on wire (1792 bits), 224 bytes captured (1792 bits) on interface \Device\NPF_{XXXXXXXXXXXXXXXXX}, id 0
>Ethernet II, Src: Microsof_YYYYYYYYYYYYYYYYYYY, Dst: Routerbo_ZZZZZZZZZZZZZZZZZ
>Internet Protocol Version 4, Src: 192.9.102.100, Dst: 192.168.101.100
>Transmission Control Protocol, Src Port: 104, Dst Port: 57624, Seq: 190, Ack: 4115020, Len: 170
> DICOM, Command ID=42169 (Success)
__PDU Type: Data (0x04)
__PDU Length: 164
_> PDV, Command ID=42169 (Success)
______PDV Length: 160
______Context: 0x51 (Explicit VR Little Endian, Ultrasound Image Storage)
______Flags: 0x03 (Command, Last Fragment)
_____>(7fe0,0010) 3686400 Pixel Data [OW] <incomplete>
__________[Expert Info (Error/Malformed): Early termination of tag. Data is missing]

I could send the whole file but I guess it includes sensitive client's DATA so it's a bit tricky.

Thanks again.

[Marco Eichelberg]

That could mean that the Wireshark capture is incomplete, or that the network connection was dropped by the PACS before the image transmission was complete, e.g. because the sending process crashed. That would also explain the error message on your side. Unfortunately that will be difficult to debug on the receiving side alone.