Post to Twitter |
Comments (8) |
Views (19513) |
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.
Comments (8)
Nov 30, 2006
Anonymous says:
Firstly it's brilliant you guys are thinking about this sort of stuff! Jus...Firstly it's brilliant you guys are thinking about this sort of stuff!
Just something else to note in the advantages of option 1 - Integration with other applications within the same sessions is then possible which is maybe not used much, but heavily marketed by VoIP vendors. Ie. CRM application integration / Outlook contacts sync, etc Also if the Softphone's functionality then expands to video conferencing the existing multimedia acceleration function could possibly be modified to work bi-directionally for sending and receiving encoded video streams. Lastly, the other big thing with softphones, instant messaging apps and so forth is the presence awareness. Citrix could collaborate with important vendors like Cisco, IBM, etc to pass session state through as presence awareness info or even look at location awareness information such as the one in Lotus Sametime.
Dec 05, 2006
Anonymous says:
Here's what I would like to see. We have to split the softphone in two compone...Here's what I would like to see. We have to split the softphone in two components. One part is installed on the endpoint, alongside the ICA client, whereas the other part runs in the user session on the Presentation Server. The two communicate through an ICA virtual channel, using a new kind of "SIP" or "VoIP" mapping, not unlike what we do for local printers, COM ports, audio, and disks today. The main purpose of this channel is to transmit control information (not audio) between the client and server based components of the softphone. The server based part takes care about the user interface, integration with other apps running on the PS (Outlook, CRM, etc) and generally is aware of anything that concerns the current user, i.e. their extension #, voice mail settings, etc. The client based part takes care about codecs, controlling audio devices, locating SIP registrars etc. It is aware of anything that concerns the local environment of the client, which it will report back to the server based part. It will also forward local events, like an off-hook, or an incoming call. And it will take commands from the server to initiate a call, play a voice mail on the attached audio device (which, BTW, could be transmitted through the virtual channel no problem as it is not real-time and can be buffered) This needs some heavy thinking to go into the design to make it truly scalable and enterprise ready. It might not even be something that Citrix should attempt, but rather one of the makers of softphones and soft-PBXs out there. Just my 2 cents.
Oct 24
Anonymous says:
Hi Guys! How are you all ? I am sara from Memphis. I must say that this is a...Hi Guys! How are you all ? I am sara from Memphis. I must
say that this is a good forum for VOIP discussion .
During my search for for VOIP and call termination forums i found lots of forums like www.voiptm.com/vforum/ which is a good forum for finding Buyers/Sellers forour desired destination.
I think i have shared the beneficial information
for all of you if it is true
then please write few lines in reply.Thanks
Dec 07, 2006
Anonymous says:
I've been to a seminar today on the roadmap for Avaya IP office and one thing th...I've been to a seminar today on the roadmap for Avaya IP office and one thing that was obvious was that a) Avaya roadmap isn't revolutionary, b) it?s IP centric and c) the future of the dedicated hard phone is limited and if I was in that hardware market, I'd been getting very worried about the future. The issue of VOIP is just one "problem" with the Citrix/terminal server architecture. Don't get me wrong - I love PS but every year it becomes harder and harder to defend. The problem is going to be locally connected devices of which VOIP is just one instance. In fact, it's *already* a problem as the single biggest issue we have with PS is the inability of users to plug the ubiquitous USB pen drive into their WYSE thin client terminal. VMware manages to offer a virtual USB controller and then virtualises any USB device plugged in. Is there any mileage in considering something similar for the Citrix ICA client? At the end of the day, USB is a high speed serial device albeit that?s a simplistic view. Plug a USB device in, Citrix ICA client grabs it, virtualises it (hmm) and passes the series data up/down the ICA channel. I realise that I?m assuming that?s the bandwidth of the connection makes this feasible but in an internal LAN environment, it should be. The device driver would then be installed as normal on the Citrix server(s). Okay, you?d have to restrict adhoc installation of drivers but for the three devices that I?m most commonly asked about, Windows already has native drivers: pen drives (mass storage), cameras (usually mass storage) and USB handsets/headsets. I realise that I?m blue-skying here but that?s my two pence as well. Cheers, Rob.
Dec 07, 2006
Anonymous says:
Hey Orestes, It's a tricky path you have there and we as an organisation are s...Hey Orestes, It's a tricky path you have there and we as an organisation are struggling to find the best way to deliver VoIP and Video to people who seem to perpetually have meetings due to their type of work. I work for a worldwide environmental charity and we're faced with the problem of users on low cost lines wanting the cheapest and most converged solution for their needs. Question1 I know my users would want both Video and Voice to be converged into the solution but I think with current technologies and line speeds that we would prefer a good or at least acceptable voice connection rather than a medium to shoddy voice and video experience. Video can wait. Question2 Our delivery is mostly to users on contended ADSL and SDSL lines delivered from a main Fat Pipe Office where the PS servers live. Question3 We'd expect a 'usable' solution accross the data lines I've already mentioned one which could make then happy to use the converged voice and application solution. Question4 It would be 'nice' to have the softphone as a published app but if it makes the experience better I'd prefer whatever gives the quality a good chance even if it means publishing the softphone for our users to download seperately should they not be on a machine with the software already deployed. Question5 Again... as long as the permiter firewall boxes could deal with whatever external to ICA protocol is used and it could be proxied via a CSG/WI/CAG type host to prevent direct exposure/connection to the internal server/VoIP kit then I'd be happy with that solution also. Integration with proprietary protocols on the Mitel or Avaya VoIP systems would be a HUGE benefit. Question6 Headsets are something we'd be happy with also, I think they provide a richer and more ledgible experience than trying to shout at the machine whilst in a non-silent environment. I hope these answers are of some use and I'll be keeping my beady eye on this forum as this is one of the hottest topics of my working life right now. Regards Paul.
Mar 03, 2007
Anonymous says:
You have clearly outlined the problems in using ICA as a the underlying protocol...You have clearly outlined the problems in using ICA as a the underlying protocol – the fact that it is TCP based and that soft phone developers never usually envision their phones to work in a TS/ICA environment. Also the ?Click to Call? feature (provided by Application Gateway) now embedded into CPS applications seems to provide some of the functionality that you describe. However, what seems to me like a feasible value add to our ICA client, is not real time communication but the ability to retrieve (and possibly send) voice messages in the corporate environment. Users logging on to their ICA client to launch published applications remotely, will also be able to check their voice mail (securely) from their desktops. Since this content can be sent as data and then buffered for local playback, there aren?t the issues in RTC that you mention. What do you guys out there think?
Apr 01, 2008
Anonymous says:
I recognise I am responding to this rather late but I would be interested to kno...I recognise I am responding to this rather late but I would be interested to know what the situation is now and if Citrix have enabled/developed a way for clients to access video within/outside the terminal session, without the need for users to cut and paste URLs into a browser bar?
Apr 08, 2008
Cris Lau says:
Hi, The short answer to your question is: Yes. Over the past couple of yea...Hi,
The short answer to your question is: Yes. Over the past couple of years, Citrix has introduced a number of features in the XenApp (new name for Presentation Server) to enhance the delivery and user experience of access multimedia content. Many XenApp customers leverage our SpeedScreen technologies to deliver multimedia (e.g., training videos), Flash (corporate communications/youtube), images (google mpas/graphics) to users efficiently. Additionally, with features like the "server to client content redirection", XenApp will recognize the URL (e.g., a link to a windows media file), intercept it and send it to the client to play on the client's local browser. As you can see, this feature effectively eliminates the need for XenApp to allocate resources to process/render the windows media file. So, the capability you are asking for is already in XenApp today. You can learn more about XenApp and its features here.
Additionally, we have actually made a bit of progress in the areas of multimedia, VoIP and Unified Communications/OCS. You can click on the links to read other blogs on them. If you have additional questions, please feel free to contact me by clicking on my name. I am interested in hearing more about your organizations needs for and share with you how XenApp can help.
Best Regards,
Cris
Anonymous replies:
Add Comment