MERLIN LEGEND Communications System Release 6.1

Issue 1

Network Reference 555-661-150

August 1998

2 Call-Handling Scenarios

 

Network Configuration Scenarios

Page 2-54

 

 

Intersystem Calling

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.

Page 112
Image 112
Lucent Technologies 555-661-150 manual Intersystem Calling