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.

By Jeff Schertz

Site Administrator

14 thoughts on “Multiple Static Routes in Lync”
  1. From above document, it looks like the matchuri is matching the domain, did I get it right? If there a way to do digits matching at all? Example, a way to match \d{4}@video.mslync.net and point to the appropriate destination?

    1. No, Lync does not perform normalization on SIP URIs, only on TEL URIs. The MatchURI can be different values depending on your needs and an upcoming article will explain this in more detail.

  2. So from my reading of what you’ve written – if you’ve got two destinations for resilience purposes rather than load-balancing, you’re right out of luck and presumably have to hide them both destinations behind a single IP address using some technique (e.g. Windows Network Load Balancing or a F5 IP F5 hardware solution)?

    1. Partially, it depends on what you are connecting to and how that application supports resiliency. Lync supports DNS Round Robin here so the target FQDN of the static route could resolve multiple IP addresses and then Lync will place connections to each IP in series. The first Lync user to send a SIP message to the trusted application will be directed to IP 1, then the next to IP 2, and the next to IP 1 again, and so on. If the destination has it's own HA solution then Lync can integrate with that as well. A future article may cover this topic on more detail.

      1. Thanks; based on your info I tried a bit of experimentation. Sadly for remote call control it doesn't work particularly well; it will "round robin" on the initial login when Lync starts up, but once that session is created, that host is chosen as a target seemingly indefinitely. So for my purposes, at least, I'm stuck with using a multiple hosts behind a single IP address.

        1. Hi all,

          I too was intrigued by the article when I first started reading it as I was looking for a similar solution – the need to point a single pool to multiple possible routes when matching a single SIP URI. Round robin DNS may end up sending signalling to different devices, but ideally you want ensure that conversation are kept to one the the devices specified. I assume the same is true in SfB?

  3. Great Article Jeff

    Do you know if its possible to seperate the IM&P traffic from voice/video. Eg send IM&P to one host and Voice or Video to another host. Where destination IM&P,Voice and Video are in the same SIP domain.

    1. I'm not sure how that applies, as the Static Routing only applies to SIP traffic. Other traffic like media is negotiated using the behavior programmed into the endpoints or servers involved in the communications. Also IM and Presence are all SIP messages while media is a completely different type of communication.

  4. Hi all,

    I too was intrigued by the article when I first started reading it as I was looking for a similar solution – the need to point a single pool to multiple possible routes when matching a single SIP URI. Round robin DNS may end up sending signalling to different devices, but ideally you want ensure that conversation are kept to one the the devices specified. I assume the same is true in SfB?

  5. Dear Jeff,

    Really appreciated article!!!

    Now, I want some help from you on one of the topic. I draw you my requirement.

    We have recently migrated from Lync 2013 to Skype for business 2015. We have 2 pools named pool01.XX.XX.XXX and pool02.XX.XX.XXX . We have cisco VCS deploed as a 3rd party application which is used for bridge call. Now, we want to integrate these 2 pools with CISCO VCS. But I have come to know that VCS only accepts request for 1 pool only. So, in my scenario, if I want to integrate these 2 pools with VCS by adding VCS as a trusted application, how can I achieve this? What is the cmdlet for the same? The 2 commands that you have mentioned will work in my scenario or anything else I need to do?

    Hoping for a quick response on the same as we have stuck here in our deployment and we need to complete this setup as soon as possible so that we can go live.

    Appreciate quick response. Thanks for your time and consideration.

    Neel

    1. Sorry, I’m not familiar with the latest requirements on VCS integration so I don’t know what the proper configuration would be, if it’s even possible to do as you intend.

Leave a Reply

Your email address will not be published. Required fields are marked *