C-MOVE operating locally only

[MatheusVieira2001]

I'm implementing a C-MOVE operation using the pynetdicom library. However, the process only works correctly in a local environment. When an external medical device attempts to retrieve the images, the operation fails.

The C-FIND operation is working perfectly. The issue occurs exclusively with C-MOVE, and only when the destination is not the local machine itself.

my handle_c_move

ae, assoc = prepare_association(destination_info)
if not assoc or not assoc.is_established: 
    yield 0xA801, None 
    return 

total_sent = send_files(datasets, assoc) 
assoc.release() 
yield (0x0000, None)

Locally it works perfectly as I mentioned only when I move to any other IP the image is not received, test carried out by radiant/sant free/orthanc

Configuration - SCP

handlers = [
        (evt.EVT_C_GET, handle_c_get),
        (evt.EVT_ACCEPTED, handle_accepted),
        (evt.EVT_C_ECHO, handle_echo),
        (evt.EVT_C_FIND, handle_find),
        (evt.EVT_C_MOVE, handle_c_move),
    ]
ae.start_server(('', 10001), block=True, evt_handlers=handlers)]

Is there something I'm forgetting to make it work from anywhere, not just on the server itself?

pydicom: 3.0.1 pynetdicom: 3.0.3

[scaramallion]

Don't return in the EVT_C_MOVE handler, or call assoc.release(). yield str(total_images) should just be yield total_images.

You don't need to do this:

ae, assoc = prepare_association(destination_info)
if not assoc or not assoc.is_established: 
    yield 0xA801, None 
    return 

total_sent = send_files(datasets, assoc) 
assoc.release() 
yield (0x0000, None)

At this stage you should just be iterating through and yielding the matching instances as (0xFF00, instance). pynetdicom will take care of associating with the Storage SCP and sending them.

Have you seen the Move SCP example?

[MatheusVieira2001]

The example cannot be used as a baseline because it implements the sending of DICOM instances directly through the SCU, which prevents interoperability with devices waiting for the objects to be delivered through a new input association. In these cases, the device is prepared to receive DICOM objects from the SCP and will not accept send connections initiated by the SCU. This behavior results in delivery failure when the recipient requires the transfer to occur from the C-MOVE source. The snippet I submitted correctly resolves this scenario by having the SCP be responsible for initiating the sending of images to the specified destination.

The issue was resolved by forwarding the response to the requester's correct IP address, considering that the environment had multiple devices with different configurations and behaviors regarding DICOM association management.

I also thank you for your attention.