VOIP (IPT) and VDI

[sgrinker]

Does anyone have experience with implementing VOIP (particularly Cisco) into the VDI world? By that I mean, the end goal would be to have one of our IP phones plugged in to the Thin Client and the Thin Client connected back to a VM workstation through RDP. Then allowing a user to be able to dial from their contacts in Outlook directly to the phone as they would with a normal workstation. We've been able to dial from contacts in early pilot, but just interested in additional feedback.

We are also planning to test Soft Phones running on the VM workstation. This would of course either require a headset or some other phone-like device plugged in to the Thin Client. Being a Citrix Admin, I'm overly familiar with the fun of audio synchronization over a remote connection, but this should work in theory anyway.

To make this even more interesting, we have just recently started to deploy cameras for the phones. It is basically a simple USB WebCam which uses drivers/software from Cisco to connect up users on a video conference through the phone. I know this would be tricky with the technology as it sits today, but I'm curious if anyone has looked into this at all. Not a full on requirement for us, but it may make or break VDI usage in some situations here.

Lastly and just to round this out, I've recently engaged a contact at NEC in regard to their "Virtual PC Center" offering (http://www.necam.com/ThinClient/). The main reason for the contacting them was that they show VOIP all throughout their marketing. I have yet to actually get a complete undersatnding/explanation of exactly what it is they are providing, and was curious if anyone has any experience with this? I'm aware the main device is OEM from Wyse, but we were curious what NEC is providing as an overall solution. More importantly how it helps with VOIP in particular.

I realize this is a rather lengthy "question", so let me know if anyone needs clarification to be able to address anythhing. Any feedback or input is very much appreciated though.

Thanks

Steve

[daniel_uk]

Hi Steve,

This is something that has been looked at in my organisation.

Technically the sound protocol is available so i see this not being an issue. Would the VOIP work by using a PC to RDP and then use VOIP? This would be a good test regardless oif the platform connecting to the backend image.

PoE is something im interested in seeing working with WYSE boxes.

[sgrinker]

Daniel

You definitely make a good point, an RDP connection should be the same the world around (granted rdesktop may be a little different depending on the flavor). I also think that the audio portion should work, but haven't had a real chance to do any good testing just yet. I'm hoping the theory pans out to be true.

The video may be the tougher configuration, at least for the moment anyway. I know work is being done in the USB/Thin Client world at the moment, so it just may have to be something that waits a little bit. We're JUST getting to the point of testing a wider pilot within our firm.

Anyone using softphones through Thin Clients at all though? Just curious to hear what performance is like, and if there have been any major issues before we dive into this one.

Thanks again

Steve

[TomHowarth]

I think the main issue is that with RDP audio is one way only not two-way as with ICA.

[sgrinker]

Thanks, Tom. I hadn't even thought of that... Sounds like the softphone idea may take a bit of work, or at least be a little ways off. Whenever Port ICA/Trinity/CDB 2.0 comes out, it would probably help out a lot more than I was thinking initially. At least in this regard anyway.

[Elie-prof]

This is what Provision Networks is also aiming to deliver with their upcoming RDP enhancements. As I understand it, part of the multimedia support for RDP, they'll deliver two-way audio.

[admin · Accepted solution]

You are going to have a few challenges here.

1. Your click to dial is going to work with no issues. Any other call handling or unified messaging via Outlook integration or via your softphone app will also work fine.

2. One thing to make note of is SOME thin clients have issues when run off the second Ethernet port of the phone. In general it should not be an issue but from time to time you can come across issues.

3. Soft phone - hard phone replacement. If the softphone uses the RDP audio driver and does not handle upstream audio in a virtual channel or something out of band, this will not work. As Tom mentioned, RDP does not support upstream audio.

4. Web Cams - Out of the box RDP does not support webcams you are going to need a software solution like remote scan

The good news is advancements over the two years have occurred around all this that will move the market forward. There are two approaches to delivering video and audio, server side decoding and client side decoding. Most of the bolt on software / RDP enhancement solutions are going to be server side decoding. Personally, I feel the longterm verdict regarding the scalability of this approach is still out.

Then there is the NEC approach with the Virtual PC Solution, where they implemented the WYSE based SOC Netclient in their newest thin client. IMO this is the best approach. Look for more SOC / FPGA based thin clients to come too market over the next 12 - 24 months. The benefit of this approach is offloading the video and audio to the client device so local CODECS and the SOC handle the decode of the video and voice rather than the server. Most will simply build virtual channels on top of RDP. NEC's solution is tight. They support webcams, VoIP and Multi-Media they are leading the market with this approach. Their solution is an end to end solution bundled with their thin client, servers, soft switch broker etc.

[mreferre]

>The benefit of this approach is offloading the video and audio to the

>client device so local CODECS and the SOC handle the decode of the

>video and voice rather than the server

This would make lots of sense as long as the client device does not have any logic on board. I don't have a good handle on how this would work at the moment but my point is that ... if what you want/need to do is bound to firmware/software running on the thin clients that needs to be updated every 2 months to support the latest video standards bla bla than I would speculate this is NOT the right approach.

On the other hand IF the device at the end is a very passive device with very little logic that doesn't need to be touched frequently than I agree.

Having this said it must also be noticed that hw (servers) is becoming so cheap and so powerful (with the additional cores) that even if you pose a bit more workload on it it's not going to hurt it too much .... especially if this allows you to have even more stupid devices distributed.

I think in the long term it is not the capacity of the servers the costraint ..... but rather the management burden of the distributed environment.

Massimo.

[admin]

I agree from the aspect that, less on the client is better, always have. Also a "Forced " client upgrade every 2/3 years is not good.

Updating it in firmware is not entirely bad depending on how its implemented. If implemented correctly, the management can be seamless similar to Sun's Sun Ray model. Last time I checked their firmware it was at 300KB. It takes about 10 seconds to load it and is fully automated. Something like an embedded OS or thin OS where you have to repackage it and push it out would not be a step forward.

There is a curve here where next generation SOC/FPGA based thin clients could come out at extremely low costs doing some client side decode of the most challenging functions. Low enough that tossing even 1000's of units could mean little too nothing from a cost standpoint even if they were tossed in two years.

At the same time there is the curve, as you said of Multi-Core systems. Also, new technology advancements could occur like offload on the server side. That could further reduce client side decoding dependency's.

[mreferre]

I agree. If it's something like the Wyse S10 firmware (and associated upgrade procedures) than I can live with that.

But I would be very very cautious about statements like "fully automated" and "seamless" because a standard system management software vendor can always tell you that a Windows XP fix can be installed in a fully automated and seamless manner ..... Just kidding .... but you know what I mean ....

My theory is that if you want to do these sort of things for a better management you'd better be aggressive ..... very aggressive. As I said I like the S10 for that for example.

Massimo.

[sgrinker]

Well first off, thanks to Warren and Massimo for the great responses. This portion of the project is definitely going to be a "work in progress" for some time here I think. We may be able to get portions of everything working, but I can't expect that everything will work the exact same for the user on a normal workstation machine. Since IPT/VOIP (escpecially the enhanced features softphones and video) are starting to get rolled out and tested, it will be very hard to sell VDI without having the same capabilities. We don't really know how high the demand will be, nor do we know if it will even be necessary in the first locations where we plan to roll out the Thin Clients. We definitely want to have our homework done though, and my boss has made mention of these ideas on a few occasions.

I have to believe that all of the larger players are working on things that will help to enhance this arena. Especially since the "VDI" concept is still relatively young. Most of the technologies have been around for awhile, but the new ways we are using them has created some new requirements. Once more vendors see the potential and start to collaborate, this area should get better along with a lot of the rest of VDI.

For now though for the cameras, I do want to get a trial of something like remote scan in place to see if that helps at all. Of course it's all a matter of getting things to talk properly. Technically the phone is made aware of the camera though Cisco VT Advantage. When a call is made, VT Advantage determines if both ends of the call have a camera. Once the connection is made, the video appears on the users screen. ...should make for a good challenge anyway.

Thank again for all the information and helping me think this through. Definitely keep any more thoughts, suggestions, questions, etc coming!

Steve

[admin]

Just remember, its not a VDI issue per-say its a issue with network delivered desktops and the current state of Display Protocols and Device Redirection. I would argue a little that the efforts going into VDI are helping push the market forward.

I like your comment regarding not knowing the demand! I collect a ton of customer requirements. For years I have heard customers say they have to support handsets to the PC - Replacing hard phones and Video/ Multimedia etc. I always ask what media formats and usually get, we need them all. Then I ask what they use today and for what and I usually get, none.

With handset replacement, I always ask if any feasibility study's have been done. Usually only call centers do this. Its clear that it would be nice to drop the cost of the handset all together. People have been saying that for 10 years. The hard part is adjusting human nature to use it. Phones are like walking, we learn from a early age how to do it. IMO it will take generations to introduce a new way of doing it and it will have to start outside the workplace as that is where we start to learn This is not to say that a certain percentage of users will not use it.

The video is also interesting. There are a lot of cartoons and jokes there Do users REALLY want people to know they are checking email and surfing the web during a conference call and not paying attention? I am truly virtual, as I work from home when I am not traveling. Do you wanna see me in my PJ's on the days I start checking email at 6:30am and never get around to changing?

I am not a big believer in some of these however, I a glad the server based computing market is moving forward with solving some of the challenges as it is a check box and we need to deliver feature comparity.

Keep us in the loop with what you find... I know I am very interested as I watch this closely. Ping me off line with your lessons learned if you wish.

[sgrinker]

Warren

Thanks again, and I'll definitely try to keep any useful information posted as we progress through these projects. I did just have two additional comments to your last post though.

Just remember, its not a VDI issue per-say its a

issue with network delivered desktops and the current

state of Display Protocols and Device Redirection. I

would argue a little that the efforts going into VDI

are helping push the market forward.

I'd actually change this a little bit. "It's not a \[VMWare] issue per-say" However, as the concept of VDI does rely on some remote protocol to function, I'd have to say it indirectly does get a finger pointed at it. Realistically though, I know what you are getting at. The concept of VDI is not really the problem, it's just that some of the "bells and whistles" are not yet available. It's obvious that Citrix is already working on a lot of these issues, and the independant community as well with rdesktop. It should just be a matter of time until better support will be available. Otherwise this whole new idea of sending video/audio outside the protocol definitely seems to be a great improvement. Although I'm still very curious to know how much bandwidth gets eaten up by that.

The video is also interesting. There are a lot of

cartoons and jokes there Do users REALLY want

people to know they are checking email and surfing

the web during a conference call and not paying

attention? I am truly virtual, as I work from home

when I am not traveling. Do you wanna see me in my

PJ's on the days I start checking email at 6:30am

and never get around to changing?

I have to be completely honest, that was my initial reaction as well when this was announced. Of course this push is coming from the top down, so we all have to do what we can to support the vision. I do see their point that it should make conversations more meaningful and useful, because it causes both parties to better engage in the conversation (i.e. not multi-tasking while pretending to listen.) As you said earlier though, we've all learned how to use the phone from a very young age... this is just one more habit that has come from that. We're not used to being seen while talking on the phone anywhere, but it's just one more thing that with time we'll all be used to.

Thanks again

Steve

[mreferre]

>Do you wanna see me in my PJ's on the days I start checking email at

>6:30am and never get around to changing?

Yes please why not ..... that would be funny.

Massimo.

[admin]

Nice... Ok, well when we get webcams working I will send out a URL for me in my PJ's working from my virtual desktop.

BUT! I am keeping my PJ's on no dirty stuff

[sgrinker]

Looks like this thread is taking a turn for the worse.

[sgrinker]

On a real quick note, going back to Remote Scan... does anyone have experience with it? I'm more curious about the camera portion, but eventually may have a use for the scanner component as well.

[TomHowarth]

oh you southern europeans with your fancy ways, you're so cosmopolitan.

[TomHowarth]

It had to happen once thoe points got used.!!!!! LOL

[TomHowarth]

I have used the scanner portion to great effect in numorous TS deployments, it is an excelant product. if the Camera portion is half as good as the remote scanner then it is top drawer.