C-MOVE Problems

Why might C-MOVE not work in practice?

It is very common for users new to DICOM and DicomObjects to find that they can get queries (C-FIND) working, but fail when they try to retrieve images using C-MOVE (Using either MoveImages or GetUsingMove). There are a number of possible reasons for this, but by far the commonest is the first - failing to set up the server. Before looking at the possibilities in detail, it is worth looking at the difference between C-MOVE and other DICOM protocols, as this explains most of the issues. For most protocols, information is sent back to the SCU over the association that the SCU has initiated, but when an SCU makes a C-MOVE request, it is asking the SCP to create a new association back to the SCU to send over the images which have been requested. The C-MOVE contains information telling the SCP where to send the images, but this is only an application entity title, so the server must have a facility to “look up” this AET, and translate it into an IP address and port number. This is shown in more detail on the page describing C-MOVE in general

Bearing this mechanism in mind, the commonest problems are:

Server problems

Failing to set up the SCP to “Know” the SCU’s AET

Somehow, the SCP must be informed how to translate the AET of the SCU into the corresponding IP address and port number. If you are using one of the DicomObjects sample applications, enter the required data into the RemoteAETs table in the database. However, for commercial imaging equipment there is no standardised method of doing this, and this may need to be set up by a service engineer.
Whilst this requirement may seem onerous, no alternative is allowed by DICOM

Server writers who didn’t read the DICOM documentation

There are a few Q/R SCPs which handle C-MOVE completely wrongly, and instead of sending the images, then sending a C-MOVE status to say how many images worked and how many did not, they (unbelievably!)

  1. Send a C-MOVE status response saying that N image have successfully been sent
  2. Then they start to send the images!

When dealing with faulty servers like this, GetUsingMove will fail (as it stops listening when the C-MOVE final status is received) but a conventional “Listener” (DicomViewer or DicomServer) will still work OK

Client problems

Failing to specify the destination

The Destination property of a DicomQuery must be set to the value known to the SCP to represent the SCU, and this is sometimes forgotten.

Failing to listen on the appropriate port (or listening twice)

The means of specifying the listening port depends on the query method used from DicomObjects:
For GetUsingMove, The ListenPort property must be set to the value known to the SCP as above. This port must not be used for other purposes, and in particular, it should not be used in a DicomViewer.Listen or DicomSever.Listen call.
For all other methods (MoveImages, DicomConnection.Move etc.) it is necessary to listen for images independently of the move request, using the Listen method of either a DicomViewer or DicomServer object

There is another AE listening on the receive port

If there is another DICOM program running on the destination PC and it’s listening on the same port as receive port, the transmitted images may end up being received by that program, not the one which you thought would get the images.

Network problems

Firewall or routing problems (Special thanks to Demetris Halazonetis)

Since the secondary association needs to be initiated back from the SCP to the SCU, it is important that the there are no network restrictions preventing such a connection. Three common problems are seen in this respect:

  • The SCU connects to the SCP via a router providing network address translation. Unless set up specifically with C-MOVE in mind, this configuration will nearly always allow the SCU to connect to the SCP, but prevent the reverse connection.
  • There may be a deliberate firewall between the SCU and SCP preventing the reverse connection.
  • There may be a software firewall in the SCU, preventing incoming associations at all. This is becoming an increasing problem with Windows XP, and the firewall needs to be disabled (or at least the appropriate port unblocked) to allow C-MOVE to work.

Most of these problems do not exist with C-GET, but unfortunately, very few commercial DICOM SCPs support C-GET, so for now it is necessary to work around them as described above.

ADSL routers: WAN and LAN

ADSL routers present yet another layer of complexity to the communication between the SCP and the SCU. If you are testing a C-MOVE operation with the Medical Connections' DICOM Server (http://dicomserver.co.uk/) and get a ‘Socket Connect Error’ and a ‘Failed to connect at TCP level’ error, then the problem may be related to your ADSL router.

The ADSL router connects between your computer and the ADSL line. Essentially, the router and the computer constitute a Local Area Network (LAN). Within this LAN, the router and the computer each have a local IP address, most commonly 192.168.2.1 and 192.168.2.2. This local IP address is not the address that the SCP (e.g. the PACS server) will use. The SCP sees your computer through its global IP address (WAN: Wide Area Network), an address specified by your internet service provider. The global address usually changes every time you connect (unless you have a static IP).

During a C-MOVE operation, the SCP will try to connect to a port of the global IP, but will fail because your computer is within a local network and has a different IP address. What you need to do is configure the ADSL router to send all connection requests that attempt to talk to the port, to your local IP address. The following instructions are for the SAGEM 1540WG router, although other routers should work similarly.

  1. First make sure you indeed have different local and global IP addresses. To check this, open the Medical Connections' DICOM Server log and see the IP address that the server is trying to connect to. The log entry should read something like: ‘OUT Connecting to : 89.253.96.9, Port : 11112’. Then, from your Windows Taskbar, use Start - Run…, type cmd and click OK. You should get a DOS window. Type ipconfig and check the IP address (this is the local address). If the addresses are different you need to configure the ADSL router.
  2. Open your favourite internet browser and type the router’s IP address. This is usually 192.168.2.1. The router’s configuration page should open.
  3. Go to the NAT section (Network Address Translation).
  4. Go to the Special Application section. This section allows you to enter the number of the port that the SCP is trying to connect to and ‘open’ the port, so that the router sends the data to your computer. The SAGEM router explains this as follows: ‘Some applications require multiple connections, such as Internet gaming, video conferencing, Internet telephony and others. These applications cannot work when Network Address Translation (NAT) is enabled. If you need to run applications that require multiple connections, specify the port normally associated with an application in the “Trigger Port” field, select the protocol type as TCP or UDP, then enter the public ports associated with the trigger port to open them for inbound traffic.’
  5. After setting the port, click the Apply button. Now everything should work fine. However, there is still one potential blocking point. This is your internet service provider (ISP). Some providers completely block ports 0 to 1024 (plus some other ports) for security reasons. Data that is destined for these ports will never reach your router, so even if you have correctly set up the NAT, the SCP will not come through. There are two solutions here:
  • Configure the ISP to open the ports. Not recommended.
  • Use a higher port. So, do not use port 104 to connect to the Medical Connections' DICOM Server, but use port 11112 instead.