Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6783] New: RTP header extensions not correctly implement

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6783

           Summary: RTP header extensions not correctly implement
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
        ReportedBy: mdesharnais@xxxxxxxxxx


Created attachment 7748
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7748
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

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.