[BitBucket user: Денис Смирнов] [BitBucket date: 2017-09-11.22:25:01] When I make a simple C-Move request to Orthanc from a workstation Orthanc establishes back an association and makes C-Store responce with a zero Move Originator Message ID (0000, 1031) value. According to DICOM NEMA Move Originator Message ID contains the Message ID (0000,0110) of the C-MOVE-RQ Message from which this C-STORE sub-operation is being performed. But Orthanc always returns zero and it causes errors when user tries to view images directly from Orthanc in Philips Portal. Here is an example DICOM output  I was given an advice in [Orthanc users google group](https://groups.google.com/forum/#!topic/orthanc-users/oHoKGB2Az0I) to open an issue about this problem.
Created attachment 4 [details] 1076252711-%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA%20%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0_2017-09-12_08-23-09.png
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2018-01-10.15:19:05] Hello, if I configure Orthanc 1.3.1 with the following configuration: ``` "DicomModalities" : { "movescu" : [ "MOVESCU", "127.0.0.1", 11112 ], "target" : [ "BREWERY", "127.0.0.1", 2000 ] } ``` Then, if I start a sample C-Store server as follows: ``` $ storescp 2000 -d -aet BREWERY ``` And if I trigger a C-Move as follows (note the **MessageID=10** argument): ``` $ movescu -v -S -aec ORTHANC -aet MOVESCU -aem BREWERY --port 11112 -od . localhost 4242 -k QueryRetrieveLevel=INSTANCE -k SOPInstanceUID=1.3.12.2.1107.5.2.33.37097.2012041613043195815872177 -k MessageID=10 ``` Then, I observe the following log in the C-Store server: ``` : ===================== INCOMING DIMSE MESSAGE ==================== D: Message Type : C-STORE RQ D: Presentation Context ID : 85 D: Message ID : 1 D: Affected SOP Class UID : MRImageStorage D: Affected SOP Instance UID : 1.3.12.2.1107.5.2.33.37097.2012041613043195815872177 D: Data Set : present D: Priority : medium D: Move Originator AE Title : MOVESCU D: Move Originator ID : 10 D: ======================= END DIMSE MESSAGE ======================= ``` The "Move Originator ID" value thus seems properly set. The "0" you observe comes from the fact that Orthanc assumes "0" if the tag "MessageID" is not available. I am however unsure of whether this is the proper way of handling "Move Originator ID". If you have any reference to better match with the DICOM standard, this would be extremely useful.
[BitBucket user: Денис Смирнов] [BitBucket date: 2018-02-14.07:25:52] When making a C-MOVE request SCU produces two dicom packets: C-MOVE-RQ and C-MOVE-RQ-DATA. With "-k MessageID=xxx" argument you change MessageID only in C-MOVE-RQ-DATA packet but not in C-MOVE-RQ. ``` movescu -v -S -aec ORTHANC -aet BREWERY -aem BREWERY --port 11112 -od . pacs.viveya.local 4242 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID=1.2.276.0.54.2017.12.17.404800 -k MessageID=666 ``` ``` DICOM, C-MOVE-RQ ID=1 PDU Type 0x4 (Data) PDU Length: 110 PDV, C-MOVE-RQ ID=1 PDV Length: 106 Context: 0x03 (Explicit VR Little Endian, Study Root Query/Retrieve Information Model - MOVE) Flags: 0x03 (Command, Last Fragment) (0000,0000) 4 Command Group Length 92 (0000,0002) 28 Affected SOP Class UID 1.2.840.10008.5.1.4.1.2.2.2 (Study Root Query/Retrieve Information Model - MOVE) (0000,0100) 2 Command Field C-MOVE-RQ (0000,0110) 2 Message ID 1 (0000,0600) 8 Move Destination BREWERY (0000,0700) 2 Priority 0 (0000,0800) 2 Data Set Type 1 DICOM, C-MOVE-RQ-DATA PDU Type 0x4 (Data) PDU Length: 68 PDV, C-MOVE-RQ-DATA PDV Length: 64 Context: 0x03 (Explicit VR Little Endian, Study Root Query/Retrieve Information Model - MOVE) Flags: 0x02 (Data, Last Fragment) (0000,0110) 2 Message ID [US] 666 (0008,0052) 6 Query/Retrieve Level [CS] STUDY (0020,000d) 30 Study Instance UID [UI] 1.2.276.0.54.2017.12.17.404800 ``` In an example above you can see MessageID = 1 in C-MOVE-RQ and MessageID=666 in C-MOVE-RQ-DATA. According to [NEMA](http://dicom.nema.org/dicom/2013/output/chtml/part07/chapter_E.html) (0000,1031) Move Originator Message ID "Contains the Message ID (0000,0110) of the C-MOVE-RQ Message from which this C-STORE sub-operation is being performed". So from my point of view (and from the point of view Philips technical support) Orthanc should return Originator Message ID from C-MOVE-RQ and it shouldn't be zero. P.S. I can't make c-move from Philips' Portal to Orthanc because of this DICOM discrepancy...
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2018-02-19.16:49:25] Issue #80 was marked as a duplicate of this issue.
[BitBucket user: Didier LESAGE] [BitBucket date: 2018-02-20.07:59:09] Hello, In file **MoveScp.cpp** (Core/DicomNetworking/Internals) Change ... ``` #!c data.iterator_.reset(data.handler_->Handle(data.target_, input, *data.remoteIp_, *data.remoteAet_,*data.calledAet_, GetMessageId(input))); ``` to ... ``` #!c data.iterator_.reset(data.handler_->Handle(data.target_, input, *data.remoteIp_, *data.remoteAet_,*data.calledAet_, request->MessageID)); ``` This solves the problem, making Orthanc returning the value extracted from the C-MOVE-RQ message. Regards.
[BitBucket user: Денис Смирнов] [BitBucket date: 2018-02-24.01:45:02] Thank you for patch! Are you going to add it in a trunk with time?
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2018-02-25.13:24:41] Denis, of course, but please be patient: https://groups.google.com/d/msg/orthanc-users/oHoKGB2Az0I/XB1pU56BBQAJ
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2018-07-12.13:11:47] fix issue #66 → https://hg.orthanc-server.com/orthanc/changeset/c1e351b6abec
*** Bug 80 has been marked as a duplicate of this bug. ***