>>Thus wrote Guy Harris (guy@xxxxxxxxxxxx):
>
>> We should probably also add a notion of "conversations" available to
>> dissectors at multiple layers (a notion more general than the current
>> address-and-port-endpoint-pair notion, that can include multiple
>> address layers, "circuits" for protocols that have a virtual circuit
>> ID of some sort, and conversations at layers above the transport
>> layer)
>
>that would definitely be helpful.
>
>As far as I can see, DVB-CI is an example that does not fit into the current mechanism very well. CI is not based on
>tcp/ip, a ci session looks like
>
>open_session_request(resource_id)
>session_opened(newly assigned session number)
>
>payload transfer(session_number, payload data) ...
>
>close session(session_number)
>
>
>For now, how would you create a conversation from this? I've been playing with a new port_type PT_DVBCI_SESSION_NUMBER >and set both source and destination port to the session number. Does that make sense or is there a better approach?
>
>Thanks,
>
> Martin
I've been contemplating the idea of making it possible to filter a "call" in the Telco world that could involve
A multitude of protocols for example SIP, DIAMETER, H248, ISUP, BICC and a number of Mobile protocols. I suppose this is
What mate tries to do. Perhaps it could be done if we had a Global conversation to which you cold add a
List of per protocol conversations. One problem is to make it generic enough and in this particular scenario the subscriber number or similar would be the thing gluing the conversations together and that would only be
Available in some messages. Another problem is when to create the global conversation e.g. what is the start.
Thoughts?
Regards
Anders
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe