April

Transcription

1 Intecom Systems Feature Transparency Application Manual April MPANY PROPRIETARY STATEMENT All information contained herein is considered company proprietary and is restricted solely to assist in the support of the Intecom systems. This information includes only the product changes prior to the release date of this document. Neither this document nor the contents may be disclosed, copied, revealed or used in whole or part for any other purpose without the prior written permission of Intecom. This document must be returned upon request of Intecom.

2 PREFACE This document is to be used by Support, Administrative and Planning Personnel. The document is organized in accordance with the approved outline established by Intecom. The information contained in this document may change without notice. Any recommended changes, improvements, additions or modifications to this document should be directed to: Intecom Product Documentation M/S 3A, Liberty Plaza II, 5057 Keller Springs Road Dallas, TX Second Edition, April 1994 This edition of the Feature Transparency Application Manual may only be used for the purpose as stated in the preface. Updates, changes, or revisions of this document may be published as information becomes available. Copyright 1994, All Rights Reserved, Intecom. Printed in the U.S.A.

3 TABLE OF CONTENTS Title Page 1.0 INTRODUCTION Single Partition INTECOM SYSTEMS CONFIGURATION... 3 Figure 1. Single Partition Intecom System Trunks and Links... 3 Figure 2. Trunk Configuration Example... 4 Figure 3. Link Configuration Example Multiple Partition System... 7 Figure 4. Single Intecom System, Two Collocated Partitions Single-Partition to Remote Switching Partition (RSP)... 9 Figure 5. Single-Partition System to RSP with IXL-21 Links... 9 Figure 6. Single-Partition System to RSP with Analog Links Multiple Intecom System Network Figure 7. Multi-Intecom System Network with IXL-21 Trunks Figure 8. Multi-Intecom System Network with Analog or T1 Trunks Single Intecom System/Multi-Partition with Trunks Figure 9. Single Intecom System/Multi-Partition with IXL-21 Trunks Primary Rate Interface (PRI) Interface IXL FEATURE TRANSPARENCY CAPABILITY i

4 THIS PAGE HAS BEEN INTENTIONALLY LEFT BLANK. ii

5 1.0 INTRODUCTION The term "Feature Transparency" refers to the perception that a feature or group of features operate (or appear) the same, whether the parties involved are all on a single Intecom System partition, on various partitions of a single Intecom System, or are on two or more Intecom Systems in a multi-switch environment. The differences and limitations of feature transparency depend upon the exact configuration and the specific features concerned. In defining feature transparency it is important to note the point of view from which the features are transparent: The individual user in the everyday work environment The Telecommunications Manager Decision Maker for the Purchase (Cost of transparency versus another configuration that may be less) This document reflects Intecom software Version V10 operation. 1

6 THIS PAGE HAS BEEN INTENTIONALLY LEFT BLANK. 2

7 2.0 INTECOM SYSTEMS CONFIGURATION 2.1 Single Partition When all concerned parties of a voice or data call are within a single partition on the same single Intecom System, there are no special restrictions to feature transparency. Any features may be invoked by any party (as described in Intecom documentation). Full feature transparency is achieved as a natural capability for single partition Intecom Systems. This includes a fully non-blocking switching matrix. SYSTEM #1 PARTITION 0 MCU #1 2.2 Trunks and Links Figure 1. Single Partition Intecom System Trunks and links are significant to a discussion of feature transparency. defined: Trunks First, each is A trunk is a single or multi-channel medium between terminal facilities. On the Intecom System, each end of a trunk circuit is controlled by a unique separate processor (Master Control Unit (MCU) -- whether apparent or actual). A trunk can be used to connect two switches. A link is a single or multi-channel medium between terminal facilities in which both ends of a circuit are under the control of a single MCU. The MCU is also aware of this fact. A link connects two partitions of a single Intecom System. Each end of a trunk is independently controlled and separately defined in the Intecom System database. When a trunk is used to connect two Systems, the port representing each end of the trunk circuit must be individually and uniquely defined in the database. A trunk may be an analog circuit, such as 4-wire E&M, a Tl circuit emulating an analog trunk, or an Inter-Exchange Link (IXL) configured as a trunk. The key difference is that when an analog or T1 circuit is used, the Intecom System must use modem pooling to make circuit switched data calls between two 3

8 switches or partitions. When modem pooling is involved, high speed sync data and LANmark cannot be accommodated between the two ends. If a trunk is used, there is a certain signaling protocol that must be used for the originating end to notify the other (terminating) end that a call is being initiated. The other end is responsible for adhering to that protocol to accept and process the call. For example: System #1 seizes, System #2 winks, System #1 sends digits, System #2 seizes at answer. When the trunk between two systems or between two partitions is an IXL trunk, any data communication that is possible intra-switch (single partition), such as high speed sync data or LANmark packet data may be passed between these two points without the need of modem pooling. The signaling protocol used by the IXL is an Intecom proprietary protocol, which the MCU(s) must adhere to in setting up, maintaining and ending a call successfully. MCU SYSTEM #1 PARTITION 0 IXL PORT IXL-21 TRUNK (NOT A LINK) SYSTEM #2 PARTITION 1 IXL PORT MCU Figure 2. Trunk Configuration Example To further clarify the application of trunks, the following example demonstrates how two Intecom Systems are connected by a trunk (see Figure 2). In this case, port in System 1 is defined (in database) as an individual port having no relationship to port in System 2. The two ports are physically connected using hardware. It is necessary to have a signaling protocol over this trunk so that the originating System can convey call setup information to the far end. When the MCU seizes outbound on port in System 1, the other MCU sees an inbound seizure on port in System 2. Two CDR records will result for what was one call. The individual steps of a call sequence occur like this: 1. The MCU directs that System 1 use trunk port Over the common signaling channel for the affected IXL buffer, the MCU sends a "seize" and the destination directory number to the far end system. 4

9 2. Trunk port on System 2 receives a "seize" and the destination number digits. It identifies the number as a voice line appearing on a System 2 station. The MCU in System 2 initiates ringing of the System 2 station. 3. In System 1, once digit outpulsing is complete, the MCU directs that the System 1 station is to be 2-way connected to trunk port When the System 2 station answers, the MCU directs that the destination station be 2-way connected to trunk port System 2 also sends an answer to System 1 over the IXL common signaling channel and System 1 records the time of answer in CDR. 5. The call is now active. Two CDR records are generated: one station to trunk (for System 1) and another trunk to station record (for System 2). Links As mentioned before, a link is similar to a trunk, except that both ends are under the control of a single MCU. When an IXL is used as a link, no signaling protocol is used. The IXL circuit is used as a medium to connect both the originating and terminating facility. The MCU "knows" about both ends of the link, so it doesn't have to tell itself that a call is coming in on the link. The link (IXL or Analog) is not "reserved" in software for the call, until the destination station answers. An IXL link may transport either voice or any type of data (including LANmark and high speed sync circuit switched data). A link cannot be used to connect two Intecom Systems, because two MCUs would control the link. A link may be an analog circuit or T1. Only voice calls may use analog or T1 links to connect a voice facility of one partition to a voice facility of another (Data calls cannot use these links). The link is used as a way to connect the facilities in the two partitions. In Figure 3, Partition 0 and Partition 1 of an Intecom System are connected by an IXL link. In this particular example, only one channel of a 21 channel IXL buffer is depicted. The ends are identified as port in Partition 0 and port in Partition 1. Since this IXL channel is a link, the MCU database identifies these 2 ports as having a specific relationship: port is "Master;" port is "Slave." This "linkage" is established in order for the MCU to know which two ports are opposite ends of the same link. When the MCU connects a station to port in Partition 0, it knows that it must connect the destination station in Partition 1 to port to complete the connection. These ports are physically connected by hardware. 5

10 MCU SYSTEM #1 PARTITION 0 IXL PORT IXL-21 LINK (NOT A TRUNK) SYSTEM #1 RSP PARTITION 1 IXL PORT Figure 3. Link Configuration Example The individual steps of a call sequence might happen like this: 1. A station on Partition 0 dials a directory number, which the MCU translates as being a voice line. 2. The MCU determines that this voice line appears on a station in Partition 1. The MCU directs that the Partition 1 station is to receive ringing. 3. The Partition 1 ringing station is answered. 4. At this time the MCU checks for an idle link to connect the two stations. It determines that "master" link port is available. 5. The MCU directs that the Partition 0 station is to be 2-way connected to port in Partition The MCU then determines by the "master - slave" relationship, that the Partition 1 corresponding link port is Since the "master" port is available, the "slave" port is also automatically available. The MCU directs that the Partition 1 station is to be 2-way connected to port The call is now connected and active. Four ports are involved: two station ports and two ports that constitute the IXL link. 6

11 2.3 Multiple Partition System Full feature transparency is possible if the Multiple Partition System is properly configured. The two partitions are connected by IXL-31 links (not trunks). A single MCU controls both partitions and is fully "aware" of all instruments and trunks in both partitions. A system may also have remote partitions connected by an IXL-21. Note: A multiple partition collocated system is not a typical configuration for a switching system. The only occurrence of this would be in an S/80+ System. It is discussed here for completeness of subject matter. Figure 4 shows a typical system configuration. This configuration is feature transparent, but there are some issues and limitations that require discussion. The system has two partitions. Each partition must be connected so that users on Partition 0 can communicate to users on Partition 1. A normal configuration includes a large number of IXL-31 link channels, which allow two partitions to exchange voice and user data. The system may not be considered fully non-blocking, unless exactly one half of the users are on each partition and one half of all ports are dedicated to IXL links between these two partitions. A configuration like the one mentioned is not practical and is rarely if ever used. It is only used as an example for discussion. This may be of concern either to a system purchaser or telecommunications manager. Since a single partition is fully non-blocking, a blocking multi-partition system may not be viewed by some customers as "feature transparent." IXL-31 LINKS SYSTEM #1 PARTITION 0 MCU SYSTEM #1 PARTITION 1 Figure 4. Single Intecom System, Two Collocated Partitions 7

12 Since the Intecom System assigns resources (such as DTMF receivers and conference bridges) based on user originating partition number, how the telecommunications manager configures the system may become critical. For example, all DTMF receivers are in a single partition (Partition 0). When users on Partition 1 go off-hook, the system will use an IXL-31 link channel (from Partition 1 to Partition 0) to connect an STE or DTMF trunk to a receiver on Partition 0. Although this will enable the telecommunications manager to configure and allocate receivers on a system-wide basis, IXL-31 link channels will be used for actual voice and data calls and for call setup as well. Likewise, if the telecommunications manager configures a system such that all conference bridges are on Partition 0, when six users on Partition 1 participate in the same conference call an IXL-31 link channel will be used to connect each user on Partition 1 to a conference bridge port on Partition 0. Although this enables the manager to predict conference bridge requirements on a system-wide basis, this configuration adversely affects the traffic engineering of IXL-31 link channels between partitions. On the other hand, if a system is configured so that shared resources such as conference bridges and DTMF receivers are allocated per partition (not shared across partitions) the number of IXL-31 links can be reduced. This will allow the total number of user devices (stations, trunks, ATDCs, etc. ) that wish to communicate between partitions to be accommodated. The number of links can be reduced to below one quarter of the total system time slots, because a portion of each partition's time slots are used by shared devices. These devices will not need to be connected to another partition; they are shared within the partition. If half of all timeslots are dedicated to IXL-31 link channels, the number of IXL-31 link channels between the two partitions equals one quarter of all available system timeslots (two timeslots per link), then the prior situations are not a problem. Enough IXL-31 channels will be available to permit a fully non-blocking architecture between the two partitions. The engineering and purchase of the IXL-31 channels may not be critical for the system, since the two partitions are collocated. In this configuration, there is not a great distance to traverse with an IXL-31 (a matter of feet), and the right-of-way is not an issue. In any multi-partition Intecom System, Classic LANmark requires a LANmark loader for each partition. Also, services provided by the IDB and by MKO must be provided by partition resident devices. Therefore, the system may have some additional configuration requirements (Check with Intecom configuration for further specifics). Overall, a multi-partition system is fully feature transparent, relative to the capabilities of a single partition system. The only limitation that may be encountered, depending upon actual physical configuration (number of IXL channels), is that a multi-partition system may not be 100 percent non-blocking. Otherwise, all features and capabilities, including data (async, sync, LANmark, etc.) are available. 8

13 2.4 Single-Partition to Remote Switching Partition (RSP) In a single-partition configuration with an RSP (Remote Switching Partition) involved, an IXL-21 link may be used to connect the two partitions to provide both voice and data connectivity (Figure 5). If voice only connections are to be provided between the two partitions, then an analog circuit link such as 4-wire E&M or T1 may be used (Figure 6). Since the distance between the two partitions may now be measured in miles instead of feet, issues of cost and right-of-way (for links used between partitions) can be of critical importance. In addition, the inter-switch link routing database can become very complex, if the system has multiple partitions (more than 2). Increasing the number of partitions increases the likelihood of blocking between partitions, unless the links are engineered and configured for the absolute maximum potential traffic that can pass from one partition to another. MCU #1 SYSTEM #1 PARTITION 0 IXL-21 LINK (NOT A TRUNK) SYSTEM #1 RSP PARTITION #1 Figure 5. Single-Partition System to RSP with IXL-21 Links 9

14 MCU #1 SYSTEM #1 PARTITION 0 ANALOG (4W E&M) LINK or T1 (4W E&M) LINK SYSTEM #1 RSP PARTITION #1 Figure 6. Single-Partition System to RSP with Analog Links Feature transparency for a single-partition configuration with an RSP connected with IXL links, is essentially the same as the multi-partition configuration discussed previously. The same restrictions apply to this configuration. Note: A multi-partition system may also have a remote partition connected with links (T1, 4W E&M or IXL-21). However, if this configuration is implemented with analog 4W E&M or T1 links, the major restriction is that partitions are only feature transparent for voice features. Modem pooling is not used for analog links, and data cannot be passed between the two partitions. Analog links are used solely to provide connectivity between voice facilities on the two partitions. 10

15 2.5 Multiple Intecom System Network A multi-switch Intecom System network (separate switches with separate MCUs) will have the same capabilities and limitations as a Single MCU/Multi-Partition System where the partitions are connected by trunks, either IXL-21, analog, or digital T1 trunks (refer to Section 2.6) The only real difference in this configuration is that instead of a multiple partition database being manipulated by one MCU, the various databases are administered separately by their own MCUs. Figure 7 depicts two single-partition systems connected by IXL-21 trunks (between system links are not possible). Not only are separate MCUs involved, but two unique and separate databases are involved. This naturally implies that System #1 cannot be aware of System #2 facilities, stations, status, etc. There is no way this configuration can be considered feature transparent, unless the IXL Feature Transparency option is used. MCU #1 SYSTEM #1 PARTITION 0 IXL-21 TRUNK (CANNOT BE A LINK) SYSTEM #2 PARTITION 0 MCU #2 Figure 7. Multi-Intecom System Network with IXL-21 Trunks When an IXL-21 is used as a trunk, the system can handle data as well as voice, including LANmark and high speed sync circuit switched data without modems. Figure 8 depicts a multi-switch system network using analog/tl trunks to connect two switches. In this configuration, circuit-switched data can be passed between the two systems by modem pooling. However, high speed sync data and LANmark packet data cannot be used. IXL Feature Transparency is not available between two switches connected by analog or T1 trunks. This feature is available only using IXL trunks. 11

16 MCU #1 SYSTEM #1 PARTITION 0 ANALOG OR T1 TRUNK (CANNOT BE A LINK) SYSTEM #2 PARTITION 0 MCU #2 Figure 8. Multi-Intecom System Network with Analog or T1 Trunks The following is a discussion of the trunk limitations in a multi-switch Intecom System network: (a) Station Access The set of voice lines used on the various Intecom Systems of the network must be unique to that system on which the stations reside. The same voice line cannot appear on two stations of two different switches. When a trunk is used to connect the two switching systems, the MCUs will not know how to connect the systems, unless a trunk destination call is specifically invoked. System #1 will not know the status or nature of, or be able to control stations on System #2. (b) Trunk Destination Routing Database administration is effected by this configuration in the area of Trunk Destination Routing. Calls that originate from System #2 must be directed to trunk groups that have ports originating on System #2. Likewise, System #1 must direct calls to its own trunk groups. For System #1 to direct its trunk destination calls to trunk groups on System #2, it must select a trunk group connecting to System #2 and outpulse the proper destination number. In this manner System #2 can correctly route the call. However, once the call is routed to System #2, System #1 cannot "back off" or re-route the call over its alternate trunk groups, if System #2 cannot successfully route the call. 12

17 (c) ITE/ATDC Displays ITE/ATDC Displays will not show name or number display across Intecom Systems, except for those capabilities provided by IXL Feature Transparency. (d) Busy Override The Busy Override feature is available across Intecom Systems using Software Release V and only with IXL feature transparency. (e) Buzz/Station Status This feature is not available across Intecom Systems. Line appearances cannot cross switch boundaries. (f) Callback Busy/Recall Callback Busy Recall is not available across Intecom Systems, except as provided by IXL Feature Transparency. (g) Callback Message Waiting Callback Message Waiting is not available across Intecom Systems, except as noted in the IXL Feature Transparency section. (h) Call Forwarding, All/Busy/No Answer Call Forwarding, All/Busy/No Answer is not truly feature transparent. The mechanism to limit the number of forwards to 16 is bypassed. Each time the call is handled over a new trunk, it is viewed by that MCU as a new call that has no bearing or relationship to the previous "iterations" of the call within that Intecom System. The call forward count is "lost" each time the call goes over a trunk. The only exception to this is when a call uses IXL trunks between Intecom Systems, each MCU will pass the IXL Hop Count to the next MCU over the IXL trunk common signaling channel. When this count indicates that 6 IXL tie trunks have been involved in the call, no further route advance to IXL trunks will be permitted. The purpose of this feature is to eliminate the potential for network "ring-around-the-rosy" switch to switch routing. (i) Call Park Call Park does work across Intecom Systems. The only caveat is that System #1 directory numbers, including call park channel directory numbers, must be defined as Satellite 13

18 Directory Numbers (SDN) in System #2 (for System #2 to know that a trunk must be used to access the number on System #1). (j) Call Pick-Up Call Pick-up does not work across Intecom Systems connected by trunks. This is for the same reason delineated in (a): the same voice line cannot appear on stations of different Systems. Trunks themselves are unable to exercise Call Pick-up, because this is a line feature. Trunks do not have the line capability to belong to a call pick-up group. (k) Conferencing Ordinarily, any party involved in a conference (except a trunk) can bring in additional parties. A station on System #1 can conference another System #1 station and a System #2 station (across a trunk). However, if that System #2 station brings in another System #2 station, an additional conference bridge will be used on System #2 (to conference the two System #2 stations). If this operation is performed across enough switching systems, the quality of the voice transmission will be degraded, perhaps to an unacceptable level. Also, the Hotline Conference feature will not work across trunks. A Hotline Conference can only include stations as conferees. (1) Intercom Groups This feature is not available across Intecom Systems. Line appearances cannot cross switch boundaries. (m) Group Listen Group Listen has the same restrictions as Conference. (n) Privacy Release and Auto Privacy Release Privacy Release and Auto Privacy Release functionality is restricted to those users within a switching system. Voice lines cannot be shared across Systems. (o) Transfer The Transfer feature is effected by this configuration. If a station on System #1 calls a station on System #2 and then transfers the call to another station on System #2, two trunks will be used to complete this call. These two trunks will still be in use when the transferring station on System #1 drops out of the call. When the transferring station on System #1 selects transfer, the System #1 inbound trunk port is transferred (not the System #2 station). This will negatively affect the usage and traffic engineering of the inter-switching system trunk groups, because trunks will be used to connect callers (even when both are on the same system). Therefore (from the view of the telecommunications 14

19 manager), Transfer may not be considered feature transparent in this configuration. However, the IXL Feature Transparency Remote Transfer option can be used to avoid this limitation. (p) Multiple Appearance Directory Numbers As previously noted, multiple appearance directory numbers cannot cross Intecom System boundaries. One MCU cannot be aware of the nature or status of and cannot control stations on another system. (q) Attendant Operation Multi-switching system networks have a negative effect on ATTENDANT OPERATION. Because of the inefficient use of trunks (related in item <o>), the display limitations (discussed in <c>), and the general lack of feature transparency in this configuration, careful consideration is needed in looking at ATDC operation. The Intecom System supports the Centralized Attendant Service (CAS) on the main switching partition, but not on Satellite Switching Partitions. So there is no feature transparency between the two. The ATDC Remote Call Forward feature is effected because the ATDC cannot remote call forward voice lines that are not on the same system. All the ATDC positions for a given ATDC group must be on the same system. The ATDC Monitor function is not transparent because lines cannot be shared. (r) Inside/Outside Ring (For Originating Trunk Groups) Inside and Outside Ring for originating trunk groups is effected. When a System #2 trunk calls a station on System #1 (over an IXL trunk), the destination System (#1) applies ring to the destination station, according to the second system's IXL trunk group database marking (internal or external). However, if the same call is placed from a System #2 station, the IXL trunk protocol provides for informing System #1 that the ultimate originator is a station. The destination station receives an inside ring. Similar rules apply to Internal/External Call Forwarding. There are some enhancements to this feature in IXL Feature Transparency. If two systems are connected by analog or T1 trunks, then the destination system ring treatment cannot be passed from switch to switch. The far end ring type is always based on the destination system inbound trunk group database marking (internal or external). (s) Call Detail Recording (CDR) Call Detail Recording is effected by this configuration. A call is considered a new call each time it crosses a trunk to access another switch. Each time that a call leaves an 15

20 Intecom System by a trunk, a new CDR record will be generated by that MCU. If a station calls a directory number that is resident on another System, generates two CDR records: one Station-to-Trunk and one Trunk-to-Station. This complicates billing somewhat because two CDR records will exist for what might be considered one call. (t) Shared Resources Separate Intecom Systems also require that shared resources such as conference bridges and DTMF receivers be physically allocated per system. This may increase the total number of such devices required (versus a single, large system) to support the total number of users, since one system's shared resources cannot be used by stations of another system. (u) Authorization Codes Authorization Codes are not transparent across Intecom Systems. Inbound trunk origination causes call processing to use the originating trunk Class of Service (CLOS) and User Group (UGRP). The switching system does not pass dialed Authorization Codes over trunks. All calls that are routed over a common trunk will be treated the same on the far end, since all calls will end up using the far end port CLOS and UGRP. Therefore, an Authorization Code used within System #1 will not affect routing of the call in the System #2. (With the IXL Feature Transparency option, dialed Authorization Codes are sent for CDR purposes only). 16

21 2.6 Single Intecom System/Multi-Partition with Trunks The following example is not a typical configuration. It is described to completely explain feature transparency. Figure 9 is an Intecom System with two partitions connected by IXL-21 trunks. This configuration is truly not feature transparent (if the IXL Feature Transparency option is not used). Since the two partitions are connected by a trunk, it appears that the two partitions were controlled by two entirely separate MCU's - although the same MCU is in control of both partitions. In this configuration, the MCU does not "know" and is not "aware" that the two ports defining the ends of the trunk are part of the same entity. To the MCU, the two ports comprising the trunk are not related, but are independent facilities. For this reason, whenever the MCU seizes outbound on the trunk port from Partition 0 toward Partition 1, the inbound seizure on Partition 1 is treated as a separate, unique call unrelated to the original outbound seizure. The fact that calls from Partition 0 to Partition 1 (or vice versa) are handled over a trunk and are treated as two separate calls by the MCU, has extensive implications. Any call or feature that would ordinarily require the MCU know of all parties involved and/or which required the same MCU have direct control of all parties involved, will either not work at all or will at best, be degraded in this situation. The same limitations and restrictions exist for Multi-Intecom System networks as depicted in Figures 7 and 8. When an IXL-21 is used as a trunk, the system can handle data as well as voice, including LANmark and high speed circuit switched data, without modems being used for calls between partitions. MCU #1 SYSTEM #1 PARTITION 0 IXL-21 TRUNK (NOT A LINK) SYSTEM #1 RSP PARTITION #1 Figure 9. Single Intecom System/Multi-Partition with IXL-21 Trunks 17

22 THIS PAGE HAS BEEN INTENTIONALLY LEFT BLANK. 18

23 3.0 IXL FEATURE TRANSPARENCY CAPABILITY When two Intecom Systems are connected by IXL-21 trunks (or IXL-31 trunks for collocated Systems), IXL feature transparency is possible. IXL Feature Transparency addresses the following 9 capabilities: 1. The originating system will send the billable directory number to the destination system for inclusion in the destination system CDR record for the call. 2. The originating system sends the dialed authorization code to the destination system for inclusion in the destination system's CDR record for the call. This authorization code is only stored in the far end CDR record- it is not validated or used for routing purposes. 3. A user originating a call for a directory number that is on another system, may leave a Callback-Message Waiting on the destination line, whether that line is ringing or busy. The destination directory number may later exercise the callback feature to callback the originator on the first system (this requires a coordinated directory numbering plan, whereby each system has unique directory numbers). Also, to display the name of the callback party on the destination system, the directory name is required to be in the destination system's Directory Lookup System (DLS) database. 4. The originating system passes directory number and name display information to the destination system so that the called station or ATDC may see it displayed. If the originating facility on the first system is a trunk, then the originating system trunk group incoming message text is sent to the destination system to be used for display. 5. Ring and Call Forward-Internal/External: the originating system ring treatment, inside or outside, is sent to the destination system for proper handling of the call. An originating trunk's Internal/External database marking is also passed from system to system for proper handling of trunk originated calls for call forwarding. 6. Remote Transfer: the system will complete the transfer of a party on a remote system by passing the transfer request to the remote system that performs the transfer, thereby eliminating the unnecessary use of IXL trunks on such calls. 7. For OAI applications across IXL trunks, the identification of the originating system connected party is sent to the OAI application. 8. Feature transparency for Busy Override is provided with Intecom System Software Release V and above. 9. Feature transparency for Voice Mail Product (VMP) Networking is provided with Intecom System software release V9 and above. 19

24 Further detailed information of IXL Feature Transparency is available in other Intecom documentation. 3.1 Primary Rate Interface (PRI) Interface Feature transparency for the PRI is as described in previous statements, with the following exceptions: 1. Feature transparency for a data trunk or link requires an ISDN Date Rate Adapter (DRA) located on each side on the connecting Intecom System data device. 2. Feature transparency of Classic LANmark is not supported for PRI. 3. Feature transparency of Voice Mail Product (VMP) is not supported for PRI. 4. Feature transparency of Busy Override is not supported for PRI. 20

25 THIS PAGE HAS BEEN INTENTIONALLY LEFT BLANK. 21