jwood

BUG1369
Loop # out-of-range in BCH_TO_TN.

Are there enough channels defined in LD 17? Just a shot in the dark.

Rachelle

100 and 116 were preexisting CBCT T1s, to my building 101 and 117 TIEs to MCI. Never had this BUG prior to adding the DCH controlled T1s. Here is my CEQU:

DLOP NUM DCH FRM LCMT YALM TRSH
PRI 004 23 ESF B8S FDL 00
005 23 ESF B8S FDL 00
006 24 ESF B8S FDL 00
007 24 ESF B8S FDL 00
018 24 ESF B8S FDL 00
019 24 ESF B8S FDL 00
034 23 ESF B8S FDL 00
035 23 ESF B8S FDL 00
050 23 ESF B8S FDL 00
051 23 ESF B8S FDL 00
056 23 ESF B8S FDL 00
057 23 ESF B8S FDL 00
088 23 ESF B8S FDL 00
089 23 ESF B8S FDL 00
100 23 ESF B8S FDL 00
101 23 ESF B8S FDL 00
104 23 ESF B8S FDL 00
116 23 ESF B8S FDL 00
117 23 ESF B8S FDL 00
120 23 ESF B8S FDL 00
121 23 ESF B8S FDL 00

Any idea what loop is pushing this BUG1369? This would help me isolate what needs to be changed.

rlc

Rachelle

In sending an overload of calls to the IVR and requesting to come out of the IVR on 100 and 116 some of the channels are synching up. Unfortunately, on 100, channels 16 through 24 are still FE MBSY and on 116, channels 1 and 17 through 24 are still FE MBSY. When callers request to speak to an agent they ride 116 out first. When all channels on 116 are full the calls then ride 100. As you can see from my description, not all channels are allowing calls to transmit.

All was fine until I built on the other side of the DDP. Could I have mismatched something? Could these services conflict?

rlc

Buckshot

Just a thought...

Are you sure all the channels coming out of the IVR are configured the same as yours? Is it possible that the IVR is having 1 set of parameters (not a true 24 channel card), and your equipment is looking for something different, causing the mismatch?

Rachelle

All was fine with the IVR until I built the new T1s on the other half of the DDPs. To my knowledge, the staff of the IVR did not reallocate or change anything. The only change was done on the DDP card. I built a TIE with DCH to MSDL on that card. So, on each card side 1 is CBCT, not DCH and side 2 is TIE with DCH.


rlc

Rachelle

Here is what is showing up now, from the IVR to/from PBX:

PRI* TRK LOOP 56 - ENBL
FFMT/LCMT/YALMT: ESF/B8Z/FDL
SERVICE RESTORE: YES
YEL ALM PROCESS: YES
ALARM STATUS : NO ALARM
CH 01 - FE MBSY DID VCE * CH 02 - FE MBSY DID VCE *
CH 03 - FE MBSY DID VCE * CH 04 - FE MBSY DID VCE *
CH 05 - FE MBSY DID VCE * CH 06 - FE MBSY DID VCE *
CH 07 - BUSY DID VCE * CH 08 - IDLE DID VCE *
CH 09 - IDLE DID VCE * CH 10 - IDLE DID VCE *
CH 11 - IDLE DID VCE * CH 12 - IDLE DID VCE *
CH 13 - BUSY DID VCE * CH 14 - IDLE DID VCE *
CH 15 - IDLE DID VCE * CH 16 - IDLE DID VCE *
CH 17 - BUSY DID VCE * CH 18 - IDLE DID VCE *
CH 19 - BUSY DID VCE * CH 20 - IDLE DID VCE *
CH 21 - IDLE DID VCE * CH 22 - IDLE DID VCE *
CH 23 - IDLE DID VCE * CH 24 - DCH 12
.STAT 57

PRI* TRK LOOP 57 - ENBL
FFMT/LCMT/YALMT: ESF/B8Z/FDL
SERVICE RESTORE: YES
YEL ALM PROCESS: YES
ALARM STATUS : NO ALARM
CH 01 - FE MBSY DID VCE * CH 02 - FE MBSY DID VCE *
CH 03 - FE MBSY DID VCE * CH 04 - FE MBSY DID VCE *
CH 05 - FE MBSY DID VCE * CH 06 - FE MBSY DID VCE *
CH 07 - IDLE DID VCE * CH 08 - IDLE DID VCE *
CH 09 - BUSY DID VCE * CH 10 - BUSY DID VCE *
CH 11 - IDLE DID VCE * CH 12 - IDLE DID VCE *
CH 13 - BUSY DID VCE * CH 14 - BUSY DID VCE *
CH 15 - BUSY DID VCE * CH 16 - BUSY DID VCE *
CH 17 - IDLE DID VCE * CH 18 - BUSY DID VCE *
CH 19 - FE MBSY DID VCE * CH 20 - IDLE DID VCE *
CH 21 - BUSY DID VCE * CH 22 - BUSY DID VCE *
CH 23 - IDLE DID VOD * CH 24 - DCH 14
.STAT 100

PRI* TRK LOOP 100 - ENBL
FFMT/LCMT/YALMT: ESF/B8Z/FDL
SERVICE RESTORE: YES
YEL ALM PROCESS: YES
ALARM STATUS : NO ALARM
CH 01 - FE MBSY CBCT CH 02 - BUSY CBCT
CH 03 - IDLE CBCT CH 04 - IDLE CBCT
CH 05 - IDLE CBCT CH 06 - IDLE CBCT
CH 07 - IDLE CBCT CH 08 - IDLE CBCT
CH 09 - IDLE CBCT CH 10 - IDLE CBCT
CH 11 - BUSY CBCT CH 12 - IDLE CBCT
CH 13 - IDLE CBCT
CH 15 - IDLE CBCT CH 16 - IDLE CBCT
CH 17 - FE MBSY CBCT CH 18 - FE MBSY CBCT
CH 19 - FE MBSY CBCT CH 20 - FE MBSY CBCT
CH 21 - FE MBSY CBCT CH 22 - FE MBSY CBCT
CH 23 - FE MBSY CBCT CH 24 - FE MBSY CBCT
.STAT 116

PRI* TRK LOOP 116 - ENBL
FFMT/LCMT/YALMT: ESF/B8Z/FDL
SERVICE RESTORE: YES
YEL ALM PROCESS: YES
ALARM STATUS : NO ALARM
CH 01 - IDLE CBCT CH 02 - BUSY CBCT
CH 03 - IDLE CBCT CH 04 - IDLE CBCT
CH 05 - BUSY CBCT CH 06 - BUSY CBCT
CH 07 - IDLE CBCT CH 08 - IDLE CBCT
CH 09 - IDLE CBCT CH 10 - IDLE CBCT
CH 11 - BUSY CBCT CH 12 - BUSY CBCT
CH 13 - IDLE CBCT CH 14 - IDLE CBCT
CH 15 - BUSY CBCT CH 16 - IDLE CBCT
CH 17 - FE MBSY CBCT CH 18 - FE MBSY CBCT
CH 19 - FE MBSY CBCT CH 20 - FE MBSY CBCT
CH 21 - FE MBSY CBCT CH 22 - FE MBSY CBCT
CH 23 - FE MBSY CBCT CH 24 - FE MBSY CBCT


Loops 56 and 57 were not touched during the installation of the new T1s. Now, I am thinking that the IVR has a hardware issue. Is that a solid conclusion to jump to? Do I blow the alarm on that system?

rlc

jack

R,

Start with the basics, what is the IVR looking for from the PBX, this looks like a configuration mismatch.

What state are the d's in?

When you LCNT what are you getting?



Jack

Rachelle

Jack:

LCNT is zero on all levels for all loops associated with the IVR. The Ds are up and solid.

The IVR is a Periphonics VPS/is system that was custome designed to use ISDN/PRI circuits sent from the 81C. The 81C has been the NET of these T1s for years.

Nothing on these circuits/loops, within the PBX, has been changed. We do know that the BUG1369s all started on Friday, March 11. They are so heavy that the HST continues to overflow.

Could this be data corruption in the IVR? Since the same lines are doing the same thing on both sides of the IVR, it would appear that a hardware failure would not be the cause.


rlc

jack

If you disable the two new ones does the trouble/errors stop as well?

Any chance you could swap the new ones with the existing ones -- frog the cables at the IVR side?

Any chance the IVR is looking for an E-1 and not a PRI -- real long shoot but...

Still feels like a configuration error, but I've seen stranger things.

Hmm....