911 CAMA TRUNKS BLOCKING PROBLEMS

[JosieL]

Any tips out there for this problem.

We have a Teltronics 911 ANI system.
Two Cama Trunks.
If a user calls 911 the call goes through but then the trunk goes blocked. With the blocked state being

B5 Blocked by equipment outside the system, for example another exchange which is not a digital system.


The following is the route setup
RODAP:ROU=15;
ROUTE DATA
ROU TYPE VARC VARI VARO FILTER
15 TL22 H'002F0031 H'42011020 NO

END

<ROCAP:ROU=15;
ROUTE CATEGORY DATA
ROU SEL TRM SERV NODG DIST DISL TRAF SIG BCAP
15 0030000000000011 4 0010030000 0 30 128 00151515 101100000000 001100

END

<RODDPEST=305;
EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
305 15 0005000000000250000000000 0 4 0
10 1 0005000000000250000000000 3 4 0 300911

END

 

[dstrang1]

Hi Josie,

Here are the settings I had for my system (BC9.0E) when we had a CAMA trunk/Telident setup.

I ditched all that & sent everything out our local PRI's...life is much better now.

I gave all my equipment and documents to Bill Phillips at Mansfield U. -- you might contact him to see if he ever got it working.....he can help make sure your E&M connections and card strapping are correct.

Good luck,


Dave Strang


<rodap:rou=6;
ROUTE DATA
ROU TYPE VARC VARI VARO FILTER
6 TL22 H'002F0031 H'42011020 NO

END

<rocap:rou=6;
ROUTE CATEGORY DATA
ROU SEL TRM SERV NODG DIST DISL TRAF
6 002000000000 4 0010000000 0 5 128 00151515
SIG BCAP
101100000060 001100

END

<roddp:dest=57038;
EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
57038 6 000500000000025000 0 1 0

 

[JosieL]

Dave
Thanks, but not all of our phones want to send Call ID out, (i.e. Sheriff personnel, Child Abuse Case workers) so for 911 I need Telident to send the info Unless you know of a way to bypass Telident and Cama trunks, which I would love to hear of options.
Jlinnebur@larimer.org

 

[dstrang1]

JosieL (TechnicalUser) 11 Jul 05 14:11 sed:

>Dave
>Thanks, but not all of our phones want to send Call ID >out, (i.e. Sheriff personnel, Child Abuse Case workers) so >for 911 I need Telident to send the info Unless you know >of a way to bypass Telident and Cama trunks, which I would >love to hear of options.

Josie,

If you have PRI for your local outbound services, you can restrict number presentation (ADC bit 3 for EX and ADC bit 4 for KS) -- shows as "unlisted" on internal display -- and set the network affiliation (ADC bit 9 for EX and ADC bit 10 for KS) to allow presentaion to the network.

The call goes to the PSTN as "user screened", IOW, will show "private" on a caller-ID display, but the calling number is still contained in the call setup -- and therefore will still be visible to 911 dispatch and other higher priority entities.

For non-DID extensions, you can use number translation to change the outbound extension to public numberwhich 911 dispatchers can use to call back in case of a hang-up (you have to translate in both directions). Or you can use a "common public number per lim" if you have LIMs with extensions in only one location. The common public number is sent if if "network affiliation" is set to 0 for KS or EX.

You can test whether or not 911 will work on your PRI's by setting up an LCR entry for 911 that points to your outbound PRI -- use ENT and DNT2, you want to make it easy to undo quickly after a couple of calls. Set a common public number for your LIM, then make 3 calls: 1st with your number presentation unrestricted, 2nd with number presentation restricted, and 3rd with "network affiliation" set to 0 -- each time ask the dispatcher what calling party info they see on their display.

If you have a way to let them know ahead of time that your are going to place some test calls, I'm sure they'll be grateful.

Lemme know if you want some printouts of what I have set up here.


Good luck,

Dave Strang

Jlinnebur@larimer.org

 

[JosieL]

Dave
Yes, post some printouts. I will look this over. One more question. We only have a 13 LIM system but we do go over a 3 city geographical area. LIMs are set up to attach appropriate prefix but even within that we have several buildings. How is that affected I need to get 911 to the right building if called.
Always a layer upon layer

 

[dstrang1]

JosieL (TechnicalUser sed:
>Dave
>Yes, post some printouts.

below:

>I will look this over. One more question. We only have a >13 LIM system but we do go over a 3 city geographical >area. LIMs are set up to attach appropriate prefix but >even within that we have several buildings. How is that >affected I need to get 911 to the right building if called.

Your number translations would likely mirror whatever your Telident puts out......whatever method you currently use to update your 911 location database info would also not change.

The STS box only prefixes/changes the station digits it receives -- it deals mainly with number ranges, and also has a default record if no number, or bogus is received. The Actual location info that populates the screen in the dispatch center is pulled from the 911 database based on the received number.......as long as the number sent over the PRI is the same as that sent over the CAMA trunk for a given extension, then the location info will be correct.

Like I said, if you can set up a quick test to send 911 over one of your PRI's from an extension for which the Telident translation is known, you can verify whether or not it will work. If it does, you can continue with the Telident while you work on the rest of the programming & then switch over when you're comfortable.

>Always a layer upon layer

Job security!!! ;-)

Here's the printouts......

Our LEC is Verizon, the outbound PRI route is 40 -- I hope this looks better on the full page.


<oprsp:rou=40;
OPERATOR ROUTE NAME
ROU NAME
40 GTE

END

<rondp:rou=40;
ROUTE NUMBER DATA
ROU PRE ROUDIR EXNOPU EXNOPR TERAC
40 2-740

END

<lcddp:tab=dnt2,entry=911;
NOT ACCEPTED
ENTRY NOT FOUND

<lcddp:tab=dnt1,entry=911;
LEAST COST DESTINATION DATA
EXCEPTIONS TABLE
ENTRY TRC PRE ACCT FRCT TOLL CBCS BTON TNS OSA
911 0 0 8 111111011111111 0
END

<roddp:dest=3508;
EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
3508 40 102600000000025000 0 5 0

END

<lcddp:tab=fdt;
LEAST COST DESTINATION DATA
FICTITIOUS DESTINATION TABLE
FRCT TZONE PRE
8 1 3508


<cpdlp;lim=1;
COMMON PUBLIC DIRECTORY NUMBER PER LIM DATA

LIM DIR

1 31000
2 31000
3 31000
4 31000
60 31000


<nutrp;entry=392;
NUMBER CONVERSION DATA
ENTRY CNVTYP NUMTYP PRE TRC NEWTYP CONT BCAP HLC
5930 0 4 2 0
5931 0 4 2 0
5932 0 4 2 0
5934 0 4 2 0
59391 0 4 2 0
59392 0 4 2 0
59393 0 4 2 0
59394 0 4 2 0
59395 0 4 2 0
59396 0 4 2 0
59397 0 4 2 0
59398 0 4 2 0
59399 0 4 2 0
5942432 0 4 34632 7 0
5944722 0 4 34622 7 0
5944923 0 4 34623 7 0
5949731 0 4 39120 7 0
5970 0 4 2 0
59710 0 4 2 0
59711 0 4 2 0
59712 0 4 2 0
59713 0 4 2 0
59714 0 4 2 0
59715 0 4 2 0
59716 0 4 2 0
59717 0 4 2 0
59718 0 4 2 0
59719 0 4 2 0
59721 0 4 2 0
59725 0 4 2 0
59726 0 4 2 0
59727 0 4 2 0
59728 0 4 2 0
59729 0 4 2 0
59730 0 4 2 0
59731 0 4 2 0
59732 0 4 2 0
59733 0 4 2 0
59735 0 4 2 0
59736 0 4 2 0
5975 0 4 2 0
5976 0 4 2 0
5977 0 4 2 0
59780 0 4 2 0
597810 0 4 2 0
5978110 0 4 39270 7 0
5978111 0 4 39271 7 0
597812 0 4 2 0
597813 0 4 2 0
597814 0 4 2 0
597815 0 4 2 0
597816 0 4 2 0
597817 0 4 2 0
597818 0 4 2 0
597819 0 4 2 0
59782 0 4 2 0
59783 0 4 2 0
59784 0 4 2 0
59786 0 4 2 0
59792 0 4 2 0
59793 0 4 2 0
59794 0 4 2 0
59795 0 4 2 0
59796 0 4 2 0
59797 0 4 2 0
59798 0 4 2 0
59799 0 4 2 0
6542013 0 4 76795 7 0
6543065 0 4 31222 7 0
6544745 0 4 3523 7 0
6993066 0 4 76795 7 0
6993067 0 4 3528 7 0
6993068 0 4 31222 7 0
7726620 0 4 76795 7 0
7731317 0 4 31222 7 0
7732220 0 4 3521 7 0
51001 0 5 73266 5 0
51001 0 6 97078810 5 0
7405931 0 6 5 0
3 1 10 59 0
520 1 10 56662 3 0
528 1 10 56663 3 0
534 1 10 56665 3 0
537 1 10 56669 3 0
538 1 10 56666 3 0
54604 1 10 34622 5 0
54605 1 10 34622 5 0
54606 1 10 34622 5 0
577 1 10 00 0
587 1 10 56667 3 0
589 1 10 56668 3 0
60 1 10 56 0
61 1 10 56 0
66 1 10 56 0
67 1 10 56 0
68 1 10 56 0
69 1 10 56 0
7 1 10 59 0



Good luck,


Dave Strang