RadiAnt is padding odd transfer syntax strings to even. For example the following comes from RadiAnt as a acceptence response to implicitVRLittleEndian:
14:12:12 (2) IN 31 00 21 00 00 1A 07 00 00 00 40 00 00 12 31 2E
14:12:12 (2) IN 32 2E 38 34 30 2E 31 30 30 30 38 2E 31 2E 32 00
14:12:12 (2) IN 21 00 00 1C 09 00 00 00 40 00 00 14 31 2E 32 2E

Length of implicit VR LE (1.2.840.10008.1.2) is 17 characters (11 hex), but the response saying what has been accepted for PS 7 from the other end is 18 characters (12 hex in yellow) with an extra 00 appended. Association negotiation is not like the rest of DICOM – all characters are significant, and there is no padding to even boundaries, so the strings with and without the 00 character at the end are different strings with different lengths ….. hence RadiAnt is trying to “accept” something which was never offered.

RadiAnt also Proposes Transfer Syntax values with the superfluous 00 bytes. This may not be recognized. Again as above this is an attempt to pad odd lengths to even which is illegal in negotiation strings unlike the rest of Dicom.

Hi Jere,

Thank you for your precious remarks. Somehow it was missed when developing the PACS client. However, with many different PACS servers/workstations/modalities tested, we didn't encounter any problems resulting from this violation of the DICOM standard.
We will fix this issue, of course, in the next version.

Thanks again & kind regards,
Maciej