Support for multiple ae_titles on same IP/port

[aamcurtis]

Looking over the ul/server code. There appears to be an edge case in the DICOM standard that isn't supported:

• A single network access point (IP Address and TCP Port) can support multiple Application Entity Titles. Section C2 bullet 3

Although covered by the promiscuous mode, I believe the code should be able to accept multiple specified AE titles and reject anything that isn't specified.

For context, I'm evaluating this library to move over from an aging proprietary library and this is a feature that is heavily leaned on, so may try to develop this feature and contribute it with some guidance!

[Enet4]

Thank you for reporting, that makes sense. Let me know if you need assistance.

[jjedele]

Hey,

I'm looking for something similar (working on a proxy-style application which would do some downstream logic depending on what was the called AE title during the transfer).

Now I'm thinking how this would look like. It seems it should already be possible to handle association establishment pretty naturally due to the option to write custom AccessControls which get the called AE title. Would just need to write one containing a list of multiple AE titles and check against that.

The problem is, after the association is established, there is no record anymore of the called AE title. Would it make sense to just add this as another field to ServerAssociation?

[jjedele]

In case it helps anyone, here is a rather ugly workaround which manages to do the same with version 0.8.0 as is:

struct AssociationContext {
    called_ae_title: String,
    calling_ae_title: String,
    user_identity: Option<dicom::ul::pdu::UserIdentity>,
}

struct ContextPreservingAccessControl<'a> {
    permissible_ae_titles: Vec<&'a str>,
    context: &'a mut OnceCell<AssociationContext>,
}

impl<'a> AccessControl for ContextPreservingAccessControl<'a> {
    fn check_access(
        &self,
        this_ae_title: &str,
        calling_ae_title: &str,
        called_ae_title: &str,
        user_identity: Option<&dicom::ul::pdu::UserIdentity>,
    ) -> dicom::ul::association::server::Result<(), dicom::ul::pdu::AssociationRJServiceUserReason>
    {
        if self
            .permissible_ae_titles
            .iter()
            .any(|permissible_ae_title| called_ae_title == *permissible_ae_title)
        {
            let ae = AssociationContext {
                called_ae_title: called_ae_title.to_string(),
                calling_ae_title: calling_ae_title.to_string(),
                user_identity: user_identity.map(|ui| ui.clone()),
            };
            self.context.set(ae);
            Ok(())
        } else {
            Err(dicom::ul::pdu::AssociationRJServiceUserReason::CalledAETitleNotRecognized)
        }
    }
}

// this is the relevant code where the association is established

fn handle_connection() {
    let mut association_context_cell: OnceCell<AssociationContext> = OnceCell::new();
    let access_control = ContextPreservingAccessControl {
        permissible_ae_titles: vec!["AE1", "AE2"],
        context: &mut association_context_cell,
    };
    let mut options = dicom::ul::association::ServerAssociationOptions::new()
        .ae_access_control(access_control)
        .ae_title(calling_ae_title);

    let mut association = options
        .establish(scu_stream)?;
    let assocation_context = association_context_cell.get().unwrap();

    info!(
        "New association from {} to {}",
        assocation_context.calling_ae_title,
        assocation_context.called_ae_title
    );
}