This was performed after the notes in 'config-clear-procedure'.
The first and most obvious thing to get working is the ability to set up a simple POTS line. That sounds like an easy task, but remember, we removed almost all the hardware necessary to do that back in the config clearing. We don't even have ENET. Aside from that, there's a lot of other translations necessary to even set up a LINEATTR, which is of course required for assigning lines also.
We're going to go about this very mechanically. We'll go into SERVORD and try to set up a 1FR, for now. We'll worry about IBN and RES later (and any other LCCs).
Entering SERVORD, we use the 'NEW' command. We give it the default 'NOW' for the SONUMBER, and next we're asked for a DN. We're already unable to proceed here, as we have no DNs assigned to our switch.
DNs which are assigned to our switch are set up in TOFCNAME. In order to make entries into TOFCNAME, you also need an SNPA/STS configured.
An STS/SNPA is configured in SNPANAME and HNPACONT, but since we aren't completely starting from scratch, we already have one. When I was removing the SNPANAME entry, the DMS told me I better put on in there to replace it or an empty table could cause issues. My SNPA is set as '222' which isn't a real area code in NANP, and we've been using to denote the Shadytel Coordinated DialPlan, or SCDP.
(it's probably worth mentioning here I haven't exactly figured out the difference between an SNPA and an STS yet, but it seems these are two dependent concepts in some manner.)
In TOFCNAME, a new tuple is added referring to my SCDP prefix (222-563) with no special options.
AREACODE OFCCODE OPTIONS
-----------------------------------------------------------------------
222 563 $
Back in SERVORD, creating a NEW line, we get a bit farther now that we're able to select a DN. Interestingly, we don't immediately hit a snag on the LCC (1FR), but I know that'll give us trouble later when we try to submit it. The next field to stop us is LEN_OR_LTID. Of course, we have no LENs because we don't have any line cards, which go in line drawers, which go in LCMs, which attach to an LTC, which attach to ENET or another BEARNET. So, you see, we've got some dependencies to walk.
We start by adding our ENET back in ENINV. Note that for this part, I still have the interface cards for the ENET defined and configured in the message switch, so I won't need to do any of that. Those are cards 6 and 8, in my case.
Adding the tuple in ENET, we of course start with shelf 0 (the only shelves I have in my case). My ENET is a single cabinet configuration, up to 64k (if I got rid of the LIS shelf which makes it an MCNI) thus it is a PRI64K class. Since my ENC was converted to an MCNI, I'll use that for the frame type. The MCNI is an NTYA05AA. My shelves are labeled NT9X0818 (despite some discrepancy with the old table contents). The message switch card is 6 (physical slot 12), link 0, port 0, and card 8 (physical slot 14), link 0, port 0. The load name on my switch is ENC22BN.
ENKEY ENCLASS FRTYPE FRNO FRPEC SHPEC MSCARD0 MSLINK0 MSPORT0 FLOOR0
ROW0 FRPOS0 SHELF0 LOAD0 MSCARD1 MSLINK1 MSPORT1
FLOOR1 ROW1 FRPOS1 SHELF1 LOAD1
---------------------------------------------------------------------------
0 PRI64K MCNI 0 NTYA05AA NT9X0818 6 0 0 1
A 2 39 ENC22BN 8 0 0
1 A 2 13 ENC22BN
Notice how ENCDINV fills some data automatically when the ENET is created. All of the common pack fill is created, but not any crosspoint cards which will have to be added later.
At this point, I turned on ENET plane 0, shelf 0. The newly-created ENET needed to be brought from offline to mbsy using the 'bsy' command in mapci;mtc;net;system. Then the software needed to be loaded with the 'loaden' command, and lastly returned to service with the 'rts' command.
It's not clear if it's strictly necessary in a switch with only one bearer network, but we'll fill in BEARNETS at this point. Modeling after the original tuples in the switch, we end up with the following:
NETIDX BNETNAME DISPLAY FABRIC
OPTIONS
------------------------------------------------------
NET 0 TDM_ENET ENET ENET
$
Now we'll add in out crosspoint cards and their interfaces in ENCDINV. For my switch, I can't fathom a reason I'd ever need more than one crosspoint card, which supports 2048 channels. One card can be equipped with a paddleboard for 3xDS-512 and 16xDS30 (there are other options, this is just the useful one to me for my switch). However, an additional crosspoint card is also needed (the one that occupies slot 9) for the interface to the message switches. Technically this isn't a supported configuration though, as there's a minimum crosspoint buildout of 4 cards due to the arrangement of busses and termination in the ENET planes. While these cards must be provisioned, I have not yet tested if they need to be physically present and powered for operation. The correct fill order for cards is discussed in the section for ENCDINV in the data schema reference manuals.
In ENCDINV, we add a tuple for card 9 in shelf 0 of plane 0. The card type is a crosspoint. The card type in my switch was an NT9X35CA, issue 15. This card is for the message switch interface, so it gets no paddleboard (NIL_PB/NIL_PEC). You'll notice that an identical entry for plane 1 is created at the same time.
The second card will be the first that bears any actual interfaces. There's a sequence to adding cards, so slot 10 is next. This is also an NT9X35CA issue 15 crosspoint card on my switch. Since it's the best fit for my switch, I'll be using a DS_30_DS_512_INTERFACE, a NT9X45BA which happens to be issue 04.
The 3rd and 4th cards go much the same way in slots 31 and 32, and I configured them without paddleboards since I don't see myself needing the interfaces for anything.
ENCDKEY CPTYPE CPPEC CPDCD PBTYPE PBPEC
PBDCD
------------------------------------------------------------------------
0 0 9 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0
0 0 10 CROSSPOINT NT9X35CA 15 DS_30_DS_512_INTERFACE NT9X45BA
4
0 0 31 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0
0 0 32 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0
At this point, we can physically add those cards to the shelf and see if we can bring them up in the MAP. For that, we go into mapci;mtc;net;shelf x;card y, then bsy the cards followed by returning them to service.
The next step will be to provision some form of LTC (LGC, LTC, etc. set up to serve LCMs). That is accomplished in table LTCINV.
That also requires some planning on the hardware end. For the sake of least-power-consumption, my plan was to build the most capable LTC that I could from the parts I had, to avoid running multiple. To do this, I combined the contents of a DTCI and an LGC, using mostly the cards from the DTCI.
cards I had for use in the LTC I built:
NT2X70AE - +-5/12V PWR CONVERTER 50A - 25 - LGC
NT2X70AF - +-5/12V PWR CONVERTER 50A - 25 - DTCI *
NT6X40FA - DS512 XPM INTERFACE CP - 22 - DTCI/LGC *
NT6X40GA - DS512 LINK PADDLEBOARD - 22R - DTCI/LGC *
NT6X41AA - SPEECH BUS FORMATTER CP - 21 - DTCI/LGC *
NT6X42AA - CHANNEL SUPERVISION MGS CP - 20 - DTCI/LGC *
NT6X44AA - TIME SWITCH CP - 14 - LGC *
NT6X48AA - DS30A LCM INTERFACE CP - 6-7 - LGC *
NT6X50AB - DS-1 E.F.F. CARD CP - 1-5 - DTCI *
NT6X69AC - MSG PROTOCOL & TONE GEN CP - 18 - LGC
NT6X69AD - MSG PROTOCOL & TONE CCT CP - 18 - DTCI *
NT6X78AB - CLASS MODEM RESOURCE CP - 13 - LGC *
NT6X92BB - DOMESTIC UNIV TONE REC CP - 15 - LGC
NT6X92BC - DOMESTIC UNIV TONE REC CP - 15 - DTCI *
NTAX78AA - TIME SWITCH - 14 - DTCI
NTBX01BA - ENHANCED ISDN SIG. CP - 16 - DTCI *
NTMX77AA - PROCESSOR PCP - 12 - LGC
NTSX05AA - 64 MEG PROCESSOR CP - 12 - DTCI *
Using the marked cards, I should be able to build a pretty good LTC that does:
lines via
-DS30A interfacing to LCMs via NT6X48
-tone generation via NT6X69 (e.g. dialtone, progress tones)
-caller ID, other CLASS services (ADSI) via NT6X78
-tone reception e.g. DTMF via NT6X92
DS1/PRA trunks via
-DS1 interfacing to network via NT6X50
-tone generation via NT6X69
-tone reception e.g. DTMF, MF via NT6X92
-ISDN D-channel signaling via NTBX01
common XPM functions via
-power via NT2X70
-DS512 interface via NT6X40
-speech bus serialization/deserialization via NT6X41
-channel supervision message reception and generation via NT6X42
-messaging protocol (CM messaging) via NT6X69
-timeslot switching via NT6X44AA (NTAX78AA not supported on LTC, only NTAX78BA)
-processing functions via NTSX05
There are a number of fields in the LTCINV tuples that describe the hardware present in the LTC as well other run-time parameters that set the capabilities. Following the data schema manual closely, I ended up with the following:
LTCNAME
ADNUM FRTYPE FRNO SHPOS FLOOR ROW FRPOS EQPEC LOAD
EXECTAB
CSLNKTAB
OPTCARD
TONESET PROCPEC
EXTLINKS
E2LOAD
OPTATTR
PEC6X40 EXTINFO
----------------------------------------------------------------------------
LTC 0
1 LTEI 0 18 1 B 3 6X02NA QLI22AO
( POTS POTSEX)$
(0 10 16 0) (0 10 16 1) (0 10 16 2) (0 10 16 3) (0 10 16 4) (0 10 16 5)
(0 10 16 6) (0 10 16 7) (0 10 16 8) (0 10 16 9) (0 10 16 10) (0 10 16 11)
(0 10 16 12) (0 10 16 13) (0 10 16 14) (0 10 16 15) $
(UTR15 ) (MSG6X69 ) (CMR13 CMRU23A) (ISP 16) $
NORTHAA SX05AA $ SX05AA $
0
SXFWAL01
$
6X40FA N
Note that on ENET, the DS-30s are numbered 0 to 15, and the DS-512s are 16 to 18. Thus, in my example, link 16 is the first DS-512 (then each DS-30 within the DS-512 needs to be accounted for). Notes on EXECTAB can be found in the peripheral software release document. Also refer there for the load names.
Once the LTC is created, the ENET link needs to be BSYed and then RTSed in mapci;mtc;net;shelf u;card v using the 'bsy x link y' and 'rts x link y' commands where 'u' is the ENET shelf, 'v' is the ENET card, 'x' is the ENET plane, and 'y' is the link number. Following that, the LTC needs to be BSYed, LoadPMed, and then RTSed in mapci;mtc;pm;post LTC 0 by using the 'bsy PM' command followed by the 'loadpm' command and finally the 'rts' command. Note that a loadpm operation can take the better part of an hour, depending on the CPU card and the size of the software load. (on an SX05 loading QLI22AO, it took about 45 minutes).
When we created the LTC, an entry was also automatically created in LTCPSINV. However, we need to edit that entry to match the way we intend to use the LTC. Each P-side link needs to be defined whether it is to be used for DS30A (for connecting an LCM, for example) or a T1 or PRA. The link numbers for the DS30As and the DS1 interfaces can be referenced in the DMS-100 family quick reference guide (TAM-1001-018) and also in the DMS-100 wiring installation method (IM 03-9059). Note that the DMS will force you to allocated the first two LCM links, which support message links, on different NT6X48 slots for redundancy.
LTCNAME
PSLNKTAB
----------------------------------------------------------------------------
LTC 0
N (0 NILTYPE ) (1 NILTYPE ) (2 NILTYPE ) (3 NILTYPE ) (4 NILTYPE )
(5 NILTYPE ) (6 NILTYPE ) (7 NILTYPE ) (8 NILTYPE ) (9 NILTYPE )
(10 NILTYPE ) (11 NILTYPE ) (12 NILTYPE ) (13 NILTYPE )
(14 NILTYPE ) (15 NILTYPE ) (16 NILTYPE ) (17 DS30A )
(18 NILTYPE ) (19 DS30A ) $
With the P-side links configured, we can now add an LCM in LCMINV.
LCMNM FRTYPE SHPOS FLOOR ROW FRPOS EQPEC LOAD CSPMNO
BICTST ADNUM MEMSIZE
LCMTYPE
----------------------------------------------------------------------------
HOST 00 1 LCE 38 1 B 2 6X04AA XLCM18AW LTC 0
N 2 256K 256K
LCM Y C HLCM (17) (19)$
Then we can bsy, loadpm, and rts in mapci;mtc;pm;post lcm 0 1. Thankfully, loading an LCM doesn't take nearly as long as an LTC.
We then need to add a line drawer to the LCM in LCMDRINV. Creating the LCM automatically creates the tuple in LCMDRINV, so we just need to change it.
LCMNM
DRWRTAB
----------------------------------------------------------------------------
HOST 00 1
(0 NT6X54AA NT6X05AA ) (1 NILDRWR ) (2 NILDRWR ) (3 NILDRWR ) (4 NILDRWR )
(5 NILDRWR ) (6 NILDRWR ) (7 NILDRWR ) (8 NILDRWR ) (9 NILDRWR ) $
You may need to bsy and rts the new linedrawer in mapci;mtc;pm;post lcm 0 1 using the bsy drwr x and rts drwr x commands.
Then we can finally provision some line cards in LNINV. Note that you must provision an NT6X17 in position 0 of the 0th LSG of an LCM. This card is reserved for some special test purposes that I can't find a lot of detail on, and can't be assigned for actual service. For that reason, I provisioned three right off the bat so that I can use the second two to provision lines.
LEN CARDCODE PADGRP STATUS GND BNV MNO CARDINFO
-----------------------------------------------------------------------
HOST 00 1 00 00 6X17AC STDLN HASU N NL N NIL
HOST 00 1 00 01 6X17AC STDLN HASU N NL N NIL
HOST 00 1 00 02 6X17AC STDLN HASU N NL N NIL
Back in servord, we try a new line again. Trying a 1FR again, DN 5631000, LEN 0 1 0 1, option 'dgt' to support DTMF. This time we get an error message about not finding a line attribute index, and that's because we don't have any matching ones defined in LINEATTR.
We're going to have to walk some dependencies here again.
We need to create a new tuple in XLAPLAN. We're going to stay as basic as possible, no screening, and no pretranslator. You would almost never actually use an XLAPLAN like this, it has some issues I'll note later. The end result, though, is that translations will be used directly out of HNPACONT.
XLAPIDX SCRNCL HSTS PRTNM ZEROMPOS RESINF
OPTIONS ADMININF
-------------------------------------------------------------------
222_POTS_0 NSCR 222 NPRT NONE N
$ 1FR_POTS
We'll also need a RATEAREA. The most straightforward one is to just ignore the existence of rates for now, AKA no local calling area, and no LATA, and no message rate anything.
RTAIDX LCANAME MRSA LATANM ADMININF
----------------------------------------------------------------------
NLCA_NILLA_0 NLCA NIL NILLATA $
Finally, we can start a LINEATTR. I point to the XLAPLAN and the RATEAREA that was defined, and make a new 1FR class. Some of the other fields are for things like international translations that don't apply on a north american switch, and various options we don't need.
LNATTIDX LCC CHGCLSS COST LTG TRAFSNO SFC MDI
IXNAME DGCLNAME FANIDIGS DFLTXLP DFLTRA
OPTIONS
----------------------------------------------------------------------------
0 1FR NONE NT 0 0 NILSFC 0
NIL NIL 00 222_POT
S_0 NLCA_N
ILLA_0
$
Then we create two lines in SERVORD, 563-1000 and 563-1001, on HOST 00 1 00 01 and HOST 00 1 00 02, 1FR, option dgt. If you have trouble getting dialtone, you might have to return the line cards to service in mapci;mtc;ltp;post d x where x is the DN (I think servord does this automatically, if the LCM and line drawer are already up and running).
At this point, you should have dialtone available on both lines that were provisioned, but anything you dial will ultimately fail because we haven't set up any routing. Worse yet, you won't even get reorder, you'll just be reset back to dialtone because we don't even have treatments set up (we'll get to that later).
Having a look with a traver reveals the routing issues:
> traver l 5631000 5631001 t
TABLE LINEATTR
0 1FR NONE NT 0 0 NILSFC 0 NIL NIL 00 222_POTS_0 NLCA_NILLA_0 $
LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE
TABLE XLAPLAN
222_POTS_0 NSCR 222 NPRT NONE N $ 1FR_POTS
TABLE RATEAREA
NLCA_NILLA_0 NLCA NIL NILLATA $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE LENFEAT
TUPLE NOT FOUND
TABLE OFCVAR
AIN_OFFICE_TRIGGRP NIL
AIN Orig Attempt TDP: no subscribed trigger.
TABLE HNPACONT
222 Y 99 10 ( 0) ( 0) ( 0) ( 0) 0 $
. SUBTABLE HNPACODE
. KEY NOT FOUND
. REAL VALUE IS: VCT VACT N
There's more, but it's just about failing to find treatments. We'll deal with that next.
Since it's routing through HNPACONT and into HNPACODE, we should add a tuple there to match the numbers in our office. In subtable HNPACODE for the 222 entry in HNPACONT, I created the following to route local DNs for my switch:
FROMDIGS TODIGS
CDRRTMT
------------------------------------------
563 563
DN 222 563
Finally, we should be able to route calls from one telephone set to the other, but there is one quirk. Because we're not using a pretranslator, the switch doesn't really bother trying to figure out when you're done dialing digits except for the normal interdigit timeout (or 10 digits). Again, this is something we'll deal with later.
Coming back to treatments, we see the following in that failed traver from before as well:
TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLED
REORDER ALSO NOT DATAFILLED
TMTCNTL is automatically filled with a few basic treatment sets, with OFFTREAT functioning as the default set. The data schema manuals detail this, but the basic sequence is for the switch to search for the treatment first in the specific treatment set to that thing, followed by searching for the treatment in OFFTREAT, followed by searching for RODR (reorder) in OFFTREAT, before finally returning to an idle condition if everything else fails. That's what's occuring on our couple of lines that are provisioned, if we dial something invalid right now.
We've got some dependencies to walk, again, and some additional points to consider based on what was previously datafilled for the switch.
Firstly, reorder is based on a 120IPM LO tone. We don't even have the CLLI defined for it, so we'll start there:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
T120 84 10 FASTBUSY
Once the CLLI is defined, we can define the tone in TONES:
CLLI TRAFSNO SEGTIME OFFTIME TONEPATT
TONETYP
OFFTONE
MAXDURN MAXCONN
FNTONID
TONESGRP
----------------------------------------------------------
T120 0 25 25 101010
LO
SILENT_TONE
30 255
TONE_NULL
N
And finally, for the moment, we can add it directly in TMTCNTL.TREAT in OFFTREAT.
TREATMT LOG FSTRTE
----------------------------
RODR N S T120
Now if we dial something invalid, our lines give us reorder. However, for treatments specific to lines, we can get a bit fancier and do a LKOUT after a single duration of the T120 tone (LKOUT, IDLE, and ROH should not be used in OFFTREAT or trunk treatments). For this, we'll have to define a route in OFRT.
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
1 (S D T120) (S D LKOUT) $
$
Then in TMTCNTL, in the TREAT subtable for LNT:
TREATMT LOG FSTRTE
----------------------------
RODR N T OFRT 1
However, it's worth noting we won't hit this if we dial a valid number that is otherwise nonexistent, in that case we would hit the VACT or BLDN treatment (depending how far we get in translations).
Another notable one is that busy tone isn't defined, so instead you'll get reorder for that too.
Back in CLLI, we add T60:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
T60 85 10 SLOWBUSY
then in TONES:
CLLI TRAFSNO SEGTIME OFFTIME TONEPATT
TONETYP
OFFTONE
MAXDURN MAXCONN
FNTONID
TONESGRP
----------------------------------------------------------
T60 0 50 50 101010
LO
SILENT_TONE
30 255
TONE_NULL
N
And then in the OFFTREAT TREAT subtable:
TREATMT LOG FSTRTE
----------------------------
BUSY N S T60
Then we can create a route for LNT TREAT again:
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
2 (S D T60) (S D LKOUT) $
$
And lastly, point to it from LNT TREAT:
TREATMT LOG FSTRTE
----------------------------
BUSY N T OFRT 2
Obviously there's a lot more treatments, but unless you've got more specific announcements or handling for them, reorder/T120 is about as good a default as you can have (with the obvious exception of BUSY).
Now we've got some routing improvements to make. As noted, dumping straight into HNPACONT has some issues, so lets back out and implement a pretranslator. That's done in stdprtct:
EXTPRTNM STDPRT AMAPRT
------------------------
POTS ( 0) ( 0)
And then we need to build subtable STDPRT out with some very crude NANP basics. We're going to basically block anything other than 1+10d dialing, since that's what they use in the LATA I'm in.
FROMDIGS TODIGS
PRETRTE
-------------------------------------------------------
0 11
D VACT
12 1910
N DD 1 NA
1911 1911
D VACT
1912 199
N DD 1 NA
2 910
N NP 0 NA
911 911
D VACT
912 99
N NP 0 NA
Basically blocking anything that doesn't look like a 1+ or NPA/NXX number. Operator assisted is vacant, CAC is vacant, and 911 is blocked because... I don't want to deal with that.
Then we need to add an FNPACONT table to take over the routing for our fake '222' area code.
NPA MAXRTE
ROUTES
FNPACODE FNPASTS RTEREF RTEMAP
---------------------------------------------------------------------
222 10
-
( 0) ( 0) ( 0) ( 0)
FNPACODE works a bit differently, so we need to add a RTEREF:
RTE RTELIST
----------------------------------------------------------------------------
563 ( DN 222 563 4)$
Since we don't have any trunking yet, it'll just be the '563' prefix in FNPACODE that points to our DNs.
FROMDIGS TODIGS RTEREF CAMAAUTH
-------------------------------
563 563 563 Y
HNPACONT may need to be reconfigured for more ambiguous codes:
STS SNPA NORTREFS NOAMBIGC RTEREF HNPACODE ATTRIB RTEMAP
OPTIONS
----------------------------------------------------------------------------
222 Y 99 20 ( 0) ( 1) ( 0) ( 0)
$
Then HNPACODE is filled in a little differently from before:
FROMDIGS TODIGS
CDRRTMT
------------------------------------------
20 210
AMBI OPF VCT VACT VCT VACT
212 221
AMBI OPF VCT VACT VCT VACT
222 222
AMBI OPF VCT VACT FNPA 0
223 410
AMBI OPF VCT VACT VCT VACT
412 510
AMBI OPF VCT VACT VCT VACT
512 610
AMBI OPF VCT VACT VCT VACT
612 710
AMBI OPF VCT VACT VCT VACT
712 810
AMBI OPF VCT VACT VCT VACT
812 910
AMBI OPF VCT VACT VCT VACT
912 987
AMBI OPF VCT VACT VCT VACT
989 99
AMBI OPF VCT VACT VCT VACT
Basically, because we don't have trunking yet, all of the NPAs are directed to VACT, except 222 which filters into FNPACONT for 1+10d dialing.
Now we just need to add the pretranslator to our XLAPLAN:
XLAPIDX SCRNCL HSTS PRTNM ZEROMPOS RESINF
OPTIONS ADMININF
-------------------------------------------------------------------
222_POTS_0 NSCR 222 POTS NONE N
$ 1FR_POTS
Next up, trunking. We'll be starting with defining a PRI, but as you might guess, this is a big drawn out process involve a ton of different tables, crosslinking of data, etc. We'll be following along with 298-7002-001 (DMS SuperNode System Primary Rate Interface (PRI) Translations (the student guide for Nortel course 7002).
The first place to have a look at is the CARRMTC table, which contains information about DS1 trunk profiles, essentially. Having a look through, there's one entry that we didn't remove from the University of Alabama that looks about right for a modern PRI on our LTC:
CSPMTYPE TMPLTNM RTSML RTSOL ATTR
----------------------------------------------------------------------------
LTC ESFB8ZS 255 255 DS1 NT6X50AB MU_LAW ESF B8ZS BPV NILDL
N 250 1000 50 50 50 1000 3 6 864 100
17 511 4 255
It's set up for a mu law DS1 on a 6X50AB using ESF framing and B8ZS line code. The training material suggests this may be one of the default entries for this table (or modified from it). This entry matches our needs and hardware, so we'll use it. The other fields have to do with out-of-service and maintenance error limits for trunks that are having issues.
Then we've got a few changes to make in LTCINV. When we initially configured it, we were just worried about supporting POTS, so we didn't set it up for DS1 trunks. We'll change our entry to include the PRAB TRMTYPE using the DTCEX EXEC. Those go as an additional entry to the EXECTAB field. The resulting new tuple is the following:
LTCNAME
ADNUM FRTYPE FRNO SHPOS FLOOR ROW FRPOS EQPEC LOAD
EXECTAB
CSLNKTAB
OPTCARD
TONESET PROCPEC
EXTLINKS
E2LOAD
OPTATTR
PEC6X40 EXTINFO
----------------------------------------------------------------------------
LTC 0
1 LTEI 0 18 1 B 3 6X02NA QLI22AO
( POTS POTSEX) ( PRAB DTCEX)$
(0 10 16 0) (0 10 16 1) (0 10 16 2) (0 10 16 3) (0 10 16 4) (0 10 16 5)
(0 10 16 6) (0 10 16 7) (0 10 16 8) (0 10 16 9) (0 10 16 10) (0 10 16 11)
(0 10 16 12) (0 10 16 13) (0 10 16 14) (0 10 16 15) $
(UTR15 ) (MSG6X69 ) (CMR13 CMRU23A) (ISP 16) $
NORTHAA SX05AA $ SX05AA $
0
SXFWAL01
$
6X40FA N
The next changes we'll have to make are in LTCPSINV. This is where the T1 cards themselves get assigned. I've added an NT6X50AB to slot 5 of unit 0 of my LTC. This corresponds to ports 0 and 1. Thus, ports 0 and 1 will be changed to DS1PRA type (for PRI), reference ESFB8ZS from CARRMTC, interface identifier of 0 for both, line equalization set to NIL, and echo canceller tail set to '$'. The line equalization and tail only apply to cards with integrated echo canceller (6X50EC, I think). For 6X50AB and AA, the line equalization is set by dip switches. I also set up ports 2 and 3, which would be slot 5 of unit 1. I'm going to see what happens if I don't install the card. I need these additional ports equipped because SYNCLK enforces some redundancy rules for clocking and I needed another card in the other unit. The results follow:
LTCNAME
PSLNKTAB
----------------------------------------------------------------------------
LTC 0
N (0 DS1PRA ESFB8ZS N 0 NIL $)
(1 DS1PRA ESFB8ZS N 0 NIL $) (2 DS1PRA ESFB8ZS N 0 NIL $)
(3 DS1PRA ESFB8ZS N 0 NIL $) (4 NILTYPE ) (5 NILTYPE )
(6 NILTYPE ) (7 NILTYPE ) (8 NILTYPE ) (9 NILTYPE ) (10 NILTYPE )
(11 NILTYPE ) (12 NILTYPE ) (13 NILTYPE ) (14 NILTYPE )
(15 NILTYPE ) (16 NILTYPE ) (17 DS30A ) (18 NILTYPE )
(19 DS30A ) $
The interface identifier gets used in larger trunk groups, I believe, and may need to be set correctly if you're setting up a PRI group that comprised more than a single DS1.
Next, we'll have to define our trunk in the CLLI table. We'll need to pick a CLLI, and administrative number, set our trunk group size, and optionally set some administrative information. The CLLI is a free-form entry, but should ideally be composed so as to clearly identify the trunk. The administrative number must be a value above 50, because 1 through 50 are reserved for pseudo-CLLIs used by internal parts of the switch. Aside from that, a number of fixed CLLIs exist that are likely already assigned various places, so you'll have to work around them. In my case, the result is this:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
LBRDILLG01T0 100 24 PRI_TO_CISCO
I didn't touch PADDATA (or maybe I couldn't delete it) when I cleared tables, so I won't need to set that again. Suffice it to say that PADDATA contains loss plan information for calls between various trunk and line types. The defaults that come with the switch are probably pretty sane.
The trunk group itself finally gets defined in TRKGRP. The trunk group must use a CLLI already defined previously for the GRPKEY. For a PRI, the GRPTYP will be PRA. Since I don't care about traffic separation, I'll use TRAFSNO of 0. The PADGRP for a PRA should be PRAC (unless you have something else in mind). That is defined in PADDATA as previously mentioned. NCCLS has something to do with OM pegs when GNCT occurs. A sane default seems to be NCRT. We'll choose ASEQ (ascending sequence) for SELSEQ (channel selection sequence). We don't require a specific billing DN at this time, so we enter N. For the initial LTID entry, $ is used and this will be assigned later when we make an entry in LTMAP. We won't use any additional options to be specified on this trunk, so we enter $ for OPTION. The result is the following:
GRPKEY
GRPINFO
----------------------------------------------------------------------------
LBRDILLG01T0
PRA 0 PRAC NCRT ASEQ N $ $
We have to define some ISDN parameters in ISDNPARM. To be honest, I don't fully understand this yet, but it has to do with mapping or blocking information elements as part of different message types in the ISDN signalling. For now, I'm leveraging the old values from the UofAl translations, which were pretty uniform:
NAME MSGTYPE MSGDIR DFLTACT PARMACT
----------------------------------------------------------------------------
PRI1 SETUP BOTH MAP (DIE MAP) (SH5 BLK) (SH6 BLK) (SH7 BLK)
(UNK BLK) (CGS ATP) (CDS ATP) (LLC ATP)
(HLC ATP) $
PRI1 NOTIFY BOTH MAP (DIE MAP) (UNK BLK)$
PRI1 ALERT BOTH MAP (UNK BLK)$
There are some additional parameters that can be set in TRKRCSEL, but it's not clear what they are or do, and apparently if you don't define them, some sane defaults are used, so I'll leave them unset.
With those ISDN parameters taken care of, we can define the trunk subgroups in TRKSGRP. We add an entry for out CLLI (LBRDILLG01T0). Only subgroup 0 is valid for ISDN trunks. For ISDN, the cardcode is DS1SIG, SGRPVAR is ISDN. PSPDSEIZ is the timeout for partial dial seizure (reception of first digit). PARTDIAL is the same but for any digit after the first. VERSION is the ISDN protocol version. CRLENGTH determines the number of bytes to use for the call reference value. BCHNEG determines whether B channels can be negotiated (during setup, I assume?). BCHGLARE determines whether the switch will STAND or YIELD in the event of B-channel glare. IFCLASS determines whether the switch is the network or user side of the connection. CONFIG should be set to PT_PT for normal point to point trunks. LOCATION determines the location to be used for creating cause codes. SAT should be set based on whether satellite switching is used in the trunk. ECSTAT is set to UNEQ for no echo canceller. TRKGRDTH sets the lockout timeout. L1FLAGS set to Y is normal for most vendors and has to do with Q.921 flags. We can choose the ISDNPARM entry with PARMNAME. Our D-channel is in LTC 0, span 0, channel 24. It is 64k and uses normal polarity HDLC. We don't have a backup D channel, so we enter $. We don't have any options, so we enter $.
SGRPKEY CARDCODE
SGRPVAR
SGRPVAR
----------------------------------------------------------------------------
LBRDILLG01T0 0 DS1SIG
ISDN 10 12 87Q931 2 N YIELD USER PT_PT USER N UNEQ
75 Y PRI1 LTC 0 0 24 64K HDLC
$
$
Now we can define the trunk members in TRKMEM. We do this for each of the B channels. We use our previously defined CLLI, create an entry for each B-channel with EXTRKNM starting from 0, trunk subgroup is 0, and specify the channels on our LTC 0, span 0, channel 1 through 23.
CLLI EXTRKNM SGRP MEMVAR
-----------------------------------------------------------
LBRDILLG01T0 0 0 LTC 0 0 1
LBRDILLG01T0 1 0 LTC 0 0 2
LBRDILLG01T0 2 0 LTC 0 0 3
LBRDILLG01T0 3 0 LTC 0 0 4
LBRDILLG01T0 4 0 LTC 0 0 5
LBRDILLG01T0 5 0 LTC 0 0 6
LBRDILLG01T0 6 0 LTC 0 0 7
LBRDILLG01T0 7 0 LTC 0 0 8
LBRDILLG01T0 8 0 LTC 0 0 9
LBRDILLG01T0 9 0 LTC 0 0 10
LBRDILLG01T0 10 0 LTC 0 0 11
LBRDILLG01T0 11 0 LTC 0 0 12
LBRDILLG01T0 12 0 LTC 0 0 13
LBRDILLG01T0 13 0 LTC 0 0 14
LBRDILLG01T0 14 0 LTC 0 0 15
LBRDILLG01T0 15 0 LTC 0 0 16
LBRDILLG01T0 16 0 LTC 0 0 17
LBRDILLG01T0 17 0 LTC 0 0 18
LBRDILLG01T0 18 0 LTC 0 0 19
LBRDILLG01T0 19 0 LTC 0 0 20
LBRDILLG01T0 20 0 LTC 0 0 21
LBRDILLG01T0 21 0 LTC 0 0 22
LBRDILLG01T0 22 0 LTC 0 0 23
Next we declare a logical terminal group for the PRI in LTGRP. It's not clear if we have to do this or if we can use the default ISDN LTGRP.
GROUP GROUPNO OPTIONS
--------------------------
PRI 16 $
PRIPROF controls protocol variants. We create an entry for NI2, and lean on the UofAl translations a bit for the OPTIONS.
PROFNAME VARINFO
SWITCH
----------------------------------------------------------------------------
PROFPRI NIPRI NI2V1
(UNTONNPI)$
Now we define the logical terminal in LTDEF. We add a logical terminal to our LTGRP PRI. The only supported LTAP for PRIs is B for circuit switching. PRA indicated the PRA type, 23 B channels, NIPRI ISDN variant and the NI2V1 issue. We use the PROFPRI profile, and the NOPMD option is default (we entered $ and didn't specify additional options).
LTKEY LTAP
CLASSREF
----------------------------------------------------------------------------
PRI 1 B
PRA 23 NIPRI NI2V1 PROFPRI (NOPMD ) $
Next we add an LTMAP to point our PRI 1 LTDEF at our CLLI. PRI requires an option of TEI 0.
LTKEY MAPPING OPTION
----------------------------------------------------------------
PRI 1 CLLI LBRDILLG01T0 ( TEI 0)$
When the entry is created in LTMAP, the DMS also updates table TRKGRP with the LTID:
GRPKEY
GRPINFO
----------------------------------------------------------------------------
LBRDILLG01T0
PRA 0 PRAC NCRT ASEQ N (PRI 1) $ $
We also need to consider clocking for the switch. In my case, as wrong as it sounds, I'll have the DMS synchronize to my Cisco 3845. This is because the 3845 is always on in my setup, so it is the best device to use as a clock master at the moment. It doesn't have to be, but the way it's all set up currently, it just makes the most sense.
Clock settings are set in SYNCLK. Since my switch is currently set to free run after I cleared the tables previously, I won't have to switch to free run before changing the clock synchronization settings. Since the tuple in SYNCLK always exists, we'll have to change it rather than add one. We'll be a stratum 3 clock, clocked off of our trunk in our LTC (LTC 0 circuit 0). Apparently the datafill manual advises that for LTCs (and a number of other XPMs) the circuit number choices are 0 and 8, but it seems like any circuit can be specified. LK0_REG determines which register on a 2-link DS1 card gets used (relevant for XPM DS1 interfaces). Possible choices are 0 or 1, but it's not clear which one applies to what circuits. The DMS will make sure you use the right one, so there's a bit of trial and error here. The DMS also really wants you to define a secondary timing link, and it enforces some rules. I think it wants the links used for timing to be in different shelves.
CLKKEY CLKDATA
OFFCDATA
-----------------------------------------------------
0 STRAT3
SLAVE LTC 0 0 0 LTC 0 2 1
Now that we've got everything configured as far as the trunk goes, we'll need to put the trunk into service. When we created the trunk initially, it went into the INB or INstallation Busy state. We must manually put the trunk in service using mapci;mtc;trks;ttp;post g lbrdillg01t0;bsy all followed by rts all.
We need to do similar with the D-channel in mapci;mtc;trks;pradch;post gd lbrdillg01t0;bsy all followed by rts all.
And finally, we need to do the DS1 carrier itself in mapci;mtc;trks;carrier;post ltc 0 0;bsy all; followed by rts all.
[insert thing about checking and switching the clocking over to train on the link here]
At this point, hopefully we've got everything configured for the PRI to come up. We don't yet have any outgoing or incoming routing set. We'll start with outgoing. First is to set up a route.
I'll add my first route in OFRT. I picked a free route reference number and added an ISA type route to the route list. ISA is Integrated Services Access. There may be other types of routes that would work, but this will do for now. I did not enable off-hook queueing, call-back queueing, or expensive route warning tones. I pointed the route selector at the CLLI I defined for the trunk and set the number type to public. I disabled operator access, did not use a transit network selector, did not require calling number identification, and chose no digit manipulation. I ended the route list and did not use any additional options for the route.
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
3 ( ISA N N N LBRDILLG01T0 N PUB NONE N N 0)$
$
With the route created, we need to set up the translations to send some traffic out using it.
Back in FNPACONT, we enter the RTEREF subtable for the 222 (SCDP) FNPA. Here, we add a RTEREF to point to our OFRT route list. We use the T selector for Table, and point to OFRT 3. Then we end our route list. Note that we could have implemented the ISA selector here directly, if we wanted to.
RTE RTELIST
----------------------------------------------------------------------------
1 ( T OFRT 3)$
Then we back out and enter the FNPACODE subtable for the 222 FNPA. For now, we'll add a couple ranges around our existing 563 code to encompass all possible SCDP (noting that we're covering a couple reserved codes like N11 etc.).
FROMDIGS TODIGS RTEREF CAMAAUTH
-------------------------------
200 562 1 Y
563 563 563 Y
564 999 1 Y
[add text for ltcalls]
LTID XLARTSEL
OPTIONS
----------------------------------------------------------------------------
PRI 1 PUB XLALEC 0 222_POTS_0 NLCA_NILLA_0
$
We can also set routes to support hunting to multiple trunks:
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
4 (ISA N N N HYMRVAX002T0 N PUB NONE N N 0) (T OFRT 3) $
$
We can also route DNs that are assigned to the switch. This can be done in DNROUTE, but SERVORD is a better choice here. Using the NEWDN command, we can assign a block of DNs to a route:
SO:
>newdn
SONUMBER: NOW 24 1 13 PM
>
SNPA:
>222
BLOCK_OF_DNS:
>yes
FROM_DN:
>5632000
TO_DN:
>999
VDNTYPE:
>rte
ROUTE:
>ofrt 3
OPTION:
>$
COMMAND AS ENTERED:
NEWDN NOW 24 1 13 PM 222 YES 5632000 999 RTE OFRT 3 $
ENTER Y TO CONFIRM,N TO REJECT OR E TO EDIT
>y
>
While there's more trunking and routing to potentially build out, the general idea from here is the same.
From here, there's a few things we can do to attempt to improve the usability of the switch. For one, the LTC takes a very long time to load (nearly and hour), but it can support a device called a Peripheral Remote Loader (PRL) memory that allows faster reloading of the software for the processor. The NTSX05 processor uses PCMCIA flash cards for the PRL. I'm going to see if I can use a 64MB CF card in a PCMCIA adapter to accomplish this.
We first need to go back into LTCINV and change the tuple to add 'PRL' to our two NTSX05AA processor entries. PROCPEC will be changed to 'SX05AA PRL $ SX05AA PRL $'
LTCNAME
ADNUM FRTYPE FRNO SHPOS FLOOR ROW FRPOS EQPEC LOAD
EXECTAB
CSLNKTAB
OPTCARD
TONESET PROCPEC
EXTLINKS
E2LOAD
OPTATTR
PEC6X40 EXTINFO
----------------------------------------------------------------------------
LTC 0
1 LTEI 0 18 1 B 3 6X02NA QLI22AO
( POTS POTSEX) ( PRAB DTCEX)$
(0 10 16 0) (0 10 16 1) (0 10 16 2) (0 10 16 3) (0 10 16 4) (0 10 16 5)
(0 10 16 6) (0 10 16 7) (0 10 16 8) (0 10 16 9) (0 10 16 10) (0 10 16 11)
(0 10 16 12) (0 10 16 13) (0 10 16 14) (0 10 16 15) $
(UTR15 ) (MSG6X69 ) (CMR13 CMRU23A) (ISP 16) $
NORTHAA SX05AA (PRL) $ SX05AA (PRL) $
0
SXFWAL01
$
6X40FA N
After making the change, the unit must be busied and then returned to service for the changes to take effect. If you have the PM actually running duplex, you can do as the DMS advises and perform this action to one side of the PM at a time:
WARNING: Static data needs to be updated for:
LTC 0
BSY the INACTive unit, RTS and SWACT the peripheral.
Since I am not running both processors, I will have to take my LTC out of service, insert the NTSX06 flash card, and then return to service.
At this point, you can check if the card is recognized properly with 'QueryPM config' on the MAPCI screen for the LTC. Since I don't have an actual NTSX06 flash card, my cards were not recognized and I couldn't continue.
In theory, the next step is to use the XPMSTOR command to load the software onto the unit in question (choosing between active/inactive). From there, you should probably test whether it successfully loads from the PRL card. You can do that with loadpm. No telling if it'll do that during boot/system recovery on it's own, or if you need to tell it manually. If I decide to overpay for an NTSX06BA, I guess I'll find out.
Another nice feature will be to enable IP access so that we don't need to use the serial ports to access the switch. I have had some trouble with IOMs intermittently taking a long time to initialize from a cold start, I'm hopeful that the ethernet interfaces in the XA-core initialize more consistently.
From what I can find, the table CMIPADDR is used for the interfaces that are part of the XA-core. The first steps are to define the links:
KEY
DATA
----------------------------------------------------------------------------
ETHRLNK 0
ETHR 5 REAR NONE (172 23 5 3) 8 (172 23 5 4) 8 (172 23 5 1) 0
ETHRLNK 1
ETHR 14 REAR NONE (172 23 5 5) 8 (172 23 5 6) 8 (172 23 5 1) 0
My packs are HIOPs, so the packlet field gets 'NONE'. All IPs need to be in the same subnet. Also, it seems like the DMS got subnet masks backwards: 8 seems to correspond to /24
Next is to fill the active IPs for the XA-Core:
KEY
DATA
----------------------------------------------------------------------------
CMHOST 0
HOST (172 23 5 7) 8 0
CMHOST 1
HOST (172 23 5 8) 8 0
Again, these IPs must be in the same subnet as the others.
Lastly, if you need to reach the XA-core from other subnets (or if the XA-core needs to reach IPs in other subnets) a gateway needs to be added:
KEY
DATA
----------------------------------------------------------------------------
GATEWAY 0
GW (172 23 5 1) 0
At this point, you should be able to ping all of the IPs of the XA-core, assuming your links all came up OK. Unfortunately, that's about all I can convince the DMS to do. I'm not sure if telnet or any other TCP protocols are supposed to be supported, but I don't seem to be able to do anything with any of the assigned IPs beyond pings.
I also tried stuff in IPNETWRK and IPHOST:
KEYREF CMIPADDR SUBNET OPTION
PARMAREA
----------------------------------------------------------------------------
0 130 160 128 151 8 $
(DFLT_INTERFACE Y) (DFLT_GTWY_IPADDR 130 160 128 1) (SCRNFLAG N) $
15 172 23 5 7 8 $
( IRM_INTERFACE )$
INDEX NODENAME NODEINFO
---------------------------------------------------------------------
0 CM 0 64 16 16
Next steps to see what's going on is to maybe put a packet sniffer on the ethernet segment and see what's coming out of the DMS. Obviously I can ping the IPs and get replies, but not much else. It would be useful to see 1) if any traffic is coming out of the DMS without even doing anything (maybe ARP looking for some IPs or something) 2) try the FTP client on the DMS and see if I see the connection attempt, and how it looks.
With that out of the way, next we'll set up an EDRAM. Useful documentation includes 297-1001-527, 297-8991-597, and -598.
I've placed my EDRAM (NT1X80BA) into the slot 6 of the ISM shelf at position 19 (which I deem to be MTM 0) in my MCAM. Since the DS-30 cabling in the MCAM is pre-wired, this connects it to DS-30 1 (rather than 0). The DS-30 cabling is run to ports 0 and 2-4 on card 10 of ENET shelf 0. Port 1 cannot support message links, I guess, so it has to be skipped for PMs with only a single DS-30 link.
The EDRAM card is it's own PM, but it's classed such that it is configured in TMINV.
TMNM FRTYPE FRNO SHPOS FLOOR ROW FRPOS LKDATA EQPEC
LOAD EXECS SCTMLOC
---------------------------------------------------------------------
DTM 0 MCAM 0 19 1 A 4 0 10 2 0 1X80BA
ED16AA07 MTMEX SINGLE_CARD MTM 0 6
That takes care of defining the PM, so we should be able to bring the link up and see if the EDRAM card will load. We can start in mapci;mtc;net;shelf 0;card 10. Here, we can see that the new link is in the offline state. We can first put it in the manual busy state with the 'bsy x link y' command where x is the ENET plane number and y is the link number. We can then follow that with 'rts x link y' where x and y are the same as before.
With the link returned to service, we can start on the PM with mapci;mtc;pm;post dtm 0. Similar story here as other PMs: MBSY with 'BSY', then load software with 'LOADPM', lastly return to service with 'RTS'. Note that since we haven't defined any announcment files anywhere, it'll warn you about that. No big deal, we'll get to that later. I figure it's good to make sure our DS-30 is working right before we get there. To make substantial changes to the EDRAM, we'll have to busy it back out, so do that with the 'bsy' command.
Bursty
Our EDRAM card will require a CLLI:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
EDRAM0 102 33 EDRAM
Next, we need to enter the DRAMS table and define our EDRAM:
DRAMCARD TMTYPE TMNO TMCKT CARDCODE
CARDINFO
----------------------------------------------------------------------------
0 0 DTM 0 0 1X80BA
CTLR EDRAM0
0 1 DTM 0 0 1X80BA
PROM (0) $
0 2 DTM 0 0 1X80BA
PROM (1) $
0 3 DTM 0 0 1X80BA
RAM (2) $
0 4 DTM 0 0 1X80BA
RAM (3) $
0 5 DTM 0 0 1X80BA
RAM (4) $
0 6 DTM 0 0 1X80BA
RAM (5) $
0 7 DTM 0 0 1X80BA
RAM (6) $
0 8 DTM 0 0 1X80BA
RAM (7) $
0 9 DTM 0 0 1X80BA
RAM (8) $
0 10 DTM 0 0 1X80BA
RAM (9) $
0 11 DTM 0 0 1X80BA
RAM (10) $
0 12 DTM 0 0 1X80BA
RAM (11) $
0 13 DTM 0 0 1X80BA
RAM (12) $
0 14 DTM 0 0 1X80BA
RAM (13) $
0 15 DTM 0 0 1X80BA
RAM (14) $
0 16 DTM 0 0 1X80BA
RAM (15) $
0 17 DTM 0 0 1X80BA
RAM (16) $
0 18 DTM 0 0 1X80BA
RAM (17) $
0 19 DTM 0 0 1X80BA
RAM (18) $
0 20 DTM 0 0 1X80BA
RAM (19) $
0 21 DTM 0 0 1X80BA
RAM (20) $
0 22 DTM 0 0 1X80BA
RAM (21) $
0 23 DTM 0 0 1X80BA
RAM (22) $
0 24 DTM 0 0 1X80BA
RAM (23) $
0 25 DTM 0 0 1X80BA
RAM (24) $
0 26 DTM 0 0 1X80BA
RAM (25) $
0 27 DTM 0 0 1X80BA
RAM (26) $
0 28 DTM 0 0 1X80BA
RAM (27) $
0 29 DTM 0 0 1X80BA
RAM (28) $
0 30 DTM 0 0 1X80BA
RAM (29) $
0 31 DTM 0 0 1X80BA
RAM (30) $
0 32 DTM 0 0 1X80BA
RAM (31) $
We define the first two slots as PROM to load stock announcement files into, and the rest of the card as RAM for custom announcements. We can always change this later, thought it may mean busying the card.
Next, we'll define some standard announcement sets to load in EDRAMINV:
EDRAMNM TUPINFO
----------------------------------------
DTM 0 1 ANN ESTD0AA
DTM 0 2 ANN ESTD0AA
ESTD0AA is actually canadian english, so it's worth noting that it should probably be ASTD0AB (american english) for my region. However, I'm too lazy to see if that file exists on my switch (turns out it does), so we'll stick with the canadian set.
We'll have to add this to PMLOADS, so the switch knows where to find it:
LOADNAME
ACTFILE ACTVOL
BKPFILE BKPVOL UPDACT
------------------------------------------------------------
ESTD0AA
ESTD0AA F02LPMLD
ESTD0AA F17LPMLD N
To load the announcement set, we need to use mapci;mtc;pm;post dtm x where x is the number of your EDRAM DTM. From here, we can first busy with 'bsy', then load the announcement sets with 'loadpm ann', followed by returning to service with 'rts'.
We will also need to assign the phrases in DRAMPHRS. Supposedly we're Not Supposed To Do That and use the ASSIGN command within DRAMREC instead. In any case, here's our end result:
DRAM PHRSNAME PHRASENO BLOCK LENGTH RECORDED
----------------------------------------------------
0 ENG1 48 0 1 N
0 ENG2 49 0 1 N
0 ENG3 50 0 1 N
0 ENG4 51 0 1 N
0 ENG5 52 0 1 N
0 ENG6 53 0 1 N
0 ENG7 54 0 1 N
0 ENG8 55 0 1 N
0 ENG9 56 0 1 N
0 ENG0 47 0 1 N
0 SILENCE 0 0 1 N
0 TEST760 1 0 1 N
0 SIT1 8 0 1 N
0 SIT2 9 0 1 N
0 SIT3 10 0 1 N
0 SIT4 11 0 1 N
0 SIT5 12 0 1 N
0 SIT6 13 0 1 N
0 SIT7 14 0 1 N
0 SIT8 15 0 1 N
0 SIT9 16 0 1 N
0 SIT10 17 0 1 N
0 SIT11 18 0 1 N
0 SIT12 19 0 1 N
0 SIT13 20 0 1 N
0 SIT14 21 0 1 N
0 SIT15 22 0 1 N
0 SIT16 23 0 1 N
0 SIT17 24 0 1 N
0 SIT18 25 0 1 N
0 SIT19 26 0 1 N
0 SIT20 27 0 1 N
0 SIT21 28 0 1 N
0 SIT22 29 0 1 N
0 SIT23 30 0 1 N
0 SIT24 31 0 1 N
0 SIT25 32 0 1 N
0 SIT26 33 0 1 N
0 SIT27 34 0 1 N
0 SIT28 35 0 1 N
0 SIT29 36 0 1 N
0 SIT30 37 0 1 N
0 SIT31 38 0 1 N
0 SIT32 39 0 1 N
0 NCA 40 0 9 N
0 ROA 41 0 9 N
0 VCA 42 0 12 N
0 ROH 43 0 13 N
0 VDN 44 0 6 N
0 MCA 45 0 11 N
0 MCL 46 0 10 N
0 PROMPT 2 0 1 N
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
ALLANNS 106 1 ALL_ANNOUNCEMENTS
ALLANNS2 107 1 ALL_ANNOUNCEMENTS_2
ALLANNS3 108 1 ALL_ANNOUCEMENTS_3
ALLANNS4 109 1 ALL_ANNOUNCEMENTS_4
CLLI ANNARCH TRAFSNO CYTIME MAXCYC DATA
----------------------------------------------------------------------------
ALLANNS NETWK 0 0 1 STND N 255
ALLANNS2 NETWK 0 0 1 STND N 255
ALLANNS3 NETWK 0 0 1 STND N 255
ALLANNS4 NETWK 0 0 1 STND N 255
ANNMEM HDWTYPE CARD
MEMINFO
----------------------------------------------------------------------------
ALLANNS 0 DRAM DRA
( 0 DTM 0 1)$
ALLANNS2 0 DRAM DRA
( 0 DTM 0 2)$
ALLANNS3 0 DRAM DRA
( 0 DTM 0 3)$
ALLANNS4 0 DRAM DRA
( 0 DTM 0 4)$
ANNPHKEY
PHSLIST
----------------------------------------------------------------------------
ALLANNS 0
(SILENCE) (TEST760) (PROMPT) (SIT1) (SIT2) (SIT3) (SIT4) (SIT5) (SIT6)
(SIT7) (SIT8) (SIT9) (SIT10) (SIT11) (SIT12) (SILENCE) $
ALLANNS2 0
(SILENCE) (SIT13) (SIT14) (SIT15) (SIT16) (SIT17) (SIT18) (SIT19) (SIT20)
(SIT21) (SIT22) (SIT23) (SIT24) (SIT25) (SIT26) (SILENCE) $
ALLANNS3 0
(SILENCE) (SIT27) (SIT28) (SIT29) (SIT30) (SIT31) (SIT32) (NCA) (ROA) (VCA)
(ROH) (VDN) (MCA) (MCL) (ENG0) (SILENCE) $
ALLANNS4 0
(SILENCE) (ENG1) (ENG2) (ENG3) (ENG4) (ENG5) (ENG6) (ENG7) (ENG8) (ENG9)
(SILENCE) $
mapci;mtc;trks;ttp;post g allanns;bsy all;rts all;post g allanns2;bsy all;rts all;post g allanns3;bsy all;rts all;post g allanns4;bsy all;rts all
We can point a route list at our announcement set to string them together:
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
5 (S D ALLANNS) (S D ALLANNS2) (S D ALLANNS3) (S D ALLANNS4) (TRMT DISC)
$
$
We end with the "DISC" treatment because otherwise the call ends with all-circuits-busy as the cause code.
We can point a number at our route list in SERVORD with the NEWDN command, point to RTE table, and then to our route in OFRT. This results in a new DNROUTE being created:
AREACODE OFCCODE STNCODE DNRESULT
----------------------------------------------------------------------------
222 563 1003 T OFRT 5
It would be nice, at this point, to set up some announcements for VACT and BLDN treatments as well. First we'll need to set up the announcements for them:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
VACT 110 1 VACANT_CODE_ANNOUNCEMENT
BLDN 111 1 VACANT_DN_ANNOUNCEMENT
CLLI ANNARCH TRAFSNO CYTIME MAXCYC DATA
----------------------------------------------------------------------------
VACT NETWK 0 0 1 STND N 255
BLDN NETWK 0 0 1 STND N 255
ANNMEM HDWTYPE CARD
MEMINFO
----------------------------------------------------------------------------
VACT 0 DRAM DRA
( 0 DTM 0 5)$
BLDN 0 DRAM DRA
( 0 DTM 0 6)$
ANNPHKEY
PHSLIST
----------------------------------------------------------------------------
VACT 0
( SILENCE) ( VCA) ( SILENCE)$
BLDN 0
( SILENCE) ( VDN) ( SILENCE)$
mapci;mtc;trks;ttp;post g vact;bsy all;rts all;post g bldn;bsy all;rts all;quit all
Then we can set it up in TMTCNTL. Remember that we have OFFTREAT for the default office treatments, and then we have LNT for lines. OFFTREAT is as follows:
TREATMT LOG FSTRTE
----------------------------
VACT N S VACT
BLDN N S BLDN
Meanwhile, for LNT, we can get a bit fancier, first setting up a couple OFRTs:
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
6 (S D VACT) (S D LKOUT) $
$
7 (S D BLDN) (S D LKOUT) $
$
Then in the TREAT subtable of TMTCNTL LNT:
TREATMT LOG FSTRTE
----------------------------
VACT N T OFRT 6
BLDN N T OFRT 7
Then we want our beautiful announcements to play out over trunks as well, so we need to add an option to the logical terminals in LTDATA:
LTDKEY
LTDRSLT
----------------------------------------------------------------------------
PRI 1 SERV
SERV Y N SCREENED ALWAYS $
The 'AUDTRMT' option is set to 'Y' here to enable sending audible treatments to the trunk in the event of certain treatments.
Now we've got just one more thing to take care of: announcements supervise by default, but we can't have that over a trunk! The solution is a fake trunk CLLI that allows us to override supervision. So in OFRT:
RTE RTELIST
OPTIONS
----------------------------------------------------------------------------
8 (S D ONHKSUP) (S D VACT) $
$
9 (S D ONHKSUP) (S D BLDN) $
$
Then in the TREAT subtable of TITRKGRP (which corresponds to our ISDN trunk from earlier) in TMTCNTL:
TREATMT LOG FSTRTE
----------------------------
VACT N T OFRT 8
BLDN N T OFRT 9
If we want to assign a number to an arbitrary treatment, we could potentially do so when deleting a line or DN in SERVORD, but this is restricted to treatments that actually make sense, like BLDN (and others). VACT is not normally used for DNs though, so if we want that, we have to assign it manually in DNROUTE with 'D', the treatment selector:
AREACODE OFCCODE STNCODE DNRESULT
----------------------------------------------------------------------------
222 563 1004 D VACT
Let's see if we can load any old University of Alabama announcements. Starting up DISKUT and listing my PMLD volume shows a likely candidate for an announcement backup file:
File information for volume F02LPMLD:
{NOTE: 1 BLOCK = 512 BYTES }
--------------------------------------------------------------------------------
FILE NAME O R I O O V FILE MAX NUM OF FILE LAST
R E T P L L CODE REC RECORDS SIZE MODIFY
G C O E D D LEN IN IN DATE
C N FILE BLOCKS
--------------------------------------------------------------------------------
DTM_BK3 O V 0 255 3808 2304 160425
The naming suggests this went on card 3. I decided to make a copy of this file called UNIVANN to be sure I didn't do anything bad to the original. We need to specify this file to be loaded into the card on the EDRAM in table EDRAMINV. It's worth noting that the university didn't have any files specified in here, so there's a good chance the full set of their announcements is simply gone.
EDRAMNM TUPINFO
----------------------------------------
DTM 0 3 ANN UNIVANN
You may have to bsy the DTM peripheral before you add the entry here.
We can also define this one in PMLOADS so that we don't have to jump through hoops to get the DMS to find them on it's own:
LOADNAME
ACTFILE ACTVOL
BKPFILE BKPVOL UPDACT
------------------------------------------------------------
UNIVANN
UNIVANN F02LPMLD
UNIVANN F17LPMLD N
Before we return the EDRAM to service, we need to cause the file to load into it. We can be specific and load just the new file for card 3: 'mapci;mtc;pm;post dtm 0;loadpm ann 3'. Then we can RTS.
Since these announcements are custom, and haven't been defined previously, we will need to use a command in DRAMREC to get them listed. That will be the 'record' command with the extra 'force' parameter. Essentially fill out the record command as you normally would, without connecting a trunk to the EDRAM for recording, and then also use the force parameter. DRAMREC will fill DRAMPHRS with the parameters you gave it without actually recording anything.
In the event you make any custom recordings, you really should set up files to store them in. The DMS will not automatically save the recordings, but you can manually trigger it with the upload command in the mapci page for the EDRAM.
TODO: DISC treatment for LNT is going to GNCT, need to figure out the right way to set that up. LKOUT is better, but doesn't do battery drop.
Above, we also used the 'DISC' treatment. This treatment will cause a trunk call to end with normal call clearing conditions, useful to prevent an ACB cause code after a routelist for an announcement played over a trunk ends. While no extra setup seems to be necessary for this treatment over ISDN trunks, we'll need to set it up for lines. Since the purpose is to emulate normal call disconnection, all we really need to add in the TREAT subtable for LNT in TMTCNTL is the following:
TREATMT LOG FSTRTE
----------------------------
DISC N S LKOUT
This will just cause the line to go into lockout after disconnection. Note that this will inhibit battery drop when the DISC treatment is used, but it's better than the alternative (goes to reorder forever because the DISC treatment doesn't exist, so routes to GNCT).
The EDRAM can also generate a few different tones. For this, you'll need the mwttone file.
In table DRAMS, we need to configure a PROM type card to hold the tones, since the tones file is not custom. Note that in order to make changes in the DRAMS table, the EDRAM 'card' (subunit, really) will have to be placed in the INB state. You can do this by posting the EDRAM itself (remember we defined CLLI EDRAM0 for it?) in the TTP MAPCI level, navigating to the card number to be modified, and then bsy inb. Once you have made the change, bsy mb and rts.
DRAMCARD TMTYPE TMNO TMCKT CARDCODE
CARDINFO
----------------------------------------------------------------------------
0 4 DTM 0 0 1X80BA
PROM (3) $
Again, you may need to add the MWTTONE file to PMLOADS:
LOADNAME
ACTFILE ACTVOL
BKPFILE BKPVOL UPDACT
------------------------------------------------------------
MWTTONE
MWTTONE F02LPMLD
MWTTONE F17LPMLD N
Then we tell the system to load the EDRAM with this file in EDRAMINV:
EDRAMNM TUPINFO
----------------------------------------
DTM 0 4 ANN MWTTONE
The DTM will have to be busied and then returned to service to add this tuple. We will also have to reload at least that card with loadpm ann 4.
[TO BE CONTINUED] I'll get back to this, but last time I tried to load my copy of MWTTONE, I caused something to get angry (other than myself) and the switch stopped recognizing the EDRAM card. After a day and a reboot it was working again, but I wasn't sure whether loading MWTTONE caused an issue or not, so I'm moving on for now and will come back to this section later.
Next, we'll add some conference circuit cards. First, we'll need an MTM. I'll be using the ISM that my EDRAM is installed in.
We'll add the MTM in TMINV:
TMNM FRTYPE FRNO SHPOS FLOOR ROW FRPOS LKDATA EQPEC
LOAD EXECS SCTMLOC
---------------------------------------------------------------------
MTM 0 MCAM 0 19 1 A 4 0 10 0 0 FX42AA
MTMKA02 MTMEX SHELF
We will need to return to service the link that the MTM is on in mapci;mtc;net;shelf x;card y where x is the shelf number and y is the card number. We bsy y link z where x is the plane number, and y is the link number. Then we rts x link y, where x and y are again the plane and link numbers.
Next, we move to the PM with pm;post mtm x where x is the MTM number. We can bsy the PM first with 'bsy', then load with 'loadpm', and finally return to service with 'rts'.
Now we're ready to provision some conference circuits.
First, lets have a look in the CLLI table:
CLLI ADNUM TRKGRSIZ ADMININF
----------------------------------------------------------------
CF3P 52 170 3_PORT_CONFERENCE_CIRCUIT
CF6P 53 200 6_PORT_CONFERENCE_CIRCUIT
These are the two CLLIs that conference circuits go into. These should already exist on your switch, and I don't believe they can be removed once they've been created. If they don't exist, consult the data schema manuals to see about adding them. The main thing to note here is that the TRKGRSIZ is defined high enough to accomodate the highest EXTRKNM entries (noting that each conference circuit takes up an additional 2 or 5 EXTRKNMs past the first one that is specified in the tables that follow).
I have NT3X67 cards, which can be provisioned as either 2 3-port conference circuits, or one 6-port conference circuit (but not both at the same time). Provisioning is done in CONF3PR and CONF6PR. I'll start with CONF3PR:
CNFCKTNO GRPCLLI EXTRKNM TMTYPE TMNO TMCKTNO CARDCODE PADGRP
---------------------------------------------------------------------------
0 CF3P 0 MTM 0 24 3X67AA CONF
1 CF3P 10 MTM 0 25 3X67AA CONF
The external trunk member numbers must be unique, and the data schema manual suggests making them multiples of 10. The TMCKTNO can be referenced from the DMS-100 quick reference guide based on whether the card is installed in an MTM shelf or an ISM shelf. It is also important to note that the conference circuit cards use 6 ports and must be provisioned in a slot that allows for the next 6 circuits to be dedicated to the card. A PADGRP must be selected for the conference circuits, CONF should be the default PADGRP. Lastly, 3X67AAs need the circuit numbers that correspond to their 0th and 1st ports allocated separately as one corresponds to the first 3 port conference and the other corresponds to the second 3 port conference. In the case of 1X31AA cards, it will instead be the 0th and 3rd ports.
With the cards provisioned, we can post the trunk group with mapci;mtc;trks;ttp;post g cf3p. The conference trunks will be in the INB state. From here, we can 'bsy all' and then 'rts all' to put our conference circuits into service. We are OK to do it this way because we're starting from no circuits, but if we were adding circuits and already had some configured, we would want to explicitely bsy just the newly added circuits. We could do this when we post our circuits, using the syntax 'post g cf3p 10 to 19' to select only the members of our 2nd 3-port circuit, for example (noting that normally you would probably want to grab increments of a card, which would be '0 to 19' for example).
We should now be able to provision and use 3 way calling on some of our telephones, if all went well. We can add that option in servord to an existing line with the 'ado' command.
Next up, we'll provision a 6 port conference circuit. To ensure the cards are not too close together, I've spaced the next card at least 3 slots away from the other (that is, a gap of 2 slots) in slot 11. Slot 11 corresponds to circuits 18 and 19 (and the conf circuit card will occupy the next 4 as well).
6 port conferences are provisioned in CONF6PR:
CNFCKTNO EXTRKNM TMTYPE TMNO TMCKTNO CARDCODE PADGRP
-----------------------------------------------------------------
0 0 MTM 0 18 3X67AA CONF
The datafill here is pretty similar to CONF3PR, but since each card only corresponds to one 6 port conference circuit, we only need one entry per card. Additionally, we don't need to specify the CLLI explicitely, the system will assume CF6P.
Again, we'll need to return this new conference circuit to service: mapci;mtc;trks;ttp;post g cf6p 0 to 9, then 'bsy all' followed by 'rts all'. Note again, that if you are adding conference circuits to an existing pool, you should be careful to select only the appropriate circuits or else you might take something out of service that shouldn't be when you execute the 'bsy' command.
In order to actually make use of our 6 port conference circuit, I will set up an MMCONF. However, you need to first set up a customer group as this is an MDC feature.
Customer groups are added in CUSTENG:
CUSTNAME ADNUM NONCOS NOIBNTMT CONSOLES DOMAIN GROUPID
OPTIONS
----------------------------------------------------------------------------
SHADYTEL 1 10 0 N PUBLIC 0
$
Note that customer groups without attendant consoles are internally assigned customer group numbers starting at 256, and this means that customer groups without consoles will need OFCENG parameter to be CUSTOMER_GROUP_IBNGRP_OM_COUNT to be at least 288 (must be higher than 256, and must be a multiple of 32). To change that parameter, you will have to first use the 'rwok on' command to allow writes to restricted data (followed by 'rwok off' to disallow writes again).
We also need to put some minimums in CUSTHEAD.
CUSTNAME CUSTXLA DGCOLNM IDIGCOL
OPTIONS
----------------------------------------------------------------------------
SHADYTEL PRAXLA NDGT NIL
( VACTRMT 0) ( EXTNCOS 0) ( SUPERCNF )$
The VACTRMT, EXTNCOS options are by default, and the SUPERCNF option lets my MMCONFs span to a higher capacity than otherwise allowed. I reused the PRAXLA translator so I can avoid actually setting one up for now.
We have almost nothing defined in terms of this customer group at this point, but even just this should be enough for an MMCONF. Most of the other parameters have to do with dialplans and class of service restrictions, features, etc. MMCONF doesn't need any of the stuff that has to do with outbound calling, but we will need a bit of configuration for inbound that we'll get to after the conference itself.
MMCONFs are added in table MMCONF:
TABLE: MMCONF
>lis
TOP
LKEY SNPA NNX DEFGDIGS LSCOMB DID DIDORIG ACALLOW SIZE
CONFTYPE OPTIONS
------------------------------------------------------------------------
SHADYTEL 0 222 563 1006 0 Y Y N 6
STD $
This MMCONF is the STD type with the DN that is listed. We allow calls from outside the customer group to not only participate in (DID), but even start the conference (DIDORIG). Since we've only defined one 6 port conference circuit, I stayed with a maximum size of 6 for now.
The LSCOMB parameter of the MMCONF refers to table LSCFLAGS. Each entry in LSCFLAGS allows us to allow only calls with the correct LSC set. For now, we'll set one entry up to allow everything. If you don't have this set properly, the calls will be screened and the MMCONF will give BUSY as treatment (which is odd, as I personally feel that's more of a RODR type of condition than BUSY).
KEY LSCFLAGL
----------------------------------------------------------------------------
0 (B0) (B1) (B2) (B3) (B4) (B5) (B6) (B7) (B8) (B9) (B10) (B11) (B12)
(B13) (B14) (B15) (B16) (B17) (B18) (B19) (B20) (B21) (B22) (B23)
(B24) (B25) (B26) (B27) (B28) (B29) (B30) (B31) $
At this point, our MMCONF can be used.
With a customer group created, we can finish setting up the group to support telephone sets as well. Since sets in customer groups use customer translators, we'll have to set one up and assign it for the group.
Translators are first created in XLANAME:
XLANAME
DEFAULT
MAXDIG
----------------------------------------------------------------------------
STXLA
$
9
We create the translator STXLA for ShadyTel Translator, use no default selector, and our maximum digit is 9 (other options have to do with using the ABCD digits as part of the dialplan).
We'll have to add our new translator to the customer group as well in CUSTHEAD:
CUSTNAME CUSTXLA DGCOLNM IDIGCOL
OPTIONS
----------------------------------------------------------------------------
SHADYTEL STXLA NDGT NIL
( VACTRMT 0) ( EXTNCOS 0) ( SUPERCNF )$
And then we'll need to define our translator in IBNXLA:
KEY
RESULT
----------------------------------------------------------------------------
STXLA 10
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 11
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 120
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 121
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1220
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1221
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1222
NET N N 0 N POTS N Y DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1223
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1224
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1225
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1226
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1227
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1228
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 1229
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 123
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 124
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 125
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 126
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 127
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 128
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 129
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 13
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 14
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 15
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 16
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 17
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 18
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
STXLA 19
NET N N 0 N POTS N N DOD N 0 222_POTS_0 NLCA_NILLA_0 NONE $
[need to work on this more]
We'll also need to define at least one NCOS. I'll be defining two since there is also a default NCOS that gets specified for originators external to the customer group. NCOS 0 will be used for the default unprivileged calls while NCOS 1 will be the standard for in-group originators.
CUSTGRP NCOS NCOSNAME LSC TRAFSNO OPTIONS
----------------------------------------------------------------------------
SHADYTEL 0 NCOS0 1 0 $
At this point, we can create a line with the IBN line class in SERVORD. Because I have limited pair count from the DMS to the house, I'll have to move one of my 1FRs and create the IBN on the now-unused pair. For reference, you can move LENs with the 'CLN' command (change-LEN).
We can restrict MMCONF to disallow callers from outside the customer group from starting the conference (DIDORIG) or joining at all (DID). This means that lines outside the customer group and trunk calls that enter through means other than the IBN translations for the customer group will be considered to be outside the group and disallowed access as configured.
LKEY SNPA NNX DEFGDIGS LSCOMB DID DIDORIG ACALLOW SIZE
CONFTYPE OPTIONS
------------------------------------------------------------------------
SHADYTEL 1 222 563 1008 0 N N N 30
STD $
Trunk calls can also be directed into the customer group by having them use the IBN translations. We can either do this globally for all calls on a given trunk, or we can split them up based on some different means. In any case, this is controlled back in the LTCALLS table.
Normally the DMS supports use of the Network Specific Facility message in conjunction with the ISDN Number Plan Indicator (NPI) to specify different call types to be routed differently. My Cisco ISR does not support NSF IE, but we can take advantage of the private NPI. I will route private type calls through the IBN translations, and this will make those calls treated as in-group calls. On the cisco end, I will make sure that calls which should classify as in-group calls get the private NPI, and calls which do not get a public NPI (like 'ISDN' or 'public'). In any case, the tuple for private routing is added in LTCALLS:
LTID XLARTSEL
OPTIONS
----------------------------------------------------------------------------
PRI 1 PVT XLAIBN 0 222_POTS_0 NLCA_NILLA_0 SHADYTEL 0 0
$
Note that the XLAIBN option for XLARTE specifies both a line class code to enter the national translations as well as a customer group for private translations. As best as I can tell, it is possible, with NSF, to designate a call as private in the NSF but use a public NPI, and that can cause the normal national translations to be used (but that won't apply here, because I will not be using NSF).
It's also worth noting that the supported NSF and NPI combinations vary by ISDN signaling types. For this to work, I had to switch from NI-2 to the SL1PROFL which uses the NTNAPRI variant, which I believe is sort of a DMS-100 specific ISDN variant (which may predate NI-2).
For future reference:
2024/01/19 14:27:55 <@joe_z> for my future reference: the left-most AC circuit has a 7.7A draw and 875W
2024/01/20 15:05:47 * joe_z notes for his future reference, 864W on the middle outlet
2024/01/21 16:44:36 <@joe_z> OK, for my future reference again, turning on the DMS now
2024/01/21 16:49:53 <@joe_z> and the rightmost outlet is doing 888W, 8.21A
2024/01/22 17:47:09 <@joe_z> for my future ref, 906W/7.65A on the leftmost outlet in the garage
2024/01/23 17:02 <@joe_z> for my ref. the center outlet is drawing 875W, 7.70A
2024/01/23 17:02 <@joe_z> may have to update that later if I get the 1X67s moved over into the ISM shelf
19:01 <@joe_z> rightmost outlet drawing 888W and 7.77A
08:44 < joe_z> 922W and 7.89A on the leftmost outlet |