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