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.

To run KPhone, we put a script in /usr/bin on the terminal server called kphone (Listing 5). This script simply opens access to the xserver, determines the terminal at which the user is sitting and starts the KPhone process on that terminal.

To make things easier for the users, we created an entry in the KMenu for KPhone that they can select or move onto their docks if they wish. This entry is created by adding the file kphone.desktop (Listing 6) to /usr/kde/3.3/share/applications/kde on the terminal server.

The user then can select the KPhone menu item and launch KPhone (Figure 1). The first time the application is run, the user has to select File→Identity to open the Identity dialog (Figure 2) and enter the connection information. The data to enter here must match that information for the SIP accounts on the VoIP server (Asterisk in our case). Because KPhone stores its configuration in the user's home directory, it need be configured only the first time the user starts KPhone. Because /home is NFS-mounted from the server, the station where users log in is their phone, so the phone effectively follows them if they should change workstations. Once users have registered with the server, they can make calls from the call dialog and DTMF panel (Figure 3).

Figure 1. The user's desktop environment runs on the LTSP server, but KPhone runs locally.

Figure 2. When first running KPhone for a new user, enter the information for the Asterisk server.

Figure 3. The KPhone call dialog works like a hardware phone.

Initially we had KPhone running, but the response time for any action was horrible. Any time the user would perform an action that caused an SIP message to be sent—dial a number, press a phone button on an active call, answer or hang up the phone—it would take nearly a minute for the action to occur.

We determined that this problem was occurring because of a DNS name resolution issue that was waiting to timeout. The solution was to put entries into /etc/hosts for each of the stations that would be running KPhone, install dnsmasq on the terminal server and have the terminals reference the terminal server as their DNS server, configured in dhcp.conf. There are other, perhaps better, ways to solve this issue, but this solution took minimal time to configure and run, and it worked. Finding the source of the problem was the hard part.


There have been a couple drawbacks to this system. Occasionally KPhone closes for no given reason, which can be quite annoying. We have not yet determined the cause of this problem, and we hoped that upgrading KPhone to 4.1 might help.

The KPhone package.def file contains the necessary lines for building KPhone 4.1.1. The change to the Makefile mentioned above for 4.0.5 still applies as of 4.1.1. Our preliminary tests indicate, however, that 4.1.1 has the same problem of closing suddenly for an unknown reason. We have inquired with the maintainers of KPhone to see if they can help, but so far we do not know the cause of the problem.

Another drawback is that when the phone rings, it rings through the headset and gives a visual alert on the screen. If users are not in front of their terminals with their headsets on, they will not know that their phones are ringing. Once the call center is in full operation, operators probably will spend most of their time at the terminals, so this may not be a problem.



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.