The past video conferencing integration articles have primarily discussed the Real-time Media eXperience (RMX) platform, but the  Distributed Media Application (DMA) also supports direct integration with OCS and Lync and is the preferred SIP path when both devices exist in an environment.

Out-of-the-box DMA integration instructions are included in the Polycom UC Deployment Guide for Microsoft Environments document, but the steps shown don’t address the scenario where an RMX is already integrated in the network and DMA is being introduced.  The documented approach would be to simply define DMA as another Application Pool and define a new route for video calls.

But there is a simpler way to approach adding DMA into an environment where there is already a functional RMX integrated into Lync.  The premise is that SIP signaling will primarily be directed to the DMA instead of the RMX for the chosen routing domain, yet signaling and certificate-based TLS signaling will still be supported for the RMX.  As the RMX should typically remain a Trusted Application to support certain integration features or outbound SIP calling into Lync then it would not be a good approach to simply replace the RMX configuration with the DMA information.

Calling Scenarios

Before addressing the configuration steps it is important to take a step back and understand the various call routing scenarios that are available with RMX and DMA integration with Lync Server.

Lync Video Call to RMX

This is the most basic integration and is the default approach when no DMA is involved.  Because the called SIP URI is not defined on any SIP-enabled Lync user in the forest then Lync will fail to locate any presence information for the contact; this is by-design. But when attempting to call this contact Lync will find the configured static route for the Match URI (mslync.net) and then send the request to the defined FQDN in the route’s Transport parameter (rmx.schertz.local).

Media is then negotiated directly between the endpoints over RTP or encrypted STRP and depending on the capabilities of the specific RMX model either Real-time Video (RTV) or H.263 codecs are used.

Note: Although the same approach applies to Office Communications Server as it does to Lync there was a limitation which prevented the using a MatchURI value that was the same as a defined SIP domain in OCS. Thus past recommendations were to typically use a unique entry like “video.contoso.com” when routing calls to the RMX. With Lync Server it is now possible to use the same namespace which simplifies both deployment and end-user experience, as well as provides native federation access to the RMX for external partners. The examples in this article reflect this best practice of using the primary SIP domain as the MatchURI value.

Lync Video Call to DMA

In this scenario a Lync user places a video call to a meeting room defined instead on the DMA (71444@mslync.net).  Identical to the scenario above this SIP URI is not defined on a Lync user so no presence is shown and the defined static route is used to send the request to the defined FQDN in the route’s Transport parameter (dma.schertz.local).

For this simple integration only the DMA needs to be configured in Lync Server as a trusted host and issued an SSL certificate as all TLS encrypted SIP signaling is sent from Lync to the DMA. During call setup SDP instructions in the SIP messages will facilitate media negotiation directly between the Lync client and the RMX (or through an Edge Server for external or federated calls). Because the RMX’s media interface IP address is offered during this process and the endpoint will attempt to connect directly to it then there is no need to define the RMX within the Lync Server topology.

Lync Video Call to a Registered Virtual Meeting Room

With the addition of Virtual Meeting Room (VMR) registration in RMX release 7.2 there is now a calling scenario that offers presence registration for the meeting room but this is handled directly by the RMX and not via DMA.  Thus supporting this scenario in the same environment would require that the RMX is also defined in Lync as a trusted host and issued an SSL certificate, although no routing configuration is needed.

Here a Lync user places a video call to a meeting room (msdemovmr@mslync.net) that is defined on the RMX (and not on DMA) which is also directly registered as a defined Lync user.  Presence for the standard Lync user appears and when a video call is started Lync sends the traffic directly to the RMX in the same manner if it was any other Lync endpoint.  The call flow is identical to a native Lync peer-to-peer call.

Lync Inbound Video Call from an RMX

This final scenario is less common, but is often used for testing calls or when a specific virtual meeting room on an RMX is preconfigured to place outbound calls to invite other SIP participants automatically.  A common use for this would be to automatically call specific Lync users when someone dials into a certain virtual meeting room.  In this case the RMX sends the initial SIP INVITE to the Lync Server and thus SIP signaling would be handled directly between the RMX and Lync without the DMA involved at all.

Configuration

In order to configure the new DMA in an environment with RMX already configured in Lync yet still support all of the above calling scenarios then here are the four basic areas to be addressed:

• Define a new FQDN for DMA and create a new DNS Host (A) record
• Request a a new SSL certificate and import it into DMA
• Add DMA as a trusted application to Lync
• Update the current static route in Lync with a new route to DMA

1. Name Resolution

Create a new DNS Host (A) record in the same domain namespace where the current RMX DNS Host record exists for DMA.  The address should be the virtual IP address assigned to DMA (or the DMA cluster) as this is where signaling traffic needs to be routed to.

• Using the same domain name space as the Lync Server a new record is created for dma.schertz.local and set to the virtual IP address of the DMA.

2. SSL Certificate

Using the directions outlined in this previous blog article submit a new online certificate request against a Windows Enterprise CA using Internet Information Services (IIS) Manager on the Lync server (or any other Windows 2008 Domain member server).

• Using the DMA FQDN of dma.schertz.local as the certificate Common Name a new certificate is created and submitted to an internal CA.

The Certificates MMC snap-in should be used to export the certificate to a PFX file.  Do not export the file using the IIS Manager as it will not provide the option to include the Root CA’s public certificate in the package which DMA needs in order to trust the issuing CA of the Lync Server’s SSL certificate (assuming that the DMA certificate is being requested from the same CA that issued the Lync Server certificate).

• From the Certificate Export Wizard select the option to Export the private key.

• Also select the option to Include all certificates in the certification path.

• Enter a very basic password for the PFX file when prompted as some formats of complex password strings can prevent the PFX from expanding inside the DMA (or RMX).  Something very easy like password works every time, avoid numbers, spaces, or any other special characters.  (Don’t get too creative here unless you enjoy troubleshooting TLS errors; you’ve been warned.)

Finally the certificate package needs to be imported into DMA.

• From the DMA web management interface select Configuration > System > Certificate Management then browse to the exported PFX file and enter the password used to protect the PFX file during the original export.

• Restart DMA to apply the new certificate.  It is recommended to delay this restart until the following Lync Configuration steps are completed.

3. Lync Trusted Application

Assuming that the RMX was previously integrated using the best practice recommendation of defining a multiple server application pool in Lync then the DMA is simply added as another trusted computer to the existing pool.  As the pool itself is trusted by Lync then any new servers entered into the pool will automatically inherent the existing trust configuration.

• Using Topology Builder locate and expand the existing Trusted Application Server pool where the RMX is currently defined.

• Select the New Server action while focused on the application pool object and enter the DMA FQDN which was defined in the first step for the DNS Host record (dma.schertz.local).

• Publish the Topology to save these changes.

4. Lync Routing

Because static routes in Lync cannot be modified the previous route to the RMX needs to be deleted and then a new route created for DMA.

• Simply running the Get-CsStaticRoutingConfiguration cmdlet will show all defined routes in a single value and can be difficult to identify the correct data.  Run the cmdlet with the additional parameters as shown below to expand any additional routes separately.

Get-CsStaticRoutingConfiguration | Select-Object -ExpandProperty Route

Transport               : TransportChoice=Certificate=Microsoft.Rtc.Management.
                          WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=
                          rmx.schertz.local;Port=5061
MatchUri                : mslync.net
MatchOnlyPhoneUri       : False
Enabled                 : True
ReplaceHostInRequestUri : False

• If there is currently only a single route in the Lync environment then it is easiest to simply null-out the route parameter using the following cmdlet.

Set-CsStaticRoutingConfiguration -Identity Global -Route $null

• But if multiple routes exist for other unrelated applications then only the RMX route must be deleted manually using these two separate cmdlets.  The first cmdlet recalls and stores the desired route value into a variable and then the second cmdlet deletes the specified route.

$delroute = Get-CsStaticRoutingConfiguration -identity global | Select-Object -ExpandProperty Route | Where-Object {$_.MatchUri -eq “mslync.net“}

Set-CsStaticRoutingConfiguration -identity global -Route @{Remove=$delroute}

At this point the new routing configuration is re-entered using the DMA FQDN as the target instead of the previous RMX FQDN.  The same MatchURI will be used in the new route.

• Run all of the following cmdlets to store the new route data into a variable, write the data into the Lync routing configuration, and then save the changes to the topology.

$route = New-CsStaticRoute -TLSRoute -destination “dma.schertz.local” -port 5061 -matchuri “mslync.net” -usedefaultcertificate $true

Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}

Enable-CsTopology

• To validate the new configuration run the Get-CSStaticRoutingConfiguration cmdlet again with the additional parameters just like before.

Get-CsStaticRoutingConfiguration | Select-Object -ExpandProperty Route

Transport               : TransportChoice=Certificate=Microsoft.Rtc.Management.
                          WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=
                          dma.schertz.local;Port=5061
MatchUri                : mslync.net
MatchOnlyPhoneUri       : False
Enabled                 : True
ReplaceHostInRequestUri : False

Given the flexibility shown in this article then if desired there could actually be multiple static route configured so that calls could be directed to either DMA or RMX in the same configuration.  The approach used here is the least-complicated and supports the best-case scenario of routing all normal calls to the DMA yet still supports the additional configuration steps for calling presence-enabled, registered meeting rooms directly on the RMX.