1、 ECMA TR/88 1stEdition / June 2004 Designing an Object Model for ECMA-269 (CSTA) Technical Report ECMA TR/88 1stEdition / June 2004 Designing an Object Model for ECMA-269 (CSTA) Ecma International Rue du Rhne 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org IW TR-088.doc 03.08.2
2、004 11:21 . Brief History Although ECMA-269 (CSTA) specifies its basic objects, CSTA functionality is largely available through a service model, e.g., via XML schemata in ECMA-323 and through Web Services in ECMA-348. Adoption of CSTA for interactive voice services has resulted in increased demand f
3、or object-oriented access to CSTA. This Technical Report demonstrates how CSTA objects and behaviour, in particular for use with interactive voice services, can be modelled under the principle of ECMA-335 (CLI). This TR illustrates examples in ECMA-334 (C#), a language member of the CLI family. This
4、 Ecma Technical Report has been adopted by the General Assembly of June 2004. Table of contents1 Scope 1 2 References 1 3 Brief Review of CSTA Operational Model 4 Key Concepts of Service and Object Models 2 5 CSTA Object Model 3 5.1 CSTA Objects 3 5.2 Services and Events 5.3 Service Acknowledgements
5、 5 6 Illustrative Call Control Examples 6.1 Starting a CSTA application with implicit association 6.2 Placing a monitor on a device 6 6.3 Notification of an inbound alerting connection 7 6.4 Answering an inbound alerting connection 9 6.5 Clearing a connection 6.5.1 Service Request 9 6.5.2 Notificati
6、on of a cleared connection 10 6.6 Initiating an outbound call 10 6.6.1 Service Request 11 6.6.2 Outbound Call Event Sequence 11 6.7 Single step transfer or Deflect call 13 6.7.1 Service Requests 13 6.7.2 Notification events 14 6.8 Single step conference or Join Call 15 6.8.1 Service Requests 16 6.8.
7、2 Notification Event 7 Illustrative Examples for Interactive Voice Functions 18 7.1 Obtaining an object 18 7.2 Attaching the audio 7.3 Simple prompt playback 19 7.4 Advanced prompt playback 7.4.1 Set Voice Attribute for the filler prompt 20 7.4.2 Play the filler prompt 20 7.4.3 Prepare the new promp
8、t 21 - i - 7.4.4 Stop the filler prompt 21 7.5 Simple speech recognition 7.5.1 Obtain device and attach audio 22 7.5.2 Set up recognition grammars 7.5.3 Attach event handlers and start recognition 22 7.6 Simultaneous DTMF and speech recognition 24 7.7 Simultaneous speech recognition and speaker veri
9、fication 24 7.8 Sharing voice devices 25 Annex A (informative) - A comparison between CSTA and SALT 1.0 27 - ii - 1 Scope With the introduction of TR/85, “Using ECMA-323 (CSTA XML) in a Voice Browser Environment,” CSTA has witnessed a strong adoption in the area of interactive voice services. Softwa
10、re agents, equipped with speech recognition and synthesis capabilities, are deployed in call centres to provide automated services. Leveraging the rich functionality of CSTA, businesses are able to offer customers around the clock services without being limited to office hours or personnel constrain
11、ts. Accompanied with the strong adoption is the demand for simpler access to CSTA functionality. One such demand for CSTA concerns the need of CSTA in an object oriented programming style, the mainstream computer software development paradigm. Although CSTA has been specified in a manner consistent
12、with an object oriented design, the CSTA Standard Suite has been exclusively composed of specifications that make CSTA functionality available in a service model. ECMA-323 and ECMA-348 specify an XML based syntax and WSDL for CSTA respectively. This Technical Report demonstrates how developers can u
13、se CSTA in an object-oriented fashion. To broaden the reach, this TR bases the discussion on ECMA-335 (Common Language Infrastructure, or CLI) that enables an object model specification in a platform agnostic and programming language independent manner. The sheer volume reflecting the rich functiona
14、lity makes it impractical to enumerate all the features of CSTA. Inspired by the success of ECMA TR/85, this TR will focus the discussion in the areas of call control and interactive voice services where the demand for CSTA object model seems to be particularly strong. Examples highly parallel to EC
15、MA TR/85 are given in ECMA-334 (C#), a member of the CLI family. 2 References This TR refers to CSTA and CLI, for which the following Ecma Standards are definitive references: ECMA-269, Services for Computer Supported Telecommunications Applications (CSTA) Phase III, 6thEdition. ECMA-323, XML Protoc
16、ol for Computer Supported Telecommunications Applications (CSTA) Phase III, 3rdEdition. ECMA-348, Web Service Description Language (WSDL) for CSTA Phase III,2ndEdition. ECMA TR/85, Using ECMA-323 (CSTA XML) in a Voice Browser Environment. ECMA-334, C# Language Specification, 2ndEdition. ECMA-335, Co
17、mmon Language Infrastructure (CLI), 2ndEdition. The Interactive Voice Services in CSTA closely follow the operational model of Speech Application Language Tags (SALT), a specification of voice browsers available at www.saltforum.org where additional information on interoperating with CSTA can be fou
18、nd. 3 Brief Review of CSTA Operational Model As illustrated in Figure 6-1 of ECMA-269, a CSTA application can draw services from Switching Function (SF) and Computing Function (CF). Typically, the CF implements the application logic, where the SF provides the infrastructure for the needed telecommun
19、ication functionality such as call controls. In addition, a CSTA application can use services from Special Resource Function (SRF) that consists of feature add-ons to the application. Examples of features that can be implemented as SRF include Voice services and events in CSTA (ECMA-269, Clause 26).
20、 These additional features can be modelled either as part of SF or CF. In a call centre, the business procedures are often codified in and enforced by the CF software, whereas the call controls and computer telephony integration (CTI) are facilitated through service requests to the SF or SRF. Note t
21、hat, although the rest of this TR will focus on call controls and interactive voice services, they are just a category of services in CSTA SF and SRF, respectively. Examples of other categories of - 1 - SF services include capability exchange (feature discovery) services; call routing services, serv
22、ices to control a device (e.g. message waiting, writing to display, forwarding settings), and many others. 4 Key Concepts of Service and Object Models Since the dawn of the computer age, software has been developed using the service model, where reusable sequence of computer instructions are package
23、d into procedures or subroutines, each of which offers a specific service to the rest of the program. Usually, each service operates on a series of parameters (arguments) whose roles and the transformations inflicted upon them are well defined by the service. The service model is not limited to prog
24、rams running on the same computer. The service, for example, can be offered off from software in another computer connected through a network to the computer asking for the service. As a matter of fact, the majority of distributed processing protocols today are still specified in a service model. A
25、key feature of a service based programming model is that software designers would adopt a “vowel centric” or “action oriented” way of thinking. This is because each service is often characterized as performing a transformation on its arguments, and the transformation can usually be named after a ver
26、b while its arguments, nouns. Grouping a sequence of operations into a packaged service is a special case of abstraction where software designers are allowed to create customized vowels to describe their application domains. The idea of grouping can be applied to data as well. There, relevant pieces
27、 of information can be grouped into a data structure and be thought of as an integrated entity. Similar in notion to the customized vowels, being able to define data structures allow the programmers to create customized nouns for their application domains. These customizations help bridging the gap
28、between the programming model and the real world application, and therefore make the software easier to design, develop, and maintain. As the software gets more sophisticated, it is becoming more challenging to keep a holistic view of the whole application domain. As a result, computer programs are
29、increasingly made of well structured building blocks that themselves are computer programs composed of their own local services and data structures. Such a software design approach is reflected in the object oriented programming style. An object is an encapsulation of a data structure and the associ
30、ated services and operations that can be performed on the data. The objects serve as the building blocks of a program. An object oriented programmer usually thinks in terms of what objects are involved in the application domain, and how their individual services can be collaborated to facilitate des
31、ired outcomes. Because objects often refer to things, object oriented programming has a noun centric way of thinking. Encapsulation is a key concept to give rise to the strength and popularity of object oriented programming. Modern programming environments have further advanced the notion of encapsu
32、lation to include not only the data and operations, but also the asynchronous responses of an object as well. ECMA-334 (C#), for example, is a programming language in the ECMA-335 (CLI) family that provides comprehensive supports for object oriented programming. While data and operations can be mode
33、lled as the properties and methods of an object, respectively, C# allows the asynchronous responses to be modelled as events of an object. Localizing events to the object level streamlines the software design process by alleviating the burden of tracking event sources from the programmers. Although
34、CSTA has been specified largely in the form of a service model, the underlying objects are quite clear. CSTA Switching Functions are defined in terms of the interplay of Call, Connection, and the Device, and CSTA Special Resource Functions, Voice Unit, Listener, Prompt, DTMF Parser, and Prompt Queue
35、. These abstractions lay a solid foundation for a CSTA object model because, in essence, the basic objects of CSTA have been clearly identified. The challenges, as common to all the exercises to evolve a computational platform from a service model to an object model, are to properly encapsulate the
36、attributes, services, and events into these basic objects without departing significantly from the operational model already defined and widely implemented. This TR strives to provide a stepping-stone in that direction. As object model design is far from a trivial task, this TR by no means is intend
37、ed to be the final authority on the CSTA object model. Instead, the purpose of this TR is to summarize the collective thinking of experts in the field at the - 2 - time of publication, and to serve as an invitation to those skilled in the art to join our ongoing discussion and refine the object mode
38、l design. 5 CSTA Object Model The objects to facilitate CSTA SF have been clearly specified in Clause 6.1, ECMA-269 as the CSTA Connections, Calls, and Devices. They are accessible through a CSTA Provider that manages the collections and services surrounding these objects. In addition, the applicati
39、on can elicit services from Voice Resources, such as Voice Unit, Listener, Prompt, DTMF, and Prompt Queue (Clause 6.1.1.4.7 through 6.1.1.4.12, ECMA-269). Figure 1 shows the object hierarchy. Switching Function Voice Resources Provider Devices Device Calls Call Connection Connections Voice Unit List
40、ener Prompt IMonitor DTMF Prompt QueueFigure 1 - Schematic of CSTA Object ModelCSTA Monitor is a special object that enables event reporting. A Monitor can be placed, for example, on Device or Call objects to observe and keep track of the states of the objects. In addition, all the SRF objects may r
41、aise events. Event monitoring is therefore a feature that objects from both SF and SRF domains will provide. Accordingly, CSTA Monitoring Services are modelled as a CLI interface that can be implemented by other objects. 5.1 CSTA Objects Provider object models the CSTA SF subdomain. The instantiatio
42、n of a Provider object establishes the application association with CSTA, i.e., the constructors of the Provider object include the implicit/explicit and client/system initiative association as defined in Clause 7 of ECMA-269. Naturally, the Provider object encapsulates the System wide Services and
43、Events, - 3 - including Get Switching Function Capabilities, Get Switching Function Devices (13.1.4 through 13.1.6, ECMA-269), and System Services (Clause 14, ECMA-269). The Device object models a CSTA device (6.1.1). Typically, applications do not instantiate the Device object directly. Instead, th
44、e “Get Switching Function Devices Service” operation from the Provider object returns instances of Device objects. Device objects provide operations directly related to CSTA devices, such as Get Logical/Physical Device Information (13.1.2 and 13.1.3), Snapshot Device (16.1.2), Physical and Logical D
45、evice Features (Clause 21, 22, 23), as well as device oriented call control operations like Alternate Call (17.1.2), Conference Call (17.1.9), Consultation Call (17.1.10), Group Pickup Call (17.1.14), Join Call (17.1.17), Make Call (17.1.18), Make Predictive Call (17.1.19). The Connection object mod
46、els a CSTA connection (6.1.3). Typically, applications do not instantiate the Connection objects directly as they often result from a CSTA service request invocation. For instance, when an application makes an outbound call, the resulting Connection object is accessible through an argument in the Or
47、iginated Event (17.2.14). Similarly, the application can obtain the Connection object for an incoming call through the argument in the Delivered Event (17.2.5). The Connection object provides references to its Device and Call objects as it represents the relationship between these objects. It contai
48、ns the connection state, and offers most of the non device oriented call control services such as Accept Call (17.1.1), Answer Call (17.1.3), Clear Connection (17.1.8), Deflect Call (17.1.11), Hold Call (17.1.15), Intrude Call (17.1.16), and Single Step Conference (17.1.24), Single Step Transfer (17
49、.1.25), and Transfer (17.1.26). The Call object models a CSTA call (6.1.2) that contains call attributes such as user data, correlator data, and account or charging information. Typically, applications do not instantiate the Call objects directly. Instead, a Call object is often obtained from the Connection object that models the relationship of the call and the device. Call oriented operations include the Snapshot Call (16.1.1), Snapshot CallData (16.1.3), Clear Call (17.1.7), and Services in the Call Associated Features (18.1). Note that the Call object may serve as a ric
