Telephony Application - Revision history

Abrassard: /* Features */

2010-09-13T11:58:19Z

Features

Ktrueman: fixed layout

2009-07-06T18:48:45Z

fixed layout

Ktrueman: /* Features */

2009-05-08T13:58:59Z

Features

Ktrueman: /* Features */

2009-05-08T13:57:42Z

Features

Ktrueman at 13:56, 8 May 2009

2009-05-08T13:56:36Z

Ktrueman at 21:31, 7 May 2009

2009-05-07T21:31:13Z

Ktrueman at 21:11, 7 May 2009

2009-05-07T21:11:14Z

Ktrueman at 21:09, 7 May 2009

2009-05-07T21:09:30Z

Ktrueman at 21:07, 7 May 2009

2009-05-07T21:07:47Z

Ktrueman: New page: x ---- Return to the Toolpack User Guide

2009-05-07T21:05:03Z

New page: x ---- Return to the Toolpack User Guide

New page

x

----

Return to the Toolpack [[User Guide]]

@@ Line 23: / Line 23: @@
 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 shure they opened two instances. TelcoBridges products (applications and adapters) automatically detect each other by reference to a UDP Port named the "gateway port".
+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'''
@@ Line 45: / Line 45: @@
 *Sorting could be implemented.
 *Some people prefer a browser to a text editor.
 == Usage ==

@@ Line 45: / Line 45: @@
 *Sorting could be implemented.
 *Some people prefer a browser to a text editor.
 == Usage ==

@@ Line 39: / Line 39: @@
 '''Logging'''
-The logging is done using System Logging block who’s default implementation is to write to a XML file. A XSL sheet
+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:
 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.

@@ Line 27: / Line 27: @@
 '''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.
+To bridge a call correctly, it is important to know where to make the outgoing call. Detailed information can be found in the [[CallRouting|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'''
@@ Line 46: / Line 46: @@
 *Sorting could be implemented.
 *Some people prefer a browser to a text editor.
 == Usage ==

@@ Line 9: / Line 9: @@
 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.
-So far this application uses the two following services:
+To date this application uses the two following services:
 *Bridging service

@@ Line 1: / Line 1: @@
-The "Telephony Application" a.k.a "Gateway" was designed as a full featured ready-to-use gateway. It bridges incoming
+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.
 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.
+*Help us identify the difficulties clients could face.
-• Test the underlying framework.
+*Provide a solid example to clients.
-• Default application for the standalone product.
+*Test the underlying framework.
-This make this application a good starting point for most of client applications. In fact we designed this application so
+*Default application for the standalone product.
-that clients would only need to modify modules this application uses thus it could be used virtually unmodified.
+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.
 So far this application uses the two following services:
-.1.2 Features
+*Bridging service
 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.

@@ Line 36: / Line 36: @@
 pages depends on clitools since a GUI abstraction layer (adding transparent svga or window support) is a project on
 its own.
-.1.2.5 Logging
+'''Configuration file'''
 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
+*Add color to trace levels. e.g. red for errors
-• Display fields in table columns.
+*Display fields in table columns.
-• Sorting could be implemented.
+*Sorting could be implemented.
-• Some people prefer a browser to a text editor.
+*Some people prefer a browser to a text editor.
-−
@@ Line 66: / Line 59: @@
 *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]]