1、ITU-T RECUN*Q-3303 95 m 4862593 Ob35838 087 9 INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU INTELLIGENT NETWORK Q.1301 (1 0/95) TELECOMMUNICATION APPLICATIONS TASC ARCHITECTURE FOR SWITCHES AND COMPUTERS (TASC) - ITU-T Recommendation Q.1301 (Previously “
2、CCIlT Recommendation“) FOREWORD The ITU-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (IT). The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a view to standardiz
3、ing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WSC), which meets every four years, establishes the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Me
4、mbers of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12, 1993). ITU-T Recommendation 4.1301 was prepared by ITU-T Study Group 11 (1993-1996) and was approved under the WSC Resolution No. 1 procedure on the 17th of October 1995. NOTE In this Recommendat
5、ion, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. O ITU 1996 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, includi
6、ng photocopying and microfilm, without permission in writing from the IT. I ITU-T RECPIN*Qe3303 95 m 4862593 Ob15840 735 m CONTENTS Introduction Scope References Terms and Definitions 4.1 Abbreviations Architecture 5.1 Domains 5.1.1 Domain 5.1.2 Call views Call monitoring . i 6.1 Introduction 6.2 CE
7、 monitoring versus call monitoring 6.3 Call monitoring operation . TASC interfaces . 7.2 Multiple TASC interfaces . TASC switching model 7.1 Single TASC interface 8.1 8.2 8.3 8.4 TASC objects 8.1.1 Communication Entity 8.1.2 Line CE . 8.1.3 Distribution CE . Communication Party . 8.2.1 Description a
8、nd behaviour 8.2.2 Types . 8.2.3 Line CP . 8.2.4 Distribution CP . User . 8.3.1 Description and Behaviour . 8.3.2 Types . 8.3.3 Registered User . 8.3.4 Non-Registered User . Call View 8.4.1 Originating Call View . 8.4.2 Terminating Call View 8.4.3 Incoming Distribution Call View Call view states . 9
9、.1 9.1.1 Originating states 9.1.2 Terminating Call View States . 9.1.3 Incoming Distribution Call View Call View State descriptions . 9.1.4 Agent model Recommendation Q.1301 (10/95) Page 1 . 1 1 2 2 2 2 2 3 6 6 6 6 7 7 7 8 8 8 9 10 11 11 11 11 12 13 13 13 14 15 16 16 16 17 18 18 18 20 21 22 1 - ITU-
10、T RECMN*Q.L30L 95 II Y862591 Ob158Y1 671 = SUMMARY This Recommendation identifies the Architecture that supports TASC (Telecommunication Applications for Switches and Computers) and is one in the Q.130-Series Recommendations on TASC. The main purpose of TAX is to allow applications running within th
11、e network users environment to integrate telecommunication services with computing facilities. This would typically allow business applications to use TASC to integrate the computer workstation and telephone at the users desktop. This Recommendation does not define how the elements of the architectu
12、re are implemented. Part of the definition of the TASC architecture includes the TASC objects which are the basis for the TASC Functional Services. INTRODUCTION The concept of TASC, which this architecture supports, is described in Recommendation 4.1300, TASC Overview. Although the TAX architecture
13、identifies, describes and models interactions between the TASC objects, it does not specify how they should be implemented. In addition to call and telecommunication device objects, the role of Agents (as in ACD system) is modelled. BACKGROUND This Recommendation is based on the experience of ECMA (
14、Standardising Information and Communication Systems) and ANSI (American National Standards Institute) member companies in developing switch-to-computer intedaces and takes directions from CSTA (Computer Supported Telecommunications Application) and SCAI (Switch-to-Computer Application Interface) sta
15、ndards. KEYWORDS Architecture, Models, Objects, TASC. 11 Recommendation Q.1301 (10/95) ITU-T RECflN*Q-1301 95 48b2591 Ob15842 508 W Recommendation Q.1301 TELECOMMUNICATION APPLICATIONS FOR SWITCHES AND COMPUTERS (TASC) - TASC ARCHITECTURE (Geneva, 1995) 1 Introduction This Recommendation defines the
16、 architecture for TAX and identifies the various objects which represent information which the TASC interface operates on. The concept behind TASC is described in Recommendation Q.1300, which is considered essential reading prior to this Recommendation, and the services that the architecture support
17、s are defined in Recommendation Q. 1302. Recommendation Q. 1303 defines the requirements for managing the objects herein described. 2 Scope This Recommendation defines an architecture for the support of Telecommunication Applications of Switches and Computers. The architecture supports the communica
18、tion between the switch and computer and the services conveyed by that communication. This Recommendation considers how the information communicated is represented. TASC does not define how the aspects making up TASC in either the switch or computer environment are implemented. The emphasis of TASC
19、has been to define third-party call control functions which also encompasses first-party call control. TASC is independent of any underlying mechanism and is applicable to public, private and hybrid networks. TASC is designed to be flexible in order to support other communication environments in add
20、ition to those based upon ISDN and Intelligent Network (IN) principles. It is focused on providing an application service interface between a switch and computer. TASC supports both a single-ended call (originating and terminating) view as well as a global call view. The TASC architecture accommodat
21、es different ways of viewing calls available in implementations but models these views on stable and accepted modeis of how calls work. 3 References The following IT-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recomme
22、ndation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision: all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other refe
23、rences listed below. A list of the currently valid ITU-T Recommendations is regularly published. - IT-T Recommendation Q. 1300 (1995), Telecommunication Applications for Switches and Computers (TASC) - General overview. - IT-T Recommendation Q. 1302 (1995), Telecommunication Applications for Switche
24、s and Computers (TASC) - TASC Functional services. - IT-T Recommendation Q. 1303 (1995). Telecornmunication Applications for Switches and Computers (TASC) - TASC management: Architecture, methodology and requirements. Recommendation Q.1301 (10/95) 1 4 Terms and Definitions This Recommendation uses t
25、erms defined in Recommendation Q. 1300. , 4.1 Abbreviations For the purposes of this Recommendation, the following abbreviations are used: ACD CE CP cv FS ocv TASC TCV Automatic Call Distributor Communication Entity Communication Party Call View Functional Service Originating Call View Telecommunica
26、tion Applications for Switches and Computers Terminating Call View 5 Architecture The TASC Architecture provides a framework for communication between a computer and a switch. Recommendation Q. 1300 describes the environments in which TASC may be used. 5.1 Domains Domains identify the area that TASC
27、 may manipulate and influence. 5.1.1 Domain Call domains ultimately deal with controllable and visible telecommunication devices in TASCs problem space. Such devices are referred to as Communication Entities (CE) so as to avoid confusion with connotations of specific types of devices. 5.1.1.1 Contro
28、l and visibility TAX deals with the control and visibility of calls as they originate and terminate at CES. All TASC functions revolve around this fundamental principle. Therefore, the problem space involves calls which can originate, terminate, or become visible at CES. The CES defined by TASC incl
29、ude Line CES and Distribution CES. When dealing with a call the switch is transparent to the application. TASC does not attempt to directly control or provide visibility of switches and computers. So switch and computer objects are not in the TASC problem space. Only the CES related to or attached t
30、o switches and computers involved in the calls are visible. 5.1.1.2 Objects of interest TASC consists of a set of functional services that provide peer-to-peer applications with a standard means of communication for the control and visibility of calls. Ultimately it is the peer-to-peer applications
31、which know the objects of interest. Peer-to-peer applications not only have a communication application context, but they also have a common, and agreed, set of CES in the object space. In other words, the two applications know the CES over which they have control and visibility. This object space i
32、s either statically or dynamically defined. The locations of the objects are transparent to TASC. This is depicted in Figure 1 below. 2 Recommendation Q.1301 (10195) I Object location is transparent to TASC $. Physical mmunicdii 4 FIGURE 1/Q.1301 Transparent Location of CES 5.1.1.3 Operation and wor
33、king domains The identification of CES of interest to an application may occur through static (subscription arrangements) and dynamic means (messaging). The identified CES are the operation domain for a particular application. Once that application has begun processing, the transitional objects such
34、 as CVs (calls views), CPs (connections between CES and calls), and Users may be created and destroyed as a result of TASC related activity. The working domain may expand or contract during the lifetime of the application but may not expand to include CES outside of the defined operation domain. It
35、is the set of CES (objects) which can be monitored by an application which form a Working Domain. The relationship between Operation and Working Domain is illustrated in Figure 2. TASC does not provide the ability for applications to acquire and lock the use of a CE for the exclusive use of a partic
36、ular application process. Therefore coordination of applications and their use of CES is outside the scope of TASC. For example, in a customer service department for a company which has agents and an ACD system, the object space for the application is the set of objects representing the agent CES an
37、d ACD pilot numbers where calls are originated, terminated, or become visible. This Operation Domain does not include end users at least one CE must reside within the Operation Domain for call monitoring to function. This type of monitor will follow a single call. It may only be invoked once the cal
38、l has been created and a Call View ID returned to the application, e.g. after a TASC Make Call Functional Service request or Call- Arrived event (see Recommendation Q. 1302). A Call Monitor set on a CE will generate events as a result of a Call View state change for every call that has involved the
39、specified CE since the call monitor was invoked. A call where some CES are outside the TASC operation domain may report less call progress information; at least one CE must reside within the Operation Domain for call monitoring to function. This type of monitor will follow all calls which have conta
40、ct with the specified CE, e.g. a call monitor on a distribution CE will monitor all calls which are distributed by that CE. Events will be generated during the complete life of each call distributed. Call monitoring is considered further in clause 6. 5.1.2.5 Calk between CES As calls originate, arri
41、ve, terminate and disappear from CES within the working domain, events are reported based on the single-ended view, features in effect, and characteristics of a CE. Since all calls are uniquely identified by a Call View ID, any and all events which specify the same Call View ID in the communication
42、protocol between the peer applications refer to the same call. The switches assign and manage Call IDS although a management function may manipulate these IDS as described in Recommendation 4.1303 5.1.2.6 Call view ID Call 1Ds are assigned and managed by the switch and must uniquely identify calls a
43、t CES. These Call 1Ds must be unique within the Working Domain between peer applications. How the switch assigns Call 1Ds to calls between CES in the operation domain (Le. whether or not it uses the same Call view ID for both originating and terminating objects and events) must be understood and kno
44、wn by the applications prior to association. Thus Call view ID assignment is part of the application rules and in part a function of the type of network - public, private or hybrid. It should be noted that a request for a global call view may be rejected based upon the capabilities of the signalling
45、 environment in which the applications exists. 5.1.2.7 Global call view ID In a call between two CES in a working domain, a Global Call is characterized by the same Call View ID being assigned for both originating, terminating and distributing endpoints. The Call view ID is unique in the Working Dom
46、ain. Management of identifiers is achieved via parameters included in Functional Service responses and Event Reports. Identifiers cease to be valid when their context vanishes. If a call ends, its Call View Identifier is no longer valid to refer to that call. If a call changes its Call View Identifi
47、er when a Conference or Transfer occurs, identifiers are provided to link the old Call View Identifier to the new Call View Identifier. Similarly, if a CE Identifier is changed identifiers are provided to link new and old identifiers. Event Reports are used to report state changes. Recommendation Q.
48、1301 (10/95) 5 Identifiers can be re-used. Once an identifier has lost its context, it may be re-used to identify another object. Note that it is recommended that implementations do not re-use identifiers prematurely. Individual Call View and CE Identifiers are not guaranteed to be globally unique.
49、TASC requires that the combination of Call View and CE Identifier be globally unique within an operation domain. To accomplish this, either the Call View Identifier, or the CE Identifier (or both) shall be globally unique. 6 Caii monitoring 6.1 Introduction Call Monitoring is a Functional Service which will provide call progress information for all Communication Entities (CES) involved in a call. During the life of a call, regardless of the operations performed on that call, this service will continue to provide call progress information for as long as the c
