[Colby], [Print SCP] IDicomNServiceProvider and DicomN*Request

[Hesham Desouky]

Hello All,

I am in the middle of DICOM Print SCP implementation. I faced several issues in the DicomService and DicomN*Request classes implementation as follows:

1.  DicomService stops the communication if the request SOP class UID is not in negotiated presentation contexts. This will cause the connection to hang between the SCU and SCP. I know that from the standard all PCs should be negotiated prior to request/response operations, but several DICOM vendors (software and hardware) is not respecting this. I suggest to modify the DicomService class to have an option to work with first presentation context if request SOP class is not in negotiated list.
   
2. DicomN*Request classes are not handy at all, it should support specifying AffectedInstanceUID and result dataset (to set the CommandDataSetType to 0x0202 automatically)

Should I proceed to these changes in my branch or you have another suggestion?

Please advice.

Hesham

[Chris Horn]

Hesham,

I'd say follow the standard, the last thing we need is new software that doesn't conform.

I currently use a hybrid solution that uses both mdcm for the communication and Fo-Dicom for the imaging.

The issues you mentioned I seen seem to be manufacture specific, however I was able to bypass the issues by getting the vendor to turn off particular features in the printers SCP (Fuji).

We should follow the Dicom Standard and then have a specific overload for these edge cases

[Hesham Desouky]

Thank you Chris for your input, but as you know when developing SCP you have to deal with different manufacturers inconsistencies and bad standard implementation and much more legacy systems.

I think it will  be better to have new setting in the DicomService class to not abort in certain implementations. Standard is great but not all vendors are following it :(.

[Chris Horn]

I know where your coming from.
I'd love see what you have and maybe help test it for you

[Hesham Desouky]

Hello Chris,

I found the main cause of the problem, the current implementation of DicomService class is not considering Meta classes like Basic Grayscale Print Management Meta SOP Class.

As you know Meta classes can be requested in the Association request which implicitly a request for other SOP classes. In our case these will be the Basic Film Session, Basic Film Box and Basic Grayscale Image Box SOP Classes.

I modified the DicomService to send the N-* responses using the requested presentation context in first place. I will pull my update soon to GitHub for your review but this I need to know Colby opinion for the applied modification.

Thanks for your support.