This white paper describes the possibilities of using SwyxWare, SwyxIt! and SwyxPhone in a Microsoft or Citrix Terminal Server environment.
1. Terminal Server Basics
A terminal server configuration essentially consists of 3 parts. First, the Terminal Server Service, which runs on one or a number of Windows 2003/2008 (or newer) servers. Applications such as MS Word, Excel, Outlook or CRM applications or SAP are installed on these servers. The terminal servers now make the applications available to the terminal clients via a specific protocol, RDP (Remote Desktop Protocol) for Microsoft or ICA (Independent Computing Architecture protocol) for Citrix, the third component. The applications always run on the terminal server machine, the protocols only transport the desktop content to the terminal client, which then displays this content. Of course, keyboard entries and mouse movements are also sent back from the terminal client to the terminal server.
Each user only sees his individual session, which is transparently managed by the server operating system. The user is independent of the sessions of other clients.
- There are a number of advantages of this not so new technology (text-based terminals were the first interactive input devices in the classic mainframes):
Central storage of data and applications. So that central backup and updates are possible.
- More effective use of computing power.
- The display unit, i.e. the terminal client can be "simple". Starting with a Windows PC, Linux clients or Windows CE based clients without hard disk, fans etc.
- The low bandwidth also allows access via slow lines or while on the move.
- A disconnection or a crash of the workstation system is unproblematic, the session can be re-established and you start where you left off before.
Terminal Server Configuration
1.1 SwyxWare in Terminal Server environments
SwyxIt! can also be installed on a terminal server like any other application. Then all terminal clients could use SwyxIt! and e.g. work together with an Outlook running on the terminal server. The problem in this arrangement is the sound device, i.e. the SwyxIt! handset. The terminal server protocols do not allow the satisfactory voice data transfer and the terminal server would soon be at the end of its computing power if it had to do the voice processing for several hundred SwyxIt! instances.
Therefore in terminal server environments a SwyxIt! must be used, which does not need a sound device. This is the case when SwyxIt! is in CTI or CTI+ mode. The CTI SwyxIt! then controls either a SwyxPhone Lxxx remotely, or a second SwyxIt! installed on the terminal client, which works normally and has a USB handset or USB headset. Since SwyxIt! 2013 it is also possible to control almost any other phone via CTI+.
This architecture also has the advantage that the terminal server is not burdened with the network traffic of the actual voice data (media streaming), because this always runs from the controlled terminal to the respective remote station (other terminal or gateway). This is especially advantageous if the terminal server is located at a different location than the user and/or SwyxServer, because the CTI control commands exchanged between SwyxIt! on the terminal server and SwyxServer require very little bandwidth in the network (much less than the voice data).
The SwyxServer does not even notice that a SwyxIt! is installed on a terminal server and is used by a terminal client.
1.2 CTI SwyxIt! controls SwyxPhone (Case 1)
This is actually the normal CTI mode, in which the user has installed a SwyxIt! on his Windows PC, but he does not have a USB handset, but a SwyxPhone Lxxx, which is logged in under the same SwyxUser. Operation e.g. dialing an Outlook contact is done on the PC with SwyxIt! in CTI mode, but calls are made with SwyxPhone Lxxx. In a terminal server configuration the SwyxIt! in CTI mode no longer runs on the local PC but on the terminal server and only the screen content is displayed on the client.
Since nothing is installed on the terminal client, this configuration is quite easy to install and also works on terminal clients with operating systems like Windows CE or Linux (Thin Client) for which no SwyxIt! is available. Of course, you can also make phone calls if the terminal client is switched off.
By the way, it is not possible to record the calls in this case, because the SwyxPhone is used and it is currently not possible to record calls made with the SwyxPhone. An alternative to this is TrunkRecording, which allows external calls to be recorded on the server side for some types of trunks (ISDN trunks with SX2 card installed in the server and SIP trunks, but not SIP gateway trunks).
1.3 CTI SwyxIt! controls local SwyxIt!
The second way to run SwyxIt! in terminal server configurations requires a terminal client with a Windows operating system on which SwyxIt! can run. This locally installed SwyxIt! is only used to control the USB handset, so you will not see any skin of the local SwyxIt! during normal operation, when incoming calls the local SwyxIt! will not pop up either. As in case 1 there is a SwyxIt! on the terminal server, which is running in CTI mode and with which the user is working.
In this configuration the use of a cheaper handset compared to the SwyxPhone is possible and also the recording of calls is now supported.
Please note that in a terminal server scenario the use of SwyxIt! video telephony is not possible.
Furthermore all usual restrictions of the CTI mode apply (no local recording via SwyxIt (see 1.2), no call activation via SwyxMonitor).
Network: The SwyxIt! on the terminal server must be able to establish a direct IP connection to the SwyxServer. If the terminal server is not located at the SwyxServer, a VPN connection of the terminal server is required. A SwyxRemoteConnector connection cannot be used on a terminal server.
Please also note:
SwyxIt! on Windows Terminal Server or Citrix XenApp/Presentation Server/MetaFrame.
Memory usage of SwyxIt! on Windows Terminal Server
TAPI for Windows Terminal Services.
Please sign in to leave a comment.