Filter
Top Products
MERLIN LEGEND Communications System Release 6.1
Network Reference
555-661-150
Issue 1
August 1998
Call-Handling Scenarios
Page 2-54Network Configuration Scenarios
2
Intersystem Calling 2
This topic illustrates how different types of calls are made and received in
Scenario 2, using the extension numbers and extension equipment types shown
in Figure 2–3 on page 2–45
.
Table 2–12, page 2-55
shows how calls are made and displayed at different
recipients’ extensions within the private network. Notice that because the systems
are connected by tandem tie trunks, calls from non-local extensions display as
outside calls at recipients’ extensions. For the centralized VMS/AA, this means
that all calls are treated as outside calls and the centralized VMS/AA cannot
provide different call handling and/or greetings based on the type of call. Contrast
this display with those in Scenario 1, Table 2–5, page 2-30
.
Notice that because intersystem calls are made on tie trunks, transfers to non-
local extensions do not return when the intended destination is busy or has Do
Not Disturb activated, and no coverage is available. For Release 6.1 or later
systems, when the automated attendant transfers a call to a non-local system,
and the call is not answered within the fixed transfer redirect timeout (32
seconds), the call will stop ringing at the remote destination and be redirected to
the extension on the transferring system programmed to receive redirected calls.
This can be the first QCC queue, another extension, or an available calling group.
Refer to the Programming Guide, “Redirect Outside Calls to Unassigned
Extension Numbers” for details.
When Night Service is activated at System D, all calls route to the centralized
VMS/AA on System C. The centralized VMS/AA offers customers the choice of
leaving a general message for the customer service representative group or a
message in an individual mailbox. Because of the time difference, the recorded
messages must be carefully selected.
When a caller leaves a message for an extension on System D, Message Waiting
light updates are sent over tie trunks in this private network. The updates are sent
in-band as part of intersystem calls.
If all tie trunks are busy, when Message Waiting light updates are attempted, the
updates are queued in the Message Waiting light queue behind any other earlier
queued updates. All queued Message Waiting light updates are retained on the
central system until a tandem T1-emulated tie trunk is available. Up to 1499
messages can be queued in the Message Waiting light queue. This may cause a
delay in Message Waiting light update.