(Page 1 of 1 in this chapter) Version

Chapter 3

Initializing a DPNSS Application

3.1 Introduction
3.2 Initializing the Application
3.3 Making Switch Connections
3.4 Initializing CT Access
3.4.1 Initializing CT Access Services
3.4.2 Creating Event Queues
3.4.3 Creating CTA Contexts and Opening Services
3.5 Starting DPNSS on a CTA context
3.6 Stopping DPNSS on a CTA context

3.1 Introduction

This chapter:

3.2 Initializing the Application

A DPNSS application performs the following initialization tasks:

  1. The application initializes CT Access, and creates a separate CTA context for each B channel on the trunk. For more information, see Section 3.4, Initializing CT Access. 

    

  2. The application creates a separate CTA context for the number of DPNSS virtual channels the application plans to use. 
    

    

  3. The application next initializes the DPNSS protocol on each CTA context, using the dpnStartProtocol function from the DPNSS service library. 
    







3.3	 Making Switch Connections





The DPNSS service manages DPNSS call control and supplementary service message sending and receiving. The DPNSS service does not provide any function for playing or recording voice messages. This has to be done using other NMS boards with DSP resources that are connected to the DPNSS B channels through the MVIP bus. The application must make these settings, using the CTA switching service. The connections must be full duplex. 



The following table shows the BX 3000 trunk/stream/timeslot mapping according to the MVIP-90 and MVIP-95 switching models:  





 Board 



 MVIP-95



 MVIP-90 




 BX-3000/1E 



·	 MVIP bus: streams 0..15;
timeslots 0..31 


·	 E1 Trunk : local 0:0..29



·	 MVIP bus: streams 0..15; 
timeslots 0..31 


·	 E1 Trunk : 16:0..29




 BX-3000/2E 



·	 MVIP bus: streams 0..15;
timeslots 0..31 


·	 E1 Trunk 1 : local 0:0..29


·	 E1 Trunk 2 : local 4:0..29



·	 MVIP bus: streams 0..15; 
timeslots 0..31 


·	 E1 Trunk 1: 16:0..29


·	 E1 Trunk 2: 18:0..29
















For more information about BX 3000 MVIP switching, see your BX 3000 Installation and Developer's Manual.






3.4	 Initializing CT Access





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


    


  1. Initialize CT Access services, including the DPNSS service, using ctaInitialize. 
    

    

  2. Create one or more event queues, using ctaCreateQueue. Each function call creates a queue and returns a handle. Make sure at least one queue is attached to the DPNSS service manager. 
    

    

  3. Create one or more contexts, using ctaCreateContext. Each call creates a CTA context and returns a CTA context handle. 
    

    

  4. Open services on the CTA contexts using ctaOpenServices. 
    







3.4.1	 Initializing CT Access Services





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 which are linked to the application.



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






3.4.2	 Creating Event Queues





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






3.4.3	 Creating CTA Contexts and Opening Services





Create CTA contexts 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 service functions. Events communicated back to the application are also associated with the CTA context.



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


 Specifying B Channel CTA Contexts



Create a separate CTA context for each B channel that your application will interact with. To open CTA contexts under CT Access, use ctaCreateContext followed by ctaOpenServices. In each call to ctaOpenServices, specify: 




Under CT Access, these values are included in the CTA_MVIP_ADDR structure passed to ctaOpenServices.






3.5	 Starting DPNSS on a CTA context





Once a CTA context is opened, the application starts the DPNSS protocol by calling the function dpnStartProtocol. Once a DPNSS protocol has started on a CTA context, the application can use call control functions to place and answer calls on that CTA context. 



When dpnStartProtocol is called, DPNEVN_STARTPROTOCOL_DONE is returned. If the protocol is started successfully, the event value field contains DPN_REASON_FINISHED. Otherwise, the value field contains another reason code. 



For more information about dpnStartProtocol, see Chapter 5.






3.6	 Stopping DPNSS on a CTA context





To stop the DPNSS protocol on a given CTA context instance, call dpnStopProtocol from within the application. 



The DPNEVN_STOP_PROTOCOL event contains the completion status of the stop request. If the stack instance stopped successfully, the value field in this event will contain SUCCESS. Otherwise, another reason code will appear here. 



For more information about dpnStopProtocol, see Chapter 5.








 
    (Page 1 of 1 in this chapter)  Version




 




tech_support@nmss.com



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