C-ECHO failure with dcm4che 2.0

saba · Post by **saba** » Sat Jun 09, 2007 6:16 am

I have an utility program written on top of dcm4che version 2.0 running on my machine with a C-Store service. I have configured the pacs one to have this AE. But when I try to do a C-ECHO to this machine I get this following error.

Verify() failed: error = Invalid response received: command = 1

But I am able to ping successfully from other tools ( like dcm4che utility tools and JDicom tools)

Any idea what this error means ?

Regards,
Saba.

Post by **pacsone** » Sat Jun 09, 2007 5:01 pm

This error means PacsOne has received a command response (0x1) from this remote AE, but it's not the C-ECHO-RSP (0x8030) which PacsOne was expecting.

To trouble-shoot this further, you can add the following line as the first line in function CEchoPdv::recvResponse(&$data, &$complete, &$error) in the php/dicom.php script under the directory where PacsOne is installed:

Code: Select all

pacsone_dump($data);

Then ping this remote AE again, and this time PacsOne will dump the entire command response received from this AE to the browser.

altie · Post by **altie** » Wed Jun 20, 2007 6:21 am

I've got a similar problem but not just with C-ECHO. PacsOne MWL C-FIND does not like the responses produced by dcm4che 2.0.

The instructions above were followed and I get the following data table on a C-ECHO response but I can't work out what it means:

Code: Select all

0	0	0	36	1	3	0	0	0	0	4	0	0	0	28	0
0	0	0	0	0	1	2	0	0	0	30	80	0	0	20	1
2	0	0	0	1	0	0	0	0	8	2	0	0	0	1	1
0	0	0	9	2	0	0	0	0	0

I have a suspicion that it may have something to do with Big/Little-Endian-ness of the response. Any help would be appreciated.

Post by **pacsone** » Wed Jun 20, 2007 4:23 pm

The above dump of the C-ECHO-RSP content indicates that this remote AE was including a retired Dicom data element (0000,0001) in the response it returns to PacsOne, which was unexpected by PacsOne and thus the error.

We have since made changes in version 4.1.4 of PacsOne Server to accommodate for this retired data element, so if you upgrade to version 4.1.4 or later release of PacsOne Server, it should work fine with these older Dicom applications even with the retired data element included.

altie · Post by **altie** » Mon Oct 22, 2007 1:56 am

Ok, it's been a while since your reply to this thread, but I've only just now been able to get back to this issue.

I've installed PacsOne 5.1.2 and done the same test.

However, I still get the same error. I've added the dump statement to the recvResponse() function and get the same dump (which is expected as I haven't changed the application that PacsOne is getting the C-ECHO response from).

I'll upgrade the toolkit that my application is based on and see if that changes anything.

altie · Post by **altie** » Mon Oct 22, 2007 3:32 am

Upgraded the toolkit to the latest version (dcm4che 2.0.12) and still no go.

Here's the dump from recvResponse():

Code: Select all

0	0	0	36	1	3	0	0	0	0	4	0	0	0	28	0
0	0	0	0	0	1	2	0	0	0	30	80	0	0	20	1
2	0	0	0	1	0	0	0	0	8	2	0	0	0	1	1
0	0	0	9	2	0	0	0	0	0

Any ideas on how to fix this?

Post by **pacsone** » Mon Oct 22, 2007 3:53 pm

Looks like the problem is more severe than originally thought:

One mandatory data element Affected SOP Class UID (0000,0002) is missing in the C-ECHO-RSP response received from this remote AE (dcm4che). So you should contact the technical support for this application and ask them why this required data element was missing in the C-ECHO-RSP responses they send out.

altie · Post by **altie** » Mon Oct 22, 2007 10:51 pm

That was an excellent lead. Found a programmatic setting in the toolkit that caused the toolkit to include the UID in the responses so PacsOne now successfully receives C-ECHO and MWL C-FIND responses from dcm4che. Thanks for your help!

For anyone else who has the same problem, include this line of code before you start any of the dcm4che services:

Code: Select all

CommandUtils.setIncludeUIDinRSP(true);