This option is for launching the server.

This option is associated with the configuration file explained in Configuration chapter.

This option is for updating TelServer configuration with another installed TelServer configuration.

This option is associated with the configuration file explained in Configuration chapter.

For example, to update TelServer vx.z.b from an installed vx.y.a on a Linux OS, use the command "TelServer.sh -update /opt/uniGone/TelServer/vx.y.a"

This option is for launching the embedded database server. The embedded database server is automatically launched if it is requested by configuration.

This option is associated with the configuration file explained in Configuration chapter.

This option is for launching a command line tool to manages the embedded database.

This option is associated with the configuration file explained in Configuration chapter.

MAY BE UPDATED. This setting defines the name of the file where TelServer finds the logging configuration.

By default, the logging is configured to issue 'debug' information (the logging threshold is set to 'debug') which enables to get useful information at the early stage of deployment. Afterwards, the logging threshold may be configured by the management. It can also be totally configured in the logging properties file. To get more information on the logging properties, you shall refer to Log4J.

The logging configuration file defines three types of logs :

• logging 'debug' level in up to 25 files of a maximum size (20MB),
• logging 'debug' level in a daily rolling file,
• logging 'debug' level to a Syslog system.

If an update of configuration is requested, the logging configuration will be updated too.

The file is searched in the current directory or if not found in the same directory as the configuration file.

Default value is "logging.properties".

Example:

telserver.logging.properties.filename=logging.properties

MAY BE UPDATED. It is the TelServer Administrator email address.

Default value is none.

Example:

telserver.administrator.email.address=peter.admin@thecompany.com

MAY BE UPDATED. It is the smtp host address of the Administrator email server.

Default value is none.

Example:

telserver.administrator.email.smtp.host=smtp.thecompany.com

MAY BE UPDATED. It is the port used by the Administrator email smtp server.

Default value is 25.

Example:

telserver.administrator.email.smtp.port=25

MAY BE UPDATED. It is the "from" field in the emails sent to the Administrator. It must be an email address that doesn't need to be an existing email address but it must be a "well-formed" one.

Default value is "TelServer@unigone.com".

Example:

telserver.administrator.email.from=TelServer@unigone.com

MAY BE UPDATED. It defines the list of addressees of the emails sent to the Administrator by TelServer. The Administrator email address (telserver.administrator.email.address) is automatically added to this list. It is a comma separated list.

Default value is none so that only the Administrator email address is included here.

Example:

telserver.administrator.email.tolist=admin.assistant@thecompany.com

MAY BE UPDATED. It defines the list of carbon-copy addressees of the emails sent to the Administrator by TelServer. It is a comma separated list.

Default is none.

Example:

telserver.administrator.email.cclist=interestedby.TelServer@thecompany.com

This setting defines the userid of the administrator. It may be used to connect to TelServer remote management.

Default is none.

Example:

telserver.administrator.userid=admin

This setting sets the password used in conjonction with the userid defined above. This password must be previously encrypted by the -epwd command in order it is not written in clear text in this file.

Default is none.

Example for the "admin" password:

telserver.administrator.password=6WzEy

This setting defines whether remote management is enabled. Disabling remote management implies that a configuration change can be applied only after a server complete restart.

Default is true.

Example:

telserver.remote_management.enabled=true

This setting defines the local (TelServer machine) TCP port for remote management access. A http server is then running waiting for connections on this port. Access to this server is basically controlled by a username/password.

Default port is 8083. If you use that port, ensure it is not used already by another application.

Example:

telserver.remote_management.port=8083

DEPRECATED: User telserver.administrator.userid in place.

DEPRECATED: User telserver.administrator.password in place.

This setting sets the preferred language for the remote management page. The language can be "en" (english) or "fr" (french).

If no language is specified, TelServer will seek for the local language. If the language is "fr" then the page will be in french otherwise the language will be english.

Example:

telserver.remote_management.language=fr

This setting enables the TelServices gateway.

Supported values are "true" and "false". Default value is "true".

Example:

telserver.TelServicesGateway.enabled=true

This setting defines the local (TelServer machine) TCP port of TelServer for the TelServices gateway. The client has to connect to TelServer hosting machine IP address and this port to benefit of TelServices services.

Optionnally one can precise the backlog (i.e. the maximum connections the server will accept) and the bind address of the TCP port (i.e. the server will listen only to the specified port on this IP address). The bind address can be used on a multi-homed host for a server that will only accept connect requests to one of its addresses.

Default port is 8082. If you use that port, ensure it is not used already by another application.

Examples:

For specifying a listening port for all IP addresses of the machine with a default backlog :

telserver.TelServicesGateway.port=8082

For specifying a listening port for all IP addresses of the machine with a backlog :

telserver.TelServicesGateway.port=8082,50

For specifying a listening port for all IP addresses of the machine with a backlog and a bind address :

telserver.TelServicesGateway.port=8082,50,192.168.0.2

This setting defines the protocol to be used on the TCP port. It can be TCP, SSL or TLS (ignoring case). To define a secure gateway, please refer to the chapter "Secure gateway configuration".

Default protocol is TCP.

Example:

telserver.TelServicesGateway.port.protocol=TCP

This setting defines the keystore path when port protocol is SSL or TLS.

Default path is ${TelServer_HOME}/work/TelServer.jks.

Example:

telserver.TelServicesGateway.port.keystore.path=${TelServer_HOME}/work/TelServer.jks

This setting defines the password of the keystore.

Default is 'unigone'.

Example:

telserver.TelServicesGateway.port.keystore.password=unigone

This setting defines the password of the certificate key in the keystore.

Default is 'telserver'.

Example:

telserver.TelServicesGateway.port.keystore.key.password=telserver

This setting defines the path of the directory where HTML documents delivered by TelServer are standing. The HTML documents are used by the TelServices javascript library or when accessing TelServer from a web browser.

Default value is in '${TelServer_HOME}/work/html'.

Example:

telserver.TelServicesGateway.htdocs.path=/opt/telserver/company/html

This setting defines whether a direct connection to the gateway from a web browser is enabled. If direct connection is disabled, bridge files that are necessary for making TelServices javascript clients work will still be delivered by TelServer but others will be rejected by a 404 error.

Default value is true.

Example:

telserver.TelServicesGateway.htdocs.direct_access.enabled=true

This setting defines the sequence of characters that would be written at the end of the XML TelServices encoding, when using the TelServices protocol directly over TCP and UDP. The end of PDU is a sequence of characters that is added to results to TelServices requests over TCP as well as to events send over UDP. The endOfPDU, if added at the end of a TelServices request encoding sent by the client, is ignored.

NOTE: this does not apply if HTTP is used.

Default value is that no end of PDU is written.

Example:

telserver.TelServices.endOfPDU.sequence=\r\n

This setting defines the number of threads that are launched by advance waiting for TelServices clients connections. The threads are launched by advance to avoid the overhead of thread creation when a client connects. This doesn't prevent other connections but additional connections will create additional threads.

Default value is 20. Minimum value is 5.

Example:

telserver.workers.pool.limit=20

This setting defines the TCP SO timeout. It is the time that a worker thread should block while reading from a client connection, before it times out and closes a connection. Without this timeout, a worker thread could be tied up indefinitely waiting for a client to issue a request. The value is in milliseconds.

Default is 5000 for 5 seconds. Minimum value is 1000 ms.

Example:

telserver.workers.so.timeout=5000

This setting enables the SIP/CSTA gateway.

Supported values are "true" and "false". Default value is "true".

Example:

telserver.SIPCSTAGateway.enabled=true

This setting defines the local (TelServer machine) TCP port of TelServer for the SIP/CSTA gateway. The SIP UA has to connect to TelServer hosting machine IP address and this port to benefit of the SIP/CSTA gateway services.

Optionnally one can precise the backlog (i.e. the maximum connections the server will accept to queue) and the bind address of the TCP port (i.e. the server will listen only to the specified port on this IP address). The bind address can be used on a multi-homed host for a server that will only accept connect requests to one of its addresses.

Default port is 5161. If you use that port, ensure it is not used already by another application.

Examples:

For specifying a listening port for all IP addresses of the machine with a default backlog :

telserver.SIPCSTAGateway.port=5161

For specifying a listening port for all IP addresses of the machine with a backlog :

telserver.SIPCSTAGateway.port=5161,50

For specifying a listening port for all IP addresses of the machine with a backlog and a bind address :

telserver.SIPCSTAGateway.port=5161,50,192.168.0.2

This setting defines the protocol to be used on the TCP port. It can be TCP, SSL or TLS (ignoring case). To define a secure gateway, please refer to the chapter "Secure gateway configuration".

Default protocol is TCP.

Example:

telserver.SIPCSTAGateway.port.protocol=TCP

This setting defines the keystore path when port protocol is SSL or TLS.

Default path is ${TelServer_HOME}/work/TelServer.jks.

Example:

telserver.SIPCSTAGateway.port.keystore.path=${TelServer_HOME}/work/TelServer.jks

This setting defines the password of the keystore.

Default is 'unigone'.

Example:

telserver.SIPCSTAGateway.port.keystore.password=unigone

This setting defines the password of the certificate key in the keystore.

Default is 'telserver'.

Example:

telserver.SIPCSTAGateway.port.keystore.key.password=telserver

This setting enables the CSTAp2 gateway.

Supported values are "true" and "false". Default value is "false".

Example:

telserver.CSTAp2Gateway.enabled=true

This setting defines the local (TelServer machine) TCP port of TelServer for the CSTAp2 gateway. The client has to connect to TelServer hosting machine IP address and this port to benefit of the CSTAp2 gateway services.

Optionnally one can precise the backlog (i.e. the maximum connections the server will accept to queue) and the bind address of the TCP port (i.e. the server will listen only to the specified port on this IP address). The bind address can be used on a multi-homed host for a server that will only accept connect requests to one of its addresses.

Default port is 2555. If you use that port, ensure it is not used already by another application.

Examples:

For specifying a listening port for all IP addresses of the machine with a default backlog :

telserver.CSTAp2Gateway.port=2555

For specifying a listening port for all IP addresses of the machine with a backlog :

telserver.CSTAp2Gateway.port=2555,50

For specifying a listening port for all IP addresses of the machine with a backlog and a bind address :

telserver.CSTAp2Gateway.port=2555,50,192.168.0.2

This setting defines the protocol to be used on the TCP port. It can be TCP, SSL or TLS (ignoring case). To define a secure gateway, please refer to the chapter "Secure gateway configuration".

Default protocol is TCP.

Example:

telserver.CSTAp2Gateway.port.protocol=TCP

This setting defines the keystore path when port protocol is SSL or TLS.

Default path is ${TelServer_HOME}/work/TelServer.jks.

Example:

telserver.CSTAp2Gateway.port.keystore.path=${TelServer_HOME}/work/TelServer.jks

This setting defines the password of the keystore.

Default is 'unigone'.

Example:

telserver.CSTAp2Gateway.port.keystore.password=unigone

This setting defines the password of the certificate key in the keystore.

Default is 'telserver'.

Example:

telserver.CSTAp2Gateway.port.keystore.key.password=telserver

This setting defines whether the CSTAp2 gateway handles the client TCP connection as a mutliplex of devices, i.e. multiplexing all messages for all devices within the same TCP connection. This is the normal way to handle a CSTA connection (ROSE envelope and events cross reference identifiers allow the client to separate the data stream). However, acting in non multiplexer mode allows first party application easily : the application monitors a device only and receives results and events concerning that device only.

Supported values are "true" and "false". Default value is "true".

Example:

telserver.CSTAp2Gateway.multiplexer.enabled=true

This setting is used for starting TelServer embedded database (HSQLDB) if it is used. It defines the path where the database server will store data.

Default value is ${TelServer_HOME}/../data/telserver meaning that database files will be stored in the directory containing TelServer versions in a sub-directory named 'data' with database file names starting by telserver. Assuming that the installation structure is the default structure with ${TelServer_HOME} ending by "/vx.y.z" where vx.y.z is TelServer's version, the database is thus by default shared by all versions of TelServer.

Example:

telserver.data.path=${TelServer_HOME}/../data/telserver

This setting is used for passing parameters to the Java command launching the HSQLDB process. It is the same usage as for a standard Java command and must be adapted to the main JVM (which is used to launch TelServer) usage.

Default value is none. For example, with a SUN JVM, one can use -Xmx256M for a 256MB maximum memory allocation pool size.

Example:

telserver.data.JVM.args=-Xmx256M

This setting is used for starting TelServer embedded database (HSQLDB) if it is used. It defines the properties of the database as specified by HSQLDB as a ';' separated key=value pairs list.

Default value is hsqldb.cache_file_scale=8 for allowing data file up to 8GB.

Example:

telserver.data.properties=hsqldb.cache_file_scale=8

This setting is used for starting TelServer embedded database (HSQLDB) if it is used. It defines the port the database will use for JDBC connections.

Default value is 9001.

Example:

telserver.data.jdbc.port=9001

MAY BE UPDATED. This setting defines whether the history database is enabled or not.

Default value is true.

Example:

telserver.data.history.enabled=true

MAY BE UPDATED. This setting defines whether the history database is the embedded database.

Default value is true.

Example:

telserver.data.history.embedded=true

MAY BE UPDATED. This setting defines the driver class name to use to connect to the SGDB. It may be TelServer embedded database (HSQLDB). It may also be any application database. Generally a JDBC driver is provided for each SGDB vendor. The class must be found in the classpath of TelServer.

Default value is org.hsqldb.jdbcDriver.

Example: this setting defines the driver class name for HSQLDB database that can be installed by TelServer commands.

telserver.data.history.jdbc.driver.classname=org.hsqldb.jdbcDriver

MAY BE UPDATED. This setting defines the URL to connect to the database. It must be in the form jdbc:subprotocol:subname where subprotocol:subname is the name of the pilot to be used.

Default value is jdbc:hsqldb:hsql://localhost/telserver.

Example: this setting defines the URL for TelServer embedded database.

telserver.data.history.jdbc.connection.url=jdbc:hsqldb:hsql://localhost/telserver

MAY BE UPDATED. This setting defines the username to be used to connect the SGDB. If the database is the application database, this user should have the rights to insert data into the specified tables as well as read data from them. For TelServer embedded database it is 'telserver'.

Example:

telserver.data.history.jdbc.connection.username=telserver

MAY BE UPDATED. This setting defines the password for the previously defined username. For TelServer embedded database it is 'telserver'.

Example:

telserver.data.history.jdbc.connection.password=telserver

MAY BE UPDATED. This setting defines the SQL structure of the history table containing the call and optionnally the agent records. It is defined through the INSERT command. The command must use the SQL syntax with column names. This setting is simply used to extract the table name, the columns names and control the data types. The INTO keyword is required.

The following variables can be used (optional ones can be absent from the table). The main data type is given in parenthesis (constraints can be applied).

• %userid% (VARCHAR): the user id,
• %usernumber% (VARCHAR): the user phone number,
• %creationdate% (VARCHAR): the date of creation of the call,
• %creationtime% (VARCHAR): the time of creation of the call,
• %otherpartynumber% (VARCHAR): the other party number,
• %duration% (INTEGER): duration of the communication (connected call),
• %outgoing% (TINYINT): whether the call is an outgoing call (value is 1) or not (any other value),
• %connected% (TINYINT): whether the call has connected (value is 1) or not (any other value),
• %cause% (INTEGER): the cause of the record,
• OPTIONAL: %alertingDuration% (INTEGER): duration of the alerting phase of the call (only incoming calls),
• OPTIONAL: %otherpartyname% (VARCHAR): the other party name,
• OPTIONAL: %otherpartycompany% (VARCHAR): the other party company,
• OPTIONAL: %otherpartynumbertype% (TINYINT): the other party number type (being 0 for a work phone number, 1 for a home phone number, 2 for a mobile phone number and 3 for an IP phone number),
• OPTIONAL: %extradata% (VARCHAR): the optional extra data associated to the first other party of the call,
• OPTIONAL: %callreference% (VARCHAR): the PBX call reference for that call,
• OPTIONAL: %oldcallreference% (VARCHAR): the PBX old call reference for that call (when a transfer or a conference has occured),
• OPTIONAL: %firstcallednumber% (VARCHAR): the first number that has been involved in the call (PBX provided),
• OPTIONAL: %lastredirectionnumber% (VARCHAR): the last number from which the call has been redirected (PBX provided),
• OPTIONAL: %agentstate% (INTEGER): the new state of the agent.

Example: this setting defines the table structure with TelServer embedded database (it is a single line or it may be split with the '\' character).

telserver.data.history.jdbc.sql_insert=INSERT INTO history (userid, usernumber, creationdate, creationtime, otherpartynumber, otherpartyname, otherpartycompany,
otherpartynumbertype, alertingduration, duration, outgoing, connected, cause, extradata, callreference, oldcallreference, firstcallednumber, lastredirectionnumber, agentstate)
VALUES('%userid%','%usernumber%','%creationdate%','%creationtime%','%otherpartynumber%','%otherpartyname%','%otherpartycompany%',%otherpartynumbertype%,%alertingduration%,
%duration%,%outgoing%,%connected%,%cause%,'%extradata%','%callreference%','%oldcallreference%',%agentstate%);

MAY BE UPDATED. This setting defines the SQL that will be used to create the history table. It should be written in accordance with the defined SQL INSERT command.

The default is for the default TelServer embedded database.

Example: this setting defines the embedded database table creation (it is a single line or it may be split with the '\' character). It also contains indexes creations.

telserver.data.history.jdbc.sql_create=CREATE CACHED TABLE history (id BIGINT IDENTITY, userid VARCHAR(36), usernumber VARCHAR(10), creationdate VARCHAR(10), creationtime VARCHAR(8),
otherpartynumber VARCHAR(25), otherpartyname VARCHAR_IGNORECASE(100), otherpartycompany VARCHAR_IGNORECASE(80), otherpartynumbertype TINYINT, alertingduration INTEGER, duration INTEGER,
outgoing TINYINT, connected TINYINT, cause INTEGER, extradata VARCHAR(50), callreference VARCHAR(128), agentstate INTEGER);
CREATE INDEX history_creationdate_idx ON history (creationdate);CREATE INDEX history_creationtime_idx ON history (creationtime);
CREATE INDEX history_userid_idx ON history (userid);CREATE INDEX history_usernumber_idx ON history (usernumber);

MAY BE UPDATED. This setting defines the SQL that will be used to alter the history table if it is already existing. It should be written in accordance with the defined SQL INSERT command.

The default is for the default TelServer embedded database.

Example: this defines the ALTER command to add some columns.

telserver.data.history.jdbc.sql_alter=ALTER TABLE history ADD oldcallreference VARCHAR(128);ALTER TABLE history ADD firstcallednumber VARCHAR(25);ALTER TABLE history ADD lastredirectionnumber VARCHAR(25);

MAY BE UPDATED. This setting defines the record date format.

Default is "yyyy-MM-dd".

Example:

telserver.data.history.date.format=yyyyMMdd

MAY BE UPDATED. This setting defines the record time format.

Default is "HH:mm:ss".

Example:

telserver.data.history.time.format=HHmmss

MAY BE UPDATED. This setting defines the hour of the day (in the format 00:00:00) at which the SQL purge command will be issued each day.

Default is "00:00:00".

Example:

telserver.data.history.jdbc.sql_purge.hour=00:00:00

MAY BE UPDATED. This setting defines the SQL command issued at each .

Default is DELETE FROM history WHERE DAY(creationdate) < DAY(CURDATE()) - 180; to delete all records older than 180 days.

Example:

telserver.data.history.jdbc.sql_purge=DELETE FROM history WHERE DAY(creationdate) < DAY(CURDATE()) - 180;

MAY BE UPDATED. This setting defines whether the private calls are hidden when the history is viewed through the management pages.

Default value is true.

Example:

telserver.data.history.hide_private_calls_in_management.enabled=true

MAY BE UPDATED. This setting defines whether the user_directory database is enabled or not. The user_directory database is used to store a private directory for a user. The private directory is filled by UpdateUserDirectory requests.

Default value is true.

Example:

telserver.data.user_directory.enabled=true

MAY BE UPDATED. This setting defines whether the user_directory database is the embedded database.

Default value is true.

Example:

telserver.data.history.embedded=true

MAY BE UPDATED. This setting defines the driver class name to use to connect to the SGDB. It may be TelServer embedded database (HSQLDB). It may also be any application database. Generally a JDBC driver is provided for each SGDB vendor. The class must be found in the classpath of TelServer.

Default value is org.hsqldb.jdbcDriver.

Example: this setting defines the driver class name for HSQLDB database that can be installed by TelServer commands.

telserver.data.user_directory.jdbc.driver.classname=org.hsqldb.jdbcDriver

MAY BE UPDATED. This setting defines the URL to connect to the database. It must be in the form jdbc:subprotocol:subname where subprotocol:subname is the name of the pilot to be used.

Default value is jdbc:hsqldb:hsql://localhost/telserver.

Example: this setting defines the URL for TelServer embedded database.

telserver.data.user_directory.jdbc.connection.url=jdbc:hsqldb:hsql://localhost/telserver

MAY BE UPDATED. This setting defines the username to be used to connect the SGDB. If the database is the application database, this user should have the rights to insert data into the specified tables as well as read data from them. For TelServer embedded database it is 'telserver'.

Example:

telserver.data.user_directory.jdbc.connection.username=telserver

MAY BE UPDATED. This setting defines the password for the previously defined username. For TelServer embedded database it is 'telserver'.

Example:

telserver.data.user_directory.jdbc.connection.password=telserver

MAY BE UPDATED. This setting defines the SQL structure of the user_directory table containing the directory records. It is defined through the INSERT command. The command must use the SQL syntax with column names. This setting is simply used to extract the table name, the columns names and control the data types. The INTO keyword is required.

The following variables can be used (optional ones can be absent from the table). The main data type is given in parenthesis (constraints can be applied).

• %userid% (VARCHAR): the user id,
• %otherpartynumber% (VARCHAR): the other party number,
• %otherpartyname% (VARCHAR): the other party name (as a full name),
• %otherpartycompany% (VARCHAR): the other party company,
• %otherpartynumbertype% (TINYINT): the other party number type (being 0 for a work phone number, 1 for a home phone number, 2 for a mobile phone number and 3 for an IP phone number).

Example: this setting defines the table structure with TelServer embedded database (it is a single line or it may be split with the '\' character).

telserver.data.history.jdbc.sql_insert=INSERT INTO user_directory (userid, directoryname, otherpartynumber, otherpartyname, otherpartycompany, otherpartynumbertype) VALUES('%userid%','%directoryname%','%otherpartynumber%','%otherpartyname%','%otherpartycompany%',%otherpartynumbertype%);

Note: a template JDBC directory cache is created in relation to the 'user_directory' database settings. Conversion patterns may be modified.

telserver.directory.user_directory.jdbc.phoneNumber.conversionPatterns.1=        

MAY BE UPDATED. This setting defines the SQL that will be used to create the user_directory table. It should be written in accordance with the defined SQL INSERT command.

The default is for the default TelServer embedded database.

Example: this setting defines the embedded database table creation (it is a single line or it may be split with the '\' character). It also contains index creations.

telserver.data.history.jdbc.sql_create=CREATE CACHED TABLE user_directory (id BIGINT IDENTITY, userid VARCHAR(36), directoryname VARCHAR(20), otherpartynumber VARCHAR(25), otherpartyname VARCHAR_IGNORECASE(100), otherpartycompany VARCHAR_IGNORECASE(80), otherpartynumbertype TINYINT);CREATE INDEX user_directory_userid_idx ON user_directory (userid);

MAY BE UPDATED. Used by TelServices gateway. This setting defines whether the administrator remote management username can be used as a userid to be authenticated when opening a session.

Supported values are "true" and "false". Default value is "true".

Example:

telserver.sessions.user_authentication_by_administrator.enabled=true

This setting defines the userid that can be used to authenticate a user when opening a session.

Default is none so that no username/password is required to open a session.

Example:

telserver.user_authentication.administrator.userid=admin

This setting sets the password used in conjonction with the userid defined above for authenticating users when opening a session. This password must be previously encrypted by the -epwd command in order it is not written in clear text in this file.

Default is none.

Example for the "admin" password:

telserver.user_authentication.administrator.password=6WzEy

MAY BE UPDATED. Used by TelServices gateway. This setting defines whether the TelServices QualifyCall request should lead to an automatic AnswerCall if the request selects this option (the option is part of the TelServices QualifyCall request). If the setting is true and if the request has indicated the option, the server will launch an AnswerCall command on the PBX if the current call is not already in the CONNECTED state.

Supported values are "true" and "false". Default value is "true".

Example:

telserver.sessions.answerCall_on_QualifyCall.enabled=true

MAY BE UPDATED. It defines the timeout after which the local connection is automatically cleared if the other party has dropped. The value is in milliseconds.

The default value is '-1' for no automatic clearing.

Example:

telserver.sessions.automatic_clear_local_connection.timeout=0

MAY BE UPDATED. It specifies whether the TelServices protocol should report the permitted agent states according to TelServer's model, when the agent state is provided by the PBX. In particular, if true, this allows the TSWidget tool to propose only the permitted agent state options to the user.

The default value is true.

Example:

telserver.sessions.permitted_agent_states_if_agent_state_by_pbx.enabled=true

MAY BE UPDATED. It defines whether the correlator data can be treated as the calling device when it is provided through the link in specific CSTA events such as Delivered or Established. This is useful to know the calling device as soon as possible before the actual transfer takes place.

In particular, this is useful on Alcatel PBXs for devices that belong to an ACD. It is recommended to set the setting to 'true' in this situation.

The default value is false.

Example:

telserver.sessions.correlator_data_as_calling_device.enabled=false

MAY BE UPDATED. It defines whether an inactive HTTP agent session should be closed. If not closed, the agent is moved 'loggedOff'. The period of inactivity depends on the timeout of the long polling period (twice that timeout is used - by default 120 seconds).

The default value is false.

Example:

telserver.sessions.http.inactive_agent_session_close.enabled=false

MAY BE UPDATED. It defines whether the HTTP long polling mechanism is performed in background or not.

• If background polling is enabled: the HTTP client maintains a background HTTP connexion opened to perform the long polling used to get the events. If a request is to be sent, the background polling is not interrupted, which makes two TCP connections opened in the browser during the time of the request.
• If background polling is not enabled: the long polling is interrupted by a request which makes only one TCP connections opened during the time of the request.

The default value is true.

Example:

telserver.sessions.http.background_polling.enabled=false

MAY BE UPDATED. It defines whether the first other party number should be provided on the consulted device. This allows the consulted device to be aware of the calling (or called) customer when consulted by a fellow agent.

The default value is false.

Example:

telserver.sessions.first_other_party_on_consulted_device.enabled=false

MAY BE UPDATED. It defines the period of sessions call contexts synchronization with the PBX. The synchronization is efficient if the pbxlink.pbx.csta.snapshotDevice.enabled setting is set to true. The defined period is in milliseconds.

The default value is none. It must be greater than 5000.

Example:

telserver.sessions.call_contexts_synchronization.period=60000

MAY BE UPDATED. It defines the limit of history record requested to the database.

The default value is 100.

Example:

telserver.sessions.queryHistory.result.limit=100

MAY BE UPDATED. It defines if the user_directory feature is enabled for users.

The default value is false.

Example:

telserver.sessions.user_directory.enabled=false

MAY BE UPDATED. It defines the list of directories that will be used as user directories. It is a list of comma separated values.The list is in addition to the user_directory directory which is automatically defined if the user_directory database is enabled. It allows the definition of user directories defined externally.

The default value is none.

Example:

telserver.sessions.user_directory.directories.list=

MAY BE UPDATED. This setting defines the service of the routing point. It should be correlated to the service of agents handling calls for that routing point. The service is mandatory and several routing points are defined, all routing points should get a distinct service.

The setting may contain or be equal to the variable "%name%". This implies that the service name will be set at the creation of the routing point. It is used for outbound campaigns when the name of the campaign is used to build the service name.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.service=commercial

MAY BE UPDATED. This setting defines the main number of the routing point. If defined, this number must exist within the PBX. Generally, this number is a virtual number within the PBX where the call should stay a minimum time before being routed by the PBX (without an immediate forward). During this time TelServer routing logic is applied.

The number may not be defined. Such is the case for routing points serving oubound campaigns in 'preview-auto' mode (the call is launched directly from the agent).

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.number=500

MAY BE UPDATED. For an outbound routing point only, this setting defines the time after which the service is closed by TelServer. Normally, an outbound service is closed by the application, this timeout is a safety timeout for being sure the service is closed.

The value is given in hours. The value is none.

Example:

telserver.routing.point.myRoutingPoint.service.timeout=12

MAY BE UPDATED. This setting defines the comma separated list of intervals of hours in the day (0 to 24) when the routing point is working (opened). Intervals are defined as a start hour and an end hour separated by a '/'. Outside working hours during the working days the calls are routed to the telserver.routing.point.routingPoint.non_working_hours_routes.list route.

Default value is none.

Example: this defines two intervals in the day, from 8H30 to 12 and from 14H15 to 18.

telserver.routing.point.myRoutingPoint.working.hours=8:30/12,14:15/18

MAY BE UPDATED. This setting defines the non working days of the week as a list of comma separated numbers (1 for Sunday, 2 for Monday,... and 7 for Saturday).

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.non_working.days_of_week=1,7

MAY BE UPDATED. This setting defines the comma separated list of non working days of the year. Each day is an optional year (yyyy) followed by a '-', a month (1 to 12) followed by a '-' and a day (1 to 31). The pattern is [yyyy-]MM-dd. It can be an interval as a start day and an end day separated by a '/'. Limits are included.

Default value is none.

Example: Every 25th of December and from the 26th December 2010 included to the 2nd January 2011 included are not worked.

telserver.routing.point.myRoutingPoint.non_working.days=12-25,2010-12-26/2011-01-02

MAY BE UPDATED. For an inbound routing point, this setting defines the time a call is enabled to stay on the routing point (i.e. queued or alerting an agent) without being answered by an agent. After that time, the call is diverted to the failure route. For an outbound routing point, this setting defines the time an outbound call is enabled to alert the destination before answer.

The value is given in seconds. Default value is:

• for an inbound routing point: 30 seconds, or
• for an outbound routing point: 15 seconds.

Example:

telserver.routing.point.myRoutingPoint.no_answer.timeout=30

MAY BE UPDATED. For an inbound routing point, this setting defines the time a call handled by this routing point is enabled to stay on an agent without being answered. After that time, the call is diverted to the next agent ready for treating calls for that routing point. If no available agent is found the call is diverted to the failure route.

The value is given in seconds. Default value is:

• for an inbound routing point: 15 seconds, or
• for an outbound routing point: useless.

Example:

telserver.routing.point.myRoutingPoint.agent.no_answer.timeout=15

MAY BE UPDATED. For an outbound routing point, this setting defines the time between two call retries if the last attempt was unsuccessful.

It is in seconds. Default value is none.

Example:

telserver.routing.point.myRoutingPoint.failed_call_retry.timeout=30

MAY BE UPDATED. For an outbound routing point, this setting defines the count of retries after the initial call before an outbound campaign call is qualified.

Default value is none. A value of 3 means that the call may be attempted 4 times.

Example:

telserver.routing.point.myRoutingPoint.failed_call_retry.limit=3

MAY BE UPDATED. This setting defines the timeout for the "working after call" state of an agent. The time starts once a call has been cleared by the agent and during that time the agent will not receive any call from the routing point. After that time, the agent is moved ready again and can receive further calls. A value of "-1" means an infinite timeout which means that the agent must exit this mode by himself. A value of "0" means that the agent becomes immediately "ready" after the call ends up.

The value is given in seconds. Default value is:

• for an inbound routing point: 5 seconds, or
• for an outbound routing point: 20 seconds.

Example:

telserver.routing.point.myRoutingPoint.agent.working_after_call.timeout=5

MAY BE UPDATED. This setting defines the limit of the queue. It is defined as a percentage of the busy or working after call agents. When a call arrives on the routing point, if no agent is available, the call is queued if the number of calls currently in queue is less than the number of busy or working after call agents. If the call cannot be queued because the limit of queued calls is reached, the call is routed to the failure route.

Default value is 100 authorizing to queue as many calls as there are busy or working after call agents.

Example:

telserver.routing.point.myRoutingPoint.queue.limit=100

MAY BE UPDATED. It defines whether the agent is automatically logged on as soon as the agent opens the session.

The default value is true.

Example:

telserver.routing.point.myRoutingPoint.agent.logged_on_on_OpenSession.enabled=true

MAY BE UPDATED. It defines whether the agent state is moved to 'ready' as soon as the agent logs on.

The default value is true.

Example:

telserver.routing.point.myRoutingPoint.agent.ready_on_logged_on.enabled=true

MAY BE UPDATED. This setting defines the method that is used by TelServer to order the PBX to route the call to the provided route. This depends on how the PBX accepts routing orders : it can either let TelServer divert the call or actively request a route from TelServer.

Values can be "DivertCall", "RouteRequest" for inbound routing points or "MakeCall" for outbound routing points. Default value is "DivertCall".

Example:

telserver.routing.point.myRoutingPoint.pbxlink.method=DivertCall

MAY BE UPDATED. This setting defines how TelServer will search the agent number (the route). The search can be:

• "local": the route is obtained, for an inbound routing point, through the "customer" directories (if it contains assigned or skilled agents) or, for an outbound routing point, through call directories.
  
• "http": the route for a given calling number is obtained using a HTTP request with the calling number as a parameter (for an inbound directory only).

Default value is "local".

Example:

telserver.routing.point.myRoutingPoint.routeLookup.method=local

MAY BE UPDATED. If the route lookup method has been defined as being "local", this setting defines the list of directories (comma separated) where this routing point searches information. This setting is mandatory. It should contain a customer directory or an agent directory (both in the general case) for an inbound routing point or a call directory and an agent directory for an outbound directory.

Default is empty.

Example:

telserver.routing.point.myRoutingPoint.routeLookup.method.local.directories.list=myDirJdbc

MAY BE UPDATED. If the route lookup method is "http", these settings define the configuration of the HTTP client making the request.

telserver.routing.point.%routingPoint%.routeLookup.method.http.maxConnectionsPerHost=5

telserver.routing.point.%routingPoint%.routeLookup.method.http.maxRetries=3

telserver.routing.point.%routingPoint%.routeLookup.method.http.connection.timeout=3000 

telserver.routing.point.%routingPoint%.routeLookup.method.http.timeout=3000

telserver.routing.point.%routingPoint%.routeLookup.method.http.proxy.host= 

telserver.routing.point.%routingPoint%.routeLookup.method.http.proxy.port= 

telserver.routing.point.%routingPoint%.routeLookup.method.http.proxy.authentication.username= 

telserver.routing.point.%routingPoint%.routeLookup.method.http.proxy.authentication.password=  

telserver.routing.point.%routingPoint%.routeLookup.method.http.authentication.username= 

telserver.routing.point.%routingPoint%.routeLookup.method.http.authentication.password= 

telserver.routing.point.%routingPoint%.routeLookup.method.http.authentication.realm= 

Default value is none.

Example: in the following example, a php file gives the destination given a "calling" parameter in the query. Note that there must not be any blank after the '=' sign.

telserver.routing.point.%routingPoint%.routeLookup.method.http.request=http://routing_server/getDestination.php?calling=

MAY BE UPDATED. This setting defines the default route distribution logic to apply if TelServer cannot provide the best skilled agent route or if this route is not applicable. The logic can be "pbx", "none", "cyclic", "sequential"or "most-idle".

For an inbound routing point only, if the distribution is "none", it means that the call is automatically diverted to the default_routes list numbers while TelServer handles the agent state. If the distribution is "pbx", the PBX handles fully the distribution including the agent state.

Otherwise, TelServer handles the distribution:

• If the distribution is "cyclic", it means that the next agent is the one after the last one that has handled a call from the routing point. If the next agent is not ready then the next one is candidate and so on. If a specific order should be applied, it can be defined through telserver.routing.point.%routingPoint%.default_routes.distribution.agents.list.
• If the distribution is "sequential", it means that the next agent search is always starting from the first agent. The order may be defined through telserver.routing.point.%routingPoint%.default_routes.distribution.agents.list. If the next agent is not ready then the next one is candidate and so on.
• If the distribution is "most-idle", it means that the next agent is the one who has been ready without treating calls for the longest time. If the next agent is not ready then the next one is candidate and so on.

For an inbound routing point only, if there is a distribution defined and if no agents are ready, the call is queued on the routing point.

Default value is "most-idle".

Example:

telserver.routing.point.myRoutingPoint.default_routes.distribution=most-idle

MAY BE UPDATED. This setting defines the list of agents handling calls for this routing point. This is normally defined through the directories but if an order should be applied, this setting defines the appropriate order. It is efficient only if the distribution is 'cyclic' or 'sequential'. This list takes precedence over the list defined by the directories if any. It is a comma separated list of agent numbers.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.default_routes.distribution.agents.list=801,842,824,802

MAY BE UPDATED. This setting defines the route to apply if the queue can be controlled by TelServer through specific devices on the PBX (generally virtual devices). When needed, the first available queue slot will be used. The call is diverted to it and when an agent becomes ready the call will be transferred to it from that queue slot. The list can be a single number or a comma separated list of numbers.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.default_routes.queue_slot.list=597,598

MAY BE UPDATED. This setting specifies the type of device of the queue slots. Queue slots can be 'alerting' when the call is left alerting on the device and then diverted to an agent or the failure route, or 'answering' when the call should be answered on the device and then transferred to an agent or the failure route.

Default value is 'alerting'.

Example:

telserver.routing.point.myRoutingPoint.default_routes.queue_slot.device=alerting

MAY BE UPDATED. This setting specifies the type of telephony tone should be applied on an 'answering' queue slot. This allows some PBX to play a message.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.default_routes.queue_slot.device.answering.telephonyTone=9

MAY BE UPDATED. This setting specifies the telephony tone duration on an 'answering' queue slot. The duration is given as is to the PBX, thus the unit is PBX specific.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.default_routes.queue_slot.device.answering.telephonyTone.duration=100

MAY BE UPDATED. This setting defines the route to apply if no distribution is defined or if the queueing is impossible (it is not possible to leave the call on the routing point and no queue slot devices can be defined on the PBX). The call is then diverted on one of these numbers and there is no more control over it (in particular the call cannot be transferred to a ready agent if any). The list can be a single number or a comma separated list of numbers.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.default_routes.list=500

MAY BE UPDATED. This setting defines the last route to apply if the default route is not applicable. If the PBX provides devices that can be controlled by TelServer (generally virtual devices), this setting allows to define the list of them. When needed, the first available slot will be used. The call is diverted to it and a message can be played on. The list can be a single number or a comma separated list of numbers.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.failure_routes.slot.list=797,798

MAY BE UPDATED. This setting specifies the type of device of the failure slots. Failure slots can be 'alerting' when the call is left alerting on the device, or 'answering' when the call should be answered on the device and asked to play a message.

Default value is 'alerting'.

Example:

telserver.routing.point.myRoutingPoint.failure_routes.slot.device=alerting

MAY BE UPDATED. This setting specifies the type of telephony tone should be applied on an 'answering' failure slot. This allows some PBX to play a message.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.failure_routes.slot.device.answering.telephonyTone=12

MAY BE UPDATED. This setting specifies the telephony tone duration on an 'answering' failure slot. The duration is given as is to the PBX, thus the unit is PBX specific.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.failure_routes.slot.device.answering.telephonyTone.duration=100

MAY BE UPDATED. This setting defines the last route to apply if the default route is not applicable and if the PBX does not provide any controllable devices to play a message. The failure routes can be a single number or a comma separated list of numbers. If the failure route is rejected, the call should be handled by the PBX.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.failure_routes.list=501

MAY BE UPDATED. This setting defines the route to apply when in non working hours. If the PBX provides devices that can be controlled by TelServer (generally virtual devices), this setting allows to define the list of them. When needed, the first available slot will be used. The call is diverted to it and a message can be played on. The list can be a single number or a comma separated list of numbers.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.non_working_hours_routes.slot.list=795,796

MAY BE UPDATED. This setting specifies the type of device of the non working hours slots. None working hours slots can be 'alerting' when the call is left alerting on the device, or 'answering' when the call should be answered on the device and asked to play a message.

Default value is 'alerting'.

Example:

telserver.routing.point.myRoutingPoint.non_working_hours_routes.slot.device=alerting

MAY BE UPDATED. This setting specifies the type of telephony tone should be applied on an 'answering' non working hours slot. This allows some PBX to play a message.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.non_working_hours_routes.slot.device.answering.telephonyTone=15

MAY BE UPDATED. This setting specifies the telephony tone duration on an 'answering' non working hours slot. The duration is given as is to the PBX, thus the unit is PBX specific.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.non_working_hours_routes.slot.device.answering.telephonyTone.duration=100

MAY BE UPDATED. This setting defines the route to apply when in non working hours and if the PBX does not provide any controllable devices to play a message. The non working hours routes can be a single number or a comma separated list of numbers. If the non working hours route is rejected, the call should be handled by the PBX.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.non_working_hours_routes.list=501

MAY BE UPDATED. This setting defines whether a cache can be used to route the call to the last agent that has been in communication with the same other party when this other party has no assigned agent. If an assigned agent is defined, the cache is not used and the calls will be routed to the assigned agent.

Default value is "false".

Example:

telserver.routing.point.myRoutingPoint.last_call_cache.enabled=true

MAY BE UPDATED. This setting defines the limit size of the last call cache.

Default value is 20.

Example:

telserver.routing.point.myRoutingPoint.last_call_cache.limit=20

MAY BE UPDATED. This setting defines the pattern of the numbers that will be cached.

Default value is none meaning that all calls on agents with an open session are cached.

NOTE: To cache only external calls a pattern must be defined.

Example:

telserver.routing.point.myRoutingPoint.last_call_cache.pattern=[0-9]{4,}

MAY BE UPDATED. This setting defines hours of the day when the statistics of the the routing point are reset. Resetting the statistics allows to get a view of a certain duration from the management or in backup files. Several hours can be defined separated by commas ','.

It is in hour of the day in the 24-hour clock using pattern "hh:mm:ss" with optional 0 leading fields. Default is at 08H.

Example:

telserver.routing.point.myRoutingPoint.statistics.reset.hour=8

MAY BE UPDATED. This setting defines hours of the day when the statistics of the the routing point saved to backup files. On non worked days, backup files are not saved. Several hours can be defined separated by commas ','.

It is in hour of the day in the 24-hour clock using pattern "hh:mm:ss" with optional 0 leading fields. Default is none.

Example:

telserver.routing.point.myRoutingPoint.statistics.backup.hour=8

MAY BE UPDATED. This setting defines the directory path where the statistics of the the routing point are saved. The file is a csv file the name of which is "statistics-%service%-YYYY-MM-DD-HH-MM-SS.csv" where %service% is the name of the telserver.routing.point.%routingPoint%.service.

Default is ${TelServer_HOME}/work/statistics.

Example:

telserver.routing.point.myRoutingPoint.statistics.backup.path=${TelServer_HOME}/work/statistics

MAY BE UPDATED. This setting defines whether the statistics backup files are sent to the supervisor (telserver.routing.point.%routingPoint%.supervisor.email.tolist).

Default is false.

Example:

telserver.routing.point.myRoutingPoint.statistics.backup.emailing.enabled=true

MAY BE UPDATED. This setting defines a timeout for ignoring within statistics the calls that are abandoned too fast. It is accurate in inbound routing only. Such calls will be counted as 'incoming calls' and 'immediately abandoned calls' but will be ignored in the other statistics.

It is in milliseconds. Default is none.

Example:

telserver.routing.point.myRoutingPoint.statistics.incoming_call_immediately_abandon.timeout=3000

MAY BE UPDATED. It is the routing point supervisor's email address. It is used for sending statistics.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.address=peter.admin@thecompany.com

MAY BE UPDATED. It is the smtp host address of the routing point supervisor email server.

Default value is none.

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.smtp.host=smtp.thecompany.com

MAY BE UPDATED. It is the port used by the routing point supervisor email smtp server.

Default value is 25.

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.smtp.port=25

MAY BE UPDATED. It is the "from" field in the emails sent to the routing point supervisor. It must be an email address that doesn't need to be an existing email address but it must be a "well-formed" one.

Default value is "TelServer@unigone.com".

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.from=TelServer@unigone.com

MAY BE UPDATED. It defines the list of addressees of the emails sent to the routing point supervisor by TelServer. The routing point supervisor email address (telserver.routing.point.%routingPoint%.supervisor.email.address) is automatically added to this list. It is a comma separated list.

Default value is none so that only the routing point supervisor email address is included here.

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.tolist=admin.assistant@thecompany.com

MAY BE UPDATED. It defines the list of carbon-copy addressees of the emails sent to the routing point supervisor by TelServer. It is a comma separated list.

Default is none.

Example:

telserver.routing.point.myRoutingPoint.supervisor.email.cclist=interestedby.TelServer@thecompany.com

MAY BE UPDATED. This setting defines special numbers that are to be treated as is, either from the PBX or from the computer. Note that it is not mandatory to define such numbers if they do not match other rules because they will be treated as is in the same manner.

Default value is none.

Example: this setting defines 112, 115 and 9 numbers as special numbers.

telserver.pbx.numberingRules.specialNumbers.pattern=^112$, ^115$, ^9$

MAY BE UPDATED. This setting defines the rules to be applied to numbers when they are given by the computer before provided to the PBX.

The setting is given as a regular expression for matching the number from the computer and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is that no patterns are defined. If the number does not match any pattern then it is provided as is to the PBX without any transformation (except removing non authorized characters such as the scheme if present 'tel:', the phone context ';phone-context=<descriptor>' and non dialable characters; dialable characters are +*#0123456789ABCD).

Examples (french dial plan): some examples are given that may be used all together :

# 1 - internal numbers with 4 digits starting optionally by '+' and followed with 6, 7 or 8 are to be passed to the PBX as is (after removing the '+' if any)

telserver.pbx.numberingRules.computer2pbx.conversionPattern.1=^\+?([678][0-9]{3})$ > $1

# 2 - numbers optionally starting with + and then 3316012 and with 4 digits starting with 6, 7 or 8 are to be converted in the associated internal number

telserver.pbx.numberingRules.computer2pbx.conversionPattern.2=^\\+?3316012([678][0-9]{3})$ > $1

# 3 - numbers optionally starting with + and then 33 then 9 digits are to be treated as national numbers (removing 33 and adding 00, assuming the first 0 is the outgoing prefix and the second 0 is the operator prefix)

telserver.pbx.numberingRules.computer2pbx.conversionPattern.3=^\\+?33([0-9]{9})$ > 00$1

# 4 - numbers optionally starting with + and then not 33 (not 3 followed by any digit or 3 followed by any digit which is not a 3) plus more than 5 digits are converted to international numbers

telserver.pbx.numberingRules.computer2pbx.conversionPattern.4=^\\+?(([^3][0-9])|(3[^3]))([0-9]{5,})$ > 000$1$4

MAY BE UPDATED. This setting defines the rules to be applied to numbers when they are given by the PBX before provided to the computer (meaning the client of TelServer).

The settings is given as a regular expression for matching the number from the PBX and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is that no patterns are defined. If the number does not match any pattern then it is provided as is to the computer without any transformation.

Examples (french dial plan): some examples are given that may be used all together :

# 1 - internal numbers are converted to complete numbers adding national code and main number

telserver.pbx.numberingRules.pbx2computer.conversionPattern.1=^([678][0-9]{3})$ > +3316012$1 

# 1 - internal numbers may be simply converted adding a '+'
#telserver.pbx.numberingRules.pbx2computer.conversionPattern.1=^([678][0-9]{3})$ > +$1

# 2 - national numbers are converted to complete numbers
adding the + code and the national prefix removing the local access
code (after the external prefix) 

telserver.pbx.numberingRules.pbx2computer.conversionPattern.2=^0[0-9]([0-9]{9})$ > +33$1

# 3 - international numbers are converted to complete numbers adding the + code and removing the international prefix

telserver.pbx.numberingRules.pbx2computer.conversionPattern.3=^000([0-9]+)$ > +$1 

MAY BE UPDATED. This setting defines the maximum count of results a search by name request actually returns.

Default value is 1000.

Example:

telserver.directory.searchNameResult.limit=1000

MAY BE UPDATED. This setting defines the URL of the LDAP directory. It expects the url and the port (by default the port is 389).

Default value is none.

Example: this setting defines an Active Directory at address 192.168.0.10 on port 389.

telserver.directory.myDirLDAP.ldap.provider.url=ldap://192.168.0.10:389

MAY BE UPDATED. This setting defines the type of authentication for the LDAP directory. It can be "none", "simple" or "strong". The most often used method is "simple" with a username and password. Generally, a username 'TelServer' can be defined within the LDAP directory and given a password; that user would then be used for authentication to the LDAP service.

Default value is "simple".

Example:

telserver.directory.myDirLDAP.ldap.authentication.method=simple

MAY BE UPDATED. This setting defines the username to be used according to the authentication method defined above. It should specify the identity of the principal for authenticating the caller to the LDAP service. The format of the principal depends on the authentication scheme.

Example: this setting assumes a specific username 'TelServer' exists within the LDAP directory users in the 'mycompany.local' domain.

telserver.directory.myDirLDAP.ldap.authentication.username=TelServer@mycompany.local

MAY BE UPDATED. This setting defines the password for the previously defined username. The value of the property depends on the authentication scheme. For example, it could be a hashed password, clear-text password, key, certificate, and so on...

Example: this setting assumes a clear text password that is defined within the LDAP directory.

telserver.directory.myDirLDAP.ldap.authentication.password=secret

MAY BE UPDATED. This setting defines maximum size of the cache.

Default is 100000 entries.

Example:

telserver.directory.myDirLDAP.ldap.cache.size.limit=100000

MAY BE UPDATED. This setting defines if the directory search can be performed inline, that is by connecting to the LDAP directory at each request.

Default is false.

Example:

telserver.directory.myDirLDAP.ldap.inline_search.enabled=false

MAY BE UPDATED. If the directory searches inline, this setting defines if the directory inline search result is stored in the cache.

Default is true.

Example:

telserver.directory.myDirLDAP.ldap.inline_search.cache.enabled=true

MAY BE UPDATED. If the directory searches inline and caches results, this setting defines the period of the cache refreshment. At each period the cache it cleared.

Default is 30 days. The unit is one day.

Example:

telserver.directory.myDirLDAP.ldap.inline_search.cache.refresh.period=30

MAY BE UPDATED. This setting defines the LDAP names of the contexts to search. The names must respect the LDAP naming conventions. The contexts can be given as a list separated by ";".

Note : The LDAP naming convention orders components from right to left, delimited by the comma character (","). Thus the LDAP name cn=Rosanna Lee, o=Sun, c=US names an LDAP entry cn=Rosanna Lee, relative to the entry o=Sun, which in turn, is relative to c=us. The LDAP has the further rule that each component of the name must be a name/value pair with the name and value separated by an equals character ("=").

Example: this setting assumes that information is to be found in two contexts ExternalUsers and Users within the mycompany.local domain.

telserver.directory.myDirLDAP.ldap.target_contexts=CN=ExternalUsers,DC=mycompany,DC=local; CN=Users,DC=mycompany,DC=local

MAY BE UPDATED. This setting defines the LDAP attributes representing a name as defined within the context such as 'displayname' or 'cn' or 'sn'. Several can be provided ',' separated.

Default is "displayname,cn,sn".

Example: this setting defines the name attributes.

telserver.directory.myDirLDAP.ldap.search_controls.name.attributes=displayname,cn

MAY BE UPDATED. This setting defines the conversion patterns to apply for each name.

The setting is given as a regular expression for matching the name from the directory source and a replacement string used to replace the matching name (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is none.

Example: the following setting defines a pattern that removes the title at start of a name (Mr., Mrs...).

telserver.directory.myDirLDAP.ldap.name.conversionPatterns=^(Mr|Mrs|Mme|Mlle|M\\.)\\.?\\s+(.*)$ > $2

MAY BE UPDATED. This setting defines the LDAP attribute representing the company name as defined within the context.

Default is none.

Example: this setting defines the company attribute as 'company'.

telserver.directory.myDirLDAP.ldap.search_controls.company.attribute=company

MAY BE UPDATED. This setting defines the LDAP attribute representing the extra data name as defined within the context. The extra data may be used as a special code for example; the content will be provided in the call events for each call where the user is involved.

Default is none.

Example:

telserver.directory.myDirLDAP.ldap.search_controls.extraData.attribute=

MAY BE UPDATED. This setting defines the LDAP attributes representing main telephone numbers (generally the work phone numbers) as defined within the context. Several can be provided ',' separated.

Default is "telephonenumber".

Example: this setting defines the telephone number attribute as 'telephonenumber'.

telserver.directory.myDirLDAP.ldap.search_controls.telephoneNumber.attributes=telephonenumber

MAY BE UPDATED. This setting defines the LDAP attributes representing home phone numbers as defined within the context. Several can be provided ',' separated.

Default is "homePhone".

Example: this setting defines the home number attribute as 'homePhone'.

telserver.directory.myDirLDAP.ldap.search_controls.homePhoneNumber.attributes=homePhone

MAY BE UPDATED. This setting defines the LDAP attributes representing mobile phone numbers as defined within the context. Several can be provided ',' separated.

Default is "mobile".

Example: this setting defines the mobile number attribute as 'mobile'.

telserver.directory.myDirLDAP.ldap.search_controls.mobilePhoneNumber.attributes=mobile

MAY BE UPDATED. This setting defines the LDAP attributes representing IP phone numbers as defined within the context. Several can be provided ',' separated.

Default is "ipPhone".

Example: this setting defines the mobile number attribute as 'ipPhone'.

telserver.directory.myDirLDAP.ldap.search_controls.ipPhoneNumber.attributes=ipPhone

MAY BE UPDATED. This setting defines the LDAP filter to apply for a search in order to get the phone number / naming information. The LDAP syntax must be respected. All attributes defined above (for name, phone number and company) will be requested to the LDAP directory with this filter. From the results, the server will extract each attribute and store information locally.

Default is "telephonenumber=*".

Example: this setting defines the filter as "search for objects that contain a telephonenumber attribute or a homePhone attribute or a mobile attribute".

telserver.directory.myDirLDAP.ldap.search_controls.phoneNumber.filter=(|(telephonenumber=*)(homePhone=*)(mobile=*))

MAY BE UPDATED. This setting defines the conversion patterns to apply for each number.

The setting is given as a regular expression for matching the number from the directory source and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string. If the replacement string is empty this means that the number will be simply ignored.

Note that if conversion patterns are defined, all whitespaces in the numbers are automatically removed before the application of the matching pattern and after the application (whether replacement occurs or not) all characters not in 0123456789 are removed.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is none.

Example: the following setting defines a pattern that converts any number starting by a '0' followed by 9 digits into a normalized number adding '+33' at start, and a pattern that converts any number starting by '00' and followed by any number of digits into a normalized number adding '+' at start. The third rule allows to modify numbers like +39 (0) 12345678 into +39123456789 removing the brackets and digits inside.

telserver.directory.myDirLDAP.ldap.phoneNumber.conversionPatterns.1=^0([0-9]{9})$ > +33$1
telserver.directory.myDirLDAP.ldap.phoneNumber.conversionPatterns.2=^00([0-9]+)$ > +$1
telserver.directory.myDirLDAP.ldap.phoneNumber.conversionPatterns.3=^\\+(\\d*)\\(\\d*\\)([0-9]+)$ > +$1$2

MAY BE UPDATED. This setting defines hours of the day when the local cache is resynchronized with the actual directory source. Several can be defined separated by commas ','.

It is in hour of the day in the 24-hour clock using pattern "hh:mm:ss" with optional 0 leading fields. Default is none.

Example:

telserver.directory.myDirLDAP.ldap.synchronization.hour=0

MAY BE UPDATED. This setting defines the timeout of a LDAP search request.

It is in milliseconds. Default is 2000.

Example:

telserver.directory.myDirLDAP.ldap.search_controls.timeout=2000

MAY BE UPDATED. This setting defines the driver class name to use to connect to the SGDB. Generally a JDBC driver is provided for each SGDB vendor. The class must be found in the classpath of TelServer.

Default value is none.

Example: this setting defines the driver class name for an ODBC-JDBC driver. It thus allows to access a ODBC compliant SGDB such Microsoft Access for example. This driver is in the classpath by default if using a Sun JVM.

telserver.directory.myDirJdbc.jdbc.driver.classname=sun.jdbc.odbc.JdbcOdbcDriver

MAY BE UPDATED. This setting defines the URL to connect to the database. It must be in the form jdbc:subprotocol:subname where subprotocol:subname is the name of the pilot to be used.

Default value is none.

Example: this setting defines an URL for a Microsoft Access database stored within a file Contacts.accdb (Access 2007). The pilot used is the odbc pilot and the extra information is provided to the pilot.

telserver.directory.myDirJdbc.jdbc.connection.url=jdbc:odbc:Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=D:\\sgdb\\Contacts.accdb

MAY BE UPDATED. This setting defines the username to be used to connect the SGDB.

Example: this setting defines no username to connect to the sgdb.

telserver.directory.myDirJdbc.jdbc.connection.username=

MAY BE UPDATED. This setting defines the password for the previously defined username.

Example: this setting defines no password to connect to the SGDB.

telserver.directory.myDirJdbc.jdbc.connection.password=

MAY BE UPDATED. This setting defines maximum size of the cache.

Default is 100000 entries.

Example:

telserver.directory.myDirJdbc.jdbc.cache.size.limit=100000

MAY BE UPDATED. This setting defines if the directory search can be performed inline, that is by connecting to the JDBC directory at each request.

Default is false.

Example:

telserver.directory.myDirJdbc.jdbc.inline_search.enabled=false

MAY BE UPDATED. If the directory searches inline, this setting defines if the directory inline search is stored in the cache.

Default is true.

Example:

telserver.directory.myDirJdbc.jdbc.inline_search.cache.enabled=true

MAY BE UPDATED. If the directory searches inline and caches results, this setting defines the period of the cache refreshment. At each period the cache it cleared.

Default is 30 days. The unit is one day.

Example:

telserver.directory.myDirJdbc.jdbc.inline_search.cache.refresh.period=30

MAY BE UPDATED. This setting defines if the JDBC connection will persist or is created at each query/update.

Default value is true.

Example:

telserver.directory.myDirJdbc.jdbc.connection.persistence.enabled=true

MAY BE UPDATED. This setting defines the SQL queries to request either customer or calls information from the SGDB. The syntax must respect the SQL conventions. The queries can be given as a list separated by ";". For a "call" directory, there should be a single query and it can contain the variable "%name%" that will be replaced by the campaign name (provided by the startRoutingPoint request from the supervisor application).

Example for a customer directory: this setting assumes that information is to be found in the "contacts" table.

telserver.directory.myDirJdbc.jdbc.sql_queries=SELECT * FROM contacts

Example for a call directory: this setting assumes that information is to be found in the "campaigns" table.

telserver.directory.myDirJdbc.jdbc.sql_queries=SELECT * FROM campaigns WHERE campaign='%name%'

Example for an agent directory involved in an outbound campaign: this setting assumes that information is to be found in the "campaignagents" table.

telserver.directory.myDirJdbc.jdbc.sql_queries=SELECT * FROM campaignagents WHERE campaign='%name%'

MAY BE UPDATED. For a "call" directory only, this setting defines the SQL update to update the calls table disposition field after a call is qualified in the SGDB table. The syntax must respect the SQL conventions.

Example: this setting assumes that information is to be found in the campaigns table.

telserver.directory.myDirJdbc.jdbc.sql_update_call=UPDATE campaigns SET disposition=%disposition% where key='%callKey%'

MAY BE UPDATED. For a "call" directory only, this setting defines the SQL update to initialize the calls table disposition field in the SGDB table. The syntax must respect the SQL conventions.

Example: this setting assumes that information is to be found in the campaigns table.

telserver.directory.myDirJdbc.jdbc.sql_update_init=UPDATE campaigns SET disposition=NULL where validity=1 and updated=1 and campaign='%name%'

MAY BE UPDATED. This setting defines the separator used to separate several values within a single column value. This may be used for column like assignedAgent or skill for example.

Default is none.

telserver.directory.myDirJbdc.jdbc.value.separator=;

MAY BE UPDATED. This setting defines the columns indexes where to find the names (starting from '1' as in SQL) within the result set obtained from the SQL query. If several SQL queries have been defined, then the name columns can be defined for each of them separated by "&&" (one at most per SQL query). The '+' character can be used to concatenate names extracted from several columns (to concatenate the first name and the name for example); the names are concatenated after insertion of a space character between them.

Default is none.

Example: this setting defines the name is to be built by concatenating the column 3 and 4 within the results set obtained by the SQL query.

telserver.directory.myDirJbdc.jdbc.name.columns=3+4

MAY BE UPDATED. This setting defines the conversion patterns to apply for each name.

The setting is given as a regular expression for matching the name from the directory source and a replacement string used to replace the matching name (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

The settings is applied after the optional concatenation of several columns.

Default is none.

Example: the following setting defines a pattern that removes the title at start of a name (Mr., Mrs...).

telserver.directory.myDirJdbc.jdbc.name.conversionPatterns=^(Mr|Mrs|Mme|Mlle|M\\.)\\.?\\s+(.*)$ > $2

MAY BE UPDATED. This setting defines the column index where to find the company name (starting from '1' as in SQL) within the result set obtained from the SQL query. If several SQL queries have been defined, then the company can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.company.columns=2

MAY BE UPDATED. This setting defines the columns indexes where to find the raw telephone numbers (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the telephone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Raw phone number settings should be used if the table contains one column for the phone number and one column specifying the type of the phone number. If not, and if the table structure contains number specific columns, the telephoneNumber, homePhoneNumber, mobilePhoneNumber or ipPhoneNumber settings must be used.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.rawPhoneNumber.columns=7

MAY BE UPDATED. This setting defines the columns indexes where to find the raw telephone number type (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the telephone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

The raw phone number type value should be consistent with telserver.directory.%directory%.jdbc.rawPhoneNumber.types.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.rawPhoneNumber_type.columns=8

MAY BE UPDATED. This setting defines the types as integers of the raw phone number in the order work, home, mobile and ip.

Default is 0,1,2,3. This means that a value of 0 is for a work phone number, 1 for a home phone number, 2 for a mobile one and 3 for an ip one.

Example:

telserver.directory.myDirJdbc.jdbc.rawPhoneNumber.types=0,1,2,3

MAY BE UPDATED. This setting defines the columns indexes where to find the telephone numbers or work phone numbers (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the telephone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.telephoneNumber.columns=7

MAY BE UPDATED. This setting defines the columns indexes where to find the home phone numbers (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the home phone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.homePhoneNumber.columns=8

MAY BE UPDATED. This setting defines the columns indexes where to find the mobile phone numbers (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the mobile phone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.mobilePhoneNumber.columns=9

MAY BE UPDATED. This setting defines the columns indexes where to find the IP phone numbers (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the IP phone number columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.ipPhoneNumber.columns=

MAY BE UPDATED. This setting defines the conversion patterns to apply for each number.

The setting is given as a regular expression for matching the number from the directory source and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string. If the replacement string is empty this means that the number will be simply ignored.

Note that if conversion patterns are defined, all whitespaces in the numbers are automatically removed before the application of the matching pattern and after the application (whether replacement occurs or not) all characters not in 0123456789 are removed.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is none.

Example: the following setting defines a pattern that converts any number starting by a '0' followed by 9 digits into a normalized number adding '+33' at start, and a pattern that converts any number starting by '00' and followed by any number of digits into a normalized number adding '+' at start. The third rule allows to modify numbers like +39 (0) 12345678 into +39123456789 removing the brackets and digits inside.

telserver.directory.myDirJdbc.jdbc.phoneNumber.conversionPatterns.1=^0([0-9]{9})$ > +33$1
telserver.directory.myDirJdbc.jdbc.phoneNumber.conversionPatterns.2=^00([0-9]+)$ > +$1
telserver.directory.myDirJdbc.jdbc.phoneNumber.conversionPatterns.3=^\\+(\\d*)\\(\\d*\\)([0-9]+)$ > +$1$2

MAY BE UPDATED. This setting defines the columns indexes where to find the extra data associated to a customer (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the assigned agent columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined. The extra data may be used as a customer code for example; the content will be provided in the call events for each call where the customer is involved.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.extraData.columns=

MAY BE UPDATED. For a "customer" directory, this setting defines the columns indexes where to find the category of the customer's calls (starting from '1' as in SQL) within the result set obtained from the SQL query. The category must be a number:

• a negative number for a blacklisted call or,
• a positive number for a VIP customer (calls are treated in priority when queued).

The value can be a separated value contain several actual values.

Default is 0.

Example:

telserver.directory.myDirExcel.spreadsheet.category.columns=

MAY BE UPDATED. For a "customer" or a "call" directory, this setting defines the columns indexes where to find the assigned agents (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the assigned agent columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined. The conversion patterns are not applied to these numbers.

This setting should be defined for a directory containing customer information only and it is exclusive with the telserver.directory.%directory%.jdbc.service.columns setting.

The value can be a separated value contain several actual values.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.assignedAgent.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the assigned agents is required or not (starting from '1' as in SQL) within the result set obtained from the SQL query. A negative value can be used to indicate that no columns are defined.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.assignedAgentRequired.columns=

MAY BE UPDATED. For an "agent" directory, this setting defines the columns indexes where to find the services dealt by the number (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the service columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

This setting should be defined for a directory containing agent information only and it is exclusive with the telserver.directory.%directory%.jdbc.assignedAgent.columns setting.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.service.columns=

MAY BE UPDATED. For an "agent" or a "customer" directory, this setting defines the columns indexes where to find the skills respectively got by the agent or required by the customer (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. If several SQL queries have been defined, then the skill columns can be defined for each of them separated by "&&" (one at most per SQL query). A negative value can be used to indicate that no columns are defined.

The value can be a separated value contain several actual values.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.skill.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the key of the call to be launched (starting from '1' as in SQL) within the result set obtained from the SQL query; they are separated by ','. The key used mainly to perform an efficient SQL update defined by telserver.directory.%directory%.jdbc.sql_update_call.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.callKey.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the appointment date (if any) when the call is to be launched (starting from '1' as in SQL) within the result set obtained from the SQL query. A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.appointmentDate.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the appointment date format.

Default is "yyyy-MM-dd".

Example:

telserver.directory.myDirJdbc.jdbc.appointmentDate.format=yyyyMMdd

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the appointment time (if any) when the call is to be launched (starting from '1' as in SQL) within the result set obtained from the SQL query. A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.appointmentTime.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the appointment time format.

Default is "HH:mm:ss".

Example:

telserver.directory.myDirJdbc.jdbc.appointmentTime.format=HHmmss

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the call is valid (to be launched or not) or not (starting from '1' as in SQL) within the result set obtained from the SQL query.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.validity.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the call is to be considered or not after an update of the directory or not (starting from '1' as in SQL) within the result set obtained from the SQL query.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.validity.columns=

MAY BE UPDATED. This setting defines hours of the day when the local cache is resynchronized with the actual directory source. Several can be defined separated by commas ','.

It is in hour of the day in the 24-hour clock using pattern "hh:mm:ss" with optional 0 leading fields. Default is none.

Example:

telserver.directory.myDirJdbc.jdbc.synchronization.hour=0

MAY BE UPDATED. This setting defines the path of the spreadsheet file. For a "call" directory, the calls of a campaign are to be fully contained in a dedicated file, thus the setting can contain the variable "%name%" that will be replaced by the campaign name (provided by the startRoutingPoint request from the supervisor application).

Default value is none. Note that the ${TelServer_HOME} may be used.

Example: this setting defines the path of a file name customers.xls (an Excel file) relatively to the location where TelServer has been launched.

telserver.directory.myDirExcel.spreadsheet.path=../db/customers.xls

Example: for a "call" directory, this setting defines the path of a file name %name%.xls (an Excel file) relatively to the location where TelServer has been launched. For a campaign named 'firstcampaign', the file will be 'firstcampaign.xls'.

telserver.directory.myDirExcel.spreadsheet.path=../db/%name%.xls

MAY BE UPDATED. This setting defines the type of the spreadsheet file. It may be "EXCEL" or "CSV" (ignoring case). If it is not provided explicitely, the extension of the file is used. ".xls" or ".xslx" lead to an EXCEL type, ".csv" leads to a CSV type.

Default value is none and the extension of the file path is used.

Example:

telserver.directory.myDirExcel.spreadsheet.type=EXCEL

MAY BE UPDATED. This setting defines maximum size of the cache.

Default is 100000 entries.

Example:

telserver.directory.myDirExcel.spreadsheet.cache.size.limit=100000

MAY BE UPDATED. This setting defines the column separator of the spreadsheet file. It is used only when the type is CSV.

Default value is ";".

Example:

telserver.directory.myDirExcel.spreadsheet.column.separator=;

MAY BE UPDATED. This setting defines the char a row must begin with to be ignored as a comment in the spreadsheet file. It is used only when the type is CSV.

Default value is "#".

Example:

telserver.directory.myDirExcel.spreadsheet.commentRow.char=#

MAY BE UPDATED. This setting defines the separator used to separate several values within a single column value. This may be used for column like assignedAgent or skill for example.

Default is none.

telserver.directory.myDirExcel.spreadsheet.value.separator=;

MAY BE UPDATED. This setting defines the sheet names within the Excel workbook. There can be several sheet names which can be given as a list separated by "&&". A sheet name can be a number starting from '0' (for the first sheet of the workbook).

Example: this setting defines the first and the second sheet.

telserver.directory.myDirExcel.spreadsheet.sheetNames=0&&1

MAY BE UPDATED. This setting defines the starting row index (starting from '0') within the associated sheet. If several sheets have been defined, then one starting row can be defined for each of them separated by "&&" (one at most per sheet).

Default is 0.

Example:

telserver.directory.myDirExcel.spreadsheet.startingRows=1&&1

MAY BE UPDATED. This setting defines the columns indexes where to find the names (starting from '0') within the sheet. If several sheets have been defined, then the name columns can be defined for each of them separated by "&&" (one at most per sheet). The '+' character can be used to concatenate names extracted from several columns (to concatenate the first name and the name for example); the names are concatenated after insertion of a space character between them.

Default is none.

Example: this setting defines the name is to be built by concatenating the column 3 and 4 for the first sheet defined while using column 3 for the second sheet defined.

telserver.directory.myDirExcel.spreadsheet.name.columns=3+4&&3

MAY BE UPDATED. This setting defines the conversion patterns to apply for each name.

The setting is given as a regular expression for matching the name from the directory source and a replacement string used to replace the matching name (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

The settings is applied after the optional concatenation of several columns.

Default is none.

Example: the following setting defines a pattern that removes the title at start of a name (Mr., Mrs...).

telserver.directory.myDirExcel.spreadsheet.name.conversionPatterns=^(Mr|Mrs|Mme|Mlle|M\\.)\\.?\\s+(.*)$ > $2

MAY BE UPDATED. This setting defines the column index where to find the company name (starting from '0') within the sheet. If several sheets have been defined, then the company name can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.company.columns=2

MAY BE UPDATED. This setting defines the columns indexes where to find the raw telephone numbers (starting from '0') within the sheet. If several sheets have been defined, then the company name can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Raw phone number settings should be used if the table contains one column for the phone number and one column specifying the type of the phone number. If not, and if the table structure contains number specific columns, the telephoneNumber, homePhoneNumber, mobilePhoneNumber or ipPhoneNumber settings must be used.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.rawPhoneNumber.columns=7

MAY BE UPDATED. This setting defines the columns indexes where to find the raw telephone number type (starting from '0') within the sheet. If several sheets have been defined, then the company name can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined. A negative value can be used to indicate that no columns are defined.

The raw phone number type value should be consistent with telserver.directory.%directory%.spreadsheet.rawPhoneNumber.types.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.rawPhoneNumber_type.columns=8

MAY BE UPDATED. This setting defines the types as integers of the raw phone number in the order work, home, mobile and ip.

Default is 0,1,2,3. This means that a value of 0 is for a work phone number, 1 for a home phone number, 2 for a mobile one and 3 for an ip one.

Example:

telserver.directory.myDirExcel.spreadsheet.rawPhoneNumber.types=0,1,2,3

MAY BE UPDATED. This setting defines the columns indexes where to find the telephone numbers or work phone numbers (starting from '0') within the sheet; they are separated by ',' . If several sheets have been defined, then the telephone number columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.telephoneNumber.columns=2&&2

MAY BE UPDATED. This setting defines the columns indexes where to find the home phone numbers (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the home phone number columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.homePhoneNumber.columns=4&&4

MAY BE UPDATED. This setting defines the columns indexes where to find the mobile phone numbers (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the mobile phone number columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.mobilePhoneNumber.columns=9

MAY BE UPDATED. This setting defines the columns indexes where to find the IP phone numbers (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the IP phone number columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.ipPhoneNumber.columns=

MAY BE UPDATED. This setting defines the conversion patterns to apply for each number.

The setting is given as a regular expression for matching the number from the directory source and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string. If the replacement string is empty this means that the number will be simply ignored.

Note that if conversion patterns are defined, all whitespaces in the numbers are automatically removed before the application of the matching pattern and after the application (whether replacement occurs or not) all characters not in 0123456789 are removed.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is none.

Example: the following setting defines a pattern that converts any number starting by a '0' followed by 9 digits into a normalized number adding '+33' at start, and a pattern that converts any number starting by '00' and followed by any number of digits into a normalized number adding '+' at start. The third rule allows to modify numbers like +39 (0) 12345678 into +39123456789 removing the brackets and digits inside.

telserver.directory.myDirExcel.spreadsheet.phoneNumber.conversionPatterns.1=^0([0-9]{9})$ > +33$1
telserver.directory.myDirExcel.spreadsheet.phoneNumber.conversionPatterns.2=^00([0-9]+)$ > +$1
telserver.directory.myDirExcel.spreadsheet.phoneNumber.conversionPatterns.3=^\\+(\\d*)\\(\\d*\\)([0-9]+)$ > +$1$2

MAY BE UPDATED. This setting defines the columns indexes where to find the extra data associated to a customer (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the extraData columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined. The conversion patterns are not applied to these numbers. The extra data may be used as a customer code for example; the content will be provided in the call events for each call where the customer is involved.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.extraData.columns=

MAY BE UPDATED. For a "customer" directory, this setting defines the category of the customer's calls (starting from '0') within the sheet.

The category must be a number:

• a negative number for a blacklisted call or,
• a positive number for a VIP customer (calls are treated in priority when queued).

The value can be a separated value contain several actual values.

Default is 0.

Example:

telserver.directory.myDirExcel.spreadsheet.category.columns=

MAY BE UPDATED. For a "customer" directory, this setting defines the columns indexes where to find the assigned agents (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the assigned agent columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined. The conversion patterns are not applied to these numbers.

This setting should be defined for a directory containing customer information only and it is exclusive with the telserver.directory.%directory%.spreadsheet.service.columns setting.

The value can be a separated value contain several actual values.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.assignedAgent.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the assigned agents is required or not (starting from '0') within the sheet. A negative value can be used to indicate that no columns are defined.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.assignedAgentRequired.columns=

MAY BE UPDATED. For an "agent" directory, this setting defines the columns indexes where to find the service dealt by the number (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the servicecolumns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

This setting should be defined for a directory containing agent information only and it is exclusive with the telserver.directory.%directory%.spreadsheet.assignedAgent.columns setting.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.service.columns=

MAY BE UPDATED. For an "agent" or a "customer" directory, this setting defines the columns indexes where to find the skills respectively got by the agent or required by the customer (starting from '0') within the sheet; they are separated by ','. If several sheets have been defined, then the skill columns can be defined for each of them separated by "&&" (one at most per sheet). A negative value can be used to indicate that no columns are defined.

The value can be a separated value contain several actual values.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.skill.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the key of the call to be launched (starting from '0') within the sheet.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.callKey.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the appointment date (if any) when the call is to be launched (starting from '0') within the sheet. A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.appointmentDate.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the appointment date format.

Default is "yyyy-MM-dd".

Example:

telserver.directory.myDirExcel.spreadsheet.appointmentDate.format=yyyyMMdd

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find the appointment time (if any) when the call is to be launched (starting from '0') within the sheet. A negative value can be used to indicate that no columns are defined.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.appointmentTime.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the appointment time format.

Default is "HH:mm:ss".

Example:

telserver.directory.myDirExcel.spreadsheet.appointmentTime.format=HHmmss

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the call is valid (to be launched or not) or not (starting from '0') within the sheet.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.validity.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes where to find if the call is to be considered or not after an update of the directory or not (starting from '0') within the sheet.

If the content of the column is "1", the value is 'true' otherwise it is 'false'. Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.validity.columns=

MAY BE UPDATED. For a "call" directory, this setting defines the columns indexes of the disposition column (starting from '0') within the sheet. The disposition is updated after a call is qualified.

Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.disposition.columns=

MAY BE UPDATED. This setting defines hours of the day when the local cache is resynchronized with the actual directory source. Several can be defined separated by commas ','.

It is in hour of the day in the 24-hour clock using pattern "hh:mm:ss" with optional 0 leading fields. Default is none.

Example:

telserver.directory.myDirExcel.spreadsheet.synchronization.hour=0

MAY BE UPDATED. This setting defines the maximum time TelServer waits for a PBX return after it has requested a command. The value is in milliseconds.

Default value is 5000 for 5 seconds. Minimum value is 3000 ms.

Example: telserver.pbxlink.return.timeout=5000

This setting defines the time TelServer shall wait before trying to re-establish the CSTA link with the PBX after this link has failed (for example because the link audit has failed). The value is in seconds.

Default value is 60 seconds. Setting a negative value deactivates the feature.

Example:

telserver.pbxlink.automatic_restart_after_failure.timeout=60

This setting defines the file location of the file containing the PBX settings for the PBX named %name%. The file is searched in the current directory or if not found in the same directory as TelServer configuration file.

Default value is none.

Example: suppose two PBXs must be supported, one named NexSpan and another one name Alcatel :

telserver.pbxlink.NexSpan.properties=nexspan.properties

telserver.pbxlink.Alcatel.properties=alcatel.properties

MAY BE UPDATED. This setting defines the patterns for assigning the PBX named %name% to an extension. When a request must be handled by TelServer, it knows the extension which is at the origin of that request. That number is checked through the various patterns to assign the PBX link so that the request is sent through that link. The extensions patterns is defined through regular expression. Several patterns can be defined adding ".%index%" to the setting where %index% is an index starting from 1 (for example telserver.pbxlink.NexSpan.extensionsPattern.1).

NOTE 1: The expression can be applied to an extension but also to a TEL URI (aka Line URI) since with SIP/CSTA the MonitorStart contains the TEL URI (the case with SIP/CSTA gateway). The selection depends on the TEL URI configuration which can be by E164 number (tel: +33160127787) or by phone-context (tel:6811;phone-context=nexspanXL@mycompany.com). See the example below.

NOTE 2 : working with several PBX assumes that one internal number on a PBX is unique for all PBX (the dialplan must be uniform).

Default value is none meaning that all extensions will match.

Example 1: in the case of the assignment is made by extension numbers (the case with TelServices gateway), suppose two PBXs must be supported, one NexSpan with all extensions starting with 6 and one Alcatel with all extensions starting with 7:

telserver.pbxlink.NexSpan.extensionsPattern=6[0-9]{3}

telserver.pbxlink.Alcatel.extensionsPattern=7[0-9]{3}

Example 2: in the case of the assignment is made by extension TEL URI with E164 numbers, suppose two PBXs must be supported, one NexSpan with TEL URI such as tel:+331601273xx (where xx goes from 00 to 99 for example) and one Alcatel with TEL URI such as tel:+331601282xx :

telserver.pbxlink.NexSpan.extensionsPattern=.*331601273[0-9]{2}$

telserver.pbxlink.Alcatel.extensionsPattern=.*331601282[0-9]{2}$

Example 3: in the case of the assignment is made by extension TEL URI with phone-context, suppose two PBXs must be supported, one NexSpan with all extensions TEL URI in the phone context 'phone-context=nexspanXL@mycompany.com' (for example TEL URI is tel:6xx;phone-context=nexspanXL@mycompany.com where xx is from 00 to 99) and one Alcatel with all extensions TEL URI in the phone context 'phone-context=alcatelOXO@mycompany.com':

telserver.pbxlink.NexSpan.extensionsPattern=.*phone-context=nexpanXL.*

telserver.pbxlink.Alcatel.extensionsPattern=.*phone-context=alcatelOXO.*

This setting allows definition of a stand-by link for the PBX link (known as the main link). This may be useful in situation where 2 CTI entry points or 2 network interfaces can be defined on the PBX network. If the IP path to the first CTI entry point fails, the other path may still be working and the PBX link defined as the 'stand-by' link may become the actual link. This way the CI connection to the PBX is still functional. This is not possible with every PBX.

Default value is none.

telserver.pbxlink.NexSpan1.stand-by.pbxlink.name=Nexspan2

This defines whether the main link is automatically switched active again when recovering from error (if possible). The stand-by link then becomes inactive.

Default value is true.

telserver.pbxlink.NexSpan1.stand-by.switch_over_on_main_pbxlink_recovery.enabled=true

This defines whether the call contexts are reset when switching from one stand-by or main link to the other.

Default value is false.

telserver.pbxlink.NexSpan1.stand-by.reset_call_contexts_on_switch_over.enabled=false

This setting allows the dynamic definition PBX properties. When a client connects to the CSTAp2 gateway, it can define the PBX properties dynamically through the extension mechanism of CSTA phase II. Dynamic PBX properties explains how to set those properties.

Default value is false.

telserver.pbxlink.dynamic_properties.enabled=false

Minimal configuration:

pbxlink.pbx.type=PBX_AASTRA_MX_ONE
pbxlink.pbx.address=pbx_ip_address

It may require an Application Link server.

CSTA licenses are requested on the PBX.

Minimal configuration:

pbxlink.pbx.type=PBX_AASTRA_NEXSPAN
pbxlink.pbx.address=pbx_ip_address

Minimal configuration:

pbxlink.pbx.type=PBX_AASTRA_OPENCOM
pbxlink.pbx.address=pbx_ip_address
pbxlink.pbx.user.name=administrator username
pbxlink.pbx.user.password=password

The protocol used is CSTA and the login is defined either using the PBX administrator login and password.

CSTA licenses are requested on the PBX.

Minimal configuration:

pbxlink.pbx.type=PBX_ALCATEL_OMNI_PCX_ENTREPRISE
pbxlink.pbx.address=pbx_ip_address

CSTA licenses are requested on the PBX.

Minimal configuration:

pbxlink.pbx.type=PBX_ALCATEL_OMNI_PCX_OFFICE
pbxlink.pbx.address=pbx_ip_address

Asterisk version 1.6 or upper is required.

Minimal configuration:

pbxlink.pbx.type=PBX_ASTERISK
pbxlink.pbx.address=pbx_ip_address
pbxlink.pbx.user.name=admin
pbxlink.pbx.user.password=secret
pbxlink.pbx.asterisk.contexts.list=asterisk_contexts
[pbxlink.pbx.asterisk.conferences.list=asterisk_reserved_meetme (*)]
[pbxlink.pbx.asterisk.db.dnd.family=asterisk_db_family_for_DoNotDisturb (*)]
[pbxlink.pbx.asterisk.db.dnd.family.on_value=asterisk_db_family_on_value_for_DoNotDisturb (*)]
[pbxlink.pbx.asterisk.db.callForwardImmediate.family=asterisk_db_family_for_immediate_call_forward (*)]
[pbxlink.pbx.asterisk.db.callForwardBusy.family=asterisk_db_family_for_busy_call_forward (*)]
[pbxlink.pbx.asterisk.db.callForwardNoAnswer.family=asterisk_db_family_for_no_answer_call_forward (*)]
[pbxlink.pbx.asterisk.SIPPhoneGateway.enabled=true (*)]
[pbxlink.pbx.asterisk.SIPPhoneGateway.port=8084 (*)]

The connection to Asterisk is made through the Asterisk Manager API protocol which requires to be enabled within Asterisk.

manager.conf

To enable the Manager API on Asterisk, you must edit your manager.conf configuration file (or the appropriate file depending on the Asterisk distribution used) and restart Asterisk. The manager.conf also contains constraints on the range of IP addresses that are allowed to connect and username and passwords for authentication.

A sample might look like:

[general] 
enabled=yes
port=5038
bindaddr=0.0.0.0

[admin]
secret=secret
permit=0.0.0.0/0.0.0.0
read=system,call,log,verbose,agent,command,user
write=system,call,log,verbose,agent,command,user,originate

This will enable the Manager API, allow access from any IP address using the username "admin" and the password "secret". All manager API commands registered by Asterisk modules have a privilege group associated to it. In order a manager API user can issue a command, it has to have read or write privilege to the appropriate group. The write option should also contain 'originate'.

The userid and password should be reported in the TelServer.properties using:

pbxlink.pbx.user.name=admin
pbxlink.pbx.user.password=secret.

sip.conf

The file sip.conf (or the appropriate file depending on the Asterisk distribution used) must be edited to add callevents=yes.

[general]
callevents=yes

Contexts

The contexts of the Asterisk dialplan used to initiate calls which are defined in extension.conf (or the appropriate file depending on the Asterisk distribution used) should be also defined in TelServer.properties:

pbxlink.pbx.asterisk.contexts.list=default,from-internal

Conferences

To allow the ConferenceCall which conferences an active call and an held call, a list of specific meetme room numbers must be defined. Each meetme number in the list must allow the user to enter the conference without requesting a password. The numbers count should be equal to the number of simultaneous conferences desired. Upon ConferenceCall requests, TelServer will find a free meetme room within this list to redirect all concerned users to it.

pbxlink.pbx.asterisk.conferences.list=200,201

Devices

Since Asterisk Manager API does not offer the same level of control than with a CSTA or JTAPI PBX, some call control features are natively not enabled. TelServer may however enhance the call control support for SIP phones which provide a direct (HTML or XML...) interface. This may require some configuration on the device itself (to allow TelServer to pilot the device).

The table exposes the supported SIP phones and the configuration required if any, as well as recommendations that should be followed to ensure the expected behavior works correctly:

Minimal configuration:

pbxlink.pbx.type=PBX_AVAYA_AES
pbxlink.pbx.address=pbx_ip_address
pbxlink.pbx.jtapi.peer=com.avaya.jtapi.tsapi.TsapiPeer
pbxlink.pbx.user.name=
pbxlink.pbx.user.password=

The protocol used to dialog with the AVAYA Communication Manager Application Enablement Services is JTAPI. The <jtapi>.jar file must be obtained previously. The jar file should be installed in TelServer installation 'lib' directory replacing the existing jtapi.jar (containing only the JTAPI interfaces), or at least the AVAYA jtapi.jar must be added in TelServer classpath defined in TelServer.bat or TelServer.sh file.

The pbxlink.pbx.address setting must be defined with the IP address of the Application Enablement Services server.

TelServer.properties should contain the JTAPI provider defined by pbxlink.pbx.jtapi.peer=com.avaya.jtapi.tsapi.TsapiPeer. If you don't know the path of the AVAYA JTAPI service, TelServer will get it through the IP address and port. If you know it, you can add the path of the JTAPI service like: pbxlink.pbx.jtapi.service=AVAYA#S8500PE#CSTA#MY-AES. If you have provided the JTAPI service, you can also edit the TSAPI.PRO file in the lib/ext directory of TelServer. It should be edited according to the Avaya specifications. This may be useful for providing alternate services to the preferred service (the one given by pbxlink.pbx.jtapi.service) using for example: Alternates(AVAYA#S8500PE#CSTA#MY-AES)=AVAYA#S8500PE#CSTA#MY-AES2.

Additionally, the user name (pbxlink.pbx.user.name) and password (pbxlink.pbx.user.password) must also be defined, corresponding to the user created in the AES Administration. That user defined within the AES must be enabled for call control.

It is recommended to avoid the ';' character in the user name and password because the PBX JTAPI provider string uses ';' as separator.

The choice of receiving global or local to the node call ID is configured through pbxlink.pbx.csta.use_pbx_global_callid.enabled.

Minimal configuration:

pbxlink.pbx.type=PBX_CISCO
pbxlink.pbx.address=pbx_ip_address
pbxlink.pbx.jtapi.peer=com.cisco.jtapi.CiscoJtapiPeerImpl
pbxlink.pbx.user.name=
pbxlink.pbx.user.password=

The protocol used to dialog with the CISCO PBX is JTAPI. The jtapi.jar file can be obtained from the CallManager using http(s)://ip_address_communication_manager/plugins/jtapi.jar. The jar file should be installed in TelServer installation 'lib' directory replacing the existing jtapi.jar (containing only the JTAPI interfaces), or at least the CISCO jtapi.jar must be added in TelServer classpath defined in TelServer.bat or TelServer.sh file.

TelServer.properties should contain the JTAPI provider defined by pbxlink.pbx.jtapi.peer=com.cisco.jtapi.CiscoJtapiPeerImpl.

The pbxlink.pbx.address setting must be defined with the IP address of the CallManager server.

Additionally, the user name (pbxlink.pbx.user.name) and password (pbxlink.pbx.user.password) must also be defined, corresponding to the user created in the Cisco CallManager Administration. That user defined within the Cisco must be able to control all devices that need to be controlled by TelServer. Thus, when creating the user for TelServer within Cisco Administration, in the 'Devices Information block', you should:

• Add all devices that need to be controlled into the 'Controlled devices'.
• Add the user to the appropriate group (Add to User Group). It is simpler to add the user in the "Standard CTI Allow Control of All Devices" group. For more information, please refer to the Cisco Administration Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/5_0_1/ccmsys/a08cti.html at the "Applications That Monitor and Control All CTI-Controllable Devices" chapter.

It is recommended to avoid the ';' character in the user name and password because the PBX JTAPI provider string uses ';' as separator.

The choice of receiving global or local to the node call ID is configured through pbxlink.pbx.csta.use_pbx_global_callid.enabled.

Minimal configuration:

pbxlink.pbx.type=PBX_CISCO_CME
pbxlink.pbx.address=pbx_ip_address

Minimal configuration:

pbxlink.pbx.type=PBX_SIEMENS_HIPATH
pbxlink.pbx.address=pbx_ip_address
pbxlink.pbx.user.name=31994
pbxlink.pbx.user.password=31994

The protocol used is CSTA and the login is defined either using the PBX administrator login and password, either with a special login sequence which can be defined using an empty system password setting (pbxlink.pbx.system.password=).

Minimal configuration:

pbxlink.pbx.type=PBX_TADIRAN_CORAL
pbxlink.pbx.address=pbx_ip_address

This setting defines the type of the PBX. It should at least be defined with pbxlink.pbx.address so that TelServer can connect to the PBX.

The type can be (use the exact strings):

• PBX_DEFAULT for defining the PBX settings manually (it can be used for CSTAStub),
• PBX_AASTRA_MATRA_NEXSPAN (or PBX_EADS_TELECOM_M6500) for emulating a Nexspan PBX,
• PBX_ALCATEL_4400 for an Alcatel 4400,
• PBX_ALCATEL_OMNI_PCX_OFFICE for an Alcatel Omni PCX Office,
• PBX_ALCATEL_OMNI_PCX_ENTREPRISE for an Alcatel Omni PCX entrepreprise ,
• PBX_ASTERISK for an ASTERISK PBX (with Asterisk Manager API),
• PBX_AVAYA_AES for an AVAYA Communication Manager with Application Enablement Services (with JTAPI),
• PBX_CISCO for a CISCO PBX (with JTAPI),
• PBX_CISCO_CME for a CISCO Communications Manager Express PBX (with CSTA phase III XML over SIP),
• PBX_ERICSSON for an Ericsson PBX (MD110 or MD Evolution),
• PBX_SIEMENS_HIPATH for a Siemens HiPath,
• PBX_TADIRAN_CORAL for a Tadiran Telecom Coral IP PBX.

Default values of other PBX settings depend on this setting. However those settings may be refined manually.

Example:

pbxlink.pbx.type=PBX_AASTRA_MATRA_NEXSPAN

This setting defines the IP address of the PBX. It should at least be defined with pbxlink.pbx.type so that TelServer can connect to the PBX.

Example:

pbxlink.pbx.address=192.168.0.7

It is the CSTA port on the PBX. Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.port=3211

This setting tells TelServer to listen to the specific IP address when opening the PBX connection. Default is none, meaning TelServer will listen to all interfaces.

Example:

pbxlink.local_bind_address=192.168.1.5

This setting tells TelServer to listen to the specific port when opening the PBX connection. This setting is efficient if pbxlink.local_bind_address is defined.

Default is none.

Example:

pbxlink.local_bind_port=3212

Some PBX may require an authentication. This setting defines the system password while one can use the pbxlink.pbx.user.name and pbxlink.pbx.user.password authentication. Note that user.name/password authentication will take precedence over the system.password if both information is provided.

Default value is none.

Example:

pbxlink.pbx.system.password=admin

The setting defines the user name for authentication.

Default value is none.

Example:

pbxlink.pbx.user.name=admin

This setting defines the user password if the user.name has also been defined for authentication.

Default value is none.

Example:

pbxlink.pbx.user.password=admin

This setting defines the size of the FIFO used to receive messages from the PBX. Messages are stored in the fifo waiting for treatment by the application.

Default value is 100.

Example:

pbxlink.messages.fifo.size=100

It defines PDU delimiter that is used to delimit TCP/IP packets containing CSTA PDUs.

The values can be (use the exact string) :

• NO_DELIMITER,
• TWO_BYTES_LENGTH_DELIMITER (to indicate that CSTA data from the PBX and to the PBX are always starting with the length on 2 bytes of the following PDU),
• TPKT_DELIMITER (for a TPKT RFC1006 header),
• TPKT_TWO_BYTES_LENGTH_DELIMITER (for a TPKT RFC1006 header followed by a pdu preceded by 2 bytes length header),
• HEADER_20_03_LENGTH_DELIMITER (0x20 0x03 followed by one byte for the length and followed by the PDU),
• HEADER_26_TWO_BYTES_LENGTH_DELIMITER (0x26 followed by the length on 2 bytes and followed by the PDU),
• ECMA_323_WITHOUT_SOAP_DELIMITER (when ECMA 323 is used transported in TCP following ANNEX J.2).

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.pduDelimiter=TWO_BYTES_LENGTH_DELIMITER

It defines whether audit is to be performed by TelServer. An audit of the link is useful to check the PBX is still listening to TelServer. Since problems may occur either on the TCP link (physical deconnection for example), either from the PBX side (failure for example), TelServer must be aware of them to undertake appropriate measures. If the audit is enabled, when TelServer will detect a link inactivity for a certain time defined by pbxlink.pbx.audit.timeout, TelServer will send a CSTA SystemStatus request to the PBX, the PBX must then answer by a result indicating it is in the appropriate state. If there is no result after pbxlink.pbx.audit.failedAuditMaxRetry, then the link shall be declared out of service. TelServer may then try to re-establish the link after telserver.pbxlink.automatic_restart_after_failure.timeout. If ever the failure persists, the Administrator should be enclined to undertake a "manual" action.

Supported values are "true" and "false". Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.audit.enabled=true

It defines the timeout of inactivity that makes TelServer triggers the audit. It is in seconds.

Default value is 60 seconds.

Example:

pbxlink.pbx.audit.timeout=60

It defines the period of audit request sending. It is in seconds.

Default value is 30 seconds.

Example:

pbxlink.pbx.audit.period=30

It defines the audit maximum retry count, after audit has been retried this number of time and always with no acknowledgement from the PBX, then the CSTA link is declared out of service.

Default value is 2.

Example:

pbxlink.pbx.audit.failedAuditMaxRetry=2

It defines the timeout in milliseconds the server waits for an ack to a service message (a service message is all those messages that are to be sent outside the CSTA scope such as a special sequence for establishing the session for example). When the timeout occurs the server considers the link as being out of service.

Default value is 5000. The minimum value is 500.

Example:

pbxlink.pbx.serviceMessageAckTimeout=5000

MAY BE UPDATED. This setting defines the rules to be applied to numbers provided to the PBX if they must be specifically formatted. The rules should provide a dialing number.

The setting is given as a regular expression for matching the number from the computer and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is that no patterns are defined.

Example: assuming a PBX provides numbers formatted like <xxx;term1> where xxx is the number and term1 is a terminal identifier, the following rules extracts only the number.

pbxlink.pbx.numberingRules.pbx2computer.conversionPattern.3=^<([0-9]+);.*$ > $1

MAY BE UPDATED. This setting defines the rules to be applied to numbers to be provided to the PBX.

The settings is given as a regular expression for matching the number from the PBX and a replacement string used to replace the matching number (capturing groups are allowed using $n for the capturing group n). The separator ">" (or ">>") is used to separate the matching regular expression and the replacement string.

The setting can be a list of such patterns given with an index number, the rules are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default is that no patterns are defined.

Example: assuming a PBX that accepts only Tel URL such as "tel:xxxx".

pbxlink.pbx.numberingRules.computer2pbx.conversionPattern.1=^([0-9]+)$ > tel:$1

It defines whether the display names provided by the PBX (if they are provided) are to be used. If they are used, the search through the directory is not performed.

Supported values are "true" and "false". Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.display_names.enabled=false

It defines a list, comma separated, of devices numbers that can be used to achieve call diversion on some destinations when the PBX reject doing so. For example, diversion to an external number is not always possible by call control on the PBX. Defining such numbers allows TelServer to divert the call to the first available device, answer the call on it and then transfer the call to the requested destination. The destination is given by a pattern pbxlink.pbx.diverting_slot.use_on_divert.pattern.

Default value is none.

Example:

pbxlink.pbx.diverting_slot.list=588,589

This setting defines the destinations when a diversion should use a diverting slot.

The setting is given as a regular expression for matching the destination number.

The setting can be a list of such patterns given with an index number, the patterns are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default value is none.

Example:

pbxlink.pbx.diverting_slot.use_on_divert.pattern=^[0-9]{5,}$

It defines the version of CSTA to be used. It can be (use the exact string) :

• CSTA_PHASE_I : for CSTA phase I (ECMA 179/180)
• CSTA_PHASE_II : for CSTA phase II (ECMA 217/218)
• CSTA_PHASE_III : for CSTA phase III (ECMA 269/285)
• CSTA_PHASE_III_XML : for CSTA phase III (ECMA 323)
• CSTA_PHASE_III_XML_OVER_SIP : for CSTA phase III (ECMA 323 following ECMA TR87)

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.version=CSTA_PHASE_II

It defines whether ACSE should be used to establish the CSTA link to the PBX.

Supported values are "true" and "false". Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.acse.enabled=false

It defines the application-context-name component (defined as Application-context-name ::= OBJECT IDENTIFIER) in the ACSE AARQ-apdu. Although it is normalized by CSTA, PBX manufacturers sometimes change this value. The setting is given as an OBJECT IDENTIFIER written as a string where each arc is separated by dots.

Default value is "1.3.12.0.180.1". Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.acse.application_context_name=1.3.12.0.180.1

It defines the called_AP_title component (defined as AP-title-form2 ::= OBJECT IDENTIFIER) in the ACSE AARQ-apdu. The setting is given as an OBJECT IDENTIFIER written as a string where each arc is separated by dots.

Default value is none. Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.acse.called_AP_title=1.3.12.0.180.1

It defines whether ECMA 354 specifying the application session estalishment should be used to establish the CSTA link to the PBX. This can be used if pbxlink.pbx.csta.version is CSTA_PHASE_III_XML.

Supported values are "true" and "false". Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.ecma-354.enabled=false

These settings define the services and events the PBX is supposed to handle.

These settings may be useful for the SIP/CSTA gateway in case the PBX is not able to provide the service or an identical one, or to override the service given by the PBX. Normally, the service is mapped to an ACSE request/result but if the ACSE is not enabled or unable to provide the service (this is the case if the cstaVersion is CSTA_PHASE_I because there is no standard means to get the information defined in the ECMA standard). These settings allow to define default values that will be used to give the response to the CSTAp3XML GetCSTAFeatures service.

In addition, the pbxlink.pbx.csta.supportedServices.default setting can be used for the TelServices gateway (as well as for the SIP/CSTA gateway) to enable or not specific services for the end user.

The default values are given in the examples below.

Examples:

To define the default supported services :

pbxlink.pbx.csta.supportedServices.default=\
<supportedServices>\
 <systemStatServList><requestSystemStatus/></systemStatServList>\
 <monitoringServList><monitorStart/><monitorStop/></monitoringServList>\
 <callControlServList><alternateCall/><answerCall/><clearConnection/><conferenceCall/><consultationCall/>\
 <deflectCall/><holdCall/><makeCall/><reconnectCall/><retrieveCall/><singleStepConference/><singleStepTransfer/>\
 <transferCall/>\
 </callControlServList>\
 <logicalServList><getDoNotDisturb/><getForwarding/><setDoNotDisturb/><setForwarding/></logicalServList>\
</supportedServices>

To define the default supported events :

pbxlink.pbx.csta.supportedEvents.default=\
<supportedEvents>\
 <callControlEvtsList><conferenced/><connectionCleared/><delivered/><diverted/>\
 <established/><failed/><held/><originated/><queued/><retrieved/><transferred/>\
 </callControlEvtsList>\
 <callAssociatedEvtsList><serviceCompletionFailure/></callAssociatedEvtsList>\
 <logicalEvtsList><doNotDisturb/><forwarding/></logicalEvtsList>\
</supportedEvents>

It defines whether a SnapshotDevice is allowed.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.snapshotDevice.enabled=true

It defines whether a SnapshotDevice is allowed after a MonitorStart. Some PBX policy is to report events after a MonitorStart only when the device has gone into the iddle state but not before (even if the MonitorStart is done). For example, if a device is in communication and a MonitorStart is requested, the PBX will not report the event signalling the end of that communication. In such a situation, a SnapshotDevice request may not be accurate because the existing communication will never be removed. This setting allows controlling the SnapshotDevice.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.snapshotDevice_at_monitorStart.enabled=true

It defines whether the strict CSTA call model is used. In the strict call model, Transfer/Conference/Reconnect/Alternate are authorized with any active and held calls, and not only for calls that are bound within a consultation call context.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.strict_call_model.enabled=true

It defines whether the conference model differs from the regular CSTA conference model. The CSTA regular call model specifies that a conference is represented by a call and one connection to that call per involved device. This implies that a device has got a single connection to the conference. In the "two_calls_conference_model", the device controller of the conference stills holds two connections to the conference (with the same call identifier) and is then able to perform an AlternateCall or a ReconnectCall or a TransferCall.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.two_calls_conference_model.enabled=false

It defines whether a new call, while an existing call is running, should be considered as a consultation call. Normally, it is considered as new call appearance.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.force_consultation_on_new_call.enabled=false

It defines whether the SetFeature/Forward Immediate On or Off is overriden by the server. True means that the request is intercepted and immediately answered back with a positive ReturnResult while the actual request is still sent to the PBX. The return (either ReturnResult or Error) from the PBX will then be ignored. This is useful for PBX that would provide error for activating/deactivating a forward that is already activated/deactived; a better behavior is simply to answer a positive result in such a case.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.force_immediate_forward_result.enabled=false

It defines whether the Forwarding Immediate On or Off event is overriden by the server. True means that a SetFeature/Forward/Immediate request is intercepted and that on a positive result from the PBX, the adequate event is simulated as if the PBX has sent it. This is useful for PBX that do not provide immediate forwarding events.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.force_immediate_forward_event.enabled=false

It defines whether the SingleStepTransfer is simulated by a ConsultationCall followed by a TransferCall. This is helpful when the PBX supports only CSTA phase I.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.single_step_transfer_simulation.enabled=false

It defines whether the SingleStepTransfer simulation implies a TransferCall only after the Established event indicating that the transferred to device has answered the call.

Default value depends is false which means the as soon as the Delivered event is received the call is transferred.

Example:

pbxlink.pbx.csta.single_step_transfer_simulation.transfer_on_Established.enabled=false

It defines whether the SingleStepConference is simulated by a ConsultationCall followed by a ConferenceCall. This is helpful when the PBX supports only CSTA phase I.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.single_step_conference_simulation.enabled=false

It defines whether the SingleStepConference simulation implies a ConferenceCall only after the Established event indicating that the added device has answered the call. It is useful when the PBX does not accept to conference calls that are not 'connected'.

Default value depends is false which means the as soon as the Delivered event is received the call is conferenced.

Example:

pbxlink.pbx.csta.single_step_conference_simulation.conference_on_Established.enabled=false

It defines whether the MonitorStart can be started only when the agent logs on. This is applicable only if the PBX reports a system service notifying that the agent logs on without being monitored previously. Alcatel PBX allow such behavior. If this setting is true, TelServer listens to specific information from the PBX stating that an agent logs on (and off). When the information is notified, TelServer sends the monitorStart to the PBX. When the agent logs off, the monitor is stopped.

Default value depends on pbxlink.pbx.type setting.

Example:

pbxlink.pbx.csta.monitorStart_at_agentLogin.enabled=false

It defines whether the CSTA crossRefID should be generated as being the bytes from the ascii number or considering the number is the hexadecimal value (adding the char 'F' at the end if needed). The second option (setting being false) is possible if the dialing number consists of numeric digits only while the first option can be used in all cases.

Default value is true.

Example:

pbxlink.pbx.csta.generate_crossRefId_from_ascii.enabled=true

It defines whether the CSTA call reference is set with the global call ID provided by the PBX link (if it does). This may be useful if the PBX link handles several PBX.

Default value is false which means that the local call ID provided by the PBX is used. To allow the global call Id, it may require a specific configuration on the PBX.

Example:

pbxlink.pbx.csta.use_pbx_global_callid.enabled=false

It defines the SIP session timer if pbxlink.pbx.csta.version is CSTA_PHASE_III_XML_OVER_SIP.

It is in seconds. Default value if applicable is 1800.

Example:

pbxlink.pbx.sip.session_timer.period=1800

It defines the SIP URI of the host if pbxlink.pbx.csta.version is CSTA_PHASE_III_XML_OVER_SIP.

Default value if applicable is the local address.

Example:

pbxlink.pbx.sip.uri.host=192.168.0.20

It defines the Asterisk dialplan contexts used to initiate calls. The context of a controlled phone may be provided alternatively in the phone number passed to TelServer (for example a tel URI tel:11;ext=Context.11;context=Context can be used), in which case the given context is used first.

Default value is none.

Example:

pbxlink.pbx.asterisk.contexts.list=default,from-internal

It defines the Asterisk conferences number that TelServer can use when the user requests a ConferenceCall for conferencing an held and an active call. Natively, Asterisk uses meetme rooms for conferencing. A ConferenceCall request will redirect held, active and local users to a free meetme room among those defined in the list. Each meetme number in the list must allow the user to enter the conference without requesting a password. It is optional.

Default value is none.

Example:

pbxlink.pbx.asterisk.conferences.list=200,201,202

It defines the maximum timeout to establish an Asterisk conference. It is the maximum time needed to get the first MeetMeJoin event after redirecting the active channel to the meetme room.

Default value is 5000 milliseconds.

Example:

pbxlink.pbx.asterisk.conference_setup.timeout=5000

It defines the Asterisk database family used for the Do Not Disturb. It is optional.

Default value is none. It is DND for FreePbx for example.

Example:

pbxlink.pbx.asterisk.db.dnd.family=DND

It defines the value that indicates a DND "on" in the Asterisk database.

Default value is "YES". It is "YES" for FreePbx for example.

Example:

pbxlink.pbx.asterisk.db.dnd.family.on_value=YES

It defines the Asterisk database family used for the Call Forward Immediate (or Call Forward All). It is optional but if set, all callForward settings are mandatory.

Default value is none. It is CF for FreePbx for example.

Example:

pbxlink.pbx.asterisk.db.callForwardImmediate.family=CF

It defines the Asterisk database family used for the Call Forward Busy. It is optional but if set, all callForward settings are mandatory.

Default value is none. It is CFB for FreePbx for example.

Example:

pbxlink.pbx.asterisk.db.callForwardBusy.family=CFB

It defines the Asterisk database family used for the Call Forward No Answer. It is optional but if set, all callForward settings are mandatory.

Default value is none. It is CFU for FreePbx for example.

Example:

pbxlink.pbx.asterisk.db.callForwardNoAnswer.family=CFU

It defines whether the SIP phone gateway is enabled. This gateway is useful for some SIP phones such as Snom phones which are able to provide 'call' information to TelServer. The information is used to allow specific features (such as HoldCall/AnswerCall...) that are not efficient otherwise.

Default value is false.

Example:

pbxlink.pbx.asterisk.SIPPhoneGateway.enabled=false

This setting defines the local TCP port for the SIPPhone gateway.

Optionnally one can precise the the bind address of the TCP port (i.e. the server will listen only to the specified port on this IP address). The bind address can be used on a multi-homed host for a server that will only accept connect requests to one of its addresses.

Default port is 8084.

Examples:

For specifying a listening port for all IP addresses of the machine :

pbxlink.pbx.asterisk.SIPPhoneGateway.port=8084

For specifying a listening port for all IP addresses of the machine with a bind address :

pbxlink.pbx.asterisk.SIPPhoneGateway.port=8084,192.168.0.2

This setting defines the protocol to be used on the TCP port. It can be TCP, SSL or TLS (ignoring case). To define a secure gateway, please refer to the chapter "Secure gateway configuration".

Default protocol is TCP.

Example:

pbxlink.pbx.asterisk.SIPPhoneGateway.port.protocol=TCP

This setting defines the keystore path when port protocol is SSL or TLS.

Default path is ${TelServer_HOME}/work/TelServer.jks.

Example:

pbxlink.pbx.asterisk.SIPPhoneGateway.port.keystore.path=${TelServer_HOME}/work/TelServer.jks

This setting defines the password of the keystore.

Default is 'unigone'.

Example:

pbxlink.pbx.asterisk.SIPPhoneGateway.port.keystore.password=unigone

This setting defines the password of the certificate key in the keystore.

Default is 'telserver'.

Example:

pbxlink.pbx.asterisk.SIPPhoneGateway.port.keystore.key.password=telserver

This setting defines the patterns of extensions defined in the dialplan for which no events should be reported. It is useful in a dual forking configuration in a MOCS environment because the dialplan has normaly configured a dual Dial one to the SIP trunk to the Mediation Server and one to the Asterisk SIP device. Entering the pattern of the SIP trunk in this setting prevents the Dial to the SIP trunk to report any event.

The setting is given as a regular expression for matching the dialed extensions.

The setting can be a list of such patterns given with an index number, the patterns are treated in the given order. Leading and trailing whitespaces are ignored. Be careful to escape the '\' character used to escape the regular expressions characters.

Default value is none.

Example:

pbxlink.pbx.asterisk.ignore_events_on_dialed_extension.pattern.1=

It defines the JTAPI peer as a Java class name.

NOTE that the jar file containing the class should be in the classpath. The simpler is to replace the jtapi.jar file in the lib directory of the distribution.

Default value is none.

Example:

pbxlink.pbx.jtapi.peer=com.cisco.jtapi.CiscoJtapiPeerImpl

It defines the JTAPI service that is provided to the peer to get an appropriate provider. It is optional and depends on the JTAPI implementation.

Default value is none.

Example:

pbxlink.pbx.jtapi.service=AVAYA#S8500PE#CSTA#MY-AES

It defines the JTAPI request timeout. It is provided to the JTAPI implementation, assuming that it provides a means to define this timeout.If the implementation does not provide a means to set this value, this setting is ignored.

Default value is 5 seconds.

Example:

pbxlink.pbx.jtapi.request.timeout=5

This error occurs if it has been detected that the link to the PBX audit has failed. Normally, it should try to restart it automatically after a while but this feature has not been set in configuration. In such a case, as soon as the link is "out of service", TelServer invites the Administrator to undertake a manual action.

This warning occurs when TelServer configuration has been updated through the remote management.