Wlmscpfs and Toshiba CT

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
martinrame
Posts: 347
Joined: Mon, 2009-02-23, 19:57

Wlmscpfs and Toshiba CT

#1 Post by martinrame »

Hi, I'm using Wlmscpfs 3.5.4 to provide WL services to two modalities, one is a CR and the other one is a Toshiba CT, the CR gets the list without problems, but when I try to connect the CT to wlmscpfs it hangs until the connection is released by the CT.

I'm running wlmscpfs.exe using this command:

C:\ModalityWorkList\wlmscpfs.exe --debug -dhl -dfr -dfp C:\ModalityWorkList\ 104

And, when the CT asks for the WL, the log is this:

Code: Select all

PDU Type: Associate Request, PDU Length: 285 + 6 bytes PDU header
  01  00  00  00  01  1d  00  01  00  00  51  52  52  49  53  53
  43  50  20  20  20  20  20  20  20  20  54  4d  5f  43  54  5f
  43  4d  57  5f  56  33  2e  30  30  20  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  00  00  00  00  00  00  00  00  00  00  10  00  00  15  31  2e
  32  2e  38  34  30  2e  31  30  30  30  38  2e  33  2e  31  2e
  31  2e  31  20  00  00  2e  01  00  00  00  30  00  00  11  31
  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e  31
  40  00  00  11  31  2e  32  2e  38  34  30  2e  31  30  30  30
  38  2e  31  2e  32  20  00  00  4a  03  00  00  00  30  00  00
  16  31  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  35
  2e  31  2e  34  2e  33  31  40  00  00  11  31  2e  32  2e  38
  34  30  2e  31  30  30  30  38  2e  31  2e  32  40  00  00  13
  31  2e  32  2e  38  34  30  2e  31  30  30  30  38  2e  31  2e
  32  2e  32  50  00  00  3c  51  00  00  04  00  00  70  00  52
  00  00  1d  31  2e  32  2e  33  39  32  2e  32  30  30  30  33
  36  2e  39  31  31  36  2e  32  2e  36  2e  31  2e  31  30  30
  55  00  00  0f  54  4d  5f  43  54  5f  43  4d  57  5f  56  33
  2e  30  30
Association Received (172.16.1.20:TM_CT_CMW_V3.00 -> QRRISSCP)

Parameters:

Our Implementation Class UID:    1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID:    1.2.392.200036.9116.2.6.1.100
Their Implementation Version Name: TM_CT_CMW_V3.00
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    TM_CT_CMW_V3.00
Called Application Name:     QRRISSCP
Responding Application Name: 
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 28672
Presentation Contexts:
  Context ID:        1 (Proposed)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
  Context ID:        3 (Proposed)
    Abstract Syntax: =FINDModalityWorklistInformationModel
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Proposed Transfer Syntax(es):
      =LittleEndianImplicit
      =BigEndianExplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Constructing Associate AC PDU
Association Acknowledged (Max Send PDV: 28660)

Our Implementation Class UID:    1.2.276.0.7230010.3.0.3.5.4
Our Implementation Version Name: OFFIS_DCMTK_354
Their Implementation Class UID:    1.2.392.200036.9116.2.6.1.100
Their Implementation Version Name: TM_CT_CMW_V3.00
Application Context Name:    1.2.840.10008.3.1.1.1
Calling Application Name:    TM_CT_CMW_V3.00
Called Application Name:     QRRISSCP
Responding Application Name: 
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 28672
Presentation Contexts:
  Context ID:        1 (Accepted)
    Abstract Syntax: =VerificationSOPClass
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =LittleEndianImplicit
  Context ID:        3 (Accepted)
    Abstract Syntax: =FINDModalityWorklistInformationModel
    Proposed SCP/SCU Role: Default
    Accepted SCP/SCU Role: Default
    Accepted Transfer Syntax: =BigEndianExplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
DIMSE receiveCommand
Association Aborted

+++++++++++++++++++++++++++++
Any hint?

omarelgazzar
Posts: 101
Joined: Wed, 2009-07-08, 16:06
Location: Oldenburg, Germany

#2 Post by omarelgazzar »

May be you can try to accept the implicit VR little transfer syntax using the option +xi. This transfer syntax should be supported by any correct DICOM implementation.

martinrame
Posts: 347
Joined: Mon, 2009-02-23, 19:57

#3 Post by martinrame »

Thanks omarelgazzar. I think the problem is not related to transfer syntax, if that were the cause, the server should respond instantly, and in this case, the server waits about a minute between DIMSE receiveCommand and
Association Aborted.

Also you can see that both SOP Classes proposed by the CT are accepted by wlmscpfs.

martinrame
Posts: 347
Joined: Mon, 2009-02-23, 19:57

#4 Post by martinrame »

Sorry omarelgazzar, and thank you again. Forcing LittleEndian was the solution.

I don't know what changed in the CT side, until last week it was proposing LittleEndian only, since this weekend it started proposing both Little and Big.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 1 guest