no incoming calls to DID's that start with a "1" 1

Check that the 1xxx extensions have CLS = UDI

Also do a test by creating an ACD of 1xxx with NCFW going to a known number and seeing if your DID call works.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Also check that your 2 PRI's have the RDB set correctly and have been given the correct IDC table number. Post the RDB and the IDC used.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Thanks for the reply. ACD to any other extension does not work, fast busy with dch error cause 42. Direct DID to analog same, fast busy. IDC table to any other extension except for 1xxx, works. IDC table to 1xxx fails, fast busy cause 42.
Verizon says its my side of course. Waiting to see if Verizon is sending any caller id info over the 1xxx DID range. Both PRI loops are in the same RDB.

I thibk it's best to post your IDC table and RDB information.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

IDC table is very large. I printed out a short version of it, not sure if you want the entire thing or if this is enough to check.

TYPE RDB
CUST 00
ROUT 13
DES LOOP 13
TKTP DID
M911_ANI NO
M911_TONE NO
NPID_TBL_NUM 0
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI
ISDN YES
MODE PRA
IFC NI2
CBCR NO
NCOS 0
SBN NO
PNI 00001
NCNA YES
NCRD NO
CHTY BCH
CPFXS YES
CPUB OFF
DAPC NO
BCOT 0
INTC NO
MBXR NO
DSEL VCE
PTYP PRI
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
RANX NO
SRCH LIN
TRMB YES
STEP
ACOD 8013
TCPP NO
PII NO
TARG
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 0 *
NDNO 0
DEXT NO
DNAM NO
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
FLH 510


PAGE 002

GRD 896
SFB 3
NBS 2048
NBL 4096

IENB 5
VSS 0
VGD 6
DRNG NO
CDR YES
INC YES
LAST NO
QREC NO
OAL YES
AIA NO
OAN YES
OPD NO
CDRX NO
NATL YES
VRAT NO
MUS YES
MRT 81
RACD NO
EQAR NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQ NO
OHQT 00
TDET NO
TTBL 0
ATAN NO
PLEV 2
MCTS NO
ALRM NO
ART 0
SGRP 0
ARDN NO
AACR NO

DISK SPACE NEEDED: 808 KBYTES
REQ prt
TYPE idc
CUST 0
DCNO 0

DCNO 0
IDGT CDGT
2555 6298
4001 1013
4002 1077
4003 1078
4004 1079
4005 1080
4006 1081
4007 1082
4008 1083
4009 1084
4010 1085
4011 1086
4012 1087
4013 2013
4015 1090
4016 1091
4017 1092
4018 1093
4019 1094
4020 1095
4021 1096
4022 1097
4023 1098
4024 5076
4025 5077
4026 1038
4027 2077
4028 2078
4029 2079
4030 2080
4031 2081
4032 2082
4033 2083
4034 2084
4035 2085
4036 2086
4037 2087
4038 2089
4039 2090
4040 2091
4041 2092
4042 2093
4043

Im not that familiar with North American protocols, but it doesn't seem to be that different to the UK ones.

The IDC seems fine. The only thing that it could be if the Telco is sending other digits such as 6 instead of 4 that they should be using.

You could try and add a couple of longer digit lengths that don't conflict on IDC table 0.

Also try monitoring the D channel to see if you get any indication of a call trying to dial in.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Thanks for that. You might be onto something with the digits. I did bring it up to Verizon already, but they came back said they are sending 4 digits. I did however put in 10 digits in the IDC table and the call went through to a 1xxx range. They still deny the issue is on there side. I am not sure what the IDC table has to do with telco at the point of the internal transfer but apparently it has some bearing. I am also looking into caller id with name being sent along with the 1xxx range, and we are set for NDS on the dch.

You might need to use a new IDC table but at least you know where the problem is.

I have a Procomm Plus script to input IDC entries as it looks as if all yours don't follow in sequence.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

I tested all this with a new IDC table. Thanks for the script offer but yeah these numbers are all over the place. Still waiting for telco to come to site and get a test call into their Tberd.

Verizon tested and was able to get a call into their Tberd so the problem looks like its on the PBX side for sure. I just outed all the PRI data and rebuilt it, but still same problem. Where is there a 1 conflicting on this pbx? I checked FCR in 49 and it has a bunch of deny's that all start with a 1.

The FCR tables apply to outgoing calls.

Download the attached tool and follow the instructions to compile a complete list of your DN that's been configured.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Thanks again. I tried the file but dont see the .exe file only see .txt
Ill check again. Do you think this could be corrupt data? The software has not changed in many years. I am thinking of doing a sysload.

Try this one

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Or this one

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Thanks for the files again. Unfortunately for me I've been trying to get the dnb file from the remote pc to my pc all day, and finally got it over to find that the excel file is locked and I cant enable editing to upload the dnb. My laptop is always a piece of shit so I am sure thats the problem. What are we looking for with this full dnb anyway?

Just follow my link and email me the DNB. Also do the TNB and I'll see if I can compile it for you.

Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website = linkedin

Found that the calls that fail are coming in as 3.1 khz audio {BCAP 85} and the calls that are good come in as speech {BCAP 81}. So it's getting kicked back to Verizon. We'll see

So the 3.1 does not seem to be the issue. I do see that incoming calls that fail are basically making 3 calls at once. We are using loop 44, so channels 44-1, 44-2,and then 44-1 are being used for the single call in to a 1xxx extension. I guess this is why we are getting the dch error cause 42, switch congestion. Why are 3 calls being made to only 1xxx extensions?
If I build 1xxx (1993) in the IDC and point it to a 2xxx ACD DN, and NCFW it back to the 1xxx (1993) the call goes through. I guess it's a work around for now.

found the problem..drum roll please...it was the speed call list 0 that had the ac1 code plus 1 programmed on the 1. So every call that came in with the 1 got the default pretranslation treatment. Perfect example of why we do not build anything on speed call list 0