(Page 1 of 1 in this chapter)

Chapter 3

Initializing an AG ISDN Application

3.1 Introduction
3.2 Initializing the Application
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 "Dummy" D Channel CTA Contexts
3.5 Setting Up D Channels
3.5.1 About Network Access Identifiers (NAIs)
3.5.2 Initializing an AG ISDN Protocol Stack Instance
3.6 Starting ISDN TCP Instances
3.6.1 Loading Parameters
3.6.2 Starting a TCP on a CTA Context
3.6.3 Setting mediamask (AG Quad T/E only)
3.7 Stopping an ISDN Protocol Stack Instance

3.1 Introduction

This chapter:

3.2 Initializing the Application

An AG ISDN application performs the following initialization tasks for each trunk or NFAS group:

1. If necessary, the application makes MVIP 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 7. Routing Channel Data to On-Board Resources
  • The application initializes CT Access or AG Access, and creates a separate CTA context for each B channel on the trunk or NFAS group that it will interact with. For more information, see Section 3.4, Initializing CT Access.

    
The application must also create a separate CTA context for the D channel. The CTA context for a D channel is used only to refer to the stack instance on the channel in other AG ISDN library function calls (such as isdnStopProtocol). Signaling from a D channel is not accessed through the dummy context; instead, the channelizer in the protocol stack routes the signaling for each B channel to the CTA context for that B channel.
    
 
    

    

    Figure 8.	 Creating CTA Contexts for Channels
    

    

  • The application initializes an ISDN protocol stack instance on the D channel CTA context, using the isdnStartProtocol function from the AG ISDN library. This function starts up an ISDN protocol stack instance on the dummy CTA context in NCC stack mode. In the function call, the trunk is specified using its network access identifier (NAI). For more information, see Section 3.5, Setting Up D Channels.
    

    
 
    

    

    Figure 9.	 Calling isdnStartProtocol
    

    

  • The application starts a Trunk Control Programs (TCP) on each B channel context, loading country-specific parameters for each one (if necessary). For more information, see Section 3.6, Starting ISDN TCP Instances.
    

    
 
    

    

    Figure 10.	 Starting TCPs on B channel Contexts
    

    

    • 

    

    3.3	 Making Switch Connections for AG ISDN
    

    


    To allow an application access to ISDN channels, several MVIP 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 CT Access 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 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 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 with an AG Quad E.
    


    
 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 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 with an AG Dual E.
    


    
 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-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 with an AG-E1.
    



    


    

    

    

    

 
    


    The isdncta sample program (documented in Chapter 6) illustrates how an application makes these MVIP connections.
    

    

    

    3.4	 Initializing CT Access
    

    


    To begin call control operations, the application initializes CT Access, as follows:
    

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

      


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

      

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

      

    3. It opens services 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 on each trunk or NFAS group 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 "Dummy" D Channel CTA Contexts
    

    


    Create a separate "dummy" CTA context for each D channel on each trunk or NFAS group that your application will interact with. The CTA context for a D channel is used only to refer to the stack instance on the channel in other AG ISDN library function calls (such as isdnStopProtocol). Signaling from a D channel is not accessed through the dummy context; instead, the channelizer in the protocol stack routes the signaling for each B channel to the CTA context for that B channel.
    


    The AG Quad T and AG Quad E can each support up to four separate D channels. The AG Dual T and AG Dual E can each support up to two separate D channels. The AG-T1 and AG-E1 can support one D channel each.
    


    To open "dummy" 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	 Setting Up D Channels
    

    


    Initialize an ISDN protocol stack instance 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 dummy CTA context in NCC stack mode. 
    

    

    

    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 Quad T, AG Quad E
    

    		
 Up to 4
    

    		
 0 through 3
    


    
 AG Dual T, AG Dual E
    

    		
 Up to 2
    

    		
 0 through 1
    


    
 AG-T1, AG-E1
    

    		
 1
    

    		
 0
    



    


    

    

    

    

 
    


    The NAI of a trunk is specified in the AG configuration file. For more information about this file, see your AG ISDN Installation Manual.
    

    

    

    3.5.2	 Initializing an AG ISDN Protocol Stack Instance
    

    


    To initialize an AG ISDN protocol stack instance on a CTA context:
    

    

    

     Initializing A Stack Instance Using the AG ISDN Daemon
    

    


    To initialize an ISDN protocol stack instance, you can run the isdncta daemon supplied with the AG ISDN software. This daemon starts the ISDN protocol stack, and also makes the MVIP switch connections needed to support AG ISDN (see Section 3.3, Making Switch Connections for AG ISDN).When an ISDN protocol stack instance is initialized using the daemon, applications which use the standard CT Access call control API will operate with the ISDN TCP in the same way they would operate with any other TCP. 
    


    The daemon initializes an ISDN protocol stack instance by calling isdnStartProtocol. On the command-line, indicate the NAI to use. To learn how to launch isdncta, see Section 6.3, ISDN Daemon: isdncta.
    

    

    

     Initializing A Stack Instance Using isdnStartProtocol
    

    


    To initialize an ISDN protocol stack instance from within your application, call the isdnStartProtocol function in the ISDN library.
    

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 direct isdnStartProtocol to initialize a stack instance in NCC stack mode, set the protocol, partner_equip, and parms arguments as follows:
    

  

    


    
 Argument
    

    		
 Set to...
    


    
 protocol
    

    		
 ISDN_PROTOCOL_CHANNELIZED
    


    
 partner_equip
    

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

·	 EQUIPMENT_NT, if the AG board is connected to network equipment
    

·	 EQUIPMENT_TE, if the AG board is acting as network equipment
    


    
 parms
    

    		
 Pointer to a parameter structure to configure the stack. If the application needs to change any of the parameters for Natural Call Control, it should pass the structure name ISDN_PROTOCOL_PARMS_CHANNELIZED in this call. This structure is identical to the ISDN_PROTOCOL_PARMS_ Q931CC structure, except the behavior-governing bits listed in the structure are not used in the NCC configuration. (See the AG ISDN Messaging API Developer's Reference Manual for more information on AG ISDN parameters.)
    

    If the application will not need to change parameters, pass NULL to accept the default settings. The default parameters for the NCC stack mode enable the required service access points (SAPIs).
    



    


    

    

    
 
    

 
    


    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 the isdnStartProtocol function, see the AG ISDN Messaging API Developer's Reference Manual.
    

    

    

    3.6	 Starting ISDN TCP Instances
    

    


    When all ISDN protocol stack instances have been created, the application starts an ISDN TCP instance for each B channel CTA context. To start a TCP instance:
    

1.	 The CT Access Parameter Management Service loads the AG ISDN TCP parameters and default values.
    

      


    1. The application modifies the values, if necessary.
      

      

    2. The application calls adiStartProtocol to start the TCP instance.
      

    

    

    

    3.6.1	 Loading Parameters
    

    


    When you install AG ISDN software, parameter files are installed. The parameters in these files configure the TCP. 
    


    Some parameters determine the amplitude, frequency, length and pattern of the busy tone, ring tone and reorder tone. Since the tones differ from country to country, these parameters are country-specific, and should not be modified. Other parameters determine the service to request when placing an outbound call, the mode the TCP runs in, the channel direction, and the signal sending mask. These parameters can be modified to suit your application.
    


    Two types of parameter files are installed with each package:
    

    

    

     Loading the Binary Parameter File
    

    


    In order for CT Access to load the binary parameter file, the binary parameter file (.pf file) for the target country must be in one of the directories specified with the AGLOAD environment variable. Make sure only one file named adixxx.pf (containing parameter category definitions) appears in the AGLOAD directory; otherwise the parameters will not load.
    

    

    

     Changing Parameter Values
    

    


    The adiisd.par file contains a list of the parameters in the .pf file that can be changed without affecting regulatory approvals. To change parameter values, modify the value in adiisd.par. Your application can then load the changes as follows:
    

      


    1. Parse adiisd.par.
      

      

    2. Do one of the following:
      

        

      • Call ctaSetParmByName for each parameter specified in the file, to set 
a new default value. (For an example of this, see the 
DemoLoadParameters function in the demonstration library supplied 
with CT Access.)

        

        
OR
        

      • Use the ctdaemon program to set the parameters system-wide. See the 
CT Access Developer's Reference Manual for more information.

        

      


      Parameter modification must take place before adiStartProtocol is called. When adiStartProtocol is called to start the TCP (as described in Section 3.6.2, Starting a TCP on a CTA Context), the TCP is programmed as specified by the parameters.
      


      To learn more about parameter files, including their locations and names, see Appendix B.
      

      

      

      3.6.2	 Starting a TCP on a CTA Context
      

      


      Once a CTA context is opened and the TCP parameters are loaded, the application starts a TCP on that CTA context using the loaded parameters. The function adiStartProtocol starts a TCP on a CTA context. Once a TCP has started on a CTA context, the application can use call control functions to place and answer calls on that CTA context.
      

Note:  In order to start a TCP from within an application, the TCP must have been downloaded to the AG board at system initialization time. The agmon program downloads all TCPs specified in the AG configuration file, ag.cfg. For more information about the AG configuration file, see the AG ISDN Installation Manual and the AG Runtime Configuration and Developer's Manual.


      For AG ISDN call control, protoname passed to adiStartProtocol should be isd0. protoparms should be NULL, so the default TCP parameters (loaded as described in Section 3.6.1) are used.
      


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


      If your AG application terminates, all channels associated with the application are terminated, all TCP instances are shut down, and an idle pattern is broadcast on all B channels.
      

      

      

      3.6.3	 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 (such as DTMF tone detection or echo cancellation). 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:
      

      

      Either method 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 the AG ISDN Messaging API Developer's Reference Manual.
      

      

      


      
 
    (Page 1 of 1 in this chapter)
      


      
 



      
tech_support@nmss.com

      

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