That is the question! Warning: Really quick reflexes required to dodge stones and arrows flung by ticked-off end-users at IT staff! Seriously though, recently we have received more and more people asking us to support VoIP (and even video) communications over ICA and we are researching the area aggressively as I type this. Stick with me on this blog; at the end I will ask that you interact and provide answers to some questions to help us hone in on a spot for a Presentation Server solution in this problem space.
The attraction of combining voice and video communications over ICA is clear. Ease of firewall traversal, performance on lower bandwidth and higher latency networks and the use of a universal client for applications, data, voice and video sound very appealing. It the promise that the recent buzz around promises – a single integrated solution for all services needed by your end-users, neatly packaged and delivered securely with good performance to any end point. The entire office follows the user; not just his Presentation Server hosted applications. If the user wishes to place a call, why not do it over the same system that allows secure access to his applications from any location? Why not include peer-to-peer video communications in the mix as well?
Sounds good in theory, but there are several obstacles associated with remoting voice and video over ICA. They are not insurmountable but they are challenging due to the very nature of the protocol itself. There are several characteristics that need to be addressed in a VoIP solution that are not quite there today. For one thing, voice quality may be an issue. In an environment where telephony is mission critical such as a call center, voice quality must be commercial grade and it must be nearly as reliable as the regular PSTN quality we are so accustomed to today. The only way to get this type of service is to have a very good network in place with QoS mechanisms deployed to ensure a high level of voice quality or at least an alerting system that signals when quality degrades. This is at odds with one of the key use cases that some customers talk about when wanting to deploy VoIP Softphones over ICA. What they are sometimes asking for is WAN or internet connectivity to a back end VoIP infrastructure without having to deploy Softphones to unmanaged client devices in users homes or across the internet. In this case, the Softphone would be published on Presentation Server and the audio input and output would be remoted to the ICA client. The situation is less than ideal for commercial grade quality. The best quality that users would hope to expect in this scenario is something akin to Skype which is hit or miss depending on the connection. So, firewall traversal and WAN/internet connectivity are really in conflict with the requirement for excellent voice quality in commercial grade operations. We may be able to reach commercial grade quality on a LAN with some work but the applicability may be limited.
What else could we do? Well, we could take an approach similar to what we did with SpeedScreen Multimedia Acceleration. With this feature we leveraged ICA by sending compressed video streams to the client over the protocol and leveraged client-side processing by using client-resident codecs. The results were a of both worlds scenario where server side processing was nearly zero, network bandwidth usage was minimized and the CPU intensive video decoding and playback was relegated to the client. We could do something similar whereby a Softphone would reside on the client side (rather than on Presentation Server) and the VoIP packets would be routed either over ICA or a separate SIP connection (ICA would provide degraded quality when a SIP connection is not possible). The Softphone would either be included in the ICA Client or deployed alongside. Using a client-side Softphone along with a separate SIP connection would provide the best possible quality but may not be the best way to get a connection every time. Using ICA allows for connections in more scenarios but may result in degraded voice quality.
Why is this? For two basic reasons – first, ICA is TCP based and VoIP is UDP based. The implication is that as the network conditions degrade, TCP will force more re-transmissions as compared to what would happen on a high quality, low latency LAN and the voice quality becomes choppy to unusable. Furthermore, visibility into VoIP streams and packets is lost in a TCP based protocol like ICA. The result is that network voice monitoring and QoS equipment designed to control and maximize voice quality and guarantee commercial grade service cannot perform their functions properly. Secondly, in a remote deployment scenario, the published Softphone is separated from the user (and his microphone and speakers) by a potentially significant network segment. This could wreak havoc on the Softphone critical silence detection and echo cancellation algorithms that assume that the audio devices are collocated with the software itself not separated as in the case of a published scenario.
The bottom line is that there are some enticing use cases dealing with voice and ICA and there may be some solutions to real business problems within our reach, but there are some challenges and inherent limitations as well. The key to a workable solution lies in the customers expectations. Helping us narrow down the answers to some key questions will accelerate our ability to bring a solution to market. Here are some of the questions to start the discussion flowing:
- What are the use cases that you have in mind for or video over ICA Is this for delivery of the services to remote users or for use on the LAN or both?
- What types of networks do you expect this to work over?
- What type of voice or video quality do you expect over ICA? Does the expectation change depending on whether the solution is deployed on a LAN, WAN or over the internet?
- Are you strictly interested in publishing the Softphone or would you be open to having the Softphone deployed alongside the ICA client? Would you be open to having Citrix build a Softphone into the ICA client?
- Would you be open to a solution that required a separate network protocol (outside ICA) to deliver either voice or video services to the end-user device?
- Would you be OK with a solution that required a headset at the user end (as opposed to speakers and microphone)?
Feel free to post replies to the questions that apply to your scenarios or add any comments to help us better understand your needs. With this information we will be better equipped to build a solution that meets your needs.