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. 

[DAVID BURKHART]

@Steven L Can you help me understand at what location in the 911 Call Announcement document the 3999 would be inserted? Right now 3999 exists in every campus partition as a Route List pointing to the router on each campus, which picks up the pattern and points it out the appropriate FXO port. 

Is the call routing in this new scenario going to be
Call translation pattern 3999 that points to Hunt Pilot DN to play Announcement > Hunt List > Line Group > CTI port...

I'm struggling with all these hops. 

[Steven L]

i would use a standard local route group.

use the trunk to the router in the local route group for each device pool.

so 3999 would point to a hunt pilot that would queue and play the message, then would route to the LRG....the local SIP trunk.

[Steven L]

i can try and make a drawing but am in the middle of something right now

[DAVID BURKHART]

OK - Here's what I've got, and it's routing to the FXO port but not playing the announcement. 

• 3999 in campus ABC partition - Hunt Pilot with Announcement selected also points "When no hunt members answer, are logged in, or registered" calls to 0423999 in the ABC campus partition (the Hunt List not Line Group are even used, so I don't understand why they are there).
• 0423999 in ABC partition is a Route Pattern the points incoming calls to the router on the campus.
• Dial-peer statement in router points 0423999 calls to an FXO port on the router.
• When I dial 3999 from within the campus partition, the call blows past the Announcement in the Hunt Pilot and hits the FXO port on the router. 

What did I miss? 

[Steven L]

sent PM

[Jason@Logicalis]

It looks like you are close to a solution, and I commend everyone coming together working on a solution. But as you referenced in one of your other posts, a better solution is access key cards or dare I say... InformaCast or something similar?  I am not a sales person for InformaCast by no means but I've deployed InformaCast for similar lock down solutions.

They integrated InformaCast with their electronic door lock system so that if the school needs to go into lock down. The solution is possible because of InformaCast’s ability to easily integrate with other systems. three things happen

1. InformaCast broadcasts an alert tone and pre-recorded warning for people to seek shelter (this goes out to the Cisco phone system, overhead speakers, and administrators’ email accounts)
2. All of the doors in the facility automatically lock
3. After a preset amount of time, staff badges are disabled so they can’t be used by an intruder

[DAVID BURKHART]

Jason@Logicalis I appreciate your reply, but we already have most of those systems in place. No need to recreate it all with a different paid system. Additionally, we do hope to leave this system and replace it with one that is based on badges rather than phones - which will make anything I do here moot. 

[Maren Mahoney]

Did you set up the Native Call Queuing part? When you do, be sure that you set up the MoH Audio Source to "Play Announcement before routing to Hunt Member".

The reason the Hunt List and Line Group are in there is that without those components the Hunt is "incomplete" and CUCM will not route a call through it.

Maren

[Steven L]

I worked with David live on Friday on this. There were a few issues here:

1. There was no annunciator associated with the device pool he was testing from. 
2. No Local Route Groups configured.

I walked him through completing the configuration and we successfully tested one of his sites.

At this point i need to give him a list of the steps he needs to take for each site/device pool.

Jason@Logicalis i don't think InformaCast is the right choice here. @DAVID BURKHART  has a solution that already works. He is trying to solve a specific problem with misdials. No need to rip it all out and start over and have to budget for that.

[DAVID BURKHART]

I do very much appreciate your help, @Steven L. I look forward to getting this finalized and off my plate!