t message, however, it will have also the opportunity to classify this call (resp. message) as SPIT or legitimate. The user feedback mechanism depicted in Figure 23.3 will allow the callee to insert the URI or the IP address used by the caller © 2009 by Taylor & Francis Group, LLC A Conceptual Architecture for SPIT Mitigation either in the black list, SO further calls or messages from these user will be blacked, or in the white list, SO all further calls or messages from this user will be accepted without any anti-SPIT detection. 23.4.2.2 Case Study 2 The audio analysis framework is another solution for dealing with SPIT activi- ties. This solution follows the same spirit as the first case, however, the authen- tication module and the C/R module are replaced respectively, with proxy check module and Audio Analyzer module. In fact, on the one side, both the authentication module and the proxy check module are used to enforce the authentication process and prevent the use of fake identities, however, they work differently. On the other side, the C/R module and the Audio Analyzer module have the same scope, i.e., the detection of SPIT activities handled automats. However, the detection techniques used in both are different. The authentication module filters the SIP signalling, however the Audio Analyzer monitors the RTP session. The audio analysis based solution is depicted in Figure 23.4. The first detection entity in this framework is the check proxy module. Its way of operating is described in detail in Section 23.4. If the check proxy does not report any suspicious behavior, the SIP request will be tested further through the white/black lists module and the machine learning module. The manner this is achieved was already discussed in Section 23.4. If these tests are successful, the request is directed to the last test, namely the Audio Analyzer module. Contrary to the other modules which take their decision based on the SIP session, the Audio Analyzer takes its decision based on the RTP session. For this reason,