Breaking Up With Your Phone

on Chris Martin's Blog

dark cell phone tower

Let's decouple our ability to call and text from the need to carry a mobile phone. You can port your phone number to a VoIP + SMS provider, then access its services using platform-agnostic protocols and client software that you can run on any computer or network connection in the world, including a mobile phone when you choose. The goal is to maintain your access to the PSTN + SMS networks, and your existing identity (phone number) on those networks, regardless of which device you're using, without having to run proprietary software.


In 2016 we have many ways to communicate that are both strongly encrypted and easy to use. Still, much of the world still talks on the phone and texts via SMS. These networks are badly compromised by mass surveillance. Worse, most people's access to these networks is tied to a particular mobile phone. Cell phones are packed with sensors and software that surveill users and their associates at all times, often without the knowledge or consent of these parties. With effort, most of the smartphone-centric privacy issues can mitigated, at least with Android OS 1. Still, the following two intrusions cannot be mitigated in a practical way.

1. Network-Based Location Tracking

If you carry any cell phone (it doesn't need to be a smartphone), the carrier tracks your physical location using tower-based trilateration. This doesn't require GPS, and it occurs even if you disable the various location services on your smartphone. It is necessary for the health of the network, so that your data connection can be efficiently handed off between towers as you move about. It is also very convenient for an actor who wants to know where everyone is (1 and 2), all of the time (3), and who they meet/travel with. (The NSA wants you to believe they're not trying to collect this information inside the USA. Evaluating that agency's track record of honesty is an exercise left to the reader.) Also, the US government uses tower-based positioning to assassinate suspected terrorists with flying robots in the middle east. If you believe the anonymous purported drone operator:

"People get hung up that there’s a targeted list of people," he says. "It’s really like we’re targeting a cell phone. We’re not going after people – we’re going after their phones, in the hopes that the person on the other end of that missile is the bad guy."

2. Baseband Processor

The baseband processor (BP) is a second computer inside your mobile phone, separate from the application processor (AP) that runs Android or iOS. Its primary function is to control the radios that communicate with mobile networks. It also has direct access to hardware sensors, and some BPs control their own power state independently from the AP.

The baseband processor's proprietary operating system is difficult to inspect, but those who have tried find a poor security model and easily-exploited vulnerabilities (1, 2). It is rumored that sophisticated actors already use BPs to remotely exfiltrate data from targeted phones and listen to their users' activities. Without better visibility into how modern baseband processors function, it is difficult to make informed decisions regarding their privacy/security risk if you are concerned about such things.

Maybe you don't see a reason to stop using your mobile phone now, but you want to retain the option in the future -- when surveillance technologies are deployed in more pernicious ways against larger groups of people, or under unspecified future political conditions. Maybe you only want to use your phone some of the time, based on your assessment of the convenience and risk in various situations. We need this flexibility to change our minds, without losing the ability to reach others (and be reached) on the phone and via SMS.

Design Goals

We need a service that lets us call and SMS from any device on the internet (including a mobile phone, when we choose). Many commercial VoIP services claim to deliver this, but few meet the following requirements.

  • Send and receive both phone calls and SMS messages
    • Using non-proprietary client software that speaks standard VoIP (SIP/RTP) and text (HTTP/email) protocols
    • Using any computer, including a smartphone (receive an incoming call/SMS on any device)
  • Port in a US-based mobile number
  • Bonus: service exposes an API so I can build my own software around it

"But wait", you say, "SIP and RTP are not encrypted protocols! Someone could intercept your packets and listen to your calls!" You are right, but remember that we're connecting to the PSTN, an even weaker link where someone is almost certainly intercepting your traffic with the ability to listen to your calls -- here is a good explanation. I'm not trying to secure my communication over these untrusted networks (there are much better options), just find a platform-agnostic way to access them. (If you're nervous about using VoIP on public Wi-Fi hotspots, you can tunnel your VoIP traffic through a VPN at the penalty of some additional latency.)

Also, I'm already running a CardDAV server to store and synchronize my contacts, so the solution doesn't need to do that.


I considered but passed on these services:

I eventually chose, which satisfied all my design goals. The first thing I noticed about was their excellent wiki! I also noticed they are running Asterisk under the hood. provides advanced call flow configurations without marketing it as a "Cloud PBX" and charging a premium. This means that (among many other things) you can create a subaccount (extension) for each of your devices, add them to a ring group, and forward incoming calls to all devices in the group simultaneously.


The solution I configured with isn't perfect, but it's not bad!

Calling on

Using VoIP Only

VoIP gives you lots of flexibility: nearly any general-purpose computer can make and receive calls using a softphone application. These also exist for all the major smartphone OSes, so you can use your smartphone with a VoIP service. (You can also use a dedicated VoIP device, but I'm not going to bother.)

If you have a smartphone running Android 5 or later, try the built-in Android SIP client. It is nicely integrated with the native Phone/Dialer application. On my computer running Debian GNU+Linux, I chose Linphone.

Your computer is probably behind a firewall; in order to complete SIP registration and receive incoming calls, your softphone needs to know how to traverse NAT. On Linphone, this was as easy as selecting "Behind NAT / Firewall" in the network settings, and specifying any public STUN server (I chose

The voice quality with VoIP can be very good, but it depends on the quality of:

  1. Your internet connection
  2. Your audio setup (speaker/headset/mic), combined with
  3. Your client's echo cancellation

If you are not using echo cancellation, then you need good audio isolation between your headset/speaker and microphone. My sister reported a horrible echo when I called her using my built-in laptop speakers + mic, which went away after connecting a Bluetooth headset. Calls that I placed using the Android SIP client on a smartphone were also fine.

My test calls were excellent with a good internet connection (home wi-fi or Verizon 4G), but I had unusably severe audio latency (like, 5-10+ seconds) on AT&T's HSPA+ network. (I also tried the proprietary ZoIPer Android app, and this had the same problem - likely something with the network.)

VoIP Forwarding to Mobile Phone

If you want to travel with your smartphone but don't have good results with VoIP on its mobile data connection, there is another strategy: you can continue to use your mobile phone directly on the mobile voice network. In order to receive incoming calls from a number you've ported to a VoIP service, you'll need to re-activate your mobile phone with a new number, then add that number as a forwarding destination in your ring group, right alongside the account/subaccount for your VoIP-enabled computer.

There is one problem with this arrangement. When you place outgoing calls from your mobile phone, your caller ID will display as a new number, not the ported number that people already know you by. There are three different ways around this:

  • Block outgoing caller ID from your cell phone; people will see your calls coming from 'private number'.
  • Tell people that sometimes you'll call them from a different number, but they should continue to call you on your original number.
  • Order an additional number in (they are called DIDs) and attach a DISA to it, configuring the DISA to use your externally known number as its outgoing caller ID. When you want to call people from your cell phone, you "island-hop" through, calling into the DISA and then placing your outgoing call from there.

SMS on

First, I should mention one overall drawback: has no MMS support. I don't mind this because group MMSes / "mass texts" are annoying (no way to unsubscribe). I'll just tell people to send cat pictures via email instead.

Anyhow, I found four ways to send the receive SMS messages on

SMS-to-Email Gateway allows you to receive and reply to SMS messages via email. This is a neat way to be notified that you have a new SMS, but I found three issues when I tried to use it for conversations... pagination bug

  1. Splitting longer messages is sort of buggy - see above.

  2. The design of the gateway only allows you to receive and reply (sending an SMS to an existing number that has texted you before). This is probably because they use a unique ID in the subject line. If you want to start a conversation with a new number, you'll need to use one of the other options.

  3. The messages arrive with a From: address of [smsnumber] <>. Since they all share the same email address, you can't attach names to them by saving new contacts in your email software.

A solution to 2. and 3. would be to use email addresses whose local-parts are unique and predictable per SMS number, like Then, you could assign contact names to them, and send an SMS to new numbers directly by using the appropriate email address. (, maybe you're listening!)

Desktop web app

This seems like it was built mostly for troubleshooting purposes. Not a good UI for having a conversation. SMS message center

Mobile web app

Much better UI than the desktop site (also very usable in a desktop browser), but forces you to re-authenticate after a few minutes of inactivity, which isn't fun on a smartphone keyboard. It also doesn't appear to support push notifications, which people tend to expect with SMS. SMS mobile app

REST/JSON API, a.k.a. "build your own SMS application"

This is really useful and I might use it to build an XMPP gateway. I think SMS via XMPP instant messaging would provide a good user experience on desktop and mobile OSes. XMPP has excellent non-proprietary clients for all the major platforms, despite its faults (e.g. managing state between multiple devices on the same account). SMS Android app

It looks like a Michael Kourlas wrote a native Android app using the REST/JSON API. Unlike the web applications, it has push notifications. From a few minutes of testing, it seems very good - the most usable of the existing options! My only hesitation is that it only works on Android OS, violating the design goal of platform agnosticism. It also leaks a little bit of metadata (which of your numbers receive an SMS and when) to the developer's Google Cloud Messaging broker, but again, there are much weaker links in the chain.

You can get the Android APK from GitHub or Google Play, and see the source code on GitHub.


I haven't yet taken the plunge and ported my mobile number, but seems very good. I'm only holding off because I'm not in love with any of their existing options for SMS. I may build a solution to that, and cover it in a subsequent post here. :)

(Opening photo credit Leonard J Matthews on Flickr.)

  1. You can replace your stock operating system with Cyanogenmod, avoid installing Google Play services, carefully vet each app that you install, and so forth - a topic for another post.


Hi Chris,

I arrived at a very similar solution to yours -- I use for my primary PSTN presence, receive calls via SIP or adding a cellphone forward to the ring group, and placing calls via DISA. I use the API to bridge SMS sending/receiving to XMPP clients I run on my phones/computers/etc.

I'm mostly happy with the arrangement, although there are a few downsides. DISA calls, and maybe even forward calls, seem to sometimes add a bit of latency that can make conversations awkward. Also the lack of MMS is increasingly becoming a handicap. Not only can you not receive multimedia or group texts, but these days iPhones (at least) seem to be sending long messages as one 160-character SMS message, and the remainder in an MMS message, so I receive truncated texts. Convincing people that I have a crippled phone service with special rules seems like it would be a hard sell when they can communicate with 99% of their peers without such limitations. :(

I hope that comes up with some way to support MMS, since it is becoming necessary for normal communication. At times, I've been tempted to look into a Twilio solution, since they claim to support MMS in some way.

Hey Chris,

Enjoyed this article, breaking up with ones phone definitely is becoming more and more of thought these days, it may become a nessesity in the future. With the privacy and security concerns of this day and age. I like what you have wrote in regards to switching to a SIP related solutions for communication, definitely a step in the right direction. I have mostly tried using secure calling with the SIGNAL app and CsipSimple app. With similar results as you, works OK in 4G and wifi, not so great below 4G. I'm kinda hoping the future switch to 5G and greater adoption of 4G may help mitigate this. As for location based tracking, no real simple solutions(drives me nuts), one possible solution for (though a long shot), is , a long read, in the initial development stages but a possible solution to location based tracking. Couple this with Copperhead OS(for hardened security) then use secure calling, may actually have a full secure solution. At least that's what I will testing out going forward. Give me your thoughts...