Understanding DCMTK Association Negotiation Logs¶
- Table of contents
- Understanding DCMTK Association Negotiation Logs
This page describes the output shown from DCMTK's network tools. The logging level used is "DEBUG" and can be enabled in the DCMTK commandline tools by providing the "--debug" (shorter: "-d") option.
Association negotiation is often the most interesting part if communication with an SCU or SCP fails. In this section, the logs produced by the SCU tool "echoscu" is shown. The server being used is DCMTK's storescp. Any other DCMTK server will lead to the same results. The log always shows the SCU output. In order to understand what is going on, you may read the DICOM Networking Introduction in the wiki.
The system used for testing was running under Linux. Running the tools under Windows/ works the same; the output may just differ in very little details.
Preparation¶
Start storescp by calling
storescp -d localhost 11112. This will produce the following output:
michael@einstein:~$ storescp 11112 -d D: $dcmtk: storescp v3.6.1 DEV $ D: D: DcmDataDictionary: Loading file: /usr/local/share/dcmtk/dicom.dic
Now storescp is running and waiting for connection (association) requests on port 11112.
Request Logging¶
Enter "echoscu localhost 11112 -d on the commandline, and see what happens. This is the first part of the log that will be printed to the console screen:
01 michael@einstein:~$ echoscu localhost 11112 -d 02 D: $dcmtk: echoscu v3.6.1 DEV $ 03 D: 04 D: DcmDataDictionary: Loading file: /usr/local/share/dcmtk/dicom.dic 05 D: Request Parameters: 06 D: ====================== BEGIN A-ASSOCIATE-RQ ===================== 07 D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1 08 D: Our Implementation Version Name: OFFIS_DCMTK_361 09 D: Their Implementation Class UID: 10 D: Their Implementation Version Name: 11 D: Application Context Name: 1.2.840.10008.3.1.1.1 12 D: Calling Application Name: ECHOSCU 13 D: Called Application Name: ANY-SCP 14 D: Responding Application Name: resp. AP Title 15 D: Our Max PDU Receive Size: 16384 16 D: Their Max PDU Receive Size: 0 17 D: Presentation Contexts: 18 D: Context ID: 1 (Proposed) 19 D: Abstract Syntax: =VerificationSOPClass 20 D: Proposed SCP/SCU Role: Default 21 D: Proposed Transfer Syntax(es): 22 D: =LittleEndianImplicit 23 D: Requested Extended Negotiation: none 24 D: Accepted Extended Negotiation: none 25 D: Requested User Identity Negotiation: none 26 D: User Identity Negotiation Response: none 27 D: ======================= END A-ASSOCIATE-RQ ====================== 28 I: Requesting Association 29 D: setting network send timeout to 60 seconds 30 D: setting network receive timeout to 60 seconds 31 D: Constructing Associate RQ PDU
Every line is started by a letter denoting the information level it belongs to. "I:" is informational while "D:" refers to "Debug". Let's go through the lines:
01 michael@einstein:~$ echoscu localhost 11112 -d
"michael@einstein:~$" tells me that the commandline is ready to take my input. It might look a little different on Windows. I entered "echoscu localhost 11112 -d" and pressed return.
02 D: $dcmtk: echoscu v3.6.1 DEV $
02: The first output line produced. It tells us that we use "dcmtk", the tool is called "echoscu" and the version is "v.3.6.1 DEV".
03 04 D: DcmDataDictionary: Loading file: /usr/local/share/dcmtk/dicom.dic
Line 4 tells us that the file that this DCMTK installation reads all DICOM tags and their properties from a file that is located at the path "/usr/local/share/dcmtk/dicom.dic". For example, the dictionary file tells DCMTK that the tag "0010,0010" refers to the attribute "Patient's Name" which can contain not more than one value and some other information. Again, this line can look a little bit differently on Windows, since DCMTK (if not told otherwise) will include the dictionary in each tool so echoscu and other tools do not need to read it from a file but already have their own builtin copy.
05 D: Request Parameters: 06 D: ====================== BEGIN A-ASSOCIATE-RQ =====================
05. and 06. Make clear that next lines contain the parameters of the request that is sent to the server. The message type is "A-ASSOCIATE-RQ" (ACSE ASSOCIATE Request message).
07 D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1
07. Every DICOM implmenetation (in this case the DCMTK library) can provide a UID in order to identify itself which is called the "Implementation Class UID". "Our" in this context means that this refers to our own implementation not the one from the server (see 9 and 10).
08 D: Our Implementation Version Name: OFFIS_DCMTK_361
08. Besides a UID, also a text string is provided containing the identification of the DICOM implementation used. In this case it is DCMTK version 3.6.1. (note that DCMTK uses the last three numbers in the Implementation Class UID to denote the version, too; however, this is not required or might even change in the future).
09 D: Their Implementation Class UID: 10 D: Their Implementation Version Name:
values are not only sent to the server but are printed since they are "reserved" in memory by DCMTK for storing the server's values. We only receive the values once we have the response from the server, so they are always printed empty within the request.
11 D: Application Context Name: 1.2.840.10008.3.1.1.1
The "Application Context Name" contains a UID that for any DICOM application bears the same value. It basically tells the receiver that we like to talk DICOM with him. This is actually done since DICOM is an OSI network protocol. Thus on the other side there could be a system that does can understand the request package but does not understand its meaning since it does talk OSI but not DICOM in particular. In practice, you barely find a system that talks another OSI protocol than DICOM. You just have to remember: Always insert " 1.2.840.10008.3.1.1.1" for DICOM here, no other values allowed.
12 D: Calling Application Name: ECHOSCU
This is the AE title that we use for ourselves when contacting the SCP. It can change with a commandline option. Per default it is "ECHOSCU".
13 D: Called Application Name: ANY-SCP
This is the AE title that we use for the server, so it is the AE title assigned to the server. Per default we always call the server "ANY-SCP".
14 D: Responding Application Name: resp. AP Title
Responding Application Name: This again is a field that we expect to the receive from the server and that does not include any data yet, just a placeholder.
15 D: Our Max PDU Receive Size: 16384
This is the maxium size (in bytes) of a data package on the lower protocol level that we are able to receive. The SCP must stay below this level. The default is 16 KB and can be changed via commandline option.
16 D: Their Max PDU Receive Size: 0
The maximum PDU size of the server. The value here ("0") is a dummy value since we expect the server to tell us its maximum PDU size.
17 D: Presentation Contexts:
Below this line, the Presentation Contexts proposed by echoscu are printed (lines 18-22).
18 D: Context ID: 1 (Proposed)
ID of this presentation context; only odd numbers permitted, maximum is 255.
19 D: Abstract Syntax: =VerificationSOPClass
The abstract syntax of the service that we propose for Presentation Context 1. In this case the SOP Verification SOP Class should be proposed. Note that DCMTK translates known UIDs of SOP Classes and Transfer Syntaxes into human-readable text in order to make the output better understandable. We actually are sending the UID "1.2.840.10008.1.1" to denote the Verification SOP Class.
20 D: Proposed SCP/SCU Role: Default
The role echoscu wants to play for the selected SOP class. "Default" means that the initiator of the connection request (echoscu) wants to play the role of an SCU. There are only a few services in DICOM that need a non-defualt value here.
21 D: Proposed Transfer Syntax(es):
Starts the listing of Transfer Syntaxes that are proposed for the selected Presentation Context.
22 D: =LittleEndianImplicit
Only a single Transfer Syntax is proposed: "Little Endian Implicit". This is DICOM's default Transfer Syntax and must be accepted by all SCPs (if the SOP Class is supported in general which must be the case for Verification). echoscu can be configured to propose additional Transfer Syntaxes by using its commandline options.
23 D: Requested Extended Negotiation: none
DICOM allows SCUs to add some additional fields in order to use special features in DICOM. Many of those features have been introduced over the years. These optional fields are subsumed under "Extended Negotiation". In this case, we do not propose special features to the SCP ("none").
24 D: Accepted Extended Negotiation: none
This line tells us in the response from the server which of our proposed features have been accepted by the SCP. Since we are looking at the request, DCMTK shows the dummy value "none".
25 D: Requested User Identity Negotiation: none
DICOM offers the possibility to add user authorization information when proposing the connection (user name, password, ...). We do not propose anything here ("none").
26 D: User Identity Negotiation Response: none
This fields will hold the User Identity response from the server that we do not yet have in the request ("none").
27 D: ======================= END A-ASSOCIATE-RQ ======================
This marks the end of the request package. Note that the request has not been sent at this point.
28 I: Requesting Association
This marks the end of the request package. Note that the request has not been set at this point.
29 D: setting network send timeout to 60 seconds
echoscu sets a timeout how long it will try to deliver the request.
30 D: setting network receive timeout to 60 seconds
echoscu sets a timeout how long it will wait for response from the server.
31 D: Constructing Associate RQ PDU
echoscu prepares the binary network package to send the association request. After this line has been printed, the request package is sent to the server!
Response Logging¶
Here is the next block of the dump where echoscu dumps what comes back from the server:
32 D: PDU Type: Associate Accept, PDU Length: 184 + 6 bytes PDU header 33 D: 02 00 00 00 00 b8 00 01 00 00 41 4e 59 2d 53 43 34 D: 50 20 20 20 20 20 20 20 20 20 45 43 48 4f 53 43 35 D: 55 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 36 D: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 37 D: 00 00 00 00 00 00 00 00 00 00 10 00 00 15 31 2e 38 D: 32 2e 38 34 30 2e 31 30 30 30 38 2e 33 2e 31 2e 39 D: 31 2e 31 21 00 00 19 01 00 00 00 40 00 00 11 31 40 D: 2e 32 2e 38 34 30 2e 31 30 30 30 38 2e 31 2e 32 41 D: 50 00 00 3a 51 00 00 04 00 00 40 00 52 00 00 1b 42 D: 31 2e 32 2e 32 37 36 2e 30 2e 37 32 33 30 30 31 43 D: 30 2e 33 2e 30 2e 33 2e 36 2e 31 55 00 00 0f 4f 44 D: 46 46 49 53 5f 44 43 4d 54 4b 5f 33 36 31 45 D: Parsing an A-ASSOCIATE PDU
This is the binary response package we received from the server displayed in hex values. However, DCMTK will parse it (line 45) and tells us what is inside:
46 D: Association Parameters Negotiated: 47 D: ====================== BEGIN A-ASSOCIATE-AC ===================== 48 D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1 49 D: Our Implementation Version Name: OFFIS_DCMTK_361 50 D: Their Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1 51 D: Their Implementation Version Name: OFFIS_DCMTK_361 52 D: Application Context Name: 1.2.840.10008.3.1.1.1 53 D: Calling Application Name: ECHOSCU 54 D: Called Application Name: ANY-SCP 55 D: Responding Application Name: ANY-SCP 56 D: Our Max PDU Receive Size: 16384 57 D: Their Max PDU Receive Size: 16384 58 D: Presentation Contexts: 59 D: Context ID: 1 (Accepted) 60 D: Abstract Syntax: =VerificationSOPClass 61 D: Proposed SCP/SCU Role: Default 62 D: Accepted SCP/SCU Role: Default 63 D: Accepted Transfer Syntax: =LittleEndianImplicit 64 D: Requested Extended Negotiation: none 65 D: Accepted Extended Negotiation: none 66 D: Requested User Identity Negotiation: none 67 D: User Identity Negotiation Response: none 68 D: ======================= END A-ASSOCIATE-AC ====================== 69 I: Association Accepted (Max Send PDV: 16372)
This looks familiar, right? In fact the output is nearly the same as in the request. Let go through it:
46 D: Association Parameters Negotiated:
This is the the result of the negotiation, i.e. what was negotiated between SCU and SCP.
47 D: ====================== BEGIN A-ASSOCIATE-AC =====================
Start the dump of the "Association Acknowledge" message (i.e. the association was accepted).
48 D: Our Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1
Same as in request.
49 D: Our Implementation Version Name: OFFIS_DCMTK_361
Same as in request.
50 D: Their Implementation Class UID: 1.2.276.0.7230010.3.0.3.6.1
Now the server also sent its Implementation Class UIDs.
51 D: Their Implementation Version Name: OFFIS_DCMTK_361
And the related SCP Implementation Class Name.
52 D: Application Context Name: 1.2.840.10008.3.1.1.1
The OSI Application Context is still DICOM (and can't be anything else in DICOM/DCMTK).
53 D: Calling Application Name: ECHOSCU
Calling AE Title was ECHOSCU.
54 D: Called Application Name: ANY-SCP
We called the server ANY-SCP.
55 D: Responding Application Name: ANY-SCP
And the SCP responds as "ANY-SCP" (it is required to do so).
56 D: Our Max PDU Receive Size: 16384
Same as in request.
57 D: Their Max PDU Receive Size: 16384
Now also the SCP tells us its maximum PDU size. It also likes to have no packages bigger than 16KB.
58 D: Presentation Contexts:
This is the most interesting part where the server tells us for each Presentation Context proposed whether it is accepted, and if, which of the proposed Transfer Syntaxes is selected for that Presentation Context.
59 D: Context ID: 1 (Accepted)
We only proposed 1 Presentation Context, so we get back exactly 1 that was evaluated by the server. Presentation Context ID (as in the request) is 1.
60 D: Abstract Syntax: =VerificationSOPClass 61 D: Proposed SCP/SCU Role: Default 62 D: Accepted SCP/SCU Role: Default 63 D: Accepted Transfer Syntax: =LittleEndianImplicit
Abstract Syntax is Verifciaton SOP Class (line 60) - the value will always be identical to what has been requested
Line 61 shows that what we proposed in the request: We like to be the SCU (default role of initiator). Line 62 shows that the server accepted our proposal; this automatically means that the other side will play the SCP. Line 63 shows the transfer syntax accepted for this Presentation Context. Since we only offered one (the DICOM default Transfer Syntax "Implicit VR Little Endian"), this is the one that the server "selected". If the SCP would not like this one, it would have rejected the whole Presentation Context, actually rejected the whole association request since then no Presentation Context would be accepted at all.
64 D: Requested Extended Negotiation: none
We requested no Extended Negotiation features.
65 D: Accepted Extended Negotiation: none
The server accepted not to use any Extended Negotiation features.
66 D: Requested User Identity Negotiation: none
We did not use any User Identity Negotiation.
67 D: User Identity Negotiation Response: none
So the server also did not send any User Identity information.
68 D: ======================= END A-ASSOCIATE-AC ======================
That's it! We know now that we can exchange data on the connection.
69 I: Association Accepted (Max Send PDV: 16372)
The final result of the negotiation; we will send a maximum package size of 16 KB as requested by the server.
DIMSE Messaging¶
This is not dumped in detail, and not the topic here, but for completeness:
70 I: Sending Echo Request (MsgID 1) 71 D: DcmDataset::read() TransferSyntax="Little Endian Implicit" 72 I: Received Echo Response (Success)
We send an echo request to the server, this is, a DIMSE C-ECHO message (line 70). We received a response from the server which is read into DCMTK's internal data structure DcmDataset (line 71). DCMTK recognizes the response package as a C-ECHO response with status "Success" (line 72). That means that C-ECHO worked!
Releasing the association¶
73 I: Releasing Association
We release the association (and since no error is shown, this works fine).
Acknowledgements¶
This tutorial was supported through the NA-MIC project . NA-MIC is a national research center supported by grant U54 EB005149 from the NIBIB NIH HHS Roadmap for Medical Research Program.
Written my Michael Onken (DCMTK Team and Open Connections GmbH).