Content Sharing with a Skype-registered Polycom Group Series
There’s little doubt that of all the old-school VC vendors, Polycom plays nicest with Microsoft and Skype for Business. However, it’s not always as simple as we’d like (or maybe expect), and this is never more true than with the current situation around Group Series, Skype-registration and content in Skype for Business meetings.
In the past, before the Group Series had the ability to register directly to Skype for Business, a couple of Polycom solutions called RealConnect and ContentConnect made their units play nice with Skype for Business. In very simple terms, the Polycom infrastructure would create a cascade that would connect to the Skype AVMCU for audio and video and connect the two platforms (this is the RealConnect part). The ContentConnect piece would manage all content to/from the Skype meeting and transcode it into the appropriate format. I could write another blog post on the various issues we’ve had with this but for the most part this solution worked well and set Polycom apart from the rest.
As for content in Skype for Business, historically (pre-VbSS), all content used the RDP protocol. Whilst VbSS gets us closer to a standards-based content format in Skype for Business, RDP is still used in certain scenarios. This is documented here but put simply, if someone uses an old client, or someone records the meeting, or someone shares a program/window, or someone takes control, or someone presents from the Web App, the content will fall back to RDP. Once the meeting has fallen back to RDP, it never returns to VbSS again.
And these RDP-fallback scenarios are at the heart of the core problem with Polycom Group Series registered directly to Skype for Business.
In the middle of 2017 when Polycom first introduced the ability to register Group Series to Skype for Business with the 6.1.0 firmware (Jeff Schertz detailed it nicely here) there was no support for RDP encoding in order to send content. It only supported RDP decoding so that it could receive content from Skype for Business. It would appear that the Group Series just doesn’t have the grunt to be able to encode RDP.
Because of this, even if you had VbSS enabled in your Skype environment, your meeting would be forced back to RDP for content because the Polycom endpoint didn’t support VbSS (old client scenario mentioned above). What this meant was that whilst the Group Series could receive content from a Skype Meeting, when someone tried to present content from the room (using the cable), it would appear to the Skype participants in the video stream. This was not ideal because it changed the behaviour of content in the meetings and was hard to message to users. It also made the content extremely hard to see for the Skype participants. In another cruel twist of fate, if someone in Skype locked the video spotlight so they could see the content easier it actually changed the view in the room meaning all the room saw was two versions of their own content. Confusion all round.
Last month when Polycom released 6.1.5 firmware, this introduced VbSS support. So, the Group Series joining a Skype meeting will no longer cause the content to fallback to RDP and content sent from the endpoint will show properly to the Skype participants. This was a very promising step and works well.
But… (there’s always a ‘but’)
This does not fix or affect the RDP-fallback scenarios listed above. The content still gets pushed back to RDP if someone records the meeting, or someone takes control, or someone shares a program/window and we still end up with content from the endpoint showing in the video stream.
The Group series throws a message to indicate that the content protocol has changed.
Content reverting to Legacy mode. Unable to share content.
Once this is shown, the content has to be restarted by either unplugging/plugging in the content cable again or by pressing the Show Content button on the Group Series touch control.
Once this is done, the content is shown in the video stream from the Group Series (just like it was pre-6.1.5).
The Problem
The problem in an enterprise scenario is how you message this to your users. It’s a hard one to explain because on the face of it, sometimes the endpoint will show content correctly, sometimes it won’t and the users won’t know why this is the case. Also, in the room, it all looks fine. It’s the people on Skype that notice it.
Potential Workarounds
So, what can we do about this. These are some of the options:
Remove Content Sharing Cable
Take the content sharing cable from the Group Series away and force everyone to share into the meeting via the Skype for Business client. This way the fallback to RDP will never affect the content. The downsides to this are:
- Slower process to share. Need to connect laptop to meeting and avoid causing audio feedback etc.
- Refresh rate not as good in the room. Content slower to update than via the cable.
- Cannot easily share content in the room when not in a Skype Meeting.
Make cable show local content only
A bit of a variation on the option above, but you could use an HDMI switcher and enable the content to only show content in the room. The cable could be labelled to indicate that it won’t work in a Skype meeting and encourage the user to use the Skype for Business client to share content into a meeting.
Communication, communication, communication
Try and explain to people why content might be appearing in the video stream for people on the Skype meeting. Perhaps leave some collateral in the room informing people to share via Skype client if this happens. This is very difficult, no matter how good you communication channels are.
Keep Group Series registered to Polycom
Bit of an extreme one, and maybe defeating the object of why you want to register to Skype in the first place, but if you’re staying on-prem you could use RealConnect and ContentConnect. If you’re on Skype for Business Online you could look at the RealConnect for Office 365 or even the new RealConnect Hybrid. This would require extra investment though.
Go with Skype Room System (Rigel) instead
An even more extreme option; go with the native Skype Room System instead. This way you won’t have any issues with content. It even supports the Office Web Apps/Office Online Server PowerPoint sharing. If I had a greenfield environment this would be my primary option.
So, that’s the content issue with Group Series when registered to Skype for Business. I’d be very interested on anyone else’s take on this…
