>> So does that mean that DICOM multiplexes multiple sessions over TCP?
Yes. FYI, its called presentation context ID.
At some point, the conversation mechanism should probably be generalized, so that arbitrary protocols
can define conversations, with TCP/UDP address-and-port-based conversations are just a particular
subclass of the general class of conversations.
DICOM endpoints also need to manage this de-multiplxing, so I don't think it is that wrong to do this in the dissector.
The different presentation context IDs are already stored in the DICOM conversation data structures. I would currently not quite see how I would 'subclass' the conversations.
session aware protocols ...
I probably should have called id transport layer. E.g. for the DICOM Query/Retrieve Mode, it has a command channel open and a data transfer channel. This separation is provided by TCP sessions.
DICOM does not have any sequence number in its protocol data (or data re-transmit capabilities) so it is using TCP to provide all of this. It's expecting the lower layer to deliver the packets in order and consistent. So that's what I kind of 'expect' from the reassembly module. Then, other protocols, also relying on the same TCP mechanism, wound not need their own hash tables, to manage something, that is one layer below.
