Response Group Service fallback solution(s)

Hi everyone,
I want to share with you a simple solution for a well-know Skype for Business issue:
how to manage incoming calls for RGS in an isolated Branch Office?



Main Site: a Skype for Business Front-End with Response Group Service configured and a Voice Gateway.

Branch Site: a Skype for Business SBA/SBS, a Voice Gateway and a local Attendant

RGS Configuration: there is a RGS Workflow named “Branch Office IVR” with SIP URI and a Tel number tel:+39051223344 (this is from DID range on the Branch Site Voice GW)
Agent: the Attendant IP Phone at Branch Office, registered on SBA/SBS Pool and with SIP URI

During normal activities the incoming call (1) for Branch Office IVR enter from Branch Office SBC, to SBA/SBS, to RGS on Main Site Front-End, than (2) RGS route the call to Queue and Agents, one of this is the Attendant IP Phone in the Branch Office reception.

Service interruption


What happens if there is an interruption of service, for example the Internet connection between Main and Branch Sites?
In this case, the incoming call (1) cannot reach RGS and then drop…. not so good!
In case where Branch Office Number is the ONLY DID number, the Office is completely unreachable from PSTN.

Response Group Service fallback solution #1


The solution to solve this very bad behaviour is quite simple: incoming calls (1) arrive to a local virtual user that is configured to route everything to the RGS (2), if the RGS do not respond in 5 seconds, than the user route the call to a local IP Phone (2b).
Because every step of this process is inside the SBA/SBS, this will work even in case of Branch Office isolation.

Setup (you have to do do that BEFORE interruption of services!)

  1. Create a new AD Technical Account with no password expiration.
    In my example
  2. Enable this Account to SfB with Enterprise Voice feature and assign it to SBA/SBS Pool (very important)
  3. Use SEFAUtil (Deploy the SEFAUtil tool in Skype for Business 2015)
    SEFAUtil.exe /server:  /setsimulringdestination: /enablesimulring /enablefwdnoanswer /callanswerwaittime:5 /setfwddestination:

    In my example
    SEFAUtil.exe / / /enablesimulring /enablefwdnoanswer /callanswerwaittime:5 /

  4. Open the Response Group Configuration Tool (SfB Control Panel -> Response Group -> Workflow -> Create or edit a workflow), edit the Branch Office Hunt Group or IVR, then cut the Telephone number and save.
    Note 1: RGS Workflow Telephone number is not mandatory, it’s optional, only SIP URI is mandatory.
    Note 2: after this point incoming calls for this number will fail for few minutes untill you complete the precedure.
  5. Wait few minutes for RGS and SfB replication
  6. Open Technical Account (eg. properties in SfB Control Panel and paste the number from point #4 in Line URI (remember to add tel: at the beginning), then save
  7. Wait few minutes than test the solution
  8. Enjoy the solution! 🙂

Response Group Service fallback solution #2

As suggested by Michele Betelli (thank you for sharing this idea!) there is another solution for this scenario.

It’s based on Sonus SBC 1000/2000 Call Routing Table and Cause Call Reroute, let’s se how to setup:

  1. On Branch Office Sonus SBC 1000/2000 go to Settings -> Transformation and create a new Transformation Table, like this one
    Name: what you like, in my example I’ve called it “REROUTE TO LOCAL ATTENDANT” (I have a great imagination! 🙂
    Input: every called number
    Output: the number of the local Branch Office Attendant
  2. Check the Couse Code Reroute Table, if you have used Easy Config Wizard to setup your SBC you will find something like this one
  3. Open the PSTN Call Routing Table (adjust the name to your Call Routing Table naming convention) and set the Cause Code Reroutes value to UC Reroute (or whatever you’ve called it) to the entry(ies) from PSTN to SfB (like the one in this example)
  4. Add the new Transformation “REROUTE TO LOCAL ATTENDANT” to the PSTN Call Routing Table at the bottom, be careful to set Route Priority to 2
  5. Test it!

How it works?
Incoming call to Branch Office IVR is processed as usual during normal activities scenario, so you do not have to move the IVR Telephone number to the Technical Account.

In case of service interruption, the call to RGS receive a SIP 503 Service Unavailable, the Cause Code Reroute manage the next Call Routing Table Entry (REROUTE TO LOCAL ATTENDANT).
Without Cause Code Reroute the incoming call will fail.

Do you know different solutions? Share it please!
As usual, I hope this could help you.



8 thoughts on “Response Group Service fallback solution(s)

Add yours

  1. Hi Michele, interesting comment. How do you achive that?
    With Sonus SBC we can use Action Set (I planned to write an article on that), I don’t know if and how to do that with AudioCodes. Have you some article to follow?


      1. Hi Michele, thank you for this comment, it’s a good idea, something to write about!


      2. Hi Michele,
        I’ve tested your solution with Cause Code Reroute and added to this page, many many thanks for your contribution. Do you have somethink to add or change?
        Best Regards


  2. Hola Luca,

    I think that’s enough to set an example about how to achieve this solution, after that, we should adjust this with our configuration.

    For example:

    1) We should replace the “Input: every called number” with the our critical number (RGS number in this case). This change will permit us to manage more critical numbers and also to have another Route Entry after our “ReRoute” entry.

    2) Bare in mind the solution works only if the call pass trough the SBC (From PSTN or From Analogues if Tenor or FXS is used), if we need this service also from other sources (From Lync) we could force it using a Short Dial (I think you’ve already discussed about it in your blog).

    3) Are you sure the Route Priority 2 is mandatory? Does not work without it?

    By the way, thank you for add the idea and I hope will be helpful to someone.



    1. Hi Michele, thank you for this considerations.
      1) I’m speaking about that with my friend and MVP Greig Sheridan on the use or not of (.*) In my tests (not very deep tests yet) if the fallback rule do not use (.*) the call fail. As I promised to Greig I’ll do some more test, with more rules after the “fallback” one to give an answer also on priority question. #2: yes obviously this rules works only for incoming PSTN calls, but this is what the scenario ask 🙂
      I hope to go deep on that argument asap
      Thank you for mentioning my article on speed dial with Sonus!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

Up ↑

%d bloggers like this: