DICOM：dcmqrscp.exe与storescu.exe中C-STORE服务的差别

背景：

        专栏中曾分别写过dcmqrscp.exe与storescu.exe工具包的介绍，但是并未深究两者之间的差别。dcmqrscp.exe工具是一个mini版PACS，可分别响应C-FIND、C-MOVE、C-GET、C-STORE等各种DIMSE服务，而storescu.exe工具是C-STORE服务使用者，可以看出这两个工具包都提供C-STORE SCU服务。前几天博友的一个问题使得重新研究了一下两者在实现C-STORE SCU服务上的差别。通过源码分析发现问题根源出在Presentation Context构建方式不同，下面通过具体示例引出问题，最后给出一个蹩脚的解决方案。

博友提出的问题：

        起初看到提问后简单的猜想是“参数设置有误”，但是周末回来在自己电脑上尝试了多种参数组合方式也没能解决问题，因此决定从源码入手查找问题的根源。下面简单记录一下错误排查的整个过程，按照由浅入深的思路，分别从工具包官方文档配置说明、多工具包实际测试和源码分析三个方面来阐述。

DCMTK工具包配置官方文档：

dcmqrscp.exe工具：

        之前在博文DICOM医学图像处理：DCMTK的wiki资料学习之PACS调试中曾详细介绍过关于dcmqrscp.exe工具的具体配置，由于本地测试数据都采用DICOM标准中默认支持的非压缩格式，即1.2.840.10008.1.2.1,Little Endian Explicit，因此当时并未涉及到DCM文件传输语义（Transfer Syntax）的设置。而此次博友y317215133y遇到的问题多半与Transfer Syntax相关，因此需要重新学习官网中关于传输语义的说明。

        dcmqrscp.exe工具包官网中关于Transfer Syntax传输语义的主要配置参数如下图（详情参见http://support.dcmtk.org/docs/dcmqrscp.html。）：

        注意观察上图中矩形框标记的两部分，其内部的含义大多是重复的，那么为什么会分为两部分呢？并且分别以prefer和propose为前缀？其中的incoming association和outgoing association又分别代表什么呢？因为dcmqrscp.exe充当的是miniPACS，其中的DIMSE服务既有SCU端，也有SCP端，例如在C-MOVE服务中，dcmqrscp.exe工具同时扮演了C-MOVE SCP和C-STORE SCU两种角色。由此可以猜测上图中的传输语义分成两部分的原因应该是分别对应SCP和SCU端。为了验证这一想法，让我们继续看一下其他工具的参数配置。

storescu.exe工具：

        关于storescu.exe工具的使用可阅读之前的两篇博文DICOM医学图像处理：storescp.exe与storescu.exe源码剖析，学习C-STORE请求和DICOM医学图形处理：storescp.exe与storescu.exe源码剖析，学习C-STORE请求（续），这里我们只关注storescu.exe工具包的参数配置，浏览官网文档（http://support.dcmtk.org/docs/storescu.html）得到如下结果：

        通过上图基本验证了上一小节的猜想，propose与prefer分别用于控制SCU和SCP两端的传输语义，因此storescu.exe工具配置项中只有以propose为前缀的参数。为了确定我们的猜想，继续看一下storescp.exe工具的配置。

storescp.exe工具：

        不罗嗦，直接贴出storescp.exe官方的配置说明（http://support.dcmtk.org/docs/storescp.html），如下图所示：

        因为storescp.exe在DIMSE服务中充当SCP角色，因此其配置项中只存在以prefer为前缀的参数，至此验证了我们的猜测。