| Bug ID |
11847
|
| Summary |
Failure of automatic detection of UDP packets as RTP packets when associated VoIP signalling is available
|
| Product |
Wireshark
|
| Version |
2.0.0
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14113 [details]
capture filtered down to SIP/tcp call with Opus RTP
Build Information:
Version 2.0.0 (v2.0.0-0-g9a73b82 from master-2.0)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (with SSE4.2), with 8141MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 31101
--
"sometimes", RTP flows belonging to a captured VoIP signalling are not
automatically recognized as RTP.
The "intensity" of the issue (maybe several independent issues) varies.
In the attached capture, which comes from a test call, the intensity is the
highest possible one:
1) when you open the capture, the highest level protocol identified in the RTP
packets is UDP
2) when you go Telehony->VoIP calls, choose the call in the list, and ask for
the "flow sequence", only the SIP messages are indicated, no RTP flows.
3) when you choose an RTP packet and manually tell Wireshark to decode packet
to/from this UDP port as RTP, and then go Telephony->VoIP calls again and ask
for a flow sequence diagram again, there are still no RTP flows.
In other cases, although after step 1) the packets are not identified to be
RTP, step 2) above makes Wireshark "find out" that the packets are RTP, and
shows the flows in the flow sequence diagram and also changes their display in
the packet pane. In yet another cases, step 2) is not enough, but if you
manually set "decode as" and ask for flow sequence diagram again, the diagram
does contain the RTP flows' arrows.
The attached capture is a test call; so far I've seen the other varieties of
the behaviour only in live calls which I cannot post. As soon as some other
mutation of the issue pops up in a test call, I'll add that capture to the bug
as well.
You are receiving this mail because:
- You are watching all bug changes.