Wireshark-bugs: [Wireshark-bugs] [Bug 6783] RTP header extensions not correctly implement
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6783
--- Comment #4 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2012-02-01 11:44:51 PST ---
(In reply to comment #0)
> Created attachment 7748 [details]
> Patch file correcting the header extension mechanism.
>
> Build Information:
> Compiled (32-bit) with GTK+ 2.22.1, with Cairo 1.10.2, with Pango 1.28.3, with
> GLib 2.26.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
> with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
> 2.10.3, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio
> V19-devel (built Jan 31 2012), with AirPcap.
>
> Running on 64-bit Windows 7, build 7600, with WinPcap version 4.1.2 (packet.dll
> version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008),
> GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.
>
> Built using Microsoft Visual C++ 10.0 build 40219
> --
> While investigating on bug #5208, I realized that wireshark's interpretation of
> the header extensions defined in the RTP specification was not correct.
>
> According to the RTP specification (RFC 3550)[1], different header extensions
> are defined by a number appearing at the start of the extension:
>
> To allow multiple interoperating implementations to each experiment
> independently with different header extensions, or to allow a particular
> implementation to experiment with more than one type of header extension,
> the first 16 bits of the header extension are left open for distinguishing
> identifiers or parameters.
> (RFC 3550 - 5.3.1 RTP Header Extension)
>
> However, the current implementation of the RTP dissector define header
> extensions in term of dynamic payload type. This problem was discovered when
> trying to implement a subdissector of an RTP header extension conforming to the
> ONVIF specification (ONVIF Core Specification, version 2.1.1)[2]
>
> I have made a patch, based on commit 40782, which correct the probleme by
> adding a new dissector table (named "rtp_hdr_ext2") having a FT_UINT32 as key.
> For backward compability, the existing dissector table (named "rtp_hdr_ext")
> have been kept and the new table is only used if the first had no corresponding
> dissector. If backward compatibility is not need, we can simply drop the
> existing one and keep only the new.
>
> packet-rtp.c.diff is the patch file correcting the header
> extension mechanism.
>
> ONVIF_RTPHeaderExtension.lua is an example of subdissector which can operate on
> extensions with ID 0xABAC.
>
> capture_with_rtp_header_extension.pcap is an example of capture file where
> frame #14 have a header which can be dissect by the subdissector presented
> above.
>
> [1] http://www.ietf.org/rfc/rfc3550.txt
> [2] http://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v211.pdf
Hi,
As I read the RFC the header extension is per payload-type AND then a number
is used. As there is no registration body for extension types there is a big
risk of collisions especialy if people choses "1" as the extension number.
That said your solution might be OK as we currently have no extensions
registered that I know of.
Regards
Anders
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
