[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).

[Bugzilla user: s.jodogne@gmail.com]
[Bugzilla date: 2023-12-20T11:28:58+00:00]

Adding a reference to a thread from the old Google Group forum that might be related:
https://groups.google.com/g/orthanc-users/c/vPpEzsgpUbg


"Hello all, today has been error day. earlier today i posted a thread about transcoding errors but it was never posted?
and now I have a new tale.

first of all I'm using version 1.10.1  if that helps.
since the transcoding convo is still missing I'm gonna write it all again.....

We recently acquired a new CT scanner from the Neusoft brand(first week actually). now we have an old GE Brigtspeed that has been feeding orthanc since 2021.
we can send studies to orthanc from both modalities without problem, the old GE never got along with the retrieval of data from orthanc, and the GE reps were cold to integration so we got the config for the retrieval in the equipment but it never worked. and management didn't care. with the new CT right from the beginning it was configured to send and receive data from orthanc by the brand reps. so feeding orthanc goes perfectly, retrieving data.....so-so, it does retrieve the 3d image stills, the images sent to the film printers and other "Save State" type images but the gross and fine images used by both the CT and the dicom viewers to actually work the studies are not retrieved and the error reported by the neusoft software is the same as orthanc:

"E0331 10:23:44.744361 OrthancException.cpp:58] Not implemented yet: Cannot transcode from 1.2.840.10008.1.2.1 to one of [ ]
E0331 10:24:27.156329 OrthancException.cpp:58] Not implemented yet: Cannot transcode from 1.2.840.10008.1.2.1 to one of [ ]"

I know there must be a setting that can be tweaked to please the machine spirits of both AET , I don't know if I need to go to a newer version or its something I've overlooked, any advice would be appreciated.

now second error tale:

today in the middle of  transmission of x-ray still from an Agfa MUSICA workstation the errors started popping 1 still got though the other 2 from the same patient didn't. from then one not a single patient has ben successfully transferred.

"E0410 16:13:25.845145 StoreScp.cpp:273] Store SCP Failed: DIMSE: Odd Fragment Length: 4097
E0410 16:15:25.912303 StoreScp.cpp:273] Store SCP Failed: DIMSE: Odd Fragment Length: 4097
E0410 16:16:53.809853 StoreScp.cpp:273] Store SCP Failed: DIMSE: Odd Fragment Length: 4097
E0410 16:18:25.913375 StoreScp.cpp:273] Store SCP Failed: DIMSE: Odd Fragment Length: 4097
..."

 
there are 10 or 20 more errors all the same from different still images. the weird thing is nothing was changed today, 1 second working fine the next nope not doing anything. I've rebooted both the server and workstation multiple  times and no dice, now I'm considering rebooting the network so any gremlins go away.
anyone else seen this before? 

ANYWAY, thx in advance for any help with either problem. if this one doesn't post ill repost it tomorrow."

[Bugzilla user: am@orthanc.team]
[Bugzilla date: 2024-01-22T16:36:45+00:00]

@Thibault:  We had the same kind of errors with a Télémis PACS and we fixed it in 1.12.2 (commit: https://orthanc.uclouvain.be/hg/orthanc/rev/ac68a4383e51).  

The negotiation were not consistent and we finally decided to force a renegotiation even if the PACS previously claimed it would not support that StorageClassUID/TransferSyntax type.  It happened that when asking for that tuple a second time, it accepts it.

Could you give 1.12.2 a try and come back to us if you still have the issue ?  If the issue happens again, please record the DICOM negotiation in TRACE mode.

HTH,

Alain.

[Bugzilla user: tn@osimis.io]
[Bugzilla date: 2024-01-22T17:49:53+00:00]

Nice, gotcha!

As it happens I confirm we also encountered this when interacting with a Telemis PACS. In our case however Telemis was able to swiftly authorize the relevant SOP class on request by the customer in question, further indicating that it was, quote, "very simple to do". I'm thus not sure we hit a bug (rather just a policy which needed to be tweaked) but can't confirm whether this is related. The customer is now running with that PACS configuration in production so I don't feel comfortable asking them to revert the policy just to check. We may do this opportunistically during a maintenance window if they are confident nothing else started depending on it--I've taken note of the need to enable TRACE mode.

Regardless I don't think this part matters terribly: TBH I wasn't even expecting a workaround from Orthanc (it was never Orthanc's problem to solve IMHO). Rather, I merely intended to suggest for Orthanc to fail earlier and by reporting an actionable error message. I can't immediately tell if the patch addresses this; if not I fear that if any DICOM peer consistently rejects an SOP class UID by policy in a similar fashion, it will remain difficult for an Orthanc operator to determine their next step (i.e. request authorization to an administrator) without performing a network capture or finding this issue and taking a guess.

WDYT?

[Bugzilla user: am@orthanc.team]
[Bugzilla date: 2024-01-23T08:23:04+00:00]

I suggest we leave it as is and close investigations since everybody seems ok with the current situation/workarounds.