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.

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 :pserver:anonymous@cvs.ltsp.org:/usr/local/cvsroot 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:

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

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.

Great article. Another consideration would be to use the Multiplied Linux Desktop Strategy to lower costs even further - www.omni-ts.com/linux-desktop/linux-desktop-migration.html. 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.

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.

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.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.