Storage service "promiscuous mode" (accept any SOP class)
See original GitHub issueI am implementing a catch-all storage service, that will accept associations from all kinds of different PACS’es out there, and store whatever is being sent to it in a C-STORE request. I would like the service to run in “promiscuous mode”, i.e. accept any kind of storage SOP class the SCU might request.
The Presentation Contexts documentation reads
While pynetdicom can handle association negotiation containing private abstract syntaxes the implementation of the associated services/semantics is up to the end user.
However, my understanding is that what is meant here is that you still have to define your private SOP classes, and then explicitly add them with AE.add_supported_context
. Looking at the code, I don’t see an easy was to say “I accept everything” (without monkey-patching pieces of pynetdicom
anyway).
A workaround would be to indeed define a list of SOP classes and manually add them, but I would like to avoid a situation where my service rejects an association because an SCU counterpart requested some weird private SOP class, that I did not add.
BTW, Orthanc for example does support this.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
When the Association object receives a DIMSE service request it calls uid_to_service_class() which is basically just a lookup function that determines which service class to use based on the contents of a bunch of dicts like
_STORAGE_CLASSES
. Modifying it with the private UID is the simplest way to add a new SOP Class to the Storage service.I had originally planned to add simpler ways of registering private SOP Classes but I didn’t think there’d be much call for it. This is the first request I’ve gotten for it.
@scaramallion We have the same requirement (for a test SCP). It seems that the Verification SOP Class is not accepted when the unrestricted mode is activated. I still needed to set
contexts=[build_context(Verification)],
. Not sure if that is intended and I did not look further into it. Without this, I got a EVT_REJECTED. Just thought might be worth noting this here for anyone requiring the same functionality.Edit: Just to mention: With the Verification SOP class set, everything works as expected and we are happy that this unrestricted mode exists and was implemented! 😃