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!

2 Norstar & Meridian over MCDN

Status
Not open for further replies.

prolog1

Technical User
Dec 30, 2011
20
UA
Hello all,

I have followed configuration:
Two MISC (A & B) connected via PRI MCDN (both rel. 7.0 profile 2 & MCDN keycodes).
MICS B also have PRI MCDN connection to Meridian 1 (opt 11C rel. 5.5).
MICS A<->MISC B<->Meridian

MICS A and MICS B normally called each other via private network.
MICS B normally call to public network via Meridian and it internal extensions.
But MICS A can't make outgoing call to public network via MICS B & Meridian. It also can't dial Meridian internal number.
Incoming calls from Meridian normally reached both MICS.
Below DCH monitoring from Meridian.
Successful call from MICS B to Meridian:
DCH 28 IMSG SETUP REF 00008006 CH 8 1 TOD 17:01:20
CALLING #:442027777 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:4671567 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
DCH 28 OMSG CALLPROC REF 00008006 CH 8 1 TOD 17:01:20
DCH 28 OMSG PROGRESS REF 00008006 CH 8 1 TOD 17:01:20
PROGRESS: CALL IS NOT END TO END ISDN
DCH 28 OMSG PROGRESS REF 00008006 CH 8 1 TOD 17:01:20
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
DCH 28 OMSG ALERT REF 00008006 CH 8 1 TOD 17:01:20
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
DCH 28 OMSG CONNECT REF 00008006 CH 8 1 TOD 17:01:20
DCH 28 IMSG CONN ACK REF 00008006 CH 8 1 TOD 17:01:22
DCH 28 IMSG DISC REF 00008006 CH 8 1 TOD 17:01:26
CAUSE :NORMAL CALL CLEARING
DCH 28 OMSG RELEASE REF 00008006 CH 8 1 TOD 17:01:26
DCH 28 IMSG REL COMP REF 00008006 CH 8 1 TOD 17:01:26
_______________________
Unsuccessful call from MICS A to Meridian:
DCH 28 IMSG SETUP REF 00008004 CH 8 1 TOD 17:18:12
FEAT :NAS
CALLING #:112 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:4671567 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
DCH 28 OMSG FACILITY REF 00008004 CH 8 1 TOD 17:18:12
FEAT :NAS
DCH 28 OMSG CALLPROC REF 00008004 CH 8 1 TOD 17:18:12
DCH 28 IMSG DISC REF 00008004 CH 8 1 TOD 17:18:12
CAUSE :NORMAL CALL CLEARING
DCH 28 OMSG RELEASE REF 00008004 CH 8 1 TOD 17:18:12
DCH 28 IMSG REL COMP REF 00008004 CH 8 1 TOD 17:18:12
___________________________________
I see that MICS drop call. NAS feature is present in call setup. But I don't use network attendant.

Meridian setup:
ADAN DCH 28
CTYP DCHI
CARD 08
PORT 1
DES
USR PRI
DCHL 8
OTBF 32
DRAT 64KC
CLOK EXT
NASA NO
IFC SL1
SIDE NET
SEMT 1
CNEG 1
RLS ID 25
RCAP ND2 NCT MSDL MWI
MBGA NO
OVLR NO
OVLS NO
T23 20
T200 3
T203 10
N200 3
N201 260
K 7

TYPE RDB
CUST 00
DMOD
ROUT 8
DES ZEMLA
TKTP TIE
NPID_TBL_NUM 0
ESN NO
RPA NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC SL1
PNI 00003
NCNA YES
NCRD YES
TRO YES
CTYP CDP
INAC NO
ISAR NO
DAPC NO
MBXR NO
DSEL VOD
PTYP DTT
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 99908
TCPP NO
TARG
CLEN 1
BILN NO
OABS
INST
IDC NO
DCNO 0 *
NDNO 0
DEXT NO
SIGO STD
MFC NO
ICIS YES
OGIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GTO 896
GTI 896
SFB 3
NBS 2048
NBL 4096
IENB 5
TFD 0
RTD 12
VSS 0
VGD 6
DTD NO
SCDT NO
2 DT NO
DRNG NO
CDR NO
NATL YES
SSL
CFWR NO
IDOP NO
VRAT NO
MUS YES
MRT 40
PANS YES
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
TTBL 0
ATAN NO
PLEV 2
OPR NO
ALRM NO
ART 0
PECL NO
DCTI 0
TIDY 99908 8
SGRP 0
ARDN NO
ANIE 0
CAC_CIS 3
AACR NO

TYPE NET_DATA
CUST 00
OPT RTA
AC1 INTL NPA SPN NXX LOC
AC2
FNP YES
ISDN YES
VPNI 1
PNI 1
PINX_DN
MBG 0
BSGC 65535
PFX1
PFX2
HLOC
LSC
RCNT 5
PSTN NO
TNDM 15
PCMC 15
SATD 1
OCLI ALL
TIDM NO
DASC
ROPT NRO
DITI YES
TRNX YES
EXTT YES
FTOP FTLY
APAD 0 0
VNR YES
RLI 3
CDPL 4
UDPL 10
NIT 8
NAS_ATCL YES
NAS_ACTV NO
FOPT 6
CNDN
CNAT
CNIP YES
DMWM NO
MWNS NO
CNTC 380
NATC 0
INTC 00
_________________________________
MICS A setup:

Hardware Card 1 PRI
Protocol SL-1
Net ID 3
BchanSeq Descend
ClockSrc Primary

Dialing Plan Private CDP
PrivNetID 4

Routing Service Route 002
DialOut No numbr
Use Pool PRI-A
DN type Public
DestCode 9
Normal rte 002
Absorb 0

Access Codes PrivAccCode 9
__________________________
MICS B setup:
Hardware Card 1 PRI - to MISC A
Protocol SL-1
Net ID 4
BchanSeq Ascend
ClockSrc TimeMaster
Card 2 PRI - to Meridian
Protocol SL-1
Net ID 1
BchanSeq Ascend
ClockSrc Primary

Dialing Plan Private CDP
PrivNetID 3

Routing Service Route 002
DialOut No numbr
Use Pool PRI-B
DN type Public
DestCode 9
Normal rte 002
Absorb All (I remove 9 and send to Meridian public number)

Access Codes PrivAccCode 9

Remote restriction allow calls between PRI-A and PRI-B
_______________________________

Anyone here have any suggestions?

Thanks
 
Your problem is related to the Public DN length or the fact you are not removing the 9 on site A.

Site A
CALLING #:112 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:4671567 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)

Site B
CALLING #:442027777 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:4671567 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)

What is the extension range at each site?

Why are you not absorbing the 9 at site A?

I would expect you unless you are breaking out at each site to setup the following

Create two routes both going to the Meridian link in this case.

destination code 7
Absorb all
Route 002

Destination code 9
Absorb 0
Route 002

I would then tell each Norstar site to contact the Meridian the number is 7 and the extension number.

To break out you would dial 9 and the external number.

You will need to edit you public DN dial plan to reflect the additional digit. I am not sure where you are but default length in the uk would be 8 digits. Anything begining with 0 would be 11 you would need to add an entry of 90 and set the digit length as 12. Then remove the 0 if it conflicts with anything on your dial plan.

If you have local dial 9 access then you would have to either elaborate your dial plan or set 7 and the leading digit for each extension range.


Thanks,
Colin




 
Extension range at site A is 1XX, 2XX, 3XX.
Extension range at site B is 4XX.
Extension range at Meridian is 7XXX.
PSTN access at site A & B is 9, default length is 8, 90 - length 11.
Meridian have access to PSTN via CDP (0,1,2,3,4,5 - is TSC to PSTN with right dn length).

Site A don't have direct connection to Meridian.
I don't absorbing the 9 at site A, because I make transit call via site B. I absorb this 9 on site B and send to Meridian.

Site B make call at any direction with any problem.
When call comes to Meridian from site A all digits is correct and have right length, but FEAT :NAS is present at the call setup message. This feature is added in tandem calls.

Network services -> MCDN -> NetwkICCL: NO
TRO: YES
TAT: YES

I try to set any other settings but without success.

Thanks


 
Have you permitted the tandem calls on the site b by assigning the appropriate remote package. I am guessing so otherwise it would never make it to the Meridian. Can you make a call from site A to site B.

where is site b getting the following from

Site B
CALLING #:442027777 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)

442 is the extension number I am guessing but unless you have a different public CLIP being sent.

Can you ring from the Meridian to Site A

Thanks,
Colin

 
In my first post I wrote:
MICS A and MICS B normally called each other via private network.
Incoming calls from Meridian normally reached both MICS.

Remote packages allow calls between PRI-A and PRI-B on site B.

I put тrace received already from Meridian.
Calls are reached to Meridian.
But in case with tandem call Meridian received FEAT :NAS message and call is dropped.

CLID (OLI) can be anything.
 
What is your access code on the Meridian to break out. If you are using the Meridian to dial out what is your AC1 code?

Wjat do you dial on site A to transit across the network to site b and then out on the Meridian. You said it was set up as Private and this will disregard any digits dialed after the private length.

If I am on site A what exactly are you dialing to get to the Meridian and ring an extension on the Meridian. Can you also supply destination code and routes.

Thanks,
Colin

 
I don't use UDP on Meridian (no AC1 or AC2). I use CDP on Meridian(0,1,2,3,4,5 - is TSC to PSTN).
For PSTN access on site A I dial DestCode 9 (DN type Public) then PSTN number.
Then call come to site B. It also have DestCode 9 (DN type Public) to Meridian. I absorb this 9 on site B and send number to Meridian.
Meridian was received correct 7 digit number (for sample 4671567).
If I dial 94671567 from site B, call setup is correct and call reached to PSTN.
In case with tandem call from site A, Meridian was received correct 7 digit number, but call setup is wrong and MISC (site A or B, I don't know) dropped call.

For PSTN access I use Public DN type. Private DN type I use only for call between site A and site B.


 
This problem is not routing calls. In my opinion the problem in MCDN networking.
What correct RLS ID I need to setup on Meridian DCH?
Whar correct RCAP I need to setup in case with MISC connection?
I remove all RCAPs on Meridian DCH except ND2, but without success.
 
Solved !!!
I installed plugin 27 (DID to DID call (or DPNSS to DID) intercepts to the attn.)on Meridian.
Now tandem calls normally reached PSTN.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top