From TCAPI

Overview

Most telephony configuration software today is written with a specific UI that is designed for a specific switching platform. All user interface features, configuration mechanisms, storage systems, etc. are written with a specific set of applications and hardware in mind, often dead-ending people when they want to customize the system or build "the next new thing".

As an example, if you wanted to design a cool new IVR system, you'd have to choose whether to do it on top of Asterisk, YATE, FreeSWITCH or Cisco IOS, and then you'd be stuck with any baggage that comes from that decision.

With the TCAPI design framework, telephony applications and configurations can be based on a set of pre-existing logic, data models and functionality that are assumed to be standard. For example, we can assume that telephony systems must eventually connect to the public switched telephone network to be truly useful. Your special customization, however, is not likely focused on this particular detail. To save you time, the TCAPI framework already contains functionality to allow for basic connectivity with outside gateways. Instead of inventing these configuration tools, you can focus on the pieces of the project that are more directly linked to your project's goal.

Using TCAPI also gives you the benefit of preparing for future technologies. Modules to provide many standard telephony functions are already built into TCAPI, and if you do not override them they will evolve as new revisions of TCAPI arrive. A practical example is IPv6 - if you program with TCAPI libraries today, your web application will be that much closer to supporting IPv6 tomorrow.

TCAPI MVC Stack

TCAPI is based on the MVC software architectural pattern. Utilizing CakePHP to provide a Ruby-on-Rails style framework, the project adds additional layers to allow for modularity in a variety of places. This allows developers to pick and choose which parts of the base framework they want to modify and enhance.

The complete TCAPI stack is pictured above. Notes:

• The project design follows the MVC architecture
• The AJAX helpers are seperated from the individual UI modules, allowing abstraction of any AJAX layer
• The controller is capable of pulling information from outside sources via calls to PHP features such as LDAP or other native PHP calls (not pushing – that is still done in the model, if at all)

Project Objectives

The core objective is to allow a developer to spend the majority of their time on the "special" parts of the telephony app they want to design.

Development Goals

• Modular design allows for abstraction of UI components and model components
  • Should be able to abstract multiple layers of UI – AJAX/RESTful layer, configuration options layer, menu/modules layer
• Ability for a developer to quickly design a PBX or PBX-like software app with minimal ramp-up
• Ability to utilize pre-built widgets/functions common to all telephony apps (like establishing communication between devices, for example)
• Ability to add modules at any time
• Ability to change or replace functions of the UI without changing functionality of the UI (i.e. swap out the AJAX layer for a different one)
• Overall reduction in ramp-up time for new projects
• Ability to remain relatively backward compatible with initial framework design

User Experience Goals

• Ease of use / friendly interface
• Ability to manage the majority of configuration options within a web-based graphical UI
• Consistent look and feel throughout various modules/widgets
• Ability to move from one telephony system to another and have your configuration files “follow you”
  • Ease transition from system to system
  • Possibly allow a mix of systems to be used at some point
  • Allow for notifications when one system doesn't support features that another does
• Minimize page reloads – AJAX+RESTful interface
• Ability to configure a telephony system from start to finish for basic PBX functionality completely from the UI