Configure Multiple Switches Support

Feature Server supports connection to, and interactions with, multiple SIP Servers—which means support and service for multiple switches.

The Feature Server Dialplan can process requests from different SIP Servers. Feature Server can receive and process data updates for configuration objects that belong to all of the served switches, and can send MWI notifications to any device registered on those switches.

Configuration

Connections

Set of connections to SIP Servers is a part of Feature Server configuration stored in Configuration Server and can be edited in CME.

Changes of SIP Server connections will not be processed by Feature Server on the fly as Feature Server will react on any changes in connections list only after its restarted. Adding a connection to a new switch will trigger initial import of objects belonging to the switch (DNs and Agent Logins). The import will be executed when the Feature Server is stopped and started again.

It is recommended to create all necessary connections to SIP Servers in Feature Server configuration before start of the Feature Server. In case some of connections has been added, removed or changed Feature Server would need to be restarted to apply changes.

You can see the Feature Server configurations with one and with two SIP Server connections on screenshots below.

Configuring Feature Server connections to SIP Servers

Feature Server must be restarted after any changes in connections with SIP Servers. For example, changes such as:

• Adding a new SIP Server connection to Feature Server configuration
• Deleting connection to SIP Server
• Moving a SIP Server connection from one Feature Server to another

Warning logging about changes in connections list

In case any changes in SIP Server connections list have been made in CME then Feature Server will react by additional logging. Feature Server will start writing messages in log till the the particular Feature Server restarted.

An information that significant changes have been made in configuration and a necessity of restart will be written in the Feature Server log.

Warning about Dialplan cannot provide correct instructions based on device state will be written in the Feature Server log.

A Dialplan module will write in dialplan log a warning about DN state has not been retrieved from SIP Server and default device state is used. This warning will be written in dialplan log in case Dialplan will receive XSRequests from SIP Servers which have no connections in particular Feature Server configuration.

Application options & Switch options

In case Feature Server has configured with two or more connections to SIP Servers then switchlevel options will be ignored and applicationlevel options will be used instead.

For backward compatibility switchlevel options will be used in case only one connection to SIP Server is presented in Feature Server configuration. The process of adding and removing connections is described in section Connections. In some environments this change can affect the behavior of system. Such case is described below.

1. Feature Server has one SIP Server connection in configuration.
2. Option playdisclaimer is set to true on switch level. Option playdisclaimer isn't defined on Feature Server application level.
3. Hence a playing disclaimer is enabled in Feature Server.
4. A second connection to another SIP Server has been added to Feature Server according to procedure described in chapter "Configuring Feature Server connections to SIP Servers".
5. As a result playing disclaimer is disabled in Feature Server. (Default value for option playdisclaimer is false)
6. To turn the environment behavior back to expected behavior the option playdisclaimer=true should be created on application level for particular Feature Server.

Dialplan

Feature Server Dialplan will support interaction via XSProtocol with set of SIP Servers at the same time. Feature Server will have ability to process XSRequests from different SIP Servers linked to a different switches.

Configuring Dialplan

How it can be done in current implementation

As it is implemented SIP Server can be connection to external dialplan (Feature Server Dialplan) by dedicated 'dialplan DN' defined on switch. SIP Server can be set up to use external dialplan by assigning option dialplan equal to the name of DialplanDN.

Dialplan-DN has Type 'Voice over IP Service' and should be created on corresponding switch. Dialplan-DN should have couple of Annex options configured.

The first option TServer> servicetype should have the value 'extended'. The second option TServer> url should contain a Dialplan URI. (Example: http://fsserv01: 8800/)

How it should be done in multiple switch environment

The value of url option will be extended by switch name. The switch name will be passed to Feature Server Dialplan as part of url.

The new structure of dialplan url will be the following: http://<FS Server Host>:<Dialplan Port>/<Switch Name>. (Example: http://fsserv01: 8800/switch01)

Processing XSRequests

SIP Server use url of DialplanDN to send XSRequests to Feature Server Dialplan. If switch name is defined in the url of DialplanDN then each HTTP request to dialplan from particular SIP Server will have it.

Each XSRequest will be processed in context of one particular switch. All DNs mentioned in XSResponse as origination or destination and any other DNs configured in Forwarding Rules will be interpreted as DNs located on particular switch.

A switch name which is explicitly defined in HTTP request will always take priority.

For purposes of backward compatibility Feature Server Dialplan will keep the support of input parameter Switch Name. Input parameter value of switch name will be used only in case XSResponse doesn't contain explicitly defined switch name in HTTP request and this Feature Server has only one connection to SIP Server configured.

Device state

Feature Server Dialplan module requests a DN state during the XSRequest processing. Feature Server Dialplan retrieves values of 'oncall', 'ready/not ready' and 'dnd' from SIP Server for particular DN.

To support a proper behavior of Dialplan in multiple switches mode all SIP Servers which have this Feature Server configured as an external dialplan must have ability to provide DN state to the Feature Server.

Data Synchronization with Configuration Server

Initial Import

Switch data will be imported for each switch Feature Server has a connection to. The procedure of data import will be executed in the same manner as it was being done in case of connection to one switch only.

Adding new connection to Feature Server will result in initial import of switch data after restart of the Feature Server.

Runtime Synchronization

All data changes in Configuration Server which are monitored by Feature Server for single connection mode will be monitored for all connections except switch options data. Switch options data will not be tracked in case two or more connections to different switches are configured in Feature Server.

Interoperability between Feature Server and SIP Server via TLib protocol Agent level operations (login/logout, DND, call forward, …) and event monitoring will be supported for all the switches a particular Feature Server connected to.