The old Internet adage – “if you’re not paying for it, you are not the client, you are the product” – holds true for every single service on the Internet. The information that you upload to popular social networks, store on clouds, and transfer through popular commercial communication networks is a prime candidate for harvest, storage, analysis, and use by the creators of the services, as well as (as is now known), government security agencies.

If you want real confidentiality, you must avoid all the obvious popular and free (as in beer) options that already have proven untrustworthy. In other words, if you are serious about keeping your data private, you should steer clear of services such as Facebook, Hotmail, Skype, YouTube, Dropbox, and the like (this is the first level of confidentiality). You should also use only open source software (a second level of confidentiality), because it is the only software that is audited frequently by independent, non-biased third parties. A third level of confidentiality is that you should be able to host the servers that process and store your data yourself.

Now, some people might disagree here. Many sys admins will argue that hosting your own stuff in-house to defend your privacy is not a good idea. They will say that supporting servers is a full-time job and that most small office and home office (SOHO) setups are not as secure and fault tolerant as professionally maintained server farms at hosting companies. They would be right; however, I am not arguing security here, but confidentiality, and those are two different things.

A server farm will have backup systems, high levels of software and hardware security, and expert personnel to keep your data safe from the bad guys and protect from accidental erasure. However, a server farm is also more likely to be the target of malicious hackers and the secret laws, courts, and subpoenas you’ve heard so much about lately. A hosting company might be subject to a gag order as well as a subpoena, so, if you host your data with a third party, you might already have an NSA flunky’s grubby paws on your family photos, recordings of conversations, and private medical records, and you would not even know about it. If, however, a government agency wanted information from your own servers and decided to obtain it in a legal fashion, you would be the first to find out.

Of course, such an agency could just get an order to wiretap your communications without your knowledge, but, first, remember that they can do that with a third party hosting your data as well. And, second, that’s why encryption was invented.

Rules of the Game

In view of the above considerations, the post-PRISM software presented in this series of articles had to follow certain rules to make the grade. To begin with, all servers and clients had to be open source to comply with the second level of confidentiality mentioned above. They also had to be installable on a regular server without requiring additional special software or hardware to comply with the third level of confidentiality.

As for “hardware,” I chose a boilerplate stable and updated Debian server installation on a VirtualBox virtual machine. When installing Debian, I chose the server option (databases, web servers, etc.). All extra software needed to satisfy dependencies is listed in the article and, in general, is culled from Debian’s official repositories. Note that I deliberately did not include any repositories that contained proprietary software, such as non-free.

I avoided third-party software and services as much as possible, and when I was forced to communicate over third-party services (e.g., an ISP’s network), I made sure that the software provided point-to-point encryption.

The Case Against Skype

One company stands out as a having a total disrespect for its users’ confidential data, and that is Microsoft. It was one of the first to take on board the requirements of the PRISM program and has helped the NSA access email on Outlook and Hotmail at the pre-encryption stage. Microsoft also gave the agency access to their cloud storage service, SkyDrive, which hosts data from more than 250 million users. Additionally, the company has delivered vulnerability data to US government security agencies so that the data can be then used against users who didn’t even know their software was leaking.

In one of Edward Snowden’s documents published by The Guardian, the NSA gloats about how the number of calls intercepted on Skype tripled once Microsoft took over Skype. So, if there is one service to avoid in an attempt to improve confidentiality with your family, friends, colleagues, and clients, it’s Skype.

Your Own Secure Skype

The good news is that three very interesting contending technologies are available for audio/videoconferencing. The bad news is that, at the time of writing, two of them don’t work that well, at least not in a way that is useful to your average SOHO setup. Although it’s now 2013, apparently audio- and videoconferencing are still very hard to do. Popular, but proprietary technologies, such as Skype and Google Hangouts (originally GTalk), seem to have sucked users (and, hence, developers) away from open source alternatives.

The first alternative is Jingle, which is an attempt to bring an audio/video layer to XMPP, the technology behind Jabber. Jabber/XMPP is the base for the most popular messaging services out there, such as WhatsApp, and it works very well for instant messaging but not so much with audio/video.

Jingle was added as an afterthought to a protocol that was never intended to carry videoconferencing in the first place. In theory, a Java-based client, Jitsi, already exists, and you can try it out on the public server at Jitsi’s site. The fact is, however, that the client is very buggy and capricious about what it will connect to without throwing an exception-laden fit. Although Jitsi and the Jingle protocol are developing rapidly, the combination is not a good first choice for a production environment.

The second proposal is WebRTC, a technology developed jointly between Google and Mozilla that intends to make videoconferencing possible via a web browser (Figure 1).

Figure 1: WebRTC is interesting, but it is still in early development and quite buggy, as the screen capture shows.

To set things up, you run a server from your machine and include a set of JavaScript modules into a specially designed web page. You can then visit the page with your WebRTC-enabled browser – at the time of writing, Chrome, the Firefox nightly build, and Chrome Beta for Android – and enjoy a hangout-like videoconference. This is an interesting idea, and you can play with some demos of the technology online, but, in fact, it has several drawbacks: No stable version of a server is yet available, configuration is difficult and underdocumented, you must depend on some “secret” Google services, and all the bits and pieces are still under heavy development, so they are subject to change.

The third technology – the one that really works and works now – is based on Session Initiation Protocol (SIP). It is what VoIP is made of, and although it may seem overkill to set up a whole SIP system to get confidential audioconferencing, it seems for now to be the most reliable way to give Skype the boot.

Your Free Switchboard

The SIP server that best combines ease of installation and configuration, offers a large number of functionalities, and complies with the three laws of confidentiality is FreeSWITCH. Although FreeSWITCH is not in the Debian repositories, it is very easy to obtain the software’s source code.

To begin, install the Git version control software and then grab the latest stable version of FreeSWITCH from the project’s repository:

# apt-get install git
$ git clone -b v1.2.stable git://git.freeswitch.org/freeswitch.git

to grab the latest stable version of FreeSWITCH from the project’s repository.

Although you may find compiling from scratch quite daunting, FreeSWITCH comes with well-thought-out scripts to help you along the way.

The next step is to download a couple of tools necessary to build the files you need before starting the compile proper:

# apt-get install autoconf libtool

Then, change to the freeswitch directory where you downloaded the source code,

$ cd freeswitch/

and run a script that builds the files you need to compile:

$ ./bootstrap.sh

On a vanilla Debian install, you need to run the following to satisfy all the dependencies that FreeSWITCH requires:

# apt-get install g++ pkg-config uuid-dev zlib1g-dev libgnutls-dev 
  libjpeg8-dev libncurses5-dev libssl-dev

Next, you can configure the compilation by running the configure script created by the bootstrap.sh script:

$ ./configure

After running configure and before the actual compile, you might want to edit modules.conf and remove the pound sign (#) from the following line:

#asr_tts/mod_flite

This step uncomments the line and makes IVR (Interactive Voice Response – as used in voice-based interactive menus) available later. Finally, enter:

$ make
# make install

to compile.

Honks, Buzzes, and Robot Voices

To complete your setup, you’ll need a full library of tones, irritating hold music, and voice prompts. To download and install the FreeSWITCH default library of sounds, enter:

# make all cd-sounds-install cd-moh-install

Of course, these items can be exchanged for your own personalized recordings later, but the files offered by FreeSWITCH are great to get started.

Up and Running

Now you can run FreeSWITCH with:

/usr/local/bin/freeswitch

This step outputs a lot of status lines as it boots and will finally dump you at the FreeSWITCH command line. For all practical purposes, you are now up and running and can start placing calls through FreeSWITCH.

To test your setup, you first need to log on to one of the preset accounts. By default, FreeSWITCH establishes the IP address of the machine it is running on as the “host.” If you are unsure what IP address FreeSWITCH is using, type

sofia status

at the FreeSWITCH command line, and you will see something like the information shown in Figure 2.

Figure 2: Use the FreeSWITCH command line to get information about the system.

Several default accounts are set up in FreeSWITCH, including extensions numbered 1000 through 1019, all of which have “1234” as passwords. You might want to change these accounts and their passwords once you move FreeSWITCH into production, but for testing, these accounts will be fine. (You can change default passwords and other variables by editing the var.xml file located in the conf directory.)

To configure Ekiga, for example, go to Edit | Accounts and then choose Accounts | Add a SIP Account and populate the fields with something similar to that shown in Figure 3.

Figure 3: Configuring Ekiga for use with a default FreeSWITCH account.

Configuration can vary from phone to phone; however, on a Samsung S3 running the latest CyanogenMod, you can open the Phone App, press Menu, choose Settings, then scroll down and, under Internet settings, select Accounts, then Add Account. You can then fill in the configuration screen as shown in Figure 4.

Figure 4: Configuring an SIP account on an Android device.

Next, you can, for example, phone 9198, and you will hear the Tetris theme played by the FreeSWITCH tone system.

To include your own users, create an XML file in the conf/directory/default directory under the FreeSWITCH default directory (if you have followed this tutorial to the letter up to this point, that would probably be the /usr/local/freeswitch/conf/directory/default directory). If you wanted to create an account for user paul, for example, you would create a file that looked something like Listing 1.

_{Listing 1: paul.xml}

01 <include>
02   <user id="paul" number-alias="1000">
03     <params>
04       <param name="password" value="mypassword"/>
05       <param name="vm-password" value="myvoicemailpassword"/>
06     </params>
07   </user>
08 </include>

This is a bare-bones version of a user setup that will work with the default FreeSWITCH configuration. Realistically, however, a complete user file would look like Listing 2 and would require you to modify the /usr/local/freeswitch/conf/dialplan/default.xml and /usr/local/freeswitch/conf/dialplan/public.xml files to include the 1500 extension.

Listing 2: paul.xml, Mark 2

01 <include>
02   <user id="paul" number-alias="1500">
03     <params>
04       <param name="password" value="my_password"/>
05       <param name="vm-password" value="1500"/>
06       <param name="vm-enabled" value="true"/>
07       <param name="vm-email-all-messages" value="true"/>
08       <param name="vm-attach-file" value="true"/>
09       <param name="vm-keep-local-after-email" value="true"/>
10       <param name="vm-mailto" value="myemail@mydomain.com"/>
11       <param name="directory-exten-visible" value="true"/>
12       <param name="dial-string" 
          value="{sip_invite_domain=${domain_name},leg_timeout=30,
                  presence_id=${dialed_user}@${dialed_domain}}
                 ${sofia_contact(${dialed_user}@${dialed_domain})}"/>
13     </params>
14     <variables>
15       <variable name="toll_allow" 
                   value="domestic,international,local"/>
16       <variable name="accountcode" value="1500"/>
17       <variable name="user_context" value="default"/>
18       <variable name="effective_caller_id_name" 
                   value="Extension 1500"/>
19       <variable name="effective_caller_id_number" value="1500"/>
20       <variable name="outbound_caller_id_name" 
                   value="$${outbound_caller_name}"/>
21       <variable name="outbound_caller_id_number" 
                   value="$${outbound_caller_id}"/>
22       <variable direction="inbound|outbound|both" name="dtmf_type" 
                   value="info"/>
23       <variable name="callgroup" value="techsupport"/>
24     </variables>
25   </user>
26 </include>

To do this, locate the line that reads

<condition field="destination_number" expression="^(10[01][0-9])$">

in the Local_Extension section in default.xml and change it to

<condition field="destination_number" expression="^(10[01][0-9]|1500)$">

Then locate the line that reads

<condition field="destination_number" expression="^(10[10][0-9])$">

in public.xml and change it to

<condition field="destination_number" expression="^(10[10][0-9]|1500)$">

to include the new extension.

Here, the ^(10[01][0-9])$ string is a regular expression that gives you extensions from 1000 to 1019 by default. You can change it so you have more extensions.

If you rewrote this as ^(10[01][0-9]|150[012])$, for example, you would include, three more extensions, 1500,1501,1502. Before you go around creating tons of new numbers, however, read through default.xml and public.xml carefully and make sure you don’t write a regex that overlaps with other patterns already in use.

In Production

You’ll want to run FreeSWITCH in the foreground while you work out your own phone framework because the CLI offers comprehensive warnings and errors that are essential to help you debug your configuration files. When your phone setup is complete, you can consider running FreeSWITCH as a daemon and turning it into a service that runs in the background and runs every time the server gets booted.

For all practical purposes, you now have a working intranet equivalent to Skype, but you also have much more. Besides phoning other users on the network, you can record conversations, create groups of users you can phone all at once (the first user to pick up their phone “captures” the call), create conference calls, set up videoconferencing and, if you run a VPN, allow colleagues, family, and friends to communicate securely using the service from beyond your premises. If you have a VoIP line from your carrier, you can also easily configure FreeSWITCH to link to the outside world through the conventional phone network.

Conclusion

The thing about services like Skype (and Facebook, YouTube, Flickr, etc.) is that a lot of people use them precisely because a lot of people use them. Once you transcend this circular logic, however, you may realize that being able to phone everyone for free and letting a third party do the heavy lifting is not such an enormous advantage if it means sharing your sensitive conversations with organizations that have no business snooping into your calls. At that point, avoiding Microsoft’s phone service by implementing your own starts to make sense.

Additionally, setting up a basic Skype-like system is not hard with open source software. You can have basic and secure SIP services working with FreeSWITCH’s out-of-the-box installation up and running in minutes. That said, building on the basic setup and using FreeSWITCH to expand your telephony services is a very interesting and tempting project. However, you should note that phone systems are complex and audio- and videoconferencing are still hard to do, so, if you are overambitious, you could find yourself in over your head. But, that’s half the fun, isn’t it?