On Fri, Jun 1, 2012 at 1:30 PM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:
> 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.
I think that is a good idea. There are many ways that conversation
block info could be useful.
Yes, please initiate the discussion on the winpcap mailing list.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)