Telex 38109-977 Intercom System User Manual


 
Chapter 5 - Design of Matrix Intercom Systems 75
“Great” you say, “Why not always trunk and avoid HUGE matrices?” I’m glad you asked
that question.
First, there is what I refer to as the “Mother’s Day Syndrome.” Mother’s Day rolls around,
and all good sons and daughters decide to call their dear, sweet mom and wish her the best,
and many of them don’t get through. They hear a nice recording of someone saying, “All
circuits are busy, please try your call again later.” If you think about it, you have probably
gotten that message a few times in your life when calling long distance, and never when
calling someone down the block. This is because local calls (large metropolitan areas
excluded) go through a single matrix (single central office), and there is a dedicated
crosspoint (or a close equivalent) for each path. You get the message when calling long
distance because there are a limited, finite number of long distance trunks available, and
the heavy traffic volume keeps all of them busy at times.
Looking at the last example, imagine what would happen when the first person from
Matrix A calls someone in Matrix B, Trunk A (or B) gets assigned, and life is good. A
second person (maybe from B calling A this time) initiates a call, the other trunk is
assigned and life is good. Now a third person in Matrix A decides to try to call someone in
Matrix B. Oops, “All circuits are busy, please try your call again later.”
In actuality, no voice is heard, but the calling party does get a busy indication on their
panel, and the call does not go through. Therefore, we can see that trunking systems need
to be sized appropriately for the anticipated traffic. Appropriately is the key. The
Telephone Company (actually “companies” in the post-AT&T breakup era) set aside
enough trunks to handle all of the traffic most of the time – sounds suspiciously like “You
can fool all the people some of the time,” doesn’t it?
Telex
®
Intelligent Trunking shares something else in common with the telephone
company, the trunk master continuously monitors and reports on status of trunk utilization.
The telephone companies do it in great “war rooms” with multi-story maps with lighted
paths. Telex does it with a constantly updated and logged report of trunk utilization on a
conventional PC. It keeps track of (amongst other things) the maximum number of trunks
you use simultaneously in the past x amount of time. With good historical data, you can
determine the number of trunks you set aside for trunking.
However clever you think you are in setting aside trunks, there will always exist the
unforeseen possibility that you may run out of trunks at some point.
For example, you have two studios, trunked together with five trunks, and in the past year
have never used more than four at one time. Today, both studios are manned, and in Studio
B is a news program being directed by Steven Spielberg, produced by George Lucas, with
Tom Brokaw interviewing Madonna and Jerry Falwell (it could happen!). Studio A is busy
doing a documentary on the history of dental appliances in South America. Care to take a
guess how many of the crew in studio A will decide to listen in to the director, producer,
talent IFB, program audio, cameras from B? All at the same time? Know what’ll happen?
Yep, “All circuits are busy, please try your call again later.”
The other significant limitation may be for each trunk you assign (which requires a port),
you give up a port that be used for two keypanels (one at each matrix). Make your system
too long distance “friendly” by allocating a lot of ports as trunks, and you either limit the
number of keypanels on each matrix or spend more money to buy additional ports for each
matrix.
All of these limitations aside, trunking can be a very good solution for many applications.
Trunking works best when limited numbers of trunks are required to support occasional
usage. Trunking works very well when many matrices need to be interconnected. As noted
earlier, Telex
®
Intelligent Trunking can simultaneously handle automated routing between
more than 30 matrices. A side benefit of such a multiple matrix trunked system is that the
trunk master can figure out and establish trunk paths via multiple hops if needed due to
trunk usage. If the trunks from Matrix A to B (see Figure 5.8) are all in use, the possibility