SL-100 Web Log

Conference Circuits

January 25th-February 3rd, 2024

To support conference calls, the DMS-100 uses 3-port and 6-port conference circuits. The 3-port circuits are used for attendant consoles and 3-way calling and possibly some other features. The 6-port circuits are used for higher-count station controlled conferences as well as dial-in and attendant controlled conferences like meet-me conferences (MMCONF) and similar.

The conference circuit cards I have get installed in an MTM shelf. The ISM shelves in my MCAM cabinet fulfill that role, and MTMs are datafilled in table 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

I went over this table back when we set up the EDRAM. The only significant difference is that the location is just SHELF since, unlike the EDRAM, the ISM shelf is not a card that has a location inside another shelf.

With the new MTM datafilled, we need to put it's link to ENET into service in 'MAPCI;MTC;NET;SHELF 0;CARD 10' where we can 'BSY 0 LINK 0' and then 'RTS 0 LINK 0'. We then repeat for the other ENET plane as well.

We can then put the MTM itself in service in 'MAPCI;MTC;PM;POST MTM 0' followed by 'BSY', 'LOADPM', and then 'RTS'.

We're ready to provision the conference circuits now, but before we start, let's 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 two CLLIs are used for the conference circuits. I wasn't able to remove them on my switch, so I didn't have to create them again.

The main thing to look for is that TRKGRSIZ is large enough to contain all of the trunk member numbers noting that each 3 port conference is 3 members, and each 6 port is 6 members.

Obviously I have a lot fewer circuits than the switch originally did, so I won't need to adjust these numbers.

My conference circuit cards are NT3X67, which can optionally be provisioned as either 2 3-port circuits or 1 6-port circuit for each card. Datafill 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

• CNFCKTNO - Each circuit is assigned a unique number.
• GRPCLLI - Corresponds to the conference circuit group CLLI code.
• EXTRKNM - Trunk member base number. Each 3 port circuit takes up 3 sequential numbers. The data schema manuals suggests making these numbers multiples of 10.
• TMTYPE - The type of peripheral the card is installed in.
• TMNO - The number of the PM.
• TMCKTNO - The circuit number corresponding to the card slot the circuit is installed in. There is a diagram in the DMS-100 Family Quick Reference Guide based on what physical slot the card is installed in. Since the NT3X67 and NT1X31 have two 3-port circuits on a single card, each card is set up using two different circuit numbers. For the NT3X67, you use the 0th and 1st port, while for an NT1X31, you use the 0th and 3rd port.
• CARDCODE - Identifies the circuit card type.
• PADGRP - Sets the loss plan pad group for the conference circuit. The CONF pad group should be sane defaults for a conference.

With the datafill done, we can post the trunk group with 'MAPCI;MTC;TRKS;TTP;POST G CF3P'. Initially the conference trunks will be in the INB state. First we 'BSY ALL' and then 'RTS ALL' to place them in service. It is only OK to do it this way because we are starting from no existing circuits. If we had other circuits that already existed, we would need to ensure that we only 'BSY' the newly added circuits. We can do that by posting just the new circuits using e.g. 'POST G CF3P 10 TO 19' to post circuits 10 through 19.

We can now provision 3 way conferencing on some of our telephone lines. That option can be added using the 'ADO' command in SERVORD.

Next, we'll provision some 6 port circuits in CONF6PR. This process is fairly similar to the 3 port circuits, except that in this case one card is a single circuit rather than two.

It's also worth noting, when placing cards in the MTM shelf, that they must be physically spaced far enough apart so that they do not end up with overlapping circuit ranges.

CNFCKTNO EXTRKNM   TMTYPE    TMNO      TMCKTNO    CARDCODE PADGRP
-----------------------------------------------------------------
       0       0      MTM       0           18      3X67AA   CONF

This is the same format as CONF3PR except that there is no column for the CLLI as it is assumed to be CF6P.

Putting the cards into service is also done the same way, execpt we post the CF6P CLLI rather than the CF3P CLLI.

Using the 6 port conference circuits, we can provision an MMCONF. This also involves setting up a customer group, but I'll cover that in a later post. For the moment, I will cover some options needed in the customer group along the way, but gloss over the other details.

We can enable the SUPERCNF option in CUSTHEAD to allow larger conferences:

       CUSTNAME CUSTXLA DGCOLNM IDIGCOL
                                                                     OPTIONS
----------------------------------------------------------------------------
       SHADYTEL  PRAXLA    NDGT     NIL
                          (    VACTRMT  0) (    EXTNCOS   0) (   SUPERCNF )$

The MMCONF itself is datafilled in the table MMCONF (where it gets its name from).

              LKEY  SNPA  NNX DEFGDIGS LSCOMB  DID  DIDORIG ACALLOW SIZE
                    CONFTYPE                      OPTIONS
------------------------------------------------------------------------
       SHADYTEL  0   222  563     1006      0    Y        Y       N    6
                         STD                            $

• LKEY - Combination of the customer name and a conference number.
• SNPA/NNX/DEFGDIGS - The DN assigned to the conference.
• LSCOMB - Line screening code flag number. Used to screen who can enter the conference based on a screening flag set in LSCFLAGs.
• DID - Specifies if the conference is accessible from outside the customer group.
• DIDORIG - Specifies whether the conference can be initiated from outside the customer group.
• ACALLOW - Specifies if an attendant console is allowed to join or transfer calles to the conference.
• SIZE - Specifies the maximum number of simultaneous callers allowed in the conference.
• CONFTYPE - Chooses from a few different types of conferences. They mainly differ in how they can be controlled or managed by the participants.
• OPTIONS - Options related to network access registers.

We still have to configure an LSC flag set before we can use this conference. That is done in LSCFLAGS.

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) $

This table is pretty simple. Each entry defines whether a specific line screening code is allowed. If the code is present, it is allowed. If it is absent, the call is denied. The set shown above enables all calls by containing every possible line screening code (0 through 31).

At this point the conference is fully working.

When I initially got this working, I had some issues I was having with my conference circuits however. Conferences would work OK for a while, but after some time the calls would drop and the MTM would go out of service until it recovered. I didn't realize all of this at first, and the problem was exhibiting with popping noises like frame slip would produce, so I investigated clocking in depth thinking there was a trunking issue. At the time, I was using some Cisco CEM modules to transport T1 over IP and the clocking was not working perfectly so this felt like a very real possibility.

Eventually, I realized the trunk clocking was not the issue and began to look inside the switch.

I eventually realized the MTM itself was going out of service due to some issues, and began swapping parts trying to narrow down the cause. I swapped cards in the MTM, the ENET, changed ports, and I even tried switching message switch planes, but none of it solved the issues. At one point, all that was left to be the culprit was the MTM shelf and backplane assembly and the cable between the MTM and ENET. I moved the cards and tried a different shelf, but still the problems remained and all that was left was the cable.

After building a new cable and swapping to it, everything was working without any issues. Finally I looked at the bad cable and noticed that one of the wires inside the DB-25 connector shell had broken off from the pin it was soldered to completely. No continuity at all. Frankly, I don't know how it ever worked.

I repaired the cable and then it, too, was working I believe. It's just unfortunate that it took several days of troubleshooting until finally it was the only remaining part that could possibly be the issue for me to find it.