In Mike Stacy’s well-known article covering Static Routing in Lync Server the basic concepts of utilizing the New-CsStaticRoute cmdlets were outlined to create routes to external applications or hosts that the Lync Server environment was defined to trust.  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 out of Lync.

Keep in mind this is completely different from telephony routing which uses mediation servers and trunks to route an audio-only call to SIP or TEL URI destinations.  The basic static routing configuration discussed in this article can be used to externally route any type of SIP traffic containing all sorts of supported modalities.

The steps in Mike’s article show how to create a single route entry to direct traffic defined by a unique masking of the SIP URI to a single external target.  Although this target could in fact be a load-balanced service that is about the only flexibility allowed in that basic configuration scenario for granular control of the signaling traffic.  This approach is fine for smaller, flat environments but when multiple Lync server pools are deployed then sending all traffic from all clients to the same target may not be the desired approach.

Take for example a multiple pool Lync deployment where video calls need to be routed to an array of similarly deployed third party conference bridges.  As video traffic can be quite large in terms of utilized bandwidth then selecting the proper destinations for this traffic can be very important.  If the separate Lync pools reside in a geographically dispersed arrangement as well as the third party video bridges, then sending video calls from all clients to the same bridge would be costly on the WAN for at least two of the regions.  Thus it would be ideal to direct traffic from each pool to a local bridge, just as it may be ideal to use this localization approach for traffic to any third party application host.  The problem is that this is not as easily configured in Lync as it would seem.

The first approach for many is to simply create multiple static routes using the same Matching URI yet pointing to different target FQDNs, hoping that Lync has some intelligence built-in to just ‘figure out’ which route is best for each pool.  Unfortunately this does nothing of the sort as Lync does not support multiple static routes in the same routing collections which utilize the same MatchURI value.  In this configuration Lync would simply use the first route it finds with the desired MatchURI value and then would send traffic to the target defined in that route; any other routes with the same MatchURI are ignored.  It appears that the first route defined with that specific MatchURI would be the entry used and any routes added later are in essence further down the list and never even looked at.

Even if the first resolution points to a host which is not responding or is offline Lync will only use that route.  It does not move on to the next route as the logic is defined to treat the MatchURI as unique, meaning there should be another rule in the table which might be a successful match.  What is important to understand here is that this is all true within the context of the same routing collection.  By default Lync Server comes pre-defined with a ‘global’ routing collection which can be used to add any new routes to and all servers in the topology will use this routing table when needed.

Another approach might be to simply define unique MatchURIs so that multiple routes can be defined to send traffic to the desired hosts.  For example a route for SIP URIs which utilize "west.mslync.net" could be pointed to an external host located in that region and a second route for URIs containing "east.mslync.net" could be created to route traffic to a host located on a completely different region.  But then users would need to know to use different SIP domains for reaching the desired hosts which is complex.  Furthermore when a user in one region needs to call into a video bridge in the other region they would need to use a different SIP domain in the address then they typically would use for calls in their own region.  In short, this is messy any not a good solution.

So what is a better approach?  In Lync Server it is possible to create new collections of routes and assign them to a specific registrar by using the New-CsStaticRoutingConfiguration cmdlet.  This addresses the limitations with these other scenarios by allowing for multiple routes with different targets which can all share the same MatchURI value.  Because each collection of routes is assigned specifically to a registrar and are not globally defined then there is no conflict.

Configuration

As discussed in the other articles linked above before defining any static routes the target FQDNs (e.g. hostwest.schertz.name) need to be configured as part of a Trusted Application Pool and Trusted Application.  It is assumed those steps have already been completed for the destination FQDNs used in the following examples.

• Using the Lync Server Management Shell issue the following cmdlets to create a new routing configuration for the first Lync pool.

New-CsStaticRoutingConfiguration -Identity service:Registrar:poolwest.schertz.name

$routewest = New-CsStaticRoute -TLSRoute -destination "hostwest.schertz.name" -port 5061 -matchuri "video.mslync.net" -usedefaultcertificate $true

Set-CsStaticRoutingConfiguration -identity service:Registrar:poolwest.schertz.name -route @{Add=$routewest}

• Then issue the next set of cmdlets to create a new routing configuration specific to the second pool.

New-CsStaticRoutingConfiguration -Identity service:Registrar:pooleast.schertz.name

$routeeast = New-CsStaticRoute -TLSRoute -destination "hosteast.schertz.name" -port 5061 -matchuri "video.mslync.net" -usedefaultcertificate $true

Set-CsStaticRoutingConfiguration -identity service:Registrar:pooleast.schertz.name -route @{Add=$routeeast}

At this point any SIP messages directed towards *@video.mslync.net which are will be routed from their home server to only the external, trusted host assigned to that specific pool.  So if a user homed on pooleast placed a video call to ‘1234@video.mslync.net‘ the traffic would be routed directly to hosteast.schertz.name.

Stay tuned for the next article which will go into more detail on what the MatchURI value can be defined as and which approach is ideal, depending on the circumstances.