| 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 |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
wireshark 1.11.3 (wireshark-1.11.3-rc1-1854-gf1f0601 from master)
Copyright 1998-2014 Gerald Combs <[email protected]> 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.
