Call Forwarding when CUBE goes down

[billmatthews]

We have a remote site running a CUBE router.  It has an MPLS connection back to headquarters.  It also has some analog lines for SRST.  It has a dedicated DID for that site, that comes in via SIP to headquarters (CUCM v8.6). 

When the MPLS circuit goes down the router easily goes into SRST.

But how do we get the main number for that store to roll over the analog lines?  I imagine somehow when CUCM detects that the CUBE became unregistered we need to forward that call to a new DID for the analog hunt group on the router.

Thanks

Bill

[Ayodeji Okanlawon]

Bill,

You can just use dial-peer preferences to direct calls to cucm during normal operation and to the analog ports when WAN link is down..

So on your voip dial-peer use a lower preference value and on your pots dial-peer for the analogue lines use a higher preference value

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[billmatthews]

Could you provide a little more detail?  Where would those dial-peers be configured -- on the headquarters CUBE router?  How would the dial peers know that the remote site WAN is down? 

I was thinking this has to be handled in CUCM, since it knows that the remote site CUBE went down.

[Ayodeji Okanlawon]

Bill,

Your initial post said you have a remote office running CUBE...But it looks like the CUBE gateway is at the HQ?

Does this call flow represent your setup? can you describe it better?

Remotesit---SRSTGW-------MPLS---HQ---CUCM----CUBE-----ITSP

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Manish Prasad · Accepted solution]

Aokanlawon's first answer was for the calls directed towards CUCM from remote site in MPLS failure.

Now  for the calls which needed to direct from main site (CUCM) to  remote site  when CUBE(at remote site) goes unreachable ,you need to add your local pstn  gateway (as a second preference) in  the RL pointing towards the route  pattern which routes call towards remote site.

Route pattern - Route list - 1. CUBE 2. Local PSTN GW.

Now you need to do translation at local PSTN gatweway to convert dialed remote site number to new DID range of remote site.

[billmatthews]

Aokanlawon -- Sorry I wasn't clear.  Obviously the call flow for internal dialing is all internal.  But external calls the call flow is:

ITSP - hq_cube - hq_cucm - hq_UCCX - mpls - remotesite_phones

However when the MPLS is down, we need that DID to come directly into the remotesite_cube...where we have SRST and a TCL application setup to replace UCCX

mnsh.prasad -- that's making sense I think.  Modifying the route list I understand.  But then at the local PSTN gateway, why would a translation be necessary?  Couldn't it just take the DID directly and hand it to the TCL application? 

[Ayodeji Okanlawon]

Ok, its clearer now..There is no CUBE at the remote site..all you have is a SRST gateway.

In this case, your options depends on how the DDI is configured on CUCM..If this is configured as an extension on an IP phone and that IP phone is on the remote site, then you can use CFUR (call forward unregister)...

Can you let us know how the DDI is setup on CUCM

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[billmatthews]

I think the router at the remote site is a CUBE (CME as SRST)?  Sorry if my terminology is wrong.  The good news is I'm not going to be doing this config, I just like to understand so I can work knowledgebly with the vendor.

The DID is configured as a trigger for a HQ UCCX application.  That application then directs calls to the individual phones via direct line extensions on phones (for example marketing = 5000).  So those phones that have line 5000 became unregistered.  So I suppose there are two options:

CUCM somehow forwards the DID to the remote site CUBE (instead of UCCX)

Or the UCCX application still answers the DID, but then somehow forwards to the CUBE at the remote site via it's analog lines.

Sorry for the incomplete information -- I'm kind of brainstorming as I go rather than asking a direct question. 

[Ayodeji Okanlawon]

The easiest solution is to have UCCX answer the call as normal but on the phones for the remote site configure a CFUR with the full DDI of the analogue line..So when a call comes in from the UCCX and the phone is unregistered because of WAN failure, the call will be sent to the analogue line via the PSTN

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[billmatthews]

Thanks, +5 for all your help.

So when we CFUR to the DID, how do we route that to the correct extension at the store?  Today there's a single DID to the UCCX application.  Then it directs to a department, which will hit a phone that's unregistered, and CFUR to a new DID.  That remote cube router that answers the DID won't know which phones to send it to.

Sounds like I need the UCCX application out of the mix, and redirect the entire DID back to the remote cube, where the TCL application answers. 

[Ayodeji Okanlawon]

You need to configure the remote gateway to send calls to specific phones based on the Analogue line DDIs...If a call comes in on Analogue line 1, then send that call to store x etc...

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[billmatthews]

That makes sense.  So multiple DIDs on analog lines at the remote site, each one mapping to a particular extension. HQ UCCX sends to phones, when phone lines are unregistered they point to those unique DIDs.

Is that correct?

[Ayodeji Okanlawon · Accepted solution]

Yes..and you could also map the DDIs on the remotre gateways to a pilot number and have phones as part of a hunt group for that hunt pilot..This way you can use a single DDI for a store instead of dedicated DDIs for each phone

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[billmatthews]

Sounds great, thanks for all the advice