Wireshark-dev: Re: [Wireshark-dev] sigcomp implementation
From: "Martin Mathieson" <[email protected]>
Date: Tue, 27 May 2008 17:36:25 +0100

On Mon, May 26, 2008 at 6:55 PM, Claudio Fontana <[email protected]> wrote:
I have seen the wireshark SIGCOMP implementation, and it seems to
me that some operations are missing, and many corner cases are not
handled as RFCs demand, especially regarding DECOMPRESSION-
FAILURE conditions (example: MLOD self-modifying code detection).

Some stuff like operands decoding could be refactored a lot to reduce
complexity and code size.
I would prefer to build an alternative SIGCOMP implementation for
wireshark rather than tweak the current one, in order to be able to offer
a clean design.

But maybe what you already have in place is
"good enough" (tm), and in this case I would suggest to at least
integrate the RFC 4465 torture tests in the build, in order to single out
the problems with the current implementation.

It was good enough fot the work that I did (integrating a sigcomp library into a SIP state machine inside a test product).  I only read enough specs to be able to properly configure and use it.
It was good enough to help us:
- debug our SIGCOMP implementation by comparing decodes and execution traces
- verify that NACK out support was working by corrupting  frames and making sure the Wireshark implementation found the same error as our receiver

I did make some usability improvements to the dissector, e.g
- to give me a field to filter upon when bytecode was being uploaded so I could use colouring rules quickly check my apartment management within SIP calls.
- to calculate and add a generated 'Compression Ratio' field

So, for my purpose, the UDVM implementation was fine, and I wouldn't want to lose any of the usability improvements.

But if  could provide a more complete /robust UDVM implementation without completely throwing away the existing dissector, that would be great!  If you need it, and its better for everyone, its already worth it.


Wdyt ?

Claudio F.
Wireshark-dev mailing list
[email protected]