[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	9840
Summary	SIP/SDP doesn't track early RTP media
Classification	Unclassified
Product	Wireshark
Version	1.11.x (Experimental)
Hardware	x86
OS	Mac OS X 10.9
Status	UNCONFIRMED
Severity	Normal
Priority	Low
Component	Wireshark
Assignee	bugzilla-admin@wireshark.org
Reporter	hadrielk@yahoo.com

Build Information:
wireshark 1.11.3 (wireshark-1.11.3-rc1-1854-gf1f0601 from master)

Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.17, with Cairo 1.12.14, with Pango 1.30.1,
with
GLib 2.36.0, with libpcap, with libz 1.2.8, without POSIX capabilities, with
SMI
0.4.8, with c-ares 1.10.0, with Lua 5.2, without Python, with GnuTLS 3.1.10,
with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP, with PortAudio V19-devel
(built Feb 24 2014 23:07:27), with AirPcap.

Running on Mac OS X 10.9.2, build 13C64 (Darwin 13.1.0), with locale
en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.8, GnuTLS 2.12.19,
Gcrypt
1.5.0, without AirPcap.
Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz

Built using clang 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79).
--

A recent change to UDP dissection for v1.11 inr53641 causes SIP/SDP calls with
early media to not be able to decode the RTP, because that change made UDP
always create conversations for UDP packets.  That means that if a single RTP
packet is seen before the SDP anser in the 200 OK, it will create an
exact-match conversation; so any packets matching that conversation won't be
caught by the wildcarded-conversation installed by RTP.

One way to fix this would be to either provide a way for RTP to "find" that
exact-match one (which is actually pretty hard to do), or to provide a
different find_conversation function for UDP, to try wildcards before its exact
match ones, which seems nuts too.

Instead, I'm thinking of re-factoring the whole thing in v1.11, so that SIP/SDP
installs the RTP conversations when it gets the SDP *offer*, updates them on an
answer, etc.  This may seem like un-doing the change made inr47564, but I'm
not proposing un-doing it all; just to change the logic to put SIP in control
of SDP changes to RTP flows.r47564 was done because a mid-dialog SDP offer
getting rejected means you revert to the previous SDP state... but the cure was
worse than the disease. :)

Instead, what should happen is SIP should keep the current state, and give the
SDP dissector the SDP to parse and create RTP flows for, but with the ability
to revert a decision.  Only SIP really knows that kind of state/decision, not
SDP itself.

Doing it that way let us handle things like 18x responses with SDP correctly,
too, which is another broken thing right now; plus it lets us handle SDP offers
being in responses while SDP answers are in ACK/PRACK, which is also broken
right now.

---

      You are receiving this mail because:

• You are watching all bug changes.