Video Based Screen Sharing in Skype for Business
Video Based Screen Sharing (VBSS) is a new Skype for Business client capability that has for the most part flown in under the radar. There is currently very little information available about this new functionality, and as with anything not well understood it seems to be creating more confusion than warranted. Most of the questions have been centered around the topic of video interoperability, thanks in part to some generalized statements.
This article will explain what this new functionality is, as well as what it is not. With a more complete understanding of VBSS and its potential roadmap then the answers to various interoperability questions should be quite clear.
The Office 365 Roadmap currently lists this feature under the In Development section, but it is now available with the release of the Skype for Business 2016 client that is included in Office 2016.
A newer article entitled Skype for Business VBSS Update has been posted which highlights even newer functionality in Skype for Business. While the concepts covered in this article are still applicable some of the limitations documented below are no longer valid. Make sure to also read the new article to understand the latest functionality provided by VBSS.
Up until now there have been only a few places that this new feature has been discussed in the public realm, and most of that was before there was even a name for it. Generically speaking it was communicated as some level of native support for “H.264 content sharing” coming to the Skype for Business platform. Obviously companies looking to address interoperability scenarios with SfB and their standards-based video conferencing systems would sit up and take notice to these claims.
Unfortunately the problem with that simple statement is it can be interpreted differently depending on whom is reading it. For those with a foundational understanding in the traditional video conferencing world that statement can sound odd. The H.264 standard is simply a video codec which could include anything in the actual image. The transmitted pixels could be arranged to display a smiling face captured by a camera, or instead show the familiar view of a user’s PowerPoint application captured by a video output device of some sort. While a standard H.323 or SIP call can support sending a second stream of video displaying this content the actual standard that makes this possible are not H264 itself.
A call established using the call control platform will actually use the H.239 standard for establishing content sharing, where as a call that instead leverages a standard video SIP platform will use Binary Floor Control Protocol (BFCP) for establishing content. In the Microsoft world content sharing has leveraged Remote Desktop Protocol (RDP) since this ability was first provided in Office Communications Server 2005.
The most significant difference between these two workflows are the lines of communications that are established, and how they are established, even though the resulting experiences are very similar. For example:
- On one side a Skype for Business call will use Microsoft’s SIP platform to setup and negotiate a call or conference, leverage X-H264UC as the codec for the video streams, maybe opt for SILK as the audio codec, and then utilize RDP to share the desktop from one participant. Each of each lines of communications are separately established connections between the same endpoints, with their own streams and bandwidth utilization.
- In comparison the same scenario in the video conferencing world might utilize H.323 to establish the call signaling, H.264 AVC as the video codec, G.722 as the audio codec, and then leverage H.239 to send the desktop screen of a computer in a conference room connected to a VGA cable.
The delivery mechanisms for sharing content in these two worlds are very different though. While the traditional video conferencing systems use H.239 or BFCP to control the transport of the content, the actual content itself is encoded using a video codec and is sent within the same allowed bandwidth defined for the specific call. The content essentially steals bandwidth away from the main video when needed. Normally the content is encoded as an H.264 AVC video stream, but could in some cases fall back to a legacy H.263 stream.
Yet on the Lync/SfB side an additional session is created for content outside of any established video or audio sessions (if they even exist) and will transmit RDP as media over TCP, consuming additional bandwidth on top of whatever the audio and video sessions are already using. A content sharing session can be established all by itself in the Lync/SfB world, but with traditional video conferencing a video call must first be placed and then content can be added to that existing call.
These inherent differences in content encoding and transport are why traditional video content sharing has always been able to provide smoother motion, include audio in the stream, and use less overall bandwidth. Comparatively content sharing in Lync/SfB has been of much sharper quality and resolution but severely limited in frame rate and typically more costly on the network.
In an initial step to improve the content streaming quality of RDP the July 2013 cumulative update for Lync Server 2013 introduced a new parameter (EnableHighPerformanceP2PAppSharing) for peer to peer application sharing. This optional setting still utilized RDP for the data stream but boosted the frame rate a bit (as well as the bandwidth usage). A side-by-side comparison of the default and high performance RDP options can be seen in this blog article by Skype for Business MVP Michael LaMontagne. While the frame rate was slightly improved it was still very short of the frame rate needed to display video or other moving animations sufficiently.
Seeing that RDP has been stretched to its limits in terms of providing quality streaming another approach was taken with the Skype for Business client. The addition of Video Based Screen Sharing helps address some of these limitations while at the same time not negatively impacting the overall image quality that RDP has provided to date.
The primary change here is that Skype For Business clients can now utilize something other than RDP to share content between clients. Understand that currently this capability is only provided in the Office 2016 version of the Skype for Business 2016 client, starting with the public release of the 16.x client version (e.g. 16.0.4266.1003). The rebranded Lync 2013/Skype for Business 2015 15.x client installations do not include this capability and will continue to share content using RDP.
VBSS is also only available in peer-to-peer SfB sharing sessions and is only utilized on the Present Desktop sharing option. Selecting any of the other sharing options like Present Program or Present PowerPoint Files will still behave the same as in previous clients. The PowerPoint File sharing option leverages the Office Web Apps Server which does not actually stream the content and thus VBSS is not applicable here. The Present Program option does not currently take advantage of VBSS so RDP at a low frame rate is still used.
The Application Sharing service on the SfB Front End Server does not support this feature so content shared into Skype for Business meetings will also continue to use RDP regardless of the individual client versions.
Additionally in the single use-case where VBSS can be used the content sharing is provided as view-only. If remote control is requested by or given to the receiver then the content stream will seamlessly fall back to using RDP. This switch is invisible to the user except that the frame rate of the content will immediately drop as VBSS is replaced with RDP for delivery of the content. Releasing control will not upscale the content back to using VBSS, it will remain as RDP for the duration of the sharing session. Stopping and restarting the sharing session will allow VBSS to be used again.
Just as the addition of X-H264UC as the primary video codec in Lync 2013 did not magically remove all video interoperability hurdles with Lync, using this same codec for content streaming is no different. As stated previously this is not standards-based H.264 content sharing, just like video in Lync/SfB is not the same as H.264 AVC payloads.
In the field most video interoperability solutions available today are focused on conferences, not individual peer to peer calls. Simply stated, VBSS is no different than the addition of SILK to some of the Lync and SfB clients. These clients can choose to utilize the newer codec when negotiating peer calls between each other, but when involved in larger multiparty conferences are still limited to the codecs supported by the server.
That is not to say is there are no inherent benefits here. Clearly any improvements built on top of this workflow could be leveraged by additional development by third parties. For example video conferencing systems which already include native support for RDP content sharing could in theory be updated to support VBSS to further improve quality.
The following video clips were recorded with a camera showing the actual display of a Windows workstation receiving the same shared content in two separate tests.
- In the first video the typical RDP experience is shown which is clearly evident by the very low frame rate.
- The second video shows the same YouTube video being streamed from the same SfB user but this time VBSS is used and the frame rate improvement is obvious.
These embedded videos may be muted by default but if the playback audio is heard understand that the camera used to capture these clips has picked up the sound from the source (sharing) PC’s speakers located in the same room. The content sharing in SfB is still limited to video only and does not deliver any audio from the sharing client to the receiving client. To perform the same side-by-side tests simply switch between using Present Desktop (which uses VBSS) and Present Program (which uses RDP).
Using some basic math and monitoring tools the following behavior was observed when sharing a full motion video at full screen for an elapsed time of 4 minutes.
- The RDP session averaged 2.83 Mbps with 85MB of data transmitted
- The VBSS session averaged 3.5 Mbps with 105MB of data transmitted
Based on these numbers VBSS consumed roughly 25% more bandwidth than when RDP was used, yet increased the frame rate by much more than that percentage. The RDP session displayed about 3 frames per second at best while VBSS could provide 7.5, 15, or 30fps streams based on X-H264UC specifications. Note that only a single Temporal Layer is transmitted as this is a P2P session and multiple frame rates would not be applicable.
Under the Hood
When selecting the Present Desktopoption in the Skype for Business 2016 client a SIP invitation message will be sent to the other party including the following Session Description Protocol (SDP) messaging.
- The initial SDP data will look no different than what was seen in the past. This is because the first portion of the SDP messaging always includes the legacy ICE v6 declaration for communicating with Office Communicator 2007 and older clients, as denoted by the string, Clearly these old clients cannot support VBSS so there is no need to advertise any new capabilities here. Only a single media session () is declared here and the media type advertised is RDP ().
<candidate and crypto data snipped>
- The next grouping of SDP data is what will be used if the receiving client is running at least Office Communicator 2007 R2 or newer. Note that the Content-Disposition parameter no longer includes the fallback string; this section leverages ICE v19. The differences highlighted below outline how this new capability is advertised.
<candidate and crypto data snipped>
<candidate and crypto data snipped>
First, a new session level attribute a=x-mediabw is included under the section. This is what the SfB 2016 clients can use to identify and use VBSS for the sharing session between them. If both parties do not support this new capability then it will not be used and RDP will be leveraged instead just as it has been.
Secondly, an additional media session is advertised to negotiate a video stream under the familiar string, including two new attributes: a=label:applicationsharing-video and a=x-mediasettings. Note that the media payload type here is the same X-H264UC () that has been used for video since the release of Lync 2013. For added measure the out-of-band Forward Error Correction () codec used with SVC video is also included.
While not visible above because the candidate details were clipped for easier reading the RDP session only advertises TCP candidates while the VBSS session will advertise a full set of UDP (preferred) and TCP (fallback) candidates. The fact that content sharing with VBSS can now utilize the stateless UDP communication protocol is already an advantage in improving streaming. Also not represented is the communication between clients within the RTCP channel for Video Source Requests (VSR) in which the two clients negotiate resolution, frame rate, and other parameters of the video channel in-session.
As both the RDP and VBSS capabilities are advertised in the messages above then the clients will negotiate both sessions even though the content will actually flow through the VBSS session. In the event that RDP needs to be used (e.g. for remote control) then the clients can quickly switch to using RDP as a legacy fallback option.
Because all of this new functionality is embedded directly into the clients then the underlying infrastructure does not seem to be relevant to its functionality. As long as both parties have the Skype for Business 2016 client then it will be leveraged even if one or both of them are homed on a Lync Server, or even on different servers via federation. In fact the example SIP data shown above was captured from a peer call between a 2016 client registered to Skype for Business Online and a federated contact registered to a separate Lync 2013 on-premises environment.
Since posting this article Microsoft has added a a registry key to control the the VBSS behavior in the 16.x clients. Using either of these two registry settings can be used to to disable this default behavior by setting the value to zero. The first parameter is used with the 64-bit Skype for Business application running on a 64-bit Windows operating system. The second parameter is used if the 32-bit application is installed on a 64-bit OS.
Filed under Skype for Business, Video · Tagged with Media
About Jeff SchertzSite Administrator