(Page 1 of 1 in this chapter)

Chapter 4

PSTN Interface Control

4.1 Introduction
4.2 Managing the PSTN Interface
4.2.1 Initializing the PSTN
4.2.2 Responding to Calls from the
4.2.3 Responding to Data from TX
4.3 Initializing the PSTN Interface
4.3.1 Creating Event
4.3.2 Creating CTA
4.3.3 Opening CT Access
4.4 Using the CT Access Switching Service
4.4.1 Setting Up Switch Blocks and Making
4.4.2 Nailing-Up Switching
4.4.3 Dynamically Altering Switch
4.4.4 MVIP Stream and Timeslot
4.5 Controlling PSTN Calls
4.5.1 ADI Service Call
4.5.2 Responding to Inbound
4.5.3 Establishing Outbound
4.5.4 Releasing
4.5.5 PSTN Call Control State
4.6 Detecting and Collecting DTMF Tones
4.7 Converting Data with the AG TRAU Service
4.7.1 Loading AG TRAU
4.7.2 Attaching AG TRAU Channels to CTA
4.7.3 Enabling and Disabling AG TRAU

4.1 Introduction

CT Access provides a way for gateway applications to control PSTN half-calls. By using functions from CT Access and its services, Fusion gateway applications can control the flow of PCM voice data to and from PSTNs. Gateway applications also the AG TRAU service to control data conversion from PCM to data packets, and from data packets to PCM as shown in Figure 11.

This section provides an overview of how gateway applications use CT Access and CT Access service functions to control various elements of the PSTN interface.

Note: Host-based Fusion systems use a different model for controlling the PSTN interface. For more information about the model, refer to the Host-based Fusion Developer's Reference Manual.

Figure 11. Fusion Gateway PSTN Interface









Figure 12 shows how a typical gateway application uses functions from CT Access services to perform application initialization and call setup tasks:


 



Figure 12.	 Routine Gateway Application API Calls






4.2	 Managing the PSTN Interface





Fusion applications manage the PSTN interface by performing three sets of tasks: 







4.2.1	 Initializing the PSTN Interface





Fusion gateway applications initialize and configure the PSTN interface as follows:


    


  1. Initializes CT Access.
    

    

  2. Creates CT Access event queues.
    

    

  3. Creates CTA contexts.
    

    

  4. Opens CT Access services (ADI, Switching, AG TRAU, etc.).
    

    

  5. Loads AG TRAU programs.
    

    

  6. Sets up switching between AG-RT channels and TX virtual ports. 
    







4.2.2	 Responding to Calls from the PSTN





The PSTN side of a gateway application responds to calls from the PSTN as follows:


    


  1. Accepts or reject incoming calls from the PSTN.
    

    

  2. Attaches AG TRAU channels to CTA contexts.
    

    

  3. Switches PCM data to AG TRAU programs on AG-RT daughterboards.
    

    

  4. Enables AG TRAU processing on AG TRAU channels (convert PCM data to digital packets).
    




Since switching between the AG-RT daughterboard and TX board is set up during the application initialization process (refer to Section 5.3.1 for details), data is automatically directed from AG TRAU channels to TX virtual ports (through the MVIP bus).






4.2.3	 Responding to Data from TX Boards





The PSTN side of a gateway application responds to voice data from a TX packet network interface board as follows:


    


  1. Receives digital packet data from TX packet network interface boards.
    

    

  2. Attaches AG TRAU channels to CTA contexts.
    

    

  3. Enables TRAU processing on AG TRAU channels (convert packet data to PCM).
    

    

  4. Switches PCM data from AG TRAU channels to AG baseboards.
    

    

  5. Establishes outbound calls to the PSTN for PCM voice data.
    







4.3	 Initializing the PSTN Interface





Before Fusion gateway applications can use CT Access function calls, they initialize CT Access and register its services. To set up the CT Access environment:


    


  1. Initialize CT Access services.
    

    

  2. Create event queues.
    

    

  3. Create CTA contexts (attached to event queues).
    

    

  4. Open services on CTA contexts.
    




Register services by invoking ctaInitialize and specifying the service and service manager names. For example, the Sample Fusion Gateway program uses ctaInitialize to initialize the ADI service (ADI), Switching service (SWI), Voice Message service (VCE), and AG TRAU service (TRAU). 


Note:  Applications can only use functions from services that have been initialized with ctaInitialize. For more information about initializing CT Access, refer to the CT Access Developer's Reference Manual. 





4.3.1	 Creating Event Queues





CTA event queues are communication paths by which CT Access services deliver events to applications. Each processing context is associated with an event queue.



The number of queues an application creates depends on the application programming model. The Fusion Sample Gateway program uses a separate queue to handle the events associated with each telephone call. This allows the program to monitor events on a call-by-call basis. However, gateway applications may also use a single queue to handle events from multiple calls, and then distinguish the events associated with particular calls.



ctaCreateQueue creates an event queue and returns a queue handle that identifies the queue. When creating an event queue, specify which service managers to attach to it. For more information about creating CT Access event queues, refer to the CT Access Developer's Reference Manual.






4.3.2	 Creating CTA Contexts





CTA contexts organize services and accompanying resources around a single processing context. CTA contexts usually represent a single application instance controlling a single telephone call. However, some CTA contexts, such as those associated with AG TRAU Load handles, may control more than one resource. Refer to Section 4.7.1 for more information about managing AG TRAU resources.



Create a CTA context by calling ctaCreateContext and providing the queue handle returned from ctaCreateQueue. All events for services on the CTA context are received in the specified event queue. ctaCreateContext returns a CTA context handle (ctahd). Events communicated back to the application are associated with the CTA handle.






4.3.3	 Opening CT Access Services





Create a CT Access service instance by opening a service on a specific CTA context. A service instance defines a service and its associated resource (for example, MVIP board, stream, and timeslot). Only one instance of a particular type of service can be opened on a specific CTA context. However, multiple types of services can be opened on a single CTA context. For example, the Fusion Sample Gateway opens the AG TRAU service, ADI service, Voice Message service, and Switching service on each CTA context associated with a call.



Open a service on a CTA context by calling ctaOpenServices, and passing a CTA context handle and a list of service descriptors. The service descriptor specifies the name of the service, service manager, and any service-specific arguments.






4.4	 Using the Switching Service





Fusion gateway applications use the MVIP bus to carry data from baseboards to AG-RT daughterboards and back to specific MVIP streams and timeslots. TX board virtual ports transmit and receive data on the same streams and timeslots. 



Fusion gateway applications use the Switching service to configure and control switching between the AG boards used to receive calls and convert data. 


Note:  The information in this section uses the MVIP-90 naming conventions for designating streams and timeslots.


The Switching service provides functions to:










4.4.1	 Setting Up Switch Blocks and Making Connections





A switch block is an MVIP switching entity that allows connections between a network interface, DSP, or other resource and the MVIP bus. swiOpenSwitch opens a switch block on a specified device, associates the switch block with a particular CTA context handle, and returns a switch handle by which to refer to the switch block. swiMakeConnection and swiDisableOutput create and tear down "live" connections through which data passes.



Fusion gateway applications must open switch blocks for AG PSTN line interface boards. Because AG-RT daughterboards use the AG baseboard's (AG-T1/E1 or AG-8) MVIP connection, these daughterboards do not require a separate switch block. Figure 13 shows a typical switch configuration for a Fusion application that uses an AG-T1 board with AG-RT daughterboard, and a TX network interface board. Notice that the connections between the AG-T1 board and the AG-RT board can use local streams.


Note:  Fusion gateway applications that use AG-8/80 DSP boards use MVIP streams (not local streams) to switch data to AG-RT boards. 

 



Figure 13.	 MVIP Switching Between AG Boards and TX Boards




Refer to Appendix B for detailed Fusion gateway system switching diagrams.






4.4.2	 Nailing-Up Switching Connections





Fusion gateway applications can use the Switching service to nail up MVIP connections between AG line interface boards, AG-RT daughterboards, and the MVIP bus. In this scheme, switching is entirely set up in advance. The application opens a switch block on an AG board, and then connects CTA contexts (later associated with PSTN calls) with AG TRAU channels running on AG-RT daughterboards. The gateway application also connects AG TRAU channels to MVIP streams and timeslots over which TX virtual ports receive and transmit data.



This switching model is simple to implement because it creates a series of static "pipes" through which gateway applications can send information. A gateway application only needs to connect data to either end of a pipe (a channel on an AG line interface board or virtual port on a TX Series board). However, this model does not allow the application to alter switching dynamically based on board or system resource availability.


 



Figure 14.	 Nailed Up AG TRAU Switch Connections






4.4.3	 Dynamically Altering Switch Connections





Another way to set up switching is to perform dynamic switching based on telephone interface and data conversion resource availability. This allows applications to establish MVIP connections on an as-needed basis. Controlling switching in this way requires a more elaborate scheme for tracking resources on both sides of the gateway, but allows applications to alter the switching configuration based on resource availability.


 



Figure 15.	 Dynamically Altered Switch Connections



Note:  Even Fusion applications that dynamically alter switch connections usually nail up switching between AG-RT TRAU channels and TX board virtual ports.





4.4.4	 MVIP Stream and Timeslot Allocation





Each AG TRAU program converts a specific number of channels of data from one form to another. Each channel of audio data switched from an AG baseboard to an AG TRAU program uses a single timeslot from an MVIP stream. Therefore, the number of timeslots used to convey PCM data from an AG board to an AG TRAU program (from the PSTN side of the gateway) is equal to the number of channels the AG TRAU program supports. Since different AG TRAU programs support different number of channels, this number may vary.



However, in most cases no matter how many channels an AG TRAU program receives from the PSTN side of the gateway (i.e. from an AG board), the AG program outputs processed data to two timeslots on the MVIP bus. Correspondingly, a TX board virtual port receives data on these two streams and timeslots. 


Note:  For G.711 AG TRAU programs, three channels of audio data are received from the PSTN side of the gateway (on three timeslots), but this data is sent to the packet network side of the gateway on four MVIP timeslots.


The sections that follow provide examples of allocating MVIP timeslots for AG TRAU programs.


 Example: G.723.1 Program



On an AG-RT/2 daughterboard, an AG TRAU G.723.1 program supports three channels of audio data. Each AG TRAU G.723.1 program receives data from the AG baseboard on three MVIP streams and timeslots. After the AG TRAU program processes the data, it assigns the outgoing data to two MVIP timeslots of the same stream. 


 



Figure 16.	 AG TRAU G.723.1 Program on an AG-RT/2 Daughterboard



Note:  AG TRAU G.723.1 programs running on AG-RT boards can receive one channel of audio data per DSP, but still pass the data onto two timeslots of an MVIP stream.

 Example: GSM Programs



On both AG-RT daughterboard and AG-RT/2 daughterboards, AG TRAU GSM programs support four channels of audio data. This data is carried to the AG TRAU GSM program on four MVIP timeslots. However, after converting the PCM data to GSM encoded frames, the AG TRAU program outputs the audio data to two MVIP timeslots. 


 



Figure 17.	 AG TRAU GSM Program on an AG-RT or AG-RT/2 Daughterboard



 Example: G.711 Program




On an AG-RT/2 daughterboard, an AG TRAU G.711 program supports three channels of audio data. Each AG TRAU G.711 program receives data from the AG baseboard on a three MVIP streams and timeslots. After the AG TRAU program processes the data, it assigns the outgoing data to four MVIP timeslots of the same stream. 


 



Figure 18.	 AG TRAU G.711 Program on an AG-RT/2 Daughterboard






4.5	 Controlling PSTN Calls 





The ADI service is a set of functions for performing a wide variety of tasks that use AG board resources. This section provides information about how Fusion gateway applications use ADI service functions to perform two primary tasks:






4.5.1	 ADI Service Call Control





The ADI service call control functions are protocol-independent. Although an application must run a specific telephony protocol, it will use the same ADI service call control functions regardless of which telephony protocol it runs. Applications invoke adiStartProtocol to establish telephony call control protocol. 



Telephone network events and protocol-specific events are mapped to the ADI service call control events, which are semantically identical across all protocols. This independence promotes application portability and accelerates application development.



For more information about starting telephony protocols in CT Access refer to the CT Access Developer's Reference Manual or the ADI Service Developer's Manual.






4.5.2	 Responding to Inbound Calls





The ADI service establishes network-initiated connections for protocols supporting inbound or bidirectional trunks. Once the telephony protocol is started with adiStartProtocol, an application is eligible to receive incoming calls from the PSTN. After an incoming call event is offered to the application, the application is required to either accept the call by calling adiAnswerCall, or reject the call by calling adiRejectCall. If the application does not respond to the event, the call is rejected after a timeout.






4.5.3	 Establishing Outbound Calls





The ADI service can be used to place calls with telephony protocols supporting outbound and bidirectional trunks. After the telephony protocol is started by calling adiStartProtocol, the application is eligible to place calls.



The application places a call by invoking adiPlaceCall, which initiates dialing and call progress analysis. Call progress analysis detects several events (e.g., signaling, tones, voice) received from the telephone network and the remote party. These events indicate the call's progression through the telephone network.



For more information about responding to inbound calls or establishing outbound calls, refer to the CT Access Developer's Reference Manual or ADI Service Developer's Manual.






4.5.4	 Releasing Calls





For the ADI service to release a call, both the application and the telephone network must actively release it. The telephone network can disconnect an incoming call at any time, regardless of the call control state.



After the call is released by both the telephone network and the application, the ADI service generates a call released event. Once the call is released, the application is eligible to receive and place new calls.






4.5.5	 PSTN Call Control State Machine





This section provides a state diagram of ADI service call control functions. The ADI service call state machine is event-driven. The state of a particular call control does not change until a DONE event is received for any function invoked for that call.



The following table shows functions that may be invoked in each call control state:


  





 State



 Pending Command



 Functions Allowed




 Idle



 (none)
Place call
Release



 adiPlaceCall
adiReleaseCall
(none)




 Incoming Call



 (none)
Answer
Reject



 adiAnswerCall, adiRejectCall
adiAnswerCall
(none)




 Answering Call



 (none)
Answer
Release



 adiAnswerCall, adiReleaseCall
adiAnswerCall, adiReleaseCall
(none)




 Placing Call



 (none)
Release



 adiReleaseCall
(none)




 Disconnected



 (none)
Release



 adiReleaseCall
(none)




 Connected



 (none)

Release
Release 2nd
Transfer
Place 2nd call



 adiReleaseCall, adiTransferCall, adiPlaceSecondCall
(none)
adiReleaseCall
adiReleaseCall, adiReleaseSecondCall
adiReleaseCall, adiReleaseSecondCall




 Rejecting



 (none)



 (none)




























Figure 19 shows state transitions for incoming and outgoing PSTN calls:


 



Figure 19.	 Inbound and Outbound Call State Diagram






4.6	 Detecting and Collecting DTMF Tones





DTMF tones are tones that represent digits. Fusion gateway applications use ADI service functions to collect digits. The ADI service provides both synchronous and asynchronous digit collection functions. The ADI service maintains an internal digit queue to store digits that have been entered by the remote party. If the application does not asynchronously collect digits (with adiCollectDigits), any DTMF tones entered by the remote party are appended to the queue.



Synchronous ADI functions allow applications to read, or read and update digits from the digit queue. Refer to the CT Access Developer's Reference Manual or to the ADI Service Developer's Manual for more information about collecting digits.


Note:  By default, DTMF detection is enabled when calls are established. If DTMF detection is disabled, enable it by invoking adiStartDTMFDetector.





4.7	 Converting Data with the AG TRAU Service





The AG TRAU service is a group of logically related functions for controlling TRAU programs that run on AG RealTime (AG-RT) daughterboards. AG TRAU programs process voice data received from PSTN phone calls and IP/LAN sessions. AG TRAU programs encode and decode data according to a variety of algorithms (for example, G.723.1), perform on-board echo cancellation, and perform mu-law or A-law encoding. By performing these operations, AG TRAU programs convert channels of voice data from PCM form into digital packets, and from digital packets to PCM form. 






4.7.1	 Loading AG TRAU Programs





Use trauLoad to download an AG TRAU program to an available AG-RT DSP. trauLoad requires a CTA context handle as one of its arguments. The CTA context must be associated with an open TRAU service instance. This function returns a DSP ID associated with a loaded AG TRAU program on a specific DSP. 



The CTA context handle specified in the trauLoad call is referred to as a load handle (loadhd). All AG TRAU programs loaded with a specific loadhd are organized within the CTA context associated with that handle. These programs may run on a single AG-RT daughterboard, or on different AG-RT daughterboards. Figure 20 shows a Fusion gateway application loading two AG TRAU programs to two DSPs on an AG-RT daughterboard. 


 



Figure 20.	 Loading AG TRAU Programs




When trauLoad executes successfully, it returns a dspid and a TRAUEVN_LOAD_DONE event. The TRAUEVN_LOAD_DONE event returns the following information:


·	 AG-RT daughterboard where the AG TRAU program resides


·	 DSP number of the DSP where the AG TRAU program runs


·	 Type of AG TRAU program loaded




Use trauUnload to stop an AG TRAU program and free its DSP resources. For more information about loading AG TRAU programs, and a list of available AG TRAU programs, refer to the Fusion AG TRAU Developer's Reference Manual.






4.7.2	 Attaching AG TRAU Channels to CTA Contexts





AG TRAU channels are reserved paths for processing voice data received from PSTN and packet network interfaces. Each type of AG TRAU program supports a particular number of channels. For example, on AG-RT/2 daughterboards, AG TRAU GSM programs support four channels of voice data, while AG TRAU G.723.1 programs support three channel of voice data. 



Each AG TRAU channel is associated with a single AG TRAU service instance bound to a CTA context. This model allows you to join several service instances (for example, an ADI service, Switching service, and AG TRAU service) under a single CTA context. You may provide separate CTA event queues for each AG TRAU channel, or provide a single CTA event queue for all AG TRAU channels created with a particular loadhd. 


Note:  Before creating AG TRAU channels, use ctaCreateQueue, ctaOpenServices, and ctaCreateContext to establish required queues, AG TRAU service instances, and CTA contexts for the channels. 


Invoke trauAttach to associate an AG TRAU channel resource with a CTA handle. Use trauDetach with an attached ctahd to free an attached channel from its associated CTA context. 


 Managing AG TRAU Channels



To control the processing of voice data, Fusion gateway applications must keep track of the number and type of available AG TRAU channels. The following table shows AG TRAU functions that provide information about AG TRAU programs and channels:


  





 AG TRAU Function



 Program Information Returned



 Channel Information Returned



 Return Method




 trauLoad 



·	 dspid


·	 Type of program


·	 Board number


·	 DSP number


·	 Number of available channels


·	 Frame/buffer size



 None.



 TRAUEVN_LOAD_DONE 




 trauAttach 



 None.



·	 dspid


·	 Board number


·	 DSP number


·	 Channel number



 *attach_data


  (data structure returned
    synchronously)




 trauShowInfo



·	 loadhd


·	 Type of program


·	 Total channels 


·	 Number of available channels


·	 Frame/buffer size


·	 Underrun data



·	 ctahd


·	 Channel state


·	 Underrun data



 *info


 (data structure returned
    synchronously)
















Tracking the number and type of available AG TRAU channels is important for gateway applications that simultaneously run different kinds of AG TRAU programs (for example, G.723.1 and GSM). If an incoming call (from either the PSTN or packet network interface) requires a specific type of encoder/decoder, the gateway application must be ready to switch the call to an appropriate AG TRAU program.



Use information returned by trauAttach to set up switching to and from DSPs running AG TRAU channels. trauAttach returns the board, DSP, and channel number needed to switch data to an attached AG TRAU channel. Refer to Appendix B for diagrams that show MVIP stream/timeslot to AG TRAU channel mappings.



trauShowInfo returns handle and status information about the AG TRAU program and the channels supported by it. Invoke trauShowInfo by specifying the DSP ID (returned by trauLoad) of a specific AG TRAU program. 



Refer to Appendix B for specific switching information about Fusion systems that use AG-T1 or AG-8 boards. Refer to the Fusion AG TRAU Developer's Reference Manual for more information about AG TRAU commands and events.






4.7.3	 Enabling and Disabling AG TRAU Channels





After AG TRAU channels are attached to specific CTA contexts (with trauAttach), use trauEnable to begin processing voice data on AG TRAU channels. When invoking trauEnable, specify the ctahd of an attached AG TRAU channel.


Note:  Always switch voice data to an AG TRAU channel (from PSTN ports or TX virtual ports) before enabling the channel. 


To stop AG TRAU channels from processing data, use trauDisable and specify the ctahd of an attached AG TRAU channel. 



































 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



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