1、ITU-T RECMN*Q-1302 95 m 4862571 Ob12350 3T8 m INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.1302 (1 0/95) INTELLIGENT NETWORK TELECOMMUNICATION APPLICATIONS TASC FUNCTIONAL SERVICES FOR SWITCHES AND COMPUTERS (TASC) - ITU-T Recommendation Q.1302 (Previ
2、ously “CCIlT Recommendation”) FOREWORD The IT-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (I). The IT-T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a view to standa
3、rdizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), 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 t
4、he Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12, 1993). IT-T Recommendation 4.1302 was prepared by ITU-T Study Group 11 (1993-1996) and was approved under the WTSC Resolution No. 1 procedure on the 17th of October 1995. NOTE In this Recomm
5、endation, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. 3 3 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
6、, including photocopying and microfilm, without permission in writing from the ITU. I CONTENTS 1 Scope 2 References 3 Terms and definitions . 4 Abbreviations . 5 Generic Functional Service requirements 5.1 Templates 5.1.1 Functional Service template 5.1.2 Event template 6 Functional Service descript
7、ions . 5.2 Error definitions 6.1 6.2 6.3 6.4 General Functional Services . 6.1.1 Functional Service name: Answer Call . 6.1.2 Functional Service name: Call Completion 6.1.3 Functional Service name: Clear Call . 6.1.4 Functional Service name: Conference Call . 6.1.5 Functional Service name: Divert Ca
8、ll . 6.1.6 Functional Service name: Drop CP . 6.1.7 Functional Service name: Hold Call . 6.1.8 Functional Service name: Make Call 6.1.9 Functional Service name: Retrieve Call 6.1.10 Functional Service name: Transfer Call Service . Specialized Functional Services . 6.2.1 Functional Service name: Alte
9、rnate Call 6.2.2 Functional Service name: Consultation Call . 6.2.3 Functional Service name: Reconnect Call Manipulate Functional Services 6.3.1 Manipulate Feature Functional Services . 6.3.1.1 Functional Service name: Manipulate Feature 6.3.1.2 Functional Service name: Query Feature Manipulate Agen
10、t Functional Services . 6.3.2.1 Functional Service name: Manipulate Agent 6.3.2.2 Functional Service name: Query Agent 6.4.1 Call Related Routing . Functional Service name: Set routing . Functional Service name: Route Call Functional Service name: Route Call Selected . Functional Service name: Route
11、 Used 6.4.2 Non-Call Related Routing . Functional Service name: Route Information . Functional Service name: Route Information Selected . Functional Service name: Re-Route Information Functional Service name: Route Information End 6.3.2 Routing Functional Services . 6.4.1.1 6.4.1.2 6.4.1.3 6.4.1.4 6
12、.4.2.1 6.4.2.2 6.4.2.3 6.4.2.4 Recommendation Q.1302 (10/95) Page 1 1 1 1 2 2 2 4 4 6 6 6 8 10 11 14 16 17 19 21 22 25 25 26 29 31 31 31 33 36 36 37 39 40 40 43 45 47 49 50 51 53 55 I 6.5 6.6 6.7 6.8 6.9 Monitor Functional Services . 6.5.1 Functional Service name: Change Monitor Filter Service 6.5.2
13、 Functional Service name: Monitor Start Service 6.5.3 Functional Service Name: Monitor Stop Service Snapshot Functional Services . 6.6.1 Functional Service name: Snapshot Call . 6.6.2 Functional Service name: Snapshot CE Functional Service name: Event Report . Application Status Services 6.8.1 Funct
14、ional Service name: Application Activity Check 6.8.2 Functional Service name: Application Congestion Report Functional Service name: Send Private Data . 7 Event descriptions Event name: Agent Busy . Event name: Agent Logged Off Event name: Agent Not Ready Event name: Agent Ready . Event name: Agent
15、Working After Call 7.2 Call progress events 7.1 Agent events . 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 Event name: Agent Logged On . 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.2.8 7.2.9 7.2.10 7.2.1 1 7.2.12 7.2.13 7.2.14 Event name: Call Arrived . Event name: Call Cleared . Event name: Call Conference
16、d . Event name: Call Delivered Event name: Call Diverted Event name: Cail Established Event name: Call Failed Event name: Call Held Event name: Call Originated . Event name: Cail Received . Event name: Call Retrieved Event name: Call Transferred . Event name: CP Dropped Event name: Service Pending .
17、 7.3 Cause List . Page 56 57 59 61 63 63 65 67 68 68 69 70 71 71 71 72 73 73 74 75 76 76 77 77 78 79 80 80 81 82 83 83 84 85 86 87 ii Recommendation Q.1302 (10/95) SUMMARY . Recommendation Q.1302 (10/95) 111 : This Recommendation identifies the Functional Services that comprises TASC (Telecommunicat
18、ions Applications for Switches and Computers) and is one in the Q.1300-Series on TASC. This Recommendation identifies the TASC Functional Services which provide building blocks for application developers. The main purpose of TASC is to allow applications to be developed which integrate the services
19、provided by both computing and telecommunication platforms. 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 Functional Services should be implemented. These Functional S
20、ervices can be used to support applications that integrate the use of telecommunication and computing platforms. INTRODUCTION The definition of individual Functional Services is based on a model described in the TASC Architecture Recommendation and goes down to the level of parameters, not protocol
21、details. It is assumed that the reader has read the TASC General Overview Recommendation Q. 1300 and the TASC Architecture Q. 1301 Recommendations. The Functional Services are offered by either switch or computer. Events reports are generated on changes of states. A common template is used to descri
22、be the Functional Services and is structured into Relationship, General Description, Parameters, Client/Server procedures and Management Requirements. BACKGROUND This Recommendation was developed at the same time as the Architecture and Management Requirements were developed for TASC. It is based on
23、 the experience of ECMA (Standardizing Information and Communication Systems) and ANSI (American National Standards Institute) member companies in developing switch-to-computer interfaces and takes direction from CSTA (Computer Supported Telecommunications Applications) and SCAI (S witch-to-Computer
24、 Applications Interface) standards. KEYWORDS ITU-T RECMN*Q.1302 95 4862571 Ob3235b 8Lb = Recommendation Q.1302 TELECOMMUNICATION APPLICATIONS FOR SWITCHES AND COMPUTERS (TASC) - TASC FUNCTIONAL SERVICES (Geneva, 1995) 1 Scope This Recommendation defines a set of Functional Services for the area of T
25、elecommunications Applications of Switches and Computers, that allow functional integration between a computing network and a telecommunications network. The emphasis of TASC has been to define third-party call control functions which also encompasses first-party call control. TASC is independent of
26、 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 addition to ISDN and Intelligent Networks (IN). It is focussed on providing an application service interface between a switch an
27、d a computer. TASC supports both a single-ended (originating and terminating) view as well as a global call view. Computing platforms (e.g. Application Programming Interfaces - APIS) that may support such functionally-integrated applications are outside the scope of this Recommendation. 2 References
28、 The following Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation, or Annexes to this Recommendation. At the time of adoption of this Recornmendation, the reference editions indicated were valid. Recalling that
29、all Recommendations and other material incorporated by reference herein are subject to future revision, all users of this Recommendation are therefore advised that changes in the reference text that constitute future decisions of the work of Organizations or Study Groups other than ITU-T Study Group
30、 11, do not automatically apply as amended provisions to the Recommendation. ITU-T Q. 1300 (1993, Telecommunication Applications for Switches and Computers (TASC) - TAX general overview. IT-T 4.1301 (1999, Telecornniunication Applications for Switches und Computers (TASC) - TASC architecture. ITU-T
31、Q. 1303 (1999, Telecommunication Applications for Switches and Computers (TASC) - TASC management: architecture, methodology and requirements. - - - 3 Terms and definitions This Recommendation uses terms defined in Recommendation Q. 1300. 4 Abbreviations For the purposes of this Recommendation the f
32、ollowing abbreviations are used: CE Communication Entity CP Communication Party cv Call View FS Functional Service HLCp Higher Layer Capability ISDN Integrated Services Digital Network Recommendation Q.1302 (1095) 1 ITU-T RECMN*Q.3302 95 m 48b2593 Ob32357 752 m LLCp Lower Layer Capability TASC TE Te
33、rminal Equipment Telecommunication Applications for Switches and Computers 5 Generic Functional Service requirements The Functional Service provided by a server to a client consists of observing and acting upon objects which can be accessed by the server on behalf of the client. In the TASC context,
34、 both the switch and the computer may take the role of the client or the server. A Functional Service is used by a client to request a server to perform a specified function, and is used by the server to reply to the request. If the request for a Functional Service is refused, the server shall send
35、diagnostic information indicating the reason that the Functional Service was refused. For Functional Services requesting server activity from a switch, the following generic mechanisms, in principle, decouples from the specifics of the switching activity. i) The precise moment at which the response
36、is generated in relation to the switching activity is implementation and service dependent: - Some implementations may generate the response after checking the correctness of the request and before completing the requested service. Other implementations may delay the response until the requested ser
37、vice has completed or is guaranteed to complete. In this case, a failure of the requested service is reflected in the response. If a response is sent before the action requested by the Functional Service is completed, i.e. the response only indicates acceptance of the request, monitoring mechanisms
38、could be used to keep track of the subsequent server activity. - 2) Implementations based on TASC Functional Service descriptions need to indicate which of the above is implemented. Monitoring issues - If it is desirable for the computer application to know the actions the switch has performed, moni
39、toring is desirable, .e. the computer may start the Monitoring Functional Service and receive call related event reports from the switch, as defined in the filter of the Monitoring Functional Service. Alternatively an application may use the Snapshot Functional Services to determine the actual state
40、s. If the success response indicates that the requested Functional Service has been completed, monitoring may not be necessary. - The Functional Service description identifies the conditions of the client and the server and what actions they may perform. 5.1 Templates 5.1.1 Functional Service templa
41、te The Functional Service descriptions that are provided in clause 6 follow the service template as given below: Functional Service name a) Relationship The involved entities and their relationship shall be indicated. As an example, if the request for a Functional Service is sent by the computing en
42、tity (client) to the switching entity (server), the relationship is indicated as follows: Computer + Switch 2 Recommendation Q.1302 (10195) ITU-T RECMN*Q=3302 95 = 48b2591 Ob32358 699 b) General description The general description sections are provided as normative text, and should provide a general
43、 overview of the actions. cl Parameters These sections provide normative text for describing the parameters and the optionality of the parameters associated with each request for a Functional Service. If as a result of performing a Functional Service request, new objects of interest are created (e.g
44、. CVs resulting from a Make Call), then references to these objects shall be provided in mandatory parameters in the success response. Absence of a mandatory parameter will cause a reject of the Functional Service request. A present, but invalid mandatory parameter will result in an error response.
45、Absence of an optional parameter will result in the usage of a default. Details are provided in the Operational Rules. Absence of “private data” will not affect the performing of a Functional Service. REQUEST: The request indicates the operation to be performed and shall include the parameters neede
46、d for the server to perform the operation. It shall allow inclusion of non-standardized or private data. The absence of “private data” shall not affect the performing of the Functional Service. RESPONSE: The response confirms the request either positively (success) or negatively (error). Success: A
47、success response indicates receipt of the correctly formatted message, and may be generated after the requested Functional Service has been completed or is guaranteed to complete. Error: The error response always conveys the information that the request was received, but not performed. An error valu
48、e indicates the servers best evaluation of the condition that was encountered that caused the server to send an error response to the request. Parameter description All parameters listed are described to indicate their usage. d) Client (computer/switch) The exact description of the procedures (norma
49、l or in error cases) as performed in the invokinghequesting entity (client) is provided. This is informative. normal procedure Preconditions: The conditions at the point at which the request is initiated are given (entry conditions). The order is considered to be a logical sequence. (1) (-1 (x) Allowable basic call view states. Postconditions: The conditions/actions after the request has been sent shall be given (exit conditions). The order is considered to be a logical sequence. (1) (I (x) Resulting basic call view states. Recommendation Q.1302 (10/95) 3 ITU-T RECMN*Q.1302 95 Lid62
