PDU dump in log files

[Jonathan]

Hi all,

it has been a while since I have been here, but today I was asked to investigate a DICOM connectivity problem involving a PacsONE server (v6.1.3).

After a C-STORE session invoked from the PacsONE server communication is setup OK, association is made error free, the data is transferred over the line OK, but after that an error occurs and the P-DATA-TF PDU is dumped.

My main question is is the PDU dumped the full PDU or only the first bytes? Is the first byte (containing the type) also dumped? The PDU I recieve startes with a 00H value which should never be the case as it should contain a non zero value and in this case 04H IIRC.

Any of the developers able to answer my question so I can investigate further?

[pacsone]

The PDU dump does not include the PDU header, only the content of the PDU which includes both the PDV header and PDV content.

[Jonathan]

The PDU dump does not include the PDU header, only the content of the PDU which includes both the PDV header and PDV content.

Perhaps you can help me explain this error then:

Code: Select all

Fri Apr 16 11:50:26 2010 DEBUG - <2> PDV message header: [3] length: [54]
Fri Apr 16 11:50:26 2010 INFO - <2> C-STORE-RSP [3] command received in P-DATA-TF PDU
Fri Apr 16 11:50:26 2010 ERROR - Unrecognized command in P-DATA-TF PDU: 1
Fri Apr 16 11:50:26 2010 DEBUG - 00 00 00 36 03 03 00 00 00 00 04 00 00 00 28 00 00 00 00 00 00 01 02 00 00 00 01 80 00 00 20 01 02 00 00 00 01 00 00 00 00 08 02 00 00 00 01 01 00 00 00 09 02 00 00 00 00 00 
Fri Apr 16 11:50:26 2010 DEBUG - Session: <2> starting READ for 6 bytes
Fri Apr 16 11:51:14 2010 DEBUG - Session: <2> I/O completed with 6 bytes
Fri Apr 16 11:51:14 2010 ERROR - <2> Received A-ABORT PDU, aborting

I have read up on the PDV contents and first four bytes are the size of the payload (54 bytes, which seems correct). The first following byte should then be the Presentation Context ID (03), but then I am lost.

The PDV, IMHO, should then be:

Code: Select all

03 00 00 00 00 04 00 00 00 28 00 00 00 00 00 00 01 02 00 00 00 01 80 00 00 20 01 02 00 00 00 01 00 00 00 00 08 02 00 00 00 01 01 00 00 00 09 02 00 00 00 00 00

Is that correct? Where can I find pointers on how to interpret this PDV?

[pacsone]

The structures of the PDU and PDV are specified in details in PS 3.8 of the Dicom standards.

For the dumped PDU content you posted, the first 4 bytes is the PDV Length which is 54 bytes (0x36). The next byte is the Presentation Context ID (0x3), the next byte is the PDV header (0x3), followed by the content of the PDV which is a C-STORE-RSP (detailed in PS 3.7 of the Dicom standards), which includes a bogus (0000,0001) data element that has been retired in version 3.0 of the Dicom standards. This is the offending data element that was causing the error logged by PacsOne Server, as it's developed based on the Dicom 3.0 protocol and does not support such retired data elements.

[Jonathan]

The structures of the PDU and PDV are specified in details in PS 3.8 of the Dicom standards.

I was already looking there... must have been overlooking it.

For the dumped PDU content you posted, the first 4 bytes is the PDV Length which is 54 bytes (0x36). The next byte is the Presentation Context ID (0x3), the next byte is the PDV header (0x3) followed by the content of the PDV

That is what I already discovered so far indeed, based on the DICOM documentation.

which is a C-STORE-RSP (detailed in PS 3.7 of the Dicom standards), which includes a bogus (0000,0001) data element that has been retired in version 3.0 of the Dicom standards. This is the offending data element that was causing the error logged by PacsOne Server, as it's developed based on the Dicom 3.0 protocol and does not support such retired data elements.

Thanks, that is a very clear analysis, I was hoping to find myself. I will try and re-read the docs to see if I can find the last part of the missing link myself as well.

Now I can contact the other party and see if we can fix the issue on their side. Once again, thanks very much.

[Jonathan]

The structures of the PDU and PDV are specified in details in PS 3.8 of the Dicom standards.

For the dumped PDU content you posted, the first 4 bytes is the PDV Length which is 54 bytes (0x36). The next byte is the Presentation Context ID (0x3), the next byte is the PDV header (0x3), followed by the content of the PDV which is a C-STORE-RSP (detailed in PS 3.7 of the Dicom standards), which includes a bogus (0000,0001) data element that has been retired in version 3.0 of the Dicom standards. This is the offending data element that was causing the error logged by PacsOne Server, as it's developed based on the Dicom 3.0 protocol and does not support such retired data elements.

Would this be the correct way to decode the PDU?

The first element seems to be:

0000, 0000 Command Group Length UL

It should contain 4 bytes of data which would be 28h (40), which seem to be consistent with the following 4 10 byte groups as this tag should hold the Command Group Length according to PS3.7-2008, 9.3.1.2. C-STORE_RSP.

Code: Select all

00 00 00 00 04 00 00 00 28 00 00 00

This would then be the offensive tag (0000, 0010) tag IMHO:

Code: Select all

00 00 00 01 02 00 00 00 01 80

However I am not sure if your application is handling it correctly as PS3.7-2008 6.3.1 Command Set Structure, note 1 states:

The Message Length-to-End (0000,0001) Command Element is retired. Implementations may choose
to send it for backward compatibility reasons. DICOM V3.0 conformant implementations must not rely on
its presence for their operation.

Shouldn't that mean that DICOM 3.0 based applications should handle this graciously or are they allowed to error out on it?

Below would be the last three tags:
(0000, 2001):

Code: Select all

00 00 20 01 02 00 00 00 01 00

(0000, 0008):

Code: Select all

00 00 00 08 02 00 00 00 01 01

and (0000, 0009):

Code: Select all

00 00 00 09 02 00 00 00 00 00

Is above decoding correct? If that is the case all four tags seem incorrect to me as, to the best of my knowledge, as they are not listed in PS3.7-2008, 9.3.1.2. C-STORE_RSP.

[pacsone]

You seem to be running an older version of PacsOne Server which would throw an error for this retired/incompatible (0000,0001) data element, but the latest version 6.2.2 of PacsOne Server will accommodate this offending data element and will simply ignore it (instead of throwing the error). So if you could upgrade to the latest version of PacsOne Server, you will see a Warning (instead of Error) logged for this offending data element and PacsOne Server will proceed to receive the rest of the images (instead of rejecting them).