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.

Aside from configuring local applications to run on the client terminals, we also need to make sure the sound cards are active when the thin clients boot. Normally, one would set SOUND = Y, SOUND_DAEMON = <nasd or esd>, VOLUME = <default volume level> and possibly SMODULE_01 = <ISA configuration string>. However, doing so not only causes the sound driver to be loaded into the kernel, but it starts the sound dæmon, which we do not want. We need the sound card to be available for KPhone when it starts on the terminal.

What we do instead is set SOUND = N to keep the normal sound system from being activated and MODULE_01 = <kernel module for the PCI soundcard>, because LTSP does not have isapnp support, so audio needs a PCI audio device. We also set RCFILE_10 = "kphone" to run the initial configuration script to ready the system for KPhone by using the audio device. Then, in /etc/rc.d in the clients' root filesystem, we put the KPhone script (Listing 3) to enable access to the /dev/sound/* files. -rwrwrw access is not the most secure, but because only one user is running processes on the terminal at a time, it works fine. Finally, we turn on the microphone and adjust the gain and volume levels.

Building Qt and KPhone

Now that you have the LTSP environment configured and operational, you can build the LBE. Getting LBE from CVS is as simple as:

cvs -d checkout -s

You then need to su to root—using sudo with the LBE doesn't reliably work—and run ./build_all. You can take a break here, as the build of LTSP in LBE takes some time to complete.

Once you have the new root filesystem for the terminals built, change your DHCP configuration to refer to that boot image and root filesystem, and restart your DHCP server. You probably want to move /etc/lts.conf from your old LTSP root filesystem to the new one. You also should move the system-wide SSH known-host keys—the ones you created as per the Local Applications section of the LBE document—to the new filesystem.

Now we need to build the Qt libraries and then KPhone inside the clients' root filesystem. The LTSP Build Environment (LBE) makes this much more manageable. Adding packages for building in the environment amounts to creating a package.def file in a directory named for the package. The package.def files describe how to get, verify the download, unpack, configure, build and install the package software. The build script in the ltsp-src directory then does a chroot and executes the build process.

Through trial and error and discussions on the LTSP IRC channel (see Resources), we were able to construct the required package.def files (see Resources for those files). Constructing the package.def file for building Qt, in ltsp-src/qt under the LBE root, was a straightforward process. Each build exported the same variables to the build environment. Notice, also, that threading is turned on explicitly at the CONFIGURE stage. KPhone builds much more easily if Qt has threading enabled, but it is not enabled by default in Qt.

Building KPhone was a bit more complicated. The package.def file (see Resources) works well enough, but the x-includes configuration option does not seem to change the resulting Makefiles. This would cause compilation errors when building trayicon.cpp. Manually adding -I/usr/X11R6/include to CFLAGS in kphone/kphone/kphone/Makefile (Listing 4) after the configuration stage seemed to fix the problem, however. The steps to build KPhone in LBE are then:

ltsp-src# ./build --configure --only=kphone
ltsp-src# vi kphone/kphone/kphone/Makefile
   (Add "-I/usr/X11R6/include" to CFLAGS)
ltsp-src# ./build --only=kphone

We also noticed that the icons were not being located properly by KPhone at first. Making a link to ../../share/kphone in opt/ltsp/i386/usr/share from the LBE root—/usr/share from the clients' root—allowed KPhone to find the icons correctly.



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.