Created attachment 15065 [details]
Sample trace to demonstrate the issue
Build Information:
Wireshark 2.3.0 (v2.3.0rc0-1456-gdc42df2)
Copyright 1998-2016 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 4.8.7, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.46.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.12.0, without Lua, with GnuTLS 3.4.15, with Gcrypt 1.6.6, with MIT Kerberos,
with GeoIP, without nghttp2, without LZ4, without Snappy, with QtMultimedia,
without AirPcap.
Running on Linux 4.7.9-100.fc23.x86_64, with Intel(R) Core(TM) i5-2520M
CPU @ 2.50GHz (with SSE4.2), with 7939 MB of physical memory, with locale
LC_CTYPE=en_US.utf8, LC_NUMERIC=en_US.utf8, LC_TIME=cs_CZ.UTF-8,
LC_COLLATE=en_US.utf8, LC_MONETARY=en_US.utf8, LC_MESSAGES=en_US.utf8,
LC_PAPER=en_US.utf8, LC_NAME=en_US.utf8, LC_ADDRESS=en_US.utf8,
LC_TELEPHONE=en_US.utf8, LC_MEASUREMENT=en_US.utf8,
LC_IDENTIFICATION=en_US.utf8, with libpcap version 1.7.4, with GnuTLS 3.4.15,
with Gcrypt 1.6.6, with zlib 1.2.8.
Built using gcc 5.3.1 20160406 (Red Hat 5.3.1-6).
--
Hello,
When dynamic RTP payload is used, wireshark shows it's name decoded from SDP.
E.g. for rtpmap: 123R2S/8000 isR2S shown. But I found that time to time only
DynamicRTP-Type-123 is shown for my attached example even SDP contains correct
information.
During investigation I found that wrong description is shown for every
reverse RTP stream with dynamic payload. Reverse I mean RTP stream negotiated
with response to INVITE message.
I attached sample capture. Reverse RTP is negotiated in #3. Wrong description
is shown e.g. in packets #12, #23, ...
This problem I see in whole 2.x branch up to current development head. I
think that in 1.x branch it was the same.
I found that cause of the issue is wrong processing of media channel counter
in packet-sdp. It was discussed in BUG 9946 and marked as fixed. But I found
that is was not fixed or not for my case.
I created patch for it. It unify counting of media_count in transport_info_t
and disposable_media_info_t structures and use it as zero based counter and -1
as empty value.
The easiest way how to see the issue and fix is to enable conversation debug
in packet-sdp, packet-rtp and conversation (uncomment #define
DEBUG_CONVERSATION).
Without the patch, debug shows more channels (3 for voice, more for voice and
video) than are really described in SDP. Forward channel is recorded in channel
0 and reverse channel is recorded in channel 1 and 3 (which is the root cause
of the issue).
When patch is applied, correct count of channels is shown (2 for voice, 4 for
voice and video). Forward channel is recorded in channel 0, reverse channel is
recorded in channel 1.
I verified patch with my attached sample, all my samples and with sample with
multiple channels (voice and video) from wireshark library
(h263-over-rtp.pcap). Everything is decoded as before plus my issue is fixed.
Jirka Novak