Polycom Trio 5.5.2 firmware

Normally I’m not posting about specific firmware, but in the 5.5.2.11338 (5.5.2 Rev AC) release for Polycom Trio’s (yup, plural, there are two models now 8800 and 8500) the codec SILK has been made available.  Skype for Business SILK has only been added as an experimental feature so to make use of it, you need to modify the Codec Priorities on the device.  Rumors abound that we may see SILK in VVX500 and VVX600 series devices in the near future, but that lower end devices may not have the processing power needed.

SILK will only be capable of being used in peer-to-peer type calls as it’s not available in the Conferencing MCU, and a reminder that it is “Experimental” at this time.  There appears to be some typo’s currently if you want to modify a FTP Provisioning server cfg file for your Trio’s, the above exported config reports that SILK is in ksps instead of kbps.  Perhaps this is the change over to Kilo Samples Per Second, or a just a typo…  Either way, something to be mindful of when modifying config files.

voice.codecPref.SILK.24ksps=”4″
voice.codecPref.SILK.16ksps=”5″
voice.codecPref.SILK.12ksps=”6″
voice.codecPref.SILK.8ksps=”7″

This release for the RealPresence Trio 8800 system includes the following highlights:  (pdf release notes here)

• Screen Mirroring on RealPresence Trio Solution

• Software Update using Windows Server

• RealPresence Trio 8800 System Media Keepalive

• Toggle Content and People Video Streams

• Skype for Business User Experience Enhancements

• Viewing a Different Calendar in Skype for Business Mode

• Dynamic Port Ranges for Video and Content

• Adding a PSTN Participant to a Call

• Displaying Multiple Calendar Meetings on Connected Monitor

• Web Sign in for Skype for Business Online

• Secure Single Sign-On (SSO) with Third-Party Supporting Solutions

• Managing Skype for Business Conference Participant Level in the Call Roster Screen

• Device Lock

• Client Media Port Ranges for Quality of Experience (QoE)

• Microsoft Quality of Experience Monitoring Server Protocol (MS-QoE)

• Exchange Web Services Discovery

• Unified Contact Store

• Alert Tones for Mute Status

• Dial Plan Normalization

• Dial Plan for SIP URI Dialing

• Join a Meeting using SIP URI

• Hybrid Line Registration

• User Log Upload

• Audio, Video, and Content Port Ranges

• Media Transport Ports for audio, video, and content

• Experimental: Support for SILK Audio Codec

Firmware for the Trio’s can be found here:  Polycom Voice Software

iOS 11.0.1 and Skype Mobility Client

*Fast Publish*

My version of a fast publish, mainly because I need more people to verify the issue, condition and if my suggested fix works for you as well, so please give feedback.

We were hearing client reports that they were unable to sign in on an iOS 11.0.1 updated device, or if/when they are able to sign in, they were getting kicked out after 10 mins.

After running an UCWA trace on the Frontends, the traffic for the user I was testing with literally just ended.  My intuition led me to think of the reverse proxy.

Quick scan though the settings and the timeout value was set to 960 seconds, 16 mins.  That doesn’t quite match the 10 min punting window, but I’ve seen weirder, and I like all-skype-timeout things to be 20 min or more.

We tested first with 3600 second and 1800 second timeout values and both were successful, the Skype Mobility client was not longer getting kicked out.  A 1200 setting will probably work, and may retry again tomorrow, but my preference for all Skype related firewall timeouts is 30 mins.

I checked our corporate environment, where we weren’t having issues, and the timeout was already set to 1800.  Not quite a pattern, but a possibly solution I hope.

Regular Skype Desktop clients are supposed to renew their connections every 5-15 minutes, and that the firewall timeouts need to be 20 minute or higher.  The Mac and iOS clients aren’t regular clients as they are using UCWA, https based connections.  I’ve seen with Netscalar if you leave the default timeouts at 180 instead of using 1200 or 1800, that the desktop client signs in, and is immediately signed back out.  Almost like there is a TTL minus 300 mechanism of some kind, that will end the clients connection if it hasn’t already renewed.  Just a guess though.  UCWA logging for the client activity ended very abruptly and dirty.

I welcome feedback on:
– if you have a web services time out setting of less 1200 and not having issues
– if you are having issues with less than a 1200 setting and raising it to 1200 or higher resolves
– if you are still having issues with a 1200 or a 1800 setting
– I’m also curious if you have a 600 second Time-out setting, does your iOS client kick out after 5 mins instead of 10 mins.

Thanks,