Wireshark-dev: Re: [Wireshark-dev] Should payload dissectors' (RTP) packets depend on call-setu
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Anders Broman <a.broman@xxxxxxxxxxxx>
Date: Fri, 01 Jun 2012 22:30:24 +0200
Jeff Morriss skrev 2012-06-01 22:15:

Richard Sharpe wrote:

On Fri, Jun 1, 2012 at 11:44 AM, Jeff Morriss<jeff.morriss.ws@xxxxxxxxx>  wrote:

One of the more frequently asked questions/reported bugs is users filtering
for RTP, saving^W exporting those displayed packets, then opening the new
capture file only to find plain UDP.  This is because the call-setup
protocol (e.g., SIP) wasn't included in the display filter.

Now we have the ability to mark frames as dependent on others.  Should, for
example, RTP frames mark the call-setup frames as dependencies?  (I noticed
that RTP has a Setup Frame field; would one frame really be enough?)

An alternative, but more radical approach, might be to export the
state that is needed to correctly dissect the packets.

We could lobby for an additional application-specific state record in
pcap-ng or an application-specific option field. The state could be an
asn.1 encoded blob, or whatever.

True.  But I like the idea of adding ~1 line of code to the RTP
dissector and making all those questions go away.

I'd say it's a good short term solution.

 I'd like to discuss the pcap-ng track further, a new tread
on the pcap-ng mailing list? (or at least CC) https://www.winpcap.org/mailman/listinfo/pcap-ng-format How about a block or blocks with a port to protocol map similar to the address resolution block ( TCP,UDP,SCTP... port map) a Wireshark conversations block might be a nice idea too so vendor 
specified blocks could be useful too.

Though I am nervous about this whole packet-dependency thing causing
users to say "I filtered on RTP and you saved my SIP too!"

A pref some where?
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