|Deletions are marked like this.||Additions are marked like this.|
|Line 72:||Line 72:|
Digital Imaging and Communications in Medicine (DICOM)
Wikipedia has a very good high level description about DICOM and the protocol specifications can be found at the DICOM Homepage. This page will focus on wireshark specific topics.
DICOM is the third version of a standard developed by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA) and was released in 1993. Previous standards did not include network support. For more information about the history, please refer to  & 
Following screenshot shows a DICOM communication containing a C-ECHO followed by C-STORE request.
The accepted or rejected presentation contexts are decoded, to quickly identify negotiation issues.
Starting with wireshark 1.1.xx, the DICOM dissector has many new features.
- It should resemble almost all PDUs
- It supports multiple PDVs per PDU
- It decodes all tags defined in the standard 2008
- It adds 'Expert Infos', if Associations are aborted or if
- It supports to export captured DICOM objects as files
- UIDs are shown in clear text
First make sure to have a valid DICOM capture, including Association Request. Then, select File -> Export -> Objects -> DICOM.
Depending on the minimum size defined in the preferences, you will see more or less items in the list.
The Save all dialog is a little tricky, if the 'Browse for other folders' is expanded. Make sure to be in the parent directory and only highlight the target directory, don't open it.
For the DICOM Export, following UIDs are used. Since the SOP Class UID (0008,0016) and SOP Instance UID (0008,0018) are mandatory elements in the meta header, they are created if needed.
- Implementation UID (0002,0012)
1.2.8126.96.36.19980043.8.427.10Artificial Media Storage SOP Class UID for exported command PDVs
1.2.8188.8.131.5280043.8.427.11.1Artificial Media Storage SOP Instance UID for exported command PDVs
Wireshark is an ideal starting point to troubleshoot DICOM connectivity problems. Most often, the involved DICOM devices run on different operating systems, are from different vendors and sometimes are rather closed devices. In addition, the log files on those devices and cannot show both ends.
Basic connectivity problems can be identified just by using Wireshark captures. If it is more than that, it should at least be possible to tell, at which end to start.
To help quickly identify common scenarios, the DICOM dissector is creating 'Expert Info' marks as shown next.
In the Paket Details tree, warnings are highlighted as follows:
Association Request & Response
If one can't get beyond this, it's most likely a DICOM configuration or network setup issue.
- Make sure to check AE titles, host names or IP addresses and ports associated to those AE titles. Sometimes, additional connection need to be licensed and the licenses can be related to the AE titles.
- If possible, perform a DICOM C-ECHO Request. This is an application level ping and this also issues an A-ASSOCIATE Request and Response
- If a DICOM user is configured by hostname, a revers name lookup may take place, because the DICOM provider only gets it's IP in the A-ASSOCIATE request and may want to check, whether this IP is 'authorized' to create a connection.
- Check you AE title again
Query and Retrieve
Looking at the timestamps, is by far the best method, to figure out, why a transfer is slow.
Following settings are available to influence DICOM dissection its data display.
DICOM Ports: Comma separated list with TCP ports to decode. A range can also be specified. Example: 104, 3200, 50000-51000
Search on any TCP Port: When enabled, the DICOM dissector will parse all TCP packets not handled by any other dissector and look for an association request. This is disabled by default, to preserve resources for the non DICOM community. If you frequently look at DICOM traffic, enable this setting. If despite this enabled, the communication is still not recognized as a DICOM stream, add the TCP port to the list above.
Create Meta Header on Export: For exported PDUs, create a DICOM File Meta Header according to part 10. If the captured PDV does not contain a SOP Class UID and SOP Instance UID (e.g. for command PDVs), wireshark specific ones will be created. Meta headers are common now-a-days.
Min. item size in bytes to export: Do not show items below this size in the export list. Set it to 0, to see DICOM commands and responses in the list. Set it higher, to just export DICOM IODs (i.e. CT Images, RT Structures). DICOM commands are prefixed with a Meta Header as well.
Create subtrees for Sequences and Items: This is a matter of personal taste. If enabled, each sequences and items are shown in a hierarchy as show next. Since IODs can span multiple PDUs, sequence items in subsequent PDUs, may appear as root object. For a few items, containing tags are summarized and shown as an item description. Deselect this option, if you prefer a flat display or e.g. when using TShark to create a text output.
Create subtrees for DICOM Tags: This is a matter of personal taste. By default it is disabled, as it does not add much information. However, when one wants to see, the detailed tag decoding, or more important, if one wants to search for very specific DICOM attributes, enable this setting.
Example capture file
XXX - Add a simple example capture file to the SampleCaptures page and link from here (see below). Keep this file short, it's also a good idea to gzip it to make it even smaller, as Wireshark can open gzipped files automatically.
A complete list of DICOM display filter fields can be found in the display filter reference
- Show only the DICOM based traffic:
You cannot directly filter DICOM protocols while capturing. However, if you know the TCP port used (see above), you can filter on that one.
- Capture only the DICOM traffic over the default port (80):
tcp port 104