CER & 911

[mightyking]

Hello Folks,

We have 7 different locations (Campus) in the US. CER (HQ) is serving the emergency calls.  When both CERs are down, the emergency call should be routed to the local 911 service of the location where the 911 call is originated. For each location, I have two partitions and two route patterns, one for CER and one for 911. In the secondery CER, I need to route the call to the 911 route pattern in the case the secondary CER is down.  How do I implement this? We have security desk but for some reasons that I ignor, the managment has decided to send the call directly to 911 and not to the secuirty desk. Your help is very much appreciated.

MK

[William Bell]

MK,

The solution depends on which versions we are talking about here. If you are using CUCM 7.x then you can use Standard Local Route Groups (LRG) to accomplish your routing requirements. In a typical CER cluster model you probably have 911 configured as a CTI Route Point (pointing to the first node in the CER cluster) and 912 configured as a CTI Route Point (pointing to the second node in the cluster). You have '911' configured to Call Forward on Failure to 912 and then you need to have 912 configured to Forward on Failure to a dynamic destination.

This "dynamic destination" is the tricky part. There can be only one CFoF destination. Fortunately, with CUCM 7.x you can configure a Route Pattern (e.g. 9911).  This pattern can point to a Route List (e.g. Emergency_RL).  The Emergency_RL can be configured with a single Route Group. Specifically, you configure the Route List with the "Standard Local Route Group".

This is only 1/2 of the equation. You then need to have Route Groups configured for each one of your seven sites that would contain a local trunk (or set of trunks, preferable) that can be used to route emergency calls to the appropriate PSAP.  Then you need to assigned these route groups as Local Route Groups on the Device Pool level.

There are lots of design assumptions I am making here. For example, I assume you have some logic to how device pools are allocated. You will need to work out/test calls to ensure that the PSAP knows where the calls came from. Since you are bypassing CER in this case, the PS-ALI records won't be very helpful.

HTH.

Regards,
Bill

[mightyking]

Thanks Bill,

We are using CUCM 7.1.3

What would be the partition and CSS for the 9911 route pattern? Do I need to create new PT and CSS?

MK

[mightyking]

As I said the CUCM version is 7.1.3 but we are not using those new featuers such as "Standard Local Route Group". We have duplicated all the route patterns and route groupes for each site. Do you think I can use the solution you mentioned for the 911?

What is the other solution if we don't want to use the "Local Route Group"?

Thanks,

MK

[William Bell]

MK,

1. Yes, I would create a new CSS/Partition for this scenario. The CSS would be assigned to the CFoF configuration on the 912 CTI Route Point. The partition would not need to be visible from any other CSS. Actually, I wouldn't want it to be visible as it would have  a very specific function.

2. If you were to go the LRG route, then you can certainly assign Standard Local Route Groups to device pools without having an impact on Route Lists that don't use LRG.  IOW, if a Route List does NOT have the Standard Local Route Group assigned then CUCM would never try to use a LRG assigned to a device pool.  Also, if your Route List had a Standard Local Route Group BUT the device did not have a LRG (via Device Pool settings) then the Standard Local Route Group is bypassed and the next Route Group in the Route List is used.  That is a key point for "backward compatibility" (lack of a better term ;-)

3. Another solution that we had to use for a 3.3/4.1 customer was leveraging the behavior of the CSS.  In 4.1, when CFoF had a CSS of "" (i.e. no CSS was assigned) the actual behavior was that the CUCM digit analysis subsystem would "fall back" to using the CSS of the calling device.  This was actually an unexpected behavior (from Cisco's perspective) that we came across by accident. At the time, we told Cisco TAC about it and they said "really?" and then a DE approved this approach for our use with the caveat that this behavior may go away in later releases.  This was many moons ago (circa 2003 or 2004?).  Anyway, we created a unique 999911 "fallback" pattern for each site and put this in their device CSS.  When site A would hit the CFoF (null CSS) config, CUCM would use the Site-A-CSS.  For site B, the Site-B-CSS, and so on.

So, I recommend that you look into leveraging LRG.

HTH.

Regards,
Bill

Please rate helpful posts.

[mightyking]

Thanks Bill, I really  appreciate your help. I think, I am better to go with the first solution but need to convince the IT manager. The Local Route Group is the solution you recommand, is that right? As for the 9911 route pattern, does it need to be 9.911 in order to be able to predot the 9? And lasly, what partitions does the CSS of the CFOF need to contain?

MK

[William Bell]

Yes, I would go with LRG.  Of course, you will want to test behavior and ANI presentation to ensure it meets your particular needs. In regards to the actual pattern, it doesn't really matter to be honest. As with "legacy" route lists, you can do digit manipulation on the route pattern or the route group. Even if the route group is the Standard Route Group, you can still perform digit manipulation. For that matter, you can leverage transformation patterns at the gateway level to give you ultimate flexibility. So, you could make the pattern anything you wanted and then transform the pattern to what the carrier is expecting (e.g. 911).

HTH.

Regards,

Bill

[mightyking]

Is the CFoF partition only partition that the CFoF CSS will contain?

MK

[William Bell]

If you only plan on redirecting to this new route pattern, then yes.

HTH.

Regards,
Bill

[mightyking]

Thanks Bill, I will start implementing this solution tomorrow.

MK