[Bugzilla user: tn@osimis.io]
[Bugzilla date: 2023-11-23T17:06:52+00:00]
Whilst attempting to transfer data to a DICOM server via C-STORE (Orthanc as SCU), Orthanc replies that it cannot transcode from an arbitrary transfer syntax to `[ ]` (seemingly an empty list/set of transcoding targets).
**What steps will reproduce the problem?**
Make sure Orthanc is loaded with a study and a modality is configured which explicitly rejects an SOP class of at least one SOP instance used in that study during the DICOM association.
Instruct Orthanc to transfer it via C-STORE using its HTTP API (`/modalities/{id}/store`).
Note: The problem is likely to happen when requesting a C-MOVE via the DICOM listener as well (in place of the HTTP API) as it appears specific to a C-STORE request.
**What is the expected output? What do you see instead?**
By inspecting network traces we could determine with ~high confidence that an _abstract_ syntax (in this case an SOP class) was not supported by the peer C-STORE SCP (_not_ a transfer syntax), and we believe this to nevertheless be the source of the error report.
```
Presentation Context: ID 0x67, Abstract Syntax Unsupported, Grayscale Softcopy Presentation State Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 27
Context ID: 0x67
Result: Abstract Syntax Unsupported (0x3)
Transfer Syntax: Explicit VR Little Endian (1.2.840.10008.1.2.1)
Item Type: Transfer Syntax (0x40)
Item Length: 19
Transfer Syntax: Explicit VR Little Endian (1.2.840.10008.1.2.1)
Presentation Context: ID 0x69, Abstract Syntax Unsupported, Grayscale Softcopy Presentation State Storage
Item Type: Presentation Context Reply (0x21)
Item Length: 25
Context ID: 0x69
Result: Abstract Syntax Unsupported (0x3)
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
Item Type: Transfer Syntax (0x40)
Item Length: 17
Transfer Syntax: Implicit VR Little Endian: Default Transfer Syntax for DICOM (1.2.840.10008.1.2)
```
(Association response.)
Under that scenario, the expected output would be an error message along the lines of "Abstract syntax/SOP class {uid} ({name}) of SOP instance {uid} (Orthanc ID: {orthanc-id}) not supported by peer DICOM AE C-STORE SCP {modality-aet} (Orthanc ID: {orthanc-id}) per DICOM association negotiation of presentation contexts. Skipping instance. [Aborting the transfer of rest of the instances.] Warning: Successfully transferred instances will not be automatically deleted from the peer which may now contain a partial set of instances."
Instead, we observe the following:
```
{
"Details" : "Cannot transcode from 1.2.840.10008.1.2.1 to one of [ ]",
"HttpError" : "Internal Server Error",
"HttpStatus" : 500,
"Message" : "Not implemented yet",
"Method" : "POST",
"OrthancError" : "Not implemented yet",
"OrthancStatus" : 2,
"Uri" : "/modalities/REDACTED/store"
}
```
Unfortunately, the error report is not actionable as the real problem does not seem to relate to transcoding, the target set of SOP classes is confusingly empty, the HTTP status code suggests a problem with Orthanc whereas the root problem lies with the configuration/support of the remote peer, and the message "not implemented yet" suggests missing code whereas (presumably) no amount of client-side changes can circumvent the root error condition.
This suggests the program may be genuinely trying to transcode transfer syntaxes when it shouldn't have attempted to do so (i.e. "went down the wrong code path").
Sidenote: In cases where the full set of SOP instances is known prior to establishing the DICOM association (most/all cases with Orthanc), it is possible to gracefully abort the DICOM association gracefully without attempting to transfer any SOP instances, thus preventing partial sets of SOP instances to be transferred when that might be undesirable.
**What version of the product are you using? On what operating system?**
v1.12.1 on CentOS 7 via Docker/OCI container base image `osimis/orthanc:23.7.0` (Debian). |