[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?