DICOM C-GET problem

Forums > Onis operations > Others
Search the Forums
Keyword :
Hi guys,

We are still testing our radiotherapy COALA system, among other applications with Onis.

Onis behaves strange when we disable C-MOVE support on our side (so that we only accept C-GET)

This is what we do on application level in Onis:

1. Start Onis 2.3.5 free version
2. Select our server as source
3. Find the patient and try to import his data

Onis repiles with "No image could be transffered", "Uknown error 135"

This is what happens on the DICOM level

1. C-FIND service handled properly
2. ASSOCIATE-RQ from Onis:

calling AE: ONIS23
application context: DICOM Application Context Name
user info: Maximum Length Received=8192 implementation class=1.2.392.200193
presentation contexts:
id=1 abstract syntax=Study Root Query/Retrieve Information Model - MOVE transfer syntaxes: Implicit VR Little Endian,
id=3 abstract syntax=Study Root Query/Retrieve Information Model - GET transfer syntaxes: Implicit VR Little Endian,

3. ASSOCIATE-AC from our system

calling AE: ONIS23
application context: DICOM Application Context Name
user info: Maximum Length Received=32000 implementation class=
presentation contexts:
id=1 result=USER_REJECTION
id=3 result=ACCEPTANCE transfer syntax: Implicit VR Little Endian

4. Now Onis closes the socket so we get EOF.

One additional thing - if Onis wants to use C-GET to transfer images it also should propose in one of presentation contexts RTImageStorage and RoleSelector in UserItems with Onis as SCP. RT image storage because that is what we would transfer.

To know that RTImageStorage is needed Onis should probably send a C-FIND also at the IMAGE level (it does at series level) asking about SOP class uid. Support for SOP class uid is however optional (I don't knowwhy not required) in Query/Retrieve find so the FIND SCP may not include it in it's answer. That way Onis would have no way of knowing what abstract storage syntax to propose in ASSOCIATE-RQ for C-GET

In such case, if I were you, I would still send non-conformant DICOM ASSOCIATE-RQ for C-GET without proper storage syntax with SCP role proposed and count that peer DICOM server is smart enough to send you image in Implicit VR Little Endian even though it was not negotiated.

You can find details about Query/Retrieve information model get and C-GET in DICOM PS 3.4-2011 and PS 3.7-2011

As a last remark - C-GET is kept in DICOM for backwards compatibility with older applications so I suppose you may choose not to support it. However in such case do not propose it in ASSOCIATE-RQ presentation context.

Kind regards from fellow computer sciencist,

P.S. DICOM also makes my head heart sometimes.

Bartosz Meglicki

National Centre for Nuclear Research
Department of Nuclear Equipment
ul. Andrzeja Sołtana 7
05-400 Otwock, Poland
11/10/2011 8:16:36 PM

Hello Bartosz,

Onis does not support C-GET as SCU. So the behavior is normal.

Now, you are confused because Onis propose the C-GET support in the Association Request. We did this for a later use, in case we decide to support it. Proposing does not necessary mean that we are required to use it. It is still the decision of Onis. For example, you could still make an association request just to know what classes are supported by a DICOM Server, then release the association right away.

The two main reasons for not supporting the C-GET for transferring the images are:
1. it is an old protocol, used by almost nobody today
2. it is ineffective since it is difficult to receive the images in their original format. That would lead to an overwork on the server side, which is not compatible with an "on demand" viewer.

But you can still blame us for not sending a release request before closing the connection ;-)

Kind regards,

11/11/2011 11:11:24 AM

Hi Madric,

Yes, it's closing the socket which confused me. Especially it was already fixed in the version I was using (at least for find and move)

So I assumed Onis was crashing during C-GET and that was the association wasn't released.

Also the message for Onis user could be more comprehensive.

Btw. For the C-GET it would be perhaps better to propose all the supported storage abstract syntaxes during association request, not rely on C-FIND at image level with optional SOP class response as I said in earlier post.

Kind regards,

11/11/2011 7:05:06 PM
About us | Contact us | Terms and Conditions | Privacy policy | Copyright policy
Copyright © Digitalcore 2009-2015. All rights reserved.