Revision as of 01:17, March 2, 2016 by Sschlich (talk | contribs) (→‎Application options vs. Switch options)
Jump to: navigation, search

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.


1

The Feature Server Configuration...

  ...is stored in Configuration Server.
  ...contains connections to SIP Servers.
  ...is 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.

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 vs. Switch options

  • Switch level options apply when Features Server is connected to a single SIP Server.
  • Application level options apply when 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 for a Feature Server that is configured to connect to just one SIP Server.
  • Adding a second SIP Server to that configuration disables playing a disclaimer, because playdisclaimer is not defined and the default is false.

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.

Comments or questions about this documentation? Contact us for support!