> -----Original Message----- > From: Jeff Morriss [mailto:[EMAIL PROTECTED] > Sent: Friday, December 05, 2003 9:40 AM > To: [EMAIL PROTECTED] > Cc: ethereal Development List > Subject: Re: [Ethereal-dev] Patch to expose OPC/DPC from MTP3, SCCP > preferences > > > > > Michael Lum wrote: > > > I wanted to make the following changes to the MTP3 dissector: > > > > 1. Add two hidden uint32 fields for 24bit OPC/DPC > > This allows display filtering using the complete 24 bit > integer value > > as an alternative to something like "mtp3.ansi_opc == 214-170-26". > > > > i.e. "mtp3.24bit_opc == 0x66aad6" or "mtp3.24bit_opc == 6728406" > > Why not re-use "mtp3.opc" (normally used for ITU) in ANSI--but hidden? > One other reason is that currently the opc header field definition use a 14 bit MASK.
> An alternative to that (that I never had a chance to finish thinking > about) is to make "mtp3.opc" a string (instead of an integer) and then > add any values we want: > - decimal > - hex > - 3-8-3 (ITU) > - 8-8-8 (ANSI/China) > > The disadvantages (that I have thought of) to doing that (and why I > added "ansi_opc" instead of doing that at the time) are: > - we'd have to sprintf() any values we want > - it's possible filter expressions that rely on it being a > number will > break--but I don't know if anybody ever does "mtp3.opc > 1000" or if > that's even allowed > - not being an integer means we'd have to actually add > decimal *and* > hex (in case some people filter on decimal while others use hex) > > The advantages are: > - we could have a pref that chooses which of the formats > are visible > (the rest would remain hidden). Or more than one could be displayed? > - there'd only be one "mtp3.opc" instead of 2 or 3 or... > _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
