ings) is also annoying and frightening, its impact is very limited if we compare it with the impact of the spam generated by automats. On the other side, the use of white and black lists (if they are well imple- mented) can be an efficient way to mitigate this kind of SPIT activity. 23.4 Architecture The objective of this section is to define a common architectural view for the anti-SPIT solutions. This generic vision follows a modular approach and hence will ensure the following: Incorporation of new detection mechanisms in response to the emergence of new SPIT forms activities. Seamless replacement of SPIT detection mechanisms without harming the overall architecture. Flexibility of the suggested solution to be adjusted to the providers requirements. This means that for a provider whose customers accept with difficulty to be challenged, this provider can use another technique (for instance, audio analysis) as a substitute. The architecture we are proposing is depicted in Figure 23.1. Our design approach lies in the introduction of two basic layers: Detection layer: the main task of this layer is to test the received SIP requests against some predefined rules describing the spam behavior. This layer consists of one module or several ones that operate in general in a separate fashion. The results of these tests is passed to the Decision point which will integrate the received results from the different mod- ules and decide whether the SIP request (or the call) under consideration is SPIT or not. Some concrete examples of modules will be discussed later on. C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Incoming requests Diagnostics SIP server trigger Module 1 Module 2 Module n FIGURE 23.1 The generic architecture. Decision layer: the main task of the Decision point is to receive the results of the tests performed by the detection modules, as mentioned earlier, combine them, and classify the intercepted requests as SPIT or not. The Decision point could be either an indepen