(Page 1 of 1 in this chapter)

Chapter 1

Introduction

1.1 Introduction
1.2 About Point-to-Point Switching
1.3 About CT Access
1.4 Setting Up the CT Access Environment
1.4.1 Initializing CT Access
1.4.2 Creating Event Queues and CTA Contexts
1.4.3 Opening Services
1.5 Using Point-to-Point Switching in a CT Access Application
1.6 The Point-to-Point Switching Server
1.7 Using the PPX Server on Windows NT
1.7.1 Controlling the PPX Server Manually
1.7.2 Using the PPX Server as a Windows NT Service
1.7.3 Starting and Stopping the PPX Server
1.7.4 Removing the PPX Server from Windows NT Services
1.8 Using the PPX Server on Unix
1.8.1 Starting the PPX Server
1.8.2 Stopping the PPX Server
1.9 Using the PPX Initialization Error Log
1.10 SWI Error Logging
1.10.1 An Example ppxswi.log

1.1 Introduction

This chapter:

1.2 About Point-to-Point Switching

The Point-to-Point Switching service provides an application programming interface (API) for making switch connections between boards connected by a telephony bus without having to specify the intervening bus timeslots. The Point-to-Point Switching service maintains an internal database that records the topology of the switching configuration for the system and the state of all the timeslots.

When making a switch connection using Point-to-Point Switching, you simply specify the two endpoints for the connection. The Point-to-Point Switching service manages the telephony bus timeslots and controls the underlying hardware switches to make the connections. The Point-to-Point Switching service can be used with any board which has an FMIC, HMIC, or ATI/ASI type switch.

Multi-chassis switch connections are supported, but the intervening MC1 timeslots must be specified by the application.

In an example system shown in Figure 1, a connection is required between a DSP resource on an AG-8 board and a T1 channel on an AG-T1 board. The DSP resource on the AG-8 is being used to play an "on hold" message for all incoming calls.

Figure 1. An Example System Using Switching



Using CT Access Switching service (SWI) functions to make the connection, an application is required to:


    


  1. Determine if the switch connection can use the local bus or if it requires telephony bus timeslots.
    

    

  2. Determine which telephony bus timeslots are available for the connection.
    

    

  3. Send the switch commands to connect the caller to an available timeslot on the telephony bus.
    

    



    Figure 2.	 Connecting the Caller to the Telephony Bus
    

    

  4. Send the switch commands to connect the DSP resources to the telephony bus.
    

    



    Figure 3.	 Connecting the DSP Resources to the Telephony Bus
    




Using the Point-to-Point Switching service, the application calls one function specifying the location of the DSP resource (i.e., board number, local stream and timeslot) and the location of the caller (i.e., board number, local stream and timeslot). The Point-to-Point Switching service determines the required telephony bus timeslots and makes all the necessary switch connections.






1.3	 About CT Access





The Point-to-Point Switching service is a CT Access service. CT Access is a development environment providing standard programming interfaces that are hardware independent.



A CT Access service is a group of logically related telephony functions. Each service is contained in a service manager, which is a software wrapper surrounding one or more service. The service manager implements binding functions that enable a service to seamlessly integrate into CT Access.






1.4	 Setting Up the CT Access Environment





Before you can call functions from the Point-to-Point Switching service, the application must initialize CT Access and open the Point-to-Point Switching service. Application setup for CT Access consists of the following steps:


    


  1. Initializing CT Access for the process.
    

    

  2. Creating event queues.
    

    

  3. Creating CTA contexts and attaching them to an event queue.
    

    

  4. Opening services on each CTA context.
    







1.4.1	 Initializing CT Access





Register services in the call to ctaInitialize by specifying the service name and service manager name. Only the services initialized in the call to ctaInitialize may be opened by the application.






1.4.2	 Creating Event Queues and CTA Contexts





After initializing CT Access, create the event queues and CTA contexts.



A CTA context organizes services and accompanying resources around a single processing context. A CTA context usually represents an application instance controlling a single telephone call.



An event queue is the communication path from a CT Access service to an application. A CT Access service generates events indicating certain conditions or state changes. An application retrieves the events from the event queue. All Point-to-Point Switching functions are synchronous. Synchronous functions return when the function is complete and do not generate events.



Create one or more event queues by calling ctaCreateQueue. You specify which service managers will be attached to each queue. When you attach or bind a service manager to a queue, you make that service manager available to the queue.



Create a CTA context by calling ctaCreateContext. You provide the queue handle (ctaqueuehd) that was returned from ctaCreateQueue. All events for services on the CTA context will be received in the specified event queue. ctaCreateContext returns a CTA context handle (ctahd).






1.4.3	 Opening Services





Services are opened on a CTA context by calling ctaOpenServices and passing a CTA context handle and a list of service descriptors. A service descriptor specifies the name of the service, service manager, and service-specific arguments.



The Point-to-Point Switching service does not require any service-specific arguments.


Note:  It is unnecessary to open the CT Access Switching service in a Point-to-Point Switching client application unless the application is making calls directly to the Switching service on its own behalf. For example, if the Point-to-Point Switching client application sets the telephony bus clocks and stream speeds, it would use Switching service functions, and, therefore, would need to open the Switching service.


Refer to the CT Access Developer's Reference Manual for details on initializing CT Access, and for programming models you can use.






1.5	 Using Point-to-Point Switching in a CT Access Application





The Point-to-Point Switching service provides functions for making switch connections. When using the Point-to-Point Switching service, all streams and timeslots are addressed using the MVIP-95 switch model.



The CT Access Switching service provides additional functions for configuring telephony bus clocks and stream speed. Use these commands to configure the bus before making any connections. See the Switching Service Developer's Reference Manual for more information.


 







WARNING:







When using the Point-to-Point Switching service, do not use the Switching service to make switch connections. The Point-to-Point Switching service maintains an internal connection database to determine local resource and telephony bus usage. Since connections made with the Switching service are not recorded in this database, you may have unpredictable results. The Point-to-Point Switching service could use timeslots already used by the Switching service and the Switching service could use timeslots already used by the Point-to-Point Switching service.





















1.6	 The Point-to-Point Switching Server





Since the same telephony bus can be used in separate CT Access applications, the Point-to-Point Switching service must be able to manage the bus streams and timeslots across multiple applications. Each instance of the Point-to-Point Switching service that is opened on a CTA context runs as a client process to a PPX server. The PPX server (ppxserv) manages an internal connection database to determine which timeslots are available on the telephony bus and what connections have been made in the system.



As shown in the example in Figure 4, each application creates a CTA context containing the Point-to-Point Switching service, the ADI service, and the Switching service. Opening the Point-to-Point Switching service on the CTA context creates an instance of a client to the PPX server. Each PPX client can be a separate process, but it is not required. A unique PPX client can be associated with each thread running in a single process. 



All commands sent by the applications to the Point-to-Point Switching service are sent by the clients to the PPX server. The PPX server sends the commands to the board using the Switching service functions. Each application does not have to open the Switching service on a CTA context. The PPX server automatically opens an instance of the Switching service.





Figure 4.	 Point-to-Point Switching Server




Before you start up the PPX server:




The Point-to-Point Switching server must be running while any application using the Point-to-Point Switching service is running.



The PPX Service deliverables include two libraries:




The PPX service interface library consists of:




The PPX service implementation library consists of:






1.7	 Using the PPX Server on Windows NT





This section provides instructions for using the PPX server (ppxserv) on Windows NT.






1.7.1	 Controlling the PPX Server Manually





During system development and debugging of the Point-to-Point Switching configuration file, control the PPX server manually so it can be re-started as needed.




To stop the PPX server from the command line, enter:


   ppxstop




The ppxstop utility should be used whenever the server needs to be stopped.  This allows the server to terminate any connections it has established and to release communication resources.






1.7.2	 Using the PPX Server as a Windows NT Service





Once the Point-to-Point Switching configuration file has been verified, install the PPX server as a Windows NT service using the ppxservicecfg utility.  See Section 6.6 for more information on using ppxservicecfg.



If there are connections specified in the PPX configuration file, then all switching drivers must be accessible at the time that PPX is initializing. This requires that the boards be loaded and running before the PPX service is started. In the case of AG boards, the agmon service must be installed and running in order for the PPX service to be started. For more information about agmon, see the AG Runtime Configuration and Developer's Manual. For more information about installing agmon as a Windows NT service, see the CT Access Installation Manual.



Before you run the PPX server, make sure there is a valid Point-to-Point Switching configuration file.



Once the PPX server is installed in the Windows NT registry, run the PPX server as follows:


    


  1. Select Services from the Control Panel. 
    

    

  2. Highlight Point-to-Point Telephony Switching.
    

    

  3. To manually start or stop the PPX server, select Start or Stop.
    

    

  4. To automatically start the PPX server when the system reboots, select Startup and select Automatic as the startup option.
    







1.7.3	 Starting and Stopping the PPX Server





You can also control the PPX server from the command line after it is installed as a Windows NT service. Before you stop the PPX server, shut down all client applications so that all switch connections created by the Point-to-Point Switching clients are automatically broken by the PPX server. 






1.7.4	 Removing the PPX Server from Windows NT Services





To remove the PPX service and reset the Windows NT registry, enter:


  ppxservicecfg -remove






1.8	 Using the PPX Server on UNIX





This section provides instructions for using the PPX server (ppxserv) on UNIX.






1.8.1	 Starting the PPX Server





Before you start the PPX server, make sure there is a valid Point-to-Point Switching configuration file.



To start the PPX server:


    


  1. Log in as root.
    

    

  2. Enter the following:
    

       /opt/nms/bin/ppxserv [options] &

   where options are: 

    


    
 Option
    

    		
 Description
    


    
 -f filename
    

    		
 Specifies the configuration filename.
    Default = /opt/nms/ctaccess/cfg/ppx.cfg
    


    
 -e filename
    

    		
 Specifies the error log filename.
    Default = /opt/nms/ctaccess/ppxerror.log
    


    
 -d filename
    

    		
 Specifies the database output filename.
    Default = /opt/nms/ctaccess/ppxdb.log
    


    
 -l
    

    		
 Turns on the SWI comand logging process.
    Default = OFF
    


    
 -w number
    

    		
 Specifies the line number at which the SWI log file will wrap to start. Default = 2000
    


    
 -s filename
    

    		
 Specifies the SWI command log filename.
    Default = /opt/nms/ctaccess/ppxswi.log
    



    


    

    

    
    







1.8.2	 Stopping the PPX Server





Before you stop the PPX server, shut down all client applications so that all switch connections created by the Point-to-Point Switching clients are automatically broken by the PPX server. 



Run the ppxstop utility whenever the server needs to be stopped.  This allows the server to terminate any connections it has established and release communication resources.  The proper release of the communications resources is imperative for the immediate restart of the server.  When an improper shutdown occurs, a delay of up to five minutes may be required before being able to restart the server.  The PPX error log will show an error returned from tsiIPCCreateAcceptorStream.






1.9	 Using the PPX Initialization Error Log





The PPX server creates an error log file when it is initialized. If the error log file already exists, it appends current information to the existing file. This error file records initialization errors and problems associated with the interpretation of the Point-to-Point Switching configuration file (ppx.cfg). By default, this error file is located as follows:




CT Access applications use the Point-to-Point Switching service API to communicate with the PPX server (ppxserv). The communications mechanism is socket-based and the default port number used is 1110. If you see PPXERR_COMM_FAILURE in the PPX error log when you start up your CT Access application, change the port number to an unused port number. 



To change the port number:


    


  1. Review your system configuration and determine a new port number to use.
    

    

  2. Set the NMS_PPX_COMM environment variable to the new port number, using the appropriate mechanism for your operating system and shell.
    

    

  3. Restart the PPX server and all applications.
    

    
Note:  If the PPX server terminates abnormally, any switch connections that it has established at that time remain in place. Restarting the PPX server will not clear these underlying switch connections. Use the swish utility to reset the switches. 

For example, for an AG-8 board, start up swish and enter the following:
        openswitch  s0 = agsw 0
    resetswitch s0







1.10	 SWI Error Logging





The Point-to-Point Switching service is a layer of software built on top of the Switching Service. It uses the following Switching service functions: 




The Point-to-Point Switching service can log all Switching service function calls to a PPX Switching log file if you pass an optional parameter when you start up the PPX server. It records all Switching service function calls that the PPX server makes, and includes an error indicator when necessary. The error indicator is an asterisk (*) and the actual value from the Switching service is at the end of the line. 



The PPX/Switching log file is located and named as follows:




The log file is circular, which prevents excessive use of disk space. By default, the log file contains the last 2000 Switching service calls made by the PPX server. The Switching service calls are time-stamped so you can track starting and ending points. 



To start the PPX server and enable Switching service logging:




To change the default number of SWI log entries stored in the log:




For example:



To restrict SWI logging to 10,000 entries on a Windows NT system:




To perform the same modification on a Unix system:


    


  1. Log in as root.
    

    

  2. Start the PPX server in the background by entering:
    

       /opt/nms/bin/ppxserv -l -w 10000 &


    
Note:  When you restart the PPX server with logging enabled, it overwrites any existing PPX Switching log files on the system. If you need to preserve your data, back up the log file using a different file name before you restart the PPX server.







1.10.1	 An Example ppxswi.log





This section provides an excerpt from a ppxswi.log file.  The PPX server internally shares open switch handles amongst  all client instances. 


Note:  The ret: value that appears on the line marked by an asterisk is the error return value from the Switching service.


Since this is a circular file, the date-stamp and time-stamp of each issued command are recorded so that you can identify the most recent entries after the file reaches its maximum capacity.


[Fri Jan 22 10:00:20 1999] Switch 0: Handle Opened 0x1
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:0:2 TO LOCAL:5:2
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:4:2 TO LOCAL:1:2
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:2:2 TO LOCAL:7:2
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:6:2 TO LOCAL:3:2
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:0:4 TO LOCAL:5:4
[Fri Jan 22 10:00:20 1999]   swiMakeConnect: hd 0x1 LOCAL:4:4 TO LOCAL:1:4
[Fri Jan 22 10:02:44 1999]   swiMakeConnect: hd 0x1 LOCAL:0:6 TO LOCAL:5:6
[Fri Jan 22 10:03:09 1999] Switch 1: Handle Opened 0x10002
[Fri Jan 22 10:03:09 1999]   swiMakeConnect: hd 0x10002 CTBUS:0:31 TO
                             LOCAL:1:6
[Fri Jan 22 10:03:09 1999]   swiMakeConnect: hd 0x1 LOCAL:0:6 TO CTBUS:0:31
[Fri Jan 22 10:03:14 1999]   swiMakeConnect: hd 0x10002 CTBUS:0:31 TO
                             LOCAL:1:4
[Fri Jan 22 10:07:47 1999]   swiMakeConnect: hd 0x10002 LOCAL:0:0 TO
                             CTBUS:5:0
[Fri Jan 22 10:53:24 1999]   swiDisableOutput: hd 0x10002 CTBUS:5:0
[Fri Jan 22 10:54:03 1999] * swiMakeConnect: hd 0x1 LOCAL:8:0 TO CTBUS:8:0
                             ret: 0x40004







 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



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