Configuring Multiple Switches Support in Feature Server

Feature Server can connect to and interact with multiple SIP Servers—which means support and service for multiple switches, including:

Receiving and processing data updates for configuration objects that belong to all served switches.
Sending MWI notifications to any device that is registered on those switches.
The Feature Server Dialplan can process requests from multiple SIP Servers.

Feature Server configuration settings...

  ...are stored in Configuration Server.
  ...contain connections to SIP Servers.
  ...are editable by Configuration Manager.

You must restart Feature Server to enable changes to SIP Server connections, such as:

Adding a new connection.
Deleting a connection.
Moving a connection to a different Feature Server.

Application options vs. Switch options

Switch level options apply when a Feature Server is connected to a single SIP Server.
Application level options apply when a Feature Server is connected to multiple SIP Servers.

Behavior in these two instances can differ. Consider an example where the option playdisclaimer is set to true on the switch level, but not defined at all on the Feature Server application level.

Playing a disclaimer is enabled when that Feature Server is configured to connect to one SIP Server.
Adding a second SIP Server to the configuration disables playing a disclaimer, because playdisclaimer is not defined for that configuration, and the default is false.

Configuring the Feature Server Dialplan

The Feature Server Dialplan supports XSProtocol for interacting with multiple SIP Servers— processing XSRequests from different SIP Servers that are linked to a different switches. SIP Servers pass the switch name to the Feature Server Dialplan as part of the Dialplan URL, using this format:

http://<FS Server Host>: <Dialplan Port>/<SwitchName>

(For example, http://fsserv01: 8800/switch01)

Defining Dialplan-DN

Create the ?DN? Dialplan-DN on the switch.
Assign to it the type Voice over IP Service.
Inside, configure these two Annex options:

TServer > servicetype = extended.
TServer > URL = <Dialplan URI>. (For example, http://fsserv01:8800/)

Processing XSRequests

SIP Servers use the URL defined byDialplan-DN to send XSRequests to the Feature Server Dialplan.

Thus, when you define the switch name in the URL of Dialplan-DN, every HTTP request to dialplan from that particular SIP Server will specify that switch. That is required, because Feature Server processes each XSRequest in the context of one particular switch: the value of <SwitchName> in the URL format above.

All DNs mentioned in an XSResponse as the origination or the destination (and any other DNs configured in Forwarding Rules) are interpreted as DNs located on that specific switch.
You can explicitly define a switch name in the HTTP request, to take priority. Otherwise the Feature Server Dialplan uses the set value of SwitchName.

Device state

The Feature Server Dialplan requires all connected SIP Servers to report the state of <a particular> DN during XSRequest processing. Expected values are: oncall, ready, not ready and dnd.

Logging

Feature Server logs these events:

Changes to the SIP Server connections list.
When the Dialplan could not provide a device state.

Feature Server uses a default device state in this situation, and writes a warning in the dialplan log if the Dialplan receives XSRequests from SIP Servers that have no connections to this particular Feature Server configuration.

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.