The core Polycom video bridging infrastructure components of the RealPresence Platform (RPP) have recently attained Lync Qualification. As of the posting of this article the following RPP products qualified for Lync Server 2013 are:
- The Distributed Media Application (DMA) 7000 version 6.2
- The RealPresence Collaboration Server (RPCS, a.k.a RMX) version 8.5
This means that when the DMA and RMX are deployed together and integrated into a Lync 2013 environment then a host of different features and conferencing topologies are supported by both Polycom and Microsoft. In this recent article the concepts of utilizing a third party MCU to either host all conference attendees or better yet leverage both MCUs by hosting attendees on both the standards-based MCU and the Lync A/V MCU together in a single, cascaded meeting. This improved workflow, referred to as RealConnect, is discussed in this article by Adam Jacobs.
Regardless of the chosen conferencing scenarios the base integration between Lync Server and the RPP core components is the same. The latest deployment guide can always be found at the bottom of the Polycom Microsoft partner support page which can be found using this simple URL: http://support.polycom.com/microsoft.
The overall configuration guidance has remained largely unchanged since Lync 2010 was first released. These third party solutions are integrated using the Trusted Application Pool methodology and the guidance in this previous article is still applicable, with the except of a few changes and improvements over time.
Trusted Application Pools
- For most installations only one Trusted Application Pool for the entire topology is required. This pool should be created as a multiple-computer pool so that both the DMA and RMX, as well as any additional DMAs or RMX is resilient deployments are all defined in this same pool.
- Having a single pool means that only a single Trusted Application needs to be defined.
Note that it is important to understand the difference between single-computer and multiple-computer Trusted Application Pools. Use of single-computer pool is not recommended as it requires some steps to be duplicated and adds unneeded complexity to an environment which never aids anyone when troubleshooting potential issues. Utilizing a multiple-computer pool means that all of the Polycom RPP resources are contained in a single grouping and granted the same level of trust throughout the Lync topology
Also important to understand is the difference between the concepts above and having one or more unique Trusted Application Pools. As mentioned above the default practice is to create one (1) multiple-computer Trusted Application Pool, meaning one pool is defined which contains multiple computer objects.
There is at least one scenario though where more than one Trusted Application Pool should be defined in the topology. This would be in multiple Lync Pool deployments where (often geographically) separate Lync pools are paired with their own Edge pools. In the event that there is more than a single Edge pool and also more than a single Polycom RPP deployment in the environment then it is recommended to use separate Trusted Application Pools for each set of RPP components.
In the following example this Lync topology includes two separate sites (East and West) which each contains their own Front End and Edge pools.
The reason for this configuration is that the RMX will utilize the Edge server or pool that is allocated to the Front End Pool that its Trusted Application Pool points. So in the example above the RMX in the East site would leverage the Edge Server in that site, and the RMX in the West would us its local Edge Server. If the topology only contains a single Polycom RPP deployment or a single Edge pool then this is not necessary. Defining just one Trusted Application Pool will be sufficient for all Front End servers in all pools in any site in the entire topology to function correctly as Trusted Application Pools are topology-wide.
One of the steps that is still included in the official guidance covers how to define a static route to send SIP messages from Lync to the trusteed application.
In the new RealConnect workflow this is no longer necessary as all Lync participants will only ever connect to the Lync AVMCU in conference calls and then RMX will automatically connect into the same meeting running on that Lync AVMCU. Hence there is no need to define a static route, nor a Matching URI in Lync. If the traditional approach of landing Lync endpoints directly into the RMX is still required (both can be enabled in the same environment) then the static route would still be needed for those calls.
But for RealConnect-only workflows the static route is a thing of the past.
Legacy ICE Configuration Method
In past RMX releases the method of enabling Lync Edge Server connectivity to leverage ICE/STUN/TURN media traversal support has been an optional step which requires only the creation of a basic Lync user account. That configuration has been superseded by a newer approach which is now a requirement (even if there is no Edge Server in the environment) and uses a n improved design.
The original approach was to simply create a standard Lync-enabled user account and then supply that account’s SIP URI to the RMX (and not to SIP register the RMX directly to an Edge Server which has often been performed mistakenly). For older versions and comparison’s sake the legacy method is revisited in the following steps. If using RMX 8.4 or a newer release then do not uses these steps; skip directly to the next section.
- Create a new AD user account and then enable it in Lync. the AD account’s username and password fields are irrelevant so they can be anything within company policies.
- Create a simple, meaningful SIP URI in the same SIP domain name space as what was already defined in the RMX configuration. (e.g firstname.lastname@example.org).
- Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu. Then enter the name portion of the SIP URI (e.g. rmxice) into the Server User Name field.
- Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above.
If the SIP domains do not match then it is required to change the Lync account’s SIP URI suffix to the same SIP domain that is already defined on the RMX. This issue would only be applicable for Lync deployments with more than a single SIP domain defined.
New ICE Configuration Method
The ICE support configuration has now changed to utilize a Trusted Application Endpoint instead of a standard Lync user as shown above. Also the Service Globally Routable User Agent (GRUU) for the Trusted Application Pool containing the RMX is leveraged, meaning that the new ICE configuration is a two-part setup.
- In RMX 8.3 or earlier releases only the legacy methodology must be utilized.
- In the RMX 8.4 release either method can be used s both are supported.
- In RMX 8.5 and newer only the new method is supported and the legacy method can no longer be used.
Understand that the supportability statements above mean that the existing ICE configuration in a current deployment would need to be modified if the RMX is upgraded to 8.5 or newer. Also be aware that the ICE configuration is no longer optional. For the rare Lync deployments which do not contain a functional Edge Server in the deployment this ICE configuration is still required. The Lync Front End pool will actually support some of the required capabilities when an Edge Server does not exist.
Whether the Trusted Application Pool and Trusted Application objects already exist from a previous integration or need to be created for a new integration a third object needs to be created: the Trusted Application Endpoint. For new configurations simply follow the official deployment guide referenced at the beginning of this article. If updating an existing configuration use the following cmdlets to determine the desired target application pool to attach the new ednpoint object to.
- Using the Lync Server Management Shell issue the following Get-CsTrustedApplicationPool cmdlet to identify the required attributes.
Get-CsTrustedApplication | Select-Object identity,ApplicationId | ft
Identify the correct Trusted Application Pool and record the FQDN (video.schertz.name) and the Application ID (video).
- Issue the New-CsTrustedApplicationEndpoint cmdlet to create a new endpoint object in the desired existing pool. The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step. The SipAddress parameter defines a SIP URI for this new endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service. Anything unique can be used and in this example a SIP URI of ‘email@example.com’ is chosen.
New-CsTrustedApplicationEndpoint -TrustedApplicationPoolFqdn video.schertz.name
-ApplicationId video -SipAddress sip:firstname.lastname@example.org
The TrustedApplicationPoolFqdn and ApplicationId parameters must match the values resolved in the previous step. The SipAddress parameter defines the SIP address for this endpoint object and must be a unique value that is not already in use by another Lync user, contact, or service.
- Make sure to issue the Enable-CsTopology cmdlet to comment this change to the Lync Topology.
Before leaving the management shell there is one more step to complete. The target Trusted Application Pool will contain a parameter called the Service GRUU (Global Routable User-Agent URI) which needs to be set in the RMX and DMA. This Service GRUU is not something which can be manually defined in the topology; it is a value that Lync automatically defines when a Trusted Application is added to the topology.
- Run the following Get-CsTrustedApplication cmdlet to retrieve the Service GRUUs defined in Lync. Highlight the entire parameter and copy it to the clipboard or save to a text file for later use.
Get-CsTrustedApplication | fl ServiceGruu
Any RPCS/RMX instances deployed in the environment can be updated using the following configuration for ICE support within Lync.
- Go to the SIP Advanced section on the RMX under the Default IP Network Service properties and select MS from the ICE Environment drop-down menu. Enter or change the value to use the name portion of the new Trusted Application Endpoint’s SIP URI (e.g. rpp) into the Server User Name field.
- Go to the SIP Servers section on the RMX under the Default IP Network Services properties and verify that the Server Domain Name field is using the same SIP domain as the Lync account above. This should not need to be changed as it should be in the same SIP domain as the previous ICE Lync account.
Save these changes but defer any reboot request in order to make one final change.
- Navigate to the Setup > System Configuration > System Configuration menu and in the default MCMS_PARAMETERS_USER view select New Flag.
- For the New Flag name enter SIP_CONTACT_OVERRIDE_STR and then paste in the Service GRUU value which was saved to the clipboard or a text file in the previous section.
It is important to note that in the RPCS/RMX the “sip:” prefix must be omitted from the Service GRUU value when entered into this system flag.
- Save these changes and then reboot the system to enable the new configuration.
While the DMA does not actually interact with the Lync Edge Server directly for ICE support the Service GRUU is still utilized for other capabilities and should also be configured using the Service GRUU..
- Using the DMA web management interface navigate to the Network > External SIP Peers menu.
- Edit the desired Lync Front-End Pool peer object and then in the editor window switch to the Lync Integration tab.
- Enable the checkbox for the CsTrustedApplication ServiceGruu setting and then paste the entire Service GRUU into this field.
It is important to note that in the DMA the “sip:” prefix must be included from the Service GRUU value when entered into this system flag.
With the recently launched Office 365 Summit events Microsoft has started sharing technical details on the various new capabilities which are on the horizon with the future release of Skype for Business Server. In a previous article this rebranding of Lync to Skype for Business (SfB) was analyzed and explained in an effort to clarify some of the confusion immediately seen after that announcement.
This article will attempt to do the same regarding one of the advertised capabilities coming to the Lync replacement in Skype for Business: Video Interoperability. As made evident by the unexpected popularity of an earlier article on this same topic for Lync 2013, there is a growing need to understand this space which has actually become more complicated over time, due to the increasing number of applicable solutions and methods coming into the market since then, provided by multiple Microsoft partners and even Microsoft themselves.
Before getting into the new information it would be prudent to start with some baseline understanding of what the generalized term of ‘video interoperability’ actually means. Depending on the source this could be referring to traditional standards-based conference room solutions communicating with foreign systems, or this could be more of a story about tying together with enterprise and consumer grade applications. Or both. Whatever the discussion, it always boils down to figuring out a way to get something old to work with something new or making things foreign to each other find a way to interact successfully.
One additional approach is simply forego interoperability by replacing any incompatible system with new, supported solutions. This alternative approach is what the Lync Room System product line is intended to address. Either by reducing the need for interoperability by shifting new purchases toward these native systems, or by figuratively ‘biting the bullet’ and just replacing everything with an LRS solution. Clearly cost, scale, and time are controlling factors in the ability to even attempt this approach which can look much simpler on paper. Also this only addresses a company’s own systems and limits their ability to host conferences with partners and customers who may be using different solutions.
Hence the very real and common need for finding a way to protect and leverage any investment in existing systems, while possibly even shifting future expenditures toward a completely Skype-centric view.
Apples to Spaceships
There have always been a fair share of challenges in providing a bridge between the Microsoft UC platform world and the massive in-place deployment of the world’s standards-based conferencing solutions. Much of that complexity has to do with the wide array of communication paths (e.g. signaling, audio, video, content) and the large gap in design methodology between each. The popular fruit-based idiom just does not ring true in this scenario even if though both sides are trying to share the same sources of data: a person’s face, their voice, a spreadsheet, or presentation deck. It is the delivery mechanisms which can be quite different in design and application to where neither can be equated with being from the same food group, much less even both be considered foods.
The shear growth in adoption of Microsoft’s Commutations Server platform over time has driven multiple partners to provide a varying array of solutions from value-add devices to complete endpoints to core infrastructure.
Also understand that any references to H.264 Scalable Video Coding (SVC) in this article infers Microsoft’s specific implementation of the codec, advertised as X-H264UC, which is not directly compatible with H.264 SVC that some standards-based video systems support today.
Lync to Skype
Simply rebranding the enterprise solution is not enough to make it and the existing consumer platform play nice together. Microsoft has already been working on addressing how to bring together existing Skype consumer clients with the Lync enterprise deployment base. Renaming the enterprise platform the same as the consumer platform may look like the first step down that path, but in reality much work has already gone on in the background starting over one year ago, as covered in this article.
In place today is the version 2 Skype Gateway architecture which provides for direct media traversal between Skype consumer Windows desktop clients and Lync 2013 clients. This same solution will be applicable to Skype for Business clients when that product is released. Basically the Lync 2013 clients have received SILK audio support via a past Cumulative update, and the latest Skype consumer client for Windows include support for both the H.264 SVC video codec and media relay utilizing the Lync Edge Server.
This Business to Consumer (B2C) concept has been discussed in various past articles amongst the community, so for now the focus of this article will be on the various enterprise-grade options for Business to Business (B2B) needs.
Enterprise Video Interoperability
As captured in this category of articles there are already a variety of third-party solutions available to address this which have been around since the early days of the Communications Server platform. These options range from basic signaling gateways or more powerful transcoding gateways with limited scalability all the way through full suites of conferencing bridges and signaling servers which can either host the entire conference itself or join an existing Lync conference.
The four available methodologies for addressing these needs can be summarized as:
- Native Endpoint Registration
- Multipoint Control Unit
- Bridge Cascading
Native Endpoint Registration
As the name suggests, this means that no back-end interoperability solution is used. The Lync or Skype for Business environment is used as the sole conferencing engine and all endpoints (software clients and hardware devices) will connect directly and natively to these environments wherever they may reside.
Note that in this diagram the ‘Desktop Client’ could be any variety of past or future Microsoft UC clients: Office Communicator 2007, Lync 2010, Lync 2013, or the upcoming Skype for Business client. These clients all support a range of compatible audio and video codecs, with varying support for both RealTime Video (RTV) and H.264 SVC. For example, while the Lync 2013 and SfB clients will support both RTV and SVC, the Lync 2010 and older clients only support RTV. When hosting conferencing on a Lync 2013 or Skype for Business platform which either may contain older desktop clients or (more realistically) be inviting federated or foreign attendees who may still be running older Lync or Communicator client versions then it is important for the room system solutions in these environments to also support the older RTV codec so that all participants in the meeting can be seen and heard by all attendees regardless of their versions.
A few different options are available today to either provide a plug-and-play experience to users or deploy a dedicated conferencing room system that can talk directly to the Skype for Business or Lync platform. The Microsoft Lync Catalog currently lists all of the qualified Meeting Room Device and Solutions. Some of these systems support native registration to on-premises services only, while other may be also able to connect directly to Microsoft’s Office 365 offering, or even other hosting provider’s clouds.
- Desktop Clients: Provide one of the various qualified Lync video conferencing devices which connect to a Windows desktop to provide an enhanced in-room audio and video experience without the need for a dedicated endpoint. Users will bring their own workstation, connect via USB to one of these systems, and then drive the meeting from their own Lync client using their own identity. This is the least expensive option and only requires deployment of something like the Logitech CC3000e or Polycom CX5500.
- Lync Room Systems: To eliminate the need to bring any workstations into the conference room as well as improve the audio and video experience then a completely native and permanent solution is deployed into the conferencing like a Lync Room System (LRS) package available from Crestron, Polycom, or Smart. These systems are back-ended by a hardened Windows-embedded PC which communications directly with an on-premises or hosted Lync or Skype for Business environment. Also new in this space is the recently announced Microsoft Surface Hub platform which can serve as a low-end LRS-like package to easily bring a conferencing experience to any wall with basic audio and video capabilities served by an integrated microphone and camera. (Note that the Surface Hub does not run the LRS client and is a completely new design based solely on Windows 10 and the Surface touch experience.)
- Qualified Room Systems: To move even further beyond the current Lync or Skype for Business specific solutions a modern standards-based room system can be deployed which support native Lync and Skype for Business communications protocols and codecs. Partners in this space have included in their standards-based systems additional support for varying levels of the multiple protocols and codecs like Microsoft’s implementation of SIP and H.264 SVC, RTV, or the Centralized Conference Control Protocol (CCCP) to name just a few. Examples of these room solutions are the LifeSize 220 or Polycom HDX & Group Series.
Any other conferencing solutions outside of these categories are simply not invited to the party and would require some assistance from a additional solution to bridge the communications barrier.
Microsoft generically refers to these legacy standards-based conference room systems which do not contain any embedded Lync interoperability as a Video TeleConferencing system, or VTC. Throughout this article the term VTC will continue to refer to these types of systems, which must utilize one of the following solutions in order to have any chance of participating in meetings with any Lync or Skype for Business users.
The first, and most basic method to address the issue would be to use gateways to provide an access route for various unsupported room systems to reach the Lync/SfB world. Conferences and peer call control is still owned by the Lync/SfB environment, but a transcoding and/or signaling gateway can offer a path for a limited number of systems to communicate with the Lync clients and servers, often with only a subset of the available modalities and features. In short these solutions may either only support audio and video with no content sharing capabilities across all platforms, or may be limited to internally connected systems with no Edge media traversal compatibility.
In this diagram the foreign VTC is registered via H.323 or SIP either directly to a video gateway or is registered to their own native environment which includes a gateway configured to route traffic between to and the Lync environment. The gateway will translate the different signaling protocols, for example between H.323 and Microsoft SIP. Some gateways are even capable of further transcoding the audio and video codecs, like Microsoft’s X-H264UC implementation of H.264 SVC against H.264 AVC.
The diagram shows a simple environment of one VTC behind a single gateway, but imagine that the environment within the dotted grey box could be as vast as multiple endpoints connected to a complete video infrastructure behind pools of multiple gateways which are then connected to the Microsoft environment.
Examples of endpoints which fit into the VTC category would be any array of Cisco’s older Tandberg H.323 or SIP endpoints or their TelePresence solutions, some LifeSize systems, older Polycom VSX endpoints, and even ISDN video systems just to name a few.
Examples of the video gateways would be the Cisco VCS or Radvision Scopia. Note that this category has been the least active over the past few years as solutions have matured into one of the next methodologies.. Cisco’s VCS solution has received some updates for Lync 2013 video interoperability in the past year but this solution has never been included among the Lync qualified solutions. While vendor support is available from Cisco this is not a solution seen actually deployed that often in the field. Also the Radvision Scopia gateway was last qualified for Lync 2010 and has not seen any updates to support H.264 SVC as implemented in Lync 2013.
The topic of gateways will be revisited in the second-half of this article as Microsoft will will utilizing this methodology with Skype for Business server.
Multipoint Control Unit (MCU)
The simplicity of the first scenario is also its most limiting factor. As mentioned before, what about the cost of simply replacing the large of amount of functional systems out there in use today? Or deploying and managing a large number of gateways, thus further complicating the environment and communication paths? One alternative here is to utilize a standards-based conferencing solution which can deal with the plethora of non-Lync standards in existence today, and then provide a path for the Lync users to also reach this same conference. Lync and SfB users simply call into these meetings which are hosted on the standards-based MCU, also referred to as bridges, providing a single meeting place that can bring everyone together. These separate bridges are the virtual location where everyone calls into to hear and see each other.
Conferences in this scenario are hosted on the standards-based side of the fence so all clients must negotiate their media sessions directly, or indirectly with the assistance of an Edge Server if supported by the third party solution. The call signaling path is still native for endpoints on both sides, but SIP messages are routed out of the Front End Server to the integrated standards-based system. This means that conferences held in this manner, although technically able to handle audio, video and possibly some content sharing, are not utilizing any of the Front End server’s conferencing capabilities. A varying degree of native Lync and Skype for Business capabilities may not be available to those users, depending on which third party vendor’s solution is deployed.
Because each and every Lync client must directly connect to the third party bridge then vendors must test and support every type of Microsoft client available in the Lync and Skype for Business platforms. Most vendors only support a subset of these clients across different versions, and even then only some codecs and modalities among those. This means that conferences may not be able to provide the same level of results to all types, with the mobile and Mac clients traditionally lagging behind in support.
Examples of some third party vendors which support this model today are Acano, BlueJeans, Fuze, Pexip, and Polycom. Note that currently the only Lync Qualified solution among these is the Polycom RealPresence Platform, comprised of the RMX and DMA components.
Every one of the scenarios above are really just a combination of compromises in the end as while each may contain some measurable advantages over the other the overall architectures is not ideal. The best single solution is to not have a single solution, but to use both environments as originally intended and then just connect them to each other. This approach leverages the strengths of both platforms and retains the native user experiences on both sides.
In this topology the standards-based MCU is connected directly to the Lync AVMCU during any meetings allowing endpoints on either side of the table to join the same, cascaded conference with all participants able to see and hear any active speakers, and in some cases even multiple video steams in one direction or the other.
Examples of third party solutions which support this model today are Acano CoSpace, Pexip Infinity, and Polycom RealConnect. While each of these solutions leverage both MCUs in a single meeting there are varying amounts of capabilities related to the mechanics behind them, the manner in which participants join meetings, the amount of video streams, and the list of supported codecs.
One of the single biggest advantages of this model is that it leaves all of the Lync clients completely on their side of the map, unlike the previous approach which forces them to connect directly to the third party MCU. While the initial gateway approach utilizes the Lync MCU for all conferencing attendees that environment is limited to what those gateways can bring in, which often is not very much in terms of types and amounts of VTCs.
Other major advantages of this architecture is that the entire conference is native to both side. For example, capabilities unique to RealConnect are that scheduling meetings is done within Outlook using the standard Lync Meeting invitations. Joining meetings is the same for all, clicking an embedded link (for desktop users) or dialing a Conference Id (for audio attendees and room video systems). Secondly bidirectional, transcoded content sharing is made available to all parties on either side when either a Lync or SfB participants is sharing their desktop or if a VTC is sending some sort of H.239 or BFCP content stream.
Video Interoperability Server
The various options covered above are great for supplying a full conferencing environment which addresses a multitude of real-world requirements and issues. But what about the smaller environments where maybe only a handful of legacy room systems are deployed but cannot simply be replaced with new systems, nor is deploying additional infrastructure (physical or virtual) in the cards. If additional costs or management worries have traditionally meant that the third-party back-end solutions have just been not viable options, then in traditional Microsoft fashion a basic solution is now about to be embedded natively into the product.
Just as Microsoft has incorporated capabilities into the Communications Server platform along the way, like an XMPP Gateway for example, the upcoming releases of the Communications Server platform Microsoft has positioned Skype for Business Server to address both consumer client B2C scenarios and standards-based interoperability for B2B video-based communications.
B2C video support for Skype consumer clients has already been delivered by incorporating changes into the Lync 2013 client and server platform late last year to allow for peer-to-peer video calls between Lync 2013 users and Skype consumer Windows desktop users.
The B2B scenario is also being addressed natively, for the first time within the product itself, by leveraging a new server role available with on-premises deployments of the upcoming Skype for Business Server platform. This software release will contain a new server role available to define the topology and deploy called the Video Interoperability Server (VIS).
Fellow Lync MVP Adam Jacobs posted an article introducing VIS nearly a year ago, just after the 2014 Lync Conference was held in Las Vegas. That article discusses this gateway concept of a Back-to-Back User Agent (B2BUA) with what was publically known about VIS at the time. He has also just posted a follow-up article touching on both the Skype consumer capability as well as VIS. With the recent release of the latest content from the Summit events there are now more public details on VIS in terms of the supported topology and endpoints. The first takeaway from reviewing the information is that the capabilities are a smaller subset of what was originally advertised.
VIS is available only as a separate server role, and will not be offered as a collocated Front End server role, unlike the Mediation Server role. This means that additional physical or virtual Skype for Business servers will need to be deployed into one or more scaled VIS pools. Also note that Microsoft has stated that the role is only available to on-premises and Hybrid deployments, meaning an on-premises pool will need to be deployed and is not available as a feature for Office 365-only customers.
The initial offering of VIS will support a single Operating Mode entitled SIP Trunk Mode, which could be equated to what the Mediation Server role does for audio calling between Lync and IP-PBX platforms by virtue of establishing SIP trunks between them, but now for both audio and video. Basically this new server role acts as a gateway between the Skype for Business servers/clients and some sort of foreign video signaling server.
VIS supports a 1:N topology in that a single VIS pool can be configured to communicate with multiple different video signaling gateways. Meanwhile any one video signaling server can only be connected to a single VIS pool.
The only supported environment at product launch will require that VIS be connected to a Cisco Unified Communications Manager (CUCM or CallManager) deployment which in turn includes one or more of a specific list of tested and supported Cisco VTC models. Note that there is no support here for the Cisco Video Communications Server (VCS) which is more commonly found in currently deployed video environment. Cisco appears to be moving away from the legacy VCS platform by supporting video signaling in CUCM and Microsoft has chose to go the same route with VIS support.
The supported VTC endpoints listed at the time this article was written are as follows:
- Cisco TelePresence Codecs (C40, C60, C90)
- Cisco TelePresence MX Series (MX200, MX300)
- Cisco TelePresence EX Series (EX60, EX90)
- Cisco TelePresence SX Series (SX20)
Microsoft has stated that additional models which can support Cisco TelePresence System codec software version 7 or newer (TC7.0.0) may be tested after the initial Skype for Business Server release and then added to the UC Open Interoperability Program for VTCs.
The most obvious thing about VIS at this point should be that it appears to be a Microsoft-provided Cisco gateway. There is no mention of other third party VTC manufacturer involvement in this program to date. There are a variety of reasons for that, one being that some partners which were focused on video compatibility with Office Communications Server and Lync Server in the past have fallen off the radar. For example Radvision’s gateway solution for Lync has not shown any activity in the qualification space since their purchase by Avaya. LifeSize has also not stayed up to date in the qualification program, as well as bowing out of the Lync Room System program last year. Most of the newer names in this space, like Acano or Pexip, are providing gateway and bridge solutions and do not provide any compatible endpoints.
Also clearly missing from the list above are any Polycom room systems. As covered in this variety of articles or in this blog post from another Lync MVP Brennon Kwok it should be clear that the last two generations of Polycom room systems support native Lync registration including a wide variety of features, much beyond what VIS can offer. So it would be a step backwards to attempt to utilize VIS as a gateway for the HDX and Group Series room systems instead of just using their native registration capabilities to fit into that first scenario near the beginning of this article.
VIS will provide connectivity for supported VTCs to both clients and servers. The previous diagram shows the signaling and media flow for a conference hosted on the SfB Front End server by the collocated AVMCU service. VIS is used to proxy the connection and media for VTCs so they can participate directly in the meeting. In the SIP Trunk mode each VTC remains registered to the CUCM infrastructure and then can place calls through CUCM, to the VIS pool, and then on to the Skype for Business Front End pool’s Conference Auto Attendant. There is no drag-and-drop support so SfB users cannot locate a specific VTC and simply drag it into a peer or conference call in an attempt to invite the VTC to the meeting. The VTC must call into the meeting manually by the conference room attendees.
Once in the meeting only a single active video participant can be sent to/from the VTC via VIS, and there is no support for content sharing thus far. This means that the experience from inside the conference room will look a lot like the following image. The Skype for Business and Lync users will receive multiple video participants via the Gallery View in addition to content shared by another desktop client, the same as they would in any normal meeting. Yet when the VTC joins the meeting the attendee will only see the active speaker and will also not receive any of the shared content.
Compare the room system and desktop user experience above, as provided by VIS with what a third-party solution like bridge cascading can provide because they can support multiple streams and content. For example the capabilities of Polycom RealConnect are depicted below which includes bi-directional content sharing and multiple active speaker video participants from Lync appearing on the VTC.
Microsoft’s implementation of H.264 SVC provides multiple simulcast video streams in multiparty conference calls. While Lync 2013 and SfB clients are programmed to send (when requested) these additional streams directly to the Front End server, the legacy VTCs do not have this capability. (Note that native endpoints like LRS and the Polycom Group Series do support these simulcast streams).
In order to retain the flexibility to fulfill different video resolution and frame rate requests across various clients the Front End Server AVMCU needs this to be addressed by VIS. The way this works is that VIS acts as a media transcoding gateway, not just a basic signaling gateway.
The VTC will negotiate an outbound video stream directly to VIS at a specific resolution and frame rate . If the Front End Server AVMCU has any client requests for differing, lower resolutions or frame rates it will then request one or two additional streams. Because the VTC can not provide these additional streams then VIS must create them. VIS itself will transcode and send to the AVMCU up to a maximum of three different video streams, all derived from the single, original stream send by the VTC.
The example above shows a VTC joining a meeting with 3 other Skype for Business endpoints of varying hardware capabilities and conference views. The VTC in this case happens to negotiate and encode a 720p video stream at 30 frames per second to VIS.
- VIS repackages the original H.264 AVC stream into an SVC session understood by the AVMCU which in turn relays it to the laptop participant who happens to have ‘Speaker View’ enabled and thus is requesting full screen high definition video at the full 30 fps.
- VIS will transcode a second stream, downscaling the resolution to 360p as requested by the desktop client which has the default ‘Gallery View’ enabled.
- VIS will also transcode as third stream, downscaling the provided video even further to supply a 180p stream at only 15fps for the mobile device in the conference.
All three of the above streams are simulcast from VIS directly to the AVMCU. If any attendees change the way that video is viewed during the call, leave the meeting, or new participants join then the AVMCU will adjust the requests to VIS in the event that one or more of the additional simulcast streams is no longer required.
VIS must perform this work as the legacy VTCs do not support this capability. For this reason a single VIS server can only support up to a few VTCs simultaneously in a single environment, thus multiple server nodes and even multiple pools may be required to support the transcoding demand which may exist in a specific environment.
One important limitation of this design is that VIS can only transcode H.264 SVC video streams to and from the Skype for Business side of the equation. It does not support transcoding RTV so only Lync 2013 and SfB clients, or any other native device which supports the H.264 SVC implementation in Lync/Skype will be applicable. If a Lync 2010 or Office Communicator client were to join this conference call they would still see the other native participants, who are capable of sending a second RTV stream during the meeting for legacy clients. That additional RTV stream is not sent on to VIS though as it does not support it transcoding it, so that means the VTC will not be able to see the 2010 client’s video and the 2010 client will not see the VTCs video.
An additional limitation is that VIS cannot leverage Edge for media traversal between itself and the VTC environment because the legacy VTCs contain no built-in support for ICE/STUN/TURN as implemented in Skype for Business Server. This means that both CUCM and all VTCs must have the ability to communicate directly with the VIS pool without traversing any network address translation (NAT). The VIS pool does communicate with the Edge server on its SfB-facing side though to establish media sessions with any external or federated Lync and Skype for Business clients, so the imitation is only placed on the VTC side of the network.
Peer to Peer Calling
Peer-to-peer (P2P) calls between the VTCs and other registered Skype for Business or Lync 2013 clients are also supported, although in the initial release only calls placed by a VTC to a SfB user is supported. SfB users cannot call a VTC.
And just as described in the meeting scenario VIS does not support transcoding of RTV so only Lync 2013 clients, Skype for Business clients, or any qualified system which supports Microsoft H.264 SVC can participate in peer calls with supported VTCs.
While VIS does not need to supply additional simulcast streams in a simple two-party call it must still perform some basic transcoding to translate the standards-based H.264 AVC stream sent by the VTC into a n X-H264UC compatible SVC stream that the Lync 2013 or newer clients require for interoperability.
One of the points of this article is to explain not only what VIS is, but also what VIS is not (or at least is not yet).
It does not offer any native capabilities in Skype for Business server to bridge its clients with the vast array of H.323 based conferencing systems, as SIP-only endpoints registered to CUCM is the single supported topology for now. For environments moving in that direction then VIS can provide some capabilities for cross-platform conferences, but it is clear that Microsoft partners providing video interoperability solutions for many years now provide solution sets far beyond the capabilities of VIS, today But as Skype for Business matures one might expect to see additional features and capabilities coming to the platform which will help close some of the gaps. In the meantime, or for the foreseeable future going with a complete end-to-end solution like bridge cascading is one of the ways to finally bring together desktop users and conference rooms in a user experience that is easy to schedule, simple to join, and familiar to all.
The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.
This meeting will be conducted in our familiar two-session format:
The first session presented by Enghouse Interactive will cover Contact Center solutions for Lync.
The second session presented by a local subject matter expert will discuss the announcement of, as well as provide an update on Skype for Business Server.
Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync. Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.
Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.
For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group. For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted. For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.
As usual I will be hosting the Chicago event downtown. Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.
|Tuesday, January 20th
5:30PM – Food and Networking
6:00 PM – Presentation Kickoff
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
Microsoft’s Corporate Vice President for Skype, Gurdeep Singh Pall, released the following message to Twitter coinciding with the official blog articles confirming the hunches of many in the industry on how Microsoft would ultimately tie the Lync and Skype products even more closely together.
The articles do not go into much detail at all about exactly what is happening, outside of some semblance of a rebranding but a closer look at some of the statements do point to a few important items.
In the first half of 2015, the next version of Lync will become Skype for Business with a new client experience, new server release and updates to the service in Office 365.
This basically means that the next on-premises server, clients, and Office 365 releases of what would be Lync will now simply be renamed, and the Lync name will be apparently be deemphasized. Surely this does not mean that the existing consumer Skype platform would be positioned to businesses, or mean the death of Lync as a platform. For all intents and purposes the two separate products must still exist : the consumer ad-driven solution known as Skype, and the enterprise-grade solution known to all as Lync which will simply be rebranded as Skype for Business.
Many enterprises will continue to run on Lync 2010 and 2013 platforms if they have just upgraded and moving to the next platform may be far off for them, while others will be excited to start evaluating the next release to see if it is a candidate for them to warrant upgrading to.
And speaking of upgrades the following statement seems to validate the rumors that in-place upgrades will be supported in the next server release cycle.
Current Lync Server customers will be able to take advantage of these capabilities simply by updating from Lync Server 2013 to the new Skype for Business Server in their datacenters. No new hardware is required.
Ultimately this rebranding fits a pattern that the product has had since it was first rolled out as Live Communications Server (LCS) 2003 and then 2005. It was brought into the Office collective by name as Office Communications Server for the next two releases (2007 and 2007 R2), followed by two more release cycles rebranded as Lync 2010 and 2013. So this is not a surprise at all given the history of the product.
Furthermore a redesign of the Windows client has also occurred in the past three release cycles (Office Communicator 2007, Lync 2010, and Lync 2013) so this change also comes as no surprise. A closer look at the Windows client shows that while the design borrows the color scheme and icons from Skype, the layout and function is still most definitely Lync at its core.
On a personal note I have known about this rebranding for quite some time and have already gone through the five stages of loss and grief that the rest of the technical community will undoubtedly be experiencing starting today.
- Denial – “Well that’s a silly idea, so clearly they will come to their senses.”
- Anger – “Stop changing the name already! People just became comfortable with Lync.”
- Bargaining – “ Look, how about using the Skype client with the Lync server, akin to Exchange and Outlook”"?”
- Depression – “Well, forget this. I’m going to stop blogging about the product and join a monastery.”
- Acceptance – “OK, I suppose it’s not the end of the world. There might be some upside here.”
It will be confusing for a bit as the lines are blurred between the consumer and enterprise products, but in the end the user community (and not necessarily IT administrative staff) should benefit the most. Imagine an employee, already comfortable with operating the Skype client on their personal computer and devices, seeing this familiar interface on their corporate workstation and devices, both handheld and in conference rooms? Nearly 5 years ago there was roughly the same initial reaction to the new Lync rebranding of OCS and the product itself clearly won over many fans in the years to come. On the upside at least I won’t have to hear anyone calling it ‘Lynx’ anymore.
A previous article entitled Media Codes in Lync 2013 covered the introduction of the SILK narrowband and wideband audio codecs from Skype into the Lync 2013 desktop client. Since posting that article Microsoft has also added SILK support into the various Lync 2013 mobile clients, which means that some call scenarios like mobile-to-mobile Lync calls are already using SILK Wideband as the primary audio codec for those calls.
While this new behavior for Lync audio calls is not made evident directly to the user by the client it can be validated by reviewing the Peer-to-Peer Session detail reports from the Lync Monitoring Server.
The following image shows only the relevant data clipped from the Media Quality Report of a test audio call between an iPhone and an Android phone both running the latest Lync 2013 mobile clients.
Both audio streams are reported as using SILKWide which is the wideband SILK audio codec. A Sample Rate of 16000 denotes wideband codecs while a value of 8000 means it is a narrowband codec. (There is one exception to this rule which is called out later in this article).
To understand how SILK was used for this peer-to-peer Lync audio call a capture of the SIP messages generated during the call setup will show which audio codecs the clients advertise to each other.
The Session Description Protocol (SDP) data in a SIP INVITE message sent by a 2013 mobile client currently advertises the following codec capabilities for receiving audio streams:
m=audio 37124 RTP/AVP 104 9 111 0 8 103 97 13 118 101
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=fmtp:104 useinbandfec=1; usedtx=0
a=fmtp:103 useinbandfec=1; usedtx=0
As explained in the previous article the m=audio line declares all of the client’s supported audio codecs and lists them each by their payload type in order of preference. The other client in the conversation also sends its own list in return.
The first payload listed is 104 which is SILK wideband, as denoted by the 16000 clock rate. When negotiating an audio call with another Lync endpoint which supports this same codec it will be used by default. A mobile to mobile or a mobile to desktop client call would utilize SILK wideband unless some other event (like constrained bandwidth) triggers the selection of a more appropriate (and less-preferred) codec. Additionally the use of in-band Forward Error Correction (FEC) is defined (useinbandfec=1) after the initial declaration of the SILK codecs.
Yet a mobile client joining a conference call, thus negotiating media directly with the Lync AVMCU, will not use SILK as it is not currently supported by the Lync AVMCU. That call would instead leverage the first compatible codec which happens to be the next in the list: G.722 (9).
Looking closely at the list above shows that these mobile clients do not include Real-Time Audio (RTA) which could be construed as an indication of a move away from RTA as the primary audio codec for Lync peer calls. In head-to-head tests SILK has consistently outperformed the other Lync wideband audio codecs. Although the wideband version of SILK requires slightly more bandwidth than the wideband version of RTAudio it is much less than G.722 and also can perform better is less than ideal network conditions. That makes it a great option for the mobile clients which are at best on a Wi-Fi network and at worst using a cellular data network; both of which are lossy networks.
Also note that (as explained in this article) G.722 is incorrectly declared in SDP as a narrowband codec with a clock rate of 8000Hz even though it is truly a wideband audio codec.
The following table compares the quoted bitrates for the different wideband audio codecs in peer-to-peer sessions only.
|+ UDP, RTP, SRTP||+ FEC|
|G.722||9||Peer-to-Peer||64 Kbps||80 Kbps||96 Kbps||160 Kbps|
|SILK Wideband||104||Peer-to-Peer||36 Kbps||52 Kbps||64 Kbps||100 Kbps|
|RTAudio Wideband||114||Peer-to-Peer||29 Kbps||45 Kbps||57 Kbps||86 Kbps|
Each value in the table includes the column before it as additional overhead, like when Real-Time Protocol (RTP) control messages and Forward Error Correction (FEC) data are stacked on. When planning for media bandwidth on the network it is best to use the FEC value for any calculations as there is also some level of packet loss or delay in wireless networks to contend with. Using only the payload value is not indicative of the actual bandwidth which could potentially be consumed by a single stream.
Be aware that to-date Lync to Skype audio calling is still using the v1 gateway model explained in the previous article so audio sessions between the Lync mobile clients and Skype clients are not yet utilizing SILK in a direct peer-to-peer model in the way that Lync peer calls function. The v2 model for Skype interoperability with Lync 2013 is still pending a release form Microsoft.
This article aims to serve two purposes. Firstly, as a reminder to always keep Lync Phone Edition (LPE) devices updated and not to grow lackadaisical regarding the routine administrative tasks of frequently downloading these periodic cumulative updates and applying them to the Lync servers.
Secondly, if the previous advice was not taken to heart then some Lync administrators may already be experiencing a specific problem directly related to running older device firmware versions in a current Lync environment. There is also the potential for newly purchased devices coming from existing stockpiles to have older firmware preinstalled from the factory which can exhibit this same issue, by no fault of the Lync administrator.
The problem referred to is that Lync Phone Edition devices may fail to successfully sign-in to a Lync Server due to an untrusted certificate being presented by the server itself during the initial secure TLS network connection setup. This scenario can occur when an LPE device is running on an older version of firmware which still contains an outdated public Certificate Authority (CA) store. In the event that the Lync Server is using a server certificate from a public CA which was signed and issued by a newer CA than the phone is aware of it will fail to connect because it will treat the certificate presented by the Lync server as untrusted.
Be aware that this issue should be limited to the USB-tethered provisioning approach which uses a different method to download root CA certificates then when using the PIN Authentication method. Depending on the exact issue it can be possible to leverage the DHCP Option 43 configuration to allow a PIN Authentication attempt to download the proper public CA certificate directly from the Lync Server Certificate Provisioning Web Service.
But to support USB-tethered provisioning a workaround may be required to get the updated public CA certificate installed into an internally connected phone using an LDAP connection to Active Directory so it can then trust the certificate passed by the Lync server to establish a successful TLS connection. There are two ways to accomplish this, the easy way and the hard way.
- The preferred method is simply the guidance stated in the opening paragraph and is a preventative step. If the issue in this article is not a current problem in an environment but the ingredients sound familiar (public certificates on internal servers and LPE not running recent firmware versions) then heed this warning and go download and update those devices today before it is too late. As usual test the newer version out on a few test phone to validate that no unrelated problems appear before rolling it out to all phones in the environment.
- On the other hand if this article came up as a result of an administrator frantically searching for a resolution to this problem then unfortunately the preventative route cannot be taken at this point as that ship has sailed. Luckily there are a few options available to get past this ‘catch-22’ scenario of needing to update the firmware to get TLS working again but requiring TLS in order to facilitate an update.
Because Lync utilizes TLS for all signaling traffic this secure connection must be established before any additional steps like the actual user registration or a device update can take place.
A typical Lync environment will most often utilize an internal Windows Enterprise CA for the Lync server certificates, while a public certificate from a well-known third party certificate authority would be used for only the external side of any Edge Servers. While this still is the most popular topology in use today it is slowly becoming common to see public certificates used on the internal Lync server roles instead of private certificates for a myriad of reasons.
Environments using public certificates on the internal Lync server roles present a unique problem to LPE devices that many other clients are not subject to. There is no mechanism in the Windows CE-based LPE firmware to automatically refresh any preinstalled public root and intermediate CA certificates like other Windows-based operation systems. In the event that a specific public CA makes a change to one of their root or issuing CAs then the new certificate for that CA would need to be propagated down to any clients or servers which currently trust the previous certificate. Standard Windows operating systems utilize Windows Updates to refresh these types of changes, but LPE does not. The only way these phones can be made aware of these external changes is by being upgraded to a newer firmware release in which Microsoft has specifically updated the certificate store. Note that many other 3PIP Qualified phones for Lync can have the same manufacturer-updated behavior so make sure to keep those current as well for the same reasons.
Trusted Certificate Authorities
For optimized Lync Phone Edition devices from all manufacturers Microsoft manages the firmware and updates the root CA store periodically as public CA server certificates expire, are revoked, or are simply replaced. The TechNet article Certificates for Lync Phone Edition contains a list of the various CA certificates stored in the firmware’s Trusted Authorities Cache but this table is not kept up-to-date. As of the posting of this article that page still reflects the October 2013 Cumulative Release 10 (4.0.7577.4414) which is over a year old.
The following table lists all of the trusted root CA certificates utilized by LPE, both old and new:
From a brief glance at the above table a few things should be apparent:
- In versions older than CU10 nearly half of the cached certificate are
expired or revoked.
- If the phone is not running at at least the January 2014 Cumulative Update 11 (4.0.7577.4420) then it is not aware of a host of new CA certificates.
Where the problem introduced earlier comes into play is when a Lync environment is using a public certificate issued from one of the vendors in the table above that have made changes to the originally trusted certificates. Older server certificates assigned to Lync server might have been signed by the original CA, but as those certificates approach their expiration dates any good administrator will preventively update them prior to that date. So when these new certificate requests are generated on the Lync server and sent out to the same public CA for signing they are coming back issued from a different CA chain, and one that the older phone firmware is not aware of. When the servers are updated with these new certificates then phones running that older firmware will no longer be able to register to Lync.
If there are plans to update an public Lync server certificates in the near future and there are any Lync IP Phones in the environment then now would be a good time to get those phones on a newer release.
It is required to upgrade to at CU11 (4.0.7577.4420) at a minimum to avoid this problem, but it is always recommended to move to the most recent firmware currently available.
If the Lync server certificate has already been changed, or new phones running older firmware have been introduced into the environment, and they cannot successfully register then the following workaround can be used to address this problem.
Note that the hardcoded pre-authentication download attempt against the ‘ucupdates-r2’ hostname which was carried over from the original Office Communications Server Tanjay devices is not applicable here. The issue is not that the phone is failing to register to the Lync server, but that it cannot even get to that step due to the underlying TLS requirement not being available. This out-of-the-box update process requires TLS for a portion of the communication, even though the internal URL provided by the device update service uses HTTP. So without a working TLS connection the device update service is not reachable.
While the following approach is not new to Lync Phone Edition this guidance may not be something that newer Lync administrators are often aware of. Prior to the introduction of the current Aries family of LPE devices designed for Lync 2010 the older Tanjay devices introduced with OCS 2007 did not support the simplified PIN Authentication based on DHCP Option 43 as that feature was introduced in Lync Server 2010. In OCS if public certificates where assigned to internal server roles then Active Directory could be used as a central distribution point for the required public CA certificates. Because the current LPE firmware is based on that older platform then this behavior is still active in all LPE versions.
The process of publishing third party certificates into Active Directory was originally covered by Rui Jose Silva and references to this process can be found in various other articles, some of which appear to have vanished over the years.
Throughout the directions in this article the example scenario is a Lync 2013 Server utilizing the following newer DigiCert SLL certificate for all three usages on the Front End Server:
To clarify this is not an issue related specifically to DigiCert certificates, but any public CA unknown to the phone’s older firmware. DigiCert has a great program for active Microsoft MVPs which allows them to utilize public certificates in personal test labs for researching and writing articles like this.
Retrieve Root Certificates
Before any certificates can be imported into Active Directory they must first be saved into a Base-64 encoded X.509 file.
This can be accomplished by either locating and downloading the file(s) from the Internet or manually exporting them from the Lync server. The fastest method can be to just get them directly from the vendor’s website, but most public CAs have multiple root and subordinate/issuing servers so finding the correct certificate chain can sometimes be a daunting task.
- If already familiar with this process and the exact certificates have been identified then locate and download them from the vendor. Make sure to get all files in the certificate chain in the event that the Lync server certificate was not issued directly by a root server but was instead signed by a subordinate server. (This is most common as third party CAs rarely have the all-important root CA online and available to sign requests directly.)
Alternatively to ensure that the correct certificates are retrieved it is recommended to validate the current server certificate and then manually export the chain.
- On the Lync Server use the Lync Server Management Shell to execute the follow cmdlet which will list the currently assigned server certificate(s).
PS C:\> Get-CsCertificate | fl Issuer,Use,Thumbprint
Focusing on the Default, WebServiceInternal, and WebServicesExternal usages (and ignoring the OAuthTokenIssuer certificate) a typical configuration will have the same certificate assigned to all three client-facing usages. This Lync Server is utilizing a single certificate issued by DigiCert as made evident by the same Thumbprint value being reported for each.
- On the same Lync Server open a Microsoft Management Console window (mmc.exe) and then add the Certificates snap-in for the local Computer Account.
- Browse to the Certificates (Local Computer) > Personal > Certificates store and then locate the certificate which is most likely the one referenced in the previous output.
- To confirm that the correct certificate was selected switch to the Details tab to compare the Thumbprint value with what was reported by the Get-CsCertificate cmdlet (e.g. 3DFB6A83366BAD70DC4427565A64A07A0733EA49).
- Change to the Certificate Path tab to view the certificate chain for this certificate. Highlight the root server (e.g. DigiCert) at the top of the tree and click the View Certificate button.
- In the next Certificate window switch to the Details tab and then click the Copy To File button to export the certificate to a text file.
- In the Certificate Export Wizard select the Export File Format as Base-64 encoded X.509 (.CER).
- Save the file (e.g. C:\Temp\DigiCertRootCA.cer) to the local disk and complete the wizard.
At this point the root CA certificate, which is essentially the public key of the certificate, is now in a format suitable for importing into Active Directory. Because this example includes a 2-tier CA chain the same steps must be repeated for the subordinate certificate.
- Return to the Certification Path tab of the original server certificate, highlight the subordinate CA entry (e.g. DigiCert SHA2 Secure Server CA), and click View Certificate.
- On the Details tab use the Copy To File button to perform the same export procedure as before, saving the file with a unique name (e.g. C:\Temp\DigiCertSubCA.cer).
Import Root Certificates into Active Directory
The next step is to import these files into the proper Active Directory store location so that the Lync Phone Edition devices will attempt to download them the next time they are powered-on.
Prior to importing these though files first that a look at where they will be stored in Active Directory.
- On the Lync server launch ADSI Edit (adsiedit.msc) and connect to the Configuration Naming Context and browse to Services > Public Key Services.
CN=Public Key Services,CN=Services,CN=Configuration, DC=schertz,DC=name
Notice that the only object currently stored in these container is for the existing Windows Enterprise Certificate Authority which is AD-integrated by default when deployed in the domain. If there is no internal Enterprise CA in the environment then these stores will typically be empty.
To import the two DigiCert CA certificates into this store the certutil.exe Windows command can be used, which will place each certificate file in both the CN=CertificationAuthorities and CN=AIA stores located under the Public Key Services container.
- From the same domain-joined Lync server open a Windows Command Prompt window and issue the following command.
certutil -f -dspublish c:\Temp\DigiCertRootCA.cer RootCA
If the action is successful then the CA certificate should be reported as added to both DS store locations in the AD Configuration container.
- Repeat the step for any additional certificates in the chain.
certutil -f -dspublish c:\temp\DigiCertSubCA.cer RootCA
- Refresh the ADSI Edit window to verify that the new certificates are displayed in the stores as reported.
The final step is to attempt to sign-in on the phone using the USB-tethering approach so that the AD credentials can be supplied to the phone. If any older CX700 models are in the environment they are not required to be tethered as the AD credentials can be entered directly on the phone.
If the phone is still unable to register at this point then try one or both of the following tips:
- Perform a soft reset on the phone to clear any cached credentials and certificates and reattempt signing in.
- When signing-in enter the User Name in the odd-looking format of the DNS Domain instead of the NetBIOS name in this format: domain.com\username (e.g. schertz.name\jeff).
The MsTurnPing.exe application included in the Lync Server 2013 Resource Kit Tools package contains a bug that may have inadvertently triggered some incorrect practices related to the configuration of Edge server certificates.
Remember that the officially supported, best practice covered in this previous article is that an Edge Pool must utilize a single, identical certificate on all servers for the internal Edge interface which only includes the Edge Pool FQDN as the Common Name. The individual Edge Server’s unique FQDNs are not, and should not be included as these certificate should not include any SAN entries.
When running MsTurnPing.exe against a single Edge server it should not report any issues as the certificate’s Common Name is the single Edge Server’s FQDN (e.g. edge.schertz.name).
But when run against a multiple server Edge Pool in a DNS Load Balanced arrangement it will not function accurately. The tool will incorrectly report a problem with the certificate because it is hardcoded to utilize the Edge Server’s internal FQDN (e.g. edge1.schertz.name) during the test. But that FQDN should not be included in the certificate, thus causing the tool to report a problem establishing a secure connection to the server. The actual Lync Servers do not utilize the same method as they properly use the Edge Pool name.
- The tool will resolve the Edge Pool FQDN (e.g. edgepool.schertz.name) which is reported as the Cluster Name in the output. But as it connects to each server in the pool the Machine FQDN is reported
Cluster Name: edgepool.schertz.name
Machine FQDN edge1.schertz.name
Exception Message: Operation failed because the network connection was not available.
Cause: Lync Server Audio/Video Authentication service is not started
Cluster Name: edgepool.schertz.name
Machine FQDN edge2.schertz.name
Exception Message: Unable to establish a connection.
Cause: Lync Server Audio/Video Authentication service is not started
In this environment there are actually no problems with the Lync Server A/V Authentication service and all ICE/STUN/TURN capabilities are functional.
- Checking the System log on the local server where the tool was executed should report an Schannel error explaining why the previous test connection failed.
Log Name: System
Event ID: 36884
The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is edge1.schertz.name. The SSL connection request has failed.
As the tool reports a false-positive in this scenario this unfortunately has caused some administrators to go down the incorrect route of replacing the internal Edge certificates with SAN certificates containing both the Computer and Pool FQDNs. The problem here is that every computer FQDN would need to be in the SAN as the same exact certificate must be applied to all servers so that the same public and private keys are used by all server nodes, yet there should not be a SAN field contains on the certificates.
The proper guidance is to leave the certificates as Lync intended, with only the Pool FQDN assigned to the single shared certificate and no other FQDNs are included.
The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.
This meeting will be conducted in our familiar two-session format:
The first session presented by Aruba Networks will cover Software Defined Networking (SDN) and Wi-Fi scenarios with Lync.
The second session presented by a local subject matter expert will discuss Lync Online within Office 365.
Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync. Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.
Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.
For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group. For current members if your region’s event is not yet scheduled you just make sure that your notification options are configured so that you’ll get an alert when the new event is posted. For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.
As usual I will be hosting the Chicago event downtown. Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00
|Wednesday, October 22th
5:30PM – Food and Networking
6:00 PM – Presentation Kickoff
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
This article covers various aspects of configuring a complete Quality of Service (QoS) design in a Lync environment which utilizes various models of IP handsets for Lync. Prioritization of both signaling and media communications will be covered by addressing the following topics:
- Designing and configuring a network QoS plan
- Enabling QoS on network devices
- Enabling QoS for Lync desktop clients
- Enabling QoS on Lync Qualified IP Phones
- Updating QoS for Lync Phone Edition devices
The term Quality of Service (QoS) can refer to a variety of technical approaches for prioritizing specific traffic over an IP network. For the purposes of Lync the applicable solutions covered in this article are (a) leveraging Differentiated Services Code Point (DSCP) identification of specific traffic types and (b) defining separate custom port ranges for the various media payloads in Lync. Using this combination of traffic classification, commonly referred to as DiffServ, and organization will provide network routers and switches the ability easily identify real-time communication traffic and then prioritize each category as desired.
While there exists various modes of thought on these approaches the example guidance in this article will closely mimic real-world best practices which many production deployments of Lync share in common. Not all of the options shown here are necessarily critical; for example some administrators prefer to only prioritize the media payloads of Lync while others will also include the signaling traffic. Or in some cases only the audio traffic is tagged while other times audio, video, desktop sharing, or other traffic types like peer-to-peer file sharing are all individually categorized with unique values to create a layered approach to handling critical and non-critical data streams.
Design a QoS Plan
Providing end-to-end QoS in a Lync environment starts with defining port ranges for specific traffic to always be sent to and then includes the ability for the client sending that traffic to tag it with proper DSCP values so that the network devices place the traffic into the appropriate QoS queues.
This article is not intended to serve as a complete guide to all aspects of enabling QoS for Lync Server. A proper QoS approach is to address both client-to-server and server-to-server topologies by configuring Windows operating system policy settings and Lync Server settings applicable to both Windows desktop clients and servers. Various existing articles like the official TechNet guidance and this excellent article by Lync MVP Elan Shudnow are great resources to also read through. Keep in mind that although the official TechNet guidance covers how to configure some of the same settings as shown in this article their examples do not always represent the common practices used in the field.
Addressed here are only bi-directional peer-to-peer media sessions between any internal Lync endpoint including desktop clients and both types of Lync Optimized and Qualified phones. A complete QoS plan should also take into account the media port ranges and DSCP values for client-to-server and server-to-server media for conferencing and media relay call flows. The articles linked to in the previous paragraph include those details and can be used to complete the configuration started in this article.
The ‘tagging’ or ‘marking’ mentioned earlier is in reference to the DSCP value set on the outgoing packets from a client. By default this value is null and would be seen in a packet capture like this:
Differentiated Services Field: 0x00 (DSCP 0x00: Default)
This previous article explains the different levels of classifications and the supported marking values for each. The actual values which should be used must coincide with what the networking devices are configured to support, so it is critical to first understand how DSCP may already be defined on the network. For the purposes of this article it is assumed that QoS is not yet defined on the network and the next section will outline the actual configuration on an example switch.
It should be understood that it is not required to define media port ranges in order to utilize DSCP traffic prioritization on the network. But without doing so it is not possible to assign different types of traffic to different DSCP queues on the network as all traffic from the Lync desktop clients would be tagged, and thus prioritized the same. the easy way would be to simply tag all traffic from the Lync client application but then signaling, media, DNS requests, web service connections, and any other type of traffic would be prioritized no differently as the network device would not be able to tell one packet from the next.
The proper approach is to separate the different media types into their own unique port ranges so that the network devices can properly identify them and place each into the proper queue providing a layered approach. For example audio traffic is traditionally treated as the most critical payload and these packets are the last to be dropped on a saturated network, while less important (or higher bandwidth) traffic like video or non real-time communications like the signaling traffic or file transfers can still be prioritized over generic unclassified packets, but in a lower class or queue than the audio.
While defining media port ranges is used in conjunction with DSCP tagging for QoS there is another common reason outside of QoS for defining custom client media port ranges. By default all peer-to-peer media between Lync clients will utilize destination ports on both endpoints on a random high port between 1024 and 65535. In the event that internal clients are separated from each other by any firewalls then direct media sessions will usually not be possible and the clients will need to leverage ICE/STUN/TURN provided by the Edge Server to communicate with each other even though they are both internal clients. To avoid this undesirable load on the Edge Server it is recommended to define a much smaller port range for peer-to-peer media than the default of 64,511 ports (which no firewall administrator in their right mind would open up) to something much smaller (like 100 ports or less) which can be allowed through these firewalls between any internal network where Lync clients and devices may reside.
- To validate this default behavior in Lync simply capture a packet trace with a tool like Wireshark to view the source and destination ports used on a peer-to-peer media sessions between two Lync endpoints.
The example above shows a Polycom VVX 600 (192.168.1.100) and a Lync 2013 desktop client (192.168.1.101) in a peer audio call utilizing a UDP media session. Note that the source and destination ports are randomly selected within the 1024-65535 range (and that the DSCP flag is null).
The recommended custom port ranges for each media modality had traditionally been advertised by Microsoft as a minimum of 40 but that is older, outdated guidance. The latest guidance shown in TechNet correctly reflects the required minimum of at little as 20 ports per modality. Note that the exact math behind this number is related more to the audio and video modalities and a behind-the-scenes look at this was presented in the July 2014 Lync Users Group meetings. Utilizing the default range of 20 port per modality means that at most a single range of 100 ports would need to be opened on the internal firewalls. Also these ports are not actively listening and are only opened dynamically during media establishment between two clients.
The example port ranges in this article are arbitrary and realistically any unused range of ports can be defined. The approach used here roughly follows the same guidance seen in various other articles with one important exception related to supporting the Polycom Qualified IP phones (e.g. VVX). While the Lync clients and Lync Phone Edition devices can be defined with an exact range of any number of ports the VVX phones do not have the same configuration flexibility. These devices are hardcoded to use a range of up to 48 ports (24 for audio and 24 for video) and only the starting port can be defined, thus is the Lync policy is defined to use on 20 ports then it would be possible for the VVX phones to request media from the Lync clients to be sent in an out-of-scope port which would fail to be properly tagged.
To provide a complete QoS solution in which all Lync clients, optimized devices, and qualified devices will always communicate within the correct ranges then it is recommended to increase the defined port ranges for audio and video to at least 24 ports. Rounding these up to 25 ports can make the configuration easier to manage when derailing with a larger contiguous block. Adding one additional port to round it out will not cause any problems if a Lync client or LPE device uses that single destination port above 24 when receiving media from a VVX phone as the VVX phone will still tag all outbound media correctly. The VVX in turn will only utilize one of the defined 24 ports for its own destination (listening) port when accepting peer connections from a Lync client or LPE device, which is also still in the defined range. So in short increasing the range from 20 to 25 ports can provide for a simple to manage policy that will work for all clients. In fact it is perfectly fine to assign an even larger port range like 100 contiguous ports to make the plan very simple to read. As long as the Lync-defined port range is larger than the static port range on the VVX phones the traffic will be properly tagged in both directions. The only difference is how many ports must be opened between internal firewalls, as network administrators may be accepting of 100 ports in total but maybe not 500 ports.
As explained the DSCP values are a reflection of what are commonly used in the field but are in no way the only values which can be used. Any existing DSCP configuration on a network should be leveraged as the network administrator may already have defined classifications for certain types of traffic. The actual port numbers used are arbitrary and the 60xx range in this article is only only an example. Various TechNet documentation uses 20000 or 50000 but high ports can be used as long as they do not overlap with other traffic, like 5061.
Also understand that while the focus of this article is on IP phones in which only audio (and for some models video) are applicable each peer-to-peer media modality should be included in the design even if there are no plans to prioritize that traffic. Once custom client port ranges are enabled then all modalities will be enabled and the default values need to be changed for each (explained further in a later section).
Traffic Type DSCP Value Protocol Port Range Audio 46 – Expedited Forwarding (EF) UDP & TCP 6000 – 6024 Video 34 – Assured Forwarding (AF41) UDP & TCP 6025 – 6049 Signaling 24 – Class Selector (CS3) TCP 5061 Application Sharing 0 – Unclassified TCP 6050 – 6074 File Transfer 0 – Unclassified TCP 6075 – 6099
When selecting the port ranges do not forget that the starting port counts as the first port so when beginning with ‘0’ ports like 6000 that is why the ending port is only 6024 as that range includes 25 actual ports. If this seems confusing then just start on the ‘1’ digit for ranges like 6001-6025. Or if the network administrator doesn’t mind dealing with non-contiguous port ranges for all traffic then something like 6001-6025, 6101-6125, and so on can be even easier to manage. Aligning the different media ranges end-to-end is better practice though as then a single contagious range (e.g. 6000-6099) can be opened in firewalls if required to support internal peer-to-peer client sessions.
Setup the Network
This section is included to provide a complete story but will differ greatly depending on the type of network equipment in the environment as well as how it may already be configured. The environment used for this article is the same Lync 2013 lab used for all past articles which includes a NetGear Pro-Safe GS110TP switch that will be used for managing QoS on the network.
The default configuration on this switch indicates that there are 4 different hardware queues available for prioritizing traffic differentially.
- Review the default DSCP Queue configuration to see which of the desired DSCP values are mapped to which hardware queues.
Note that in this example the queue values are displayed in binary so converting them to decimal will make it much easier to understand. Interestingly this specific switch has both EF and AF41 assigned to the same hardware queue which would not actually prioritize audio and video traffic differently based on the previously selected DSCP values.
DSCP Value Decimal
Class Selector (CS 3) 24 18 011000 1 Assured Forwarding (AF 41) 34 22 100010 2 Expedited Forwarding (EF) 46 2E 101110 2
In a typical production environment any existing network DSCP configuration would dictate the values used in Lync, but for this example the switch configuration will be modified to retain the desired DSCP values.
- Modify the configuration as necessary to provide the required design. For this example the Expedited Forwarding value was reassigned to the highest hardware queue (e.g. 3) to ensure this traffic is forwarded ahead of any other classified data in the switch’s buffer.
With this configuration in place then in the event of network congestion any unclassified traffic will first be delayed or dropped, then the signaling traffic, then video traffic, and finally audio traffic as a last resort.
Configure Lync Clients
What follows are the necessary steps for turning on QoS for Lync clients which are disabled by default, configuring policies to enable Windows desktop Lync clients to tag packets with a designated value, and finally defining a custom port range for media traffic for all QoS-capable registered Lync clients to utilize. Note that mobility clients will not utilize this QoS capability as it is only applicable to Windows and Mac desktop clients and desktop IP phone devices which are registered directly to an internal Lync pool on managed networks; QoS is not applicable for traffic routed over the Internet.
Media Port Ranges
By default Lync Server has port ranges already defined for peer-to-peer media sessions but they are not enabled, thus the default client behavior of using random high ports. The first step is to enable the static port ranges so that Lync clients and devices will receive this information in-band during registration. Yet the default values for the different media ports are actually not configured correctly and all overlap, which is not ideal and should be changed prior to actually enabling QoS.
- Using the Lync Server Management Shell execute the Get-CsConferencingConfiguration cmdlet to display the default Lync Server configuration.
PS C:\> Get-CsConferencingConfiguration | fl client*
Note that the starting port for each type of media is the same port (5350) which means that if the default configuration was simply enabled then all clients would attempt to use the same 40 ports for all modalities. That would prevent any QoS compatible network devices from being able to identify between different payload types and putting them in different queues.
The ClientMediaPort and ClientMediaPortRange parameters are not used by Lync clients but are meant for older Office Communicator 2007 clients which were only able to define a single media port range for all media payloads (audio, video, and application sharing). The parameters highlighted in yellow are used by Lync 2010 and 2013 clients for separate port ranges for each peer-to-peer media modality.
The two ClientSipDynamicPort parameters do not actually do anything and can be ignored (these may be left over from LCS). SIP traffic in Lync 2013 is always client-to-server (not peer-to-peer) and is always TCP 5061 on internal networks to the Lync Front End servers.
- Enter the following Set-CsConferencingConfiguration cmdlet to configure the desired custom port ranges, which were defined in the table earlier in this article, and then enable Lync desktop clients to use these settings.
PS C:\> Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled $true
-ClientAudioPort 6000 -ClientAudioPortRange 25 -ClientVideoPort 6025
-ClientVideoPortRange 25 -ClientAppSharingPort 6050 -ClientAppSharingPortRange 25
-ClientFileTransferPort 6075 -ClientFileTransferPortRange 25
- Re-run the Get-CsConferencingConfiguration cmdlet to verify the proper configuration was applied to the global policy.
PS C:\> Get-CsConferencingConfiguration | fl client*
If any older Office Communicator clients are still in use in this topology than the ClientMediaPort parameters should also be configured with another unique port range of at least 40 ports to cover the multiple modalities included in that range. This articles assumes that only Lync clients are utilized internally in the environment and thus these parameters will be ignored.
To enable DSCP tagging for Windows desktop Lync clients the host operating system is what needs to be configured to perform this action; this is not configured anywhere on the Lync Server. The steps for configuring this on Windows 7 and Windows 8 workstations can be found in the official TechNet documentation on this specific page. As mentioned earlier the guidance in this article will differ slightly in a few spots which will be explained in detail.
For the purposes of this lab, and as a general recommendation to test any major changes before applying them to every domain-joined workstation in the network, the following configuration uses a new Organizational Unit (OU) created in the Active Directory domain to store the computer account of the test workstation running the Lync desktop client.
These same steps can be completed locally on a workstation in the event domain-joined computers are not available for testing in a given environment. Simply use the Lync workstation’s Local Group Policy Editor (gpedit.msc) to define the following Policy-based QoS settings instead of the Group Policy Management tool (gpmc.msc) used for domain controllers.
- On the Lync Front End Server or Domain Controller launch the Group Policy Management tool (gpmc.msc) and then create a new GPO called Lync Client QoS Policy in the desired location. In this example the test workstation’s computer object in Active Directory has been moved into a new OU called ‘Workstations’.
- Select the newly created Group Policy Object and select Edit to launch the Group Policy Management Editor and then browse to Computer Configuration > Policies > Windows Settings > Policy-based QoS.
- Create a new policy in this container entitled Lync Audio and set the Specify DSCP Value option to 46.
- Advance to the next window and select Only applications with this executable name and then enter lync.exe as the application name.
As mentioned earlier the TechNet guidance will differ in a few place, this being one of them. In TechNet the QoS Policy is shown as being applied to any application on the workstation instead of ideally limiting the tagging behavior to only the lync.exe application. The latter practice will prevent other applications (rogue or intended) on the same workstation from accidentally having their traffic prioritized in the event that a randomly selected port happened to fall into a range defined for Lync traffic.
- Advance to the next window and leave the default options selected for Any source IP address and Any destination IP address.
- In the next window select TCP and UDP for the protocol and then select From this source port number or range. Enter the defined port range for audio traffic as the starting port and ending port separated by a colon. (e.g. 6000:6024).
Here is another area where the guidance can differ depending on the source. TechNet outlines the exact guidance shown above, in that only the source port is used to identify traffic and apply the assigned DSCP value to the outbound audio packets. Other directions will often state to set both source and destination ports but this is unnecessary if the QoS configuration is correct in all areas. Also in the event other Lync endpoints which do not not support custom media port ranges are used then the approach above will allow the Lync desktop client to still tag its outbound media even if it’s destined for a port outside of the defined range.
Now that the audio policy is complete repeat these same steps to create new policies for video, and signaling traffic as detailed in the QoS design for this example environment. If additionally prioritizing application sharing and/or file transfer media sessions is desired then create policies for those as well and assign the desired DSCP value.
- Using the defined QoS Policy create new policies for Lync Video and Lync Signaling. Take note that the signaling policy needs to be configured slightly different in that the Protocol is only TCP and the Destination Port (and not the Source Port) needs to be set to 5061 as the Lync client will use a random source port for signaling traffic sent to the Lync Front End Server.
If these changes were applied to the AD domain’s Group Policy (and not the local workstations Group Policy directly) then forcing a refresh of the domain policy on the workstation may be required prior to testing the configuration changes.
- Issue the following command on the test workstation to force an immediate update of the domain global policy changes to be applied to the workstation.
To validate the new configuration on a Lync desktop client exit the Lync application on a workstation and restart it to trigger a registration connection which will refresh any policy settings. (Make sure that the Lync user is assigned to the proper client policy in the event that the previous configuration changes where not applied to the Global conferencing configuration container.)
- Browse to the current user’s Tracing folder to locate the Lync-UccApi logs file to search for the latest provisioning data passed in-band to the client during the registration process.
- Open the Lync-UccApi-0.UccApilog file in a text editor like Notepad and go to the end of the file. Search for a previous instance of the string ucPortRangeEnabled to look for the most recent settings provided in the <provisionGroup name="ServerConfiguration" > section.
The output above shows the various custom port ranges which were defined earlier. If the default settings still appear here then wait a few minutes and then repeat the process until the correct configuration appears on the client.
Next the Windows registry can be viewed to verify that the defined Policy-based QoS parameters have also successfully been imported into the workstation with the Lync desktop client.
- Open the Registry Editor (regedit.exe) on the Lync desktop client’s workstation and browse to the following location to verify the existence of the custom QoS policies.
A new test call between this Lync client and a Polycom VVX phone will show that the Lync client is now using the defined range.
- Capture a new trace on traffic between the Lync client and a VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.
Notice that the destination port on UDP media traffic (the audio payload) to the Lync client (192.168.1.101) now falls within the expected port range (6018). The Polycom VVX phone on the other hand still needs to be configured as an out-of-range dynamic port (2230) was still used for the media sent by the Lync client to the phone.
Also seen is the successful DiffServ tagging of outgoing media packets from the Lync client as confirmed by DSCP 0x2e Expedited Forwarding reported in the packet, which equals 46 in decimal. Even though the Polycom VVX device is not yet configured for QoS the Lync client still tagged traffic that it sent to the phone on a destination port of 2230. Because the Lync QoS policy was configured to use source ports for media then because that traffic left UDP port 6018 on the Lync client the traffic was properly tagged.
The next test is to verify that the signaling traffic from the Lync client to the Lync Front End Server is also classified correctly.
- Capture a trace on the traffic between the Lync client and the Lync Front End server that it is currently registered to. Perform any basic action like placing a call to another Lync user which will generate some SIP traffic to the server. In the following example Microsoft Network Monitor was run directly on the Lync Front End Server to capture the traffic.
The results above show that signaling traffic from the Lync client (192.168.1.101) to the Lync Server (192.168.1.33) is properly tagged with a DSCP value of 24 which would put this type of traffic into a lower priority hardware queue than the media in the previous test based on the configuration enabled on the network switch in this scenario.
Configure VVX Devices
This section is applicable to all 3PIP Qualified Polycom handsets which run on the Unified Communications Software (UCS) firmware. Although the modern Polycom VVX devices are the focus of this section the SoundPoint IP, SoundStation IP, and SoundStructure models can also utilize the identical configuration shown here.
It is unknown if the other currently qualified handsets from Audiocodes and Snom support custom port ranges and if so what their behavior is. An article from Lync MVP Matt Landis briefly shows how to set DSCP values on these other models.
The following configuration settings for the Polycom UCS-based qualified devices can either be manually imported into the phones individually for testing by using the embedded web management interface or in bulk to all devices using a custom provisioning server as detailed in this past article.
Media Port Ranges
As was mentioned earlier these qualified devices do not currently adhere to the in-band media port ranges in Lync so a separate configuration step is require to make sure they utilize listening ports for media in the proper custom port ranges.
- Define the following parameters on the Polycom VVX phones to set the proper starting port for each range of supported media traffic.
In most cases only the first parameter for audio needs to be defined but in the event that some of the VVX models are equipped with the supported USB video camera then it is possible to perform phone-to-phone video calls via Lync. (Phone-to-Lync peer video calling is not yet supported due to the lack of any common video codec between Lync clients and the phones.)
DiffServ values can be individually configured for signaling, audio, and video using another set of parameters.
- Define the following parameters on the Polycom VVX phones to set the desired DSCP value for each mode of supported traffic.
The qos.ip.rtp.dscp parameter applies to all media if it is the only one defined but if the video parameter is also defined then only audio will be tagged using the general qos.ip.rtp.dscp setting. The callControl parameter applies to signaling traffic sent to the Lync Front End server.
A single XML provisioning file can be created with both the custom port ranges and DSCP tagging parameters defined, which would look like the following:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!–Schertz Home Lab Shared configuration file –>
<qos qos.ip.rtp.dscp="46" qos.ip.rtp.video.dscp="34" qos.ip.callControl.dscp="24" tcpIpApp.port.rtp.mediaPortRangeStart="6000" tcpIpApp.port.rtp.videoPortRange.enable="1" tcpIpApp.port.rtp.videoPortRangeStart="6025"></qos>
- Copy the text above into a new text file and save it with a .cfg file extension (e.g. qos.cfg).
- Connect to the embedded web management interface on a Polycom VVX phone from a web browser.
If the device is running UCS firmware version 5.1.1 or newer and the Lync Base Profile is enabled then the web interface may not function as it is disabled by default when used in Lync environments. To temporarily re-enable this feature perform the following steps directly from the phone (as usual this can also be performed programmatically for all phones using a centralized provisioning server).
- Press the Home key and then navigate to Settings > Advanced (enter the administrator password which is ‘456’ by default) > Administration Settings > Web Server Configuration (located at the bottom of the menu).
- Select Web Server and then choose Enabled.
- Select Web Config Mode and then choose either HTTP Only, HTTPS Only, or HTTP/HTTPS.
After the phone reboots the web management interface will again be available. For security purposes it may be desirable to disable this feature again after the configuration file has been imported.
- Connect to the phone’s IP address using a web browser and then go to the Utilities > Import & Export Configuration menu.
- Under Import Configuration select Choose File and then locate the previously created configuration file ( e.g. qos.cfg).
- Click the Import button to confirm the action and then trigger a reboot of the phone.
Now that both the port range and DSCP parameters have been imported into the phone it should behave identically to the configured Lync clients and both QoS features should be functioning in either direction for all media.
- Capture a new trace on traffic between the the Lync client and the VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.
The results above indicate that media sent from the phone (192.168.1.100) to the Lync client (192.168.1.101) is now assigned to the correct port range for its source port (6000) and destination port (6016). This outbound UDP audio traffic from the VVX phone is also properly classified using the configured DSCP value of 46 (0x2E) which is Expedited Forwarding (EF).
The return traffic sent from the Lync client is still allocated within the proper port range as was configured earlier in this article, so now media is successfully defined in the proper ranges and with the ideal DiffServ markings bi-directionally.
The last test is to verify that the signaling traffic from the VVX phone to the Lync Front End Server is also classified correctly.
- Capture a trace on the traffic between the VVX phone and the Lync Front End server that the phone is currently registered to. Perform any basic action like placing a call to the Lync client which will generate some SIP traffic to the server.
The results above show that signaling traffic from the VVX phone (192.168.1.100) to the Lync Server (192.168.1.33) is properly tagged with the DSCP value 24 which will drop this type of traffic into a lower hardware queue than the media in the previous test based on the previous configuration enabled on the network switch. Note that the DSCP value will not be defined on the traffic from the server to the Lync client yet as this article does not cover the QoS configuration on the servers as was explained earlier.
Configure LPE Devices
This section is applicable to all Optimized Lync Phone Edition devices from any of the four current manufacturers.
The previously completed configuration for defining media port ranges for Lync clients applies to LPE devices as well, so no additional steps are required for addressing the media ports.
By default Lync Server already has QoS enabled for any Lync Phone Edition device registered to it. This default behavior is covered in detail along with a primer on DSCP in the previous article Lync Quality of Service Behavior. As was pointed out in that article Microsoft has set the default DSCP value as 40 which is not commonly used for audio traffic in most networks. Since the Expedited Forwarding classification of 46 is used for audio throughout this article then this value needs to be updated to configure LPE devices accordingly.
Be aware that the signaling traffic for LPE devices cannot be prioritized as the following behavior is hardcoded to only apply to the audio traffic leaving the phone.
- Using the Lync Server Control Panel browse to the Clients > Device Configuration section.
- Either edit the existing Global or custom device configuration if one exists, or create a new Site level configuration object if so desired.
- Set the Voice Quality of Service (QoS) value to 46 and the Commit the change.
This modification as well as the previous changes applied to the media port ranges will not automatically be applied to any currently registered LPE devices until a maximum of 8 hours as each device’s own schedule of refreshing Lync policy changes occurs.
- To push the change immediately to one or more devices simply reboot the phone(s) to force a new registration to the Lync server.
To validate the configuration change perform the same steps as in the previous sections to review the audio source port and DSCP marking values in a network trace.
At this point the environment should be correctly configured to support QoS on all signaling and media traffic involved with peer-to-peer media sessions between any internal Lync desktop client, Lync Phone Edition device, or Polycom VVX phone. This includes all peer-to-peer media traffic as well as all signaling traffic between these clients and their registered Lync Front End Server(s).
As mentioned at the beginning of the article to complete the entire QoS story for all internally routed media make sure to additionally configure QoS policies on the Lync Servers so that multiparty conferences will also have their media protected when these same Lync endpoints are instead sending their media sessions directly to the server instead of in a peer-to-peer model. For more details on these different call-flow scenarios have a look at the previous article Understanding Lync Modalities.
An earlier article entitled Polycom CX5100 for Lync 2013 introduced the newest RoundTable device for Lync, briefly discussing the firmware update process. As this product was brand new at the time there had been no newer firmware updates yet released to warrant covering that process in detail.
Now that the CX5100 and the nearly identical CX5500 have been out for some time a few firmware updates have been made available for them. As usual it is always a best practice to utilize the latest device firmware version available to provide for the best experience possible. And like the other Updates articles on this blog site the following table will be updated over time to capture any future releases for these two new products. For details on the older CX5000 models head over to this older article.
The same software release package is applicable to both the CX5100 and CX5500 models so there are no separate download files to worry about. The CX5500 does include additional Polycom UC software similar to what is found in the VVX phones which is already included in the package, but this additional code is simply unused by the CX5100 model.
For details on specific issues addressed in each update check the ‘Resolved Issues’ table listed near the end of the Release Notes for that specific version. Some of the new features provided in future releases are also covered at the end of this article.
|1.0.0||December 2013||Initial Release of CX5100 model|
|1.1.0-10114||May 2014||Hotfixes and support added for the CX5500 model||Release Notes
|1.1.1-10117||September 2014||Hotfixes and security related patches||Release Notes
|1.1.2-32157||October 2014||Hotfixes and new functionality:
- CX5500 touch interface call control options when USB tethered to Lync
- CX5500 embedded UCS firmware upgraded to 18.104.22.16880
|22.214.171.124-4||January 2015||Hotfixes||Release Notes
These new models include a few different available methods for updating the firmware on the device. Older models were basically limited to a single process which was not all that user-friendly. It required installing an application on a Windows PC, physically connecting a Windows computer via USB, reading the documentation to find a little known default device password, and then finally copying the package files to the device using a complicated command line utility.
The newest models have completely redesigned the upgrade process to provide for different requirements. For one-off, hands-on updates the software can simply be dropped on a standard USB flash drive and inserted into the system to trigger an instant upgrade. Yet for bulk updates the software can be retrieved from a central location and scheduled for periodic updates to automatically be applied.
The multicolored LEDs surrounding the three Mute buttons on the camera base of either model are used to indicate the current readiness status of the device when powered on.
- No Light - Device is ready to be used and mute is not enabled. (Or it is powered off.)
- Solid Red – Device is ready to be used and the microphones are muted.
- Flashing Green – Device is powering on or rebooting.
- Flashing Red/Green – Device is performing a firmware update process.
USB Flash Drive
By far the simplest method, and a welcome change over the previous generation device, a single file can be copied to a USB flash drive and inserted in the camera base to trigger an automatic update. This process can be used to perform either an upgrade or a downgrade as the device will apply whatever version firmware is provided. Do not store more than one firmware package on the drive, only copy over the desired version.
- Download the desired firmware package form the table above and then save the .tar file to the root of a USB flash drive. (Do not decompress the package or extract the files.)
- The USB drive should be formatted as FAT32 . (FAT partitions are also compatible but NTFS-formatted volumes are not.)
- Insert the USB drive into the USB Type-A slot located at the base of the tabletop camera unit.
The secondary USB port on the Power/Data Box can also be used but this port is typically the blocked with a small rubber plug. It is simply easier to just use the more accessible port on the camera base.
After inserting the USB flash disk the device (when idle and not actively in a Lync call) will look at the root directory of the volume and search for a valid firmware update package.
- On a CX5100 if a valid firmware file is located then the upgrade process begins automatically within a few seconds. The three mute buttons will begin to alternately flash red and green to indicate that the process has begun.
- On a CX5500 the display will report a successful discovery of the firmware package on the USB disk, prompting to either cancel or proceed with the upgrade. This screen will automatically advance to the upgrade process within a few seconds so there is no requirement to confirm by actually selecting OK. Tapping Cancel within those first few seconds though will interrupt the automatic process and return to the main menu.
On either model the process is the same from this point forward as the blinking red and green lights indicate the firmware is being updated and the process should not be interrupted.. The CX5500 will additionally report the current upgrade status on the integrated display
From this point on do not attempt to use the device, disconnect, or connect anything. Removing the USB flash drive could corrupt the firmware and damage the system.
The device will first download the files from the USB disk and then perform a reboot within one to two minutes. After the first reboot completes it will begin installing individual files in the firmware packages which typically takes about 10 minutes for the first batch of components. A second reboot may be triggered mid-way through this process potentially a third reboot to complete then entire process. The entire process should only take about 15-20 minutes.
After the final reboot the blinking lights will stop and the main screen will be displayed on a CX5500.
- Remove the USB drive.
Although not necessary, if desired the firmware version can be checked to validate the expected version was successfully applied. This is very easy on the CX5500 as it can be looked up on the device itself or via the integrated UCS web management interface (covered later in this article). But on the CX5100 only way to check without connecting from a separate PC would be to review the device log files. (Additionally the control panel application can also be used on either model as an alternative method, covered in the next section.)
The following process is valid for either model (CX5100 or CX5500).
- Connect the same USB flash drive which was just used for the update to a computer and look for a folder on the root directory named with the device’s Serial Number (e.g. 88142541B785DB).
- Open this folder and look for the most recent log file package (e.g. log_1411222116678.tgz) which should have been written to the USB drive after the last boot up process.
- Open the desired .tgz file with a compatible application (like WinRar) and then open the data\log\system_properties.txt file.
- Search for the string “polycom.ver” to locate the reported version (ro.build.polycom.ver) and build number (ro.build.polycom.num) strings in the file. In the example below the device’s current firmware is the 1.1.0-10117 release.
As mentioned a much easier way to do this on the CX5500 is to use the touch interface to browse to the Phone status menu.
- On the device’s home screen select Settings > Status > Platform > Phone and review the Device Software Version value.
Also briefly mentioned in a previous article was the new Polycom CX5100/CX5500 Control Panel application which provides the ability to manage, update, customize, and troubleshoot the devices in ways not possible with the older generation RoundTable models.
Fellow Lync MVP and Polycom employee Brennon Kwok has already posted an excellent article covering the various options in the Control Panel application so all aspects of the utility do not need to be rehashed here. As the focus of this article is on updating the firmware then only the Software Update sections will be covered.
Note that the update processes triggered by the control panel require that the CX5100 or the CX5500 is connected to an Ethernet network, the device has a valid IP address, and has access to the Internet (or to the network location of a custom update server if one is defined).
Also this process cannot be used to downgrade a device as it will only apply newer updates that are stored on the configured update server. The only supported method to downgrade a device is via the USB process shown in the previous section.
|1.1.0-42||December 2013||Initial Release of the Control Panel application||Download|
|1.1.2-74||October 2014||Added USB 3.0 optimization option for reduced cabling arrangements||Download|
The control panel can be used to update the firmware in one of two ways: either immediately or scheduled for a future, reoccurring time.
- Download and install the latest version of the CX5100/CX5500 Control Panel Application from the Polycom Support site on an Windows workstation.
- Connect the CX device using the blue USB 3.0 Type A-to-B cable from the tabletop camera base to the workstation.
- Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and default to the System Information screen under the System section.
Note that the current Device Software Version is displayed in the screen above. Clearly this is a much easier way to verify the current firmware on a CX5100 than the log-based approach shown in the previous section.
The following steps walk through the process of trigging an immediate update over the Internet and without having to download the firmware to a USB drive first.
- Switch to the Software Update menu under the System section and select the Update Now button to initiate an upgrade process.
The device will then connect to the currently configured update Server source and look for a package different than what is currently installed. By default the central Polycom update server which is available over the Internet is defined which always contains the latest publically available firmware package. The exact location is not listed on this menu but is simply shown as ‘polycom’. The next section of this article will show how to point the device to a custom distribution point instead of using the default Polycom server.
- Once the update process begins the control panel will change to show on the update status. Disconnecting the USB cable from the PC at this point will not cause any problems as the device is using it’s own Ethernet connection to retrieve the package directly from the server. The only thing the control panel is doing at this point is reporting the upgrade status.
The remainder of the upgrade process is exactly as described in the USB Flash Drive section earlier in this article. Once complete the control panel will reconnect to the device.
- If the focus changes to the Profile Editor section the device password may be prompted for. Simply hit Cancel and then switch back to the System > System Information screen where the new version can easily be confirmed.
These steps show how to schedule an automatic update using software currently posted to the Polycom update server.
In order to modify the configuration of the device the device password will be required. The default password is the serial number of the unit, but be aware that the tabletop camera unit and the main box typically placed on the floor have different, unique serial numbers. The serial number located on the main floor box is what should be entered here, not the serial number found on the camera base. An easier method to retrieve the serial number is to simply use the control panel as shown in the following steps.
- Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and show the System Information screen under the System section.
- Record the Product Serial Number (e.g. 88142541B785DB) as this is also the default device password which will be prompted for in the next step.
- Switch to the Profile Editor section and the control panel application should request the device password. If it does not then either exit the control panel application and restart it, or go to the Load Profile menu in the bottom left corner and select Load from Device.
- Enter the current device password.
- Select the Software Update menu and then select a day under the Update Frequency menu and as well as a time under the Update Time menu.
The example above shows that at 4:00AM device local time every Tuesday the public Polycom update server will be contacted to check for any updates. If at that time a newer version is found on the update server then the same update process and behavior documented earlier in this article will begin.
- To optionally change the firmware distribution point simply replace the text ‘polycom’ with a valid URL of a web server hosting the desired firmware package (e.g. http://server.domain.com/directory/)
Point to the directory where the desired firmware package has been expanded. To prepare the source directory extract the .tar file into the desired location so that the ‘millennium’ folder created by the extraction process is located in the directory that pointed to. Do not point directly to the millennium directory in the update Server path as that is what the device looks for.
For example a subdirectory named ‘update’ was created at the root of the web server in this example and then the latest firmware package was extracted into that directory which automatically created a millennium subdirectory. For future updates make sure to delete all previous files before extracting the new package.
Note that if the Update Server path is changed this also changes the location that the device will go to get updates when the previously discussed Update Now process is manually triggered.
To return the configuration to the default Polycom server simply enter ‘polycom’ as the Update Server value and the device will recognize that name and utilize the hardcoded distribution URL.
- Click the Apply to Device button to write the configuration changes to the device. The update process will begin at the scheduled date and time.
Web Management Interface
This approach is only valid for the CX5500 model as the embedded UC Software stack includes the same web service that the Polycom VVX phones models utilize. Just as with those phones the CX5500 can be updated remotely by accessing the embedded web interface, signing as as an administrator, and then updating the device.
Note that the password used to remotely connect as an Admin or User to the Polycom Web Configuration Utility is not the same as the device password used in the previous step for the control panel application. The embedded UCS stack utilizes its own separate password which is identical to the VVX phones. The default Admin password is ‘456’ and the default User password is ‘123’.
- Connect to the device’s IP address in a web browser.
- Leave the Login As selection on Admin, enter the password (e.g. 456), and click Submit.
- Select the Utilities > Software Update menu.
Note that the options shown above are the same as what the control panel application provides. Whereas the control panel has the immediate update and scheduled update options in different locations the web management utility has them both on the same page.
- To trigger an immediate update process identical to what was covered in the previous section simply click Update Now.
- Alternatively to schedule the update process to be triggered at a later date and/or time configure the Update Frequency and Update Time as desired and click Save.
Additionally the Update Server URL can be changed here, as instructed in the control panel, when needing to utilize a central destitution server other than the public Polycom update server.
This section will include details on some of the more important capabilities added throughout the various updates.
- When a CX5500 model is USB tethered to a Windows workstation running the Lync 2013 desktop client the touch panel on the device can now be used to Answer or Reject an incoming Lync call. The established call can also be placed on Hold or Ended directly from the device.
- When simultaneous audio calls are active on both the tethered Lync client and via the embedded SIP telephony client then the calls can be individually managed using new Calls and PC Lync buttons at the top of the screen.
- The CX5500 model also contains newer embedded Unified Communications Software (UCS) to bring it in line with the current VVX firmware release of 5.2.0. Be aware that selecting the Lync Base Profile in this new release will disable the embedded web management interface as described in this previous article.