expose its identity to, or otherwise its identity cannot be exposed by, any other entity, or the attacker. - Caller's anonymity only to the callee, in which the identity of the caller should be revealed only to the callee. - Caller's anonymity only to her/his provider, in which the identity of the caller should be revealed only to the his/her provider. - Caller's anonymity only to callee's provider; same as above, but for the peer's provider. C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Except the first privacy class, the other three are not disjoint, and may coexist. In the following sections we will see how the existing SIP anonymity proposal and specifications deal with these four classes. We should mention here that the potential attacker might be one of the service providers or the callee, depending on the privacy protection class. For instance, the attacker might be a callee that aims to expose the name of any caller that wishes not to display his/her name to the peer party. To support the above privacy classes, any anonymity architecture should make an attacker unable to distinguish between the occasions when a callee transmits or receives an SIP message and the occasions when she/he does not [4]. Additionally, it should take into account some of the idiosyncrasies of the SIP, such as: - The SIP messages should not be delayed, e.g., for mixture. - The sequence of SIP messages should not be violated. - The traverse path of the SIP messages might be predetermined, accord- ing to service agreements between local, regional and national operators. Moreover, any anonymity architecture should protect the physical location of the end-user. No one in the system, neither the system itself, will know from which point a user is connected. Even if the relation of the transmitted or received SP messages with a particular callee is not possible, the anonymity system should prevent attackers from linking the messages with physical loca- tions. This will avoid the provable expose