Starting with sipXecs release 3.10 localization packs can easily be uploaded using the administrator Web interface. A language pack provides localization for the user interface language, voice prompts, dialplans, and local call progress tone settings. Several language packs can be installed at the same time offering an individual choice of language per user. Both the user portal as well as the administrator interface switch language according to local browser settings automatically provided the respective language is installed in the system. The language for voice prompts for the personal voicemail system can be set individually by the user. When a caller is diverted into the voicemail inbox of a particular user, the prompt is then fetched based on the language settings of that user.

All the text strings for the user and admin Web interface are abstracted into simple text files.There is a set of these text files required per language where the text files include simple strings that can be translated without doing any programming. Based on individual browser locale settings a specific language is selected automatically. Therefore, every user can see the Web interface in his or her preferred language.

Voice prompts are recorded and stored as wav files for inclusion into the language pack. There is a list of prompts provided that need to be recorded. And finally the dialplan is a simple XML file that can easily be adapted to represent the requirements of a default local dialplan.

Plug & play management support using phone and gateway plugins

Managing phones and gateways is a key feature of sipXecs. There are over 50 different phone and gateway models from 11 vendors already supported and new ones are added all the time. The management and configuration application of sipXecs auto-discovers phones and gateways on the LAN and adds them to the database. Provisioning a new user with a phone takes no more than three clicks with the entire configuration being created automatically. All you have to do is plug in the phone and power it up. While sipXecs typically auto-generates the entire configuration, the admin is given the ability to go in and change every parameter of a particular phone or gateway manually if necessary. This can be done per device or for a group of devices. Creating a new plugin for a new phone or gateway is easy. All you have to do is create an XML description of the configuration parameters of a particular device and tell the system what format the phone's configuration file is in. The entire user interface is then auto-generated. Simple and easy. It typically takes about 1 week of work to support a new device.

A phone or gateway plugin does not have to offer the full functionality available to be functional or useful. The full capabilities of the sipXecs plug & play management interface include the following:

1. Generation of the basic configuration including line identity, proxy server address and password
2. Allow configuration of softkeys, such as speed dial keys and the BLF presence function
3. Allow the configuration of directory information into the phone
4. Provide management of firmware and firmware upgrades
5. Provide auto-discovery of the device on the LAN

A lot of good examples of existing plugins can be found in the code base. Please note that all plugins are accompanied by respective unit test. Plugins also have to be maintained as vendors upgrade firmware adding features or changing existing ways to configure the devices. The project team mainly focuses test activities on phones from Polyco, Snom, and LG-Nortel. The Audiocodes gateways are particularly well supported. Other plugins are more community maintained.

The Wiki provides more detailed info on how to build and maintain phone plugins or gateway plugins or how to support firmware management .

Redirector plugins provide ultimate flexibility for call routing

Need a new routing rule that is currently not supported by the dialplan? Writing a new redirector plugin is often the answer. Redirector plugins were introduced in the 3.8 release and have since been used quite extensively to extend call routing capabilities of the system. We used a redirector plugin to provide a "Microsoft hack" that allowed correcting a bug in the Exchange SIP implementation. Also, the ENUM and ISN routing capability is implemented in a redirector plugin.

 Existing examples of redirector plugins can be found in the code base.

 Good examples for the use of redirect plugins are also source routing where calls are routed based on incoming Caller ID, or cases where a database lookup is desired to dynamically control routing based on certain aspects of an incoming call.