Two Carriers, CS1K Only Passes One to 2nd PBX

[ComradeSlice]

I have a CS1000 with three T1's: a DID PRI (NI2) from our local carrier, a TIE E&M from our long distance carrier, and a TIE PRI (QSIG/ISGF) that goes to an Asterisk PBX. I use DSC's to route extensions (4-digit) to the Asterisk TIE. Asterisk can make outgoing calls over the local and long distance trunks however incoming calls only go to Asterisk from the local trunk. Incoming calls from the long distance trunk to Asterisk get a fast busy. I see nothing on the Asterisk DCH when a call comes over the long distance trunk so I'm assuming the call is getting dropped because of the Meridian. Calls going from the long distance trunk to a Meridian extension complete successfully. What could be causing this? Here is some info.

Thanks in advance!

Local:

DES  LIGHTPATH
TN   006 01
TYPE DID
CDEN SD
CUST 0
TRK  PRI
PDCA 1
PCML MU
NCOS 0
RTMB 6 1
B-CHANNEL SIGNALING
NITE
STRI/STRO OWK OWK
AST  NO
IAPG 0
CLS  UNR DTN CND WTA LPR APN THFD HKD
     P10 VNL
TKID
DATE 27 JUN 2014

Long Distance:

DES
TN   009 01
TYPE TIE
CDEN SD
CUST 0
TRK  DTI
PDCA 1
PCML MU
NCOS 0
RTMB 4 1
TGAR 0
SIGL EAM
STRI/STRO WNK WNK
SUPN YES
AST  NO
IAPG 0
CLS  UNR DTN CND WTA LPR APN THFD HKD
     P10 VNL
TKID
DATE 15 JUL 2013

Asterisk:

DES  ASTERISK
TN   007 01
TYPE TIE
CDEN SD
CUST 0
TRK  PRI
PDCA 1
PCML MU
NCOS 0
RTMB 7 1
B-CHANNEL SIGNALING
TGAR 1
AST  NO
IAPG 0
CLS  UNR DTN CND WTA LPR APN THFD HKD
     P10 VNL
TKID
DATE 16 FEB 2018

 

[ComradeSlice]

I changed TRNX and EXTT to "YES" in NET_DATA per a previous recommendation. Before that they were both "NO". FTOP was "FRES" and is now "FTLY". I do not see a prompt for DITI in CHG or PRT. Calls from the outside are still going to our NITE DN.

I originally thought the issue might have to do with routing from DID to TIE but our local loop is a DID and it routes to Asterisk successfully. I posted a few days ago that I converted Loop 9 (Long Distance) from TIE to DID. So both circuits that handle calls from the outside world are DIDs. Asterisk is a TIE.

 

[kstaff22]

I was going to suggest the NET data DITI=YES---------not sure why you are not seeing that in your net data.
I would change the FTOP to FRES--that will override any trunk to trunk restrictions---

 

[KCFLHRC]

FRES is Fully Restricted, I don't think he wants that

FTOP Flexible Trunk to Trunk Options. basic-23
(FRES) Flexible Trunk to Trunk Connections
Restricted. FTT feature is inactive.
TBFT Trunk Barring Flexible Trunk to Trunk
Connections. FTT adds new restrictions on
connections not barred by TBAR
FTTB Flexible Trunk to Trunk connections Trunk
Barring. FTT lifts TBAR restrictions for routes
barred by TBAR. FTT cannot add any new
restrictions for non-barred routes.
FTLY Flexible Trunk to Trunk Connections Only. All
set based trunk to trunk connections for
Transfer and Conference are controlled by

 

[ComradeSlice]

I believe I would need PKG 131 for DITI. Correct me if I'm wrong but isn't this a problem with Loop 9 itself, not the CDB? Loops 6 and 9 are both DID so I wouldn't think it's a trunk-to-trunk setting in the CDB. It's only Loop 9 that's not routing the call. Any call going towards Loop 7 from Loop 9 goes to our NITE DN.

NET_DATA:

TYPE NET_DATA
CUST 00
OPT RTD
AC2
FNP YES
ISDN YES
  PNI 0
  PINX_DN
  MBG 0
  BSGC 65535
  PFX1 516
  PFX2 357
  HLOC
  LSC
  RCNT 5
  PSTN NO
  TNDM 15
  PCMC 15
  SATD 1
  OCLI NO
TRNX YES
EXTT YES
FTOP FTLY
VNR NO
NIT 8
FOPT 14

RDR_DATA:

TYPE RDR_DATA
CUST 00
OPT CFF CFRA PVCD CWRD
FNAD FDN
FNAT FDN
FNAL FDN
CFTA YES
CCFWDN
CFN0 4
CFN1 4
CFN2 2
DFN0 4
DFN1 4
DFN2 2
DNDH NO
MDID YES
NDID YES
MWFB YES
TRCL 0
CRT0 00 00 00 00
CRT1 00 00 00 00
CRT2 00 00 00 00
CRT3 00 00 00 00
DAY0
DAY1
DAY2
DAY3
HOLIDAY0
HOLIDAY1
HOLIDAY2
HOLIDAY3

 

[ComradeSlice]

Also, SUPN is "YES" for all 20 Loop 9 DID's (it's a 20 channel DTI).

 

[RickyPone]

Ok kinda forget where we are but can you try this? The dn that you are trying to pass to Asterisk, can you put that on a set on the CS1000? If you can and it terminates on the set you program it on that will confirm what and how many digits they are sending on the LD route. I hate beating this horse but you need a way to confirm what is arriving to the switch. I also NDGT set to 31. If you are using DNIS then I think that has to be the exact number of digits you're expecting. Not real sure about that though. And that other question I asked about tenant service. That will cause exactly what is happening here. When you build a TN do you have to define TEN in the database? If it were me first thing I would do is make these incoming digits ring on a phone on the CS1k.

 

[phones1]

ld 21
prt
net
cust x

LOOK for DITI in the print out

DITI (no)yes --> DID to TIE connections allowed

As the above post state you have checked that a successful call is terminated on a local set haven't you????

Remember if it doesn't work hit it harder

Scott UK

 

[ComradeSlice]

I do not have the DITI prompt.

Nortel phones work just fine with the DNs on SCR keys. I do not need to make any other changes in the database besides programming the TN itself.

My vendor says AT&T is sending 4 digits and our DNs are 4 digits.

 

[RickyPone]

If it rings through to a Nortel phone then they are sending four. If you don't have to input anything for TEN when building a phone then you aren't using tenant service. I would involve your vendor at this point. Make then escalate to TAC.

 

[ComradeSlice]

My vendor says they do not know what to do. That's why I came here

 

[KCFLHRC]

So 3 things to look at in the NET_DATA

DITI = YES
TRNX = YES
EXTT = YES

If those are all set correct, then I have one other suggestion and then I'm out

Change the NCOS on the TIE LD route to 3 on all trunks. I think this may be your issue. I ran across this years ago on a system. Since 0 is a default value I think I ended up make it a 3 and it worked. What do you have to lose? Worth a shot. And if this works, get another vendor

 

[ComradeSlice]

I do not have the package for DITI. I believe that requires a specific package.

What could make incoming calls work on Loop 6 and not Loop 9? They are both DID's. I'll try out changing the NCOS.

 

[KCFLHRC]

The call that is failing is TIE to TIE and the calls that work are DID to TIE, that is the difference. Just try it. Change the NCOS on the inbound LD Tie Route trunks to a 3 and leave the TIE to Asterisk alone at 0

 

[KCFLHRC]

One other thought if the above doesn't work. Change the TIE Route to the Asterisk at the RCLS and make it INT instead of EXT

 

[ComradeSlice]

I had our vendor change AT&T to a DID, so both of the outside trunks are DID. Asterisk is still a TIE. RCLS INT and NCOS 3 did not work

I did notice these BUGs output every time someone calls in via AT&T, and the call goes to our Automated Attendant. TN 10 12 is a Meridian Mail channel.

BUG4006
BUG4006  : 00198924 00001002 00008218 00001CA0 0000088A 19 00000001 00000001 000
00000 0 0 00002084 0000AAA7 00000000 00000000 00000000 00000000 00000000 00000E
BUG4006  +   1067E808 10629ECA 10629744 101E873C 101DBC6C
BUG4006 + 101DB2AC 101DAD70 101DA25C 1082E364 1082DDC2
BUG4006  + 1051186E 10510EC4 1050F5E8 1050F12C 1050E1CE
BUG4006 + 1050DFCC 108D9D18 108D8B94 108C3FEA 10E65BAC
BUG4006  + 10E6550C 10E65404 10E63080

BUG6246
BUG6246  : 10 0 0 12 7839
BUG6246  +   1067E808 101E4F80 101E4748 101E20CE 101DA250
BUG6246 + 10E6360A 10E63246 10E63128

 

[KCFLHRC]

I wouldn't have changed the ATT to DID, that may cause more issues than you have right now. By changing multiple things you may never know what is causing the issue

 

[phones1]

how can you have a DTI circuit without having the DTI packages?

Remember if it doesn't work hit it harder

Scott UK

 

[RickyPone]

So maybe try this for a work around. Build a phantom tn with the incoming dn. Set a dcfw to a dsc pointed to the asterisk pri. PITA but if it allows you to pass calls who cares right?

 

[RickyPone]

And try one other thing just to humor me. Change the FLEN to 0.

 

[ComradeSlice]

I've set FLEN to 0 on one of the DSC's and built a phantom TN. Testing...

I've read that DITI is used internationally. I don't know if that's true or not.