Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CS1000B - DID's don't work in failover

Status
Not open for further replies.

mrclean0613

Technical User
Apr 6, 2010
38
US
Greetings ~

We performed a scheduled failover test this evening. We discovered that our branch office lost In-bound DID capabilities.

Configuration:
CS1000B with PRI to PSTN > Redundant CS1000E with no PSTN > CS1000M with all PSTN trunking.

We dropped the Prime SS on the CS1000E - the Branch phones registered local to the "B". This is when we discovered the In-bound DID's did not work. I turned up DCH monitoring — witnessed the call hitting the DCH and getting rejected.

Shouldn't the In-bound DID's work under these conditions?

Just not too certain why?

Thanks,

mrclean613
 
It should work that way.

My 1st comment would be go back to your installer/maintainer and get them to fix it.
 
Are your switches in seperate zones or one big happy family so to speak? Has your provider added your various DID's routing tables on all PRI's?
Not a fan of the redundant setup personally, too many bugs/issues like this to hammer out. If we didn't have DID CO issues, we had network issues as rls 6 changes the network rules..
 
Make sure in the 1000B, that there is a DN with the same length as your DID's configured in the Customer Data Block for LDN0.

I would be willing to bet that the programmer of the B left this out.
 
The CS1000B is our branch office > with its own PRI to local carrier

The DID's work fine in normal conditions

We loose In-bound DID's when the TLAN of the CS1000E fails
(We had a scheduled failover test last night) that's how we discovered this

So... I would suspect the DID's to continue to work since this is a direct PRI into the CS1000B

When we normalized the systems - the DID's were back working fine.
 
What's your numbering scheme like DID wise? For instance do you have nxx 123 at one location and nxx 456 at another?
In normal mode your DID's sound configured right at the CO routing on your main pri's, but in abnormal now you're relying on DID routing on your branch pri's instead. If the DID ranges don't co-exist on all pri's you'll have this sort of issue
 
In normal operation, the processing of DID calls into the 1000B is handled by the Main Office (1000E).

When the Main Office is not available, the 1000B needs to be able to process the calls, and if it has not been correctly configured (for instance, LDN0 has not been defined), calls will fail.

One of the basic components that controls the routing of DID calls is LDN0. The length of the DN programmed in LDN0 must match the length of the inpulsed digits on your DID route.

The condition you described - seeing the call come in, but fail - is a classic symptom of LDN0 being blank, or the wrong length.

It only takes a minute to check.

In LD 21
Req: Prt
Type: ldn
Cust <enter>

 
Hmmmm

Well I was assuming in normal mode that the DID's to the branch would terminate directly to the CS1000B PRI?

I'll turn up DCH monitoring to se how the DID's are presented to the Branch
 
Do you have any analog or digital line cards in the branch?
 
Ok...

Here's the LDN information on bothe the CS1000B & CS1000E

*****************
CS1000E - LDN

REQ: prt
TYPE: ldn
TYPE LDN_DATA
CUST 0

TYPE LDN_DATA
CUST 00
OPT XLDN
DLDN NO
LDN0 8999
LDN1
LDN2
LDN3
LDN4
LDN5
ICI 00
ICI 01
ICI 02
ICI 03
ICI 04
ICI 05
ICI 06
ICI 07
ICI 08
ICI 09

*****************
CS1000B - LDN

REQ: prt
TYPE: ldn
TYPE LDN_DATA
CUST 0

TYPE LDN_DATA
CUST 00
OPT XLDN
DLDN YES
LDN0 8999
LDA0
LDN1
LDA1
LDN2
LDA2
LDN3
LDA3
LDN4
LDA4
LDN5
LDA5
LDBZ
ICI 00
ICI 01
ICI 02
ICI 03
ICI 04
ICI 05
ICI 06
ICI 07
ICI 08
ICI 09

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top