Lucent Technologies 555-661-150 User Manual

Issue 1

August 1998

Call-Handling Scenarios 

Page 2-54

Network Configuration Scenarios 

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.