Building a Call Center with LTSP and Soft Phones

Need to equip an office with terminals and phones, all on a small budget? With LTSP and KPhone, you can do it with only terminals, sound cards and headsets.

A new customer approached us with a need to provision the office. The customer was receptive to open-source software and was interested in using Linux. Being a nonprofit organization, the budget for the project was tight.

We provisioned the new office with a server running software from the Linux Terminal Server Project (LTSP) to make the desktop economical from the start. We then installed an Asterisk server as a PBX for the call center. To make things easier for the staff, we wanted to have a working soft phone on their terminals with headsets for hands-free operation.

This article discusses the installation and use of the LTSP build environment to build Qt and KPhone so the staff members could run KPhone locally on their terminals. I do not discuss the installation of Linux or Asterisk here, but I have included the relevant context for KPhone, which resides in the Asterisk sip.conf file. We used Gentoo for this particular LTSP server, but any Linux distribution can do the job.

Software Needed

The main software packages needed for this project were LTSP, KPhone and the LTSP build environment (LBE). LTSP easily provides thin-client access to a main server. We often recommend LTSP as an economical way to equip an office, because it focuses monetary resources on the main server rather than on the individual stations. The incremental cost of adding a new user to the office is relatively small, and administration is simplified.

The customer's new office is intended to be a small call center, so hands-free phone operation is a big benefit. We wanted to try using headsets and amplifiers that use a computer sound card for their connectivity rather than hardware phones. These headsets, coupled with software SIP phones on each user's local station, allowed us to meet their phone needs without having to buy separate phone equipment.

Because we already were using Asterisk (see the on-line Resources) as the PBX for the office, it seemed logical to use an open-source software phone. We decided to use KPhone (see Resources) as the software SIP phone, because it had proven reliable on standalone systems previously tested. One of the drawbacks of every SIP soft-phone package we investigated at the time was none supported a network-enabled sound protocol. As a result, they were required to run locally on the station that physically has the sound card. As these stations are thin clients that boot from the main server, KPhone needs to be resident in the filesystem on each station. When a user runs KPhone from the desktop, which runs on the server, the KPhone process needs to start in the local terminal environment.

KPhone is not a standard part of the LTSP package, so we needed to build it inside the local stations' root filesystem that is NFS-mounted from the server at boot time. Building software for the terminals' root filesystem requires LBE (see Resources). Building software in LBE also requires that all necessary libraries be present in the filesystem. One of the other benefits of KPhone is the Qt library is the only library required beyond those already in LTSP.

Installation and configuration of LTSP are detailed in the LTSP documentation (see Resources). One deviation from the standard install of LTSP is that the DHCP configuration file must reference the root filesystem that LBE builds rather than the root filesystem installed with the LTSP package (Listing 1).

Technically, we did not need the LTSP package because LBE includes the necessary boot image and root filesystem. However, if you are not already familiar with LTSP, I recommend you install that package first and get it operational. Deploying LTSP involves the configuration of other standard software included with almost all Linux distributions: DHCP for assigning IP addresses, boot images and root filesystem information for the stations; TFTP for client stations to retrieve their boot images; and NFS for thin clients to remote-mount their root filesystems and the /home filesystem for running remote applications. Installing LTSP provides demo configurations for all of these packages that makes setup much easier for a novice.

The main LTSP documentation describes well most of the preparation for running applications locally on the clients. Their installation and configuration also are covered on the LTSP 4.1 Web page. In addition to the software mentioned above, you also need to configure SSH client and NIS on the server.

SSH is the means we used for starting the process on the remote client. Notice that the LTSP 4.1 documentation demonstrates the use of rsh for launching the applications. Although that would work, the required dæmons for rsh no longer are part of the LTSP package. SSH is now the norm for launching local applications. You can find information about preparing for SSH launching of local applications in the Local Applications section of the LBE documentation.

NIS is needed because the thin clients need to authenticate users through SSH as they launch the applications. NIS configuration is guided by the NIS HOWTO. One item that was not immediately obvious from the documentation was that NIS would complain that /etc/publickey was not present. Creating that file with touch /etc/publickey solved the problem.

Once all the supporting software is in place, configuring LTSP to run local applications is easy: set LOCAL_APPS = Y in /etc/lts.conf within the LTSP root filesystem. This causes the clients to mount the /home directory from the server with NFS. Also, NIS is made active by /var/yp/nicknames, /etc/yp/conf being created on the clients, domainname being run with the value of the NIS_DOMAIN entry in the lts.conf file and ypbind being run. The sshd dæmon also is activated on the client.

For SSH operations to be transparent to users, we need SSH keys created without expecting users to do it themselves. To accomplish that, we installed superadduser in Gentoo, which is reported to be adduser from Slackware (see Resources) and modified it to generate the SSH keys automatically for the user when the user is created (Listing 2).



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Voice separate from LTSP

Dr. Dave's picture

We have successfully built multiple Call Centers using LTSP, however for the voice we use Grandstream Phones with headsets. Keeping the Voice and workstation separate makes a lot of sense in an Enterprise Call Center or BPO environment. If for some reason your LTS server takes a dive, it does not effect your voice server and you can continue to at least answer incoming calls until the system is back on line. The other reason is the separate SIP box or SIP phone from Grandstream has much better quality sound then trying to combine everything into one. Linux Terminal Server Project LTSP on our web site. VICIdial is another really good product that runs on LTSP.

Good Knowledge

haber's picture

Thanks for good knowledge.

Linux Desktop Multiplier

Trevor Poapst's picture

Great article. Another consideration would be to use the Multiplied Linux Desktop Strategy to lower costs even further - With the Desktop Multiplier, you can connect up to 10 call center user stations to a regular desktop (Intel P4 2.6Ghz or better with 2GB of RAM recommended).

Licensing is only $99 per seat, which is much cheaper than the hardware, management and electricity costs associated with the LTSP thin-client hardware. Plus, you'll get better performance. Each user station is connected directly to the PC and, as such, has dedicated video access.


der-Vertrag's picture

Thats a great idea.

i bookmark it

8165.tgz missing

Anonymous's picture

i'm trying to build my how call center with your idea but there's no 8165.tgz in your ftp web site... any ideas where i can find it?

8165.tgz missing

Keith Daniels's picture

This has been repaired and you can now link to the file.


All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013

sound quality

Anonymous's picture

Great article - the amount of time we waste reconfiguring workstations for the temps - seems like a revolving door. This is a sensational alternative. .. are you saying that the sound quality is equal to that of a hard ip phone ? All experiences i have had with the softphones has left a little to be desired (even in a switched LAN environment). Sound quality is important to us.

sound quality

Anonymous's picture

this is an interesting project but with today's cheap hardware ip phones and linux audio issues not to mention network issues (voip should be on it's own prioritized vlan for example) I would go down hardware based route for call centers with ltsp and asterisk - You can abstract out the extension/agent to virtually link the logged in user on the phone and on the terminal.

I would say the above example would be particularly useful when you need an agent logged in to the phone system with software on the terminal (as well as the hw phone) to provide screen pops for inbound calls.