This is the third post in a series of posts (part 1, part 2) describing a secure alternative to applications like WhatsApp. I started with the following statement:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

In this post, I will discuss the SIP service providers, how to enable them to make a profit, while keeping the network open and secure.

Basics

Service providers are expected to be third parties, either for-profit or not. PSTN termination would be an optional feature, possibly only offered by for-profit services.

The services would consist in just a standard SIP service, with STUN/ICE for NAT traversal, plus an API for getting PSTN termination rates, credit balance, account creation, and for buying credit.

All authentication will be performed with public key cryptography, using the data already available in the directory service.

The idea would be that companies can make a profit by selling PSTN termination and SMS sending. In this way, users get good rates for calling/texting people who are not part of the network, and free SIP-to-SIP calls don't impose a big load on the service.

It is expected that the providers would offer some free calls, to allow the users to test the service. Public providers like Betamax already offer free calls to land lines in many countries.

To make this simple for the users, the client application would use the API to provide an unified interface to the service providers, without the need for passwords or a web browser.

To support multiple services, the overseeing authority must be in charge of compiling a list of authorised providers, which then the client application would use when creating an account. Provider selection can be made automatically, depending on commercial agreements or user location, and for power users, the option to manually choose a provider should be offered.

To ensure control of the providers, they should not be able to control the directory servers used. The client application should be careful in exposing as little private data as possible to them.

Account creation

With the components described so far, we can think already of how account creation and first calls would be handled:

  1. The client application creates a public/private key pair.
  2. It requests the directory service to create an account for the public key and the phone number.
  3. The directory service uses an encrypted SMS challenge or other similar mechanism to authenticate the request.
  4. The public key is published, associated with the phone number.
  5. The client app gets a list of service providers, which includes configuration parameters and PSTN rates, and offers the user the chance to select one, or it is automatically selected.
  6. The client app then requests an account creation using the phone number as identification, while authenticating with the published key.
  7. The provider uses DNSSEC to validate the request, and an account is created.
  8. The client then creates an ENUM record in the directory service, associating the phone number with the SIP account.
  9. The client registers with the SIP service, again using the public key to authenticate, and can start making calls right away.
  10. When the user wants to make a non-free call, the application can offer to buy credit, or use the GSM network.

How is this different

As you can see, there is not much difference with the current status. In fact, I would expect that traditional VoIP providers could become part of this network without much additional cost.

The big differences are:

  • Authentication is delegated to the directory service.
  • The provider API, wich handles all administrative tasks, usually offered by web applications.
  • Account creation is 100% automated and immediate.
  • The provider must offer federated SIP service, and use encryption for all SIP transactions.
  • PSTN termination would ideally accept encrypted RTP streams, but that's probably too much to ask.

What's next

In the next post I will describe what's possibly the most challenging part of this project: the client application.