Architecture Overview

Terminology

RedPhone is an encrypted VoIP client designed with the mobile environment in mind. In any RedPhone call, there are generally four participating entities:

1. The initiator RedPhone client. This is typically the device of the RedPhone user who is initiating a call to another RedPhone user.
2. The responder RedPhone client. This is typically the device of the RedPhone user who is receiving a RedPhone call from another RedPhone user.
3. The master RedPhone server (described below).
4. The relay RedPhone server (described below).

So in the RedPhone environment, there are two types of clients (initiators and responders) as well as two types of servers (master and relay).

Role of the RedPhone Server

The RedPhone Server (as a general class) is responsible for:

1. Signaling. The RedPhone Server receives call setup requests from initiators and signals responders that they are receiving an incoming call.
2. Authentication. The RedPhone Server provides a server-trusted level of authentication that initiators and responders are who they claim to be when setting up calls, making it non-trivial to spoof calls.
3. NAT Traversal. The RedPhone Server acts as a TURN server, efficiently relaying opaque encrypted RTP packets from one device to another in order to deal with the impossibility of direct peer-to-peer communication on most carrier networks.

The third responsibility, NAT traversal, demands that clients wishing to conduct calls with appropriate low-latency characteristics need to be near the RedPhone server. It would not be acceptable for an initiator and responder, both located in Asia, to route all of their traffic through a RedPhone server on the east coast of the United States.

So in practice, RedPhone servers are divided into two types:

1. master servers, which are responsible for signaling and authentication. These can be located in trusted locations and given isolated access to the RedPhone user database and signaling interfaces.
2. relay servers, which are responsible for NAT traversal. These can be scattered in POPs throughout the world, in order to provide the lowest-latency path for a call. Since all authentication and signaling are delegated to a master server, the relay servers don't need to be as highly trusted, and can be located in POPs where adversaries might be able to eventually gain physical access.

Basic Anatomy Of A Call

So we see that a call has the following steps:

1. An initiator contacts a master RedPhone server, and signals that they would like to establish a call with a responder.
2. The responder receives an encrypted signal, connects to the master RedPhone server, and indicates that it has received the call signal.
3. If the responder chooses to answer the call, it is relayed through the closest available relay RedPhone server.

The signaling protocol is custom to RedPhone (documented in depth elsewhere), and the voice traffic is encrypted using ZRTP.