Administrator Guide: SMP Application¶

Overview¶

What is the SMP Application ?¶

Escaux solutions real-time tasks always run on Service Operational Points (SOP’s). These are appliances that can be installed on-site for connectivity and to be close to the users. SOP’s can also be installed remotely, as long as the phones and applications can reach them over a network. Those can also take the form of virtual appliances (vSOP’s).

Non-real-time tasks are split off in a centralized Service Management Point (SMP). A full-size SMP deployment possibly consists of up to 6 machines, corresponding to 5 roles: SMP Web, Engine, Reporting, SSH Router 1, SSH Router 2, and BMS (Backup and Monitoring Service).

The SMP Application is the software which is running and distributed on the SMP Web, Engine and Reporting machines. The SMP Application basically provides the following services:

Service Creation
Provisioning
Day-to-day provisioning and operations
Reporting
Licensing

Multiple SMP Application instances (possibly different versions) can run on the same SMP cluster.

The SMP Admin software is a common layer on the SMP Web, Engine and Reporting. It adds support for multiple SMP Application instances. It also contains shared libraries and the schema for the database containing SOP key configuration, which is shared by all SOP keys. In that sense it is a dependency for the SMP Application releases and upgrading the version used by one of the instances might require to upgrade the SMP Admin common layer.

SMP instances are typically used to distinguish between production and test environment (you’ll see names like “stable-4”, “ed-4”, “production” or “test”). Within the SMP Application, any SOP key can be configured to use one of those instances. The current SMP instance being used can be seen in the browser address bar (e.g. smp001-stable-4.escaux.com or smp001-ed-4.escaux.com).

Upgrading the SMP typically means upgrading the SMP Application of one of the instances. Hence the SOP’s using that instance will get the new version of the SMP Application.

The remainder of this Admin Guide will concentrate on the SMP Application part of the SMP cluster, for version 5.6.

What Administrators should be aware after an upgrade to SMP Application 5.6 from 5.3 ?¶

Depending on password policy defined by Escaux for the SMP instance, the SMP will require a better password when changing it for a user
New tool for bulk administration called FlexAdmin allowing to manage a subset of the internal directory with CSV files
Task and reports will not be sent by mail anymore when only the e-mail address is configured. Output should be set to mail. Tasks and reports should be modified accordingly where needed.
In order to allow deletion of smpadmin users, those can now (only) be managed in a scope SMP SOP key. Smpadmin users can now be created on SMP Scope SOP key only. To manage those users, access right to that SOP key is required.

What Administrators should be aware after an upgrade to SMP Application 5.3 from 4.10 ?¶

The concept of template is now extended and templates can be upgraded while keeping customer data. This is done by keeping track of components that came with the template using the source field and by moving most of the configuration to the internal directory.

Moving modules and resources configuration (for example) to the directory is possible thanks to the new Escaux Templating Language. That language can be used in parameters to retrieve configuration from fields of the internal directory or profile parameters.

Resources can now serve as template for other resources by introducing the concept of “Master Resources”. Other resources can then take parameters from a master resource by “inheriting” the values. templates will mostly contain master resources.

Parameter sets will replace the global parameters for the configuration of profile parameters (preview in SMP Application 5.3). The number of profile parameter is not limited to 42 vars anymore. The names of the profile parameters are visible in bulk administration instead of var_1, var_2,... Parameter sets also support parameters of “Complex type” and fine-grained permissions for users (Roles)

Roles allow to define groups of users sharing the same permissions on profile parameters (preview in SMP Application 5.3). That way only one user profile can be created for example but with different permissions on the available parameters depending on the Role. Roles are configured in the parameter sets and assigned to users in “Directory” » “Users”.

“Apply Changes without cache” can now be executed without requiring to manually clear the cache.

“Install Modules” and “Apply Changes” can now be automatically triggered after the SOP baseline installation using the new automated installation option.

In the internal directory a standard/advanced view switch button is available in list view and in edit view. The standard view shows only the most frequently used fields and so avoids making errors and overloading the screen.

Notes can be added and seen at cluster level by smpadmin users.

The SOP search field and SOP keys drop-down list is replaced by a more efficient unified SOP selection bar.

There are many changes in bulk administration:

new and renamed columns for resources, internal directory, users
When parameter sets are enabled, bulk administration for the internal directory is available per profile and the parameter names are shown in the column titles
Routes are now exposed in bulk administration

Task output is now sent by mail also when launched manually (not for reports). For tasks and reports the output can now be written to a file on the filesystem or to a distant FTP location.

New scopes are available for SOP keys (in addition to SOP and Cluster): Account & SMP. Those provide a context for components that require access to all SOP key of the same account or all SMP. It is used by new ReportUPTransactions for example.

SMP Application concepts & functionalities¶

Provisioning	Preparing a solution for a customer. It is the first configuration or big change on existing configuration.
SMP-SOP Connectivity	SOP’s connects to the SMP by establishing 2 SSH tunnels. Those tunnels can be used by the SMP to “Install Modules” and push configuration by “Apply Changes” but it first required to accept the SOP public key in the “Server Configuration” page for that SOP key.
SOP key	Unique identifier for SOP’s and clusters, made of 8 digits (e.g. 00000004). SOP keys are assigned to customers by specifying the Account code. To manage anything on the SMP the user first has to choose a SOP key he has access rights on. SOP keys can be configured in the “Server/Cluster Configuration” page for the selected SOP key.
Consolidated Management	Feature allowing to manage a cluster of SOP’s in a consolidated way, with the configuration from all SOPS in one single place.
Apply Changes	When the configuration is changed on the SMP, it is not immediately pushed to the SOP’s. Doing so would mean a performance penalty with every change that were made. Also, it would be dangerous in case an error was introduced: the actual SOP configuration would be modified with an incorrect configuration and problems could arise. Changes made on SOP’s are not real-time. Thanks to that the SMP can perform consistency checks before applying the changes, the SMP always has a backup copy of the configuration and in case a SOP becomes defective, the configuration from the SMP can be pushed to a new SOP.
Deployment Architecture	The SOP deployment architecture can be chosen during provisioning: a standalone SOP, a redundant solution in Active/Active or Active Standby or a combination of those in a cluster. Supported architectures include single site or multi-site, with a centralized or distributed solution. A deployment architecture can also make use of virtual appliances called vSOP’s.
Server/Cluster Configuration	Page in the “Advanced” menu of the SMP Application. Depending on the SMP Access Level, it allows to define the deployment architecture, configure SOP keys, define the SMP instance version to be used, configure basic SOP IP settings, enable monitoring and backup, setup the SMP-SOP connectivity,...
(Service) Template	Snapshot of a solution that can be reused for other SOP’s. It is made from an existing configuration on the SMP. It can be a public template, being a standard solution provided by Escaux or template available only to the same Account as the SOP key it was created on.
Directory Centric Approach	Idea to move modules, resources, cluster/server configuration in the directory. It allows to offer a simpler configuration interface, that can be exposed in end-user applications. By having all customer configuration at one place it allows to upgrade solutions while keeping customer data. See Apply template upgrade
Module	Escaux software to be installed on SOP’s like “Communication Server”, “net.Console” or “Polycom Phone Support”. That software can then live on its own or be used and configured by resources and actions..
Resource	Allows to provision and configure things on SOP’s for the Escaux solution like IP phones, Interfaces, call queues, desktop applications,... but also monitoring probes and advanced reports.
Master Resource	A resource defined as master resource can contain configuration that can be inherited by other resources during provisioning. That way a standard configuration can be applied to all resources without requiring to duplicate and update configuration in other resources.
Action	Used to configure telephony flows (e.g. user or IVR callflow) and application processes (e.g. Instant Messaging). Actions are assembled in callflows using logical connectors in the Escaux Callflow Editor tool.
Application Selector	Special action, outside the callflow editor, assigned to a combination of profile and status. It is the first action executed.
Profile	Feature set for user or service extensions. Supports multiple variants depending on status and can be configured per extension using profile parameters that can be global parameters or parameter sets. Profiles make use of application selectors and callflows. Profiles are assigned to extensions during provisioning.
Callflow	Set of configured actions assembled in a logical tree. Callflows are assigned to profiles.
Bulk Administration	SMP Application tool allowing to export and import configuration in a CSV format for provisioning purposes. It is available for example for the management of end-users, internal directory, resources,...
Access Level	User privileges for SMP Application features in ascending order of access rights, from end-user that can only manage his own extension to superadmin (ESCAUX).
Role	Set of permissions given to users for profile parameters management defined in a service template. Roles allow to define fine-tuned access levels (read and write, read, read only and hidden) for subsets of parameter sets.
Global Parameter	Parameters that can be used in callflows. Those can live on their own as global values or be assigned to profiles and so the value might depend on what is configured for the extension using the profile. A type can be defined, being Integer, String, Extension or Options Select for example. This will influence in which actions the parameter is available and how to render the input field in profile parameters GUI.
Parameter Set	Replacement to global parameters as from SMP Application 5.3 supporting more than 42 parameters per profile and fine-tuned permissions (Roles)
Profile Parameter	Parameter assigned to a profile and that can be changed per extension. Can be global parameters or parameters from parameter sets.
Permission	Giving users access to desktop applications and advanced reports, with some options
Template Restriction	Mechanism used for some Escaux service templates like Fusion that allows to do an “Apply Changes” only if the resources, modules and actions used match template ones (except callflow action) and restrict from editing template components
Automated Installation	Automatically accept SOP public key, launch “Install Modules” and “Apply Changes”
Basic Reporting	Reporting on SOP data
Advanced Reporting	Reporting on data synchronized to and processed by SMP
Scheduling	SMP Application feature used for tasks and reports. Those can be scheduled to be run Continuously, Every hour, Every night, Every Sunday night, Every 1st of the month.
Apply (Public) Template Upgrade	Loading a new version of the same template while keeping Customer data. Requires compliant templates (source and destination).
User	Accounts for end-users giving permissions for desktop application and accounts for SMP Application users with higher Access Levels.
Snapshot	Before every “Apply Changes” a backup of the configuration is made on the SMP. Several backups are kept and can be restored. Snapshots can also be created manually.

Getting started¶

Point your web browser to https://smp.escaux.com or the partner SMP URL, and enter the username and password you received. The username is usually your e-mail address.

Provisioning on SMP¶

Unless specified, all the provisioning can be done when the SOP is not online (yet).

Defining the Deployment Architecture¶

The SMP Application allows to define the SOP deployment architecture and assign SOP keys to customers. Possible deployment architectures are: a standalone SOP, a redundant solution in Active/Active or Active Standby or a combination of those in a cluster. Supported architectures include single site or multi-site, with a centralized or distributed solution. A deployment architecture can also make use of virtual appliances called vSOP’s.

3 Deployment architecture choices are to be implemented in the early stages of the provisioning during the SOP key configuration:

Standalone SOP,
Cluster of SOP’s and
Active/Standby redundancy.

When managing the solution the SMP web interface and tools will adapt themselves to the chosen architecture. For example when a cluster is created:

a network Overview on the home page shows all the physical SOP’s and their status,
a tool allowing to configure MeshSipTrunks between SOP’s shows up,
most of the configuration is done at cluster level,
the modules installation and SOP key configuration remain at the physical SOP level only.

This is difficult to change afterwards. Others are more related to configuration. See the summary table below.

Architecture	SOP key Configuration	Other
Standalone SOP	standard
Cluster of SOP’s with Consolidated Management	Create an additional SOP key for the cluster level and configure the same network ID for all SOP keys	See the Consolidated Management Administrator Guide
Active/Standby redundancy	Define one SOP as clone of the other	See the Active/Standby Administrator Guide
Active/Active redundancy	Only requires SOP’s to be in a cluster	See the Active/Active Administrator Guide
Multi-site Centralized Solution	Only requires SOP’s to be in a cluster	Configure Sites and Local Area Networks. See also the Active/Active Administrator Guide
Multi-site Distributed Solution	Only requires SOP’s to be in a cluster	Configure Sites and Local Area Networks. See also the Active/Active Administrator Guide
Virtual Appliances		First set up a vSOP Host and vSOP(s) then configure like any SOP(s)

For more information, see Deployment Architectures and Virtual Appliances.

Assigning SOP keys to customers (smpadmin)¶

The first thing to do in order to provision a solution is to assign SOP keys to customers. For each (virtual) machine one SOP key is required. An additional SOP key is required for the cluster level in case multiple SOP’s are going to be installed and Consolidated Management should be implemented.

Choose unassigned SOP keys in the SOP key selection tool
In the “Server/Cluster Configuration” page in the “Advanced” menu, select the right Account for the customer or create a new one before.
If Consolidated Management is going to be implemented,
- an additional SOP key is required for the cluster level,
- for the first one choose “Cluster” for the Cluster/SOP drop-down
- choose a name for the cluster and put it in Network ID, use the same name for all other SOP keys (this is what will put all SOP’s in the same cluster)
For each physical SOP key (machines) choose SOP for the Cluster/SOP drop-down

For SOP’s forming an Active/Standby pair: in the “Server Configuration” page for the second SOP key, choose Clone From... the first SOP key.

ALERT For physical SOP keys, the server/cluster configuration includes managing SOP IP details and timezone. This should be edited only after Loading the template (which erases those fields).

The “In Service” flag is an administrative status which impacts backup and monitoring. You might to keep it on No for all SOP key until the SOP’s are used in production;

Regarding other fields like “Backup”, “Monitor”, “Automated Installation”,... see later.

Decide and load the solution to be implemented¶

Once the early architecture choices have been made (Standalone, Active/Standby or Cluster), the service template to be implemented can be loaded. This is to be done on each SOP key, including the cluster SOP key.

Advanced > Load (Public) template

Configuring SOP IP¶

Basic SOP network configuration is to be configured on the “Server Configuration” page. Some modules like the Network module, Communication Server,... use that configuration during the “Install Modules” process.

ALERT That configuration can also come with the template that was loaded. Or it could be implemented directory centric in the template. In that case, it should be configured in the internal directory, using the extensions and profile parameters foreseen in the template. For those reasons, always load the template before configuring the network, because the changes would be lost after loading the template.

The following fields are mandatory:

IP address
Subnet mask
Default gateway
Primary and secondary DNS server. If only 1 DNS server is available, fill in the same value for both fields

Configuring Sites and and Local Area Networks¶

Sites¶

Advanced > Site Configuration

In case the corporate network is composed of several sites interconnected by VPN links, it is possible to define the sites where the phones are connected.

The sites are defined in a very basic way. Only the name of the site is required, the other fields are user attributes which are free. Those can be used in callflows.

There can be various applications, more common are:

Call Admission Control: bandwidth control on the various links
Support for Emergency numbers in case the same SIP Trunk is used for multiple sites. See Escaux Fusion 3.0 Install guide

Phones are associated to sites thanks to the network definition. See below.

Local Area Networks¶

Advanced > Network Configuration

A site is composed of one or various Local Area Networks (LAN). These LAN segments identify a particular network region. On this page local network(s) can be linked to the site locations defined before.

A network name, the network address and subnet mask need to be filled in as well as the site the network should belong to.

Configuring modules¶

Escaux software can be configured module-wise. This is the case for global module configuration (like the “Outgoing SMTP Server” for the Mail Server module) or a default configuration that can be overridden in resources (like the “Qualify SIP devices registration” in Communication Server).

See the Module reference guide

The SMP Application shows the modules, their version and configuration like it is supposed to be on the SOP if everything that was configured on the SMP was installed on the SOP.

Advanced > Module Configuration

This will show the list of modules that are present on the selected SOP.

Since SMP Application 5.7.0 an extra field allows you to disable modules. By default all modules are always enabled. Only if you explicitly disable it the module will behave as if it was not in the list. There will be no checks done of the packages.

It is not a real-time view. Also making changes in the modules list or configuration only impacts the SOP when triggering an “Install Modules”.

Modules configuration can also come with the template that was loaded.

As from SMP Application 5.3 a mechanism allows service creators to enable module parameters provisioning inside profile parameters of extensions in the internal directory. This is using a Templating Language that takes place in the usual module configuration parameters. That’s why editing module parameters is not possible anymore when those modules are part of the service template that is applied, as it would break the template. The source field for those modules is usually set to “Template” so that template upgrade is supported.

The following modules typically need to be configured:

Mail server
Local admin password: admin and customer ‘s password
Fax server: Domain and number of fax channels
DHCP Server: disabled by default, to be activated if needed
NTP server: if default NTP server are not reachable

If you need to add another module, see the modules’ release notes to decide which version the module to use, how to configure it and what are the dependencies on other modules or resources. If template restrictions are in place, the “Install Modules” and “Apply Changes” will not be possible without asking Escaux to explicitly allow the additional modules. See “Allowing Extra Modules, Resources”

Note that in order push new modules configuration to the SOP, the modules need to be re-installed regardless if the change was made in the modules parameters directly or directory centric.

To install a module, the action first needs to be set to “INSTALL” in the modules’ list or in the module configuration. In the modules’ list simply click on “nothing” to flag the module as to be installed (“nothing” will be replaced by “INSTALL”). You may want to remove the INSTALL flag for modules you don’t need to (re)install. On the top of the page, you can also choose to “Schedule” all modules for installation or “Uncheck” all modules for installation.

Click on the “Install Modules” button to trigger the installation of the modules marked with “INSTALL”.

Managing modules at Cluster level ¶

Advanced > Module Configuration

From the cluster view, this menu item allows manage modules on several SOP’s at once.

In a first step, select the SOP’s and modules you want to manage (upgrade, reinstall,...)

Next, a table is shown with the selected SOP’s and modules.

The highlighted cells show which modules will be (re-)installed on which SOP’s when pressing the “Apply and Install modules” button.

Use the ‘install’ checkbox to highlight the cell, indicating that you want to (re-)install a module.

Use the dropdown fields to change the version, i.e. upgrade or downgrade a module.

Changing the version will automatically highlight the module. It would not make any sense to change the version of module in the database of the SMP without actually reinstalling it.

When deselecting the install flag, the select box will be reset to the original version.

Just above the select boxes, the current version is shown for your reference. You can click on the current version to view and edit the parameters of this module.

To easily upgrade (or downgrade) a module on all selected SOP’s, use the dropdown fields on the top header of the table.

It is not possible to add new modules from this page. To add modules, use the modules configuration tool from the SOP view.

Adding and configuring Resources¶

Resources allow to provision IP phones, call queues, Music-On-Hold, desktop applications, audio prompts, vSOP,... configure SIP/ISDN Interfaces,... Example resources could be delivered with a service template.

See the Resource reference guide

As from SMP Application 5.3, just like modules, a mechanism allows service creators to enable resource parameters provisioning inside profile parameters of extensions in the internal directory. It allows:

to offer a simpler configuration interface, that can be exposed in end-user applications
to have all customer configuration at one place.

This is using a Templating Language that takes place in the usual resource configuration parameters. That’s why editing resource parameters is not possible anymore when a service template is applied, as it would break the template.

Another addition of SMP Application 5.3 is the ability to define resources as master resources allowing other resources to inherit parameters from those.

Resources provided with a service template:

are usually template (master) resources with validated configuration,
usually have their source field set to “template” so that template upgrade is supported,
usually make use of the Escaux Templating Language to implement a directory centric provisioning

If you need to add resources not foreseen in the service template, See the resources’ release notes to decide which version of each resource to use, how to configure it and what are the dependencies on modules. If template restrictions are in place, the “Apply Changes” will not be possible without asking Escaux to explicitly allow the additional resources. See “Allowing Extra Modules, Resources”

Pushing new resources or new parameters to the SOP is done using the “Apply Changes” feature.

Configuring Routes, Route Groups & Restriction Groups¶

ALERT This can be restricted by template. In that case, configure outgoing profiles/callflows in the internal directory. See the template documentation.

Restrictions: each phone can be restricted for outward calls. For example, one phone can be allowed to make international calls while another is not. Some users may have different phones with different restrictions: for example, if a floor manager has both a fixed phone as well as a cordless one, the cordless phone could be put in a group that only allows internal calls. While on the floor, he can call colleagues. For calls outside of the company, he can use his fixed phone in the quieter environment of his office.
Routes: to make it easy to restrict phones, first define routes and route groups. A route maps a phone number pattern (for example, all numbers starting with 0049*) to an interface (a SIM box with a SIM card of a specific provider). These routes are grouped: this and other routes are part of a route group called “mobile”.
Phone and restrictions: a restriction group is a list of route groups. For example, one could contain the route groups “national” and “mobile”, but not “international”. If we put a phone in that restriction group, then that phone cannot make international calls.

Routes¶

Communication Routing > Routes

The best way to link numbers to routes is to use patterns that will match the wanted numbers to the corresponding routes.

To make patterns, use the following special characters:

X matches any digit from 0-9
Z matches any digit from 1-9
N matches any digit from 2-9
[1237-9] matches any digit or letter in the brackets (in this example, 1,2,3,7,8,9)
. wildcard, matches one or more characters
! wildcard, matches zero or more characters

There are several kinds of patterns that can be configured using those special characters. Note that every pattern must start with a “_”:

Pattern	Explanation	Example of matching numbers
`_0XZ`	Match number starting with a 0, followed by a number from 0 to 9 and a number from 1 to 9	001, 042
`_112.`	Match any number starting with 112 but with at least one character after the 112	1122, 1123
`_112!`	Match any number starting with 112	112, 1121
`_04[6789]Z.`	Match any number starting with 04 then 6,7,8 or 9 and then any number between 1 and 9	0482111111, 0467111111

ALERT Be careful not to use the pattern “_.” as it will match everything, including some special extensions used internally.

Route Groups & Restriction Groups Definition¶

Communication Routing > Route Groups & Restriction Groups

A route group is simply a number of routes grouped together for a certain reason. For example, mobile calls show certain patterns that can be managed in the routes list and they can be grouped together in this list.

Restriction Groups Configuration¶

Communication Routing > Restriction Group Configuration

A restriction group is a list of route groups that will be used as permissions: all users in a restriction group can only call numbers that correspond to routes in the route groups of the restriction group. Setting up the relationship between routes and route groups was done before. This section describes the relationship between route groups and restriction groups.

In the list you can see all the route groups that each restriction group contain. In the screenshot above, we see that the users who are in the restriction group called “RestrictNatMob” can only call internal numbers, national and mobile numbers.

The precedence allows us to define a priority for each route group in the restriction group. This is useful when there are at least two routes that overlap, to ensure that the right route will be selected. Contrary to most routing mechanisms, the SOP will not necessarily select the route based on the longest matching prefix. Some examples:

For two routes with the patterns “_04.” and “_043.”, setting a smaller precedence to the route with the pattern “_043.” will ensure that all numbers starting with 043 will use this route and not the other one.
For two routes with the same pattern but different gateways, sometimes one should be given the priority in a given restrict group. This can be done using a smaller precedence for this route in the given restrict group.

Callflows, voicemail extensions and other predefined voice application are included in the ‘default’ route group. It is therefore mandatory to include the route group ‘default’ in custom restriction groups.

Restriction groups and route groups are also known as contexts. This nomenclature is sometimes used in the resource configuration for interfaces.

Using Bulk Administration¶

Bulk administration is available for “Users”, “Directory”, “Resources”, “Routes” (new SMP Application 5.3), “Incoming Number Mapping” and “Outgoing Number Mapping”.

If multiple administrators connect to the SMP, a straight execution of a bulk administration task may lead to problems, as another administrator can modify the configuration while the bulk administration is ongoing. To avoid this, it is a good practice to lock the configuration for the duration of the bulk task and to unlock it afterwards. See the “Advanced” menu.

Example¶

Whether you want to upload a list of users, extensions, phones or something else, the procedure starts simple: go to the menu item that you would use to manually add or configure those items. Above the list view, you will also see a “Bulk Administration” button, if that option is available for what you want to configure. The example below shows the bulk administration option in the user management section of the SMP directory menu:

When clicking the “Bulk Administration” link, you get an explanation of the procedure that includes a description of the fields of the data you will be importing:

The procedure has three steps:

You can download a template file in CSV format (comma separated values). This template can contain either:
- all components of that type currently configured in the SMP (except components delivered with a service template),
- or it can contain only the previously uploaded CSV values.
If you open this file, it will usually open in a spreadsheet program like Microsoft Excel or OpenOffice.org Calc. You can modify all the data you want, import other files and perform all other operations that your software allows. Finally, save the file again in CSV format.
Upload the edited CSV file with the upload field. Note that a maximum of 5000 lines in the imported file is allowed.

It is possible to skip steps 1 and 2 and to upload a CSV file immediately. This can be practical if you have just exported certain data from another system, for example, user data from a CRM. However, it still makes sense to first download the template to make sure that your CSV file is formatted correctly.

In the CSV file, you have the option to include a source column or not. This gives you the following choice:

No source column: the SMP will automatically fill in CSV as the source for the imported items. The SMP will first remove all the existing records with CSV as its source, then it will add the imported items.
Source column: you have decided to use this column for your own purposes. You can fill in the data you like in the source column before uploading the CSV file. The SMP will first empty the complete database and then import all the items from the CSV file.

After you have uploaded the CSV file, the SMP performs a validation of the data in your file. If everything was correct, you will get a screen that shows your data:

In the example above, the source column has been used for other purposes, so the SMP warns that this will overwrite the complete database.

If you have reviewed all your CSV data and you are ready to import the file, click the import button to proceed.

Special case for Users¶

The users are shared among the whole SMP. Also not only end users are managed there but also users with higher Access Levels on the SMP.

For technical and security reasons:

only users with User Access Level are exported and can be imported in bulk administration,
to edit users that also exist on other SOP’s/clusters you alse to have access to those SOP’s/clusters

NOTE: Languages specified in the CSV data must match the available languages (see “Language Configuration” menu), otherwise they are switched to default (empty value).

New column: ROLE

Special case for the Internal Directory¶

Profile parameters can be implemented using global parameters or parameter sets. This is a global settings.

If parameter sets are used (preview in SMP Application 5.3), profile parameters are exposed with their friendly name in bulk administration and the amount of profile parameters depend on the profile assigned to the Extensions. That’s why, as from SMP Application 5.3, the bulk administration for the internal directory can only be done per profile when parameter sets are enabled.

The bulk administration tool for the internal directory can also be used to provision and update parameters for which the reference value is on the SOP and not on the SMP. See “Day-to-Day Operations”, “Updating Profile parameters for dynamic profiles”.

New column: SYNC_TO_SOP

The CALLFLOW column was renamed to PROFILE in SMP Application 5.0

Special case for the resources¶

Resources that inherit parameters from master resources always inherit the version from the master resources and that’s what can be seen in the SMP Application web interface. However in bulk administration another version could be seen. You can ignore that. For parameters inherited from a master resources, you’ll see that Templating Language code: <%= t =%>

Digits in resource VERSION are not mandatory anymore when a template is applied and if mentioned it should match the template version.

New columns: INHERITANCE, INHERITS, EXTENSION, FUNCTIONS, LABELS

Using Flex Administration ¶

Flex administration is available for the directory since SMP Application 5.5 when parameter sets are used. It is an alternative to bulk administration when you don’t want to work on the complete directory but rather act on specific extensions.

It is still a good practice to lock the configuration when using flex administration although multiple administrator could organize themselves to work on different parts of the directory, to avoid stepping on each other changes.

Downloading a template CSV file¶

At the bottom of the flex administration page, a table gives a preview of the columns that will be included in the downloaded file.

Uploading the downloaded template CSV file without modifying it would result in no changes being made. This template file can therefore be used as a safe base to make modifications.

Special case for the directory¶

You can download a template file containing an extract of the directory.

Not selecting a profile will result in a CSV file containing only the main directory fields and no profile parameter columns.
Selecting a profile will only include extensions using that profile in the resulting CSV file and there will be one column for each profile parameter (prefixed with P_).

Additional fields can be available for customizing the downloaded file, depending on the template used. They are stored in the global parameter FLEXADMIN_DIRECTORY_FILTER.

FlexAdmin CSV file format¶

OPERATION column value	Description of the action applied
(empty)	automatic add or update: entry will be added if non-existent or updated if it already exists
A	add: entry will be added, line will skipped as error if it already exists
U	update: entry will be updated, line will skipped as error if it doesn’t exists
D	delete: entry will be deleted, line will skipped as error if it doesn’t exists

.

Special case for the directory¶

As highlighted in the preview table at the bottom of the flex administration, only 3 columns are mandatory:

OPERATION
EXTENSION
CONTEXT

Other columns can be included or not, at will, in any order.

The OPERATION column specify what will happen the directory entry identified in a unique way by EXTENSION and CONTEXT.

P_ columns¶

These columns are specific to a profile, since they correspond to profile parameters. When they are included in a CSV file, care should be taken that all lines use a profile that contains these profile parameters. Otherwise, some lines will be marked as error and skipped if the profile parameter cannot be found.

Of course, this is only relevant for Add and Update OPERATION, these columns will be ignored by the Delete OPERATION.

NEWP columns and Add OPERATION¶

In the case of the Add OPERATION only, it is possible to prefix some P_ columns corresponding to profile parameters with NEW_. This will allow automatic creation of resource based on a master resource.

For a detailed explanation: Format of the NEW P columns content

However, these columns will be ignored by Update and Delete.

Special case for the Users¶

As highlighted in the preview table at the bottom of the flex administration, only 4 columns are mandatory:

OPERATION
LOGIN
EMAIL
PASSWORD

The password can be left blank in case of *update*. If filled, the new value will replace the password, if left empty, the password will be kept. Other columns can be included or not, at will, in any order.

The OPERATION column specify what will happen the user entry identified in a unique way by LOGIN, EMAIL and PASSWORD.

Upload results¶

Once you have a file ready, you can upload it through the flex administration page. Minimal verification will be done regarding the format and it will then be processed line by line.

At the end of the process, a results table will be displayed. Red lines in the table indicate an error, while white lines confirm the OPERATION was applied to an entry.

If some lines were skipped because of an error, you can resubmit the same file including only those lines and modifying them until the error is solved.

A good practice is to make a snapshot of the configuration of the sopkey before uploading your file, for an easy rollback if needed.

Example¶

Directory containing extension 500 to 550. Uploading the following file:

OPERATION	EXTENSION	CONTEXT	SOP1	FIRSTNAME	LASTNAME	P_ForwardToMobile
A	549	internal	00000679	NewUser	NewName	yes
A	551	internal	00000679	NewUser	NewName	yes
U	501	internal	00000679	UpdatedName	OldName	no
D	521	internal

Will lead to:

Line	Result
1	Error: extension 549@internal already exists
2	Added new extension 551@internal with Firstname=NewUser, LastName=NewName and Profile Parameter ForwardToMobile=yes
3	Updated existing extension 501@internal with Firstname=UpdatedName, LastName=NewName and Profile Parameter ForwardToMobile=no
4	Deleted extension 521@internal

Applying (Public) template Upgrade & Update Source¶

ALERT Ask Escaux if your template is compatible with upgrade management

SMP > Advanced > Apply Template Upgrade

When arriving on this page, a list of public templates is displayed. You are allowed to choose one. Make sure that this template is compatible with template management. If you press continue:

Directory entries that do not have the template flag are exported
Resources entries that do not have the template flag are exported
Modules that do not have the template flag are exported
Permissions are exported.
...
The template is imported, scratching the old database.
Directory entries are imported.
Resources are imported.
Modules are imported, if an imported module is now present in the template it will not be imported.
Permissions are imported.
...

The service creator should mark the modules for installation when updating the template. Manual action is still required to press on the install module button.

In case of error it is advised to rollback by restoring the previous configuration snapshot.

Update Source

Components in the current configuration could be part of the template but not marked so (source=Template) because the previous version of the SMP Application didn’t support it.

It would cause either the Apply template upgrade to fail or the upgrade process to keep those data where it should not.

Advanced > Update Source of template Items

This tool allows to change the source field to template for the SMP components below if those are part of the current template.

Basic reports
Global parameters
Profile
Route Groups & Restriction Groups
Translation Catalog

The tool will first ask what is the current version of the public template in order to compare what is in the configuration and what is in the template that was loaded initially. Components that are also in the template will be marked as source=Template in the current configuration.

Editing SOP/Cluster Notes (smpadmin)¶

Advanced > Edit Notes

Here notes can be added regarding the provisioning like special configuration or information about the Project. Notes are then visible on the home page showing the SOP/cluster network.

These notes can only be viewed and edited by smpadmin or higher SMP Application Access Levels. Basic text and hyperlinks are supported.

Enabling Automated Installation¶

“Automated Installation” is a flag can be set on a physical SOP key that:

allows the SMP to automatically accept the SOP public key during the Baseline installation.
Once the connection to the SMP is established an Install modules will be triggered followed by an “Apply Changes”.
After that the Unattended installation mode will be disabled.

Note that if a previous public key was already accepted, it will be cleared and the new one will be accepted.

Advanced > Cluster/Server Configuration > Automated Installation

Establishing the SMP-SOP Connectivity¶

ALERT Requires online SOP

The SOP maintains a secure connection to the SMP. The SMP needs to know that the SOP that is connecting to the SMP is really the one it claims to be. To do that the SMP needs to know the public key of the SOP. While the SOP installation process automatically sends the public key to the SMP, it is finally up to the administrator, to say that the key can be .

If the SOP has sent its key to the SMP, the key can be seen in the text box. If you trust the key, you can use the Accept Key button to install the key on the SSH routers and allow the SOP to establish the connection with the SMP.

The key cannot be altered by hand, it can only be published from the SOP:

during the installation of the SOP
by using the SOP Shell Configuration > Key management > Regenerate authentication keys

If a key is already on the SMP, a new one cannot be published. The following message would be shown on the SOP when attempting to publish a new key:

Not authorized to register key on SMP

In that case, use the Clear Key button to remove the key from the SMP.

Installing Modules¶

ALERT Requires online SOP

After installing the SOP Baseline through the USB key and enabling the SMP-SOP connectivity, the remaining software is to be installed using the SMP Application.

Each physical SOP key has its own module list and configuration, except Active/Standby pairs that always share the same configuration. modules and their configuration can be part of an Escaux service template. In that case making changes to the included modules can be restricted. Sometimes other modules need to be added during provisioning or a custom solution needs to be set-up. See “Configuring modules” therefore.

Modules are installed using the “Install Modules” feature. In order to install all the modules to a SOP for the first time:

Advanced > Module Configuration

On the top of the page, choose to “Schedule” all modules for installation or “Uncheck” all modules for installation. Click on the “Install Modules” button to trigger the installation of all the modules.

After that, when changing modules configuration, the module has to be re-installed (See “Configuring modules”).

Preparing Advanced Reporting¶

For each SOP the time zone parameter in “Advanced” » “Server Configuration” on the SMP should be set to the local time zone of the SOP

The SOP’s keep a record of every phone call in a so called CDR (Call Data Record). SOP’s also store State Transition Record that includes status changes for users, queues, PUM,... All of that is stored locally on the SOP’s. In order to export it to the SMP a special system task SyncCDRDB should be configured. This should be done for all SOP’s that contain relevant CDR’s that will be processed in advanced reporting.

When a FAX Server is installed on a SOP records from fax received or sent will be available on the SOP. Configure the SyncFDR task to export those to the SMP.

See the Advanced Reporting Administrator Guide for more details.

Using Provisioning Task Resources¶

A bunch of system tasks are available to ease the provisioning of the system, perform migrations and perform checks on the system.

Examples: ZeroConf, SyncLDAP, TaskRunner, ListPackages

See the Tasks Reference Guide for the whole list.

Scheduling tasks ¶

Tasks (like reports) can be scheduled at regular intervals, e.g. every month.

To schedule a task:

Go to the configuration screen of the task you want to schedule
Set “Run automatically” to e.g. “Every 1st of the month”
Press “Save”

For more information see Common task parameters reference guide

Scheduled tasks that are currently running can be seen in “Advanced” » “Tasks and Report Status”

Preparing Backup & Monitoring¶

Once SOP’s are in production, it’s important not to forget to enable backup and monitoring by the SMP.

On the cluster SOP key, configure “”Monitor” and “In Service” on “Yes”.
On the individual SOP’s, configure “Backup”, “Monitor” and “In Service” on “Yes”.

See the Cluster and Server Configuration Reference Guide for more information.

Day-To-Day Provisioning¶

Provisioning tasks on SMP that are very frequent and with low impact.

Managing the Internal Directory & Profile Parameters¶

The internal directory is used to define user’s extensions, service numbers and extensions for directory-centric configuration.

Directory > Internal Directory

There you can assign extensions to profiles, edit First Name, Last Name, Department,... fields that are applicable for all extensions. A primary and secondary phone to be used in callflows can be assigned as well.

Other parameters can be configured depending on the profile that is linked with the extension. Those are called profile Parameters. Click on the edit button left in the profile column, left to the profile names.

See the Internal Directory Reference Guide for more details.

Adding, editing or moving an extension requires an Apply (Cluster) Changes. This can be quite heavy. The “Apply Extension Change” button next to the delete button. makes use of a more efficient solution. To implement it, follow the Administrator Guide: Extension Move-Add-Change v.2. After that, new extensions, extensions changes and extensions moving to other SOP’s can be applied by using the “Apply Extension Change” button as long as the extensions and phones are on the same SOP.

Assigning Incoming / Outgoing Numbers¶

One way to configure external numbers for incoming or outgoing calls is to use the “Incoming Number Mapping” and “Outgoing Number Mapping” tools.

Communication Routing > Incoming Number Mapping

Mapping incoming calls comes down to routing the incoming DDI numbers that you received from your phone operator to internal extensions. This can be done using an action, as shown in the list of the incoming number mapping:

Mapping these numbers onto an internal extension, you can trigger a phone or a root extension (call flow) for automatic answering of calls. The following screenshot shows the detailed view when modifying or adding a mapping:

The external numbers to be shown when dialing out can be assigned using the Outgoing Number Mapping tool.

Communication Routing > Outgoing Number Mapping

See the Outgoing Number Mapping Reference Guide for more information.

Managing End User & SMP User¶

The “Users” page allows to define end-users for Escaux applications with different roles depending on the service template. It is also the place where privileged accounts are created for people who access the SMP, with different access levels.

Different SMP users can have different levels of access. A higher access level has all the rights of a lower level.

See the Users Reference Guide for more information.

Managing Permissions¶

Resources > Permissions

This is where user permissions for desktop applications and advanced reports are defined. The SMP Application shows a list of all the permissions currently defined.

Uploading Audio prompts¶

ALERT In service templates like Escaux Fusion, audio prompts can be managed differently. See the Service Template Admin Guide.

Resources > Audio Prompts > Global Parameters

The audio prompts can be managed as global variables. In that case, select the menu item mentioned above, which is equivalent to:

Communication Flow Studio > Global Parameters > Audio Prompts

Associated files can also be managed using the File Manager:

Resources > Audio Prompts > File Manager

An informational message will be displayed about access to the SOP:

When uploading your own audio prompts (for example recorded by a professional studio) please respect the following :

Format : .ul with the option CCITT u-Law format, 8kHz.
Files should not have any header (for example .wav header)

Managing Music On Hold¶

Resources > Music on hold

This is where music on hold are defined. The SMP Application shows a list of all the music on hold tunes defined in the system.

See How To Configure Music On Hold for more details.

Applying Changes¶

In case of cluster architecture, the SMP Application offers you two options to push the changes to the SOP’s. When at a physical SOP key level, the menu will show “Apply SOP Changes”. When doing configuration at the cluster level, the menu will show “Apply Cluster Changes”.

Apply Changes > Apply SOP/Cluster Changes

The Apply SOP Changes will only apply the new configuration relevant to the current SOP key.

When you select “Apply Cluster Changes”, the SMP will push the changes to all the SOP’s in the cluster. Because this may take a long time in large setups, the SMP will first display a warning.

After confirmation, the SMP will start a backup of the current configuration. After the backup is complete, the configuration is pushed towards each of the SOP’s. Several SOP’s will be updated simultaneously. You can follow the progress on the screen:

In case the process is stuck, click on the green arrows. The processes launched by “Apply Changes” will be restarted. Note that this should be used exceptionally, in a normal day-to-day situation this is not required.

As from SMP Application 5.0.0 a new button is available in the Apply Changes Menu: “Apply Changes Without Cache”. It will clear the cache and start an “Apply Changes”. Use it only if there is a caching issue or if a SOP is replaced. Flushing the cache can lead to a significantly longer “Apply Changes” process.

In case the “Apply Changes” was started by accident it is usually best to just let it run. However, you have the possibility to abort the process by clicking on the red cross.

The “Apply Changes” process is a background task, so it’s possible to continue browsing the configuration by using the menu. In order to go back to the progress display:

Apply Changes > Progress

After the “Apply Changes” process has finished, an overview of the the errors and warnings for each SOP will be displayed. The options on the right can be used to analyze what happened:

Doing Snapshots¶

Before every “Apply Changes” a backup of the configuration is made on the SMP. Several backups are kept and can be restored. A snapshot contains all the configuration for the current SOP key except users and deployment architectures cluster and clone definition.

Last 15 automated snapshots are kept.

Snapshot can also be created manually:

Advanced > Create Configuration Snapshot

The snapshot will start immediately.

After the snapshot is finished, you get a result screen:

To restore a snapshot:

Advanced > Restore Configuration Snapshot

The snapshot that should be restored can be selected. The SMP Application guides the user through the steps to restore the configuration to the older version.

Day-to-Day Operations¶

This section describes local changes usually made directly on the SOP and without global impact

Changing Extension’s Status and dynamic profile’s parameters¶

An extension (user or service extension) can have different intentional status, for example Office, Forward, Holiday. Every status is linked with a different callflow (a way to handle the call). The status can be changed using net.Desktop or a specific callflow but also on the SMP.

Since SMP Application 5.3, changing the status on the SMP uses the SOP API (if installed). That way the callback service extension configured in the API module will be triggered.

Directory > Internal Directory

Here we have an overview of all the extensions. Navigate to the “Profile” column (previously named “Callflow”). There is a change icon and a text (the name of the profile, e.g. User). Both the text and the icon are clickable but the action is different.

If you want to change the status of an extension click on the text (e.g. User). A new page will open. All the different statuses for the selected profile will be shown. Choose the new status and click the submit button.

Clicking on the change icon in the “Profile” column we can change the profile parameters for that extension. For example the forward number for a “Forward” status.

Service Creation¶

The SMP Application is also a Service Creation Environment. Any Escaux solution is built and managed using the SMP Application. This is done by assembling Escaux components.

Modules contain Escaux software to be installed on SOP’s.
Most resources allow to provision and configure things on SOP’s for the Escaux solution like IP phones, Interfaces, call queues, desktop applications,...
Actions are used to configure telephony flows (e.g. user or IVR callflow) and application processes (e.g. Instant Messaging). Actions are assembled in callflows using logical connectors in the Escaux Callflow Editor tool. Callflows are assigned profiles by the service creator and those can in turn be assigned extensions to configure a solution.
SMP Application components: routes, profiles, roles, profile parameters,...

Depending on the context, resources and actions are part of a standard service or can be seen as configuration.

Escaux solutions are often packaged in service templates. Those include modules, callflows, template resources and other SMP components. Customers can also create their own solution, packaged in a service template or not. Service templates can have versioning and release notes like other Escaux components (new SMP 5.3)

The advantages of service templates are:

the same standard service can be easily replicated
every deployed solution behave the same way and can be validated by Escaux as a Product
when the configuration and the service are split of, the solution can be easily upgraded using the SMP without losing the configuration (new SMP 5.3)

A drawback is that the standard service needs to be protected (i.e. non editable) to keep the previous advantages. Modifications can be made as long as it does not affect the service template. This is enforced in SMP 5.3.

Translating¶

Communication Flow Studio > Translation Catalog

The translation catalog allows to show status names and profile parameter names in the language of the end-user.

The catalog is consulted by net.Desktop, Escaux Connect and some types of phones.

For example, if you have a status called ‘Office’. You could make translations as follows:

Original Text	Language	Translated Text
Office	NL	Kantoor
Office	FR	Bureau

A user having his language set to “NL” will see “Kantoor” instead of “Office”. A user having a language for which there is no translation will see the original “Office”.

The same catalog is used for translating names of profile parameters.

Reporting¶

To get an overview of the usage of an Escaux telephony solution, the SMP offers two types of reporting: basic and advanced CDR reporting. Aside from these two, the solution also offers reporting on presence and on queue usage for call centres and receptions.

Basic CDR reporting can be used to get a quick overview of certain types of calls. For example, it is possible to select all calls to mobile numbers and get an overview of total cost of those calls per extension. Advanced CDR reporting is similar but offers more flexibility than the standard reporting. First of all, reports can be scheduled to run automatically and to be sent by e-mail. Second, advanced reporting is consolidated: reports on multiple SOP’s can be generated as easily as for one SOP or one user. Even when the appliances are located on different sites of the company, the consolidation will still gather all the information and make up a single report. This means monthly or quarterly reports for management can be fully automated for all the sites of the company.

An administrator can generate two forms of presence reports: State Transition Record (STR) and State Duration Record (SDR) reports. Every time a user’s status changes, the solution logs an STR. STR’s therefore give an overview of who changed his status when (including automatic status changes, for example, by the Exchange calendar integration). SDR’s act as an accumulator of STR’s: they indicate the amount of time every user stayed in a certain status before changing to another status. An SDR report is therefore useful to get an overview of how the solution is used.

To report on the performance of a call center or a reception setup, Escaux offers advanced reporting on the usage of queues. Reports can be summarized by queue, agent, call result, time or date, caller and called numbers.

Basic Reporting¶

Reporting > Basic Reports

The SOP keeps the details of all internal and external calls in an internal database. These details can be consulted online. In order to assist the user with the analysis of this large amount of data the SMP allows to define reports. The basic reporting tool allows to define and save several reports. When requesting a large amount of data the basic reporting could give a timeout error, this is to avoid overhead on the sop. To make such a large request work you need to use advanced reporting.

When clicking on the report name, you can consult the report.
When clicking on the ‘Change’ button next to a report name, you can define the report details as shown below:

When using basic reporting, all processing is done on the SOP and may have a degrading effect on the voice quality.

Depending on locale settings for the spreadsheet program that will be used to import data the user can choose between 2 format:

dot as decimal mark: The decimals are indicated by a dot.
comma as decimal mark: The decimals are indicated by a comma.

Advanced reports¶

Overview¶

Reporting > Advanced Reports

Besides CDR’s (Call Data Records), advanced reporting allows to report on STR’s (State Transition Records) and SDR’s (State Duration Records). These new data records store how various attributes change over time. For instance if a user changes his status from Office to Absent, this state change is recorded in an STR. It is often interesting to know how long a certain state was retained, e.g. how long a user has been in status Office. Therefore, based on the STR’s, SDR’s are calculated.

In contrast to basic reporting, the reports are calculated on the SMP, offloading the processing from the SOP. For this to work, the data must first be copied using the SyncCDRDB Task. During this process, the SDR’s are calculated and certain data is added to the raw CDR’s, including the estimated price.

In order for a correct price estimate to be calculated, both the Price List and the timeslots must be correctly defined. (See below)

If the ‘Enrich CDR’s with queue data’ option is be enabled in the SyncCDRDB task, additional information is stored in the CDR’s and one more type of records is generated: QDR’s, i.e. every passage of a call through a queue.

If the ‘Replace extension or device information by first name and last name, when possible’ option is be enabled in the SyncCDRDB task, additional information is stored in the CDR’s. This allows to show the first name and the last name of a device’s owner, not just the device id (SDPxxxx) in the reports.

Various other reports exists, e.g. for faxes. Refer to the Resource Report Reference Guide for the full list of reports and how to use them.

Another advantage of advanced reporting is that it can be used by regular users (non-administrators) (See Managing Permissions).

Scheduling reports ¶

Reports (like tasks) can be automatically generated at regular intervals, e.g. every month.

To schedule a report:

Go to the configuration screen of the report you want to schedule
Set “Run automatically” to e.g. “Every 1st of the month”
Press “Save”

For more information see Common report parameters reference guide

Scheduled reports that are currently being generated can be seen in “Advanced” » “Tasks and Report Status”

Time slots¶

Reporting > Timeslot Definition

The price of a call is often dependent of the time of day, whether it is in a weekend or not, and other conditions. A timeslot is typically something like “PEAK” or “OFFPEAK”. For each such timeslot a different pricing can be used.

To determine which timeslot to use for rating a certain call, the rules are evaluated in order of their rule number. The first rule for which the time specification matches the call’s date and time is used. The timeslot name of that rule will be used to look up the price in the price list.

The time specification is expressed by 5 components separated by white-space: (crontab format)

minute: 0-59
hour: 0-23
day of month: 1-31
month: 1-12
day of week: 1-7 (7=Sunday)

Each component can be a comma-separated list like ‘1,2,3’, a range like ‘1-3’ or ‘*’ to match anything.

Examples:

‘* * * * 6,7’: weekend
‘* 18-23 * * *’: evening from 6PM
‘* * 25 12 *’: Christmas
‘* * * * *’: matches everything

Price lists¶

Reporting > Price List

The price list associates a price with each access code and timeslot combination. The rating engine will use this information in order to calculate the price for each CDR (call data record). Separate prices can be used for call set-up and for per-minute pricing.

As an example, the SMP is populated with access codes for Belgium. It is the responsibility of the administrator to adapt the prices in function of the price given by his providers.

Licensing¶

The SMP Application shows a “Licenses” menu. The content depends on the licensing model applicable: “Unification Point” licensing model or “Resource” licensing model.

See below the menu items for the Unification Point licensing model.

Menu item	Minimal Access Level	Non-clustered SOP	Cluster level
View Licenses	poweroperator	✔	✔
Manage Licenses	smpadmin	✔	✔
Contracts	poweroperator	✔	✔
UP Account	admin	✔	✔
SMP UP Account	smpadmin	✔	✔

In the “Resource” licensing model only the first menu item will appear: “View Licenses”.

Unification Point licensing model¶

Overview¶

In the “Unification Point” licensing model, all extensions, resources and modules must be covered by an appropriate license.

The administrator can create and modify extensions, resources and modules freely as long as everything is covered by a license. This is checked when doing an apply changes.

The reseller can add and remove licenses as long as the total ‘cost’ of the licenses is within the contract. The cost is expressed in Yearly Required UP’s (YRU).

The reseller can create contracts, thereby consuming UP’s from its UP account.

The reseller can consult the balance and transaction of his UP account.

The following sections discuss these menu items one by one.

View Licenses¶

Licenses > View Licenses

Licenses allow you to use certain types of objects in you configuration. There are four types of licenses:

Resource licenses allow you to use resources like interfaces, net.Desktop, etc.
Profile licenses allow you to create extensions having a profile with a certain level of complexity (basic, advanced,...)
Module licenses allow you to install certain modules.
Custom licenses cover functionalities not based on components in configuration

This screen shows all possible licenses that exist and for each, some counters:

Configuration requirement: the total amount of licenses you need as a minimum based on your configuration (note: configuration requirement is greater than used licenses if you don’t have enough licenses)
Total licenses: the amount of total licenses (= provisioned licenses + free licenses)
Free licenses: the amount of free licenses
Provisioned licenses: the amount of licenses you have purchased
Used licenses: the amount of licenses you are currently using based on your configuration (note: you cannot use more licenses than you have purchased)
Available licenses: the amount of licenses not used (= total licenses - used licenses)

Note that licenses can be valid for different kinds of objects, e.g. a license for net.Desktop X300 is also valid for net.Desktop X500 and vice versa. Furthermore, unused licenses can also cover lower level licenses when these are missing for the current configuration.

Manage Licenses (reseller)¶

Licenses > Manage Licenses

If you have sufficient rights, you can use this screen to change the mix of licenses as long as you stay within the contractual YRU (yearly required unification points)

For every license, following information is shown:

the suggested number of licenses you need based on your configuration (configuration requirement)
the total number of licenses (= provisioned licenses + free licenses)
the number of free licenses
a text-box to change the provisioned licenses
the total YRU (= number of provisioned licenses * YRU per license)
YRU after discount (= Provisioned Licenses * YRU per license * (Threshold + (1 - Threshold) * Discount Factor^(MAX(Provisioned Licenses/Step-1;0))) )
YRU per license, free licenses, Threshold, Discount Factor and Step are determined by the pricelist.

Non-satisfied configuration requirements are highlighted in red. For certain licenses a discount might be offered depending on your pricelist. The YRU after discount column will indicate the number of YRU needed to support your current configuration.

At the bottom of the screen, the YRU after discount for all licenses is shown and compared to the contractual YRU. This value should not exceed the contractual.

The “Add missing licenses” button will only add missing licenses in the provisioned column in order to match configuration requirement. The “Match configuration” button will adapt ALL provisioned licenses in order to match configuration requirement. For these two actions, no changes take place until you press Save.

Contracts¶

Licenses > Contracts

A contract specifies a number of UP’s to be consumed every year in exchange for the right to use licenses up to that amount of YRU (yearly required unification points)

Given sufficient rights, you can create new contracts or in some cases alter existing contracts.

Initially a contract is in the NEW state. At this state you can still alter and confirm the contract.

Once a contract is CONFIRMED, the YRU can be used for licenses. The charging schedule cannot be changed anymore but the YRU can be adjusted to match the configuration requirement. The contract can also be canceled with the cease action.

After an activation delay defined in the charging schedule is elapsed, the contract goes to ACTIVE state. At this point, UP’s will be consumed and changes can no longer be made.

When ceasing an active contract, it first goes to the CEASING state. This means that a cease is been requested but the contract duration has not yet elapsed.

Once the contract duration is expired, it will not be renewed and it goes to CEASED state. The effective cease request date depends on conditions defined in the charging schedule.

The list view shows all contracts for the current SOP or cluster.

The edit screen reveals following fields:

Reference: free text field intended to store a contract number
Description: free text field intended to store a human readable description
Initial Duration: the minimum contract duration
Price List: cannot be changed
Charging Schedule: how payments are scheduled in time
YRU: the contract value expressed in Unification Points per year
Suggested YRU: the minimum YRU required for the licenses specified in the “Manage Licenses” screen, taking into account other contracts
Info 1, Info 2 and Info 3: free fields to give extra information about the contract
State: the state of the contract (see also above):
- NEW: all fields can be changed, YRU is not taken into account
- CONFIRMED: The charging schedule is fixed, YRU is taken into account
- ACTIVE: contract is frozen, billing started, YRU is taken into account
- CEASING: contract is frozen, YRU is taken into account, contract will ceased at next cease opportunity
- CEASED: contract is frozen, YRU is not taken into account

UP Transactions Report (reseller)¶

Your UP account is like a bank account and this report shows the transactions on that account. In the past and also a prediction for the future based on the current contracts.

Following types of transactions can occur:

consumption: this is by far the most common transaction: UPs are consumed by a contract
purchase: you have purchased UPs from Escaux.
expiration: UPs you have purchased earlier remained unused for longer than contractually agreed and will (or have) expired.

The report has following columns:

date: can be in the past or future (=forecast)
customer: the account code and the network name of the customer
contract ref.: the reference of the contract consuming UPs
contract info 1, contract info 2 and contract info 3: extra informations related to the contract
transaction desc.: UP transaction or contract charging description
expense type: as defined in the payment schedule of the contract consuming UPs
sales model: as defined in the payment schedule of the contract consuming UPs
transaction: the amount of UPs debited or credited from the account
new balance: the balance of the account after this transaction
bucket ref.: the oldest UPs are consumed first, this is the reference of the purchase from which the UPs are consumed
euro: the consumed UPs expressed in euros based on the purchase price

Resource Licensing Model¶

Overview¶

In the “Resource” licensing model only resources mentioned in the “License” view must be covered by an appropriate license. All other resources can be used without license.

Some extensions and modules are optional extras but aren’t mentioned in the “License” view. Like Fax Server, G729,...

View Licenses¶

Licenses > View Licenses

You can also consult the license list by using the “view licenses” link from the respective resource list page:

Licenses allow you to use certain types of objects in your configuration.

According to your commercial contract you have rights to use some of resources of each type. For instance if you have purchased 10 phone licenses, you can create up to 10 phone resources.

The type of license is identified by the first characters of the resource name.

For instance a phone resource SDP40001 will consume a phone license because a phone license is defined as anything that has a name starting with SD (SIP Device), ZD (Zaptel Device), ID (IAX Device), LD (Local Device) or SV (SIP Virtual).

See below the name of the licenses :

License name	Codes
net.Phone	SD/ZD/ID/LD/SV
Queue	AQA
Advanced Reporting	RWC/RWQ/RWD/RWS/RWA
net.Supervisor	WCE0
net.Desktop X100	WCE1
net.Desktop X300	WCE3
net.Desktop X350	WCE4
net.Desktop X500	WCE5
net.Console X700	WCE7
net.Console X900	WCE9

This screen shows some licenses that exist and for each, a number of counters:

Used: the number of these licenses you are currently using based on your configuration
Limit: the number of these licenses you have purchased
Left: the number of licenses available (= used - limit)

Appendix¶

Top bar reference guide¶

Here is what the top bar of the SMP looks like since SMP Application 5.3:

Logs you out of the SMP interface and ends your SMP session

Password change. You will be prompted to input your old password, your new password and then your new password again as confirmation

Help. Opens another browser window with the customer documentation portal .

Network. Takes you to the network overview of the solution where you can quickly view all of your SOP’s and choose between any of them, their clones and the cluster level.

Cluster. Switches you to the cluster level. This level allows you to configure parts that are shared between all the SOP of the cluster, like: user management, profiles, statuses, callflows, call queues, advanced reporting...

Go to active SOP. Switches from the clone SOP to the active SOP (active/standby)

Version and user info. Show the current version of the SMP Application and user currently logged in.

SOP Selection Bar. Allows to navigate in the the SOP keys by typing either a SOP key or SOP name. Type 00 to see the whole list of SOP keys.

Other administrators are logged in on the selected SOP key. Mouse over the icon to see the usernames. Make sure you discuss with the other administrator before applying any changes. If both you and the other administrator want to modify the configuration at the same time, an apply change may include changes by the other administrator that you did not anticipate or vice versa

Connected. Shows whether you have a connection to the SOP from the SMP.

Disconnected. Shows whether you have a connection to the SOP from the SMP.

“In Service” means that the SOP is supposed to be operational, that SLA’s apply, monitoring and backup may be activated, etc. This status can be set by a poweradmin in the server configuration.

“Not In Service” means that the SOP is still in delivery phase, temporary under maintenance etc. This status can be set by a poweradmin in the server configuration.

Means the configuration was locked to avoid concurrent changes. The lock can be removed using the same menu item used for locking the configuration: “Advanced” » “Lock Configuration”

Menus depending on context ¶

Managing a SOP or Cluster¶

Menu	Standalone	Cluster level	Clustered SOP	Clone SOP
Apply Changes	✔	✔	✔
˫ Apply Changes	✔
˫ Apply Changes Without Cache	✔
˫ Apply SOP Changes			✔
˫ Apply SOP Changes Without Cache			✔
˫ Apply Cluster Changes		✔
˫ Apply Cluster Changes Without Cache		✔
˫ Check Configuration	✔	✔	✔
˫ View Progress	✔	✔	✔
Directory	✔	✔	✔
˫ Users	✔	✔
˫ Internal Directory	✔	✔	✔
Communication Flow Studio	✔	✔
˫ Profiles	✔	✔
˫ Statuses	✔	✔
˫ Callflows	✔	✔
˫ Callflow Assignment	✔	✔
˫ Parameter Sets	✔	✔
˫ Roles	✔	✔
˫ Callflows - Technical View	✔	✔
˫ Global Parameters	✔	✔
˫ Translation Catalog	✔	✔
Communication Routing	✔	✔	✔
˫ Routes	✔
˫ Extra-Cluster Routing			✔
˫ Intra-Cluster Routing		✔
˫ Route Groups & Restriction Groups	✔	✔
˫ Restriction Group Configuration	✔	✔
˫ Inter-Site Media Links	✔	✔
˫ Incoming Number Mapping	✔	✔
˫ Outgoing Number Mapping	✔	✔
Resources	✔	✔	✔
˫ IP Phones	✔	✔	✔
˫ Interfaces	✔	✔	✔
˫ Virtual Links	✔	✔
˫ Networks	✔	✔
˫ Queues	✔	✔
˪ Audio Prompts	✔	✔	✔
˫ Global Parameters	✔	✔
˫ File Manager	✔		✔
˪ Music On Hold	✔	✔	✔
˫ Resource Manager	✔	✔
˫ File Manager	✔		✔
˫ Probes	✔	✔	✔
˫ vSOPs	✔	✔	✔
˫ SMP instances	✔	✔	✔
˫ Services	✔	✔	✔
˫ Sopreps	✔	✔	✔
˫ Desktop Applications	✔	✔	✔
˫ Permissions	✔	✔
Reporting	✔	✔	✔
˫ Basic Reports	✔		✔
˫ Advanced Reports	✔	✔
˫ Time Slots	✔	✔
˫ Price List	✔	✔
Advanced	✔	✔	✔	✔
˫ Cluster Configuration		✔
˫ Server Configuration	✔		✔	✔
˫ Modules Configuration	✔		✔
˫ Modules Configuration		✔
˫ Site Configuration	✔	✔
˫ Network Configuration	✔	✔
˫ Language Configuration	✔	✔
˫ Action Management	✔	✔
˫ Phone Status	✔		✔
˫ Task and Report Status	✔	✔	✔
˫ Create Configuration Snapshot	✔	✔
˫ Restore Configuration Snapshot	✔	✔
˫ Manage Public Templates	✔	✔	✔
˫ Load Public Template	✔	✔	✔
˫ Apply Public Template Upgrade	✔	✔	✔
˫ Update Source of Template Items	✔	✔	✔
˫ Manage Templates	✔	✔	✔
˫ Load Template	✔	✔	✔
˫ Apply Template Upgrade	✔	✔	✔
˫ Update Source of Template Items	✔	✔	✔
˫ Lock Configuration	✔	✔	✔
˫ Edit Notes	✔	✔	✔
˫ System Tasks	✔	✔	✔
˫ Extra Modules	✔		✔
˪ Extra Resources	✔	✔

.

End User view¶

Menu	User view
My Extensions	✔
My Phones	✔
My Reports	✔
Desktop Applications	✔

.

SMP and Account level SOP Keys¶

Menu	SMP/Account view
Users	✔
Reports	✔

.

Users reference guide¶

Login name: The username to be used for authentication
Password: Define a new password or left empty to keep the existing one
Real name: First name and last name
E-mail: A valid e-mail address, used for password reset
User attribute 1 to 10: Free fields
Language: User language (only used in end-user applications)
Level. The following levels exist:
- user: an end user, can only access his own records.
- readonly: Can view but not change all day-to-day administration data (internal directory, phones etc.)
- superuser (new SMP Application 5.2): Same rights than readonly but can also edit all the extensions whose owner or admin has an equal or lower level of privileges.
- operator: for simple day-to-day administration, can manage attribution of phones and monitor the system.
- poweroperator: for more advanced day-to-day administration, can manage resources, in addition to what an operator can.
- admin: for service creation, can manage callflows and routing but cannot install modules, in addition to what a poweroperator can.
- poweradmin: has a complete access on the SOP’s he owns.
- reseller (new SMP Application 5.3): can manage contracts and up licenses in addition to what a poweradmin can
- smpadmin: has a complete access on all SOP’s of the SMP (As from SMP App 5.4 can only be created and managed on a scope SMP SOP key)
Role: (preview since SMP App 5.3) the role of a user can be change in the list view (and not when adding or editing a user), by clicking on the role of the user.
Allowed from IP(s): Limit SMP authentication from those IP adresses
Receive alarms: User will receive monitoring alerts by e-mail (configurable by smpadmin only)
Source: the database that contains this user’s contact information. This field is filled in automatically when synchronizing with an external database.

Adding a user with a username that already exists on another SOP key will not create a new user but add a relation to the same one.

Deleting a user will only remove the relation to the current SOP key in case the user exists on other ones. It will effectively delete the user if it does not exists anymore on another SOP key (new in SMP App 5.4: also for smpadmin users)

The reset password link allows to generate a random password of 8 characters. It will show it on the web interface so that it can be communicated to the user.

After 20 attempts the user is blocked. The amount of authentication failures is shown in the unlock password column. Click on the counter to reset the counter or ‘locked’ to unlocked the user.

Required access level for each functions¶

Function	Required Level
Apply Changes	operator
Users (view only)	readonly
Users	operator
Internal Directory (view only)	readonly
Internal Directory (change extension status)	superuser
Internal Directory	operator
Profiles	admin
Statuses	admin
Callflows	admin
Parameter Sets	admin
Roles	admin
Global Parameters (view only)	admin
Global Parameters	admin
Translation Catalog	admin
Routes	admin
Media Links	admin
Incoming Number Mapping	readonly
Incoming Number Mapping	operator
Outgoing Number Mapping (view only)	readonly
Outgoing Number Mapping	operator
Phones (view only)	readonly
Phones	poweroperator
Interfaces (view only)	readonly
Interfaces	poweroperator
Queues (view only)	readonly
Queues	poweroperator
Prompts (view only)	readonly
Prompts	poweroperator
Music On Hold (view only)	readonly
Music On Hold	poweroperator
Probes (view only)	readonly
Probes	poweroperator
vSOPs (view only)	readonly
vSOPs	poweroperator
Desktop Applications (view only)	readonly
Desktop Applications	poweroperator
Permissions (view only)	readonly
Permissions	poweroperator
Basic Reporting (view only)	readonly
Basic Reporting	operator
Advanced Reporting (view only)	readonly
Advanced Reporting	operator
Timeslots (view only)	readonly
Timeslots	operator
Pricelist (view only)	readonly
Pricelist	operator
Server Configuration	poweradmin
Install Modules	poweradmin
Define Sites	admin
Define Networks	admin
Action Management	admin
Task and Report Status	admin
Configuration Snapshot	admin
Manage Template	poweradmin
Manage Public Template	smpadmin
Load Template	admin
Load Public Template	poweradmin
Lock Configuration	admin
System Tasks	admin
View Licenses	poweroperator
Manage Licenses	reseller
Contracts	poweroperator
Access on all SOPs	smpadmin

Internal Directory reference guide¶

Entries¶

SOP1: (shown only in case of cluster) SOP on which the extension will be located, primary SOP of the extension in case of Active-Active redundancy. Only use “(all)” for technical extensions having a static profile.
SOP2: (shown only in case of cluster) secondary SOP of the extension in case of Active-Active redundancy, leave to default (none) otherwise
Admin: this is the user managing this extension
Owner: this is the user controlling this extension
Extension: the internal number. Please avoid using an extension from the list ‘Predefined extensions’ below.
First Name: first name of the user using this extension (consisting of alphanumerics, parenthesis, dots, dashes, whitespace, underscores)
Last Name: last name of the user using this extension (consisting of alphanumerics, parenthesis, dots, dashes, whitespace, underscores)
E-mail: email address of the user associated to this extension. Voicemail messages will be sent as .wav attachments to this email address. If this email address is undefined, the voicemail-to-email forwarding will not function.
Mobile Number, Fax Number and Home Number: these numbers can be used throughout the different callflows
Department: Extra information (consisting of alphanumerics, parenthesis, dots, dashes, whitespace, underscores)
Office: Extra information (consisting of alphanumerics, parenthesis, dots, dashes, whitespace, underscores, slashes and plus)
Group: the group identifier allows you to place users in the same group. A group is useful for example:
- to make all the phones within the same group ring together
- when wanting to perform a call pickup within a group (group pickup)
Context: For **advanced* purposes only.* Use only the context ‘internal’.
Profile: Defines the service that should be called by the extension. Can support multiple variants depending on status and callflow behind.”
Admin pincode: For **advanced* purposes only.* Can be used for voicemail access authentication, DISA access authentication. Often replaced by a user pincode as profile parameter.
Primary and Secondary Phone: the directory allows to associate 2 devices (Soft phone, IP phone, IP/analog converter, ...) to a particular extension. More devices can be associated via the callflow definition. In order to be able to select a phone, the different phones have to be defined via the ‘IP Phones’ menu item in the ‘Resources’ menu (see later).
Source: the database that contains this user’s contact information. This field is filled in automatically when synchronizing with an external database.
Visibility: if set to “Hidden”, this user is not shown in the client applications.
Sync to SOP: For **advanced* purposes only.* Should always be set to ‘1’.

Regarding profile parameters, see the service template documentation.

Authorized characters

Login: Can contain alphanumeric and following special characters @ . _ - +
Owner and email: Can contains alphanumeric characters and following special characters _ - . +. Should be composed by two blocks separated by @
Extension: Can contain alphanumeric characters and following special characters . # + / ! & * _ - [ ] %
Firstname, lastname and Department, Office: Can contain alphanumeric characters, parenthesis, dots, dashes, whitespace, underscores, slashes and colons
Mobile, Fax and Home Number: refer to extension specification

Profile Administration reference guide¶

Profile name: choose a name for the profile
Override license:
- The profile license level is calculated based on the action used in the linked callflows. The profile license level is the highest action license level.
- The override license parameter allows to force (another) the license level. When this is used the callflow will be read-only.
Type:
- static: the status cannot be changed, extensions will have to be linked to a combination of profile + status.
- dynamic: the status can be changed on the sop, extensions can be linked to the profile name and the user (or administrator via SMP) can choose the status (a default status should be defined)
Default status: choose a default status (required for dynamic profiles)

Outgoing Number Mapping reference guide¶

5 actions can be selected for outgoing number mapping:

Existing: reuse the one that is currently configured.
Hide: don’t show any number when dialling out.
Incoming: use the same number as the one your contacts use to call you directly (DDI).
Default: use a default number, e.g. the main reception number.
Other: enter any other number. Of course, limitations apply: you can only use numbers that your operator allows you to use.

Possible issues¶

When the caller ID configured on the SMP doesn’t work, it can result in showing the main number, another number or a hidden number. There are a number of things that might cause this:

The outgoing route(s) are configured to not change the caller ID

If the outgoing routes are configured to not change the caller ID (“transparent” mode), it will use the internal extension number as caller ID. This will not work on external trunks. Please verify that this has been correctly configured at

Communication Routing > Routes

The outgoing routes should either be configured to have the setting “Caller ID policy” set to “Translate” (previously “As set in Global Parameters”).

The telephony operator overwrites your changes

If your telephony operator was asked to ignore the caller ID sent by the PBX and set a specific (or hidden) number, you will not be able to set a caller ID. Please contact your telephony operator

The value is not in the syntax required by the telephony operator

Quite often, the caller ID will be the national number format sent without a prefixed ‘0’. However, it might be possible that your telephony operator requires a different syntax. First try the number without prefixed ‘0’, afterwards with zero. For example: try 27974409 as well as 027974409.

If this fails, please contact your telephony operator in case of doubt.

The value is not permitted

The caller ID can only be a number which arrives on your circuit. If you try to send an invalid caller ID, your telephony operator will either hide the number or use the base number of your circuit.

Example: if the only number range which arrives on your SOP is “027974400 » 027974409” , you will not be permitted to use 036693120 as caller ID. The caller ID value must be, in this example, higher than or equal to 027974400 and lower than or equal to 027974409.

Please contact your telephony operator in order to find out which numbers are available.

Hide caller ID on SIP trunks: CLIR mode

Some SIP providers allow to send the external callerid on the trunk and hide it for the called party. This is useful for billing purposes.

In order to configure that you have to keep an outgoing number mapping configured for your extensions. The hidden mode can be configured in the goto.INTERFACE action in the extra-cluster routing: use “CLIR” mode.

You can also setup an outgoing callflow to activate CLIR mode. That way you can enable CLIR based on the context or only for some extensions. See the CallInterface documentation: “Caller ID policy” CLIR and “Shared trunk and IMS trunk” section

Cluster / Server configuration reference guide¶

Cluster Configuration reference guide¶

Snapshot mode

In the cluster configuration, you can now change how the automatic snapshot are done when you do an “Apply Changes”. There are now 3 options available:

Snapshot for master SOP and member SOP’s : an automatic snapshot will be done for the master SOP and all the SOP’s in the cluster.
Snapshot for master SOP only : an automatic snapshot will be done for the master SOP only.
No snapshot at all : no automatic snapshot will be done.

For the other fields, see server configuration below

Server Configuration reference guide¶

Server Name

The server name can be set to anything you want to easily identify the SOP. The name has to be unique in your cluster.

Account / Network ID / Cluster (smpadmin only)

SMP owners can set the account and network ID of a SOP.

The account identifies your customer. The network ID allows to group SOP’s in a cluster. If the network ID is blank, the SOP will be a solitary SOP. If a network ID is given, SOP’s having the same network ID (and the same account) will form a network. A network should have exactly one SOP set as Cluster. This is not a real SOP, it is a representation for the cluster as a whole.

ALERT Changing the “Account”, “Network ID” or “Cluster/SOP” flag has severe consequences on the configuration. In general it should never be changed for SOP’s that are in use.

SMP Version (smpadmin only)

The SMP version allows to change the version of the SMP being used for this SOP. The available options depend on the versions installed on your SMP.

Clone From (smpadmin only)

If set, this SOP will become a clone of the SOP specified. A clone will be configured exactly the same as it’s HA-master (when doing apply changes or install modules). The only difference is the standby IP address (see High-Availability module). An HA-master and clone form an Active-Standby high availability setup. Note that from an operational point of view, there is no difference between a HA-master and a clone. Except for the SMP, they are equal. The HA-master could be active and the clone standby or vice versa.

ALERT Changing the “Clone From” field has severe consequences on the configuration. In general it should never be changed for SOP’s that are in use.

vSOP container (smpadmin only)

This must be set if the SOP is not a physical machine, but a virtual SOP (vSOP), i.e. a virtual machine running on a host SOP. The host SOP has a vSOP resource for every vSOP container. With this dropdown you can specify on which host SOP and in which container this SOP is running.

Network configuration

Mandatory basic IP network configuration parameters. Additional, more advanced parameters can be found in the Network module. In case of active-standby high-availability, an additional IP address is configured in the High Availability module.

Time Zone

This is mandatory to ensure proper display of the time in various places including phones and reports. SOP’s in a cluster can be in different time zones. Phones on the same SOP cannot.

Backup, Monitoring, In Service

Backup and monitoring allows you to enable the backup and the monitoring of the SOP. You should note that depending on the SMP, It might take up to one day to start to monitor the SOP.

In Service should be set to ‘yes’ when the SOP is in production and ‘no’ when in maintenance (for example). When set to ‘no’, both backup and monitoring will be disabled. When set to ‘yes’, it depends on the backup and monitoring flags if backups and monitoring are enabled.

The “in service” flag enables or disables monitoring and/or backup only for that sopkey, regardless if this is a cluster or a normal sop. So in case a cluster sopkey has in_service set to yes, this does not imply that in_service is set to yes for the sops of that cluster.”

The monitoring flag is also available in the cluster configuration. This does not influence the monitoring of the individual SOP’s of that cluster. It only enables/disables the aggregated probes at the cluster level. Aggregated probes combine data from several SOP’s of the cluster.

Recovery Password (smpadmin only)

This displays the recovery password. The recovery password allows to reset the admin password using the SOP shell. This feature requires the Shell module 1.14.5 or higher.

Unattended installation

This allows the SMP to automatically accept the SOP public key during the baseline installation. Once the connection to the SMP is established an “Install modules” will be triggered followed by an “Apply Changes”. After that the unattended installation mode will be disabled.

Note that if a previous public key was already accepted, it will be cleared and the new one will be accepted.

Public Key

The SOP maintains a secure connection to the SMP. The SMP needs to know that the SOP that is connecting to the SMP is really the one it claims to be. To do that the SMP needs to know the public key of the SOP. While the SOP installation process automatically sends the public key to the SMP, it is finally up to you, the administrator, to say that you trust the key.

If the SOP has sent its key to the SMP, you will see the key in the text box. If you trust the key, you can use the Accept Key button to install the key on the SSH routers and allow the SOP to establish the connection with the SMP.

The key cannot be altered by hand, it can only be published from the SOP:

during the installation of the SOP
by using the SOP shell

Configuration > Key management > Regenerate authentication keys

If a key is already on the SMP, you cannot publish a new one. You will see following message on the SOP when attempting to publish a new key:

Not authorized to register key on SMP

In that case you have to use the Clear Key button to remove the key from the SMP.

Common report parameters reference guide¶

Scheduling and Output configuration parameters

You can first choose the interval at which the report will be generated by configuring the Run automatically field that has the following options :
- Never : means you don’t schedule a report.
- Continuous : means the report will be scheduled every minute.
- Every hour : means the report will be scheduled every hour but not necessarily on the hour.
- Every night : means the report will be scheduled every night. The earliest it can start is midnight.
- Every Sunday night : means the report will be scheduled every Sunday night. It occurs during the night of Sunday to Monday and the earliest it can start is midnight.
- Every 1st of the month : means the report will be scheduled every 1st day of the month. The earliest it can start is midnight.
Automatic Run Options: options that apply only when the report is scheduled
1. You can also choose the output. That’s the way the report will be sent or stored when scheduled. The Output field has the following options :
  - No output : means the report won’t be stored.
  - File : means the report will be stored in a file on the SMP. Note that the file name is given by the Report filename field explained later.
  - Mail : means the report will be sent by mail. Note that the mail address is given by the Email report to field explained later.
  - FTP : means the report will be stored in a file on an FTP server (for instance your own). Note that the FTP URL is given by the Report filename field explained later.
2. Email report to is used when Mail is configured as Output. This should be a valid email address or multiple e-mail addresses separated by a comma. (e.g. test1@mail.com,test2@mail.com)
3. Report filename is used when either File or FTP is configured as Output.
  - Output set to File : It should be a filename (without a path, not containing ‘/’).
  - Output set to FTP : It should be an FTP URL. An FTP URL is of the form: ftp://user:password@host:port/path/filename.

Note : For the report filename

you can format a date when the output is set to “File” or “FTP” as you wish by surrounding PHP date by angular brackets. Example : will print 20141201 for the 1st december 2014.
you can format a sequence when the Output is set to FTP by specifying the length of the sequence surrounded by square brackets. Example: [6] will print 000001 for the first time a report is generated. It will print 000002 for the second time the report is generated. Note that after 999999, it will start again at 000001.

General behaviour

The reports/tasks are run one at a time, there cannot be 2 reports/tasks running at the same time. It means that before being executed, the previous reports/tasks must be processed. Note that reports are executed after tasks in order to ensure that SyncCDRDB is finished before we start generating the reports.

It means we cannot predict the exact time at which a report will be started, we can just tell the earliest time at which it could be started. See Configuration options for more details.

ALERT The “Output” parameter and other Automatic Run Options are only used when the report is scheduled (as opposed to tasks). It will be of no effect when the report is generated manually.

Common task parameters reference guide¶

Scheduling and Output configuration parameters

You can first choose the interval at which the report will be generated by configuring the Run automatically field that has the following options :
- Never : means you don’t schedule a report.
- Continuous : means the report will be scheduled every minute.
- Every hour : means the report will be scheduled every hour but not necessarily on the hour.
- Every night : means the report will be scheduled every night. The earliest it can start is midnight.
- Every Sunday night : means the report will be scheduled every Sunday night. It occurs during the night of Sunday to Monday and the earliest it can start is midnight.
- Every 1st of the month : means the report will be scheduled every 1st day of the month. The earliest it can start is midnight.
You can also choose the output. That’s the way the report will be sent or stored. The Output field has the following options :
- No output : means the report won’t be stored.
- File : means the report will be stored in a file on the SMP. Note that the file name is given by the Report filename field explained later.
- Mail : means the report will be sent by mail. Note that the mail address is given by the Email report to field explained later.
- FTP : means the report will be stored in a file on an FTP server (for instance your own). Note that the FTP URL is given by the Report filename field explained later.
Email report to is used when Mail is configured as Output. This should be a valid email address or multiple e-mail addresses separated by a comma. (e.g. test1@mail.com,test2@mail.com)
Report filename is used when either File or FTP is configured as Output.
- Output set to File : It should be a filename (without a path, not containing ‘/’).
- Output set to FTP : It should be an FTP URL. An FTP URL is of the form: ftp://user:password@host:port/path/filename.

Note : For the Report filename

you can format a date when the Output is set to File or FTP as you wish by surrounding PHP date by angular brackets. Example : will print 20141201 for the 1st december 2014.
You can format a sequence when the Output is set to FTP by specifying the length of the sequence surrounded by square brackets. Example: [6] will print 000001 for the first time a report is generated. It will print 000002 for the second time the report is generated. Note that after 999999, it will start again at 000001.

General behaviour

The reports/tasks are run one at a time, there cannot be 2 reports/tasks running at the same time. It means that before being executed, the previous reports/tasks must be processed. Note that reports are executed after tasks in order to ensure that SyncCDRDB is finished before we start generating the reports.

It means we cannot predict the exact time at which a report will be started, we can just tell the earliest time at which it could be started. See Configuration options for more details.

ALERT The Output parameter is also used when the task is launched manually (as opposed to reports).

Language Configuration¶

The language configuration menu manages all the languages available for setting user language. They are defined under format [language[_territory]] where territory is optional, allowing support for non-localized versions.

This menu is only available for the service creator.

Components lifecycle¶

Components that can be used on the SMP to build a solution can have multiple status and visibility.

Component status¶

dev : Under active development, can be changed at any time
ed : Early deployment, may not be changed anymore, but not recommended for general use
gd : General deployment, may not be changed anymore, recommended for general use
deprecated : A deprecated version that shouldn’t be used any longer for one of 2 reasons:
- Contains a bug or limitation with a significant impact on the rest of the system
- Not supported anymore

Component visibility¶

Some components can have the Restricted flag. It concerns limited deployments or deployments that are part of a template that includes those components.

The restricted components or the specific versions that are restricted will only be visible in the SMP

when the component is included in the template applied to the current SOP
when the component was added by Escaux to the SOP

The documentation of restricted components is not publicly available.