From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia

[edit] Description

Well defined ideas are managed in the issue tracker under JIRA Roadmap. This page is meant to help track some ideas, encourage collaboratation in development projects with similar agendas and spark some dialog on mailing list.

The SipX Roadmap is updated regularly and reflects work ongoing towards the next release.

NOTE: All the changes that we introduce in the sipXconfig code are the results of implementing user requirements. We do not change the sipXconfig architecture without a user story to be implemented. Every change has a corresponding JIRA issue. The long term goal of the team is to make sipXconfig simpler, more testable and easier to extend. On this page we maintain a registry of ideas of how to get closer to this goal. We may choose to implement some of those opportunistically or, if we deem it important enough, we may dedicate a sprint to implement some of them. Placing items on this list does not however constitute any type of commitment on the sipXconfig team.

[edit] Product Wishlist

1. Provide an API for adding new types of services, like we do now for phones and gateways. sipX family of servers will be implemented using the plugin.
2. Extend the voice mail user portal to become an integrated desktop application that allows click-to-dial from the MS Outlook directory, management of the hard phone directory, control of the hard phone offering URI dialing, simple setup of conference calls (initiated on the PC and picked up on a hard or softphone), voice mail administration integrated into an Outlook folder, call logging, IM session management and logging, presence management, control of follow-me and forwarding services, etc. (How about an Outlook toolbar?)
3. Integration of performance and fault management and respective reporting, both for the user and for the admin (e.g. call statistics, CPU load, failed calls, missed calls, NAGIOS reporting)
4. Control client that runs as a daemon on a PC and allows config server to manage softphone and IM clients. Such a control client would register with ConfigServer and allow profiles to be pulled from ConfigServer. This allows for remote management of voice, video and IM clients by an admin.
5. Plugin system for localization: Language packs have to be installable into a running system without any change to the binary, the installer, the DB schema or other.
6. Automatic update mechanism like Microsoft's "Windows Update" where sipXconfig updates could be downloaded and installed without admin intervention.

[edit] Developer Wishlist

• Devise a layer of abstraction between web pages so that going from Page1 to Page2 then back to Page1 doesn't require Page2 knowing about Page1's name or state. Currently we have setReturnPage(String name), but this only takes you so far. SpringWebFlow integrates into other view technologies, may integrate nicely here because Tapestry does not have any general mechanism for this that I know of.
• Separate components: Currently apache still runs as user sipxchange. We should separate such services and allow apache to run in standard configuration. This would make it a lot easier to integrate sipxpbx as an application into different Linux distributions.
• Speed web page development by not having to build war to run 1 page.
• Create a distributed system:
  1. sipXconfig can run on a separate host
  2. sipXconfig let's you configure how many of each sipX server component are available. This way several instances of the media server, the conference server, and other servers could be run on different machines but part of the same system
  3. sipXconfig would allow management of several complete sipX systems offering service to different domains. That way sipXconfig could be used in a hosting center as the central management system for many independent sipX systems

• Enhance settings model
  • ability to isolate UI description from setting description - at the moment setting description is reflected very closely in UI, you can declare setting as advanced or hidden but you cannot move it to separate page or display it conditionally
  • support for collection of settings (at the moment we only support scalar settings, collections have to be modeled using Java objects)

• Profile generation extension
  • most profile generation code relies on the fact the we create a file or set of files, we might need a more generic concept where profile generation is replaced with "configuration" phase and depending on a phone model configuration might mean different things - generating the file, sending SNMP frames etc.
• remove dependencies on other packages so that one install, build and run sipXconfig without installing building and running other sipX services
  • remove dependency on sipx-config from sipxconfig.sh startup script