Troubleshooting Routing Issue of an RLI 2

[rachelle]

Route 104 has 8 T1s assigned as members.
RLI 104 has entry 0 to this RT 104 members.
RLI 104 has entry 1 LTRE yes and sends calls to a menu service.

Callers to this route are hitting the menu service even though the members of RT 104 are available. What would cause this? How would I troubleshoot?


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[bigindian65]

post the RLI and RDB, are the frls same? is this inbnd only?

Mato' Was'aka

 

[rachelle]

As far as the reports are saying, it seems to be only calls coming from the outside world in to the PBX that fronts the CallManager.

Lots of members. I can't believe that I have an all trunks busy situation. None of the TM3.2 Traffic Reports show us ever having all trunks busy.


RLI
RLI 104
ENTR 0
LTER NO
ROUT 104
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
VNS NO
CNV NO
EXP NO
FRL 0
DMI 0
FCI 0
FSNI 0
SBOC NRR
IDBB DBA
IOHQ NO
OHQ NO
CBQ NO

ENTR 1
LTER YES
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
VNS NO
FRL 0
DMI 99
FCI 0
FSNI 0
SBOC NRR
IDBB DBA
IOHQ NO

ISET 0
NALT 5
MFRL 0
OVLL 0


RDB
TYPE RDB
CUST 00
ROUT 104
DES VOIP
TKTP TIE
NPID_TBL_NUM 0
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI
ISDN YES
MODE PRA
IFC D100
SBN NO
PNI 00000
NCNA YES
NCRD NO
CHTY BCH
CTYP UKWN
INAC NO
ISAR NO
CPUB OFF
DAPC NO
BCOT 0
DSEL VCE
PTYP PRI
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH LIN
TRMB YES
STEP
ACOD 120490
TCPP NO
PII NO
TARG 01
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 0
NDNO 0 *
DEXT NO
DNAM NO
ANTK
SIGO STD
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GRD 896
SFB 3


PAGE 002

NBS 2048
NBL 4096

IENB 5
TFD 0
VSS 0
VGD 6
DRNG NO
CDR NO
VRAT NO
MUS NO
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
CBQ NO
AUTH NO
TDET NO
TTBL 0
ATAN NO
PLEV 2
ALRM NO
ART 0
SGRP 0
ARDN NO
AACR YES
ASID 17
SFNB
USFB
CALB 7 8


no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[bigindian65]

chg your iset to 2 on the RLI since you have two entries, not that that is the fix, but it speeds up routing resources when correctly set.

Mato' Was'aka

 

[rachelle]

Done

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[rachelle]

I want you to tell me that the Cisco CallManager, on the other end of this route, is the source of the problem. I want you to tell me that somehow their channels don't match my channeles and that the collision is causing my PBX to think that there is an all trunks busy situation and therefore flowing the callers to the menu service referenced in entry 1 of the RLI. If you tell me these things, then the problem is not mine to fix. It will be mine to prove but, not mine to fix. If this is a problem for me to fix, please, give me the nudge that I need.


rlc
(related post is BUG253 and PRI222 Troubleshooting)

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[bigindian65]

here is what you will have to do, disable 7 Ts, test call, disable that one, enable another, test call, until you have done all 8 of them. If you get thru on all 8, prolly not your problem.

Mato' Was'aka

 

[rachelle]

I just removed the Entry 1 from my RLI. Now, callers should hear a fast busy. Maybe now, the CallManager side of the house will see something. If the caller gets anything other than a fast busy, the CM is driving the call. I am really at my end.

right now, entry 1 is removed.
DCH 16 is still disabled
Loops 104, 116, adn 57 are disabled.

Now, I wait for feedback.



rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[GHTROUT]

Here's an RLI trick for those interested:

Make the ENTR values 5, 10, 15, 20

Or 2, 4, 6, 8

Or whatever allows you to move entries back and forth between each other.

[©] GHTROUT.com [⇔] A Variety of Free Resources for Nortel Meridian/CS1000 System Administrators

 

[trvlr1]

These are PRI's so you should be able to use D channel messaging to see if your calls are hitting the channels and you should see the response. If you do decide to test these circuits one at a time, remember you will need at least one active D channel to make it operate, so you might have to disable the channels on that one rather than the whole circuit.
This route is set with external timing too, so you need to make sure the Cisco is set to Primary or internal or whatever their equivelent is.

 

[allenmac]

From re-reading your initial post, I have a few questions:

1. What is the purpose of Route 104? Is this the tie route to the Call Manager?

2. What type of trunk service is this programmed as? DID, TIE, etc.

3. Has this ever worked?

 

[rachelle]

Calls come in to our Nortel PBX
If call is intended for the cisco VoIP CallManager, it is programmed as a DSC.
DSC point to RLI 104, Route 104
Route Data Block route 104 has 8 T1s and their members configured. The copy of the RDB is above, in earlier post. It is a TIE between the PBX and the CallManager. Yes, it has worked but, as heavier traffic has built suddenly people are reporting that calls are not reaching them.

Caller dials one of the DSCs and it behaves as though all trunks/members are busy and the call is pushed to Entry 1 of the RLI and call is sent to a menu service that isn't helpful to this type of caller, at all.

I hope that this covers your questions. PLease let me know if additional information is needed. Thanks!!!


no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[allenmac]

So the inbound calls meant for the call manager are being blocked.

There are 2 probable places that I would check. Look at your inbound trunks and make sure they are all programmed with similar restriction levels. (Check the TGAR and NCOS on the trunk members, and the TARG on the trunk route). Also look at the CLS of the trunk members.

Check the same things on all of the PRI B-Channels in Route 104. If the calls work sometimes, but not when call volume is heavy, then you could have some B-channels programmed differently than others - This goes for your inbound route as well.

 

[rachelle]

This is only hit and miss and it isn't specific to a single number, it is any of these VoIP sets.

I printed all of the trunk members and they all are built like:

TYPE TIE
CDEN SD
CUST 0
TRK PRI
PDCA 1
PCML MU
NCOS 3
RTMB 104 93
B-CHANNEL SIGNALING
TGAR 1
AST NO
IAPG 0
CLS CTD DTN WTA LPR APN THFD HKD
P10 VNL
TKID
FCAR NO
AACR NO





no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[rachelle]

If I have more channels in my route, to the CallManager, than the CallManager can receive, would I get the overflow to my entry 1 then?

EXAMPLE:
Say I have 10 trunk members but, the CM only has 5. Would the 6th caller overflow to my RLI entry 1 treatment?

If so, then I think I have an answer to the oddity.



rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[allenmac]

Yes. The number of trunks between the systems should match on both sides.

But I'm confused. If you have 8 PRI's built in the CS1000, you should have a 8 terminating on the call manager. Otherwise you would have the spans that do not terminate on the call manager out of service on the Nortel side.

I'm assuming these are not virtual trunks, as the information you have provided shows them as being built on real PRI hardware one the Nortel end.

 

[bhassell2000]

I agree, if you have 8 in the Nortel that show channels idle or tuyrned up the CM should have the same ammount

 

[rachelle]

They were showing 15 channels as Out of Service but, the Nortel side was not showing any disabled or MBSY, nothing.

Today, all cisco channels show working. I have returned all programing back to where it was (i.e. I put the second entry back in the RLI). I don't see any flaw on the Nortel side. I see nothing that would cause a call to roll to the second entry of the RLI, since it is definately not ATB, unless the CM was rejecting a call. I don't see any other way.

The cisco folks say that they don't even see a call in the CM so, it must be being rejected at the T1. That is why I was looking at the number of members on the Nortel vs. the number of members on the CM.



rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.

 

[allenmac]

Welcome to the wonderful world of cisco telephony!

Blame every problem on the other guy.

 

[rachelle]

I just can't find where the Nortel is blocking it. I just confirmed that the FRL in the RLI is set to zero.
My range in LD 87 is NCOS 0=0, 1=1, 2=2, 3=3, 4=0, and 5=2.

So, outside callers dialing a DSC in the PBX should pass straight over using the FRL/NCOS of the trunk member. Yes? All trunk members are NCOS 3.

I just don't see how the Nortel is thinking that these callers sometimes qualify for Entry 1 and sometimes doesn't. My gut says that due to call volumn the cisco is doing something hinky but, I can't prove (or disprove) that theory.


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.