(Page 1 of 1 in this chapter) Version

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.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 6.	 Routing Channel Data to On-Board Resources
    

    

  2. The application initializes CT 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 "dummy" CTA context for the 
    D channel. This CTA context is used only to refer to the stack instance on the channel with other AG ISDN library functions (such as isdnStopProtocol). Signaling from a D channel is not accessed through this context; instead, the channelizer in the protocol stack routes the signaling for each B channel to the CTA context for that B channel.
    



    Figure 7.	 Creating CTA Contexts for Channels
    

    

  3. 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 Channelized stack mode. In the function invocation, the trunk is specified using its network access identifier (NAI). For more information, see Section 3.5, Setting Up D Channels.
    

    



    Figure 8.	 Calling isdnStartProtocol
    

    

  4. The application starts a Trunk Control Program (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 9.	 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 the 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.


















The isdncta demonstration program (documented in Chapter 7) 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:


Note:  If D channel backup is defined in your configuration, CT Access must not be initialized on the context bearing the backup D channel. See 
Appendix C for more information.

    


  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 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, set these values 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.



Four-trunk AG boards can each support up to four separate D channels. Two-trunk AG boards can each support up to two separate D channels. One-trunk AG boards 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, set these values 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 Channelized stack mode. 


Note:  If D channel backup is defined in your configuration, CT Access must not be initialized on the context bearing the backup D channel. See 
Appendix C for more information.





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



The table below shows what each AG board type supports: 





 Digital Trunk Interface Board Type



 Number of D Channels



 NAIs




 Four-trunk AG boards



 Up to 4



 0 through 3




 Two-trunk AG boards



 Up to 2



 0 through 1




 One-trunk AG boards



 1



 0


















The NAI of a trunk is specified in the AG configuration file. For more information about this file, see the 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:




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 7.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 Channelized 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.1 (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 Channelized stack mode enable the required service access points (SAPIs).










 The behavior bits that govern the stack's automatic responses (such as CC_SEND_CALL_PROC_RQ) must not be modified in Channelized configuration. The only exceptions to this rule are the behavior bits governing overlapped sending/receiving (see 
Section 4.8).




 


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 contains SUCCESS. Otherwise, another value appears 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.
    

    

  2. The application modifies the values, if necessary.
    

    

  3. The application calls nccStartProtocol (NCC service) 
    or adiStartProtocol  (ADI service) 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.



The parameter files relevant to your application differ depending upon whether you are using the NCC Service or the ADI Service for call control. To learn more about loading and changing parameters, 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. 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:  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.


The function call used to start a TCP differs depending upon whether you are using the NCC service or the ADI service for call control:




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




 




tech_support@nmss.com



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