(Page 1 of 1 in this chapter)

Chapter 3

Initializing a Messaging API Application

3.1 Introduction
3.2 Overview
3.3 Making Switch Connections for AG ISDN
3.4 Initializing CT Access
3.4.1 Specifying B Channel CTA Contexts
3.4.2 Specifying D Channel CTA Contexts
3.5 Accessing D Channels
3.5.1 About Network Access Identifiers (NAIs)
3.5.2 Initializing ISDN Protocol Stack Instances
3.6 Starting the "No Call Control" TCP
3.6.1 Setting mediamask (AG Quad T/E only)
3.7 Stopping an ISDN Protocol Stack Instance

3.1 Introduction

This chapter:

3.2 Overview

An AG ISDN application performs the following initialization tasks:

  1. If necessary, the application makes switch connections to route D channel data to the HDLC controller, and to route B channel information to DSP resources. Note that certain default connections are automatically made if MVIP switching is not enabled. For more information, see Section 3.3, Making Switch Connections for AG ISDN.

    Figure 15. Routing Channel Data to On-Board Resources

    

  2. The application initializes CT Access, and creates a separate CTA context for each B channel and D channel it will interact with. For more information, see Section 3.4, Initializing CT Access.
    


    


    Figure 16.	 Creating CTA Contexts for Channels
    

    

  3. The application initializes ISDN protocol stack instances on each D channel CTA context, using the isdnStartProtocol function from the AG ISDN library. This function starts up an ISDN protocol stack instance on the D channel CTA context in ACU or LAPD stack mode. In the function call, the trunk is specified using its network access identifier (NAI). For more information, see Section 3.5, Accessing D Channels.
    


    


    Figure 17.	 Calling isdnStartProtocol
    

    

  4. The application starts a Special "no call control" Trunk Control Program (TCP) on each B channel context. This TCP puts the CTA context in a state where voice or media functions can be used without call control. For more information, see Section 3.6, Starting the "No Call Control" TCP.
    


    


    Figure 18.	 Starting nocc TCPs on B channel Contexts
    







3.3	 Making Switch Connections for AG ISDN





To allow an application access to ISDN channels, several switch connections must be made. In your AG configuration file, if EnableMvip=NO, these settings are automatically made when the AG board boots. However, if EnableMvip=YES, the application must make these settings, using the CTA switching service or swish utility.



The connections to be made are:




The connections differ depending upon whether the DigitalMode keyword is set to PRI or RAW. Specifically, if DigitalMode=RAW, no connections are made between the HDLC controller and signaling streams. This setting is for trunks which are included in NFAS groups. For more information about these keywords and about NFAS, see your AG ISDN Installation Manual.


Note:  Connections are listed in MVIP-95 nomenclature unless otherwise specified.


The following table shows the connections made by default: 





 



 Default Connections




 Board



 DigitalMode=PRI



 DigitalMode=RAW




 AG four-trunk T1 board (e.g., AG Quad T)



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..22 => 17:0..22, 
16:0..22 => 1:0..22


·	 Trunk B: 4:0..22 => 17:24..46, 16:24..46 => 5:0..22


·	 Trunk C: 8:0..22 => 17:48..70, 16:48..70 => 9:0..22


·	 Trunk D: 12:0..22 => 17:72..94, 16:72..94 => 13:0..22


 Full duplex, between HDLC controller and signaling streams:


·	 Trunk A: 2:0 => 21:0, 20:0 => 3:0


·	 Trunk B: 6:0 => 23:0, 22:0 => 7:0


·	 Trunk C: 10:0 => 25:0, 24:0 => 11:0


·	 Trunk D: 14:0 => 27:0, 26:0 => 15:0



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..23 => 17:0..23, 
16:0..23 => 1:0..23


·	 Trunk B: 4:0..23 => 17:24..47, 16:24..47 => 5:0..23


·	 Trunk C: 8:0..23 => 17:48..71, 16:48..71 => 9:0..23


·	 Trunk D: 12:0..23 => 17:72..95, 16:72..95 => 13:0..23




 AG four-trunk E1 board (e.g., AG Quad E)



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..29 => 17:0..29, 
16:0..29 => 1:0..29


·	 Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29


·	 Trunk C: 8:0..29 => 17:60..89, 16:60..89 => 9:0..29


·	 Trunk D: 12:0..29 => 17:90..119, 16:90..119 => 13:0..29


 Full duplex, between HDLC controller and signaling streams:


·	 Trunk A: 2:0 => 21:0, 20:0 => 3:0


·	 Trunk B: 6:0 => 23:0, 22:0 => 7:0


·	 Trunk C: 10:0 => 25:0, 24:0 => 11:0


·	 Trunk D: 14:0 => 27:0, 26:0 => 15:0



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..29 => 17:0..29, 
16:0..29 => 1:0..29


·	 Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29


·	 Trunk C: 8:0..29 => 17:60..89, 16:60..89 => 9:0..29


·	 Trunk D: 12:0..29 => 17:90..119, 16:90..119 => 13:0..29


 Note: Generally, DigitalMode is set to RAW only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.




 AG two-trunk T1 board (e.g.AG Dual T)


 



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..22 => 17:0..22, 
16:0..22 => 1:0..22


·	 Trunk B: 4:0..22 => 17:24..46, 16:24..46 => 5:0..22


 Full duplex, between HDLC controller and signaling streams:


·	 Trunk A: 2:0 => 21:0, 20:0 => 3:0


·	 Trunk B: 6:0 => 23:0, 22:0 => 7:0



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..23 => 17:0..23, 
16:0..23 => 1:0..23


·	 Trunk B: 4:0..23 => 17:24..47, 16:24..47 => 5:0..23




 AG two-trunk E1 board (e.g., AG Dual E)



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..29 => 17:0..29, 
16:0..29 => 1:0..29


·	 Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29


 Full duplex, between HDLC controller and signaling streams:


·	 Trunk A: 2:0 => 21:0, 20:0 => 3:0


·	 Trunk B: 6:0 => 23:0, 22:0 => 7:0



 Full duplex, between trunk voice information and DSP resources:


·	 Trunk A: 0:0..29 => 17:0..29, 
16:0..29 => 1:0..29


·	 Trunk B: 4:0..29 => 17:30..59, 16:30..59 => 5:0..29


 Note: Generally, DigitalMode is set to RAW only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.




 AG one-trunk T1 board (e.g., AG-T1)



 Full duplex, between trunk voice information and DSP resources:


 MVIP 95:  0:0..22 => 5:0..22, 
4:0..22 => 1:0..22


 MVIP 90:  16:0..22 <=> 18:0..22


 Full duplex, between HDLC controller and signaling streams:


 MVIP 95:  2:0 => 9:0, 8:0 => 3:0


 MVIP 90:  17:0 <=> 20:0



 Full duplex, between trunk voice information and DSP resources:


 MVIP 95:  0:0..23 => 5:0..23, 
4:0..23 => 1:0..23


 MVIP 90:  16:0..23 <=> 18:0..23




 AG one-trunk E1 board (e.g., AG-E1)


 



 Full duplex, between trunk voice information and DSP resources:


·	 MVIP 95:  0:0..29 => 5:0..29, 
4:0..29 => 1:0..29


·	 MVIP 90:  16:0..29 <=> 18:0..29


 Full duplex, between HDLC controller and signaling streams:


·	 MVIP 95:  2:0 => 9:0, 8:0 => 3:0


·	 MVIP 90:  17:0 <=> 20:0



 Full duplex, between trunk voice information and DSP resources:


·	 MVIP 95:  0:0..29 => 5:0..29, 
4:0..29 => 1:0..29


·	 MVIP 90:  16:0..29 <=> 18:0..29


 Note: Generally, DigitalMode is set to RAW only for trunks included in NFAS groups. NFAS is not supported on E1 trunks, so you would probably not use this configuration.



















3.4	 Initializing CT Access





To begin operations, the application initializes CT Access:


    


  1. It initializes CT Access services (including the ISDN service), using ctaInitialize.
    


  2. It creates 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 ADI service manager.
    


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


  4. It opens services you initialized in step 1 on the CTA contexts using ctaOpenServices.
    




For more information about initializing CT Access, see the CT Access Developer's Reference Manual.






3.4.1	 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.4.2	 Specifying D Channel CTA Contexts





The application must also create a separate CTA context for each D channel it will interact with. AG four-digital trunk boards can each support up to four separate D channels. AG two-digital trunk boards can each support up to two separate D channels. AG one-digital trunk boards can support one D channel each.



To open D channel CTA contexts under CT Access, use ctaCreateContext followed by ctaOpenServices. In each call to ctaOpenServices, stream, timeslot and mode should be set to 0, since no DSP processing resources are needed to control the D channel data stream.



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






3.5	 Accessing D Channels





Once one or more CTA contexts have been created for the D channels, initialize a separate ISDN protocol stack instance for each of these CTA contexts, and associate a specific D channel with each one.  When this is done, a D channel is ready to send and receive messages.






3.5.1	 About Network Access Identifiers (NAIs)





A trunk is referred to by its network access identifier (NAI). When you initialize an ISDN protocol stack instance for a CTA context (using isdnStartProtocol), you specify the NAI of the trunk to associate with the CTA context. From then on, the application can communicate with the D channel on that trunk via the CTA context handle. For example, when an event is received, the CTA context handle indicates the trunk on which the event occurred.



Different board types support different numbers of D channels, with different NAI numbers. The table below shows what each AG board type supports: 





 Board type



 Number of D channels



 NAIs




 AG four-trunk board



 Up to 4



 0 through 3




 AG two-trunk board



 Up to 2



 0 through 1




 AG one-trunk board



 1



 0



















3.5.2	 Initializing ISDN Protocol Stack Instances





Use isdnStartProtocol to initialize ISDN protocol stack instances.


Note:  Once you reference the CTA context in an isdnStartProtocol function call, do not reference that context in any other function call except isdnStopProtocol (when you wish to stop the stack).


To start up an ISDN protocol stack instance for ISDN ACU call control or LAPD, set the protocol, partner_equip, and parms arguments as follows:



protocol


Set to: 


·	 ISDN_PROTOCOL_Q931CC for ACU stack mode, or


·	 ISDN_PROTOCOL_LAPD for LAPD stack mode.



partner_equip


The type of equipment connected to the AG board. Set to one of the following:  





 If the AG board is...



 And AG ISDN is to run in...



 Set partner_equip to...




 Connected to network



 ACU stack mode



 EQUIPMENT_NT




 Connected to network



 LAPD stack mode



 EQUIPMENT_DCE




 Acting as network



 ACU stack mode



 EQUIPMENT_TE




 Acting as network



 LAPD stack mode



 EQUIPMENT_DTE
















parms


Pointer to a parameter structure to configure the protocol stack. If the application needs to change any of the parameters described in Appendix C, pass a pointer to one of the following structures in this call:


·	 ISDN_PROTOCOL_PARMS_Q931CC for ACU stack mode, or


·	 ISDN_PROTOCOL_PARMS_LAPD for LAPD stack mode.


If the application will not need to modify parameters, pass NULL to accept the default settings. For ACU, all the services are supported by default.



The ISDNEVN_START_PROTOCOL event contains the completion status of the start request. If the ISDN protocol stack instance started successfully, the value field in this event will contain SUCCESS. Otherwise, another value will appear here.



For more information about isdnStartProtocol, see Chapter 7.






3.6	 Starting the "No Call Control" TCP





Once all ISDN protocol stack instances have been created, start a "no call control" TCP on each B channel CTA context. This TCP puts the CTA context in a state where voice or media functions can be used without call control.



To start the TCP, call adiStartProtocol for each B channel CTA context, specifying NOCC in the protoname argument.



When adiStartProtocol is called, ADIEVN_STARTPROTOCOL_DONE is returned. If the NOCC TCP is started successfully, the event value field contains ADI_REASON_FINISHED. Otherwise, the value field contains another reason code.






3.6.1	 Setting mediamask (AG Quad T/E only)





mediamask is a field in the ADI_CALLCTL_PARMS structure passed in the adiStartProtocol call.  It controls which DSP resources are reserved for each DSP function (DTMF detection, echo cancellation, etc.). If you are using an AG Quad T or AG Quad E, you may need to change the setting of mediamask depending upon the setting of the CCMode statement in your AG configuration file. CCMode defines the call control resource allocation for these boards.




If CCMode is set to HIGH, MEDIUM, or LOW and mediamask is non-zero, when adiStartProtocol is called, an ADIEVN_START_PROTOCOL_DONE event is returned with the value field set to ADIERR_NOT_ENOUGH_ RESOURCES.






3.7	 Stopping an ISDN Protocol Stack Instance





To stop an ISDN protocol stack instance, call isdnStopProtocol from within the application. This shuts down the ISDN protocol stack instance, and releases all on-board resources and buffers formerly used by the stack instance.



The ISDNEVN_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 isdnStopProtocol, see Chapter 7.








 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



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