Integration PACS (GE) - WADO

[colimor]

Hello,

We are working in a project and we have to integrate a PACS with a
WADO server. After a lot of experiments we have found that when the
PACS initiates the second TCP connection (after a C-MOVE) to send the
images, it doesn't send any data throw the connection, so after a
minute the WADO server closes the connection. When the WADO server
initiates the connection (C-FIND) all works fine. We only have
problems when the PACS tries to initiate the Association after a C-
MOVE. The PACS is developed by General Electric and the WADO is a MIO
WADO (C2C). Does somebody have any idea?

Thanks in advance!

[Ignacio]

Hello,

Do you have configured the AE Title and remote port of your WADO
server on GE PACS?. Do any
firewall?

Cheers,
Ignacio.

[colimor]

Thanks for your response!

Yes, we have configured the AE Title and remote port of the WADO
server on the PACS. In addition we have done experiments with both
systems in the same network and all works fine. We see the tcp
connection in the wado but we also see an exception in logs. We find
this after a C-ECHO sent by the PACS to the WADO:

17:17:15 (84) IN TCP connection from 10.205.64.217
17:17:15 (84) IN Association request
17:17:15 (84) IN Initiating AET=OKDCWADO
17:17:15 (84) IN Called AET=MIO_WADO
17:17:15 (84) IN Application Context=1.2.840.10008.3.1.1.1
17:17:15 (84) IN Presentation Context 1
17:17:15 (84) IN Abst Syntax=1.2.840.10008.1.1
17:17:15 (84) IN Transfer Syntax=1.2.840.10008.1.2.1
17:17:15 (84) IN Transfer Syntax=1.2.840.10008.1.2
17:17:15 (84) IN User information
17:17:15 (84) IN Max length= 116794
17:17:15 (84) IN Imp UID= 1.3.6.1.4.1.25403.1.1.1
17:17:15 (84) IN Imp Name= Dicom 0.1
17:17:15 (84) OUT Association acceptance
17:17:15 (84) OUT Initiating AET=OKDCWADO
17:17:15 (84) OUT Called AET=MIO_WADO
17:17:15 (84) OUT Application Context=1.2.840.10008.3.1.1.1
17:17:15 (84) OUT Presentation Context 1
17:17:15 (84) OUT Accepted
17:17:15 (84) OUT Transfer Syntax=1.2.840.10008.1.2.1
17:17:15 (84) OUT User information
17:17:15 (84) OUT Max length= 65536
17:17:15 (84) OUT Imp UID= 1.2.826.0.1.3680043.1.2.100.5.6.3.8
17:17:15 (84) OUT Imp Name= DicomObjects.NET
17:17:45 (84) IN (0000,0000) UL : 56 (38H)
17:17:45 (84) IN (0000,0002) UI : 1.2.840.10008.1.1
17:17:45 (84) IN (0000,0100) US : 48 (30H)
17:17:45 (84) IN (0000,0110) US : 1 (1H)
17:17:45 (84) IN (0000,0800) US : 257 (101H)
17:17:45 (84) IN Command = C_ECHO
17:17:45 (84) IN SOP Class = 1.2.840.10008.1.1
17:17:45 (84) IN Verification request Received
17:17:45 (84) IN Association Aborted source=1, reason=0
17:17:45 (84) ***ERROR*** 94 Abort Received - source = 1, reason=1
17:17:45 (84) IN Error Location 4: Abort Received - source = 1,
reason=1
17:17:45 (84) OUT (0000,0000) UL : 122 (7AH)
17:17:45 (84) OUT (0000,0002) UI : 1.2.840.10008.1.1
17:17:45 (84) OUT (0000,0100) US : 32816 (8030H)
17:17:45 (84) OUT (0000,0120) US : 1 (1H)
17:17:45 (84) OUT (0000,0800) US : 257 (101H)
17:17:45 (84) OUT (0000,0900) US : 53247 (CFFFH)
17:17:45 (84) OUT (0000,0902) LO : Abort Received - source = 1,
reason=1
17:17:45 (84) OUT (0000,0903) US : 94 (5EH)
17:17:45 (84) IN Error Location 5: Abort Received - source = 1,
reason=1

What can be the problem?

Thanks!

[Marco Eichelberg]

colimor wrote:
> Yes, we have configured the AE Title and remote port of the WADO
> server on the PACS. In addition we have done experiments with both
> systems in the same network and all works fine. We see the tcp
> connection in the wado but we also see an exception in logs. We find

> this after a C-ECHO sent by the PACS to the WADO: [...]

I would guess that this is a configuration issue at the PACS.
Obviously the inbound DICOM association request arrives at
the PACS, so the TCP connection is actually successfully
established and even the DICOM association seems to be
accepted. Then, after the C-ECHO message is received, the
PACS decides to abort the association. There should be a log
somewhere on the PACS indicating the reason - perhaps the
PACS compares IP address to AE title and notices a mismatch
due to NAT - however this normally should happen at association
negotiation and not at this stage.
Anyhow, the PACS log files or vendor documentation are probably
your best friend when you want to find out what the PACS doesn't
like about this C-ECHO message.

With best regards,
Marco Eichelberg

[colimor]

Hello,

I think that the problem is in communications. I think this because in
the PACS log files we see that the PACS sent a C-ECHO response but in
the WADO we don't receive this message. For any reason we lost
packages in the way between both systems. Is there any problem with
proxies/firewalls in this kind of communication? we think that a
component is filtering packets and discarding all of them for any
reason.

Thanks!