• No results found

setting up trunks to cisco mc 3810: t1 pri

In document Nortel Option 11 Pbx at Home (Page 68-79)

voice-port 1/2

trunk-group EMTRKGRP operation 4-wire type 5

description EMTRKGRP02

!

voice-port 1/3

trunk-group EMTRKGRP operation 4-wire type 5

description EMTRKGRP03

!

voice-port 1/4

trunk-group EMTRKGRP operation 4-wire type 5

description EMTRKGRP04

! voice-port 1/5

!

voice-port 1/6

description test phone on fxs port

!

!

dial-peer voice 9000 pots destination-pattern 9000 port 1/6

!

dial-peer voice 7000 pots trunkgroup EMTRKGRP destination-pattern 7...

no digit-strip forward-digits 4

!

dial-peer voice 8000 pots trunkgroup EMTRKGRP destination-pattern 8...

no digit-strip forward-digits 4

!

setting up trunks to cisco mc 3810: t1 pri

this configuration works great and i have migrated all my t1 trunks on my meridian to isdn pri. there are definitely some added complexities in configuring t1 pri versus t1 cas and i will discuss them in detail below. assume again that we are

starting with basically a clean slate with no previously defined digital loops, d channels, trunks, routes, clock controllers, and so forth. the scenario appears as follows.

the isdn switch-type will be NI-2. the cisco will act as the network side and the nortel will act as the user side. the

nortel will provide clock for the network link. for simplicity, we are configuring the trunk as a direct inward dial trunk

rather than a tie trunk.

i do want to state explicitly that the t1 card in this case is pinned out exactly the same as in the t1 cas case above so just follow that wiring plan if the card hasnt been wired up yet.

before we proceed i do want to note that the nortel is equipped with a ddch card in this scenario. i also tried various t1 pri configurations between the cisco and the nortel when the nortel was equipped with a dchi card instead of a ddch card and was never able to make it work. once i swapped in the ddch card, it started working pretty quickly. i got lucky and got my ddch card for really cheap but since dchi cards are so much cheaper to get i would be really curious to hear if any other folks out there have been able to get it working with a dchi card. it should in theory be possible to do.

we will start out configuring the meridian, and then move along to the cisco.

step 1: create digital data block. we do it the very same way as we do for the t1 cas configuration. if you already have a DDB 0 created then you can skip this step.

>LD 73 DDB000

UDATA: 31988 1 PDATA: 101492 5 DISK RECS AVAIL: 512

REQ NEW TYPE DDB TRSH 0 RALM BIPC LFAC BIPV SRTK SRNT LFAL SRIM SRMM TRSH

UDATA: 31988 1 PDATA: 101460 5 DISK RECS AVAIL: 512

REQ ****

>

OVL000

>

step 2: define digital loops

>LD 17 CFN000

UDATA: 31908 1 PDATA: 101436 7 DISK RECS AVAIL: 512

DCH AVAIL: 64 USED: 0 TOT: 64 AML AVAIL: 16 USED: 0 TOT: 16 REQ CHG

TYPE CEQU TDS CONF

DLOP 02 23 ESF (note only 23 channels; channel 24 is the d-channel) MODE PRI

LCMT B8S YALM FDL TRSH 0 DLOP MTYP

UDATA: 31652 1 PDATA: 101266 7 DISK RECS AVAIL: 512

DCH AVAIL: 64 USED: 0 TOT: 64 AML AVAIL: 16 USED: 0 TOT: 16 REQ

REQ ****

>

OVL000

>

step 3: define clock controller. we can skip this step if we already have at least one dti/pri card installed with an active clock controller already.

>LD 73 DDB000

UDATA: 31732 1 PDATA: 101266 5 DISK RECS AVAIL: 512

REQ CHG TYPE DDB CLKN 2

PREF (default is nortel acts as clock master for the span) SREF

TRSH 0 RALM BIPC LFAC BIPV SRTK SRNT LFAL SRIM SRMM TRSH

UDATA: 31732 1 PDATA: 101266 5 DISK RECS AVAIL: 512

DTC014 REQ ****

>

OVL000

>

step 4: create an adan record for the d-channel

>LD 17

CFN000 UDATA: 31732 1 PDATA: 101266 5 DISK RECS AVAIL: 512

DCH AVAIL: 64 USED: 0 TOT: 64 AML AVAIL: 16 USED: 0 TOT: 16 REQ CHG

TYPE ADAN

ADAN NEW DCH 10

CTYP MSDL CDNO 2 PORT 1

DES MC3810PRI USR PRI

IFC NI2 CO TYPE DCHL 2 PRI OTBF 32 DRAT 64KC SIDE CNEG RLS RCAP MBGA NO NASA TIMR YES T310 10 LAPD YES T23 T200 3 T203 10 N200 3 N201 260 K 7

UDATA: 30658 1 PDATA: 101125 5 DISK RECS AVAIL: 512

DCH AVAIL: 63 USED: 1 TOT: 64 AML AVAIL: 16 USED: 0 TOT: 16 ADAN DATA SAVED

ADAN REQ ****

>

OVL000

>

step 5: enable dti/pri cards.

>LD 60 DTI000 .ENL * .ENLL 2 PRI000 2 5 PRI000 2 5 DTA023 2 OK

.****

>

step 6: bring up the d channel. first we may have to enable the ddch card and download the pri code to the ddch board (if this has not already happened before). then we can enable the d channel itself.

>LD 96 DCH000 .ENL MSDL 10

DOWNLOADING PRIE REASON: NONE ON CARD OVL021 IDLE

SDL100 BUSY OVL021 BKGD

SDL100 BUSY...

...

SDL000 PRIE ( MSDL 10), VERSION 46, MAINT MODE.

DOWNLOADING NI2 DATA REASON: NONE ON CARD ...

SDL000 NI02 ( MSDL 10), VERSION 6, MAINT MODE.

OK

.ENL DCH 10 .

DCH: 10 EST CONFIRM TIME: 20:00:58 1/04/1993 DCH: 10 EST REMOTE TIME: 20:00:58 1/04/1993 DCH000

.****

>

step 7: enable isdn in the customer record. if it is not, adding the route in the next step will fail. note that we leave HNPA and HNXX blank. this makes the meridian just send a 4-digit outbound CLID for the calling party. if HNPA and HNXX are

specified, you get 10-digit outbound CLID for the calling party that will look like HNPA-HNXX-EXTN. the important thing is

mostly that whatever you choose here lines up with the dial peers that get created later on the cisco.

if an ISDN data block already exists with HNPA and HNXX defined, they can be removed by doing a CHG on the NET_DATA and

specifying "X" for HNPA and HNXX when prompted. unlike other cases on the meridian where to remove a numeric value you specify the numeric value prefixed by "X" when prompted, here

you just specify the X alone.

>LD 15 CDB000

UDATA: 30530 1 PDATA: 100923 1 SCH5066

REQ: CHG TYPE: NET TYPE NET_DATA CUST 0

OPT AC2 ISDN YES SCH4779 PNI PINX_DN MBG BSGC

HNPA ( this would show up as your area code in the sent CLID ) HNXX ( this would show up as your NPA in the sent CLID )

HLOC LSC CNTP RCNT PSTN TNDM PCMC SATD VNR NIT FOPT

UDATA: 30530 1 PDATA: 100923 1 SCH5066

REQ:

step 8: define a LDN0 in the customer record with length

equivalent to the number of digits you expect to come in over the trunk for inbound calls. you can just make up some DN to put here so long as the length is good. apparently you have to have an LDN0 defined for ISDN PRI DID to work.

>LD 15 CDB000

UDATA: 156335 0 PDATA: 229411 0 DISK RECS AVAIL: 512

REQ: CHG

TYPE: LDN_DATA CUST 0

OPT DLDN LDN0 5555 LDN1 ICI

UDATA: 156335 0 PDATA: 229373 2 DISK RECS AVAIL: 512

REQ: ****

>

OVL000

>

step 9: add route data block

>LD 16 RDB000

UDATA: 30658 1 PDATA: 101125 5 DISK RECS AVAIL: 512

REQ NEW TYPE RDB CUST 0 DMOD ROUT 20 TKTP DID M911_ANI SAT NO RCLS EXT DTRK YES DGTP PRI ISDN YES MODE PRA IFC NI2 PNI 00000 NCNA YES NCRD NO CHTY BCH ISAR NO DSEL VOD PTYP PRI AUTO NO DNIS NO DCDR NO IANI ICOG IAO RANX NO SRCH LIN TRMB YES STEP

ACOD 9 (dial 9 to access this trunk)

TCPP NO TARG 0 BILN NO SGRP 0 OABS INST CNTL YES TIMR DRNG NO CDR NO NATL MUS NO EQAR NO OHQ NO OHQT 00 TTBL 0 PLEV 2 MCTS NO ALRM NO

UDATA: 30658 1 PDATA: 100969 6 DISK RECS AVAIL: 512

REQ SCH0101 REQ ****

>

OVL000

>

step 10: add trunk data block. basically repeat this command for unit 1 to 23 on the dti/pri card, incrementing the route member number each time. i will spare you the full text of two lengthy datafills of this nature on this page since you have basically seen it before in the t1 cas section above.

>LD 14 TRK000

UDATA: 30582 1 PDATA: 100961 9 DISK RECS AVAIL: 512

TNS AVAIL: 178 USED: 22 TOT: 200 REQ NEW

TYPE DID TN 2 1 CUST 0 NCOS 0 RTMB 20 1

B-CHANNEL SIGNALING NITE

CLS TKID

NEW TRK TN 002 01 RT 20 MB 1 UDATA: 30490 1 PDATA: 100923 10

DISK RECS AVAIL: 512

TNS AVAIL: 177 USED: 23 TOT: 200 REQ

SCH0101 REQ ****

>

that should do it as far as the meridian side of things goes.

here is the corresponding cisco configuration.

!

isdn switch-type primary-qsig isdn gateway-max-interworking

!

!

!

voice service voip sip

session transport tcp

!

!

no voice confirmation-tone

!

!

controller T1 0 framing esf linecode b8zs

clock source internal

ds0-group timeslots 1-24 fxs-loop-start description t1 to channel bank

!

controller T1 1 framing esf linecode b8zs

pri-group timeslots 1-24 description t1 to meridian

!

! the following is the configuration for the d-channel

!

! set the guard timer to be as long as possible and make

! sure the T310 counter (in seconds) matches the value set

! on the meridian in the ADAN record for the DCH. note that

! the cisco and meridian use different units of time for

! specifying the T310 value.

!

interface Serial1:23 no ip address

no logging event link-status logging event nfas-status

logging event subif-link-status isdn switch-type primary-ni isdn protocol-emulate network isdn incoming-voice voice isdn guard-timer 20000 isdn T310 10000

isdn send-alerting no cdp enable

!

!

voice-port 0:1

!

! meridian defaults to bearer capacity speech so we use that.

!

voice-port 1:23 bearer-cap Speech

!

!

! a note on the dial peers below. they serve two purposes. the first

! of course is to route incoming calls to the meridian. simple enough.

! but the second is more nuanced. basically, per cisco documentation

! on one stage and two stage dialing over isdn pri, these destination

! patterns are also used to tag incoming calls from meridian 7XXX and

! 8XXX extensions such that the cisco will treat them as DIDs.

!

! the cisco basically looks at the incoming CLID and wants to see it

! matching a pots dial-peer with the direct-inward-dial keyword. since

! we did not define a HNPA and HNXX in LD 15 NET_DATA when configuring

! the nortel, both devices are using 4-digit CLIDs throughout and the

! dial peers given below work as intended (one stage dialing).

!

! now, if we had configured a HNPA and HNXX on the nortel, it would be

! sending a 10-digit calling party CLID of NPA-NXX-EXTN. the four

! digit dial peers on the cisco will nominally work for inbound calls

! to the nortel because of our digit stripping rules, but they do not

! result in proper DID treatment for calls outbound from the meridian

! to the cisco.

!

! the resulting improper treatment is that it will work, but there is

! a quirk for the user. they basically dial the access code plus their

! number on the nortel, and they will land on a second dial tone from

! the cisco. it just throws away any digits they dialed subsequent to

! the trunk access code. at this point they will have to dial their

! number again at this dial tone to actually have their call go through

! (two stage dialing).

!

! in that case, we would have had to define 10-digit destination patterns

! in our dial peers e.g. destination-pattern NPANXX7... or NPANXX8... such

! that the proper treatment for calls outbound from the meridian to the

! cisco would occur.

!

! you can use the debug isdn q931 command on the cisco or ENL MSGI and ENL

! MSGO in LD 96 on the nortel to see what both sides think the calling and

! called party numbers are.

!

dial-peer voice 7000 pots destination-pattern 7...

supplementary-service pass-through direct-inward-dial

port 1:23

forward-digits 4

!

dial-peer voice 8000 pots destination-pattern 8...

supplementary-service pass-through direct-inward-dial

port 1:23

forward-digits 4

!

dial-peer voice 9000 pots destination-pattern 9000 port 0:1

!

sip-ua

retry invite 3 retry response 3 retry bye 3 retry cancel 3 timers trying 1000 timers notify 1000 timers info 1000

!

!

gatekeeper shutdown

!

home

In document Nortel Option 11 Pbx at Home (Page 68-79)

Related documents