 that uses multicast trans- mission, when the destination answers to the sender. It includes two phases, the initiation and the transmission phase. In the first phase, Hordes borrows the jondos idea from Crowds, and a public key scheme is used to add authen- tication services. In the first phase, called initiation phase, the sender sends a join request message to a proxy server. The proxy authenticates the sender, it returns a signed message that contains the multicast address of jondos, and informs the multicast group for the new entry. In the second phase, or transmission phase of a message, the sender selects a subset of jondos for the forwarding path and a multicast group address for the backward path. When data message is scheduled for transmission, the sender chooses a jondo member of the forwarding subset and sends this message to this peer as an encrypted onion data structure. The chosen jondo sends this message to another, ran- domly chosen, jondo with probability p, or to the receiver with probability 1 - p, using encryption layers as well. The receiver replies on the backward path, and for that reason it sends an acknowledgment as plaintext message to the multicast group. For the most of the aforementioned approaches, which are oriented mostly for e-mail and asynchronous web communication, there are some problems when directly adapting this approach to other types of Internet services, such as SIP. The first issue is related to latency. SIP call setup requests, encap- sulated e.g., via the INVITE method, require somehow immediate respond, either positive or negative. This feature is not supported directly by the PET mechanism already presented. Additionally, these PETs do not support bidi- rectional communications, excluding the Onion Routing, a characteristic that is essential for every VoIP mechanism, such as SIP. Moreover, anonymity should be semantically supported. In that sense, the PET mechanism should support unlinkability of location that calls are initiated (or terminated) from SIP-registered 