• DICOM Association question

    From Mack@21:1/5 to All on Mon Aug 23 16:04:29 2021
    Suppose an SCU sends an an A-ASSOCIATE request containing exactly two presentation Contexts (two different abstract syntaxes) to a storage-SCP.

    The Storage-SCP does not support either presentation context (does not support either abstract syntax).

    What should the storage-SCP A-ASSOCIATE response be?

    1.
    Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".

    2.
    Send associate Reject.
    Part 3.8, 7.1.1.9 lists valid reasons for association rejection. None seem to describe the case where the association is rejected because no proposed presentation contexts are supported.
    Which would be the correct reason for rejection?


    Are both (1) and (2) above correct?
    (1) seems like it gives more information to the SCU then (2).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to All on Thu Sep 2 07:16:13 2021
    I agree that

    1.
    Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".


    sounds more sensible, but I don't know any statement in the standard text which explicitly forbid

    2.
    Send associate Reject.
    Part 3.8, 7.1.1.9 lists valid reasons for association rejection. None seem to describe the case where the association is rejected because no proposed presentation contexts are supported.
    Which would be the correct reason for rejection?

    E.g.
    Result: 1 - rejected-permanent
    Source: 1 - DICOM UL service-user
    Reason: 1 - no-reason-given


    Are both (1) and (2) above correct?
    (1) seems like it gives more information to the SCU then (2).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Sabin@21:1/5 to gunter zeilinger on Fri Sep 3 04:18:58 2021
    gunter zeilinger schrieb am Donnerstag, 2. September 2021 um 16:16:14 UTC+2:
    I agree that
    1.
    Send associate Accept with the status of each presentation context as "abstract-syntax-not-supported (provider rejection)".

    sounds more sensible, but I don't know any statement in the standard text which explicitly forbid

    Agreeed. But I think that PS3.8, 7.1.2.4
    If the acceptor accepts the association, the association is available for use. Both AEs may now use any service provided by the DICOM application context that is in effect (with the exception of A-ASSOCIATE).
    Note
    This implies that once the association has been established, DICOM Messages can be exchanged as defined in PS3.7.

    and 7.1.2.6
    The UL service-provider may not be capable of supporting the requested association. In this situation, it shall return an A- ASSOCIATE confirmation primitive to the requestor with an appropriate Result parameter (rejected). The Result Source parameter
    shall be appropriately assigned either the symbolic value of "UL service-provider (ACSE related function) " or "UL service-provider (Presentation related function)." The indication primitive shall not be issued. The association shall not be established.

    could be understood in a way that if no acceptable PC is proposed:
    - no DICOM messages can be exchanged as defined in PS3.7
    - the UL service provider is not capable of supporting the requested association
    - the association should be rejected with "UL service-provider (Presentation related function)."

    This is my interpretation, admittedly one could probably reason against it, and accepting the association but rejecting all PCs yields a much better way of conveying "why it does not work"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)