 all modules whose decision rely on the SIP protocol need to be addressed before the Audio Analyzer. If the latter is used, the Decision point must also handle the rejection of calls differently. In this case, a rejection must also close the RTP session. If the audio analysis test is successful, the request will be forwarded to the callee. At this stage and similarly to the first case study, the callee has the possibility to classify the request as SPIT or legitimate. Incoming requests Decision SIP server point Proxy check White/Black Machine learning Audio analyzer module lists module module module User feedback FIGURE 23.4 Second case study architecture. © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security 23.5 Conclusion In this chapter, we started by identifying the issues behind the persistence of the current spam that will drive the emergence of SPIT. Based on the corresponding results, we have presented a generic modular architecture for detecting SPIT. The aim of combining different classifiers is to achieve excel- lent discrimination between spam and legitimate SIP requests. The modular architecture we have adopted would allow the proposed anti-SPIT solutions to be updated, upgraded and adjusted to the needs of the providers without any difficulty. In this architecture, we have identified two main layers. A detection layer where the SPIT detection intelligence is distributed over different mod- ules, and a decision layer where the results received from the detection layer are gathered and accordingly a decision is made. Finally, two case studies are considered to show how the overall architecture works. Acknowledgment First of all, I would like to express my deep and sincere gratitude to the SPIDER project [20] members for their important support throughout this work. I am also grateful to Prof. Dimitris Gritzalis, Athens University of Economics and Business, for his detailed and constructive comments. Many thanks go in particular to the editors for inviting the author