(Page 1 of 1 in this chapter)

Chapter 4

Loading and Starting CAS TCPs

4.1 Introduction
4.2 Loading Country-Specific Parameters
4.3 Starting CAS Protocols
4.3.1 Starting CAS Protocols with Resource Management

4.1 Introduction

Before starting a CAS TCP, the application must initialize CT Access and obtain CT Access context handles. The application should then start a TCP on each CTA context. For information about initializing CT Access and obtaining CT Access context handles refer to the CT Access Developers Reference Manual.

This chapter describes:

4.2 Loading Country-Specific Parameters

Many protocol features can differ from country to country or even within the same country. For this reason, AG CAS TCP parameters must be configured differently to specify the TCP behavior appropriately for various countries and networks.

Before configuring a TCP:

To change default TCP parameter:

  1. Make changes to the values in the ASCII parameter file (adi<prt>.par file) and save the changes. 

    

  2. Load the specified parameters in one of the following ways:
    

      

    • Use ctdaemon to set system-wide parameters by typing:

      

      
ctdaemon -f adi<prt>.par
      
Any CT Access application started subsequently on the system will share the parameter values contained in the adi<prt>.par file, as long as ctdaemon is kept running. Refer to the CT Access Developer's Reference Manual for more information.
      
In your application, call the CT Access function ctaLoadParameterFile giving adi<prt>.par as the function's argument.
      

    • Call ctaSetParmByName for each parameter specified in the file. This 
sets new default values. 

      

      
Note:  You must modify parameters before starting the specified TCP for the new parameters values to take effect. 

  

      


      


      WARNING:
      

      

      


      You may only change a subset of parameters for each CAS protocol without effecting regulatory approvals. 
      Chapters 7 - 19 list all parameters for each protocol and indicate which parameters may be edited. Editing other parameters may result in violations of country-specific regulations.
      

      

      


      


      

      

      

      

    


    Refer to Chapters 7 - 19 for more information about specific CAS protocol parameter files.
    

 
    

    

    

    4.3	 Starting CAS Protocols
    

    


    Once a CTA context has been opened and the TCP parameters has been loaded, the application can start a TCP on that CTA context according to the loaded parameters (see Section 4.2). Applications start CAS protocols by invoking adiStartProtocol. 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. agmon downloads all TCPs specified in the AG configuration file, ag.cfg. For more information about the AG configuration file, see the Chapter 3 of this manual and the AG Runtime Configuration and Developer's Manual.


    adiStartProtocol requires a TCP name as one of its arguments. Valid TCPs include:
    

    

    After the application calls adiStartProtocol, it will receive ADIEVN_STARTPROTOCOL_DONE. If the TCP is started successfully, the event value field contains ADI_REASON_FINISHED. Otherwise, the value field contains a reason code that describes the error that occurred.
    


    If your application terminates, all channels associated with the application are terminated, the TCP shuts down, and the bit pattern specified in the IdleCode statement in the AG configuration file is signaled on the line. 
    

    

    

    4.3.1	 Starting CAS Protocols with Resource Management
    

    


    On AG Quad boards that use DSP resource management, DSP functions started by the TCP (for example, DTMF detection) cannot be active while calls are in the CONNECTED state. For this reason, when calling adiStartProtocol, the value of the ADI service parameter mediamask (in the ADI_CALLCTL_PARMS substructure of the ADI_START_PARMS structure) must be set to zero.
    


    If mediamask is not set to zero, the TCP does not start and the application receives the ADIEVN_STARTPROTOCOL_DONE event with the reason ADIERR_NOT_ENOUGH_RESOURCES. The application must then set mediamask to zero before starting the protocol again.
    

Note:  These restrictions only apply when the AG Quad board is configured with all four trunks enabled. If you are using the AG Dual variants, no special restrictions apply. 


    


    

    

    


    
 
    (Page 1 of 1 in this chapter)
    


    
 



    
tech_support@nmss.com

    

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