(Page 1 of 1 in this chapter)

Chapter 1

Overview of CT Access

1.1 About the CT Access Environment
1.1.1 Programming Model
1.1.2 CT Access Components
1.1.3 Managing Parameters in CT Access
1.2 Setting Up the CT Access Environment
1.2.1 Initializing CT Access
1.2.2 Creating Event Queues and CTA Contexts
1.2.3 Opening Services
1.2.4 Linking with the Voice Message Service

1.1 About the CT Access Environment

This section provides background information about CT Access and summarizes the main elements of the CT Access environment. CT Access (Computer Telephony Access) is a development environment providing standard programming interfaces for telephony functions that are hardware independent. You must have CT Access installed on your system to build applications using the Voice Message service.

For detailed information about CT Access, refer to the CT Access Developer's Reference Manual.

1.1.1 Programming Model

CT Access employs an asynchronous programming model in order to take advantage of concurrent processing. When called, most functions return immediately, indicating the operation was initiated. The application may then call other functions while CT Access is processing the command.

There are two types of functions in CT Access: synchronous and asynchronous.

Synchronous functions are complete when the return value is received. The return value may be either SUCCESS or an error code.

For asynchronous functions, if the return value is SUCCESS, the function has been successfully initiated, and the execution result will arrive asynchronously via an event. If the return code is not SUCCESS, the function was never initiated; therefore, no subsequent events associated with the function will be generated.

During the function execution, events are generated indicating the occurrence of certain conditions or state changes. If an asynchronous function fails after being initiated, CT Access delivers a DONE event to the application and the event value field contains an error code.

The following table summarizes the differences between asynchronous and synchronous functions. Chapter 7 lists all Voice Message service functions and indicates if they are synchronous or asynchronous.

Characteristic

 Asynchronous

 Synchronous

Operation complete when function returns.

 No

 Yes

Returns a DONE event when function is complete.

 Yes

 No

Function can fail after function returns.

 Yes

 No

For asynchronous functions, CT Access sends a command to the service which sends a command to a telephony board. The board performs the requested functions and sends events to the service indicating its state (e.g., function was started, function is complete, etc.). The service sends events to CT Access which makes them available to the application.

Refer to Appendix B for a complete list of Voice Message service errors and events.

1.1.2 CT Access Components

A CT Access service is a group of logically related telephony functions. The Voice Message service is a CT Access service.

Figure 1. CT Access and the Voice Message Service 



A CTA context organizes services and accompanying resources around a single processing context. A CTA context usually represents an application instance controlling a single telephone call.



An event queue is the communication path from a CT Access service to an application. A CT Access service generates events indicating certain conditions or state changes. An application retrieves the events from the event queue.






1.1.3	 Managing Parameters in CT Access





The characteristics for CT Access services can be altered by modifying associated parameters. Each Voice Message service parameter structure has default values that are sufficient for most configurations.



CT Access manages parameters for services on a CTA context basis. The CTA context will maintain a copy of the parameters for all services opened on the context.



The following CT Access functions allow you to obtain or change parameter information:


 





 Function



 Description




 ctaGetParmByName



 Retrieves a single field for a given parameter name.




 ctaSetParmByName



 Modifies a single field for a given parameter name.




 ctaGetParmID



 Retrieves the parameter ID for a given parameter descriptor name.




 ctaGetParmInfo



 Retrieves a parameter field definition.




 ctaGetParms



 Returns parameter values for a given parameter structure.




 ctaRefreshParms



 Resets the values of all context parameters on a CTA context to the global defaults.















Refer to the CT Access Developer's Reference Manual for information about the parameter functions. Refer to Appendix C of this manual for detailed descriptions of Voice Message service parameters.






1.2	 Setting Up the CT Access Environment





Before you can call functions from the Voice Message library, the application must initialize CT Access and open the Voice Message service. Application setup for CT Access consists of the following steps:


    


  1. Initializing CT Access for the process.
    

    

  2. Creating event queues.
    

    

  3. Creating CTA contexts and attaching them to an event queue.
    

    

  4. Opening services on each CTA context.
    








1.2.1	 Initializing CT Access





You register services in the call to ctaInitialize by specifying the service and service manager names. Only the services initialized in the call to ctaInitialize may be opened by the application. Service managers are dynamic link libraries (DLL) in Windows NT and shared libraries in UNIX which are linked to the application.






1.2.2	 Creating Event Queues and CTA Contexts





After initializing CT Access, create the event queues and CTA contexts.



Create one or more event queues by calling ctaCreateQueue. You specify which service managers will be attached to each queue. The Voice Message service's service manager is VCEMGR. When you attach or bind a service manager to an event queue, you make that service manager available to the event queue.



Create a CTA context by calling ctaCreateContext. You provide the queue handle (ctaqueuehd) that was returned from ctaCreateQueue. All events for services on the CTA context will be received in the specified event queue.



ctaCreateContext returns a CTA context handle (ctahd). The CTA context handle is supplied by the application when invoking Voice Message service functions. Events communicated back to the application are also associated with the CTA context.



Refer to the CT Access Developer's Reference Manual for details on the programming models created by the use of CTA contexts and event queues.






1.2.3	 Opening Services





Services are opened on a CTA context by calling ctaOpenServices, passing a CTA context handle and a list of service descriptors. The service descriptor specifies the name of the service, service manager, and service-specific arguments (e.g., MVIP address).






1.2.4	 Linking with the Voice Message Service





The CT Access Voice Message service contains two components, the Voice Message service interface (vceapi) and the Voice Message service implementation (vcemgr). When building a new CT Access application that uses the Voice Message service, link to vceapi.lib (under UNIX, libvceapi.so). The vcemgr.lib (under UNIX, libvcemgr.so) is dynamically loaded at runtime.



In earlier releases of CT Access, both the interface and implementation components were shipped in a single library, the vcemgr library. It is strongly recommended that you modify makefiles of existing applications to link with vceapi.lib (libvceapi.so). 



See the CT Access Service Writer's Manual for more details about service implementation. 








 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.