This is an old fix to an old issue. But, I ran into it again, and was obliged to explain to my customer the what and why of SBA and RGS in a central site and how to get around the RGS going unanswered if the central site is down. So, in the midst of doing that, I also created some documentation which I thought I would share.
Issue:
SBA can terminate a local call, but if the call is destined for an RGS workflow, and the central site is not available for any reason, then the call will fail.
Why:
The SBA can answer the call at the gateway routing level and at the mediation server level, but when the incoming DID is resolved, the system needs to send the call up to the central site to the RGS workflow because the RGS SIP address matches the incoming DID.
SBA does not handle RGS, so therefore the call needs to route up to the central site FE pool for handling; but the central site is not-available; the call fails.
Fix:
There are two possible fixes for this:
First, SLA can be used, or delegates. However, if there are more than a few account involved, this becomes somewhat onerous. It is also possible to use an ExUM AA, but usually the SBA site will not have an Exchange services, so while this might answer the call, in the end the caller will not reach the proper resource because of the central site outage.
Second, creating a dummy account with simulring for all hours. The call will come into the SBA, and then user is local, then the user connection is initiated. If the simulring is enabled for all hours, the call will simulring up to the RGS workflow. The RGS workflow will answer and route the call according to the workflow setup.
I guess there is a third option – put a full user pool in the site instead of the SBA – but this then becomes a cost/benefit ratio analysis that I am not prepared to go into here. Suffice it to say that when faced with an SBA request, I can honestly say that 100% of the time I bring up installing an SE for the site. Just sayin’
Scenario:
Customer has existing RGS, which has an e.164 DID, which is routed inbound on a PRI that is handled by the SBA. During central site outages, the RGS inbound call fails. Customer wants the RGS call to be handled by an SBA local user until the central site becomes active. Customer is OK with notifying a user at the SBA site to login to a second account to answer the calls during the outage.
Process to follow:
- Identify the dummy account e.164 number then create dummy account in AD.
- Create SIP account for dummy, registrar is SBA (not the SE as shown). Enable for Enterprise Voice.
- Identify RGS workflow e.164 and assign to RGS workflow
- Open dummy account and setup for simulring to the RGS workflow. You can also accomplish this sub-task with sefautil.
Test
Follow-up tasks:
1. Identify personnel at each SBA site to be prepared to login as the dummy acount from a full SfB client to handle calls in outage.
2. Possible alternative is to put a phone device on the network somewhere in the SBA site and have the *operator account login and stay logged in – and the training would be to answer that phone if needed.
An alternative to #2 is to just have the phone device available and login as needed (my personal choice).
If #2 is the route chosen, then you would be advised to set a ext= format and PIN on the account so that login process would be ext and then PIN.
Summary
I have show the what and why and how of SBA/RGS/Central site outage and suggested a way around your RGS not working in that scenario.
YMMV
No comments:
Post a Comment