Mailing List Archive

Is there any information that is specific to pro-MPEG payload? if there is,
then you can check this information in your dissector and ignore the packet
if it doesn't match that.

On 6/20/06, Mark Lewis <mlewis@altera.com> wrote:
>
> Hello,
>
> I have developed a dissector plug-in for Pro-MPEG Code of Practice #3
> release 2 FEC data (
> http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf). This
> protocol is for sending FEC data over RTP.
>
> The protocol defines that this data is always sent with RTP payload type
> 96 (0x60). My plug-in currently recognizes all RTP traffic with payload type
> 96 as belonging to this protocol. However, payload type 96 is specified by
> RTP as dynamic and may be used for other purposes within other protocols. I
> don't want to issue my plug-in and then find that data of type 96 that is
> not Pro-MPEG FEC is then dissected as such.
>
> Please could somebody suggest the a mechanism for dealing with this
> problem?
>
> Thanks,
>
> Mark
>
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
>

Hi,
If there is control information sent setting up the RTP connection you
could use the mechanism used in the SDP dissector to set up a RTP
converstion
and transfer data about the Media type used for that conversation.

The AMR dissector has a preference setting (default 0 = not used) to
dissect a specified PT as AMR.

Brg
Anders

________________________________

From: ethereal-dev-bounces@ethereal.com
[mailto:ethereal-dev-bounces@ethereal.com] On Behalf Of Mark Lewis
Sent: den 20 juni 2006 11:39
To: ethereal-dev@ethereal.com
Subject: [Ethereal-dev] Dissector plug-in for Pro-MPEG CoP 3 r2
(2dparityfec)


Hello,

I have developed a dissector plug-in for Pro-MPEG Code of Practice #3
release 2 FEC data
(http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf). This
protocol is for sending FEC data over RTP.

The protocol defines that this data is always sent with RTP payload type
96 (0x60). My plug-in currently recognizes all RTP traffic with payload
type 96 as belonging to this protocol. However, payload type 96 is
specified by RTP as dynamic and may be used for other purposes within
other protocols. I don't want to issue my plug-in and then find that
data of type 96 that is not Pro-MPEG FEC is then dissected as such.

Please could somebody suggest the a mechanism for dealing with this
problem?

Thanks,

Mark