关于锐科PACS的傲娇DICOM Print协议

最近遇到了一个傲娇的锐科PACS工作站

具体情况是这样的：

某个同鞋（同事）反馈对接某医院影像工作站的时候其中一台DICOM通信无法通过验证，然后可以确认的是网络 配置什么的都没有问题，但设备验证通信时确实提示错误的，服务端这边实际是可以收到通信请求的，也没有报其他任何错误，工作站提交打印弹出错误提示 如图所示![锐科PACS--56(02-1130)]

作为一名没接触这方面多久的新人 一脸懵逼，问对方的工程师也是表示无能为力,也就是说只能靠自己 毕竟公司也确实没有这方面的大神,完全得靠自己摸索

一般情况！想要实现一个打印SCP服务器对接打印SCU客户端只要双方的SOP Class UID能够协商一致就可以完成打印通讯。

根据医院实际情况问题排查的到情况

1. DICOM通讯可以产生正常响应，即通讯网络正常 但C-ECHO不通且无法打印
2. 服务器没有报错，即代表SCU提交的SOP Class UID 服务端SCP处理都已经协商通过
3. 医院对接过其他自助DICOM打印系统 ，C-ECHO测试验证无法通过 但是却可以正常打印

基于以上三个判断 可以确定问题是出在协商通信这块，最开始以为是某个协商协议被我忽略或者拒绝掉了，导致通讯失败。但由于对方工程师无法提供相应的具体错误日志，只能将通信时的协议一个一个的输出测试，最后发现即使全部都接受还是情况一样。反反复复的测试十来遍都不行

最后发现了个unknown标示的SOP Class UID “1.2.840.113704.7.0.1.14”

百度上也没找到是干啥的 可能是厂商自己额外加的，结合上述三个情况就试着拒绝接受这个协商协议看看情况 ，意想不到的是。。。。。然后设备验证就通过了。。。。。。。好吧！ 试着打印也成功了。。。。。。