ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] RFC2733 implications for the RTP header extension (X) bit

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 30 Jan 2007 14:48:05 +0100 (CET)
Hi,

The problem with the current RTP dissector is that it is unaware of the
profile being used for the session. Therefor it has no knowledge how to
interpret the various fields in various circumstances. A number of bugs
have been filed just because of this reason. Adding generic profile
support would be a valuable addition to RTP dissection.

Thanx,
Jaap

On Tue, 30 Jan 2007, Mark Lewis wrote:

> RFC2733 "An RTP Payload Format for Generic Forward Error Correction"
> requires the RTP header extension (X) bit to be used in an otherwise
> non-standard way. The header extension is never present, independent of
> the value of the X bit. The X bit contains the result of the FEC
> protection operation as applied to each of the data packets protected by
> that FEC packet.
>
> I am considering adding support for this into Wireshark. Has any thought
> ever been given to incorporating RFC2733 support into the RTP dissector?
> Are there any good reasons why this should not be supported?
>
> Further, I would be interested to hear suggestions on how I might
> implement this. The dissector working on the RTP payload would be
> responsible for the majority of the RFC2733 dissection, but the RTP
> dissector itself would need to be aware of its payload type in order to
> treat the X bit correctly.
>
> Thanks for any comments.
>
> Mark
>