[VoiceOps] network jitter tools

Alex Balashov abalashov at evaristesys.com
Tue Sep 1 15:56:40 EDT 2009


I think the key is that something specific to the voice domain most  
likely indexes RTP and/or SIP packets by protocol-specific criteria,  
much in the manner in which database indexes operate.  In-memory data  
structures such as hash tables and binary trees are used, keyed to  
things like Call-ID GUID, port / IP tuples, etc.

Wireshark, as I understand it, just does a full text search on the  
payloads.

I don't know for certain that this is how Wireshark actually works.   
However, that would explain why searching for packets matching certain  
header field values (exactly or wildcard/pattern) takes so long.

--
Sent from mobile device

On Sep 1, 2009, at 12:41 PM, "J. Oquendo" <sil at infiltrated.net> wrote:

> Alex Balashov wrote:
>> Brooks Bridges wrote:
>>
>>> Does anyone have a suggestion for another wireshark type application
>>> for windows that won’t explode when trying to load RTP captures over
>>> ~500MB?
>>
>> I've loaded multi-gigabyte captures into the Linux version.  It
>> doesn't explode, it just eats RAM.  A lot of RAM.
>>
>> Oh, and, at that point it's so dog slow to filter, analyse or
>> aggregate anything that I lose patience and move onto watching  
>> paint dry.
>>
> I use OmniPeek from Wildpackets on my desktop machine when I need to
> open huge files. 4GB ram quad core phenom, Vista. Works fine for me so
> far. Depending on the size of the dumps, opening a 2GB file usually
> takes under a minute to sort it all out. For the voice side, as much  
> as
> I like Wireshark, it couldn't touch Omni with a 20ft pole.
>
> -- 
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP
>
> "It takes 20 years to build a reputation and five minutes to
> ruin it. If you think about that, you'll do things
> differently." - Warren Buffett
>
> 227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E
>


More information about the VoiceOps mailing list