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.
![image_thumb[8]](http://blog.schertz.name/wp-content/uploads/2015/10/image_thumb81.png "image_thumb[8]")
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.
Background
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 H.323 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.
VBSS
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.
Interoperability
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.
Comparison
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 Desktop option 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 ms-proxy-2007fallback string, Clearly these old clients cannot support VBSS so there is no need to advertise any new capabilities here. Only a single media session (m=application) is declared here and the media type advertised is RDP (a=rtpmap:127).
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <2c1ace88f86f32a5cccffd4177e8a2a1@jdskype.net>
Content-Disposition: session; handling=optional; ms-proxy-2007fallbackv=0
o=- 0 0 IN IP4 123.45.67.89
s=session
c=IN IP4 123.45.67.89
b=CT:53980
t=0 0
m=applicationsharing 58323 TCP/RTP/AVP 127
a=ice-ufrag:lbTM
a=ice-pwd:RFjNRfTU4UkaOAKa0Xivn64+<candidate and crypto data snipped>
a=setup:active
a=connection:new
a=rtcp:58323
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp
a=x-applicationsharing-contentflow:sendonly
- 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.
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <2c1ace88f86f32a5cccffd4177e8a2a1@jdskype.net>
Content-Disposition: session; handling=optionalv=0
o=- 0 1 IN IP4 123.45.67.89
s=session
c=IN IP4 123.45.67.89
b=CT:53980
t=0 0
a=x-mediabw:applicationsharing-video send=10000;recv=10000
m=applicationsharing 58323 TCP/RTP/AVP 127
a=ice-ufrag:lbTM
a=ice-pwd:RFjNRfTU4UkaOAKa0Xivn64+<candidate and crypto data snipped>
a=setup:active
a=connection:new
a=rtcp:58323
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp
a=x-applicationsharing-contentflow:sendonlym=video 58167 RTP/AVP 122 123
c=IN IP4 123.45.67.89
a=x-ssrc-range:4246247680-4246247779
a=rtcp-fb:* x-message app send:src,x-pli recv:src,x-pli
a=rtcp-rsize
a=label:applicationsharing-video
a=ice-ufrag:TRWS
a=ice-pwd:mZjxk9kd1NNgv+IgKl49XmCk
a=x-mediasettings:applicationsharing-video=required<candidate and crypto data snipped>
a=rtcp:55154
a=sendonly
a=rtpmap:122 X-H264UC/90000
a=fmtp:122 packetization-mode=1;mst-mode=NI-TC
a=rtpmap:123 x-ulpfecuc/90000
a=rtcp-mux
First, a new session level attribute a=x-mediabw is included under the m=application 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 m=video 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 (a=rtpmap:122) that has been used for video since the release of Lync 2013. For added measure the out-of-band Forward Error Correction (a=rtpmap:123) 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.
Update
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.
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000
Very informative. Thanks
Thanks for this post. Great fundamentals as always! Its sometimes really amazing that MS is doing good but not talking about it in more detail. For people using screen sharing a lot this is a major step.
Will see when LRS will start going over to the SfB client…
Excellent as always Jeff, although I had hoped for lower bandwidth consumption here’s hoping options will become available to set the frame rate centrally.
Jeff,
Excellent article as always.
I’ve recently started revisiting your posts to learn more about video codecs & Lync/SfB. I so grateful for all the great content you create, which is sadly lacking on MS part.
May I encourage you to keep up the great work and sharing it with the community.
Thanks Paul. I’m trying to keep the articles coming as long as people are still reading them 🙂
[…] In Skype for Business 2016 we introduced Video based Screen Sharing (VbSS) for peer-to-peer calls. MVP Jeff Schertz has a good post on the technical details here. […]
Hi,
I’m wondering if this topic relates to some issues we’re seeing in our enterprise with screen sharing. At times, when sharing to some computers running SfB2016 the sharing works, then hangs on the receiver’s computer. It just won’t “paint” the screen with the window the sender is sending. Sometimes the window is literally halfway to displaying but pauses.. Video/Voice remain working for the most part, until the hanging eventually causes the sender’s SfB app to crash. What makes it more intriguing is the app that the sender (who is sharing their full desktop, not just the app) is trying to maximize/display is usually an Office App (e.g Excel or OUtlook), that seems to set off the hanging. I know, this makes no sense. But am at a total loss.
The help topic at Msoft that I’ve got going is: https://community.office365.com/en-us/f/166/p/430108/1086880
Any help/advice (thinking of going to a lower version of SfB) is appreciated.
Following up on this, do you know of any way of disabling VBSS in SfB2016? Some sort of registry key possibly?
Matt, I’m not aware of any way to disable the new functionality.
Thanks. We’re definitely seeing issues with what I believe is VBSS. In our testing, when taking VBSS out of the equation (ie, using SfB2015 for one of the endpoints, or sharing an app, or sharing via multiparty) we get no hanging. When we use VBSS (sfb2016 in point-to-point session), we see that when the sending endpoint is moving windows around (particularly Office Windows), the receiver’s screen hangs. CPU for the SfB process on the receiver drops to zero. The sender can sometimes recover the session if they minimize the app that has frozen on the receiver’s display (takes some coordination between the users to figure out what is frozen, etc..”can you see it now”), but if they don’t recover/unfreeze, eventually what happens is the sender’s SfB crashes and usually restarts.
This is between two endpoints that are communicating on the same gigabit switch..bandwidth not a concern.
It can be disabled in the following registry .
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
“EnableP2PScreenSharingOverVideo”=DWORD:00000000
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Lync]
“EnableP2PScreenSharingOverVideo”=DWORD:00000000
Thanks, I’ve bee meaning to add this information to the article for some time; just updated.
We have been working with Polycom to enable ContentConnect for sharing between Skype for Business and our Polycom infrastructure. One seemingly major omission with ContentConnect is PowerPoint sharing, which is what we have trained our staff to use by default for obvious reasons – annotation, preparing for meetings in advance and bandwidth constraints. Do you know if there are plans to implement that, or does VBSS or maybe even OneNote somehow fit into the future of sharing PowerPoint with Polycom?
ContentConnect can only handle RDP-based sharing which is driven by Desktop or Program options. The PowerPoint sharing and Whiteboarding features use a handful of different protocols and server components which are not supported in any standards-based interop platforms today.
I have spent many hours looking at the performance of desktop share and complaints from users about why it is much slower than other solutions including Live Meeting. A few things I have noticed
1) P2P sharing with Lync is quicker and transmits at a lower data rate if you lower the screen depth. This is no surprise.
2) When you play exactly the same data via a conference MCU the number of tiles sent for the same content increases and this in turn increases the bandwidth. Changing screen depth in this circumstance does nothing. I see that a conference based share uses up to 4x the bandwidth compared to the same share using 16bit depth.
3) I did wonder if this issues is related to running Lync on Windows 2008 R2 and hence RDP 7. However, my tests are consistent across Windows versions and the RDP always runs in TCP despite there being support for UDP in the RDP stack. Reading the documents on this MS claim significant improvement on the WAN with UDP based RDP….So why don’t the SfB / Lync team use this ??
Hi Jeff,
Any indication when this functionality will be available for meetings (more than 2 participants) as well?
Thanks,
Milen
Microsoft has not yet stated if or when this feature will be included in the ASMCU for conferences.
Hi Jeff,
I’m also keen to know when this will be rolled out for S4B Meetings and when/whether it will be compatible with the web browser client. I’m using S4B Online for a Teledentistry outcome and as video feeds cant be switched easily, VBSS is essential for sharing intraoral camera feeds.
‘One-Press’ Switching between USB cameras (or dual stream) would optimal, do you have any idea if this featurehas been discussed at all yet?
Cheers,
Alex
Nothing I’m aware that Microsoft has stated about these. For telemedicine solutions there are many SfB-compatible options available today with Polycom Group Series endpoints, for example.
Late reply but interesting Alex, we use it for the exact same thing and that is our only major annoyance as well with SfB. Even more annoying is the Metro Lync App HAS a switch camera button but they recently discontinued it! (And it is very buggy in Win10 ;\)
It’s sad to see the barely workable metro app have such a simple important feature that the full fledged licensed desktop version lacks ;\
We are having the same issue Matt mentioned above. We are also experiencing an issue where when trying to record from a version 15 client and sharing is from a version 16 client the recording gets audio fine but shows the message “At this point in the meeting no one was presenting or sharing video” I am wondering if this could be related. We have opened a case with Microsoft on the first issue. I am hoping they will fix both or at least the first and then we’ll upgrade everyone to 16…
Hi Damion,
We’re just now experiencing the issue you described on 3/17/2016 on the blog.schertz.name site. When using Skype for Business to record audio and video during screen sharing, we end up with an mp4 file that has only audio with a printed message disiplayed in the recording that says “At this point in the meeting, no one was presenting or sharing video.” Were you able to find a solution?
Thanks in advance!
Is this feature available in regular S4B, without an in house instance?
i need to share a video between two locations using S4B and have the audio available on both ends. When testing, this isn’t working
It works between any two 16.x SfB clients, even if they are federated.
Hi Jeff,
Is there any way for intermediate routers to identify desktop sharing session of Skype clearly?
i.e. Is there anyway to say that out of the following TCP sessions, this session is a Skype desktop sharing session?
As this traffic is encrypted I would think not. Unless you separate the traffic into dedicated port ranges as is sometimes done in QoS configurations.
Why would you test VBSS with a full screen video stream? This is not a supported use case for SfB web conferencing, and I’d be concerned that is skewing your results. Based on the technology one would expect at least parity if not improvement on bandwidth usage with VBSS over RDP. I’d love to see a test with a real, supported desktop share use case (website, Excel, Word, etc). Interesting data nonetheless on the improved experience with video. Thanks for all your diligent work.
Jason, this example wasn’t meant as a test of bandwidth improvements which may occur with VBSS. It was a simple way to easily show the obvious frame-rate improvement but also reflect that it was not at the cost of 10x the bandwidth either.
Hi Jeff,
With VBSS in mind, could you see screen sharing being extended to capture the input from a capture card in the future? It would open up the potential places software VC could replace hardware codecs.
I would assume it’s not likely, unless that is something which is addressed with the Broadcast Meeting recording capabilities in Skype.
Is there a minimum driver or hardware requirement for VBSS? We are finding that some PCs with SfB 2016 VBSS screen sharing issues need driver updates to fix the problems, while others with 2011 era drivers and hardware that cannot be updated require the registry entry to disable VBSS.
The latest server CU includes advertised VBSS support. What does this mean from a feature perspective? VBSS in meetings now?
Yes, and in fact this was already added to SfB Online meetings earlier this year. So in either Online or on-premises conferences (with the latest CU) meetings with only 16.x Windows clients can leverage VBSS. If any other clients are involved then it’ll fall back to RDP. I’ll have a full write-up on this coming soon.
Thanks for the clarification, this is yet another underdocumented MSFT thing, so its natural the community is confused (again).
Great stuff Jeff we have been battling with this for a while but since the i upgraded myself to Win10 i have not seen this yet(Touching wood as i write this) and hopefully it is the case that it is not experienced on win10. But for win7 this was definitely an issue. And best part is when i contacted Microsoft i got a uhhh lets do a online repair approach (again) so i am never in a hurry to contact them.
Jeff – great article. Does this also apply for Lync 2013/SB 2015 ? SB 2015/ Lync 2013 crashes during the conference screen sharing. Lync client for an attendee crashes randomly when desktop sharing is switched from presenter 1 to presenter 2 . It crashes for multiple attandees. We have Lync server 2010 and recently upgraded office 2010 to 2013 , including Lync Client 2013 /sb2015. Lync client for few attendee crashes right after desktop sharing is switched from presenter 1 to presenter 2. Presenter’s lync do not crash. only crashes for 4-5 attendees out of 22-25.
Any help is greatly appreciated.
Thanks
All down-level clients will trigger RDP fallback as they do not support VBSS. IF you are having these issues then it’s recommended to disable VBSS on the new clients until you can figure out the root cause of the sharing issues.
Thank you for your quick response. Yeah, it is a strange issue since it only crashes when there are 20-25 attendees in the meeting. Is there a way to disable VBSS on Lync 2013 and if it is not supported do i still need to disable it ?
Thank you again.
You can only disable it for supported clients and servers. This newer article shows how to do that: http://blog.schertz.name/2016/06/skype-for-business-vbss-update/
Hi Jeff
thank yoiu very much, as usual you make it very easy to understand !
one question tho, MSFT claims that the VBSS should be consuming less bandwidth, how come is that, since your testing shows more by 25%
https://technet.microsoft.com/en-us/library/mt756736.aspx
1080p Content RPD Average VbSS Average
PPT 200kbps 100kbps
CAD 3mbps 1mbps
Video 5mbps 1.3mbps
This is a common question. True, VBSS is more bandwidth efficient when sending the same amount of data as RDP. So in a single ‘frame’ of data VBSS would show up on the wire as less transmitted data than if RDP was used. But my example is an apples to oranges comparison as I used using high motion content sharing (showing a video). RDP is dropping a lot of that data as it simply cannot send most of it, while VBSS is able to send up to 15fps of that data. So overall VBSS is sending several times the amount of actual screen data, but not at several times the bandwidth. So where I’m showing 25% more bits transmitted over the network the end results is clearly more than 25% more data on the screen. You could argue that the VBSS video looks at least 3 times smoother than the RDP video, which would be a 200% increase in ‘result’ but at a measured increase in bandwidth’ of only 25%. I’d say that VBSS is MUCH more efficient in that light.
When doing SIP exchange between SfB and other endpoint, is it MANDATORY to have fallback TCP (fallback) candidates under m=video? Can there be just one candidate for m=applicationsharing TCP (RDP) and one candidate for m=video (VBSS)? What happens in this case?
I am trying to do Desktop Sharing between SfB and another endpoint that supports both TCP/RTP/AVP 127(RDP) and RTP/AVP 122 123 (VBSS), but after successful SIP handshake on both streams, for some reason SfB still keeps using RDP instead of VBSS. What can be the reason?
Hard to saw why it’s falling back to RDP. It could be that VBSS is not supported in the calling scenario you are testing, or another possibility is a known bug in an older SfB Server CU that could sometimes cause problems with content sharing setup due to a change in port multiplexing for UDP traffic.
Scenario is Video Call elevated to Video Call with Desktop Sharing by clicking Desktop Sharing button on S4B client.
After Successful SIP handshake on both m=applicationsharing and m=video, desktop sharing starts using RDP. However, After ~20 seconds, SfB Client sends reinvite with m=video 0, effectively disabling VBSS.
I have no idea why S4B does this, especially after successful SIP handshake in the first place.
Kindly, could you elaborate more on the “bug in an older SfB Server CU”. I don’t really get what you mean by “due to a change in port multiplexing for UDP traffic”.
Thank you so much for help.
Microsoft updated VBSS to use a single port for UDP media transmissions (instead of separate ports for RTP and RTCP) a while ago for audio and video. This was recently updated for UDP-based VBSS application sharing sessions, but had a bug that prevent it from working correctly in some scenarios. As I understand it that behavior was rolled out to the ASMCU for meetings in SfB SErver CU4, reverted in CU4.HF1, and will be reintroduced, correctly in a future CU.
Hi Jeff,
Perhaps I was a blind while reading this, but you got ~ +25% more data for VBSS. but MS says VBSS should use less network:
https://technet.microsoft.com/en-us/library/mt756736.aspx
VBSS is more efficient than RDP in a like-for-like situation. So if you are transmitting roughly 1 fps of data in RDP and then do the same in VBSS the overall bandwidth will be lower with VBSS. Understand though that my example above is not the same thing. RDP is incapable of matching the throughput that VBSS can, so VBSS allows transmission of more data. So VBSS is more efficient but can also send more data in the same amount of time if asked to. What you are really seeing is VBSS is sending easily more than double the source data that RDP can but at only a 25% increase in transmitted data.
Hi Jeff….again =)
While looking for the Application sharing reports from the QoE. one thing hits to my eyes. Sometimes the QoE says about the AS call quality:
“Applied bandwidth limit” 15 Kbps and ofthen “Applied bandwidth source” is APIModality Then there I have seen one another:
“Applied bandwidth limit” 13656 Kbps and often “Applied bandwidth source” is ApiSendSideBWLimit
Do you have more idea what those are? Shall we worried if the APIModality drops the bandwidth limit to 15k?
I think you’ve dug into those reports more than I have 🙂 I don’t know what that is referring to or if it’s indicative of any problem.
I’ve noticed this same setting and looked all over for what it means. I’m really curious if the client is restricting the bandwidth available.
Anyway to enforce VBSS so that if unsupported clients join a meeting, those endpoints just don’t get content and the meeting does not deprecate to RDP? Just had an experience with our G-500s with many other SfB clients connected: VBSS was performing incredibly well…then after 20 minutes someone joined with a legacy client, the meeting switched to RDP, and the content experience got messed-up…horrible.
No as that behavior is hardcoded in the Skype Server and Cloud ASMCUs. Fallback is triggered for several different event types and cannot be disabled to force VBSS only.
Are you aware of the troubles with the QoS and VBSS does not respect the port ranges:
http://www.uccramblings.com/vbss-and-qos/
Hello, I have the same problem, our corporate skype, it stays stuck when it comes to screen sharing, however it happens when we use Microsoft System Center Endpoint Protection, Do you know if there may be any relationship of the problem with the antivirus? if i use any other antivirus the problem does not happen.