FreePBX 3.0 Design Goals

This serves as an initial white board to create some design goals going into redesigning 3.0.

Frameworks

  • Standardized PHP Framework (Zend?)
  • Standardize fully functional model layer (does not have to be what framework provides, best in class more important)
  • Standardized javascript widget library (Dojo)
    • Q. How about a templating engine?

Telephony Engines

  • Asterisk 1.6+
  • FreeSWITCH 1.0+
  • Try to maintain flexibility to easily incorporate other engines

General Design Goals

  • FreePBX style call flow chaining (keep maximum flexibility)
  • Centralized Extension Registry
  • Centralized Destination Registry
    • properly abstracted from underlying engine
  • Device and User separation (as today)
  • Dial / Feature Contexts
    • allow outbound routes to be applied differently to different groups of extnesions
    • allow feature code restrictions to different groups of extensions
    • consider designing a schema that would facilitate the ability to restrict extension dialing from some groups to others (lower priority)
  • design schema to handle multi-tenant
    • GUI and Dialplan multi-tenant design is NOT a design goal (but schema design will allow for future consideration)
  • Admin and User Portal Same interface, separate what is exposed based on permissions/roles
  • Multi-Admin / multi-input-interface friendly
    • this means intelligence in detecting and warning about changes being made to stale data
  • More Intelligent Apply Configuration Changes reload bar/warning
    • Minimize changes that hit model components that are used as part of call processing
    • Push detection of such live portions at the Model level, automatically
      • provide a form of feedback when making changes to such portions (so admin is aware the change will have some potential immediate effects
      • make sure this is granular (e.g. if making changes on an extension that is not effecting fields that are live, then don't tell the user the changes are going to have some immediate consequences).
      • don't force a reload, make a very evident warning that the PBX is in a more unstable state (e.g. in addition to the Apply Configuration Changes bar that tells them other changes have not taken effect yet).
  • Maintain current design where DB provides storage, changes queue up until they are explicitly applied.
    • this does not exclude having dialplan run out of architectures like realtime in the case of Asterisk, or other dynamic designs (e.g. Curl XML in FreeSWITCH). It just means a separation between config data, and what the PBX is using to make current live routing decisions.
  • DB implementation should be a single DB for all storage (config and live)
    • for Asterisk, this means we will probably force a solution that requires AstDB be replaced (see work oej started connecting AstDB to realtime:AppleRaisin
    • reason to use same as AstDB is to take advantage of built in Asterisk use of AstDB in various applications
    • SEE ALSO: oneDatabase
  • We should keep schema for models that are manipulated/accessed by dialplan in the family/key/value format currently used by AstDB - to help ease interaction with the Asterisk Legacy world
  • Interface (GUI) hooks well designed (different categories, tabs, etc)
  • Dial Plan Categories
    • Inbound Routes and defined hooks
    • Internal Routes and defined hooks
    • Outbound Routes and defined hooks
    • The defined hooks are where other modules can splice in dialplan. The structure of these 3 should be as similar as possible.
  • Design for Phone XML, CTI friendly eco-system
    • e.g. all relevant features accessible through publicly available APIs (with proper version-ing on models so that stale data can be detected)
  • Focus on server side feature control
    • best effort handling of client side features as is the case today (e.g. exclude CF from ring group, easy to do when CF is server side, can be difficult or impossible to control on some engines when feature is client side SIP redirect or equivalent)
  • Focus on SIP phones as primary end point technology
  • GUI Design
    • Web2.0+ (use of technologies like Comet desirable where applicable)
    • improved work flow
      • top down route creation ability (for inbound routes)
        • get around current issues where destinations need to already exist before they can be added
      • would be nice to have a drag and drop call tree route creator
      • wizards where applicable
      • strong focus on End User logical and ease of use GUIs (for non admin related portals sections)