epicted in Figure 23.3. The involved components have already been discussed previously and are not going to be discussed here again. We will restrict ourselves to the description of how the corresponding architecture is used for filtering SPIT. Upon receiving a SIP request, the SIP proxy forwards this request to the Decision point. The latter, in turn, forwards it further to the first detection module in this solution, namely, the authentication module. The latter will assure that the caller is exactly who is claiming to be. If the operation triggered by this module fails, the call will be dropped. If this operation succeeds or if one of the domains (inbound or outbound) is not implementing this technique, the call will be treated as a normal SIP session, SO it will be submitted to the next anti-SPIT test, which is represented by the white/black lists module. This module analyzes the corresponding URI information and compares it to the entries stored in the black lists repository. If the request comes from Incoming requests SIP server Decision point Authentication White/Black Proxy check Machine learning Challenge/Response module lists module module module module User feedback FIGURE 23.3 First case study architecture. C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security a domain listed in the black list, the request will be rejected without any further processing. This means that the white/black list module will inform the Decision point about that, which in turn informs the SIP server about the decision. As a consequence, the SIP server will simply reject the request under consideration. If the domain from which the SIP request was issued is not on the black list, a second test is performed. Here, the domain information of the intercepted SIP request is checked against the information stored in the white list. If the request comes from a domain listed in the white list, the request will be forwarded without any further processing. In this case, the white/black list module wil