This blog article has been a long time in the making and has been virtually written (and subsequently unwritten) multiple times in my head. Over time it appears the concepts are starting to become more widely understood, but then the same misunderstandings pop up again. Thus this article has been reborn yet again and will take a step-back from the previous articles to address the entire concept of integrating video conferencing infrastructure solutions directly with Lync Server 2010. This article is not intended to replace other documentation or serve as a detailed walkthrough of how to configure the integration. It is meant as a companion reference designed to explain the concepts in greater detail as well as provide best practices born directly from field engagements and real-world usage.
On the surface dealing with the configuration of Lync and Trusted Applications seems complex and confusing, but once the moving pieces are understood and it is clear which parameters relate to each other, and which have absolutely no bearing on each other, only then does this seemingly mysterious topic seem fall into place.
The primary focus of this article is the Polycom RealPresence Platform which is a re-branding of the Polycom UC Intelligent Core suite of solutions including the RMX and DMA products. The concepts in this article only address video conferencing MCU integration with Lync and will not discuss video endpoint (e.g. room system) integration. Some of the same concepts also apply to other third-party vendor product integration with Lync, although those solutions require additional hardware not shown in the call-flow diagrams below and also do not support some of the advanced features that are highlighted.
Additionally there is some misleading (and at this point simply inaccurate) documentation floating around out on the Internet that also adds to confusion on exactly how all this should work. The best source of integration documentation for the Polycom solutions is included in the Polycom Unified Communications Deployment Guide for Microsoft Environments document which is constantly updated as new features and functionality becomes available. This article then goes one step further to more deeply explain the components used by this integration.
The Completed Puzzle
The following diagram outlines a number of concepts which are later described in detail so that the proverbial light bulb should go on. There are two different pool configurations shown side-by-side (Single versus Multiple Computer) as well as two different potential call flow paths depicted top-to-bottom (Registered VMR versus SIP URI Dialing). Only one of these two types of pool configurations is required (although a multiple computer pool is recommended for Polycom integration) but this example shows both in the same environment to point out that multiple pools can coexist with different hosts and also to clearly demonstrate the configuration differences between each.
Before diving into all of the individual components and concepts depicted in the diagram each item has been briefly defined as a reference:
-
Lync Endpoint – A native Lync client used to place a video calls to the various potential users and SIP addresses listed in the diagram.
-
Front End Service – The Lync Server Front End service which handles the SIP signaling traffic and decides where to direct it to.
-
Trusted Application Computer – The basic Lync Server topology object that defines an external application residing on a specific host which is to be trusted by Lync for secure communications.
-
Trusted Application Pool – A Lync Server topology object that is configured as either a single or multiple computer pool. A single computer pool functions as both a Computer and Pool object as the defined FQDN is the application’s hostname. A multiple computer pool is simply a grouping of one or more Trusted Application Computer objects.
-
Trusted Application – A Lync Server topology object that points to a Trusted Application Pool and defines the trust required to support secure communications between Lync and the external application. All objects defined in that destination pool are inherently trusted.
-
ApplicationID – A descriptive name used to identify the Trusted Application within the Lync Server topology.
-
Static Route – A SIP routing configuration in the Lync Server topology used to locate an existing external trusted application host to accept request for users in a specific SIP namespace.
-
Destination – The hostname of the external application defined in a static route where requests to a matching SIP URI are routed to by the Lync Server.
-
MatchURI – An arbitrary namespace defined in the Static Route which users enter as part of a complete SIP URI to connect to resources on the external application hosts.
Understanding the Pieces
Prior to configuring the Lync Topology there are two prerequisite steps which must be addressed so that Lync will be able to resolve the selected hostname of the external application as well as establish a secure TLS connection utilizing standard X.509 certificates.
Application Hosts
Before Lync can be configured to trust an external application it must first be able to communicate with it at a network level. The hosts running these applications are traditionally other Windows domain Member Servers and thus would already be defined in Active Directory and DNS. Since video conferencing equipment is often not integrated with Active Directory and is often managed by a separate team then the first step is to configure basic name resolution.
- Identify the SIP signaling interface on the RMX or DMA as that is the only IP address that Lync will connect to for signaling traffic for each host. Any other addresses for management or media interfaces do not need to be defined anywhere in Active Directory or Lync.
- Once the proper IP address is known then a DNS Host (A) record must be created for each host using a unique Fully Qualified Domain Name (FQDN). The multiple hosts (e.g. rmx.schertz.local, dma.schertz.local, etc) in this example are all defined in the same domain namespace as the Lync Server: lync.schertz.local.
Note: The FQDN selected to identify the application host is completely irrelevant in terms of how Lync users place calls. The only requirement of this FQDN is that it is also used as the Common Name parameter for the requested SSL certificate that is installed on the external host. This also means that the FQDN does not need to, and typically does not match the MatchURI parameter. It is a best practice to use the AD namespace as the Lync server to define the application host records.
There is no technical reason that the host FQDNs could not instead be defined as rmx.mslync.net or dma.mslync.net, but it is best practice to define the hosts using the same AD namespace as the Windows servers are using, this simplifies the configuration and keeps the concepts separate. In smaller environments where both the AD namespace and the primary SIP domain are identical then all defined parameters will use the same namespaces.
Certificates
In order to support TLS communications between Lync and each of the hosts defined as Trusted Application Computers a standard SSL certificate needs to be requested against a trusted Certificate Authority (internal Enterprise or public third-party) and imported into each host. The Common Name portion of the certificate’s Subject Name field must match exactly the previous defined DNS Host record for the individual host. This name has nothing to do with the SIP address namespace that Lync users will place video calls too.
- The CN parameter of the certificate Subject Name field is shown below for two of the four hosts in this scenario.
Trusted Application Pool
The way to define a trusted host in Office Communications Server was pretty straightforward; there was one place to define either an IP or FQDN depending on if TCP or TLS was required. But with the introduction of the Trusted Application concept in Lync 2010 there are now a number of objects which need to be defined in Lync to build the entire trust relationship.
The primary building block in this concept is a Trusted Application Pool, which must be defined first. The diagram depicts both a Single Computer Pool (the orange pool object on the left side) and a Multiple Computer Pool (the blue pool object on the right side). Either the Lync Server Topology Builder or the Lync Server Management Shell can be used to define either type of pool and then publish the changes to the Lync topology.
- When creating a Single Computer Pool both the pool name and the server name share the same parameter and the value should be the FQDN of the server hosting the third-party application to be trusted. The examples below demonstrate how a single computer pool in the example can be defined in Lync Server using either tool.
New-CsTrustedApplicationPool -Identity rmx.schertz.local -Registrar Registrar:lync.schertz.local -Site Chicago -RequiresReplication $false
- But single computer pools are not typically used for video integration as a Multiple Computer Pool is the recommended configuration. This allows additional application hosts to be added to the same pool, simplifying the overall setup and design. The PowerShell example below demonstrates how the multiple computer pool in the example was defined in Lync Server.
New-CsTrustedApplicationPool -Identity video.schertz.local -Registrar Registrar:lync.schertz.local -Site Chicago –ComputerFqdn dma.schertz.local
Note: The example pool name above is completely irrelevant in terms of what namespace will be used to route calls to the video hosts. The descriptive name of video.schertz.local was used but it could just as easily be defined as polycom.schertz.local or foo.anything.org. It is only an identifier for the topology object and offers no functional purpose. Even the SIP domain itself can be used as the Pool FQDN as Lync does not prevent this configuration and it works fine.
Although this scenario uses different values for the Pool FQDN and the MatchURI there is no requirement that those values match or not. For demonstration purposes unique values have been used to clarify this concept, but in practice it is common to set the Pool FQDN to the same value as the MatchURI for simplicity’s sake and also to make it easy for any administrator to identify at a glance which pool a specific route might be associated with.
Trusted Application Computer
- To then create the additional hosts as a Trusted Application Computer in an existing multiple computer pool the following cmdlet can be used for each host, or Topology Builder can instead be used to configure the pool. These entries must match exactly the selected FQDNs for each host which were defined in DNS.
New-CsTrustedApplicationComputer -Identity rmx1.schertz.local -Pool video.schertz.local
By default when a new Trusted Application Pool is created Lync will enable the pool for replication of configuration database information. As only other Lync Server roles typically participate in this data replication process then it is recommended to disable this replication when defining pools for video conferencing hosts.
- Either use the Lync Topology Builder to uncheck the Disable replication of configuration data in this pool setting or use the Management Shell set the -RequiresReplication parameter to $false.
Set-CsTrustedApplicationPool -RequiresReplication $false -Identity TrustedApplicationPool:video.schertz.local
Trusted Application
Now that the pools are defined Lync must be configured to actually trust these application hosts by creating a new Trusted Application. It is a common mistake to omit this step and just publish the Lync topology, but Lync does not automatically trust a defined pool. The new Trusted Application cannot be created using the Lync Topology Builder tool, only PowerShell can be used.
- The following cmdlets show how each trusted application pool would be linked to each pool, with a unique application ID for each object.
New-CsTrustedApplication –ApplicationId BetaVideo -TrustedApplicationPoolFqdn rmx.schertz.local -Port 5061
New-CsTrustedApplication –ApplicationId ProductionVideo -TrustedApplicationPoolFqdn video.schertz.local -Port 5061
The specified Port is what Lync attempts to connect to the remote application host over, this parameter is not defining any type of listening port for the application on the Lync Servers themselves. It is a destination port on the external application host’s signaling interface, not a source port on any Lync Server. Lync Server already listens for incoming SIP traffic over 5061 by default from clients, other Lync servers, and trusted applications.
Note: The Application ID value does not need to match anything else in the configuration. It is often thought that either the Pool name or the Application ID need to match the MatchURI or the SSL certificate Common Name, but these are all untrue. Neither the Application ID nor the Trusted Application Pool FQDN bare any relevance to the actual SIP addresses used to route calls to the external hosts. This value is just an identifier for the topology object.
Whether Topology Builder and/or the Management Shell are used to configure the various Trusted Application settings they must first be published to the topology before Lync can use them.
- Either select Action > Topology > Publish… from Topology Builder or run Enable-CsTopology from the Management Shell.
Static Routes
Just as with creating the Trusted Application, configuring static routes also can only be performed using PowerShell. Mike Stacy has documented the processes for creating or deleting static routes in Lync and these articles should be referenced for additional details and examples.
To create new static routes in Lync Server the management shell must be used. Only a single route is required, but multiple routes, using unique MatchURI values can be pointed to either the same Trusted Application or unique Trusted Applications. This flexibility supports deployments from a single host and single domain to multiple hosts with a large number of unique SIP domains.
- The routes for this article’s scenario are created using two sets of cmdlets. The first cmdlet in the each set defines the new static route and saves the results to a variable ($route). The second cmdlet recalls that variable and adds it to the multi-valued route parameter. Each set defines a unique route, one for each of the Trusted Applications in the example scenario.
$route = New-CsStaticRoute -TLSRoute -destination “rmx.schertz.local” -port 5061 -matchuri “beta.mslync.net” -usedefaultcertificate $true
Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}
$route = New-CsStaticRoute -TLSRoute -destination “dma.schertz.local” -port 5061 -matchuri “mslync.net” -usedefaultcertificate $true
Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}
- As static routes are not part of the actual topology (and not manageable in Topology Builder) then there is no need to run the Enable-CsTopology cmdlet after running the cmdlets above. The changes will be committed immediately and depending on the size of the deployment and replication intervals then it may take several minutes before Lync clients are able to use them.
By defining a new, unique MatchURI value and pointing each route to the associated Trusted Application Computer FQDN then Lync clients will be able to route calls to either application using the appropriate MatchURI value in the dialed SIP URI.
- Looking at the static route cmdlets above it is clear that the Destination parameter matches the FQDN of the defined Trusted Application Computer for the external host, not the Trusted Application Pool in multiple computer pool configuration. (In a single computer pool the values are one in the same.). This highlights the fact that the route simply points to the host, not to a Trusted Application. There is no 1:1 relationship between a route and a pool as once the Trusted Application is defined in Lync then it can be used for any supported purpose as Lync ‘trusts’ this host and will securely communicate over the network to it.
- If during a call attempt the Lync Server fails to resolve the Destination FQDN against a defined DNS record then it will forward the request to an Edge Server to see if the FQDN is actually an external SIP domain via Federation. But if no Edge Server is deployed in the environment then Lync will fail to locate the dialed SIP URI and will immediately fail the call with the result code of 0xc3e93d6a-SIPPROXY_E_CONNECTION_UNKNOWN_SERVER.
- Most examples of creating new routes utilize the default Route Collection but it is possible in Lync to define a new route collection using the New-CsStaticRoutingConfiguration cmdlet. By setting the target identity to a Lync registrar like a Front End Pool or Director (e.g. service:registrar:lyncpool1.contoso.com) then separate route collections can be used to define different destinations. This flexibility would beneficial when geographically dispersed Lync pools need to route traffic to separate trusted hosts which are local to each pool.
MatchURI
The MatchURI parameter as defined in the static route is often the most misunderstood component of the entire scenario. This parameter’s sole purpose is to define which SIP requests will be routed to the external application. It is defined as the Matching URI Domain setting in Office Communications Server (OCS) or simply the MatchURI parameter in the Lync Server.
- The MatchURI value is completely independent of all other configured parameters and does not need to match anything else in the configuration. Not the Application Pool name, not the Certificate Common Name, not anything. It is another very common mistake to assume that this parameter must be set to the same value as anything defined in the Trusted Application settings.
- The value must be unique per route collection, but the same value can be used in multiple routes if they are defined in different collections (e.g. Global and Pool Registrars)
- The value can be set to the same string as an existing SIP domain in Lync. In fact it is best practice to define the MatchURI as the same exact value as the primary or most commonly used SIP domain. Since the large majority of users in the this scenario are configured with SIP URIs in the primary SIP domain namespace of mslync.net then the MatchURI is also defined the same.
Question: So how does Lync forward SIP traffic to the external host when the called SIP URI is using the same SIP domain as other regular Lync users?
Using the scenario in this article as an example a user would attempt a video call to 771005@mslync.net and because mslync.net is a defined SIP domain in Lync then the Front End server will parse the database to locate a Lync user account configured with this SIP URI. But a Lync user with this address does not exist as this SIP URI is simply a dynamic URI typed in to the Lync client by a user (or an Active Directory contact, or personal contact). Since Lync cannot locate a SIP-enabled user in the database with that address then it will fall back to the static routing configuration to see if there is anything else it can do to complete the call. Since a static route is defined with a MatchURI in the same namespace of mslync.net then Lync will forward the SIP invitation to the destination host in that route, which would be the signaling IP:Port of the DMA.
Note: When integrating with OCS 2007 there exists a limitation that the Matching URI Domain value cannot be the same as any currently defined SIP domain, so common practice was to use a unique value that appeared to look like a sub-domain of the SIP domain which was most commonly assigned to users. For example a value of video.contoso.com would allow users accustomed to seeing contosto.com as their SIP domain to simply dial 1001@video.contoso.com to call the RMX. This limitation does not exist in Lync Server, thus the shift in recommendation to use the same namespace.
- The primary benefits to using the same domain as the SIP domain are a simplified configuration allowing users to just append the desired virtual meeting room ID (e.g. 1001) to the SIP domain they are already accustomed to using, as well as the ability to leverage any existing Edge federation configuration. This allows external users and federated contacts to call the same virtual meeting room using the same SIP URI as internal users. This functionality can be prevented via Lync External Access Policies if external access is undesirable.
Contacts
Since the static routing scenarios utilize a SIP URI then traditionally users would just type in the desired SIP address on-the-fly in their Lync client. As the address does not resolve to any object within Active Directory and also does not match any external federated domain then Lync will display Presence Unknown.
- For example, to call a virtual meeting room defined on the DMA a Lync user would type “771005@mslync.net” in the client’s Search field. Although presence is not shown audio and video calls can still be placed to this address.
But this requires a user to both know of and correctly type in the entire SIP URI to reach the target virtual meeting room. To facilitate searching for these meeting rooms which are predefined on the DMA or RMX then Active Directory contacts objects can be utilized. This is not a requirement as the SIP URI can always be dialed, but it may be beneficial to define in AD some of the more common virtual meeting rooms to make them easy to find for the end-users.
- Create a new Active Directory Contact and define a descriptive name (e.g. RMX Meeting Room 771005) for the object.
- Using the Attribute Editor manually set the msRTCSIP-PrimaryUserAddress attribute to the SIP URI that would be entered to dial the associated video meeting room (e.g. sip:771005@mslync.net). The sip: prefix is mandatory on this attribute.
Now that Active Directory contains a contact with a populated SIP Address then the Lync Address Book service will include this object in the Lync Address Book, allowing Lync clients to simply search for the descriptive name instead of typing in the entire SIP URI.
- Force a manual update of the Lync Address Book as shown in this previous article.
- Once the updated address book files are downloaded by the Lync client then the user can type “rmx” in the client’s Search field and the new contact should be returned in the results. Note that there is still no presence information shown as this is not a SIP-enabled Lync user, just a contact stamped with a SIP address.
Virtual Meeting Room Registration
Although the Contact scenario simplifies searching and calling there still is no presence information available for the meeting room. But this gap has been addressed by Polycom and the is covered in detail in the previous article RMX Virtual Meeting Registration in Lync.
By configuring this additional functionality Lync clients will have the ability to place calls to an RMX without using a defined route as calls will be directed to a registered endpoint (the RMX) which advertises presence for one or more Virtual Meeting Room (VMR) configured as actual Lync user accounts. This calling scenario is no different than a native Lync to Lync peer video call, except that on the far-end is an RMX instead of another Lync client.
-
- In the scenario diagram the different registered users (vmr1, vmr2, and vmr3) are all configured on a different RMX; each RMX can share the same SIP domain namespace, or each could be configured with accounts in different SIP domains. There is no reason that rmx.schertz.local in the single computer pool could not be configured to register VMRs using the mslync.net SIP domain instead as there is no requirement that a static route MatchURI pointing to the same RMX must use the same SIP domain as the registered VMRs.
- VMR registration is a perfect example of how the Trusted Application functionality allows the RMX to register as an endpoint for individual Lync user accounts without requiring user account credentials or a static route. As shown in this scenario both configurations are supported at the same time (with either unique or identical domain names) for a flexible overall solution.
Summary
Hopefully after reading through this article some (or all) of these concepts are now better understood. The intent of this article was to serve as both a primer for anyone just setting foot on this journey through experienced administrators who may not have understood the ‘how and why’ behind the configuration.
If only one concept is to be taken from skimming through then let it be a clear understanding of that fact that the MatchURI does not have to be the same thing as the FQDN defined as the signaling destination for SIP traffic. Sending video calls to 1001@rmx2000a.chicago.contosocorp.local is just silly when something much simpler and more familiar to users like 1001@contoso.com could instead be used .
Jeff,
You nailed this. One of the best, and most thorough explanations yet!! The part that seems to catch people the most is the MatchUri and the static route needing to be set to the fqdn of the RMX/DMA server – not the Application Pool. This is where we often find the biggest issue with integration.
Thanks for posting this.
Perfect!! This information is very helpful. The next challenge is the use of Virtual Desktops.
[…] Third-Party Video Conferencing with Lync: http://blog.schertz.name/2011/10/lync-3rd-party-video-interop/ […]
Thank you!!! — Jeff. I come from a long history of (Cisco/swithcing/routing/security/telephony) background and this document provided the bassis of source and destination routing utilizing FQDN verbage… in a MSFT environment.
Once again thank you.
Walter De Angelis
After set a host as a trusted computer and trusted application pool set successfully,when does lync server trust this defined pool ? after the tls negotiation with the trusted host ?
when will the lync server start the tls negotiation with the trusted host ?Only if there is call route form lync server to trusted host ?
Bill, the trusted application is only leveraged when communication is established with the host. So it is when the remote host initiates an inbound connection or Lync creates an outbound connection (e.g. routing a call).
Thank you for you reply.
So if there is no call routing from Lync server to MCU, the trust relationship between lync server and mcu will not be effective. If lync server doesn’t trust MUC,and mcu invite lync client to join the conference,can lync client join the conference successfully?
The trust is valid as soon as it is defined and a static route is not required. You can use VMR registration or SIP invitations from the MCU to the Lync client without an static routes and the calls will be allowed just as long as the FQDN in the certificate on the MCU matches the the trusted application host object name in the Lync topology.
Thanks jeff, but i need further clarification about the trust relationship between lync server and mcu . You talked the trust is valid as soon as it is defined . So if i only define the MCU as the trusted host(define the trusted application pool and trusted computer in topology) ,and do not config the trust applicaiton and static route,and MCU has the right certificate, will the VMR register using TLS need authentication ?
No, you must configure all of the steps related to the Trusted Application and then publish the topology. Only the Static Route is optional if you are only using VMR registration and will not be routing unregistered SIP URIs to the RMX. If you only create a Trusted Application Pool without defining the Trusted Application Host then it will still not work.
In regards to the MatchURI… What if you have two active Lync pools , with each pool being in a different Lync site? For example, SIP domain is xyz.com and we create a static route for video matchingURI on xyz.com and sending traffic to video.xyz.com.
Let's say a user1@xyz.com on Pool A goes to send a SIP request to user2@xyz.com on Pool B… When Pool A parses through the database to find user2@xyz.com and doesn't find them, will it check database in Pool B or fall back to the static route and try to send the request to video.xyz.com?
The static route is typically added to the Global routing container so all pools in the same topology would be able to use the same route. Also the SIP URI lookup process parses all msRTCSIP-PrimaryUserAddress in AD, not just the users in the local pool.
Jeff,
I am looking to use this way to enable our conference rooms with a PC for Lync A/V.
The PC will need a Cert?
Can you lync enable the room?
Thanks,
Eric
Eric, I don't understand the question, can you elaborate?
Hi Jeff
Excellent detail and great post. I have a specific question about Lync video interop with 3rd party PBX. Basically I have Lync 2010 connected a 3rd party IP PBX via SIP trunk and I can make audio calls between Lync Client and other standard SIP terminal which are registered to 3rd party PBX. However I have no luck making a video call work the same way as audio. Two Lync clients can make and receive video calls. When I try to initiate a video call from standard sip video terminals like (polycom vvx 1500 or counterpath Bria soft phone) to Lync 2010 client , the Front end server sends back SDP which is negotiated for audio only and rejects video. I made sure the polycom and counter path clients sends SDP with H.263 codec since that is the only codec that is supported by Lync for interop purpose. First of all is this setup correct ? Can I assume that if audio works , video should also work the same way as long as I use the required codec that is H.263. Note the terminals are sending H.263 with various low bit rates options CIF and QCIF.
Thanks in advance.
Mani
Lync does not support video calls through the mediation server as it is hard coded to strip the declaration of video capabilities in the SDP of SIP messages. Only audio is supported this way and video interop is only possible through solutions which support the Trusted Application design in Lync. To verify this simply run a SIP trace of the call and you will find that the m=video portion of the SDP messages are stripped at the server and do not arrive on the other end of the SIP trunk.
When, if ever, does Microsoft plan on having Lync either become or have its own internal MCU? The idea of sending multiple (5x) video/audio streams to individual participants seems a little backwards. People are looking to use Lync as a self-contained Video/Audio communications tool, but when its necessary to potentially upgrade remote WAN locations just to support redundant video-feeds (which could be handled by an MCU like an RMXbridge did traditionally or even Vidyo’s MCU)..it seems very cost-ineffective. Bandwidth is “cheap” but upgrading small locations to multiple T1s with new hardware has a year-over-year negative run-rate in comparison with just using an MCU. Anyone know of something on the roadmap?
Regards,
Alan
Personally I doubt that would ever happen as it's completely the opposite of how the product has always worked. You don't have to utilize multiple video streams if you don't have the bandwidth, or you can use third-party hardware MCUs like mentioned to provide that in single video streams.
Hello Jeff,
We are trying to route voice call coming from our Mediation towards trusted application (Polycom DMA) using static route. MatchURI of static route is set to nok.oninte.com (same as SIP domain in Lync ) and TLS Destination dma.nok.com (DNS resolvable). If we call from lync client to sip uri 44444@nok.oninte.com for example call is successively route to DMA. But when a call to same sip uri is coming over external SIP Trunk (PSTN Gateway) via Mediation it is dropped with following DIAGNOSTIC error
LogType: diagnostic
Severity: warning
Text: Message was discarded by the application
Result-Code: 0xc3e93c38 SIPPROXY_E_NORESPONSEFORACK
We are wondering – Is it possible for external calls coming via mediation to use static routes in order to have access to DMA?
BR
Plamen Gavrailov
1) Will polycom DMA support Lync DNS load balanced scenarios?
2) Will DMA acts as lync client while registering with Lync servers.
3) Will DMA registers with 2 lync server simultaneously
Yes DNS LB is supported and should work no differently. I'm not sure what you are asking with the second question. The DMA will connect to only one FE at a time when routing inbound calls to the Lync Pool when using DNS LB.
[…] The concepts of using this Trusted Application model in Lync was then broken down in detail in this previous article explaining the relationships and dependencies on each of the components involved in routing traffic […]
[…] the previous article Third-Party Video Conferencing with Lync the concepts of the Lync Server Trusted Applications and Static Routing were discussed in relation […]
Hi Jeff,
May you be able to elaborate the pros/cons of having a VC room setup the way you defined here rather than setting up simply as an ordinary sip user in your domain?
This article is not applicable to video conferencing endpoints, like room systems. Those can integrate just like a native Lync client in some instances. This article is intended for video conferencing bridge/MCU integration.
Jeff: I just wanted to verify that Polycom video end points require telnet be enabled. I have a lot of respect for Polycom devices but the customer is looking at this as a potential security risk.
BK
Hello Jeff,
You done a really great work here.
I have one question, My company is using a Hybrid architecture in split domain of Lync 2013 in O365 and Lync 2010 OnPremise.
Originally we integrated our Cisco VCS cluster with our Lync 2010 OnPrem and everything was working perfectly. No we try to have our OnLine client communicating with the same VCS Cluster. For the moment we encounter some issue and we are a bit lost on this point.
So my main question here is, it is possible in a Hybrid scenario to have OnClient communicating with a third Party VCS system through the Hybrid architecture?
if yes, what is the main thing to check or do?
I do not know if Cisco supports VCS and Lync integration in these scenarios at all. I do know that Office 365 does not allow sharing the same namespace (e.g. Hybrid) for Static Routing configuration in Lync, meaning that you would need to deploy a completely separate, federated Lync on-premises environment (minimum of a single FE and single Edge server) to leverage Static Routing to send calls to third-party applications like this. You cannot use something like domain.com or video.domain.com as the on-premises namespace (hence no Hybrid/Split Domain). It would have to be something like videodomain.net or something completely different than the Lync Online namespace,
Hi Laurent,
Jeffs approch is correct.
With using an own CISCO Videodomain and seperate it from the Lync-URI-Domain it works fine.
My problem is more the fact that (Match URI) routing is working fine for users registered on my central registrar but not for users registered on a branch-registrar. A look into the Lync-Client log shows, that the client is trying to resolve the CISCO Videodomain via EDGE-Server instead of using the static route provided global and on registrar-level (for testing). That of course brings a SIP404 to the client, because EDGE is not able to resolve the Videodomain.
Any ideas, why that happens only on branch-registrars ?
Regards Timo
Hello Jeff,
We try to add two different Lync pools as SIP Peers in the DMA. The thing is they are in different domains. One is in contoso.com.au and the other one in fabrikam.net. They are two complete independent Domains with so two CA.
The certificate in the DMA is configured with CN:dma.fabrikam.net and it gets in SAN:dma.contoso.com.au. This certificate is issued by the CA on fabrikam.net. But on the DMA i put the two CA certificates.
The lync servers are both configured with route and trusted application with dma and rmx. the rmx is registered on the lync in fabrikam.net and this integration works with a lync client connected in fabrikam.net.
In the contoso.com.au DNS we created CNAME to say that dma.contoso.com.au is dma.fabrikam.net.
Do you have any ideas about that ? Have you ever tried it ? Do you know if is it possible ?
Thanks in advance for your help
I’ve never tested that scenario. In theory it may work but I can’t say for sure.
[…] 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 […]
Jeff,
Thanks for a great article and blog. I’m currently struggling to get my organisation and another one to agree on how to make VC interop a cost-saving reality.
I have one question regarding the Static Route setup: Do I understand correctly that newer Lync Servers can’t connect to a Polycom DMA via a TCP Static Route and that a FQDN for the DMA and the certificate are mandatory elements in order for it to work?
Thanks,
Johann
Johann, Polycom has not supported TCP integration in quite some time (the OCS days). TLS has been a requirement for integrating the DMA and RMX as Trusted Applications with Lync and SfB. The certificates assigned to these hosts need to include both the Trusted Application Pool FQDN and the Trusted Application Computer FQDN, as pointed out in this article: http://imaucblog.com/archive/2015/09/10/skype-for-business-and-match-uri-tls-validation/
Hi Jeff,
Great explanation. I want to know if there is a way to set alternate routing between static routes such that if first trusted host fails, I want to route to a second host. When I set my static route destination as pool identity, it routes calls in a random way.
No you cannot control the behavior that Lync/SfB Server uses with the routes. It will grab all routes in a rule and then assigned them to clients in a round robin fashion. Meaning that the first client to utilize a route will be given destination 1, then the next client destination 2, and so on. Each client will hold on to the specific FQDN/IP it was given and only use that only it stops responding and then the server will assign a new, working destination IP to the client.
Hi Jeff,
Please help with the error. Configuring SfB Server 2019 communication with Cisco Meeting. According to your article, I made the setting. The call is made, but there is no connection with a user from another company. Looked at the ReportServer_MONITORING logs, such an error:
1010; reason=”Certificate trust with another server could not be established”; ErrorType=”The peer did not respond to TLS or MTLS negotiation in a timely manner”;