MCI Network Call Redirect with ISDN PRI

[dsldefinity]

We have 2 call centers with MCI ISDN PRI Circuits. We are looking to overflow calls in a Disaster Recovery mode from one call center to the other. We thought that we could Use MCI network Call redirect to hop from one location to the other. Is anyone out there using Network call redirect on ISDN PRI Circuits to interflow between call centers?

Our account team tells us it may not be able to be done. Here is his take on the issue:

After working with the translations/database tech, the switch tech, order entry support and 2nd level switch support, we have come up against a roadblock in regards to the NCR tables. There are two separate, very different platforms for which NCR was designed. There is the VNET NCR table (designed to overflow VNET dial plan calls) and toll-free NCR tables (for just that).

Since the trunks that are involved in this particular NCR application are ISDN, they are considered VNET-PRI. The VNET tables can indeed be created to overflow from trunk group to trunk group as we already discussed (and thus, planned our three early morning sessions). The problem is that the Data Access Points (DAP’s) are expecting to receive a VNET call, not a toll-free. The digits being received by the DAP are not being recognized as valid VNET numbers, and are being rejected.

The toll-free tables can certainly be built on your TF Corp ID, but the criteria for a toll-free NCR overflow table is that we must supply the logical termination that we wish to overflow to. It, unlike VNET, will not allow a trunk group - to - trunk group overflow. This brings us back to the original problem of needing a multitude of tables, and of course, the cost associated with that.

The other options we had discussed in the past are Super Routing plans (not an option because of the need for unique DNIS values and unique routing); alternate routing plans (too many to have to implement at the time of a disaster..and the price associated with that many plans); and Set plans (you can still have the unique routing and DNIS, and implement them all at once)

 

[wildcard100001]

How about using the feature Busy Ring No Answer (BRNA), then using your MCI route tables route to the other trunk service ID at the other location.

Using this feature, you could program an "emergency agent", that if logged in, play busy via the inbound vector.

goto x if staffed agents in skill xxx (emergency skill)

step x busy

BRNA logic would engage.

You could program the emergency agent login on 1 supervisor phone or more, push the button, then walk out. Use a passcode on the agent ID to make sure it doesn't get accidentally pushed.

Calls would then route to your other location.

I've used this method numerous times...

Alternatively, you could use .... I forget what MCI/Verizon Business calls it... Service Assurance (AT&T term I believe), call the SA number, tell them what trunk service ID you what your calls to route to... from TF # etc...

Another option would be to define alternative routing plans.. then either call the number to manually activate a different plan, or use a percent allocation in the cloud application to do it yourself.

I hope this helps a bit..

Thanks,

Wildcard

 

[phoneguy55]

I do but its all calls or none. The feature is called custom redirect if you are using Verizon/MCI or CLAR with SBC/AT&T. With the feature I have the abality "on the fly" to redirect my toll free numbers to any other predefined number at any time during the day. This is very helpful for DR.