Centralize configuration in smsc.conf and auto-configure similar to Restcomm Connect

[deruelle]

To avoid users messing up with many different xml conf files on configuration, logging, etc we should have a central smsc.conf and a startup script to auto configure SMSC similar to how it's done in Restcomm Connect

[vetss]

Current configuring has different files / places for changing because of many components that SMSC GW has on board. Many components have it's own configuring systems and it may demands of refactoring of components before we can achieve this target.

What we have now:

• SS7: a set of xml configs in /server/default/data folder. Default value - no connection is configured. Regular configuring - by CLI or GUI interface (direct xml files update is not recommended). Configs from old servers are auto updated to new server release. This means that when new server release deployment we can copy old config files to a new release folder and old configs setting will be applied to a new server. This backup compatibility is for all version.
  Several parameters are needed to be configured in jboss-mbean.xml file (customized mproc rules configuring, dialogic SS7 cards configuring, ITU / ANSI and several extra less options that are not allowed to config by CLI/GUI)
• SMPP: same as for SS7
• HTTP:

1. RA level - update config xml files inside a jar and recreating of JAR
2. server level configuring same as SS7

• SIP:

1. RA level - update config xml files inside a jar and recreating of JAR
2. server level configuring same as SS7

• DIAMETER - separate configuring by changing of xml files
• core level configuring, mproc rules, statistcics etc: same as SS7
• logging levels - in conf/jboss-log4j.xml - we have templates for different levels

Generally most of options is configurable by GUI during a server life. Except of several special actions we can copy of config file to a new release binaries (so version updte is rather easy)

[vetss]

I see solutions "central smsc.conf and a startup script to auto configure SMSC" :

• we can leave current configs as it is and create a tool/scropt for initial file filling from smsc.conf.

1. make manually a smsc.conf and then a implement a script/tool that will update regular SMSC GW config files at a fisrt start of a server (smsc.conf filling may become a complicated task in a complicated connections case).
2. implement a GUI tool for smsc.conf generating will make smsc.conf and create a script that will change smsc.conf ino a a set of files / configs. This approach looks me more convinient.
   We will reuse of current configuring tools for further SMSC GW configuring and smsc.conf only for initial configuring.

• complete refactoring of a variaty of connectors (HTTP, SS7, diameter, HTTP, SIP) and core level so they will support that file smsc.conf. This will demand significant update of smsc parts. Another disadantages that such componets may be also used separately or in another solutions and support of all this will bring us extra complexity.

[vetss]

Here is an explainging from @gvagenas for RC side:

Currently, we have many configuration files, restcomm.xml, log4j.xml, standalone-conf.xml (jboss), jain-sip-properties to name few of them. What we did in the past was to create 1 configuration file restcomm.conf and then a bash script that was reading properties from the restcomm.conf and was was modifying the appropriate configuration file, for example set the log level, change Jboss http port, setup Restcomm etc.
Thats what we currently have, but it turned out to be a completely mess also because bash script can be VERY VERY messy as they grow up and also eventually we didn’t provide any simplification in the configuration, we just moved ALL configuration options from the various files to the new one restcomm.conf. Currently the mess is so obvious because for every new configuration option on Restcomm, we have to do the following:

1. Change Restcomm for the new configuration option
2. Add the new configuration option to restcomm.xml
3. Add the new configuration option to restcomm.conf
4. Modify the bash scripts to read the new option and modify the restcomm.xml

So eventually things are worst then before.

In any case here you can see all the new configuration files and scripts we use: https://github.com/RestComm/Restcomm-Connect/tree/master/restcomm/configuration/config-scripts/as7-config-scripts/restcomm

I strongly suggest you to check the document I shared earlier and go that way