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 email@example.com).
- 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 ‘firstname.lastname@example.org’ is chosen.
New-CsTrustedApplicationEndpoint -TrustedApplicationPoolFqdn video.schertz.name
-ApplicationId video -SipAddress sip:email@example.com
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.
20 thoughts on “Polycom RPP Configuration for Lync”
I have a dumb question. If you already a front-end pool installed in Lync 2013. To install another FE pool for HA, do you update the existing certificate or create a new one with the new SAN names?
Each pool should have its own unique certificate, which could be shared among the servers in that specific pool. But not shared across pools.
Nice article. I’ve recently implemented RC at a customer site and think its a great solution for blended meetings in a Lync centric environment, particularly with the Polycom content sharing suite. With the ability to retain Lync scheduling and joining workflow a major advantage over the competitive software inter-ops out in the market.
Any idea when the Group series endpoints will be upgraded so the calendaring feature recognises a RC enabled Lync meeting and cascades back to the DMA, instead of forcing everything onto the AVMCU as is the current predicament?
HI Jeff, in the past it was stated in your 2011 article (in regards to setup with DMA): “there is no need to define the RMX within the Lync Server topology.”
In this article are you stating we now need to define the RMX along with the DMA as a trusted application? I am asking because we have the DMA setup with Lync and signaling as taking place but I see the media being routed from the client directly to the RMX. This is causing issues as due to NAT (client on private and RMX on public IP) and I was hoping media would proxy through the Edge server but it is not. Will I need to setup the new “ICE configuration” shown above for this to work?
Disregard any conflicting guidance from older articles as the integration, and thus best practices have changed over time. For the past few years the guidance is that both DMA and RMX must be defined in Lync. The RMX needs this in order to support features like ICE, regardless of signaling and media paths.
Is there a document or blog release that can help with testing the Realconnect environment, I have followed everything properly with no errors indicated and Realconnect is not working. It seems that the Bridge can receive calls from Lync through the DMA Routing but when an AV/MCU Cascade is dialled from the RMX to the Lync server then nothing happens.
The latest solutions deployment guide can be found at the bottom of this page: http://support.polycom.com/microsoft
We have deployed solution with 2 RMX’s, however, second RMX cannot register to Lync. Lync is stating about certificate, it is expecting a sertificate with different name than what the RMX real FQDN is. Other RMX registers just fine. Application endpoint URI’s are unique within the environment.
Also calls to that RMX with failed registration works when calling within enterprise networks, but not from the outside.
Each RMX should be configured using the same procedure, with a unique FQDN for each’s Signaling IP address. You cannot use the same certificate on both RMXs, each one requires its own unique server certificate. The RMX that is not configured correctly will not be able to leverage the Edge Server, hence external call failure. I always recreate certificates from scratch in these scenarios and most of the time that resolves the issue. The most common mistakes are made during the certificate creation and installation process so that is worth revisiting.
Can Skype for Business connect to Polycom RMX 2000? I know SFB publish new role is VIS, is this related for connection between SFB and Polycom like as Cisco?
VIS is not applicable for Polycom solutions as they have much more native capabilities than even VIS can provide. To support Skype for Business clients and servers you need to make sure your RMX is running at least 8.5.4 or 8.6 firmware.
I tried to get the Get-CsTrustedApplication | fl ServiceGruu on S4B but it does not appear nothing when run the command. Is still configurable the command Gruu on polycom platform for the ICE configuration method with S4B?
Try the cmdlet without additional parameters, maybe you have a formatting issue.
Have you ever came across an issue where a SFB clint dials into a VMR on the RMX but the call fails due to an error “video not accepted”?
We recently upgraded from Lync 2013 to SFB and since then we are having this issue. When the RMX is on version 126.96.36.199 we are able to get internal SFB clients working but the RMX does not pick up the Edge server. When we upgraded to 188.8.131.52 , 8.5.10 and 8.5.11 the RMX picks up the Edge server but then both internal and external SFB calls to the RMX fails due to “video not accepted”. This issue has been sitting with polycom support now for almost 2 months but they still cant find a solution.
Normally that message indicates a media encryption mismatch. Make sure that that conferencing profile on the RMX (or DMA if deployed) is still set to use encryption when available. That being said your issue does sound more like a media relay/reflexive setup problem. I would check that the RMX configuration for ICE (via the ServiceGRUU) is still correct as well. It’s possible the upgrade could have lost or reverted some part of the configuration.
Integration of Polycom platform (composed of: RMX 1500 – V.85, DMA 7000 – v.8.6..) And Skype for Business (Front End, Edge) :
– The RMX has its Lync room recorded on SFB server; with Wilcard certificate injected into the RMX;
– The DMA is registered with the SFB server; with Wilcard certificate injected into the DMA;
– For the trusted application, static routes have been created on the server SFB.
After these configurations, the result are below :
– The presence of Polycom servers appear as “unknown presence” at the SFB clients;
– When launching the call, it’s still “connecting” on MCU.
Please, can i’ve an issue?
Tanking for your support
Rebecca, wildcard certificates are not supported with this integration, you must use SAN certificates with the appropriate FQDNs on both the RMX and DMA. Also VMRs are not registered directly on the RMX but must be defined directly on the DMA, either manually or automatically. I suggest reaching out to your Polycom partner or support channels for assistance.
Does RMX1500 v8.5 can integration with Skype for business 2015 and DMA 6.4 ?
It’s possible but depending on what feature-set you are looking for it’s best to use the approved/tested releases of DMA and RMX together, especially for RealConnect. It would be recommended to upgrade to RMX 8.7.1 as that is version tested with DMA 6.4.
In My client polycom video conferencing, we are currently experiencing issues with the RPGS 500.
the RPGS 500 cannot make a H.323 Call but can make a SIP call