Connecting Cisco Communicator to a thin client

Contemplating a marriage of VoIP and thin client? This extensive how-to explains how to hook up Cisco Communicator and HP thin clients.

Streaming the Cisco IP Communicator (VoIP client) to HP's XPe thin client (t5720) using Citrix Presentation Server Platinum Edition (now XenApp Platinum) is at this stage still a concept and has not yet been qualified as a complete solution. Still, streaming VoIP directly to the endpoint, instead of publishing, has many benefits that merit serious consideration.

Recently, I collaborated with Mike Dougherty, consulting engineer with Cisco Systems; Modesto Tabares, senior developer (primary "super-smart" engineer responsible for VoIP integration at Citrix); and Derek Thorslund, product strategist, Citrix Systems.

First, we will go over why you would use Citrix technology to implement this as a solution.

Streaming versus publishing

Let's talk about why you need to stream VoIP instead of publishing it. ICA is a TCP-based protocol that does not have UDP support built in at this time. TCP is notorious for degrading much more quickly over high-latency networks than UDP. Performance over ICA is simply not yet where it needs to be for real consideration as a "production" solution (especially if there is an SLA tied to it).

Some people may feel I am overstating or even exaggerating this point. I have been made aware of at least one customer that has deployed VoIP over ICA and been impressed with the performance. Basically, it is my understanding that this specific customer is running this solution via LAN only using high-speed network connections. In this scenario, all the traffic from the VoIP PBX to the "published" soft phone is via UDP. From the XenApp Server to the endpoint is where you will get latency. This could potentially make sense as a use case for smaller environments (if they can afford the bandwidth). In larger enterprise shops where WAN is the name of the game, it is not compelling.

Perhaps I am being a bit black and white about the whole thing. In terms of production and performance, however, I think it's the end-user experience that really matters today. By streaming VoIP, you are landing it locally on the endpoint and it is connecting directly to the Cisco Call Manager Server instead of relying on ICA.

In the current incarnation of XenApp 4.5, VoIP over ICA is not supported, since soft phones need to open the audio device more than once (first for ring tone, then again for the voice path). This is expected to be resolved with MS 2008 and the Delaware release of XenApp. Even with these improvements, however, VoIP over ICA may not be a realistic solution for some or most customers. I will reserve judgment until I see it in production.

I do know that Citrix is working on a new codec that may address some of the above concerns about bandwidth, and it is actually pretty impressive. If you are interested, check out Derek's video demo.

I think everyone is familiar by now with the benefits of streaming in general. It centralizes management, reduces desktop support and allows administrators to roll out application updates easily. You just edit the application profile, and the next time a user logs on, the updated application is streamed down. Another cool thing to consider is that with Citrix streaming, you can allow users to check out their license, so if for some reason the Citrix farm experiences an outage, the users still have access to the VoIP system.

Barriers to successful streaming

There are some known barriers to Citrix's streaming solution. You cannot stream applications that have driver, DCOM or service dependencies and expect the modules that have these features to function. The IP Communicator is a great example; Today, Cisco's E911 is nonfunctional because it has a driver dependency.

There are also some known barriers to streaming applications to a thin client. One issue is the footprint of the application. There is no hard drive. The cached application is stored in flash memory. This is a consideration when looking at the size requirement of the cached data and what its resource requirements are.

Another issue is the interpretation of the Microsoft licensing agreement for Windows XPe. This may be a non-issue, since embedded operating systems are widely used for telephony, but Microsoft has not made any public statement to endorse running soft phones on WinXPe, so it is up to you as the customer to review your licensing agreement and interpret it appropriately.

Project Alice (reverse seamless)

This is one of the most exciting projects (to my mind) that Citrix is developing today. It could have a direct impact on deploying solutions such as VoIP in VDI scenarios. Think about it in terms of the issues with performance degradation via ICA/TCP. As far as I am concerned, the only "real" option for this today is landing it locally on the endpoint so it connects directly with the Call Manager Server. If you streamed this to the client or even used Altiris or SMS to land it locally, it would still show up on the user's virtual desktop as an icon. It would appear to be seamless to them even though it is actually on the endpoint.

You may wonder why I would do this instead of using Altiris or SMS. The end goal is the same, right? It is, but if you are a Citrix admin in a large shop, you are likely to want to keep control of all of your applications and how they are delivered.

There is also the license angle. If you have the streaming licenses to begin with, why not leverage them? It's also nice to have one vendor to blame for everything; Besides, Citrix is used to being the first suspect; they can handle it.

Now let's go over the streaming implementation steps, in case you want to try this yourself.


This document describes the steps necessary to be able to use the Cisco IP Communicator software as a client-side virtualized application on XenApp (new name for Presentation Server).

The major steps described in this procedure are:

  1. Creating the application profile for the Cisco IP Communicator software.
  2. Preparing the client endpoint device.
  3. Deploying and launching the application

This document assumes you have a working XenApp PS 4.5 installation and are familiar with using the Application Streaming feature (also referred to by Citrix as client-side application virtualization) in XenApp.


The steps described in this document require the following products:

  1. XenApp Presentation Server with FP
  2. Citrix Delivery Client (SV) 10.1
  3. Citrix Delivery Client (CV) 1.1
  4. Cisco IP Communicator 2.1.1
  5. HP Compaq t5720 thin client, with a minimum of 512 MB RAM and 1 GB of flash memory


Creating the application profile for the Cisco IP Communicator software.

When creating the application profile for the Cisco IPC using the Citrix Streaming Profile, you need to select "Advanced Install" in the profile wizard (this is necessary because some registry keys need to be updated as part of the profiling).

The streaming profiling sequence will consist of two steps. In the first step, the Cisco IPC installation will be profiled by selecting the "Run install program or command line script" option in the profiling wizard. A "virtual restart" is not required. At the end of the Cisco IPC installation, do not check the "Launch Cisco IP Communicator checkbox."

Once the Cisco IPC installation in the profile has completed, select the option to "Perform additional installations" in the profiling wizard.

The next step is to update some registry settings in the newly created profile. Select the "Edit registry" in the profiling wizard.

Click on "Launch Windows Registry Editor" to bring up regedit. Using the regedit, create the following DWORD value in the registry with value of '0'. HKLM\SOFTWARE\Cisco Systems, Inc.\Communicator\EnableCDP = 0

Note that the above step disables the use of the Cisco Discovery Protocol by the IP Communicator software. This is done to prevent the software from displaying error messages related to CDP, since the client-side application virtualization environment does not support it (it is, after all, a service). It is important to note that this change in the registry will also disable the E911 functionality of the IP Communicator without warning to the end user.

Finish the profiling by selecting "Finish installations" in the profiling wizard.

Complete, sign (optionally), and save the profile as you would with any other application.

Preparing the client endpoint device

The HP thin client must be prepared for client-side application virtualization by installing the Citrix Streaming Client. Note that the HP client comes preconfigured with a write-filter that will discard, upon a reboot, any changes made to the client. This can be avoided by either "committing" the changes or disabling the write-filter. Please consult the HP documentation accordingly.

As of this writing, the Windows XP embedded HP thin client (t5720) does not support USB audio devices out-of-the-box. USB headsets provide a superior audio experience when compared with the use of analog headsets with the HP thin clients.

In order to add support to the HP thin client for USB headsets, copy the following two files from any XP PRO 32-bit machine into the same location in the client:

  1. C:\windows\system32\drivers\usbaudio.sys
  2. C:\Windows\inf\wdma_usb.inf

NOTE: These files are part of the base image of the HP t5730 Thin Client and can be downloaded here.

It is possible that during the deployment of the streamed Cisco IPC to the HP thin client, the client may run out of space in its temp folder. To correct this problem, you must disable the HP write-filter and set the TEMP and TMP environment variables to a folder in the C: drive (by default they point to locations in the Z: drive). Note that the steps described in this document can be applied to PCs running Windows XP SP2 as well.

Deploying and launching the application

At this point, you are ready to publish and launch the Cisco IPC in the same way that you would any other streamed application. You should publish two applications:

  1. The Audio Tuning Wizard, which will allow the end users to customize and tune their endpoint audio configuration.
  2. The Cisco IP Communicator, which is the soft phone itself.

Once the application is streamed and running on the client, it must be configured to communicate with the Cisco Call Manager, just as a locally installed instance would.

Important notes – Cisco IP Communication considerations

The following are two issues that need to be considered. Today there are no workarounds. However, it is my understanding that these are not showstoppers to a pilot rollout, and they are being addressed by Cisco.

Enhanced 911 not functional

One of the steps described in this document is to disable the use of CDP (Cisco Discovery Protocol) by the Cisco IP Communicator. This prevents the IP Communicator from displaying CDP-related error messages. The Citrix client-side application virtualization environment does not support CDP because it is a service. Citrix's client-side virtualization (or app streaming in normal terms) has a few drawbacks, one of them being lack of support for any feature in a streamed app that requires a service.

The E911 implementation in IP Communicator has a dependency on CDP; therefore, disabling CDP will also disable E911. The impact of this is that if the user makes a 911 call, no location information is provided. The risk that location information will not be transmitted correctly is a general issue with soft phones (it is not localized just on thin clients or streamed apps). The callers have to be able to provide location information themselves.

Impersonation risk (or spoofing)

The security model employed in this release of the Cisco IPC depends on a regular user not having access to the HKLM area of the registry. When the Cisco IPC runs inside the client-side application virtualization environment, it will always have access to the HKLM area of the virtual registry regardless of whether he/she is a regular user. This has the side effect of allowing any user to configure his instance of Cisco IPC as that of any other user in the system. Potentially, this could be used to receive another person's phone calls or to impersonate another person when making calls. If the real user does not have a password on his/her voice mailbox, the impersonator could potentially retrieve the user's messages. Cisco and Citrix are currently exploring whether certificate-based authentication overcomes this problem.

While all of these components are supported individually, they have not been qualified as a complete solution at this time. It is my understanding that the three vendors are looking for customers that would like to evaluate this solution in a pilot environment before they endorse production deployment.

Note: Though this has not been tested on the new HP t5730 thin client, the procedure described in this article should work on it as well.

This story first appeared at

Read more on Voice networking and VoIP

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.