We have released an update to the Skype Meetings App - the SfB web app available for meetings hosted on Skype for Business Online or on Skype for Business 2015 server when configured to use the online web app.  This release updates the scripts that are automatically downloaded for all customers when they use the web app; it is not necessary to download and install the app again.  


With this update, you will see the following improvements:


  • When a user cannot join a meeting due to network configuration issues (such as blocked ports or IP addresses), the app shows an informative message with a link to documentation of the network requirements for Skype Meetings App that can be passed on to the user's support team.  (Note that we streamlined our documentation of the minimum requirements to make it easier for organizations to configure their networks to support Skype Meetings App.  Check out our new topic: Skype Meetings App minimum network requirements.)
  • Fixed an issue that allowed users to unmute participants in a meeting who are called in from a phone. This was a privacy concern since the callers may not be aware that they have been unmuted.
  • Fixed an issue that prevented the Help and Find local number buttons from working when clicked more than once.
  • Updated the jQuery library used in the scripts to address a security concern.
For the steps needed to configure Skype for Business 2015 Server to use Skype Meetings App for meetings, check out this blog post. 
Thanks for using Skype Meetings App!
1 Comment
Occasional Visitor

The Skype Meetings App has been a step backwards for us unfortunately. It appears to attempt to access HTTPS resources directly, indicating that it may not be coded to respect the system web proxy configuration. So we used to be able to join other external companies' Skype meetings when we used the pure SfB Web App but now it's a standalone app that hasn't been properly coded, we now cannot join SfB Online meetings.


We are on a government network with tight security controls. All web must pass through our web filters. Non-web traffic is rarely allowed directly out.


I don't think we should have to open our firewall when we have a perfectly good web proxy solution which has already been configured to permit the requests.


I note the requirements also refer to UDP ports. Are these necessary? The traffic can't be encapsulated in HTTPS packets and therefore then sent through to the system configured web proxy?


I saw a similar situation to this when the OneDrive team re-coded the iOS OneDrive app from the ground up. They forgot to include proxy support in the initial release. I wrote to them via a blog like this. The issue was acknowledged and within a month they released a fix. I'm hoping it's the same thing here. You just need to code-in the support for web proxies. The issue appears to exist on both Windows and macOS.


Also we're looking at the firewall traffic and seeing SfB activity trying to get to a 10.56.x.x IP address. We don't think we have anything using that address on our infrastructure. Is it possible you've got some debug code in there still or something similar and you guys use 10.56.x.x internally?