(Page 1 of 1 in this chapter)

Chapter 5

Loading and Starting CAS TCPs

5.1 Introduction
5.2 Loading Country-Specific Parameters
5.3 Starting Digital CAS Protocols
5.3.1 Starting Digital CAS Protocols on AG Quad Boards

5.1 Introduction

Before starting a Digital CAS TCP the application must initialize CT Access and obtain CTA context handles. The application should then start a TCP on each CTA context.

The sections that follow describe the following tasks:

5.2 Loading Country-Specific Parameters

Call progress tones differ from country to country. For this reason, Digital CAS TCP parameters must be configured differently to produce the tones appropriate for various countries.

To configure a Digital CAS TCP:

  1. Make sure the CT Access Parameter Management service is initialized.

    

  2. Make sure the binary parameter file (adiprt.pf file) for the target country is in a directory that is contained in the list of directories specified by the AGLOAD environment variable. The.pf file contains default values for all of the country-specific parameters.
    

    

  3. If necessary, make changes to the values of any parameters that will not affect regulatory approvals if modified. These parameters can be found in the ASCII parameter file (.par file) for the TCP. To change a parameter value, modify the value in the ASCII parameter file.
    

    
 
    

    

  4. If changes are made, your application can then load the modified value, as follows:
    

      

    

  5. Parse the parameter file.
    

    

  6. 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 ctdaemon to set system-wide parameters. 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 5.3, Starting Digital CAS Protocols), the TCP is programmed as specified by the parameters.



Refer to Appendix C for more information about specific Digital CAS protocol parameter files.






5.3	 Starting Digital CAS Protocols





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. adiStartProtocol starts the TCP. 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 4 of this manual and the AG Runtime Configuration and Developer's Manual.

 



adiStartProtocol will accept the following argument in the protoname field:




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






5.3.1	 Starting Digital CAS Protocols on AG Quad Boards





On AG Quad boards that use resource management, media functions started by the TCP cannot be active during the CONNECTED phase of calls. 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 is stopped and the application receives the event ADIEVN_STARTPROTOCOL_DONE with the reason ADIERR_NOT_ENOUGH_RESOURCES. The application must then start the protocol again with mediamask set to zero.


Note:  These restrictions only apply when the AG Quad board is configured with all four trunks enabled. If the AG Quad board is used as a Dual board, no special restrictions apply. Quad T1 and E1 boards do not support the SS5 protocol if the call control mode (specified in the CCMODE = line of the Ag configuration file) is not set to NONE. This specifies that 2 of the 4 T1 or E1 trunks can be used simultaneously with SS5 TCP.







 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



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