Apologies for the novel, doubly so if this is not the right place. This issue is at the intersection of a lot of different technologies and it's been perplexing both us and our vendors.
I'm working on troubleshooting a curious issue with our VTC environment, which consists of endpoint codecs (primarily Polycom Groupseries, but some older HDX models in the mix, though the codec model doesn't seem to matter). Multipoint calls are facilitated through use of an RMX bridge. Some years ago, we added a Polycom Content Share Server to the mix, which acts as a sort of glue to allow meeting rooms to connect to meetings created in Skype for Business. My understanding is that the CSS acts as a sort of translator for the H.323 endpoints (Polycom codecs) connected to the RMX bridge and the SIP endpoints connected to Skype.
Typically, participants who are either in one of the VTC rooms or connected via Skype will share out a brief (most often a Powerpoint slide deck) via the Share Desktop feature in the Skype client. We've had end users reporting that they're seeing significant delays in slide transitions--sometimes upwards of 30 seconds to fully transition from one slide to another. While both Windows and Mac were susceptible, it seemed to happen with much greater frequency on Macs. Initially we suspected either network congestion or resource starvation (CPU/memory) on one of the servers described above, but couldn't find any evidence of either of those possibilities. Eventually, we tested upgrading software on the CSS and our Skype infrastructure to support VbSS (Video-based Screen Sharing) as the default sharing mechanism, rather than RDP. This showed an immediate improvement; rather than the slow tiling in we were seeing before, transitions were immediate (within half a second to a second of whoever was sharing changing slides, we'd see the content channel update in other locations), and slides transitioned all at once rather than tiling in (which makes sense with my understanding that VbSS is sent as a complete video stream and RDP more piecemeal).
We thought that we'd more or less solved the problem at that point, but we're seeing an odd new symptom--when a Mac Skype client connects to a meeting and shares content, at first the video is fine, but as time goes on, particularly if it remains static for a long period of time (30-60 seconds), it becomes more and more likely that the content channel will get "stuck." When this happens, someone can transitions slides, e.g. from slide 3 to slide 4, and the content channel will remain stuck on slide 3 for upwards of 30 seconds before transitioning on its own.
A couple weird things about this:
When the content gets "stuck" like this, at any time while it is stuck, if you move the mouse, it suddenly unsticks and transitions.
This only seems to happen when someone joins the meeting from their Mac without audio, which is what you'd normally do if you were actually in one of the VTC conference rooms; since the room is already joined to the meeting, joining audio from a second device in the room would cause a feedback loop/echo. When joining audio and just muting your mic/speakers, Skype pops up a small window with video/audio/content mute controls that stays always-on-top when the primary conference window is not in focus. This small control window is not present in the shared content; if you go to a full screen Powerpoint presentation, you'll see it on the Mac display, but not on any of the endpoints receiving the content. The control window does not appear when the meeting is joined without audio. These two conditions lead me to suspect that there's some sort of bug in the Mac Skype client, except that...
The delays don't happen when in a non-integrated conference (i.e. only Skype clients are connected).
As I said, we're pretty stumped on this; all my troubleshooting has been able to really do is find some weirdly specific conditions for it to happen. If anyone has any ideas, I'd greatly appreciate it.
