Creating a Backup Response Group for Lync Pool Failover

One of the common issues I have come across is the ability to have a failover Response Group Service when your primary Lync Pool becomes unavailable. Users have the ability to register to a secondary pool so they can still make and receive calls, but Response Groups currently have no failback or replication ability across pools to allow seamless functionality.

So how do we over come RGS failure? The basic solution I come up with is to create a second RGS on another pool and translate the inbound primary DID RGS number to a secondary DID number. This allows the incoming RGS number to be rerouted to an alternate Mediation Server. I guess you can call this a workaround of sorts but at the end of the day you want an inbound call to be answered by something rather than dead air and this workaround does provide a solution. There are a few issues that present themselves when considering a backup solution:

1) No two RGS work flows can have the same Tel URI.

2) For the purposes of outbound routing a gateway can only be associated with one Mediation Server or Mediation Pool.

3) Agents that were part of the original RGS call flow can not be part of our backup RGS unless they can still register with the Primary registrar, which we are assuming is down. This would mean that the RGS agents would now be registering with their secondary registrar and therefor have no presence availability. So for the purposes of this discussion we will assume that once the primary registrar pool is down our agents that were part of the original RGS are down for the purposes of taking part in the RGS back up service.

To work around these issue we need to consider three things. How do we translate our RGS inbound DID to a new number, how does the Mediation Server accepts inbound connections from Gateways not directly associated with it and lastly what do we do with the call once we have it in a new RGS service.

 

In our example we have two Mediation Server pools collocated with my Front Ends. I mentioned that outbound Mediation Servers are limited in the fact you can only associated a gateway against one pool but inbound a Mediation server will accept an inbound request from a gateway as long as it is part of the topology. It’s a handy little know fact that I come across when I wrote “Adding CUCM subscribers to Lync Topology Builder” post. 

Below is a basic set of outbound dial peers and translation rules that can be used for a Cisco gateway setup to provide DID service to Lync. In this case I am providing a basic route to a destination starting with 425 and only translating calls to the response group DID when using the backup dial peer. Its nothing to complicated. The preference command allow dial peers to hunt for an available Mediation Server. If you using AudioCodes or NET or another certified gateway they should all be able to provide similar hunt group functionality.

!
voice translation-rule 203
description Translate RGS to backup RGS
rule 1 /4255555551/ /4255555552/
!
voice translation-profile BackUpRGS
translate called 203

!
!dial-peer voice 101 voip
description to Lync Mediation server
preference 1
destination-pattern 425.......
session protocol sipv2
session target ipv4:10.10.10.11
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
no vad
!
!
dial-peer voice 102 voip
description to Lync Backup Mediation server
preference 10
translation-profile outbound BackUpRGS
destination-pattern 425.......
session protocol sipv2
session target ipv4:10.10.20.12
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
no vad

So now that you have delivered the number to a backup Mediation Server to be resolved it’s a matter of building a new RGS workflow to satisfy the need of the business. Of course this is a DR situation so your intention of whether to deliver it to a live person my differ but you have options of where to send the call:

1. Create a agent group with new agents that will be available on the backup pool.
2. Exchange UM group mailbox
3. Exchange AA
4. PSTN number to an alternate service with announcements to let callers know they are being rerouted
5. etc, etc etc

So lots of options.

This is really just a solution born out of straight forward telecom engineering rather than a grand workaround. But if your new to telecom engineering this may be something that you hadn't considered before. Sometimes backup solutions are not all that fancy but still meet business requirements. Just because the RGS is not replicated across pools doesn’t mean your dead in the water.

What has been your back up to RGS service interruptions?

VoIPNorm