Telephony Application
The "Telephony Application" a.k.a "Gateway" was designed as a full featured ready-to-use gateway. It bridges incoming calls of any supported protocol to outgoing calls of any signaling protocol. In fact specific signaling protocol knowledge is not required in the application since it routes calls to networks access points. It also adds additional behaviors to calls when needed, for now this is decided by the configuration file but it is dynamic so it could be taken from a database entry representing a specific user account. Billing is not integrated in this application since this is almost always client specific and it did not really help us test the system.
There are multiple goals for this application:
- Help us identify the difficulties clients could face.
- Provide a solid example to clients.
- Test the underlying framework.
- Default application for the standalone product.
This make this application a good starting point for most of client applications. In fact we designed this application so that clients would only need to modify modules this application uses thus it could be used virtually unmodified.
To date this application uses the two following services:
- Bridging service
- Voicemail service
Features
The application has many features that may be modified to suit clients needs. To make this happen, all these features have individual interfaces so their implementation may be changed effortlessly.
Redundancy
If two instances of the application are started, the first one that is started will become the master application and the second will remain in standby. If the master fails, the active calls will be synced on the other application and all new calls will be routed there too. There will be no loss of service and no loss of active calls. A failure is diagnosed when the CMC server has lost communication with the application. Is is also important to note that the the CMC server supports transparent redundancy. Clients have no special code to write to support CMC server redundancy, they just have to make sure they opened two instances. TelcoBridges products (applications and adapters) automatically detect each other by reference to a UDP Port named the "gateway port".
Call routing
To bridge a call correctly, it is important to know where to make the outgoing call. Detailed information can be found in the Call Routing block who’s default implementation will look in the configuration file for routes. Incoming calls for which no route is found will be refused immediately.
Command line interface
The application’s CLI is a one page display of the active calls, the CLI options and a view of the log. It is based on simple C++ wrapper classes for Telcobridge’s clitools library (also add easy multiple page display). The code for pages depends on clitools since a GUI abstraction layer (adding transparent svga or window support) is a project on its own.
Configuration file
The configuration is read from a XML file in the working directory at application startup. This is wrapped in a small configuration file reading framework so that it could be easily changed to another file format. Each part of the application is responsible to read it’s part of the configuration file. The configuration parameters are documented in the configuration file (the default value is fine for most of them). They define parameters like; logging, maximum calls, database, routes and each features specific configuration if appropriate. XML files usually come with a DTD file which describes the format of the XML file. We provide such a file to be able to warn users of an invalid configuration file. The application will continue to run because this is not critical but users should try to correct the error to prevent unexpected behavior.
Logging
The logging is done using System Logging block who’s default implementation is to write to a XML file. A XSL sheet that can transform the log in HTML is provided with the application so that a web browser can be used to look at the log files. This improves readability since it is possible to:
- Add color to trace levels. e.g. red for errors
- Display fields in table columns.
- Sorting could be implemented.
- Some people prefer a browser to a text editor.
Usage
This application may be started like any other application on the current operating system. It requires a configuration file and the DTD file. If a database is required (voicemail requires one), it must be accessible. This is all that is needed but it won’t do much if the system framework is not started (you can find which CMC server the application is attached, if any, at the top of the page). Like most console based programs, the application is controlled by keyboard keys and the possible candidates are listed in the CLI.
Memory is allocated a startup so it’s memory usage should not vary much at runtime.
Caveats
- Routing and ringback tone take their data form the configuration file and store it in memory. This is probably not feasable for big systems so clients will want to replace the memory structure with a custom database fetching mechanism.
- Since calls are synchronized when the application becomes master, it is important to have a good call synchronization algorithm (perhaps storing call states in a database) to prevent loss of call.
Return to the Toolpack User Guide
