hecksum is checked against a database. If the counter of the checksum is unknown this call is potentially not SPIT. Otherwise the call is very likely to be SPIT. The heart of the Audio Analyzer module is the calculation of the checksum itself. But also very important is how the algorithm is fed. The algorithm must C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security be able to identify the same or even slightly different audio streams as the same. This is not that difficult when the input of the audio streams is always the same. But in the VoIP environment, the input of two calls where the caller streams always the same message could result in different audio data. Due to different compressions, loss of packets, background noise or other things the audio data could be slightly or greatly different. The algorithm must take care of such possibilities. Also important is that comparing different checksums against each other or finding a checksum in a list must be very fast. In addition, the checksum algorithm must not produce false positives in a way that two different input data results in the same checksum. After discussing the requirements for such algorithms, we would like to list some concrete ways that SPITters can use to confuse these algorithms. Changing the audio playback starting time. Changing the audio playback speed. Pitching the audio data. Adding background noise or even sound. The mind of the Audio Analyzer module is the Checksum Database (see Fig- ure 23.2). It receives the requests with the checksum from the Audio Analyzer, looks for the checksum in its memory, increments the counter and sends the reply back to the analyzer. All checksums will be held in RAM in a list or hash tree where the search can be performed very quickly. Each time, a checksum is found or created, the counter of that checksum will be incremented and the modification date is changed. Checksums that are older than a certain amount of time and the corresponding counter is one, can be removed fr