Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Should payload dissectors' (RTP) packets depend on call-setu

From: Anders Broman <a.broman@xxxxxxxxxxxx>
Date: Fri, 01 Jun 2012 22:38:15 +0200
Jeff Morriss skrev 2012-06-01 22:13:
Are you saying that the correct frame is currently not tagged or that it may not always be or...?
(Simplified) In SIP there is an offer answer model the offer contains a list of possible codecs and perhaps ports The answer contains the choices acceptable by the receiver finally the offerer starts sending on one of the available choices and the receiver sends on one of the offered channels. A RE-INVITE could contain new choices. Currently we are setting up conversations on both the offer and answer I think.
This causes misinterpretation of the RTP content at times.
Regards
Anders

I suppose I should find a sample capture and try it out.

Anyway: good idea, bad idea?

Jaap Keuter wrote:
Hi,

Yes, that setup frame should be sufficient. The problem now is that not the correct setup frame is tagged, but that is another matter. Point is case is the SIP/SDP packet defining the conversation, to which the RTP dissector is set.
Thanks,
Jaap

Send from my iPhone

On 1 jun. 2012, at 20:44, 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?) ___________________________________________________________________________
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
___________________________________________________________________________
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


___________________________________________________________________________
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