Revision as of 01:34, March 4, 2016 by Sschlich (talk | contribs) (→‎Configuring the Feature Server Dialplan)
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

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>

(Example: http://fsserv01: 8800/switch01)

Processing XSRequests

  1. Create the option DialplanDN on the switch.
  2. Assign to it the type Voice over IP Service.
  3. Configure these two Annex options:
  • TServer > servicetype = extended.
  • TServer > URL = <Dialplan URI>. (Example: <tt>http://fsserv01:8800/</tt>)

SIP Servers use the URL of DialplanDN to send XSRequests to the Feature Server Dialplan.
So, if you define the switch name in the URL of DialplanDN, then every HTTP request to dialplan from that particular SIP Server will specify that switch. (That is good, because Feature Server processes each XSRequest in the context of one particular switch: the value of <SwitchName> in the URL.

  • 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 specific switch: the value of <Name of Switch> in the URL.
  • A switch name which is explicitly defined in HTTP request will always take priority, but if you do not define input parameter <Name of Switch> (from the above example), then the Feature Server Dialplan uses the set value of the input parameter SwitchName.

STEVE ASKS: WHAT IS THE SET VALUE OF SWITCHNAME?

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.

Notes on Logging

  • Feature Server logs changes to the SIP Server connections list.
  • Feature Server logs a warning that Dialplan could not provide a device state.
  • 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.

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!