om the list because the mass criteria was not reached. Checksums with counter greater than one could also be removed if they were not updated for a much greater period of time (the recommendation is a time period greater than one month). Deleting old entries will depend on the traffic volume. The more traf- fic is checked, the earlier checksums can be removed. The suggested procedure Checksum database Checksum entry Request checksum counter Checksum entry Modified data Audio analyzer Checksum entry Checksum entry Reply Checksum database Audio analyzer Checksum entry Checksum entry Checksum entry Audio analyzer FIGURE 23.2 Checksum storage procedure. © 2009 by Taylor & Francis Group, LLC A Conceptual Architecture for SPIT Mitigation is to reserve a certain amount of RAM for the list of checksums; when that amount is reached the delete procedure should start and delete 10-15% of old checksums. 23.4.2 Case Studies In Section 23.4, we suggested a generic architecture to face the SPIT problem. In this section, however, we provide some case studies to show how our archi- tecture works in a practical way. In fact, different possible combinations of the detection modules are investigated and accordingly, some more complete anti- SPIT solutions are built. Although different combinations are investigated, a unique logic is behind the investigated use cases. Indeed, we start by checking whether the call or the message is coming from a reliable source. If it is the case, we check whether this source has already been seen which means that the corresponding information is stored either in the white or black lists. If not, we need to verify whether the intercepted request is originated by an automat or a human being. To achieve this, a challenge/response mechanism (or another mechanism in the same spirit) is used. At the end and if the request is issued by a human being, the session will be established and it is up to the recipient to classify this request as SPIT or legitimate. 23.4.2.1 Case Study 1 The current case study is d