Building a Call Center with LTSP and Soft Phones
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.
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).
Listing 1. Our LTSP Section of dhcpd.conf
# LTSP Path Options option root-path "192.168.42.254:/usr/local/src/lbe/opt/ltsp/i386"; #LTSP boot image (relative to the TFTP root) filename "/pxe2/pxelinux.0";
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).
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- New Products
- Reply to comment | Linux Journal
1 min 38 sec ago
- This is the easiest tutorial
6 hours 16 min ago
- Ahh, the Koolaid.
11 hours 54 min ago
- git-annex assistant
17 hours 54 min ago
- direct cable connection
18 hours 16 min ago
- Agreed on AirDroid. With my
18 hours 27 min ago
- I just learned this
18 hours 31 min ago
19 hours 1 min ago
- not living upto the mobile revolution
21 hours 52 min ago
- Deceptive Advertising and
22 hours 28 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.