[Debian-med-packaging] Bug#753809: Bug#753809: ginkgocadx, orthanc and sending/receiving data

[Michael Onken]

Hi,

On 02.03.2016 16:05, Gert Wollny wrote:

> https://orthanc.chu.ulg.ac.be/book/faq/query-retrieve.html
> 
> This was helpful indeed, now I find the data, but downloading fails. 
> 
> With the MOVE method GinkgoCADx says (after some time):  
> [...]
> and Orthanc logs: 
> 
>   W0302 14:08:55.689193 OrthancMoveRequestHandler.cpp:171] Move-SCU 
>      request received for AET "GINKGO"
>   E0302 14:09:55.837689 DicomUserConnection.cpp:159] 
>      DicomUserConnection: Peer aborted Association (or never connected)

The client tells the server via "MOVE" to send the images. However, MOVE
is a 3 point protocol: The client tells the server in the MOVE request
which images to send but also, to which AE title (i.e. which DICOM node
on the network) they should be send. This can be the client's own AE
Title (i.e. a listener under its control) or any other system. Thus, the
images are always(!) sent on a different DICOM connection than the
original MOVE request and those connections are between the same two
systems or three systems.

Since the client does only tell the server the move destination (as the
target system is called) via the AE Title and does not provide IP
address and port, those two have to be configured on the server for each
AE Title that should be able to receive images being requested via MOVE.

So my guess is the following:

- Either the AE title that should receive the images is not configured
  with IP and port on the server.

- Or there is such an AE title's IP and port configured (or even guessed
  by the server) but no one is listening at that address.

The latter seems to be more likely since the server seems to run into a
timeout while trying to connect to the storage destination. Also for the
former there should be a particular error code "Move Destination
Unknown" which should be returned by the server to the MOVE client.

Probably Karsten can give more insights of the move destination
configuration.

> E0302 14:09:55.837942 MoveScp.cpp:183] IMoveRequestHandler Failed: 
> Error in the network protocol
> 
> With the GET method, ginkgocadx rejects the request immediately:
> 
> E: Error Downloading study: Exception in component GIL/PACS : E:
> DIMSE No valid Presentation Context ID

This means (without seeing the full negotiation logs) that the server
does not support download via "GET", i.e. the related "SOP Class" could
not be negotiated. Overall, not any of the service proposals
("Presentation Contexts") of the request could be accepted by the server
(probably since the client just asks for the GET-related service(s)).

GET is not as common as MOVE as a download method so that is not really
unexpected behaviour. One reason is that GET always downloads on the
same connection, i.e. you only can request the images for yourself and
cannot send them a third system. On the other hand, with GET you never
run into firewall troubles and you do not have to pre-configure image
storage destination AE Titles on the server but you can download right away.

HTH,
Michael

P.S: Some time ago I wrote a "short" introduction/troubleshooting to
DICOM networking with DCMTK which covers many of the issues described.
Maybe its helpful for one the readers.

http://support.dcmtk.org/redmine/projects/dcmtk/wiki/Howto_PACSDebuggingWithDCMTK