Complex Call Routing between CUCM and CUC and Back Again

[DAVID BURKHART]

I am with a school system and we have systems in place that allow each campus to be locked down (via controlled access) by dialing an extension "within" each campus. Each campus is setup like a hotel in that you cannot reach a classroom from outside the campus; only by calling the main office and them transferring the call. This is accomplished by each campus being within its own partition, and the CSS including its own campus and a global DID partition (which enables each classroom to reach any DID extension). 

Specifically, when a campus caller dials 3999 (not the actual extension), there is a route pattern that grabs the call and points it to a specific FXO port on a gateway on the campus. When that port goes off-hook, it triggers the ancillary, 3rd-party system that locks the doors, etc. 

We have experienced enough false calls that administration wants to implement a process whereby the call is answered, the caller is told, "Press 1 to cancel this lockdown or Press 2 to lock down the building" to force the user to confirm the intentions. It is easy enough to use a System Call Handler in CUC for the phone menu (going from partition ABC to the DID partition where CUC lives). I am struggling with how to get the call back to the ABC partition so that it will go to the FXO port on the campus' gateway. I could use a translation pattern to forward a DID extension to an extension in ABC partition the points to the gateway's FXO port, but 1) this makes the solution even more complex, 2) this requires the use of one DID for each campus we have, and 3) I am concerned that this DID extension will show on the phone - even if for a split second - and someone will try dialing that and bypass this whole complex solution. 

I am open to suggestions here. I could simply tell administration that it is not feasible. In addition, should fiber go down between our NOC and the lockdown campus, then the System Call Handler simply will not work (a rare situation, but it does happen). I appreciate any insight and ideas this team can devise. 

[Maren Mahoney]

If you have a centralized CUC system, you could have the dialed 3999 number hit a translation pattern before it goes to CUC which would prefix a 'campus code'. Therefore, as the calls flow into CUC each campus has its own number. This would require a System Call Handler for each campus, but you could streamline that by creating a System Call Handler Template that has all of the options pre-configured other than the Extension, the name, and the target for the Keypress 2. (I think you can even upload the greeting in the template.)

Because the CUC trunk (I'm assuming a SIP integration) has a single CSS for calls flowing back to CUCM, this would also allow you to have the 'real' numbers (the campus-specific 7-digit version of 3999) in a partition that is available to the CUC Trunk but not directly dialable by an internal user. So even if they 'see' the real extension they can't dial it.

Then CUCM can have a route pattern for each FXO port (or are you using MGCP?) that is campus-specific.

Someone else may have a more elegant solution, but I think this would meet your requirements.

Let me know if you have questions about this idea. I may have missed something in your scenario.

Maren

[DAVID BURKHART]

Thank you for your helpful post, @Maren Mahoney I already have a similar solution to your suggestion in place for internal campus calling (real extensions are seven digits with the last four digits being the ones people actually call); so I am familiar with what you are describing. I just didn't think of it for this application. 

I indeed have two SIP trunks for CUC - one from each CUCM subscriber but using the same CSS. 

The challenge is getting the call from CUC back to CUCM to use the Route Pattern. It seems I would have to introduce DID extension to point Keypress 2 to and have that be in the Route Pattern that points to the FXO port. Let me think on that...

[Maren Mahoney]

If I'm reading you right, you already have a school-specific lockdown Route Pattern going to the FXO port for that specific school. If so, the Keypress 2 on each campus's System Call Handler would be programmed for a Call Action of "Transfer to Alternate Contact Number" and you could put whatever number is already in place on the Route Pattern for the FXO port for that school.

As long as the Partition for the Route Patterns is in the CSS of the CUC SIP trunk it would work. I'd have to think if that would be the Incoming Calls CSS or the Rerouting CSS (or the OOD Refer CSS?).

Maren

[DAVID BURKHART]

Currently, when someone at campus ABC dials 3999, that hits a route pattern within that partition and sends it to the router on that campus, which has a dial-peer statement to point the call out the specific FXO port. I use 3999 at each campus - just with each campus' partition. Since CUC knows noting about partitions, I would be unable to directly send the call from CUC to the DN within each campus' partition. I will need to either employ a translation pattern, point the call to a DN that forwards all calls to 3999 within ABC's partition, or use a DID for the route pattern. 

[Elliot Dierksen]

I assume it is miss-dials that are triggering this, right? You could always prefix the pattern with "**" or "##" which would get dropped when being sent to the gateway. Create a translation pattern for the non-prefixed number that is blocked.

[DAVID BURKHART]

Yes - people are dialing 3999 for various reasons other than needing to put the campus in lockdown. The issue is less the lockdown than the time it takes to clear the campus from  lockdown - going to each door, unlocking it, and telling the teachers it's safe. On our high school campuses, this costs a lot of educational time! 

I'm afraid I do not understand how either prefix resolves the issue. We don't want to prevent dialing the extension - just want them to confirm they really meant to lockdown the campus. 

[Elliot Dierksen]

I just thought of another idea. You put put a forced auth code on the pattern for the lockdown number.

[DAVID BURKHART]

Now this is an interesting idea. It is simpler, for sure! My concern with utilizing CUC is the complexity this brings into the system. In truth, the solution is to get the phone out of the mix and use badges with panic buttons instead! 

As I'm thinking about it, I realized the forced authorization code could be an impediment to actually getting a legitimate lockdown from being deployed if the caller did not know or remember the code. That would be a problem. It sounded good, though! 

[Elliot Dierksen]

---

@DAVID BURKHART wrote:

As I'm thinking about it, I realized the forced authorization code could be an impediment to actually getting a legitimate lockdown from being deployed if the caller did not know or remember the code. That would be a problem. It sounded good, though! 

---

The code could be any single digit number. The caller would need to do a "#" at the end to make it go. It doesn't sound like it needs to be high security, it just sounds like you want to stop fat finger dials. Heck, you could add a code for every single digit number! Telling the users to dial "1#" to confirm the lock-down when they get the FAC prompt doesn't sound like a huge deal to me. It still needs to be approved by whoever has the last word on safety issues though.

[Steven L]

911 Call Announcement - Cisco Community

Take a look at that. You can deploy the same thing. Play an announcement that allows the caller to hang up before locking everything down

[Maren Mahoney]

@Steven L - This is an excellent idea. There would need to be one hunt per campus (with the 3999 in the campus-specific partition), but the same announcement and MOH Audio Source could be used for all of them.

Still a complex config, but it does keep everything in CUCM rather than looping through CUC. If the OP doesn't need users to actively press a keypress, and a simple delay with announcement will suffice, I think you've found a winner.

Maren

[Steven L]

yes, it would be a bit complex.

@DAVID BURKHART , the link i posted above is related to 911 and a little more complex than it has to be. 

even without 911 it is a bit complex but would address your issue. can probably come up with a simplified design if your interested in this route

[DAVID BURKHART]

I'm struggling with making the translation (no pun intended) from 911 to 3999 and all the other "the Directory Number is irrelevant" numbers needed. I think I'll need to whiteboard this to find the solution/path to make it work - but I think it's the solution. Once I make it work, I'll definitely mark it as so. 

[Steven L]

let me know if i can help. solving these kinds of problems breaks up the monotony......:)