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.

Static Routes

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 rmxice@mslync.net).

• 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.

Lync Configuration

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 ‘rpp@mslync.net’ is chosen.

New-CsTrustedApplicationEndpoint -TrustedApplicationPoolFqdn video.schertz.name
-ApplicationId video -SipAddress sip:rpp@mslync.net

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.

Enable-CsTopology

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

Polycom Configuration

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.