911 / CESID / Two Comcast PRI

[idxman01]

Anyone have experience with 911 services via Comcast PRI's?  I'm still dealing with this and it's taken an extreme level of effort from my end just to get with the right techs.  Lots of drama from them not having the override set to not understanding the cesid being sent based on the base device, not hotdesk extension.

Here's the issue: Two PRI's, two MCD 3300's working together.  Install group from Mitel is saying the 911 calls can only go out one PRI unless it's down.  Part of the ARS routing.  I see it in there, that makes sense.

Then comcast is telling me that they can't allow a BTN to pass for 911 if it's not a number on that specific PRI.  (area code 123 can't do 911 out the PRI that only contains area code 456)

ok: So I can change all the CESID identifiers to use one area code.  But then what if the primary PRI goes down and calls are routed out the secondary?  All that mapping I just did is useless.

Is there a way to dynamically set the cesid on the 3300 side or do I need to keep pounding on Comcast?

In contrast I don't believe we had this issue with our old Axxcess system.  I'm not familiar with it, but suspect 911 went out local pots lines since there was a pbx at each site.

[JasonTL]

I have had to contact the 911 center on installs before for a similar issue. I had all the CESID set in place for each location. The 911 center (where all my calls went due to the one PRI in use like your setup) would then forward to the correct location (city/county) depending on the incoming CESID. The 911 database had each of the locations CESID and which 911 center the call should actually go to. Not sure if all 911 centers will work with you or not, but ours did.

[idxman01]

Appreciate it, that does sound familiar.

In this scenario did you only have one PRI without a failover and/or additional area codes?  Right now that's the part that I'm hung up on.

Am pretty sure I can just define CESID numbers on our primary PRI and we'll be ok 99% of the time.  Though during failover (which did happen a few months back) the secondary PRI would not allow the CESID's we send and override back to the primary/base number on the trunk.

I also looked at location/zone routing this weekend.  Does not seem like an automated solution, however I think it would provide more flexibility.

ie: Zone 1 (based on IP) has cesid 111-234-5678.  During failover I could manually go in and change each zone to other area code's cesid.  999-234-5678

Is frustrating as each side is telling me they can't do anything and it's the other's responsibility.  Meanwhile our 911 calls are hitting the wrong PD.

[idxman01]

*bump

Am interested to hear from anyone with a similar scenario.  Have been working with Comcast engineers this past week and we don't have a good way to handle failover.  At this time we're just defining and testing a series of cesid's for both area codes.  Most of the time the primary 3300 and PRI is up and fine, but we need to fix this for the long-term.

Any tips on zones and can they operate differently while phones are failed over to the secondary?

[idxman01]

I'm hoping for a few more ideas.

Since the above I've worked with comcast to update the DB (ali/ani?) whereby we assign each address/zone an identifier for both area codes.  So: "123 example street" has both 777-222-3333 and 888-444-5555 numbers.  This has been tested with almost every PSAP and operates properly.

The issue is resiliency on the 3300 and how it continues to send the CESID from the primary over an IP Trunk to the secondary.  I've moved away from hard-coding cesid's on the base devices configured zones.  Again, this has worked just fine except resiliency.  It was also very handy during testing as I didn't need to reboot or logout of the phone.

One attempt was to disable SDS on the zone form so each 3300 would have unique numbers.  Technically that worked to separate the forms, however, it failed in practice as I guess the primary 3300 is responsible for assigning the cesid/cpn before routing over.

Is there a way to force the PBX that ultimately sends the call out a PRI (or SIP) to the pstn/real world to do the assignment or some kind of translation?

During a major failover (pri dies, 3300 dies) I could simply update the zone form, but cannot account for call re-routing over the IP trunk due to all channels being occupied.

Location-based routing doesn't seem to help in this situation either.  Sure, I can add the LBR prefix and push calls to different 3300/PRI's as needed, but resiliency continues to be the sticking point.


And if you've read this far down, I appreciate that.  I'm starting to think that I'm putting in too much time on this issue since 100% of our 911 calls have gone out the primary.  The not so funny part is that it's due to an error in ARS by Mitel installers.  They setup a digit modification plan on the emergency IP trunk route to remove 1 digit from the front.  So then the secondary 3300 removes another digit, as it should, and bingo the call doesn't go through.   


Thank You,

[ralph]

Just thinking out loud here so bear with me.

What would happen, if during a fail over event, you did not route 911 calls out an emergency route?

The system would then not look at the CESID programming and send out the caller ID of the phone.
Knowing that, you could program all the phones to use one specific number if it on the fail over PRI (or perhaps a range of DIDs).

The only down side I can think of here is that non-emergency calls would also show the "one number" if they failed over to the other PRI.

Ralph

[idxman01]

Ralph, I appreciate the reply and idea on that one.  You're right that would at least not pull the cesid giving us some wiggle room on the secondary.

I'm not sure we can do that with hotdesking and our recent push to move most staff to match their DID with CPN.  Have to chew on that a bit more soon.

http://mitelforums.com/forum/index.php?topic=8330.new;topicseen#new

Though I think the above trunk group workaround will provide us the breathing room needed to ensure an emergency call can go out the primary 3300/pri.  It's still not seamless and I'm pretty steamed about all of it, but definitely workable.  (steamed since I'm a customer, not a var/msp or mitel engineer - this kind of stuff is their job...)

Thanks again!