What is RealConnect?

February 26, 2018 by · 1 Comment 

Over the years this blog has covered the general topic of interoperability between the various Microsoft Communications Server UC platforms and industry standards-based video conferencing equipment found all over the world.  These Video TeleConferencing (VTC) systems are in no way a legacy platform as although the standards have been around for a long time there are several manufacturers producing new products based on the same open standards.

Thus the idea of interoperability between those platforms and the Lync/Skype for Business platforms, both on-premises and online, continues to be a popular topic.  While much has changed over time in terms of workflows and feature capabilities the overall need is no less important than before.  And as the Polycom RealConnect approach has grown more flexible with various methods of deliverability the scope has also grown to cover numerous different topologies.  This article is intended to explain not only the core of the RealConnect workflow but compare in detail the different topologies along with specific requirements and procurement guidance.


Interoperability is hardly a foreign concept throughout this blog. Several past articles have covered older offerings and how they worked back with earlier Office Communicator and Lync versions. RealConnect as a concept was also covered back in early 2015 as a step away from traditional singular MCU methods of meeting in the middle for cross-platform conferences.

Each of these articles are detailed and cover several scenarios including newer cloud offerings like Skype for Business Online, so for a fuller understanding of the overall story it is recommended to give them each a read before moving on here. But if one is already familiar with the concepts and terminology used throughout then by all means read on.

Most importantly, RealConnect is not the name of an individual product or service offering. It is a name that has been used to describe a patented simplistic workflow which can bring any standards-based VTC into a Lync or Skype for Business meeting.

This workflow is defined by its unique behavior of three specific concepts: Scheduling, Joining, and Cascading

  • Scheduling – Primarily all meetings are scheduled using the Skype for Business Outlook plugin no differently than the normal Microsoft workflow.  A new meeting is created using Outlook and enabled as a Skype Meeting using the standard Office plug-in. There are no changes to this process and no additional software plugins required at the end-user level.  After introducing a RealConnect solution to an existing Lync or Skype for Business deployment the users do not change how they book meetings and resources in any way.


  • JoiningThe second concept is the fact that multiple different manufacturer’s VTCs can leverage a simple One Touch Dial approach to join the scheduled meeting just like other native Lync or Skype for Business clients and devices, eliminating the need to manually enter any complex dial strings used in traditional H.323 or SIP conferencing platforms.  (This is an optional, yet desirable capability as the VTCs can always be dialed into the meetings using traditional H.323 or SIP methods.)

image     image

  • CascadingThe third is that the solution utilizes a cascading of two conference bridges, or Multipoint Control Units (MCU) so that the meeting is in essence two separate conference platforms working in concert to appears as one.  The standards-based side is run on a traditional Polycom virtual or physical MCU while the Microsoft UC side runs on a Lync or Skype for Business Front End Server on Skype for Business Online. Audio, video, and content sharing streams are transcoded between the bridges (this cascading behavior is sometimes incorrectly referred to as ‘barbelling’).  Additional information like participant lists, conference controls, and more are also shared between the two platforms.


    As discussed in other articles the benefits of the above workflow far outweighed past methods of trying to bend the Microsoft workflow to match legacy conferencing experiences which for the most part were no natively user friendly.  The ease-of-use inherent in the Microsoft platforms need not be hamstrung anymore and thus the RealConnect story immediately resonated on several levels.  The response was such that even partial facsimiles of this unique workflow were eventually brought to market in the form of Acano’s Dual-Homed offering (which is now part of Cisco Meeting Server) and Pexip’s Infinity solution.  These other solutions lack the vendor-neutral approach providing ubiquitous one-touch join, some advanced features, and official Microsoft support across multiple deployment topologies that RealConnect has.

    With the growing cloud consumption of a Microsoft UC platform which was originally designed for on-premises server deployments the next steps were to provide RealConnect into more environments by addressing hybrid and cloud-only topologies.  This is where the story started to become more complicated as with so many different offerings how is one to clearly understand which, if any are applicable to their specific environment?  Or what happens if that environment is in flux and is slowly, or rapidly, migrating from one scenario to another?

    The easy answer is that RealConnect can be utilized in any possible configuration of Skype for Business and Exchange topologies from on-premises server deployments, to hybrid configurations, to cloud-only Office 365 tenants.

    Solution Offerings

    As mentioned RealConnect is not a product but instead a workflow provided by leveraging core Polycom products.  The existing products can be consumed in one of two ways: either as on-premises server deployments or simply as a cloud service.  Throughout this article the traditional method of deploying and managing physical and/or virtual server components on-premises is referred to as Polycom Servers where the overall cloud offering is referenced as the Polycom Service.

    Today the cloud service offers only some of what the on-premises deployment does.  The entire RealConnect workflow and capabilities are provided, but not all of the additional standards-based video capabilities that come with the Polycom Servers unrelated to RealConnect.  So where the cloud service can provide meeting interoperability between standards-based devices and the Microsoft UC platforms it does not provide VTC registration and management, call routing, firewall transversal, or any of the other services available with the larger Polycom Server offering.  To summarize, outside of RealConnect there are vast differences between the server and service models, but RealConnect itself is nearly identical between the two models.

    Polycom Servers

    As mentioned there are many different Polycom servers which provide a range of capabilities across various platforms.  Among these are four core components that provide the RealConnect workflow. These are individual on-premises server installations, some of which started as hardware appliances and were later also released as virtual servers, while others have been virtual servers since their inception.  At this point all the components covered below are available as software, where the MCU component could alternatively be deployed as hardware if desired.

    The full RealConnect experience is provided by leveraging four unique on-premises components which will be referred to as thePolycom Core’ throughout this article:

    • Workflow Server is an optional application server which can host several different Polycom application-based solutions.  For RealConnect this server has two potential purposes: hosting the One Touch Dial (OTD) application for VTCs and/or supporting connectivity to Skype for Business Online meetings.
    • Distributed Media Appliance (DMA) is a core component which, for the purposes of RealConnect, primarily handles the signaling between each component and an on-premises Lync or Skype for Business Server Front End server or pool.  The DMA also provides for VTC endpoint registration and manages Polycom MCUs.

    • Collaboration Server (a.k.a. Real Media eXperience, RMX) is the aforementioned MCU which handles all of the media transcoding between standards-based VTCs and the streams coming from and going to the Lync/SfB MCU.  This MCU transcodes audio and video sessions between various protocols like H.264 AVC and X-H264UC.  Where the DMA could be referred to as the brains of the conferencing operation the RMX is the heart, doing the majority of the work.

    • ContentConnect (a.k.a. Content Sharing Server or CSS) is an additional software-only MCU that was created solely to transcode content sharing sessions between standards-based protocols like H.239 and Binary Floor Control Protocol (BCFP) into Microsoft’s sharing protocols like Video-based Screen Sharing (VbSS) and Remote Desktop Protocol (RDP).


    Essentially what the Polycom Core provides is a platform for a VTC to register to via H.323 and/or SIP and then place a call over either protocol directly to a standards-based MCU which will then connect to the associated Lync/SfB meeting MCU and bi-directionally transcode audio, video, and content sharing streams.  Additionally a user can start the scheduled meeting from within the reserved conference room by simply tapping on or selecting a ‘Join Meeting’ button.

    These components are also part of the larger Collaboration Infrastructure family (also referred to as the RealPresence Platform) which includes additional optional servers that handle various other standards-based conferencing tasks outside of what is needed for the RealConnect experience.  The entire suite is sold using a simple licensing model called Polycom RealPresence Clariti, with the exception of Workflow Server which is purchased separately and deployed by qualified consulting services.  Endpoint management, call routing, firewall traversal, and other needs can be met by the entire suite that goes above and beyond the core RealConnect interoperability workflow discussed in this article.

    Polycom Service

    This offering of RealConnect utilizes an in-place globally redundant cloud deployment in the Microsoft Azure cloud.  At the time of posting this article RealConnect is available as a service in multiple countries worldwide by leveraging a deployment hosted by Microsoft and managed by Polycom in five Azure datacenters across the planet.

    As this is a cloud offering then the individual components are essentially irrelevant, but understand that it is not just the Polycom Core server components shown above dropped into Azure virtual machines.  This service offering was created by essentially pulling apart those components and rewriting a lot of code, creating new components, and basically building an entirely new cloud architecture designed for cloud scale and availability.  The Internet-facing perimeter includes a few entry points which provide connectivity for accessing the Polycom web portals for service provisioning and configuration tasks, signaling services for VTC calls, and load balanced MCU IPs for media negotiation.

    The main difference between these offerings though is that for on-premises server deployments the MCU cascading is 1:1 where a single Polycom MCU connects to a meeting on a single SfB MCU.  Once that cascade is established then SfB clients and VTCs each have one native entry-point into that meeting.  But with the cloud offering every single VTC will be routed to a dedicated Polycom virtual MCU sized appropriately for a single VTC connection.  All of these individual MCUs then connect back to the same SfB MCU hosting the meeting, essentially creating 1:n cascades.  This architecture allows for the VTCs to connect to the closest available Polycom MCU regardless of where the SfB Meeting is actually hosted, reducing transit time over the Internet as much as possible.


    Although the primary components of this solution are cloud-based, as with any cloud solution there is sometimes a requirement for an on-premises application to handle some specific communications between the cloud services and certain on-premises components or clients.

    One scenario where this is evident is with One Touch Dial.  In the earlier on-premises server model the Workflow Server that hosts the OTD application provides the meeting invitation locally to both Polycom and compatible Cisco endpoints. But in the cloud model the solution is different as the Polycom and Cisco endpoints do not use the same methodology for Exchange compatibility.  This will be explained more further on in the article but for now understand that Polycom VTCs can go directly to the OTD Service running in Azure, but Cisco endpoints cannot; they require a local gateway to provide that connectivity.  Thus the cloud offering is made up of two components: the OTD Service running in Azure and the OTD application which must run on-premises and communicate directly with the Cisco VTCs.  In short if an environment has only Polycom VTCs then the on-premises application is not required, but the inclusion of any Cisco VTCs means that it is required if rolling out a one touch join experience is desired.

    To address the on-premises need the Polycom Cloud Relay was created.  The Cloud Relay is a lightweight virtual server available for download that Polycom cloud customers can self-deploy and then easily connect to the cloud.  It is available as either a VMware OVA or HyperV image and is essentially an on-premises gateway between various Polycom cloud services and whatever on-premises components are leveraged by the desired application.  Cloud Relay can host different applications for various Polycom service offerings and two of those are specifically related to RealConnect.  The first is One Touch Dial (OTD) as outlined in the previous paragraph, and the second is the RealConnect Hybrid application which will be explained in a later section.


    Now that the different offerings have been introduced and discussed the next step is to break down the various ways that RealConnect can be deployed or consumed.  As mentioned earlier there are no architectural limitations on the environment’s current or future state such as that either Lync Server 2013 or Skype for Business Server 2015 is deployed, and/or Skype for Business Online is involved.  Additionally any version of Exchange Server 2010 through 2016 is supported as well as Exchange Online.  Hybrid deployments of Exchange and/or Skype for Business are also supported in all RealConnect topologies.

    The following diagram offers a simplistic view of the various ways that RealConnect can be leveraged across four common scenarios. Understand that this is not a complete diagram of mandatory or optional components but is meant to depict where the two conferences are hosted in each by indicating only the MCU placements.  Dashed lines indicate signaling and media communications between each client/device and their respective native MCU, while the solid green lines indicate the cascading media sessions which travel between both MCUs.


    Among the four individual topologies listed above the the On-Premises models utilize a Polycom server deployment for the primary meeting interoperability, whereas the Cloud models leverage the global Polycom services deployed in Microsoft Azure.

    RealConnect On-Premises

    The first two models both consist of the same Polycom core server software installation which would be integrated with an on-premises Lync Server 2013 or Skype for Business Server 2015 pool.  These models support providing the RealConnect experience to any meeting hosted in a Skype or Business Server, Hybrid, or Online environment.

    Skype for Business Server

    The simplest and original offering of RealConnect is a topology of all Polycom and Microsoft server components installed on-premises.


    The Polycom Core includes the four on-premises servers described earlier that provide the RealConnect workflow, some of which are integrated with Lync or Skype for Business Server via the Trusted Application model.  The Polycom Edge represents an optional server called RealPresence Access Director (RPAD) which would support external VTCs attempting to join RealConnect meetings.

    Deployment is straightforward using the Trusted Application model between the DMA, RMX, and Lync/SfB Front End server/pool.  Signaling communications between each are encrypted over TLS 5061 in both directions.  Media communications for audio and video are directly between the RMX and Lync/SfB AVMCU and application sharing media is directly between the ContentConnect Server and the Lync/SfB ASMCU.  All media types utilize the standard Microsoft ports and protocols used by all other Lync and SfB clients.

    Also potentially included in the Polycom Core is the One Touch Dial (OTD) application by deploying an instance of Workflow Server on-premises.  This is an optional component here as if there is no need or ability to support this feature for meetings then it does not need to be deployed.  In regards to Exchange this deployment can leverage mailboxes stored in either Exchange Server or Exchange Online.  In hybrid Exchange deployments where some conference room mailboxes may reside in both locations then the OTD application would support two side-by-side configurations with 2 unique hostnames for VTCs to point to as their calendaring service.  One FQDN would be used by VTCs with their mailboxes hosted on a local Exchange Server while the other FQDN would be used by VTCs with their mailboxes hosted in Exchange Online.

    In this model the meeting invitations are unchanged and as long as Dial-In Conferencing has been enabled on the Lync/SfB Server then the audio Conference ID created by the Lync/SfB Server is also used as the video conference ID.


    Users can either dial that conference ID from any VTC or select a "Join Meeting" button on the system if leveraging One Touch Dial.  This meeting invitation format is applicable to all RealConnect topologies except for one, which is explained later on.

    Skype for Business Hybrid & Online

    This topology uses the same on-premises Polycom Server components but extends supports to Skype for Business Hybrid and Online deployments where a meeting is running in Skype for Business Online..


    This model functions a bit differently than when everything is installed on-premises across both sides.  In order to support interoperability with any Skype Meetings hosted in Office 365 a important requirements have been added:

    • Even if all Skype for Business users have been migrated to Skype for Business Online a single Front End Server and Edge Server must still be left on-premises to leverage the Trusted Application integration between the on-premises Polycom Core servers and Skype for Business Online.  (This Trusted Application model cannot be used directly with Office 365.)  This on-premises server installation can be either Lync Server 2013 or Skype for Business Server 2015.  An existing Split-Domain configuration can be utilized for permanent Hybrid deployments. Alternatively a new federated installation of Lync/SfB Server in a separate forest could be deployed for cloud-only deployments that do not currently have any on-premises servers. Cloud Connector Edition (CCE) cannot be used for this connectivity as that solution was only designed for telephony integration and does not support all the signaling and media negotiation needs for audio, video, and content sharing.
    • The Workflow Server must be deployed as it is an integral part of how scheduled Skype Online Meetings are discovered and located for the the RealConnect cascades to be established with Skype for Business Online MCUs.  If this server is omitted then RealConnect would function only for meetings scheduled by on-premises Lync/SfB users; connectivity to Skype for Business Online meetings would not be possible.  (Even if there is no desire for One Touch Dial in a specific deployment the Workflow Server is still mandatory in this model for the reasoning above.)

    Otherwise the rest of the solution is the same as the full on-premises model.  Scheduling and joining meetings is no different between each and media flows are unchanged for on-premises user’s meetings.  For any online meetings the Polycom MCU will utilize the on-premises Edge Server to relay cascaded media streams to the proper Skype for Business Online MCU.

    Meeting invitations in this model are the same for all users regardless of whether they are homed on-premises or online and look identical to the example invitation shown in the previous topology.

    RealConnect Cloud

    The other two models are completely different from the first two as these instead leverage the Polycom Services available in the cloud. Just as with the server approach the services models can provide the RealConnect experience to any meeting hosted in a Skype or Business Server, Hybrid, or Online environment.

    Skype for Business Server

    In this model the Polycom services in the cloud communicate with an on-premises deployment of Skype for Business Server by way of the aforementioned Cloud Relay server.


    The Cloud Relay server fills two roles today which are specific to RealConnect.  One of these is providing an on-premises application capable of bridging the signaling communications path between the Polycom Service in Azure to the Skype for Business Server deployment on-premises by way of the familiar Trusted Application model.  This RealConnect Hybrid application that runs on the Cloud Relay server is configured through Polycom customer portal once the Cloud Relay server has been deployed and connected to the cloud service. (Note that the usage of the word ‘Hybrid’ here refers to the pairing of Polycom cloud services and Skype for Business on-premises servers;  it is not referring to the Skype for Business Hybrid/Split-Domain deployment model.)

    The Cloud Relay is a prerequisite installation for this topology and the same deployed instance can also host the OTD application to handle the required on-premises TMS emulation for any Cisco VTCs.

    Again, the meeting invitations in this model are identical to each scenario discussed thus far as the solution continues to leverage the audio Conference ID as the traditional meeting number.

    Skype for Business Online

    This is the inverse of the full on-premises topology as now everything is hosted online in Microsoft’s Office 365 cloud.  The Polycom Services deployed in Azure are adjacent to the Skype for Business Online services in the same Office 365 datacenters.  Signaling and media connectivity between them is a direct and fast as possible, providing for a latency-free, robust route for cascaded meeting traffic.


    While there are no Microsoft server components required on-premises their may still be a need for some standards-based infrastructure to still be installed on-premises, hence the "Optional H.323/SIP Infrastructure" object in the diagram above.  This potential need is due to the fact that a standard VTC is only provided access to RealConnect meetings in this model, it does not receive SIP or H.323 registration from the Polycom Service, configuration or firmware management, firewall traversal assistance and so on.  This optional infrastructure could be provided by Polycom’s RealConnect Access Suite (RCAS), which is basically the same things you get with Clariti minus the MCU.  These traditional on-premises management and routing functions could also be performed by existing infrastructure like Cisco VCS or Call Manager deployments.  The goal here is to simple allow a VTC to place a call off-network to the Internet and reach the MCUs hosted in Azure.

    Aside from conferencing services the other capability provided by this cloud offering is One Touch Dial.  But instead of leveraging Workflow Server it has been deployed in Azure as a service.  Polycom VTCs like the HDX and Group Series can connect directly to this cloud service as they natively support Exchange Web Services (EWS) and will retrieve meeting invitations automatically.

    But the same is not true for Cisco VTCs which support Cisco’s One Button To Push (OBTP) feature.  While this feature also leverages Exchange Server to access the meeting invitations sent to a conference room’s mailbox the retrieval method is different.  A Cisco VTC is designed to rely on a configured Cisco TelePresence Management Suite (TMS) server to retrieve the mail on its behalf and then push the message to it.  For RealConnect this requires the deployment of an on-premises gateway to handle opening outbound connections to the cloud service as well as being able to directly connect to local Cisco VTCs.  To address this need of deploying a lightweight OTD application locally a new virtual server called the Polycom Cloud Relay is utilized.

    The main difference between the aforementioned Workflow Server and this new Cloud Relay is that Workflow Server is a purchased professional services deployment of a virtual server that is designed for use with the on-premises Polycom Server model, but the Cloud Relay is a free, lightweight virtual server which can easily be self-deployed and is intended for anyone leveraging the cloud Polycom service offering.

    The difference in the meeting invitation format for this specific topology means that Skype for Business users who schedule meetings must be a using a supported Office 2016 Click-to-Run (C2R) version for either Windows or Mac.  As of February 2018 all release channels other than Deferred include the prerequisite code in the Outlook and Skype for Business clients to generate additional information in the meeting invitation required by VTCs to join the meeting.


    The highlighted information above can be used to manually dial into a RealConnect meeting, but the One Touch Dial solution also parses this data to create the join button for supported VTCs.  Within this additional information a unique VTC Conference ID is created for every new meeting which is different from any audio Conference ID which may or may not already exist in the invite.

    The invitations for RealConnect look like the above for only this all cloud topology, meaning only when Skype for Business Online is used with the Polycom Service.  Notice that this invitation differs from the one shown previously because in the Skype for Business Online multitenant environment it is not possible to reuse individual audio conference ID for the purposes of video interoperability.  Also there needs to be no reliance on having an Audio Conferencing or Audio Conferencing Partner (ACP) licenses assigned to the scheduling user.  These requirements lead to the creation of new functionality put directly into the Office software by Microsoft which was only developed in the C2R model and not placed into the older MSI packages.

    Skype for Business Hybrid

    Providing RealConnect to a Skype for Business Hybrid deployment is different here in the Cloud topologies than outlined earlier in the On-Premises topologies.  While a single topology utilizing Polycom Servers supports both Skype for Business Hybrid and Online-only deployment methodologies when leveraging the Polycom Service a single model is not applicable; both models are used in conjunction.  As explained in the next section the licensing is the same so consuming both Cloud models is essentially transparent.  If Skype for Business users are migrated from server to online then the RealConnect experience is essentially unchanged, with the one exception related to the meeting invitation requirements and configuration outlined for Skype For Business Online users.

    Choosing a Solution

    After reviewing all of this information the next logical step is to outline which model or models can be utilized in a single environment.  Where some of these models can cover an entire topology others can be used together to address other potential needs.

    The following matrix lists which models support the various potential components in a Microsoft UC-enabled environment.

    RealConnect On-Premises RealConnect Cloud
    Skype for Business
    Skype for Business
    Hybrid, Online
    Skype for Business
    Skype for Business
    Exchange Server X X X X
    Exchange Hybrid X X X X
    Exchange Online X X X X
    Office 2013 X X X X
    Office 2016 X X X C2R Required
    Dial-In Conferencing Required Required (Hybrid) Optional N/A
    Audio Conferencing N/A Recommended N/A Optional

    Given the few limitations above many environments will actually be able to choose from multiple topologies, so it becomes not a question of which can be used but instead which should be used.  That answer will depend largely where it video interoperability solution is most desired.  Some will prefer a cloud service whenever possible to reduce deployment complexity and lifecycle management, meanwhile others may be more concerned with controlling the conferencing communications end-to-end by selecting on-premises components across the board.

    Some key things to think about when making this decision include:

    • Where will the meeting MCU sit and what options are available to control the media delivery?  Using a full cloud service introduces the inherent latency and loss of Quality of Service capabilities of traversing the public Internet for some or all of the potential traffic.  This may be considered ‘good enough’ when balancing the business needs versus the business costs.  Obviously choosing to put one or both MCUs on-premises offers complete control of the available options in the respective platforms and is the model of choice when focusing on an ‘executive class’ experience

    • How are Skype for Business Hybrid environments used with the Polycom Service?  For Hybrid deployments where some Skype for Business users are homed on-premises with SfB Server yet others are homed in SfB Online then both topologies will essentially be consumed.  A single licensing model covers both of these topologies so where the users are homed does not matter as they can be migrated between at any time if desired.  The invitations will look different, as outlined in sections above and the users homed on-premises can utilize any version of Outlook.  It is the users homed in SfB Online which have the Office C2R requirement, so pay special attention to this if using RealConnect for SfB Server users who are scheduling meetings on version of Office other than 2016 C2R.  RealConnect will work from those users now but if they are migrated to SfB Online then it will stop working for their meetings until they are upgraded to the required Office software.

    • Does it matter where my Exchange mailboxes reside?  All topologies support all methods of Exchange mailbox storage.  The mailboxes for both the scheduling users and room resources can be stored on any arrangement of Exchange Server, Online or Hybrid configurations.  Polycom endpoints can utilize native Exchange Web Services connections over HTTPS (TCP 443) to access the OTD application running on a Workflow Server (in On-Premises topologies) or go directly to the OTD Service in Azure (for Cloud topologies).  Cisco endpoints obviously can only communicate with an on-premises Workflow Server or Cloud Relay server, depending on the selected topology.

    • What roles do Dial-In Conferencing and Audio Conferencing play in RealConnect?  For users homed on-premises the Skype for Business Server configuration would need Dial-In Conferencing enabled to insure that the requisite audio Conference ID is included in all invitations.  For SfB Online users the Audio Conferencing (formerly PSTN Conferencing) Skype add-in license controls that behavior.  RealConnect in the Cloud model has no reliance on the existence of audio conferencing information in the invitation, so it is irrelevant.  The Cloud model when used with Skype for Business Online user is unique though as the Audio Conferencing information is optional.  If the SfB Online user has been assigned an Audio Conference license then Workflow Server will utilize the existing audio Conference ID for VTC connectivity into RealConnect meetings.  But if the user is not licensed and thus has no audio Conference ID in their invitations then Workflow Server will dynamic create a unique ID for RealConnect to utilize.  The key here is that dynamically generated ID is only ever seen by the room resources which are booked in the meeting by utilizing the ‘Join Meeting’ button.  IT is not possible to inject that ID into the Skype Meetings invitation which was already sent to numerous possible other attendees.  In short, One Touch Dial configuration is a requirement for meetings created by SfB Online users without an audio Conference ID provided in their original Skype Meeting; ad-hoc numeric dialing would not be possible.


    Purchasing RealConnect is actually quite simple once the differences between the server and services approaches are understood. While there are several possibilities depending on the engagement it is very easy to break down the offerings into two categories.  Both will use an example company of 4000 Skype for Business users with 80 standards-based VTCs deployed throughout the environment.  A generous high-water mark of 25% concurrent VTC utilization will be used for the estimates shown below.

    Polycom Servers

    Both On-Premises topologies utilize the same Polycom Server components and thus can be purchased using the same RealPresence Clariti licensing model in addition to optional professional services engagements.

    • RealPresence Clariti – includes 3 of the 4 Polycom Core Server components for RealConnect.

    • Workflow Server – optional fourth component purchased through a professional services engagement.

    • SfB Server Deployment – another professional services engagement that includes deployment and potential remote management of a lightweight Skype for Business Front-End and Edge server components required for leveraging Skype’s Trusted Application integration with the Polycom Core.  (This is only applicable to supporting Skype for Business Online meetings and only if there is not already an existing Lync or SfB Server Hybrid deployment.)

    Clariti licenses are ‘per user’ in that a user essentially an active connection, meaning this is a concurrency-based licensing model. (The terms license, user, connection, and resource are all basically interchangeable here.)  Sizing exercises would include calculating the desired VTC concurrency limit and adding that the estimated meeting concurrency limit.  Connections are consumed both by every connected VTC and every cascaded meeting, where a VTC consumes a single license but each meeting cascade can consume 1, 2, or 3 licenses.  The first is for the initial cascade establishment itself and any number of audio and video streams.  The second would be dynamically consumed if and when application sharing content is active in the meeting.  A third license per cascade would be used if an optional Polycom MCU feature is enabled to show additional VTCs and/or Immersive Telepresence layouts in the panorama video stream in RealConnect meetings.

    So, if 20 VTCs are all in the same RealConnect meeting at the same time then the solution would need to include 23 licenses (20 VTCs + 3 for a single cascade) to support all potential workloads.  More realistically it is possible that those same 20 VTCs may instead be joining 10 different RealConnect meetings at the same time which may utilize up to 50 licenses (20 VTC + 30 for ten unique cascades).

    Polycom Services

    Both Cloud topologies share a single Enterprise-Wide Licensing (EWL) model.  This model is also concurrency based, similar to Clariti, but is even simpler to calculate the desired number of licenses.

    • Enterprise Wide License – allows consumption of the Polycom video interoperability service.

    • Cloud Relay – free virtual server to provide support for the One Touch Dial application (for Cisco VTCs) and/or support the RealConnect Hybrid application required when supporting Skype meetings hosted on an on-premises for Business Server.

    • RealConnect Access Suite – provides optional on-premises traditional video infrastructure components to handle any desired VTC managing and routing calls to the Azure-based Polycom Service.

    When using the services only the VTC connections are counted; there are no additional numbers that need to be figured in based on MCU cascading.  Calculating the number of required licenses requires estimating the same desired high-water mark of concurrent VTC utilization (e.g. a 25% target).  Thus, if at most 20 VTCs need to join meetings at the same then 20 licenses is all that needs to be purchased.  It does not matter if all of those VTCs are joining a single RealConnect meeting or 20 different concurrent meetings, due to the cloud service architecture the amount of cascades is irrelevant.  (By looking closer at the media flow diagram shown earlier in this article under the Polycom Service description one can see that every single VTC is assigned its own dedicated MCU resource which means that there will be multiple cascades when multiple VTCs join the same meeting, no differently than if they join separate meetings.)

    The limiting factor here then is that the purchased licenses control how many VTCs can concurrently connect to any of the meetings scheduled by any licensed user in the company.  Additional licenses can easily be purchased later on to increase that concurrency limit and added to instantly raise that that threshold.

    That covers the ability for VTCs to leverage the cloud video interoperability services in Azure, yet a RealConnect meeting must first be scheduled for that to happen.  To utilize RealConnect with these meetings scheduled by a Skype for Business Online user an additional Microsoft Office 365 license comes into play.  As covered earlier in this article any users homed in Skype for Business Online need to be running Office 2016 C2R in order to generate the required meeting information for VTCs to join, and the way that information is populated in the invitation is by programmatically checking the scheduling user’s current Office 365 licensing and looking for an assigned Skype Meeting Video Interop for Skype for Business add-in license, highlighted below.


    This secondary Microsoft license ensures that the scheduling user’s own meetings can be joined by any VTC by including the video interoperability-specific details in the invite.  Enough of these licenses will be provided to allow all SfB Online users to be assigned one so that every user’s scheduled Skype Meetings will include the required meeting information for any VTCs to either dial in manually or configured VTCs to leverage One Touch Dial to connect to the meeting.  In this example although only 20 concurrency licenses may have been purchased this customer would still receive 4000 user licenses to cover all potential SfB Online users.

    Remember that while these Skype for Business add-in licenses are only applicable to Skype for Business Online users enough can be provided to address any Skype for Business Server users which will eventually be migrated to the cloud.  In the example above it could assumed that this environment may be using a Skype for Business Hybrid deployment and have to dat only migrated 264 users to Skype for Business Online while the remaining 3,736 users are still homed on Skype for Business Server.  As they are migrated to the cloud they can be assigned one of those available licenses and continue to leverage RealConnect for their Skype meetings which are now hosted online.

    Q1 2018 Skype and Teams UG Meetings

    February 26, 2018 by · Leave a Comment 

    The next round of quarterly Skype and Teams Users Group meetings has been announced and scheduled starting this month.


    Latest News

    A year year brings a couple new national sponsors to the user group in AVST and Embrava.

    Event Details

    This quarter’s events will be conducted in our familiar two-session format:

    Session 1: Advanced Phone System Capabilities – In this session, we will cover the more advanced features and capabilities of Phone System, including updated Call Queues & Auto Attendants, Call Plan & Phone Number management, Number Porting procedures, custom Dial Plans & Calling Policies, & more.

    Session 2: Bots & Development Capabilities in Microsoft UC  – In this session, we will learn about working with Bots in Microsoft Teams, how Bots can be used, Telehealth Templates, & other emerging Development opportunities within the Office 365 UC realm.

    Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

    Western U.S.

    Central U.S.

    Southern U.S.

    Eastern U.S.

    For a full schedule of regional events the Skype and Teams Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

    Chicago Event

    Continuing the recent schedule of alternating locations each quarter places our Q1 event back downtown in the Aon Building. 

    Food will be ready at 5:30pm so come early if you can to spend time socializing with the group before the presentations begin at 6:00pm.

    Date Location Address
    Tuesday, March 20th         
    5:30PM – Food and Networking 
    6:00 PM – Presentation Kickoff
    Chicago Downtown Event Microsoft Technology Center         
    200 East Randolph Drive, Suite 300
    Chicago, IL 60601

    Polycom Group Series with Skype for Business Online

    December 11, 2017 by · 2 Comments 

    A past article covered several facets of registering and using a Polycom RealPresence Group Series video conferencing system with Skype for Business 2015 Server deployments. In that article it was mentioned that support for Skype for Business Online was imminent.

    That support arrived this past summer in the form of official Microsoft qualification of the Group Series platform for Skype for Business Online, as reflected on the Skype for Business Solutions Catalog.

    The guidance in the previous on-premises-focused article is basically no different whether the Group Series is registering to Skype for Business Server or Online.  Updating the firmware, enabling the required Options Key, most of the configuration, and validating the overall experience are the same.  That article should continue to be used to gain an in-depth understanding of the scenarios, where this shorter article will focus on the minor differences when registering a Group Series endpoint directly to Skype for Business Online.  It is recommended to read through the previous article first to gain the foundational understanding of using a Group Series with Skype for Business.


    The prerequisite listed in this section only apply to registration with Skype for Business Online.  Some details are the same when using the Group series with an on-premises Skype for Business 2015 Server deployment while others are different or unique to Office 365 registration (e.g. Microsoft licensing).


    When official qualification and support was attained back in June the minimum required firmware version for support was release 6.1.1.  As of the posting of this article the latest Group Series software release is currently up to 6.1.4, although the more recent releases have not gone through the same qualification program.  This does not indicate that the newer releases are not supported, only that not every minor release needs to be requalified.  Requalification will happen with future major updates; for example when 6.2 is eventually released that version will go through the Microsoft qualification process. The most impactful result of becoming an officially qualified release is that Microsoft will then post that specific version in the Skype for Business Online Device Update service, allowing any registered devices to automatically receive and apply the new firmware directly, just as qualified IP phones have supported for some time.  Other manual or programmatic update processes can still be used to apply the desired version of firmware even if that is not what the device update currently has published.

    The newer minor releases are typically recommended though as they include additional hotfixes as well as one important change which is explained in the previous article and in the official Polycom Release Notes for the 6.1.2 release.  With the original 6.1.1 release in order to successfully register the Group Series to a Skype for Business Online account there must be a paired RealPresence Touch Panel which is configured with the Skype UI enabled.  The Additional Settings section of the previous article covers this configuration. 

    But with 6.1.2 and later releases this is no longer a prerequisite as support was added for using the supplied remote control or when controlling the Group Series through third-party customized devices like Creston or AMX room control panels.  The preferred in-room experience which most closely matches the rest of the Skype for Business meeting room devices out there today though is still provided by using the RealPresence Touch Panel with the Skype UI enabled, so it is still recommended to go this route when possible.


    As with any device that is registering to Skype for Business Online, be it a phone or video system, a licensed Office 365 account is required.  This can be a standard Skype for Business user or a special Meeting Room account.  Generally it is best practice to use the latter which affords the registered device some unique capabilities and behaviors, but it is not a requirement.  This previous article focusing on Online Meeting Room Accounts covers in detail the different configuration options and guidance around each.

    On the Polycom side the only license that is required is the aforementioned Skype for Business Interoperability License Options Key which is covered in the previous Group Series article linked at the beginning of this page.  As explained in that article the license is not required to successfully register to Skype for Business, but without it no other protocol or codec support is enabled, thus there would be no ability for the Group Series to handle video calls, meetings, content sharing, etc.  This is critical information when troubleshooting call failures on a registered system.

    On the Microsoft side see this companion article which attempts to explain the nuances of the Office 365 licensing options and which would be ideal or at least sufficient for various use-cases.

    This example account has been assigned an Office 365 Enterprise E3 license.


    Expanding that E3 license shows all of the Office 365 services provided within it, including the critical Skype for Business Online plan.


    At this point the desired account is sufficient to attempt registering the Group Series to Office 365.

    SIP Registration

    The detailed registration configuration steps outlined in the previous article are all applicable here.  The same general concepts are unchanged including best practices on username formats and guidance on using automatic configurations.

    The main difference is how to manually configure the target registration servers.  With on-premises deployments these are server names which would need to be known to an administrator or manually discovered.  But with the single world-wide Office 365 offering of Skype for Business Online there is a defined hostnames for the different services which can always be used in the event that autodiscovery is not working for some reason.

    Automatic Discovery

    The preferred method of SIP registration is to simply leverage autodiscovery as outlined in the previous article.  In most cases this will be sufficient to successfully locate and register to the online services, following the same guidance as provided for use with Skype for Business Server.

    Manual Configuration

    In the event that the automatic process does not result in a successful registration than the first step is to take the automatic discovery process out of the equation.  This can easily be done by hardcoding the target server in the configuration.  But what is this target’s name?

    This Microsoft support article details the various DNS records published for Skype for Business Online which provide registration, federation, and discovery services.  The DNS record information shown in the following table was taken from that article.

    Type Service Protocol Host Name Destination
    SRV _sip _tls <DomainName> sipdir.online.lync.com
    SRV _sipfederationtls _tcp <DomainName> sipfed.online.lync.com
    CNAME sip.<DomainName> sipdir.online.lync.com
    CNAME lyncdiscover.<DomainName> webdir.online.lync.com

    It is also very easy to query for these defined destination hostnames for Skype for Business Online tenants.

    • Using Windows PowerShell or a Command Prompt issue the following nslookup command with the desired domain name of the Office 365 tenant (e.g. jdskype.net) to resolve the published Service Locater (SRV) record.

    nslookup -q=srv _sip._tls.jdskype.net


    • Also issue this nslookup command with the desired domain name of the Office 365 tenant (e.g. jdskype.net) to resolve the published Alias (CNAME) record.

    nslookup sip.jdskype.net


    In both instances the same Fully Qualified Domain Name (FQDN) of sipdir.online.lync.com was returned.  It would be a good idea to simply just commit this FQDN to memory at this point as this single hostname can be used to register any SIP client or device directly to Skype for Business Online from anywhere in the world.

    Understand that this process should result in the above names for pure online-only tenants, while any hybrid deployments of Skype for Business should have been configured by their administrators to properly point to the on-premises service (e.g. Edge and Reverse Proxy).  In hybrid deployments these on-premises servers will then redirect any client registration attempts for accounts which are actually homed online.  For this reason it becomes important to understand how to manually, and forcefully, point a device directly to Skype for Business Online using the above hardcoded hostnames.  Otherwise when troubleshooting a registration failure it may not be possible to resolve the issue if the device is unable to negotiate the discovery process and/or redirection correctly.  Pointing the device directly to the cloud registration servers, even in a Hybrid deployment, will often result in a successful registration by bypassing any on-premises components.  Obviously this requires that the SfB account that the device is registering as is hosted online, which is the entire point of this article.

    Armed with this newly discovered information it is now time to enter the manual configuration and attempt registration.

    • Using the Group Series web management interface navigate to the Admin Settings > Network > IP Network menu, or simply search for “sip” and then select the SIP result.

    • Expand the SIP section click Enable SIP if it is not already enabled.

    • Change the SIP Server Configuration to Specify.

    • Set the Transport Protocol to TLS.

    • In the Sign-In Address field enter the SIP URI of the desired Lync or Skype for Business user account (e.g. gs500@jdskype.net). 

    • In the User Name field enter the User Principal Name (UPN) of the same account (e.g. gs500@jdskype.net).  In online-only tenants the user account’s SIP URI and UPN should be the same, but that may not be the case if the AD accounts where originally migrated .  (The legacy NetBIOS format of “DOMAIN\username” cannot be used with Office 365 accounts.)

    • Click the Password box to expand the Enter Password and Confirm Password fields.  Enter the user account’s password in each field.

      • In the Registrar Server field enter the string "sipdir.online.lync.com:443".  It is important to include the :443 suffix after the hostname as the Group Series will attempt TLS registration by default to port 5061 which would not be correct.  The Skype for Business Online server will only accept registration attempts destined for port 443.

      • The Proxy Server field should be left blank.  Registration can still work if the exact same value as the Registrar Server field is entered but this is redundant and normally should not be populated.  Unlike some standard SIP platforms the Microsoft SIP platform contains the proxy and registrar services in the same server roles.  (This field is not used for pointing to an outbound web proxy server, that is configured in a different section.)

    • Set the Registrar Server Type to Microsoft.       
    • Finally click Save to attempt to sign in.


    Address Book Registration

    Nothing here is any different than when dealing with Skype for Business Server, so the directions in the previous article are applicable here as well.

    • Set the Server Type to Microsoft.

    • In the Domain Name field enter the SIP domain for the the currently registered user’s environment (e.g. jdskype.net).

    The Registration Status will  initially continue to be displayed as “Registration Failed” but within 30 seconds or less the status should update to Registered.

    Calendar Registration

    In the other article it was stated that the Group Series has supported Exchange Online mailboxes for some time now, so again nothing new to see here.  Same guidance and instructions as was previously covered; default to using the auto discovery process first and if that fails then the following configuration example outlines the manual settings.

    This Microsoft support article outlines the various FQDNs for Exchange Online services, with the important hostname being outlook.office365.com which is used to access Exchange Web Services online by the Group Series.


    Media Port Range Behavior on Polycom Devices

    November 8, 2017 by · 5 Comments 

    An older, now partially outdated article covered in depth how to configure Quality of Service (QoS) on Polycom VVX phones for use with Lync Server.  Much of the guidance in that article is still applicable and even extends to newer Trio conference phones as well as the newer Skype for Business Server and Online platforms.

    What has changed since that article was published was how the Polycom UCS-based devices leverage defined media port ranges.  Previously this had to be handled out-of-band by either manually configuring the phones or using a provisioning server to perform the configuration in bulk.  That configuration required discovering the static media ports ranges defined in the Lync/SfB server platform and then duplicating as close as possible the same configuration on the phones. That manual configuration is typically no longer necessary as more recent firmware releases for the VVX and Trio have added support for picking up and configuring the media port ranges automatically.  During registration to Lync or Skype for Business any defined ranges which have always been passed in-band in the client provisioning information are now properly parsed and applied to the phone configuration.

    But there was still an important limitation to that behavior as while the phones could automatically use that information they could not use all of it.  At the time the firmware did not yet support defining separate source port ranges for audio, video, and content sharing streams.  As the vast majority of these devices in the field are VVX IP phones which only support audio communications with Lync/SfB then this gap was not a major issue though.  The media port range for audio ports defined in an environment was correctly utilized by the phones without additional configuration and thus any QoS management of that traffic worked identically between SfB clients and VVX phones.

    Yet with the growth of Trio phone deployments with the Visual+ component which added video and content sharing streams meant this gap needed to be addressed.  In later firmware releases this was in fact dealt with by introducing a new set of parameters which allowed the phones to define source listening ports in up to three different ranges to separate the audio, video, and content sharing media channels.  Additionally other compatible video conferencing platforms like the Polycom Group Series also need to be factored in to these environments.  This article will review the behavior and any configuration (if applicable) for each of these family of devices.

    With the server platforms if no static media port ranges have been defined then the phones will operate with in their factory default port ranges.  All devices registering directly to Skype for Business Online will be configured with the same globally-defined client port ranges that Microsoft controls for online clients.  Understand that although Microsoft has recently simplified the required port ranges for Skype for Business online clients this does not change the client’s listening port configuration.  Those changes are focused on outbound media connections from internal clients to Microsoft’s data centers.  Yet for environments which may include firewalls separating even some internal networks then peer-to-peer media communications between these clients still needs to be allowed for no differently than has always been the case in Office Communicator, Lync, and Skype for Business.

    As mentioned above server platforms can range from no configuration to any variety of custom port ranges, while the Office 365 offering uses a very specific set of defined port ranges.  The examples shown throughout this article will leverage Skype for Business Online which currently assigns the following dedicated port ranges for each media type to registered clients and devices. 

    Media Type Port Range
    Port Range
    Audio 50000 50019
    Video 50020 50039
    Application Sharing 50040 50059

    The configuration above is provided in the <provisionGroup name="ServerConfiguration" > section of provisioning data sent to a registering client.  This following details can be captured by a SIP trace run during the SfB client registration process or by looking through Lync-UccApi-*.UccApilog files found in the workstation’s Tracing folder.





    As of the recent September release of 5.5.2 the Trio will both utilize the in-band port configuration received during SfB registration and also takes advantage of new parameters specifically for content sharing traffic so that it is no longer sharing the same port range with video streams as was the case in earlier releases.

    There are a few ways to validate the current configuration of a Trio that has already been registered to a Lync or Skype for Business platform.  As stated earlier the devices used in this article are registered to Skype for Business Online so the media port configuration seen will match the table shown above.  The simplest way to see the configuration is to utilize the phone’s embedded web management UI to export the current configuration to a text file and then search for the specific parameters which store this information.

    Enable Web Management UI

    To perform the steps below it may be required to first enable the web UI on the device as it would have been disabled by default when set to the Skype for Business base profile.

    • Using the Trio touch interface navigate to the Settings > Advanced > Administration Settings > Web Server Configuration menu.  (When prompted for a password the default is ‘456‘.)

    • Turn on the Web Server setting and then select the desired Web Config Mode (e.g. HTTP/HTTPS).

    • Tap the Back arrow and select Save Config.  And changes applied above will trigger an immediate reboot of the phone.

    Export Configuration

    Once the phone has rebooted the web UI can be used to export the current configuration to a text file.

    • Using the Trio touch interface tap the hamburger menu in the upper left corner to easily find the device’s current IP address.

    • Using a web browser connect to the device IP address using either http or https (whichever options were enabled in the previous steps) and enter the same Admin password as before (default is ‘456‘).

    • Browse to the Utilities > Import & Export Configuration menu and then expand the Export Configuration section.

    • Leave the default selection of All Configuration (except Device Settings) and then click the Export button.


    • Save and open the downloaded Export_all.cfg file in any text editor, or an XML editor of choice if available.  Scan through the results or search for the string "port.rtp.lync" to locate the desired parameters.


    As seen above the Trio utilizes the following six parameters to store the configuration provisioned by the registrar.





    Query Configuration

    Another way to locate this information is by connecting to the phone via Telnet and looking up the parameters by name to see not only the provisioned values but also the device’s factory default values.  This is a more advanced process and may be of interest to some readers for future reference and requires prior knowledge of the specific parameter names.

    The phone’s embedded Telnet server is disabled by default so it must be enabled first by importing a configuration parameter into the phone.  Obviously this process also requires that the web management UI is enabled as shown above.  Also be aware that enabling the Telnet server on the phone is a static setting and will stay enabled though reboots, requiring either a factory reset or being manually turned back off.

    • Create a new text file named "enable_telnet.cfg" in any text editor and paste the following text into a single line in the file.

    <telnet diags.telnetd.enabled="1"></telnet>


    • Using the web UI browse to the Utilities > Import & Export Configuration menu and then click the Choose File button under the Import Configuration section.

    • Browse for the newly created enable_telnet.cfg file and then select Import.  The results should be reported as "Configuration file imported successfully".


    • Connect to the device IP address using any Telnet client over port 1023. 

    telnet 1023


    • When prompted for credentials enter the default admin username of ‘Polycom‘ and password of ‘456‘.

    • At the Admin> prompt enter the command cfgParamName followed by the name of valid configuration parameter. For example "cfgParamName reg.1.address" would return the SIP address of the currently registered user.

    cfgParamName reg.1.address


    In the results shown above there are several values returned for a specific parameter.  Most importantly valDefault shows the factory default setting for any parameter, which would be null for this type of parameter.  The valWeb value is what was used to store the registered user’s SIP address and this was because the phone was originally registered using the Skype for Business SignIn option in the web UI.

    • Using the cfgParamName command the various media port parameters can be queried to find both the default and current settings.

    cfgParamName tcpIpApp.port.rtp.lync.audioPortRangeStart
    cfgParamName tcpIpApp.port.rtp.lync.audioPortRangeEnd

    cfgParamName tcpIpApp.port.rtp.lync.videoPortRangeStart
    cfgParamName tcpIpApp.port.rtp.lync.videoPortRangeEnd

    cfgParamName tcpIpApp.port.rtp.lync.contentPortRangeStart
    cfgParamName tcpIpApp.port.rtp.lync.contentPortRangeEnd


    Notice that while the factory default values shown above as still stored in valDefault the custom values for these parameters are instead stored in valPpsSip which indicates the custom settings originally came from a SIP provisioning process; in this case during registration to SfB Online.

    As mentioned earlier it may be desired to disable the Telnet server on the phone once completed.  Follow these steps to reverse that configuration.

    • Create a new text file named "disable_telnet.cfg" in any text editor and paste the following text into a single line in the file.

    <telnet diags.telnetd.enabled="0"></telnet>


    • Import this file into the phone using the same process shown earlier in this section.


    To validate that the configuration discovered above in the various processes is actually functional the following Wireshark traces were captured during a peer to peer call between a Skype for Business 2016 Windows client and the Trio 8800 with video enabled and the SfB client actively sharing its desktop to the Trio.  Both endpoints were located on the same internal network so any media streams traveled directly between each host’s local IP.  Traffic flows shown below are all from the SfB client ( to the Trio ( as the port configuration this article is focused on is applicable to how the Trio opens up listening ports intended for inbound connections from the other endpoint.

    The audio stream seen below was sent from the SfB client over UDP to port 50004 on the Trio which is in-between 50000 ad 50019.


    Meanwhile the video stream from the SfB client was directly to UDP 50038 on Trio, correctly falling within the 50020-50039 range.


    Lastly the the shared desktop of the SfB client was sent to the Trio over TCP to port 50049 which is also within the new content sharing range of 50040-50059.  Note that the application sharing session was utilizing Remote Desktop Protocol (RDP) which only supports TCP transmission.



    As both the VVX and Trio device families are based on the same core Unified Communications Software (UCS) platform then the behavior here is the same.  Any configuration, as explained above, is no longer required as it is all automatic now when registering to Lync Server, Skype for Business Server, or even Skype for Business Online.  That being said the actual configuration utilizes slightly different parameters based on the fact that the VVX line does not support content sharing as it is only a phone.  While video calling is not yet supported with Skype for Business clients it is functional directly between SfB-registered VVX phones in peer calls only, thus correct utilization of the video port range is still important.

    Using the same instructions shown above in the Trio section the configuration can be exported or queried on the VVX phone.  Note that the standard Telnet port of 23 is used on the VVX phone, where the Trio uses port 1023 as shown in the examples above.

    Using the configuration export process the following parameters were found on the VVX phone registered to the same SfB Online tenant. 



    Note that the parameter names here are different than on the Trio.  Firstly the Trio parameters include the additional *.lync.* text in the names and secondly the audio port parameters on the VVX are entitled ‘media‘ instead of ‘audio‘.

    Using the Telnet process the two parameter sets query results are as follows:

    cfgParamName tcpIpApp.port.rtp.mediaPortRangeStart
    cfgParamName tcpIpApp.port.rtp.mediaPortRangeEnd

    cfgParamName tcpIpApp.port.rtp.videoPortRangeStart
    cfgParamName tcpIpApp.port.rtp.videoPortRangeEnd


    This time the valDefault values differ from what was seen on the Trio, indicating different factory default port ranges between the phone families, yet the active port ranges have been provisioned correctly as seen in valPpsSip.

    Outside of these configuration differences the registered VVX phone will now function identically a Trio registered to the same environment for audio (and video) streams.

    The following table can be used as a quick reference for the defined UCS parameters between VVX and Trio phones.

    Media Type Trio VVX
    Audio tcpIpApp.port.rtp.lync.audioPortRangeStart
    Video tcpIpApp.port.rtp.lync.videoPortRangeStart
    Application Sharing tcpIpApp.port.rtp.lync.contentPortRangeStart

    Group Series

    The Polycom Group Series platform does not currently behave like the phones.  While the Group Series does support native registration to Lync Server 2013, Skype for Business Server 2015, and Skype for Business Online platforms it does not utilize the in-band provisioning settings for media port ranges.  Additionally the Group does not currently separate audio, video, and content streams into different port ranges, although it does allow for some limited customization to approximate the desired configuration.

    An allowed custom configuration supports defining a starting port for two separate media port ranges for TCP and UDP traffic, which can overlap if desired.  The port range for TCP traffic is hardcoded to 11 contiguous ports with 61 contiguous ports allowed for UDP traffic.  As the Group currently supports an array of audio and video protocols with Lync/SfB then the audio and video communications will typically be over UDP, unless negotiation fails and the fallback to TCP process is used for these streams.  Also as the Group currently supports only the RDP protocol for content sharing then all supported inbound content sharing streams will arrive over TCP.

    This leaves a dilemma for the administrator to address. While the smaller TCP port range can easily be assigned within the larger 20 port ranges typically used in Skype for Business the much larger UDP range will extend beyond that range and potentially up into other ranges.  For example if the Group is configured with a starting port of 50000 it will automatically set 50061 as the ending port.  This means that inbound media streams from SfB clients could potentially travel over any of the defined 50000-50059 range used in Skype for Business Online, resulting in possibilities like video traffic landing in the audio queue, or vice versa.

    Now for SfB Online this may not actually be a problem as all meeting traffic will be destined for the Internet and thus attempting to place that traffic in QoS queues internally will more or less be moot once that traffic hits the Internet.  But for Server deployments where the majority of media streams are staying on-premises then it is suggested to look at the overall QoS and media port configuration and potentially adjust the ranges to work better with the current Group Series behavior.  Or it may be desired to treat these dedicated conference rooms differently and thus place traffic destined for those devices in different ranges and queues altogether.

    Manual Configuration

    The example configuration used here would put the TCP ports up in the Application Sharing range based on the assumption that all inbound TCP media will be RDP traffic and UDP will successfully be leveraged for all audio and video traffic.  But because the UDP ports could contain audio or video then it may be ideal to select a different media port range that is not in use by SfB and then configure the additional range for QoS as desired.

    • Connect to the IP address of the Group Series endpoint using a web browser.

    • Navigate to the Admin Settings > Network > IP Network menu and then expand the Firewall section.

    • Enable the Fixed Ports setting.

    • Set the desired starting port in TCP Ports (e.g. 50000) and the desired starting port in UDP Ports (e.g. 49938).  (Starting ports must be even integers.)

    • Click Save to apply the configuration changes.

    Fixed Ports = On
    TCP Ports = 50040-50051
    UDP Ports = 49938-49999


    This example configuration will put all UDP media outside the current SfB ranges, creating a new range of 49938-49999 which can be assigned to whatever QoS queue is desired.

    Note that this only impact inbound media sessions to the Group Series.  outbound media sessions will travel over the proper media port ranges as the far-end (clients and servers) will be advertising their listening ports correctly within the SfB configuration.


    When capturing the traffic between an SfB client ( and a Group Series ( with both cameras turned of it is easy to isolate the audio traffic.  In the capture below the audio traffic sent from the SfB client to the Group Series arrives on port 49944 via UDP.  This port falls within the defined UDP range above of 49938-49999.


    By muting the microphone and turning on the outbound video from the SfB client the majority of the capture will now show the video traffic.  the following series of packets show UDP traffic from the SfB client destined to the Group Series over port 49948.  This port also falls within the same defined UDP range above of 49938-49999.  On the surface there is no definitive way to determine this video traffic is any different than the previous audio traffic, other than possibly using the packet size as an indicator (224 vs. 1193).


    Lastly a desktop sharing session was started from the SfB client after stopping the video and muting the microphone.  The most active results at this point were TCP packets sent from the client to the Group Series destined for port 50043.  This port is in the preferred range for application sharing traffic of 50040-50051 as previously defined for TCP traffic.


    Note that throughout these captures the SfB client is still correctly sending from and receiving to the port ranges defined in Skype for Business.

    Q4 2017 Skype and Teams UG Meetings

    November 4, 2017 by · Leave a Comment 

    The next round of quarterly Skype and Teams Users Group meetings has been announced and scheduled starting this month.


    Latest News

    Please welcome members to our newest group in Tampa Bay, Florida.  Also note that the group has expanded the name to include Teams which will clearly be an integrate part of Microsoft’s UV story after the resent announcements at the Ignite conference.

    Event Details

    This quarter’s events will be conducted in our familiar two-session format:

    Session 1: Microsoft Ignite Recap – In this session, we will get you up to speed on all the important announcements that occurred at Microsoft Ignite 2017.  This will include announcements from all our sponsors and Microsoft.  If you missed anything, this is your chance to catch up!

    Session 2: The Future of Intelligent Communication – Learn about Microsoft’s vision for Intelligent Communications and how we will bring together the learnings and experiences of SFB communications into Teams Collaborations.

    Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

    Western U.S.

    Central U.S.

    Southern U.S.

    Eastern U.S.

    For a full schedule of regional events the Skype and Teams Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

    Chicago Event

    Our local member Anthony Caragol will be assuming host responsibilities for the suburban Chicago location this quarter.  We will continue the current plan of alternating locations each quarter but are setting the stage to potentially host events next year in both locations to better serve the greater Chicagoland region.

    Food will be ready at 5:30pm so come early if you can to spend time socializing with the group before the presentations begin at 6:00pm.

    Date Location Address
    Thursday, November 30th         
    5:30PM – Food and Networking 
    6:00 PM – Presentation Kickoff
    Chicago Suburban Event Microsoft Midwest District Office
    3025 Highland Pkwy., Suite 300
    Downers Grove, IL 6051

    Understanding Office 365 Licensing for Meeting Devices

    August 21, 2017 by · 12 Comments 

    The purpose of this article is to explain what type of Office 365 licenses can or should be used with any of the various phones and meeting devices qualified by Microsoft for Skype for Business Online.  These products can natively register to Skype for Business Online using resource accounts which must be assigned the correct licensing.  This covers equipment like the many different IP Phones from five different partners or the several different Meeting Room platforms like the older Lync Room Systems, newer Skype Room Systems, or even the recently qualified Polycom Group Series to name a few.

    The guidance covered in this article is not necessarily applicable to desk phones which are assigned to a specific user, as those users would already have an assigned Office 365 license which applies to any client and devices they sign into with their own credentials.  It is the meeting room solutions and other similar shared resources like conference room phones or common area phones which utilize their own dedicated account which are the focus of this article.


    As with any device that is registering to Skype for Business Online, be it a phone or video system, a licensed Office 365 account is required.  This can be a standard Skype for Business user or a special Meeting Room account.  Generally it is a best practice to use the Meeting Room account which affords the registered device some unique capabilities and behaviors, but it is not a requirement.  This previous article focusing on Online Meeting Room Accounts covers in detail the different configuration options and guidance around each type.

    Once an account is created for the device then a valid Office 356 license needs to be allocated to it before it can be used to register a device.  Typically an empty meeting room might already have an Exchange Online Room Mailbox configured for it which incurs no cost and consumes no license in Office 365, but that is only for room reservation capabilities.  Once that meeting room is equipped with a dedicated Skype for Business device then a Skype for Business license must be assigned to that account, which is not free.

    This means that the devices need only to be concerned with the Skype for Business Online portion of licensing.  The Exchange Online portion of the device’s account is still only a Room Mailbox, so then there is no need for Exchange Online plans to be assigned.  That being said many of the Office 365 licensing plans already include Exchange Online licensing so unless dealing with a standalone plans this point is moot.

    Office 365 Plans

    For those unfamiliar with the various Office 365 licensing plans the following is a list of the current plans which provide Skype for Business Online services in them.  The items in red are the default recommended options in each class and the reasoning for each is explained below.

    Standalone Plans

    • Skype for Business Online Plan 1
    • Skype for Business Online Plan 2

    Business Plans

    • Business Essentials
    • Business Premium

    Enterprise Plans

    • Enterprise E1
    • Enterprise E3
    • Enterprise E5

    The absolute minimum Office 365 license required for a device would be a standalone Skype for Business Online Plan 1 license.  But that plan is not recommended based on its limitation of only being able to join other meetings and not create ad-hoc or scheduled meetings.  On the surface this may not seem like a problem as users would not be sending meeting invitations from device’s account, they create or schedule meetings using their own Skype for Business account.  But what about when a user walks into a conference room that is not booked and simply wants to start an ad-hoc meeting?  Or what about adding new participants into an active meeting from the device itself?  Scenarios like those are covered under the Meeting Scheduler capabilities which are included in the standalone Skype for Business Online Plan 2 tier, hence this being the recommended minimum Office 365 license. 

    But most Office 365 subscribers today are typically not using the a la carte style standalone plans and are instead leveraging a Business or Enterprise plan.  All of the Business and Enterprise plans listed above automatically include Skype for Business Online Plan 2 in them, as illustrated by the following example showing an Enterprise E3 license expanded to list some of the includes services.


    Note the Skype for Business Online (Plan 2) option listed above.  Because all Business and Enterprise plans with Skype for Business leverage Plan 2 capabilities then any of these are sufficient to support joining scheduled meeting and creating ad-hoc meetings as explained earlier. This also illustrates why it is usually incorrect to assign a redundant standalone Skype for Business Online Plan license to an account which is already assigned one of the supported Business or Enterprise plans.

    Now, when only a handful of shared devices are deployed in an environment it can be less administrative work to simply assign licenses to these accounts which are already available in the tenant.  Yet from a a cost-savings standpoint it can be overkill to assign a license which may include many additional features that the device is not capable of leveraging and never would be.

    For example some of the plans listed above include licenses for Office applications which device do not need.  The reason that Business Essentials is recommended over Business Premium is that the more costly Premium license allows the account to install the Office suite software on multiple workstations, but a device-only account would never be used for that.  This same reasoning is why Enterprise E1 is generically recommended over the more costly E3 and E5 licenses as, like Business Essentials, it does not include the Office suite of applications.

    That being said there are other arguments for using Enterprise licensing due to bundled add-on licenses.  In fact there are scenarios where even Business licenses are not valid and would need to be transitioned to Enterprise licenses.  These reasons will be explored in the next section.

    Skype for Business Add-On Licenses

    Some of the following value-add licensing options can provide additional capabilities to the solution depending on what the device is and needs to do.

    Currently the available add-on licenses for Skype for Business Online are:

      • PSTN Conferencing: The Dial-In Conferencing services for joining meetings from a PSTN phone.
      • Cloud PBX: Traditional PBX functionality and support for integration with a traditional PBX system.
      • PSTN Calling: PSTN connectivity hosted directly by Microsoft Office 365.

    Here is one area where Microsoft does have some official guidance available online when dealing with licensing Skype for Business devices.  This Office support article includes both details on the various Skype for Business add-on licenses as well as how they are applicable to the newer Skype Room System v2 platform.  Taking that one step further the various Skype Room System scenarios covered in the article can be extrapolated to any device.  Again this is not specific to a single conferencing product, any meeting device follows the same requirement and guidance.

    That article includes a table which granularly lists various in-room scenarios and which licenses are required to perform those specific tasks.  As already mentioned there are differences between joining meetings and creating meetings from within the conference room itself.  The information on that support article may be a bit confusing to understand at first glance so the important information has been reworded for simplicity’s sake in the table below.

    Standalone Business Enterprise
    Join a
    Skype for Business Online Plan 1 Business Essentials
    Business Premium
    Enterprise E1/E3/E5
    Initiate an
    Skype for Business Online Plan 2 Business Essentials
    Business Premium
    Enterprise E1/E3/E5
    Invite PSTN
    via dial-out
    Skype for Business Online Plan 2
    + PSTN Conferencing
    N/A Enterprise E1/E3 + PSTN Conferencing
    Enterprise E5
    Assign an
    Enterprise Voice
    phone number
    to the device
    Skype for Business Online Plan 2
    + Cloud PBX
    + PSTN Calling
    N/A Enterprise E1/E3 +Cloud PBX + PSTN Calling
    Enterprise E5 + PSTN Calling

    The table above outlines how, for example, a video conferencing system may only need to be licensed for the basic ability to join meetings, but if it or a conference phone needs to also support the typical use-cases of placing PSTN calls or adding PSTN participants into a live Skype for Business meeting then additional licensing may be required.

    • The first two scenarios are already covered in the Meeting Scheduling capabilities included in any plan equivalent to Skype for Business Online Plan 2.  This underscores why using Plan 1 is not ideal as the second scenario is a common task performed in Skype for Business meetings.

    • The third scenario introduces the need for a PSTN participants to be invited on-demand to the meeting.  As mentioned earlier these meetings are typically scheduled by regular users who may already be granted a PSTN Conferencing licensing and the PSTN dial-in conferencing information would have been included in the invitation email.  A PSTN caller can use that information to manually dial into a conference as usual.  But this third scenario in the table above is something different, it is the ability for the someone in a conference room that is already connected to a meeting to use the device itself to manually add a new participant to the meeting and then use a PSTN phone number to call out to that desired attendee.  This action is performed on the device but the call comes from the Skype for Business server (not the meeting room device) and the callee is brought directly into the meeting when the answering on their PSTN phone.  Assigning a PSTN Conferencing add-on license to a supported plan or using an Enterprise E5 license will provide this capability.

    • The fourth scenario is not related to Skype for Business meetings at all.  This is simply the ability to assigned a PSTN phone number directly to the device so that it can place and receive peer-to-peer calls to and from the PSTN.  Including Cloud PBX is the step, followed by either getting a PSTN Calling plan directly from Microsoft or connecting to a traditional PBX with PSTN connectivity. 

    Important details to further understand the guidance in this table are that (1) the Enterprise E5 plan already includes the PSTN Conferencing and Cloud PBX licenses and (2) that while all three add-on licenses can be used with Standalone and Enterprise plans they cannot be used with any of the Business plans.

    So, if an account with a Business plan needs to leverage some Skype for Business PSTN features there are two potential paths. The recommended option is to simply transition to an Enterprise license for that account.  An alternative might be to instead purchase a standalone Skype for Business Online Plan 2 license and assign it to a account which already has Business Essentials or Premium, further allowing the additional of the add-on licenses.  But that is redundant, as pointed out earlier in this article, as well as more expensive.  For example a Business Essentials license and a Skype for Business Online Plan 2 licenses together cost more than the single Enterprise E1 license does.


    Please understand that Microsoft licensing can be very fluid and change over time so the comments in this article are not indicative of any official support statements from Microsoft or any partners.  The information is simply guidance meant to assist the community with successfully navigating what can be a confusing topic so that meeting devices like IP phones or video conferencing systems can be properly deployed.  As these comments are based on my own understanding of the topic gathered from navigating several different sources of information then some or all of this may be at some point rendered inaccurate or invalid.

    Q3 2017 SkypeUG Meetings

    August 10, 2017 by · Leave a Comment 

    The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.


    Latest News

    Please welcome members to our newest group in Spokane, Washington.

    Event Details

    This quarter’s events will be conducted in our familiar two-session format:

    The first session will cover Microsoft Teams with an In-Depth Demonstration (Chat, A/V, & Meetings). Our second session will focus on Hybrid Architectures & Related Migration Strategies.  We’ll also have a preview of Microsoft Ignite.

    Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

    Western U.S.

    Central U.S.

    Southern U.S.

    Eastern U.S.

    For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..

    Chicago Event

    As usual I will be hosting the Chicago event which will be held in downtown Microsoft office this quarter.  We will continue with the current plan to alternate locations each quarter between the downtown and suburban Microsoft offices.

    Food will be ready at 5:30pm so come early if you can to spend time socializing with the group before the presentations begin at 6:00pm.

    Date Location Address
    Thursday,August 31st         
    5:30PM – Food and Networking 
    6:00 PM – Presentation Kickoff
    Chicago Users Group Microsoft Technology Center
    200 East Randolph Drive, Suite 200
    Chicago, Illinois, 60601

    Polycom UCS 5.6 for VVX Phones

    July 31, 2017 by · 49 Comments 

    The latest release of the Polycom VVX 5.6 UCS firmware is now available for Lync and Skype for Business (SfB) environments. This release includes some minor enhancements alongside a few major changes in look and behavior.

    For additional assistance with updating phones the following articles are provided as references.

    • Perform a Factory Reset – This is an optional, but recommended step when working with individual test devices for validating new firmware in an established deployment.

    • Deploy Software – Once testing is complete then this firmware can be added to the Lync or Skype for Business Device Update service for on-premises deployments.

    • Online Updates – For Skype for Business Online customers this update automatically be published once it has passed qualification.  Use this article to control this behavior if automatic updates are not desired.

    Upgrading a Phone

    This section will cover the basic steps to upgrade a single phone using the Polycom-hosted public server to directly download and apply the firmware to the phone.  In order to perform this process the phone’s internal web server must be enabled.  Depending on the selected Base Profile the web server may need to be manually enabled.

    Set Base Profile

    As explained in many earlier VVX articles the phone must be set to the proper Base Profile when registering to various SIP platforms.  Depending on the original purchasing SKU and/or current status of the phone it will be set to one of two options by default: Generic or Lync.  (Note that “Lync” base profile was renamed to “Skype” in version 5.5.1, but they function the same.)  When a VVX phone is set to Generic then the Web Configuration Utility will be enabled by default, but as this phone is or will be used with Lync/SfB environments it is best to set or confirm this parameter before doing anything else.

    • From any screen simply depress and hold the the following Multiple Key Combo (MKC) of: 1, 4, 9.

    • When prompted after 3 seconds enter the Admin password. (The default is “456”).

    • If the current value is set to Generic then select Skype and the phone will immediately reboot.  If Skype was already selected then simply hit the Home button to exit the menu.


    Enable Web Configuration Utility

    Back when UCS 5.3 was released a new default behavior was defined for the Lync base profile which automatically disabled the embedded web server.  This can be re-enabled on the VVX phone for testing or administration purposes if so desired.  To perform many of the steps in this article it must be enabled now.

    • Press the Home key and navigate to the following menu: Settings > Advanced > Administration Settings > Web Server Configuration.

    • If not already configured then the Web Server parameter to Enabled and Web Config Mode to HTTP/HTTPS.  (If a secure connection is required then set this to HTTPS Only).


    • Select the back arrow and choose Save Config to apply the changes and reboot the phone.

    • After the phone has rebooted press and hold (for 3 seconds) the following keys: 1, 4, 7.  This handy MKC brings up the Phone Details menu which can be used to quickly find useful information like the device’s assigned IP address or current firmware version.


    • Using a web browser connect to the IP address of the phone. (e.g.

    • Enter the Admin password (default is “456”) and verify that the Home page successfully loads.


    Update Firmware

    This phone must have access to the Internet in order to connect to the public hosted Polycom update server and perform the update described in this section.

    • Using the Web Configuration Utility browse to the Utilities > Software Upgrade menu and make sure that Polycom Hosted Server is selected as the Server Type.

    • Click Check for Updates which should be followed by a response of “Successfully fetched available software from the Polycom Hosted server.”

    • Select the desired firmware version number (e.g. and then click Install.  The currently installed version will be displayed in blue with older versions in red and newer versions in green.


    • Confirm the action to reboot the phone and trigger the update.  Once the phone completes the update process it will return to whatever registration state it was in before the update. 

    The following sections outline any Skype for Business related enhancements from previous firmware versions which may change the phone’s behavior or user experience.

    Updated User Interface

    While the UCS interface was just updated on some phone models in the previous 5.5.1 release there has been additional user interface customization within the Skype Base Profile to fall even more in-line with overall Skype for Business clients and devices interfaces.  Where the previous version added a more Skype-like look to the VVX 5xx/6xx models this newer version goes one step further by adopting a darker theme used on the latest native Skype for Business devices like Skype Room System and the Polycom Trio,



    Unlike the previous release this updated interface is now also applicable to the VVX 4xx models.

    image    image

    Dial Plan Normalization

    The topic of normalizing dial strings in UCS has historically been a complicated subject.  Way back in the original 4.x software release attempts were made to perform client-side normalization by downloading and applying the various normalization patterns and rules provided by the registered Lync Server.  This proved to be problematic due to the different ways that Lync and UCS handled Regular Expression (RegEx) strings.  On one side UCS did not at that time properly handle all characters allowed in standard RegEx patterns, and on the other hand several Lync deployments were found using non-standard patterns. 

    The approach several years ago was to change the default behavior of the phone to leverage server-side normalization by simply sending an unnormalized dial string directly to the server as-dialed.  This resolved most issues but was a trade-off as it limited some other capabilities.  The ability to control the normalization behavior has long been available by modifying the value of the UCS configuration parameter reg.1.applyServerDigitMapLocally which has held different default values over time.

    As of UCS 5.6 extended support for RegEx characters and patterns has been introduced and, when in Skype profile, this parameter has once again been enabled by default to reflect the updated recommendation of using client-side normalization with VVX phones.  If an existing deployment is already controlling this parameter via any of the different provisioning server models then obviously the phone behavior will not change.  But if the parameter has been left at the default setting and has not been modified through any other methods then the act of upgrading a phone running 5.5 or earlier firmware will alter its normalization behavior.  The phone will no longer send dial strings to the server and will instead perform client-side normalization.  Due to this change it is highly recommended to test 5.6 out on a single phone first to validate that all Lync or Skype for Business dial plans are properly handled by.

    In addition to the primary parameter discussed above some additional parameters have also been adjusted with default values.  The following table lists all of these which are applicable to dial plan normalization behavior.

    Parameter Name UCS 5.5.x UCS 5.6
    reg.1.applyServerDigitMapLocally 0 1
    dialplan.1.conflictMatchHandling 1 1
    dialplan.1.impossibleMatchHandling 3 3
    dialplan.1.applyToDirectoryDial 0 1
    dialplan.1.applyToCallListDial 1 0
    dialplan.1.applyToRemoteDialing 0 1
    dialplan.1.applyToPstnDialing 0 1
    dialplan.1.applyToForward 0 1

    New Configuration Parameters

    In addition to the changes above there are a few new parameters available for controlling new capabilities.  The dialplan.TranslationInAutoComp parameter allows for auto-completion results to be shown as dialing options when entering a string of digits. This functions when client-side normalization is enabled as the phone will be able to perform these normalization checks in real-time.

    The dialplan.NUM_REPLACE_1.Additionale911dialstrings parameter listed below adds support to VVX phones for handling multiple Emergency Services numbers as is supported by Skype for Business.  The configuration of additional numbers is performed server-side using the New-CsEmergencyNumber PowerShell cmdlet as covered on this TechNet page and then the phones will pull the additional configuration information down in-band during registration and store it in this new parameter.

    If client-side normalization is enabled as discussed above then the phone can now provide on-demand dialing options in real-time as digits are being entered into the phone.  To customize the timeout before call is automatically placed the dialplan.1.lyncDigitmap.timeOut parameter can be altered.

    Parameter Name Values Description
    dialplan.TranslationInAutoComp 1
    Controls whether to display translated string in Auto-Comp list. If enabled the translated number will be shown in the autocomplete list.
    dialplan.NUM_REPLACE_1.Additionale911dialstrings Used to configure additional emergency dial strings.
    dialplan.1.lyncDigitmap.timeOut 4
    Controls timeout value for static and off hook dialing scenarios.
    This parameter replaces the obsolete parameter dialplan.userDial.timeOut
    feature.webSignIn.enabled 1
    Allows an administrator to disable and hide the Web Sign-in option on the phone.*
    feature.webSecurityBanner.enabled 0

    Allows the additional of a security message banner to be displayed when accessing the phone’s web management user interface.*
    Used to store the text displayed as a security banner enabled in the parameter listed in the row above. Supports up to 2000 characters.*
    up.configureDeviceLockAuthList EmergencyNumberAtTop
    Controls the ordering of any configured Authorized and Emergency numbers displayed while the phone is locked.*
    up.hideSystemIpAddress Nowhere
    Can be used to hide the phone’s IP address from the various locations that it is displayed.*

    *Additional important parameters added in the previous 5.5.2 release have been included in this list for posterity.

    Device Lock

    When device locking is enabled the phones are now simpler to unlock than in previous versions.  The digits can immediately be typed into the phone and it will be read as the unlock code, not a phone number to dial as before.  To place a call while locked (if allowed) the phone icon can be selected, the speakerphone button pressed, or the handset lifted.

    Device locking behavior has also been improved when using Better Together over Ethernet (BToE) mode with the latest BToE 3.6 software release. The device will now only lock/unlock when the paired workstation is locked/unlocked, and not if the pairing status changes between active/inactive.

    Support for user photos has also been added to the lock screen in UCS alongside displaying the signed-in user’s name.  The currently registered user’s photo will be shown on the lock screen of VVX 5xx/6xx models, as shown below, but only if the photo is stored in Exchange or made available via HTTP.  Photos stored only in Active Directory are not accessible by UCS.


    Another new UCS feature (one which was not available on the older Lync Phone Edition devices) is the ability to unlock the phone directly with the signed-in user’s password.  In the event that a user forgets the device unlock PIN the phone can still be unlocked with the account’s password by tapping the "?" padlock icon above to access the screen shown below.


    Unlocking the phone with this method will immediately prompt the user to create a new device PIN.

    One Touch Meeting Join

    Borrowing functionality already brought to the Polycom Trio the VVX can now more easily join Lync or Skype for Business meeting available on the phone’s calendar which were sent by third parties.  In the past receiving an Outlook invitation for an online meeting from a user outside of the same Microsoft Exchange environment may not trigger the creation of a Join button, or may create the Join button but selecting it only dials the PSTN Conferencing dial-in number.  Typically only meetings sent by users in the same organization would allow this one touch join capability, but if filtering of Transport Neutral Encapsulation Format (TNEF) was manually disabled between email organizations then the Join button would function as desired.

    This one-off approach of enabling some level of customized SMTP formatting support between organizations is not scalable so several Skype for Business clients and devices have been shedding this requirement for the past year.  At this point most of all the clients and devices available are now able to properly parse the body of the invitation to find the meeting information and no longer rely on header information that may have been stripped from the email during transit.

    The example shown below is a Skype for Business meeting sent from an on-premises user in organization A to a Skype for Business Online user in organization B.  The Join button also still appears in the meeting reminder alert.



    Call Delegation

    A few call transfer improvements have been made to the workflow for delegate call handling in Boss/Admin scenarios.

    • The Resume soft key now is only displayed when a transferred call is returned to the delegate’s phone.

    • Putting the handset back into the cradle will no longer end the transferred call as it will be placed on hold.

    • If a transferred call is returned to a delegate then the delegate’s phone will play an alert tone.

    • If a transferred call is not answered the call is automatically resumed on the delegate’s phone.

    Busy Options

    In the Skype for Business Server July 2016 Cumulative Update Microsoft added additional calling features for handling inbound calls to clients which are already in a call.  These Busy Options are now supported by VVX which includes Busy on Busy and Voicemail on Busy.  As the two names indicate the configuration applied to the phone’s registered user account will trigger either a busy signal or an immediate forward to voice mail on incoming calls when the callee is already in a call or conference.

    Siren7 Codec Support

    As UCS does not support the RTAudio (RTA) codec then one scenario where there has historically been a bit of a gap is when a VVX phone joins a Lync or Skype for Business conference running on the AVMCU.  The standard Microsoft soft clients will typically leverage RTA as a means to provide wideband audio in a low-bandwidth capable codec, but the VVX phones will be default negotiate G.722.  While the audio quality of G.722 is excellent in these scenarios the average bandwidth utilization can be higher when compared with RTA.  (Note that the VVX 201 model does not support Siren7).

    By adding support for SIREN7 in UCS the phone’s now have another option available that Lync and Skype AVMCUs also support.  The codec is not enabled by default and must be added to the "In Use" codec priority list on the phone.  While this can be enabled using the standard provisioning parameters it is also very easy to enable using the phone’s embedded web browser.

    • Using the UCS web management interface browse to Settings > Codec Priorities

    • Under the Audio Codec Priority section In the Unused field highlight the Siren7 (16 kbps) entry and then add it to the In Use field on the right.  Move the new codec to the desired order for the intended results.  In this example the codec was moved to the top to perform testing but should not necessarily be placed that high in the order.


    • To test the change select Meet Now from the home screen on the VVX to start a new online meeting and establish an audio session with the Skype for Business server.

    • Press the Home key and then navigate to Settings > Status > Diagnostics > Media Statistics to display the following window and verify the codec currently in use.


    Set Logging Levels

    This feature was actually added back in the UCS 5.5.2 release.  It allows the phone to read the in-band logging level configuration defined in a Lync Server or Skype for Business Server on-premises deployment controlled by the Set-CsUCPhoneConfiguration cmdlet.  The cmdlet LoggingLevel parameter can be set to Off, Low, Medium, or High values.

    The following table lists the individual component logging values in the phone that are configured in conjunction with each of the four possible values in the server parameter.

    Feature Off Low Medium High
    ICE 4 4 0 0
    ICE 4 4 0 0
    TICKT 4 4 0 0
    SIP 4 4 2 0
    EC 4 4 2 2
    APP1 4 4 2 2
    SO 4 4 2 2
    AFE 5 5 2 2
    PPS 4 4 1 1
    PGUI 4 4 2 2
    BTOE 4 4 2 2
    ServiceAuth 2 2 2 2
    ServiceDevicePair 4 4 2 2
    ServiceProxy 4 2 2 2
    ServiceWad 2 2 2 2

    Discovering the Skype for Business Registrar

    May 30, 2017 by · 6 Comments 

    This brief article walks through some common steps which can be used to locate the Fully Qualified Domain Name (FQDN) of a Lync or Skype for Business registrar from either on-premises or online environments.  (This content was originally to be part of another article but was split into a separate post for easier reference.)

    This can be used as a reference for other articles on this site as a common step performed when troubleshooting device registrations to Skype for Business is to manually configure the endpoint.  To do this one must know the proper FQDN of the desired Microsoft SIP registrar.  Not all of the natively interoperable voice and video solutions supported with Lync and Skype for Business today leverage the newer Lyncdiscover web service model and may still need to automatically discover the SIP registrar directly.  The configuration that supports these is still used by most clients but was the only available method supported in legacy clients like Lync 2010 and devices like Lync Phone Edition.

    On-Premises and Hybrid Deployments

    This section focuses on Lync Server and Skype for Business Server deployments where on-premises Front End pools and Edge Server pools are deployed.  Some of these environments may also be configured in the Hybrid model with a split-domain configuration connected to an Office 365 tenant.  Either way there are multiple potential registrars that client would be directed to connect to depending on the client’s network location at the time, as well as VPN connectivity is applicable.

    DNS Resolution

    The Lync/SfB registrar pool FQDN will be needed for the desired user account .  The following steps can be used to validate if the appropriate DNS records exists for the SIP domain to support legacy discovery processes.

    • From a internal workstation located inside the corporate network use the Command Prompt or PowerShell to enter the following nslookup commands to search for any Service, Host, or Alias records specifically pointing to an internal registrar (e.g. Front End Pool).

    PS C:\> nslookup -q=srv _sipinternaltls._tcp.jdskype.net
    Server:  dc.jdskype.net

    Non-authoritative answer:
    _sipinternaltls._tcp.jdskype.net      SRV service location:
              priority       = 0
              weight         = 0
              port           = 5061
              svr hostname   = fepool.jdskype.com

    fepool.jdskype.com   internet address =
    fepool.jdskype.com   internet address =
    fepool.jdskype.com   internet address =

    PS C:\> nslookup sipinternal.jdskype.net
    Server:  dc.jdskype.net

    Non-authoritative answer:
    Name:       fepool.jdskype.com
    Aliases:    sipinternal.jdskype.com

    PS C:\> nslookup sip.jdskype.net
    Server:  dc.jdskype.net

    Non-authoritative answer:
    Name:       fepool.jdskype.com
    Aliases:    sip.jdskype.com

    • From an external workstation located outside the internal network use these nslookup commands to search for any Service, Host, or Alias records specifically pointing to an external registrar (e.g. Edge Pool).

    PS C:\> nslookup -q=srv _sip._tls.jdskype.net
    Server:  google-public-dns-a.google.com

    Non-authoritative answer:
    _sip._tls.jdskype.net SRV service location:
              priority       = 10
              weight         = 100
              port           = 443
              svr hostname   = sip.jdskype.com

    PS C:\> nslookup sipexternal.jdskype.net
    Server:  google-public-dns-a.google.com

    Non-authoritative answer:
    Name:       sip.jdskype.net

    PS C:\> nslookup sip.jdskype.net
    Server:  google-public-dns-a.google.com

    Non-authoritative answer:
    Name:       sip.jdskype.net

    Note that not all of these records will typically return results.  The sipinternal and sipexternal records are rarely used, but the basic sip record is commonly configured internally for legacy devices as is often added during the server certificate creation.  It is also very commonly used as the external Edge FQDN for external clients and federation.

    If none of the lookups performed above are successful then the environment being used has not been configured to support any of the legacy autodiscovery lookup records, which is not entirely uncommon these days.  At this point a specific registrar name can be found using the desktop client instead.

    Client Information

    • Sign in to a Windows Lync or Skype for Business client.  After the client has completed the sign in process hold down the the CTRL key and right-click the client icon in the System Tray.

    • Select the now-visible Configuration Information menu item.


    • Look for the Skype for Business Server entry and take note of the FQDN displayed.

    The following example shows an internally connected client as denoted by an Inside User Status value of TRUE.  The connected Skype for Business Server is displayed as the internal Front End pool FQDN (e.g. fepool.jdskype.net).


    Be aware that in some instances this may instead display the user’s specific home server FQDN instead of the entire pool FQDN (which is shown in the example above) when registered to an internal Front End pool.  In multiple server pools the use of an individual server FQDN to manually register a device or client would not allow for any High Availability redundancy, so make sure to keep in mind that while this approach is fine for testing it is best to retrieve the pool FQDN from the IT administrator if it cannot easily be located programmatically.  (In deployments leveraging Standard Edition Front End Servers then this is moot.)

    This second example is from an externally connected client as denoted by an Inside User Status value of FALSE.  The connected Skype for Business Server is displayed as the external Edge pool FQDN (e.g. sip.jdskype.net).


    When registered to an Edge pool the actual home Front End server FQDN is not shown and only the external Edge FQDN is displayed.  Thus for external registration this value is perfectly fine for production use as it does not circumvent any High Availability capabilities which may be provided by the external pool.

    Skype for Business Online

    This section applies only to pure Skype for Business Online tenants where there are no on-premises Skype for Business servers deployed.

    For all users hosted on Skype for Business Online there is a single defined FQDN

    • From any workstation use these nslookup commands to search for the Service and Host/Alias records which point directly to the Skype for Business Online pools in Office 365.

    PS C:\> nslookup -q=srv _sip._tls.jdskype.net
    Server:  google-public-dns-a.google.com

    Non-authoritative answer:
    _sip._tls.jdskype.net SRV service location:
              priority       = 100
              weight         = 1 
              port           = 443
              svr hostname   = sipdir.online.lync.com

    PS C:\> nslookup sipexternal.jdskype.net
    Server:  google-public-dns-a.google.com

    Non-authoritative answer:
    Name:     sipdir.online.lync.com
    Aliases:  sip.jdskype.net

    This process shows the common sipdir.online.lync.com FQDN used for all registration attempts to Skype for Business Online.  This single FQDN should be used be all devices or client connecting to a Skype for Business Online account from any location.  Leveraging this FQDN insures the best connectivity.

    Alternatively the Skype for Business Configuration Information can be reviewed using the process shown in the previous section. Because the sipdir.online.lync.com FQDN is simply a geographically balanced DNS record the actual server name shown will be that of whichever registrar pool the user’s account is homed on.


    Polycom Group Series with Skype for Business Server

    May 10, 2017 by · 73 Comments 

    Earlier this year the Polycom RealPresence Group Series video conferencing platform received official qualification for use with on-premises Lync Server 2013 and Skype for Business Server 2015 deployments.  Note that this does not yet include Skype for Business Online which is a separate qualification process that is nearing completion.  When support for direct registration to Skype for Business Online accounts in Office 365 is achieved then look for a newer article covering that simple configuration.


    For anyone familiar with these devices or the previous generation HDX platform then much of the configuration outlined in this article may look familiar.  These devices are commonly referred to by a host of various names, like “Standards-Based Video Systems” or “Endpoints”, or more simply a VTC (VideoTeleConfering systems).  Another common nickname is “codec” in reference to one of the unit’s primary functions as a media encoder/decoder.

    Whatever they are called though the general idea is that the systems only work within other standards-based SIP and H.323 video conferencing platforms.  While this is true of most legacy systems from manufacturers like Cisco/Tandberg, LifeSize, and even older Polycom units to name the most common of them, the more recent generations of Polycom VTCs also have supported direct, native registration to Microsoft’s SIP-based communications platforms like Office Communications Server, Lync Server, and most recently Skype for Business Server.  Specifically the older HDX models were originally supported with OCS 2007 all the way up to Lync Server 2013.  The newer Group Series platform was supported originally on Lync Server 2010 and now with Lync Server 2013 and Skype for Business Server 2015.

    It is important to understand that for Skype for Business Server environments the Group Series can be involved in one of two ways.  Either natively, as this article discusses, or via an interoperability solution like RealConnect which was outlined in this article from a few years ago.  Also keep an eye out for an upcoming article on the new interoperability service provided in Skype for Business Online known as RealConnect for Office 365, or more generically as Cloud Video Interop (CVI).

    When the Group Series system is leveraging the native support model it will register as a Skype for Business account and do most of the things one would expect a registered client to do: support presence states, peer calling, join Skype Meetings directly to the AVMCU, etc.  But when coming through an interoperability solution the VTC is only able to call into Skype Meetings, there is no presence or peer calling support as the VTCs are not able to actually register to the Skype for Business environment.

    Prerequisite Configuration

    One of the most important concepts to understand when dealing with solutions like the Group Series or VVX phones which support multiple different platforms is that entering information as basic as user credentials may not always be entirely straightforward.  As explained in this previous article Windows user credentials can be used in different formats which do not always use the same names, depending on how the account was originally setup.  As more organizations move to Office 365 then the opportunities are reduced for scenarios where SMTP and SIP addresses do not match a User Principal Name (UPN).  But knowing and not just guessing the proper format to enter a set of user credentials is paramount.  This is the single most common problem seen in the field with failures to successfully register anything to Lync or Skype for Business.

    When dealing with on-premises Lync and Skype for Business deployments typically both the legacy NetBIOS format as well as the newer UPN format can be used.  That being said it has long been a recommended practice to use the UPN format when possible as moving away from older methods help prepare for scenarios in which these methods no longer are applicable, as in dealing with a standard Office 365 tenancy.  So, while both formats may work in a given environment the guidance seen throughout this (and all recent articles on this blog) focuses on using the UPN format throughout all examples.

    The Group Series firmware contains an embedded web server which can be used to remotely administer the device, also similar to VVX and Trio phones.  Most configuration steps shown throughout this article can be accessed using the on-screen menu system and supplied remote control, or by using the Administration menu on a RealPresence Touch (RPT) control panel.  For continuity all configuration steps outlined in this article use the web interface.

    One of the unique aspects of the Group Series platform (which was carried over from the HDX) is that the configuration for SIP registration and calendaring registration is separate.  Comparatively every other native Lync or Skype for Business client or endpoint uses the same single set of credentials to access both Lync/SfB and Exchange services.

    Firmware Update

    Qualification and official support for on-premises Lync Server 2013 and Skype for Business Server 2015 requires the use of at least the 6.1.0 version of the RealPresence Group Series software.  The most recent firmware can be downloaded directly from the Polycom Support site from any of the available models listed here.  The firmware package is identical between the 300, 310, 500, and 700 models.  Note that the RealPresence Medialign packages are powered by a standard Group Series 500 and thus uses the same firmware.  The RealPresence Centro product, although also powered by Group Series technology, uses a unique firmware version and thus is not officially qualified with SfB.

    Updating the device firmware can easily be performed from either the web interface or by using a USB flash drive.  The latest Administrator Guide can be referenced for detailed steps on each of the available formats.  Also be aware that when upgrading to any major release a new license key will need to be generated which is provided as part of the product’s purchased maintenance agreement.  What denotes a ‘major’ upgrade is any version in which either the first or second digit in the version number has been incremented.  So while moving from version 6.0.0 to 6.0.1 is a minor upgrade and does not require a new license key upgrading from 6.0.1 to 6.1.0 is a major upgrade and will require an upgrade license key, just as would an upgrade from 5.1.4 to 6.0.0.

    • To perform a system firmware upgrade over the Internet using the hosted Polycom server simply connect to the Group Series IP address (e.g. from a web browser via HTTPS on any computer with local network access to it.


    • Navigate to the Admin Settings > General Settings > Software Updates menu. Alternatively simply type “update” in the Search bar above the menu to quickly jump to the Software Updates menu.


    • Under the Software Server section click Check for Software Updates.


    • If a newer software version is available then the following screen will appear. 


    Compare the Current Software Version to the New Software Version to determine if an upgrade license key is required.  As this example is going from 6.1.0 to 6.1.1 then a key is not required and the Group Series will not prompt for one to be entered.

    • Click Start Update to begin the upgrade process.

    The browser window can be left open during the upgrade to keep track of the initial progress.  The Group Series will reboot itself several time and the entire upgrade process will take about 45 minutes to complete.  Progress throughout can also be seen on the codec’s main monitor as shown in the image below.


    Once the upgrade has finished and the codec has returned to the main home screen the following configuration steps can be performed.

    Options Key

    Various additional value added capabilities of the Group Series platform are unlocked in the software by the use of special Options Keys.  These keys can be provided by the Polycom reseller when the associated add-on license has been purchased.  All of the native Microsoft capabilities of a Group Series codec are included in the Skype for Business Interoperability License.  This license was originally referred to as the “RTV Options Key” and then later the “Lync Interoperability License”.  Even though it is now referred to as “Skype for Business” it is the same options key and used for registration to both Lync 2013 and Skype for Business 2015 server platforms.

    Technically this license is not required in order to perform a successful registration to a Lync or Skype for Business server.  Yet without the Options Key installed usage will be limited to peer to peer audio calls only, based on the few industry standard audio codecs that the Group Series has in common with various Lync and SfB clients.  The rest of the native capabilities hinge on support for multiple Microsoft protocols and codecs like X-H264UC, RTV, CCCP, RDP, and so on.  Without the Options Key applied no video calls or content sharing sessions can be established, and Skype for Business meetings cannot be joined. So in essence the Options Key is required to get any meaningful usage out of the system with Lync or Skype for Business.

    But why allow the system to register without the options key enabled in the first place, yet limiting the functionality so much?  This is a common question and to understand the reasoning behind the behavior a brief history lesson is in order.  This options key was originally introduced in the Polycom HDX platform back in 2011 and was simply called the Real-Time Video (RTV) options key. And that was all that it provided at the time: the ability to support RTV video streams with other Office Communicator or Lync 2010 clients.  Without that license then peer-to-peer video calls with those older Microsoft Windows clients still worked as they both supported the standard H.263 video codec, limited to CIF resolution.  So at that point in time the RTV options key was truly ‘optional’ as it was simply a value-add, providing for an improved video experience by adding support for additional resolutions including up to 720 high definition.

    Then Lync 2013 came along and changed everything by dropping support for the legacy H.263 video codec in the Windows clients, leaving RTV support, and adding the new X-H264UC implementation of SVC video.  This meant that an HDX could not negotiate a video session with a Lync 2013 client, unless it had the RTV options key installed as otherwise there would be no common video codecs between the two endpoints.  This change made the options key pretty much mandatory and no longer an optional purchase as deployments upgraded to Lync 2013.

    Eventually additional capabilities were added to the platform by way of including more protocols and codecs from the Microsoft platform.  Support for the Centralized Conference Control Protocol (CCCP) was added to allow the HDX to allow it directly join Lync Meetings hosted on the AVMCU.  The support for CCCP was embedded into the RTV options key, but the key was not yet renamed.  Then the HDX platform was replaced by the newer Group Series platform which carried over the same options key behavior.  Soon additional features were added to this options key for the Group Series only, like support for the X-H264UC video codec.  The options key was then aptly renamed to the more descriptive Lync Interoperability License as it was now handling a lot more than just support for the legacy RTV codec.  Even more recently this was further updated to Skype for Business Interoperability License on the Group Series, but regardless of the name used the Group Series still supports both Lync 2013 and Skype for Business 2015 servers and clients.

    Given the changes over time to incorporate the various, now required, protocols and codecs then it is clear why this options key is no longer optional.  The ability to register to a Lync or Skype for Business server has not been changed so that it cannot register without the license though.  So when performing tests if only a peer call can be established with a Lync/SfB client and only the audio works then this is a red flag that the options key is most likely missing from the system.  Understand that a call between two Group Series registered to Lync/SfB will work across all modalities (audio, video, content sharing) even if one or both do not include the options key because they will negotiate those streams over more preferred standards-based codecs (like H.264-High Profile for video or H.239 for content sharing).

    To enable all supported features retrieve the Options Key from the purchased licensing paperwork and apply it to the codec.

    • Using the web management interface navigate to the Admin Settings > General Settings > Options menu, or simply search for “options” and then select the Options result. 

    • Enter the appropriate options key and then click Save to apply.  The Skype for Business Interoperability License should then show a checkmark icon next to it to indicate that it is successfully installed and the features are enabled.


    Note that the example codec shown used in this article currently has a few additional licenses enabled, some of which may not be applicable to Skype for Business but can still be used with H.323 calls.

    • The Multipoint Video Conferencing option is used to enable an on-board software MCU which can only be used on standard SIP or H.323 calls.  When registered to Lync or SfB any multiparty calling scenarios are always escalated to and handled by the Lync/SfB server and this onboard MCU capability is automatically disabled during those calls anyway.

    • The Telepresence Interoperability Protocol (TIP) option is only applicable to standards-based calls involved with a certain type of Cisco endpoint family. 

    • The Advanced Video 1080p license is applicable to any platform, including Lync/SfB, and is required if attempting to send or receive RTV or SVC video streams above 720p resolution.

    SIP Registration

    Another uncommon facet of the Group Series codec is that it can support two separate concurrent signaling platform registrations; one via SIP and the other via H.323.  Only the SIP registration capability is applicable for use with Lync and Skype for Business .  If the system is simultaneously registered to some H.323 platform this does not adversely affect its capabilities as a native Lync/SfB endpoint but some additional attention should be paid to things like which registration ‘arm’ is used by default when manually placing outbound calls.  It would not be successful to attempt calling another standards-based system by sending a SIP dial string to a Lync or Skype for Business registrar, for example.

    The Lync or Skype for Business account being used to register the Group Series can be either a standard user account or a meeting room account, as explained in detail by this recent blog article.

    Automatic Discovery

    To configure the Group Series to register with a Lync or Skype for Business server it is recommended to use the automatic settings by default which are outlined below.  In the event that registration is not successful then manually configuring additional settings can help troubleshoot any automatic discovery issues which may be preventing the registration.  Currently the Group Series firmware performs the legacy discovery process that leverages DNS SRV and A records pointing directly to the registrar which was commonly used by Lync 2010 and older clients (like Lync Phone Edition for example).  Support for the newer Lyncdiscover process will be introduced in a future update.

    • Using the web management interface navigate to the Admin Settings > Network > IP Network menu, or simply search for “sip” and then select the SIP result. 

    • Expand the SIP section click Enable SIP if it is not already enabled.

    • Leave SIP Server Configuration set to the default value of Auto.

    • Leave BFCP Transport Preference set to the default of Prefer UDP.

    • In the Sign-In Address field enter the SIP URI of the desired Lync or Skype for Business user account (e.g. gs500@jdskype.net). 

    • In the User Name field enter the User Principal Name (UPN) of the same account (e.g. gs500@jdskype.net).  In most deployments the user account’s SIP URI and UPN are identical, but is not always be the case.  This field also supports the legacy NetBIOS format of “DOMAIN\username” but it is a best practice to utilize the modern UPN format.

    • Click the Password box to expand the Enter Password and Confirm Password fields.  Enter the user account’s password in each field.

    • Leave the Proxy Server field blank as auto discovery process will be used to locate the proper registrar.

    • Select Microsoft from the pull-down menu in the Registrar Server Type menu.

    • Finally click Save to attempt to sign-in.

    The Registration Status will always immediately report “Registration Failed” as the sign-in process is still happening, but within 30 seconds or less the registration should complete and change to  “Registered”.

    Automatic Configuration Example


    Manual Configuration

    If initial registration attempts fails then manually pointing the Group Series directly to the desired registrar is one of the first troubleshooting steps which can help identify potential automatic discovery issues which may be causing the problem.

    The Lync/SfB registrar pool FQDN will be needed for the desired user account .  Follow the steps outlined in this article to identify the appropriate SIP registrar FQDN to use with the Group Series.  Make sure to note if the targeted registrar is an internal Front End server or an external Edge Server as the Group Series configuration will differ slightly.  On an internal network registering to a Lync or Skype for Business Front End pool the destination listening port will be TCP (TLS) 5061, where as an externally placed system attempting registration to an Edge pool will need to be configured to connect over TCP (TLS) 443.

    The behavior of the Group series when specifying the registrar manually is to attempt connections by default to the well know service ports for SIP communications.  If either by automatic discovery or manual configuration when a TCP connection is attempted it will use port 5060, or for TLS communications port 5061.  In the event that a different port needs to be contacted then the port number needs to be entered after the registrar FQDN using a colon separator, as in host.domain.com:port.

    To manually configure the Group Series to register to a Lync or Skype for Business server then use the same steps as attempted above in the Automatic Discovery section, but perform the following alterations:

    • Change the SIP Server Configuration to Specify.

    • Change the Transport Protocol to TLS.  (This is not mandatory as TLS will still eventually be used when set to Auto but setting it specifically to TLS simply removes one more discovery step that is performed during registration.)

    • In the Registrar Server field enter the FQDN of the Lync or Skype for Business Server or Pool.  If this is an internal Front End Server/Pool then enter only the FQDN (e.g. fepool.jdskype.net) but if this is an Edge Server or Pool then enter the FQDN as well as the destination listening port (e.g. sip.jdskype.net:443).

    • The Proxy Server field should be left blank.  Registration can still work if the exact same value as the Registrar Server field is entered but this is redundant and normally should not be populated.  Unlike some standard SIP platforms the Microsoft SIP platform contains the proxy and registrar services in the same server roles.  (This field is not used for pointing to an outbound web proxy server, that is configured in a different section.)

    • Set the Registrar Server Type to Microsoft.
    • Click Save to start the registration process.

    As before the Registration Status will immediately be reported as “Registration Failed” as the sign-in process starts but within 30 seconds or less the registration should hopefully change to  “Registered”.

    Manual Configuration Example


    If registration is now successful then it can be assumed that the Group Series was either unable to find the desired legacy DNS lookup records or was possibly not able to handle potential redirection scenarios in a hybrid deployment configuration.  At this point it is suggested to reach out to product support channels for further assistance.

    Directory Servers

    Now that the SIP registration process has been successful using one of the approaches above the next step is to insure that the Directory Server integration is complete.  Just like with SIP the Microsoft platform differs from traditional SIP platforms in terms of address books and directories.  The Group Series needs to manually be configured to used the Microsoft Address Book Service, although other LDAP or Global Directory Services (GDS) could be utilized in place of the Microsoft address book if desired.

      • Using the web management interface navigate to the Admin Settings > Servers > Directory Servers menu, or simply search for “directory” and then select the Directory Servers result. 

      • Change the Server Type to Microsoft.

      • In the Domain Name field enter the SIP domain for the the currently registered user’s environment (e.g. jdskype.net).

      • Click Save to connect to the Address Book service.

    The Registration Status will  initially continue to be displayed as “Registration Failed” but within 30 seconds or less the status should update to  “Registered”.


    Once configured to use the Microsoft directory service option then the Group Series will adhere to the in-band AddressBookAvailability configuration as controlled by the Set-CsClientPolicy cmdlet in Lync and Skype for Business.  When the parameter is set to either FileDownloadOnly or WebSearchOnly then the Group Series will utilize only the option allowed by the defined policy.

    If the default WebSearchAndFileDownload value is configured then the Group Series will use the Address Book file download model by retrieving the address book files from the server via HTTPS.  These are the same files that the standard Lync and Skype for Business clients download to respond to searches immediately by using a cached copy (galcontacts.db) of the entire Skype for Business Address Book.

    Yet in environments with a large amount of data stored in the address book files these can reach a size too large (roughly more than 2MB)or contain too many entries (approximately more than 20,000) for the Group Series to successfully download, expand, and store in memory.  In the events where this happens the Group Series will then automatically fall back to leveraging the Address Book Web Query (ABWQ) service and then all directory searches performed on the Group Series will immediately be forwarded to the ABWQ service for the server to perform and return any results.

    Calendar Registration

    The final registration step is to configure the Calendaring Service to connect to the registered account’s Exchange mailbox.  Any version of Exchange which includes Exchange Web Services is supported with the Group Series, which includes all versions of Exchange Server 2007 through 2016 as well as Exchange Online.  Note that while official support for Skype for Business Online is not yet available the Group Series has supported connecting to Exchange Online mailboxes for several releases now.

    • Using the web management interface navigate to the Admin Settings > Servers > Calendaring Service menu, or simply search for “calendar” and then select the Calendaring Service result. 

    • Check Enable Calendaring Service if it is not already enabled.

    • In the Email field enter the primary SMTP address of the desired mailbox (e.g. gs500@jdskype.net).  This is typically the same as the currently registered Skype for Business user account, as shown in this example, but it can be a completely different user or resource mailbox if desired.

    • Leave the Domain field blank.

    • In the User Name field enter the User Principal Name (e.g. gs5000@jdskype.net) of the account which has at least reviewer permissions to the mailbox supplied in the Email field above.  Again this is typically the same account as used for SIP registration but this could be a different account in the event that a delegated-rights ‘service’ account is to be used to access the mailbox instead of the mailbox’s primary AD user account itself.

    • In the Password field enter the password associated with the provided user account in the previous field.

    • Verify that the Auto Discover Using parameter is set to E-mail Address and then click the Auto Discover button.

    At this point the Microsoft Exchange Server field should automatically be populated with the FQDN of the appropriate Exchange Server for the supplied mailbox.  Depending on the location of the mailbox the value will either be an Exchange Server FQDN (if the mailbox is stored on an on-premises Exchange Server) or outlook.office365.com (if the mailbox is stored in Exchange Online).

    • Leave the Secure Connection Protocol set to Automatic.

    • The remaining fields are optional and can either be left at the default value or customized as desired to control Meeting Reminder and Private Meeting behaviors.

    • Click Save to attempt to register to Exchange and access calendaring information stored in the targeted mailbox.

    The Registration Status will  initially continue to de displayed as “Not Connected” but within 30 seconds or less the status should update to  “Registered”.



    To validate that the Group Series is successfully working with Skype for Business a number of tests can be attempted to confirm several capabilities in addition to simply checking the System Status for general health.

    System Status

    • Using the web management interface navigate to the Diagnostics > System > System Status menu, or simply search for “status” and then select the System Status result.

    The three sections to focus on are the Microsoft Server (for the Directory Server), the SIP Registrar Server, and the Calendaring Service.  Verify that all three services are green and do not report any errors.


    Peer Calls

    To initially validate that the registration was indeed successful a simple test is to check the advertised presence of the registered Group Series and then start a video call with it.

    • Open the Skype for Business client on a workstation and look for the Group Series user by either searching the directory or directly typing in the account’s SIP URI.


    • Start a Video Call to the Group Series to test a peer call scenario and then answer the incoming call on the Group Series.


    • While the call is still established return to the web management interface for the Group series and note the additional call control buttons which are now displayed across the top of the window.


    • Click the Call Statistics button to bring up the following menu displaying some technical details on the current call.


    In a peer call a pair of audio channels and video channels are displayed.  Outbound streams are denoted by Tx (Transmit) and inbound streams are labeled as Rx (Receive).

    Note that based on the default Skype for Business window size the Group Series is sending (VIDEO TX) 640p video at around 800 Kbps using SVC.  (The Group Series will report the Microsoft-specific implementation of SVC (X-H264UC) generically as SVC-HP.)  Because this Group Series unit includes the 1080p options key and the Skype for Business Windows workstation in the call is a quad-core PC capable of encoding 1080p video then the codec is also receiving (VIDEO RX) a 1080p video stream from the SfB client.

    • Manually resize the Skype for Business client’s video session window to the smallest possible dimensions on the receiving workstation.


    • Refresh the Call Statistics on the Group Series and check the statistics reported for the Video Tx line again and notice that Group Series is now sending lower resolution video to the SfB client at around only 375 Kbps.


    • Now maximize the SfB video window on the workstation as shown below.


    • Refresh the Call Statistics again and note that the codec should no be sending a much higher resolution video stream then either of the previous arrangements. Based on the screen resolution and size of the window on this specific workstation the SfB client is now asking the Group to send a 720p high definition video stream at around 2.5 Mbps.


    • Increase the SfB video window one more time by selecting the Full Screen View option (the little opposing diagonal arrows in the upper right hand corner of the window.  This will increase the video window to the largest possible size.  The inclusion of the Skype logo watermark is an indicator that the full screen view has been enabled.


    • Refresh the Call Statistics again to see that now the SfB workstation has requested the maximum supported 1080p high definition video resolution at around 4 Mbps to be sent by the Group Series.  On less powerful workstations this would be limited to 720p, or if the Group Series is not licensed to support 1080p video streams.


    • From the SfB client select the Share Your Desktop option to add an RDP application sharing session to the existing video call.

    • Refresh the Call Statistics one last time to see the inclusion of the inbound content sharing session (CONTENT RX)


    Skype Meetings

    This take this one step further the Group Series can join a Skype Meeting hosted on a Lync or Skype for Business Server AVMCU.  If calendaring has not been enabled on this codec then to join a meeting the unit must be invited by another SfB participant currently in a scheduled or Meet Now meeting.

    If calendaring has been enabled then using either the remote control, a paired RPT panel, or a supported touch screen select the Join button displayed inside any Skype Meeting invitation which has been sent to the Group Series account’s mailbox.  The Group Series will automatically dial the Conference URI to join the Skype Meeting.  Once in the meeting various features like presenter muting will operate in the same fashion as it does on native Skype clients.

    Additional Settings

    This section covers various optional configuration settings which may be applicable to the Lync or Skype for Business environment.

    Touch Control Panel

    If a RealPresence Touch (RPT) control panel is to be used with the Group Series the capability must first be enabled and then the RPT can alternatively be configured to use a Skype for Business-specific user interface instead of the default interface.

    • Using the web management interface navigate to the Admin Settings > General Settings > Pairing  menu, or simply search for “pair” and then select the Pairing result. 

    • Check Enable Polycom Touch Device if it is not already enabled.

    • From the RPT itself select Manually Pair and enter the IP address of the Group Series and initiate the pairing process.

    Once pairing is successful the Status should be displayed as “Connected” as shown below.


    To enable the alternative Skype for Business user interface perform the following steps.

    • Using the web management interface navigate to the Admin Settings > General Settings > Home Screen Settings menu, or simply search for “skype”, and then select the Skype Mode result. 

    • Select the Enable Skype Mode checkbox.

    The screenshot below shows a touch panel that is paired with the Group Series with the Skype Mode UI enabled, as well as the Calendaring Service successfully registered to Exchange and displaying the next five meetings.


    Next Page »