Version

Chapter 1

Overview of CT Access

1.1 Introduction

1.2 CT Access Environment

: 1.2.1 Programming Model
: 1.2.2 CT Access Components

1.3 Setting Up the CT Access Environment

: 1.3.1 Initializing CT Access
: 1.3.2 Creating Event Queues and CTA Contexts
: 1.3.3 Opening Services
: 1.3.4 Linking With the Switching Service

1.1 Introduction

The Switching Service Developer's Reference Manual provides: An overview of the CT Access Switching service A reference of functions and errors
This manual defines telephony terms where applicable, but assumes that the reader is familiar with telephony concepts and switching. It also assumes that the user is familiar with the C programming language. Note: References to MVIP-90 in this manual are for legacy systems only.
Read the CT Access Developer's Reference Manual before using this manual. The CT Access Developer's Reference Manual contains detailed information concerning CT Access concepts, architecture, and application development. This information must be fully understood before you develop a switching application using CT Access.
For more information, refer to the following documents: ECTF: H.100 Revision 1.0 Hardware Compatibility Specification: CT Bus ECTF: H.110 Revision 1.0 Hardware Compatibility Specification: CT Bus CompactPCI Computer Telephony Specification PICMG 2.5 R1.0 MVIP-95 Device Driver Standard H-MVIP Standard MVIP-90 Standard
NMS also offers a Point-to-Point Switching service that provides an application program interface (API) for making switch conections between boards connected by a telephony bus without having to specify the intervening timeslots. The Point-to-Point Switching service maintains an internal database that records the topology of the switching configuration for the system and the state of all the timeslots. For more information, refer to the Point-to-Point Switching Service Developer's Reference Manual.
For GO-MVIP information, contact: GO-MVIP, Inc. 3220 N Street, NW, Suite 360 Washington, DC 20007 Tel: 800-NOW-MVIP (US and Canada) Tel: 903-769-3717; Fax: 903-769-3818 Email: info@mvip.org

For ECTF information, contact: ECTF 39355 California Street, Suite 307 Fremont, CA 94538 Tel: 501-608-5915 Fax: 510-608-5917 Email:ectf@ectf.org

1.2 CT Access Environment

This chapter provides background information about CT Access and summarizes the main elements of the CT Access environment. CT 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 Switching service.
For detailed information about CT Access, refer to the CT Access Developer's Reference Manual.

1.2.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 can 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 can 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 through 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.
All Switching service functions are synchronous.

1.2.2 CT Access Components

A CT Access service is a group of logically related telephony functions. The Switching service is a CT Access service. Figure 1. CT Access and the Switching 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.3 Setting Up the CT Access Environment

Before you can call functions from the Switching library, the application must initialize CT Access and open the Switching service. Application setup for CT Access consists of the following steps: Initializing CT Access for the process. Creating event queues. Creating CTA contexts and attaching them to an event queue. Opening services on each CTA context.

1.3.1 Initializing CT Access

Register services in the call to ctaInitialize by specifying the service name (SWI) and service manager name (SWIMGR). Only the services initialized in the call to ctaInitialize can be opened by the application. Service managers are dynamic link libraries (DLL) in Windows NT and shared libraries in UNIX that are linked to the application.

1.3.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 Switching service's service manager is SWIMGR. When you attach or bind a service manager to a queue, you make that service manager available to the 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 swiOpenSwitch.
Refer to the CT Access Developer's Reference Manual for details on the programming models created by the use of CTA contexts and queues.

1.3.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.

1.3.4 Linking With the Switching Service

The CT Access Switching service contains two components, the Switching service interface (swiapi) and the Switching service implementation (swimgr). When building a new CT Access application that uses the Switching service, link to swiapi.lib (under UNIX, libswiapi.so). The swimgr.lib (under UNIX, libswimgr.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 swimgr library. It is strongly recommended that you modify makefiles of existing applications to link with swiapi.lib (libswiapi.so).
See the CT Access Service Writer's Manual for more details about service implementation.

Version

Want to send us feedback on our documentation? Email: Tech_Pubs@nmss.com