DcmSCU method findPresentationContextID returns 0

[kumarm]

Hello,

I have used the following DcmSCU example program to test the FIND request on Windows platform. DcmSCU method findPresentationContextID returns 0 in Function call 'findUncompressedPC'.

DcmSCU Sample Program Code:

static Uint8 findUncompressedPC(const OFString& sopClass, DcmSCU& scu)
{
Uint8 pc;
pc = scu.findPresentationContextID(sopClass, UID_LittleEndianExplicitTransferSyntax);
if (pc == 0)
pc = scu.findPresentationContextID(sopClass, UID_BigEndianExplicitTransferSyntax);
if (pc == 0)
pc = scu.findPresentationContextID(sopClass, UID_LittleEndianImplicitTransferSyntax);
return pc;
}


bool PerformSearch()
{
// Set AE titles
setAETitle("MY_DEFAULT");
setPeerHostName("localhost");
setPeerPort(4722);
setPeerAETitle("sscp_cppunit");
setMaxReceivePDULength(ASC_DEFAULTMAXPDU);
setDIMSEBlockingMode(DIMSE_NONBLOCKING);
setDIMSETimeout(2);

// Use presentation context for FIND/MOVE in study root, propose all uncompressed transfer syntaxes
OFList<OFString> ts;
ts.push_back(UID_LittleEndianExplicitTransferSyntax);
ts.push_back(UID_BigEndianExplicitTransferSyntax);
ts.push_back(UID_LittleEndianImplicitTransferSyntax);

addPresentationContext(UID_FINDStudyRootQueryRetrieveInformationModel, ts);
addPresentationContext(UID_MOVEStudyRootQueryRetrieveInformationModel, ts);
addPresentationContext(UID_VerificationSOPClass, ts);

// Initialize network
OFCondition result = initNetwork();
if (result.bad()) {
return false;
}

// Negotiate Association
result = negotiateAssociation();
if (result.bad()) {
return false;
}

// Let's look whether the server is listening: Assemble and send C-ECHO request
result = sendECHORequest(0);
if (result.bad()) {
return false;
}

// Assemble and send C-FIND request
OFList<QRResponse*> findResponses;

DcmDataset req;
req.putAndInsertOFStringArray(DCM_QueryRetrieveLevel, "STUDY");
req.putAndInsertOFStringArray(DCM_StudyInstanceUID, "");

T_ASC_PresentationContextID presID = findUncompressedPC(UID_FINDStudyRootQueryRetrieveInformationModel, *this);
if (presID == 0) {
return false;
}

result = sendFINDRequest(presID, &req, &findResponses);
if (result.bad()) {
return false;
}

return true;
}



I have checked the log file generated by PACS Server (dcmqrscp.exe) and it shows the error message 'Abstract Syntax Not Supported' for FINDStudyRootQueryRetrieveInformationModel. Is this the issue with DB file index.db or some other configuration issue in the sample test program.

$dcmtk: dcmqrscp v3.6.3 2018-02-05 $

Configured a total of 3 presentation contexts for SCU
Request Parameters:
====================== BEGIN A-ASSOCIATE-RQ =====================
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.3
Our Implementation Version Name: OFFIS_DCMTK_363
Their Implementation Class UID:
Their Implementation Version Name:
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: MY_DEFAULT
Called Application Name: sscp_cppunit
Responding Application Name: sscp_cppunit
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 0
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Context ID: 3 (Proposed)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Context ID: 5 (Proposed)
Abstract Syntax: =VerificationSOPClass
Proposed SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=BigEndianExplicit
=LittleEndianImplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Requested User Identity Negotiation: none
User Identity Negotiation Response: none
======================= END A-ASSOCIATE-RQ ======================
Requesting Association
setting network send timeout to 60 seconds
setting network receive timeout to 60 seconds
Constructing Associate RQ PDU
PDU Type: Associate Accept, PDU Length: 244 + 6 bytes PDU header
02 00 00 00 00 f4 00 01 00 00 73 73 63 70 5f 63
70 70 75 6e 69 74 20 20 20 20 53 54 52 59 4b 45
52 5f 44 45 46 41 55 4c 54 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 21 00 00 19 01 00 03 00 40 00 00 11 31
2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32
21 00 00 19 03 00 03 00 40 00 00 11 31 2e 32 2e
38 34 30 2e 31 30 30 30 38 2e 31 2e 32 21 00 00
1b 05 00 00 00 40 00 00 13 31 2e 32 2e 38 34 30
2e 31 30 30 30 38 2e 31 2e 32 2e 31 50 00 00 3a
51 00 00 04 00 00 40 00 52 00 00 1b 31 2e 32 2e
32 37 36 2e 30 2e 37 32 33 30 30 31 30 2e 33 2e
30 2e 33 2e 36 2e 33 55 00 00 0f 4f 46 46 49 53
5f 44 43 4d 54 4b 5f 33 36 33
Parsing an A-ASSOCIATE PDU
Association Parameters Negotiated:
====================== BEGIN A-ASSOCIATE-AC =====================
Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.3
Our Implementation Version Name: OFFIS_DCMTK_363
Their Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.3
Their Implementation Version Name: OFFIS_DCMTK_363
Application Context Name: 1.2.840.10008.3.1.1.1
Calling Application Name: MY_DEFAULT
Called Application Name: sscp_cppunit
Responding Application Name: sscp_cppunit
Our Max PDU Receive Size: 16384
Their Max PDU Receive Size: 16384
Presentation Contexts:
Context ID: 1 (Abstract Syntax Not Supported)
Abstract Syntax: =FINDStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Context ID: 3 (Abstract Syntax Not Supported)
Abstract Syntax: =MOVEStudyRootQueryRetrieveInformationModel
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Context ID: 5 (Accepted)
Abstract Syntax: =VerificationSOPClass
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit
Requested Extended Negotiation: none
Accepted Extended Negotiation: none
Requested User Identity Negotiation: none
User Identity Negotiation Response: none
======================= END A-ASSOCIATE-AC ======================
Association Accepted (Max Send PDV: 16372)
Sending C-ECHO Request
===================== OUTGOING DIMSE MESSAGE ====================
Message Type : C-ECHO RQ
Presentation Context ID : 5
Message ID : 1
Data Set : none
======================= END DIMSE MESSAGE =======================
DcmDataset::read() TransferSyntax="Little Endian Implicit"
Received C-ECHO Response
===================== INCOMING DIMSE MESSAGE ====================
Message Type : C-ECHO RSP
Presentation Context ID : 5
Message ID Being Responded To : 1
Affected SOP Class UID : VerificationSOPClass
Data Set : none
DIMSE Status : 0x0000: Success
======================= END DIMSE MESSAGE =======================
Aborting Association
Cleaning up internal association and network structures


Thanks
Manoj

[J. Riesmeier]

Could you please post the configuration file that you use for dcmqrscp.

[kumarm]

Here is my configuration file - dcmqrscp.cfg

#
# Global Configuration Parameters
#
NetworkTCPPort = 5432
MaxPDUSize = 16384
MaxAssociations = 16
#
# UserName = <not used>
# GroupName = <not used>

HostTable BEGIN
#
# The HostTable defines symbolic names for collections of network
# DICOM Application Entities. A symbolic name can represent a single
# application entity or it can represent a group of application entities.
# Each DICOM application entity is defined by a triple consisting of
# Application Entitiy Title, host name and TCP/IP port number.
#
# Entry Format: SymbolicName = ( AETitle, HostName, Portnumber ), ... |
# SymbolicName = SymbolicName, ...
#
# NOTE: in the current implementation you cannot substitute an IP address
# for a hostname.
#
#
storescp = (sscp_cppunit,localhost,4722)
HostTable END
VendorTable BEGIN
#
# The VendorTable is used by the dcmqrdb and dcmqrti applications.
# You can give a vendor name (r.h.s. entry below) to the dcmqrti
# program and it will talk to all hosts and AEs of the vendor.
# The dcmqrdb program can use the vendor table to restrict move destination
# to hosts belonging to a vendor.
# Also, the dcmqrti and dcmqrdb programs use the name defined on the left hand side
# as the vendor name to display above images.
#
# The format:
# VendorName = SymbolicName
# The symbolic name should be defined in the HostTable.
#
#
VendorTable END

AETable BEGIN
#
# Each row of the AETable defines an Application Entities (AE) Title known
# to the dcmqrdb application. Each AE Title represents a separate
# image database located in the specified file system directory (storage area).
# Each AE Title has read/write, quota and peer access restrictions.
#
# Entry Format: AETitle StorageArea Access Quota Peers
# AccessFormat: R | RW | W
# Quota Format: ( maxStudies, maxBytesPerStudy )
# Peers Format: ( Hostname, AETitle, Portnumber ), ... |
# Entry in HostTable |
# ANY
# Adapt with absolute path:
MY_DEFAULT ..\data\db R (200, 1024) ANY
#
AETable END

[kumarm]

commandline used to run PACS Server and storescp

dcmqrscp -c dcmqrscp.cfg -lc dcm_log4cplus.cfg

storescp -lc storescp_log4cplus.cfg -od d:\my_datin -p 4722

[J. Riesmeier]

If you use "sscp_cppunit" as the called AE title, you should also specify a storage area with this name (i.e. in section "AETable"). See documentation for details.

Could it be that you've connected to storescp and not to dcmqrscp? At least you've used port 4722 for your SCU...

Btw, the storescp option "-p" means --padding-off, which is the default anyway.

[kumarm]

Thanks J.Reismeier for your suggestions.

It works with following configuration changes in DcmSCU sample program.

setAETitle("MY_DEFAULT");
setPeerHostName("localhost");
setPeerPort(5432);
setPeerAETitle("MY_DEFAULT");

AE Title and PeerAETitle should have the same title value and peer port should be 5432 for the connection with PACS server.

[J. Riesmeier]

Great to hear that it works but Calling and Called AE Title should never be the same. AE Titles should be unique within a DICOM network, otherwise C-MOVE, which is one way to do the retrieve, would not work.

[kumarm]

Hello J. Riesmeier,

One small query:

Is DcmSCU class usage is preferred over DcmFindSCU for C_FIND request implementation? In my opnion, DcmSCU class is more generic and convenient to use in terms of handling Query and Retrieve functionality.


Pls. provide your inputs.

Thanks
Manoj

[J. Riesmeier]

I would agree and prefer DcmSCU. When the class DcmFindSCU was introduced it was just a (quick) wrapper around the existing findscu functionality, and DcmSCU was net yet planned at that time. In my opinion, DcmFindSCU should be rewritten based on DcmSCU as we did with DcmStorage (not wrapping the functionality of storescu but starting from scratch and developing the "new" tool dcmsend).