[Guy Harris <guy@xxxxxxxxxxxx>]

Michael Mann is looking at generalizing conversations to handle arbitrary endpoints, presumably not necessarily in the form of an AT_ address plus a PT_ numeric port ID.

We also have the notion of "circuits", which are like conversations except that they're identified by a single "circuit ID" rather than by endpoints; the circuit types currently supported are

    CT_DLCI,            /* Frame Relay DLCI */
    CT_ISDN,            /* ISDN channel number */
    CT_X25,             /* X.25 logical channel number */
    CT_ISUP,            /* ISDN User Part CIC */
    CT_IAX2,            /* IAX2 call id */
    CT_H223,            /* H.223 logical channel number */
    CT_BICC,            /* BICC Circuit identifier */
    CT_DVBCI,           /* DVB-CI session number|transport connection id */

and there's also

    CT_ISO14443         /* ISO14443 connection between terminal and card
                           the circuit ID is always 0, there's only one
                           such connection */

but presumably there's only one such circuit per capture, and there's a comment noting that an ATM VPI/VCI pair could also be a circuit ID.

The conversation and circuit structures are used to hold:

	starting and ending frame numbers (mainly used when testing whether a packet is or isn't in a conversation/circuit, I think);

	state data dissectors keep for a given conversation/session;

	a "next dissector" for the protocol for the conversation type, so a dissector can say "dissect everything in this conversation as XXX".

Some thoughts that come to mind:

1) While we're generalizing conversations, should we have a "superclass" that includes both endpoint-labeled conversations and ID-labeled circuits, so that they can offer common services to dissectors?

2) Can we use conversations/circuits elsewhere, e.g. in the conversations and endpoints UI functions?

3) Would it be useful to add to the "Dissect As..." mechanisms the ability to say, from the UI, "dissect the conversation/circuit to which this packet belongs as...", rather than just "dissect this {packet type, transport-layer port} as..."?

4) Can we further generalize conversations/circuits to include, for example, multiple endpoint pairs/circuit IDs, so that, for example, an NFSv2 or NFSv3 "conversation" would include NFS traffic, NLM (lock manager) traffic, and mount protocol traffic?