Association closed immediately by Konica ultrasound

[gsmethells]

Describe the bug
An Association cannot be established with a Konica ultrasound HS2 unit.

Expected behavior
The Association should not immediately close after being accepted.

Steps To Reproduce

• Step 1: Run C-STORE SCP service
• Step 2: Have Konica ultrasound attempt to connect.

Actual code is close to this but has more services (DWML service, async DICOM Push event handling, async Query/Retrieve handling) that were elided, but I tried to keep the honest look of the code as best I could:

def handleCSTOREEvent(event):
  from pynetdicom.status import Status

  ipAddress      = event.assoc.requestor.address
  callingAETitle = event.assoc.requestor.ae_title
  calledAETitle  = event.assoc.requestor.primitive.called_ae_title
  filename       = f'{event.request.AffectedSOPInstanceUID}.dcm'

  print(f'Received {filename} from {ipAddress} ({callingAETitle})')

  buf      = event.request.DataSet
  bufsize  = buf.getbuffer().nbytes
  fileMeta = event.file_meta.to_json()

  # Store file code elided

  return Status.SUCCESS


class SCP():
  def __init__(self):
    self.scp       = None
    self.isRunning = False


  def run(self):
    import asyncio
    import time

    self.isRunning = True

    asyncio.run(self._start())

    while self.isRunning:
      time.sleep(1)


  async def _start(self):
    self._startSTORESCP()

    # A variety of async services started here were elided


  def _startSTORESCP(self):
    from pynetdicom import AllStoragePresentationContexts
    from pynetdicom import evt
    from pynetdicom import AE, VerificationPresentationContexts

    IMPLICIT_VR_LE                  = '1.2.840.10008.1.2'
    EXPLICIT_VR_LE                  = '1.2.840.10008.1.2.1'
    EXPLICIT_VR_BE                  = '1.2.840.10008.1.2.2'
    IMPLICIT_VR_LE_JPEG_BASELINE    = '1.2.840.10008.1.2.4.50'
    IMPLICIT_VR_LE_JPEG_EXTENDED    = '1.2.840.10008.1.2.4.51'
    IMPLICIT_VR_LE_JPEG_PROG_10_12  = '1.2.840.10008.1.2.4.55'
    IMPLICIT_VR_LE_JPEG_LOSSLESS    = '1.2.840.10008.1.2.4.57'
    IMPLICIT_VR_LE_JPEG_LOSSLESS_FO = '1.2.840.10008.1.2.4.70'
    IMPLICIT_VR_LE_JPEGLS_LOSSLESS  = '1.2.840.10008.1.2.4.80'
    IMPLICIT_VR_LE_JPEGLS_LOSSY     = '1.2.840.10008.1.2.4.81'
    IMPLICIT_VR_LE_JPEG2K_LOSSLESS  = '1.2.840.10008.1.2.4.90'
    IMPLICIT_VR_LE_JPEG2K_LOSSY     = '1.2.840.10008.1.2.4.91'
    IMPLICIT_VR_LE_RLE_LOSSLESS     = '1.2.840.10008.1.2.5'

    ACCEPTED_TRANSFER_SYNTAXES = (
      IMPLICIT_VR_LE,
      EXPLICIT_VR_LE,
      EXPLICIT_VR_BE,
      IMPLICIT_VR_LE_JPEG_BASELINE,
      IMPLICIT_VR_LE_JPEG_EXTENDED,
      IMPLICIT_VR_LE_JPEG_PROG_10_12,
      IMPLICIT_VR_LE_JPEG_LOSSLESS,
      IMPLICIT_VR_LE_JPEG_LOSSLESS_FO,
      IMPLICIT_VR_LE_JPEGLS_LOSSLESS,
      IMPLICIT_VR_LE_JPEGLS_LOSSY,
      IMPLICIT_VR_LE_JPEG2K_LOSSLESS,
      IMPLICIT_VR_LE_JPEG2K_LOSSY,
      IMPLICIT_VR_LE_RLE_LOSSLESS,
    )

    contexts = list(AllStoragePresentationContexts)

    for context in contexts:
      context.transfer_syntax = list(ACCEPTED_TRANSFER_SYNTAXES)

    ae = AE('TITLE')

    ae.supported_contexts = contexts + VerificationPresentationContexts
    ae.requested_contexts = []
    ae.maximum_pdu_size   = 0

    self.scp = ae.start_server(('', 11112), block = False, evt_handlers = ((evt.EVT_C_STORE, handleCSTOREEvent),))


  def stop(self):
    if self.scp:
      self.scp.shutdown()

    print('Storage service is stopped')

    self.isRunning = False



if __name__ == '__main__':
  # Setup code elided

  scp = SCP()

  try:
    scp.run()
  except KeyboardInterrupt:
    pass
  except Exception as ex:
    # logger trace code elided
    print(ex)
  finally:
    scp.stop()

Your environment
We do not have direct access to the user's workstation, but the following are the case:

Windows 2010
Python 3.7
pydicom 2.2.0
pynetdicom 2.0.0

NOTE: this is compiled by pyinstaller.exe and installed on Windows via NSIS

[gsmethells]

[gsmethells]

[gsmethells]

[gsmethells]

Just to follow up on this issue, as far as I know, Konica has accepted that there could be a bug on their end.

[mrbean-bremen]

Moved to discussions to keep this open as information.

[gsmethells]

@mrbean-bremen we mean to add changes to our software to place in the field to investigate the FSM in pynetdicom because debug logs do show pynetdicom is immediately sending an A-P-ABORT after sending the A-ASSOCIATE-AC PDU:

2023-05-11 08:53:42,539 joints: (2404) joints [DEBUG] ========================== END A-ASSOCIATE-AC PDU ==========================
2023-05-11 08:53:42,593 joints: (2404) joints [INFO] Association Aborted (A-P-ABORT)

we are looking to provide the medical practice with a custom build with changes like this:

-      'handlers'    : ((evt.EVT_C_STORE, cstoreHandler.handleEvent),),
+      'handlers'    : (
+        (evt.EVT_C_STORE, cstoreHandler.handleEvent),
+        (evt.EVT_FSM_TRANSITION, debug_fsm),
+      ),

and we will report what we find when we have more information.

[dan-sobczak]

The FSM debugging resulted in the following prior to the A-P-ABORT:

2023-05-11 13:41:22,271 joints: (12716) joints [DEBUG] ========================== END A-ASSOCIATE-AC PDU ==========================
2023-05-11 13:41:22,271 joints: (12716) joints [DEBUG] A: Sta3 + Evt7 -> AE-7 -> Sta6
2023-05-11 13:41:22,400 joints: (12716) joints [DEBUG] A: Sta6 + Evt17 -> AA-4 -> Sta1
2023-05-11 13:41:22,401 joints: (12716) joints [INFO] Association Aborted (A-P-ABORT)

According to this comment:

D: A: Sta6 + Evt17 -> AA-4 -> Sta1 indicates that the connection to the SCU has been closed, for example if it tried to read off the socket but there wasn't enough data. It doesn't seem to be hitting a timeout since not enough time is elapsed and it's treating it as closed immediately after the P-DATA is sent by 117 so that seems to be the proximal cause.

Any advice on next steps would be helpful.

[gsmethells]

For the record, in case future parties stumble across this discussion, we heard back from Konica

A max PDU receive size of "0" is not supported on HS2. It appears that the HS1 has that capability but the HS2 not yet and so cannot negotiate with [pynetdicom]. We are awaiting to hear back from our engineering group approx.. when that patch or software upgrade will be release.

After field testing, it was found that allowing the PDU to be configurable and setting a 16k PDU size worked correctly with the HS2 unit.