Proof of concept — demo environment, not production. No SLA, no emergency calling (no 911/112), data may be reset without notice. Calls will drop after ~50s as the app is in testing mode.
T9phone

How it works

Closed groups

A T9phone group is a closed calling circle. You can only ring people who are in at least one group with you. There are no public numbers, no PSTN, no directory you can browse. If you are not in someone's group, you cannot reach them — and they cannot reach you.

T9 dial codes

Inside a group you call people by typing their nickname on the keypad — the same way older phones spelled words with multi-tap. Each letter maps to one digit:

  • a b c → 2
  • d e f → 3
  • g h i → 4
  • j k l → 5
  • m n o → 6
  • p q r s → 7
  • t u v → 8
  • w x y z → 9

Your dial code is your nickname run through that table. The nickname gandalf becomes 4263253; noble becomes 66253. Your nickname is shown on the call screen so the person you call sees who is ringing them.

One person, multiple groups

If you belong to several groups and someone else's dial code happens to match across two groups, T9phone has two ways to disambiguate:

  1. Set a default group from the dashboard. The default group is searched first.
  2. Dial with a prefix: *N*<code>, where N is the position of the group in your alphabetically sorted group list. For example *2*262 calls the user with dial code 262 in your second group.

Audio path

Calls run over SIP/TLS to a small FreeSWITCH server. The audio itself flows peer-to-peer where possible (via ICE), or through a TURN relay when symmetric NAT prevents a direct path. T9phone never records or stores call audio.

End-to-end call encryption (ZRTP)

What you need to do on every sensitive call: when the call connects, your phone displays two words on the call screen. The person you are talking to sees two words on their screen too. Read your two words out loud and confirm that the other side sees the same pair. If they match, no one is in the middle and the rest of the conversation is safe to have. If they don’t match, hang up.

That is the entire user-facing protocol. The rest of this section explains why those two words are enough.

SIP/TLS protects the signalling and TURN-relayed media from passive observers, but the server still sits in the middle of the connection. ZRTP closes that gap: when both ends support it, the audio is encrypted end-to-end with a key the server never sees.

What happens when the call connects

  1. Hello. Both clients announce ZRTP support over the RTP stream itself — no extra signalling, no server involvement.
  2. Diffie-Hellman handshake. Each side generates an ephemeral key pair and exchanges public halves. They each derive the same shared secret. The server only relays opaque packets; it cannot compute the key.
  3. SRTP turns on. The shared secret keys SRTP — symmetric encryption applied to every audio packet from then on. The call audio is now opaque to FreeSWITCH, coturn, your VPN, your ISP, and anyone in between.
  4. The phone shows a Short Authentication String (SAS). Two words, derived from the same shared secret on both sides. Each phone displays them on the call screen.

Why you read the two words out loud

A man-in-the-middle attack against the key exchange would have to substitute its own key with each side. That would produce different shared secrets on each leg — and therefore a different pair of SAS words on each phone. If you read the words to the person you called and they match what is on their screen, there is no man in the middle.

The voice channel itself is the second factor. You recognise the other party’s voice; they recognise yours; both phones show the same two words. An attacker would need to fake the voice and intercept the key exchange and produce a colliding SAS — vanishingly unlikely. If the words don’t match, hang up.

Subsequent calls

After the first verified call, both clients cache part of the shared secret. Future calls between the same pair derive a new key that mixes in the cached value, so a one-time MITM would be detected even without re-reading the SAS — your phone shows a warning if the cache breaks. Most clients display a small padlock or “Verified” mark once the SAS has been confirmed at least once.

What ZRTP does not protect

  • Metadata. The server still knows who called whom and for how long. ZRTP encrypts the audio, not the fact that the call happened.
  • Compromised endpoints. If malware on either phone has microphone access, it captures the audio before encryption and after decryption. End-to-end means end-to-end — the ends still have to be trustworthy.
  • Calls where the peer disables ZRTP. ZRTP is negotiated; if the other side turns it off, audio falls back to plain SRTP keyed by the server. Your client will indicate the downgrade — pay attention to the lock icon.