Citrix: Optimized ‘Skype for Business’ Delivery

There’s been a big wave of popularity within the usage of Skype for Business (formerly Lync). Recent stats indicate that there are millions of Lync users migrating to Skype, others looking to implement it, and 79% of US businesses are looking to make it their infrastructure for PBX going forward. With this comes the need to assure it’s fully optimized, especially when running in a Citrix virtualized app and/or VDI environment. I can’t tell you how often I’ve seen optimizations missing with Skype on Citrix, mostly due to the knowledge not having been widespread and known.
This was one challenge, but there were others with delivering Skype in a virtualized environment:

• Server scalability – video processing is CPU intensive
• Quality – transcoding, decoding, & recoding on the server lead to loss of quality and repacketization which in turn hindered the quality of voice & video
• Latency – users may be far from the datacenter where the client is running
• User Roaming – users are free to reconnect from different devices

Previously, Microsoft promoted a v1 solution called the “VDI Plug-in“, to help with some of these challenges, but it was limited to Windows Desktop OS endpoints, and didn’t support XenApp to mention a few.
For Server side XenApp, Citrix promoted its v1 solution called “HDX RealTime Optimization Pack 1.x”, which included a RealTime Media Engine install for the endpoints, and a Connector install for the VDAs, but this wasn’t widely spread, which is why Citrix and Microsoft jointly worked together on further optimizing Skype for Business.
This joint approach resulted in development of the v2 architecture:

• Skype for Business 2015 client PU from Microsoft
• HDX RealTime Optimization Pack 2.0 release from Citrix

Why does v2 make sense?

• Native Skype for Business UI – the UI is owned by Microsoft (no hooks)
• Additional features, including:
  • Call Delegation & Response Groups
  • Voice Mail integration
  • Automatic Join Meeting audio
  • Emoticons
  • Web Proxy support
  • Support for Click-to-Run
  • Status icons (Connecting, Connected, etc.)
  • Active speaker identification
• Citrix Windows Receiver 4.4.100 is now bundled with the RealTime Media Engine 2.0.100
  • Single download, single install
  • Ideal for BYOD and at home workers on unmanaged devices
• Virtualization has security benefits
  • With Skype for Business on XA/XD, client data such as chat logs, contact lists, transferred files, etc. remain in the data center

Coming within June-July 2016 timeframe:

• HDX RealTime Optimization Pack 2.1 (what’s new?)
  • Endpoint identification for Location services – this is important for features like enhance 911, which helps Skype’s location services truly identify a 911 caller. How? Because in this model, the Skype for Business client is running in the datacenter, data from the Receiver (MAC, IP, next top router, etc.) is passed to Skype for Business so that it can do a lookup in the location database, to ensure the 911 is handled at the right location.
  • Performance optimizations
  • Improved video quality on conference calls (H.264 SVC) – the Scalable Video Codec is set to provide less CPU consumption
    • In 2.0 H.264 was used for point to point calls between 2 parties, but on conference calls Microsoft proprietary RTVideo codec was used
    • In 2.1 H.264 SVC can now be used for conference calls, which is more adaptive to the network
  • Improved audio quality on two-party calls (Silk codec)
    • Silk was designed for the public internet and is tolerant to packet loss and latency
  • “Skype for Business 2016 ready” – so you don’t have to wait for a 2.2 release
  • Quality of Experience reporting
    • In 2.0 you have the ability to right click on systray icon, & see packet loss
    • In 2.1 these stats can now be passed to Skype For Business & placed in a SQL DB that can generate reports that could be useful for troubleshooting
  • Federation with consumer Skype
  • Control of systray notification balloons
  • 64-bit Linux RealTime Media Engine

 
Understanding the v2 Architecture
In this architecture, XenApp or XenDesktop and the Skype for Business client are running in the datacenter. HDX Connector is installed there as well, interfacing to the APIs and translating them into commands that go over the ICA Virtual Channels down to the media engine. So in essense, the user interface is at the top, business logic in the middle, and the media engine with codecs in the bottom where offload is achieved. The only info going thru the Virtual Channels are command & control, things like: make a call, hang up a call, etc. The audio-video media is going out of band over secure RTP (Real-time Transport) and UDP (User Datagram) protocols.
 
Other cool aspects
The RealTime Media Engine doesn’t need to handle any authentication to the backend Skype for Business infrastructure, it’s all done by the Skype for Business client in the virtual OS (a single point of authentication).
SIP signaling (Session Initiation Protocol), which is the protocol Skype for Business uses for call setup, authentication, in-band provisioning, instant messaging, presense updates, and etc. is now handled exclusively by the Skype for Business client and not the VDA.
 
A Closer Look:
 
In v1, when an ICA connection is established, the RealTime Media Engine on the user device initializes and registers with the Microsoft Lync Session Initiation Protocol
(SIP) server. When using SIP to place a call, only signaling info is sent over the ICA protocol. When the call is established, audio-video traffic flows directly point to point or out of band of the ICA connection.
 
 

 
 
In v2, when an ICA connection is established, the Skype for Business client on the XenApp or XenDesktop now makes the SIP connection back to the Skype for Business Server (whether on premise or on O365). When the call is established, the audio-video traffic is point to point or out of band of the ICA connection.
 
 
                                               
                                                                                                                                                 In the picture above both users are on ICA, but this doesn’t have to be the case.
 
Ethernet throughput on the VDA:                                                                                                                           Ethernet throughput on the Endpoint:


 
 
 
 
 
 
 
 
 
 
 

The bandwidth is coming in via the Endpoint – therefore no hairpinning!

Hairpinning?
In telecommunication, hairpinning returns a message from an original point back in the direction it came from. If you are accessing a XenApp or XenDesktop with Skype or Lync in it and you don’t have the optimization pack, you are hairpinning AND most likely experiencing processor utilization and network penalties in the host. Therefore, avoid hairpinning and use the optimized method.
Here the user interface lives inside the virtual host, and is seen completely in the virtual desktop or app display. However, the media rendering, or engine is separated off to run on the endpoint. This allows for a very rich rendering of the audio and video experience.
In an event you can’t run in optimized mode you can, there is fallback mode.
 
Other Performance Considerations

• Failure to properly configure security Antivirus software can result in painfully slow performance of Skype for Business client
  • Best to setup AV software to avoid the logging directories
  • See CTX127030 and CTX124185 for Citrix guidelines
• Failure to configure the firewall for media traffic (STUN and SRTP ports) can completely prevent optimized operation
  • STUN: UDP 3478 and TCP 443
  • SRTP: UDP & TCP, port range 50,000-59,999
  • Alternatively, HTTP proxies support firewall traversal (RTOP 2.1 required)
• Failure to configure other ports used by Skype for Business back to edge service servers will probably result in being able to establish Skype chats, but rich media may fail or it will start to make call and not finish
  • For best possible quality enable UDP to server port 3478
  • If not possible, the RTME automatically falls back to TCP connectivity port 443
  • As alternative you can tunnel media connections to the server through an HTTP proxy, but UDP is the preferred transport for best video quality, etc.

Getting Started
To get started and to obtain further info, please be sure to check out the deployment guide here.
About Anexinet
Anexinet is a leading professional consulting and services company, providing a broad range of services and solutions around digital disruption, analytics (and big data), and hybrid and private cloud strategies. Anexinet brings insight into how technology will impact how business decisions will be made and how our clients interact with their customers in the future.
Josue Molina, [email protected]