l inform the Decision point, which in turn informs the SIP server about the decision. The SIP server will simply process the considered request. If the caller is not on the white/black lists, the request is passed to another test. The latter, called machine learning module, will examines the content of the SIP message and some other related information as describe in Sec- tion 23.4. In fact, this module will help in distinguishing between potential SPIT requests and potential legitimate calls, SO only potential SPITters will be challenges using the challenge/response module. At this stage, the system reaction has to take into account the following. The SPITters are not using proxies: the callers will be challenged, if they fail, the calls will be dropped. An option is to blacklist the corresponding IP addresses for some time (this will help in case these IP addresses are legitimate which is the case where botnets are used). The drawback of this is the fact that the user to whom the IP address belongs will be penalized and could not make calls for some time. The SPITters are using open relays: here if a list with open relay infor- mation exists already, for each received call we check whether an open relay is used. If it is the case, the call will be challenged and dropped if the test fails. The SPITters are using their outgoing proxies: if the test fails, the call can be dropped or the user can be challenged again using some sort of scoring mechanisms. However, the calls in this kind of situation will never be blocked. In our architecture, the C/R module uses reverse Turing tests and not com- putational puzzles based on hash functions. This is because the VoIP com- munication should be able to be established between low CPU power devices (e.g., mobile or handheld phones) and the delay of solving hash-based com- putational puzzles may be unacceptable by a legitimate caller. If the C/R test is successful, the request will be forwarded to the callee. At this stage, the callee will answer the call or check the instan