Table of Contents Index NMS Glossary Previous Page Next Page Version

Chapter 2

Initializing the CDI Service

2.1 Introduction
2.2 Setting Up the CT Access Environment
2.2.1 Initializing CT Access
2.2.2 Creating Event Queues and CTA Contexts
2.2.3 Opening Services
2.2.4 Receiving CDI Service Events
2.2.5 Linking with the CDI Service

2.1 IntroductionTop of Page

This chapter describes how to set up the CT Access environment and start the CDI service. Refer to the CT Access Developer's Reference Manual for an overview of the setup process and details about particular CT Access APIs.

2.2 Setting Up the CT Access EnvironmentTop of Page

Before you can call functions from the CDI library, the application must initialize CT Access and open the CDI 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, including the CDI service.
    








2.2.1	 Initializing CT AccessTop of Page





Register services when invoking ctaInitialize by specifying the service and service manager names. Only the services initialized with ctaInitialize may be opened by the application. Service managers are dynamic link libraries (DLLs) in Windows NT. 



Use CDIMGR, the CX board family service manager, in your call to ctaInitialize. See the CT Access Developer's Reference Manual for more details about using ctaInitialize. 






2.2.2	 Creating Event Queues and CTA ContextsTop of Page





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



Create one or more event queues by invoking ctaCreateQueue. You specify which service managers will be attached to each queue. The CDI service manager is CDIMGR. 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. 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 context handle is supplied by the application when invoking CDI 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.






2.2.3	 Opening ServicesTop of Page





Services are opened on a CTA context by invoking ctaOpenServices. When opening a service on a CTA context, you must specify information about the service and the service manager, and which resources to attach to the context. 



The following example shows how to fill in this information to start CDI on a CTA context: 





 Parameter



 Set as follows for the CDI service




 CTA_SERVICE_NAME:



 




  svcname



 CDI




  svcmgrname



 CDIMGR




 CTA_SERVICE_ADDR:



 Reserved for client/server usage. Initialize to 0.




 CTA_SERVICE_ARGS:



 Not used by CDI.




 CTA_MVIP_ADDR:



 




  board



 The logical board number.




  bus



 Set to 0.




  stream



 Set to 0 for MVIP streams, for switching and board management.


 Set to 4 for DSP streams, for call control.




  timeslot



 Set to 0..471 for station lines 1..48.




  mode



 Set to 0.









1
 Number of timeslots depends on the specific board configuration.











2.2.4	 Receiving CDI Service EventsTop of Page





When the CDI service manager is attached to an event queue, it opens the board driver and associates the muxable wait object returned by the driver open command with the event queue. When this wait object is signaled on receipt of events from the board, ctaWaitEvent processes the events through the CDI service and passes any event generated back to the calling function.



Events arrive in the form of the standard CTA event data structure (defined in ctadef.h):


typedef struct CTA_EVENT
{
    DWORD    id;                /* Event code (and source service ID)    */
    CTAHD    ctahd;             /* CT Access context handle              */
    DWORD    timestamp;         /* Timestamp                             */
    DWORD    userid;            /* User ID (defined by ctaCreateContext) */
    DWORD    size;              /* Size of buffer if buffer != NULL      */
    void     *buffer;           /* Buffer pointer                        */
    DWORD    value;             /* Event status or event-specific data   */
    DWORD    objHd;             /* Service client side object handle     */
} CTA_EVENT;




This structure, returned by ctaWaitEvent, informs the application which event occurred on which CTA context and includes additional information specific to the event.



The CTA_EVENT structure contains the following fields: 





 Field



 Description




 id



 Contains an event code defined in the library header file. The event's prefix relates the event to a specific Natural MicroSystems library of functions. For example, all CDI events are prefixed with CDIEVN_ (CDIEVN_SOMETHING_ HAPPENED). All CT Access events are prefixed with CTAEVN_.




 ctahd



 Contains the CTA context handle (line handle) returned from ctaCreateContext.




 timestamp



 The time since the DSP was booted, in milliseconds (modulo 65536). The resolution for CX board events is 2 milliseconds. To provide a wider range, the timer alternates between even values (0, 2, 4, ...65534) and odd values (1, 3, 5, ...65535), every (approximately) 65 seconds. 




 userid



 Contains the user-supplied ID. This field is unaltered by CT Access and facilitates asynchronous programming. Its purpose is to correlate a CTA context with an application object/context when events occur.




 size



 The size (bytes) of the area pointed to by buffer. If the buffer is NULL, this field may be used to hold an event-specific value.




 buffer



 This field points to data returned with the event. The field contains an application process address and the event's size field contains the actual size of the buffer.




 value



 This is an event-specific value. This field can hold a reason code or an error code.




 objHd



 Contains the service client-side object handle.



















2.2.5	 Linking with the CDI ServiceTop of Page





When building a CT Access application that uses the CDI service, compile the program with cdidef.h and link to the cdiapi library (cdiapi.lib for Windows NT, libcdiapi.so for UNIX).



See the CT Access Developer's Reference Manual for more details about linking to a service.








 
Table of Contents Index NMS Glossary Previous Page Next Page Version




 




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



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