Den 8 feb 2016 18:04 skrev "Guy Harris" <guy@xxxxxxxxxxxx>:
>
> On Feb 8, 2016, at 8:51 AM, Anders Broman <anders.broman@xxxxxxxxxxxx> wrote:
>
> > It seems like there might not be a "solve all" solution to the cases listed, it also seems to me like there is a need for several flavors of "conversation"
> > Such as the 5 tuple we have today for stuff like "decode as" and possibly other protocol data stored by the protocols running on the transport protocol and
> > A configurable(?) "conversation" type taking "wire" into consideration used for reassembly TCP analysis response times etc.
>
>
> We *do* want a "Decode As" that applies to a conversation (i.e., which doesn't change the dissector table, it just changes the per-conversation dissector setting), but we don't have it yet, as far as I know, so presumably you're referring to the way that feature would work.
>
> Are you saying here that if the problem is that we're seeing both sides of routing, so that you have two (or more) copies of the same packet in the capture, you would still want, for example, both instances of a given TCP connection dissected as the selected protocol, but would want TCP reassembly taking place separately on both instances?
>
Yes, when conversation is set up from say the SDP dissector for the upcoming rtp flow we will not know on which wire it will appear.
___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
