SVC Installation
Overall Installation Steps
The high-level steps for installing and configuring N2ACD SVC nodes are:
- Determine the server(s) that will supply the SVC logical component, bearing in mind the supported operating systems and minimum server requirements.
- Ensure the installation pre-requisites are met.
- Install the SVC package.
- Perform any required post-installation steps.
- Update the SVC configuration as desired.
Installation Pre-requisites
OS-specific Setup
Refer to the specific Red Hat or Debian instructions for any pre-requisites as required.
Lua
Each N2ACD SVC instance requires Lua to be available at version 5.2+. Specifically, lua
must be present in the PATH
for all users. Consult your operating system documentation to determine the appropriate package to install.
If your distribution does not support Lua at version 5.2+, N-Squared maintains a pre-packaged, separately-installable version of Lua that meets N2ACD’s requirements. Contact N-Squared Support to discuss access to this if required.
N2SVCD
The N-Squared application framework N2SVCD must be installed. Follow the installation steps for this, noting any prerequisites.
The N2ACD SVC package also expects that the default N2SVCD configuration directory exists:
/etc/n2svcd
Be sure to apply any applicable N2SVCD post-installation steps once installation is complete.
N2SCP
The N-Squared Service Control Point N2SCP must be installed. Follow the installation steps for this, noting any prerequisites.
Installation Steps
Follow the appropriate installation steps depending on your installation sources.
From N-Squared Repository
Execute the instructions specific to your operating system:
RHEL 8 | Other RPM-based Systems | DEB-based Systems |
---|---|---|
sudo dnf install n2acd-svc |
sudo yum install n2acd-svc |
sudo apt-get install n2acd-svc |
As Manual Installation
Transfer the provided package file to the target node, then follow the instructions specific to your operating system.
Execute (adjusting as appropriate for package location and version details) the following:
RPM-based Systems | DEB-based Systems |
---|---|
sudo rpm -Uvh /path/to/n2acd-svc-M.m.p-b.noarch.rpm |
sudo dpkg -i /path/to/n2acd-svc_M.m.p-b_all.deb |
Post-Installation Steps
N2SVCD and Database Integration
The N2ACD runtime uses several N2SVCD applications to perform call handling functions. For N2ACD call handling, the N2SVCD configuration must include:
- A Logic Handoff SCP N2SVCD application that receives the SIP (directly) or CAMEL/INAP (via an N2SVCD SIGTRAN application) call triggers and forwards them to…
- … a Logic N2SVCD application that executes the appropriate call logic and data after fetching it using…
- … Core and Local Database N2SVCD applications that returns pre-compiled Lua and runtime scratch data from the ACD and local databases, respectively.
At a high level, the required configuration for these applications looks like:
<application name="LHO" module="LhoScpApp"> <!-- or LhoSipApp -->
...
<parameters>
...
<parameter name="default_logic_app_name" value="Logic"/>
</parameters>
</application>
<application name="Logic" module="LogicApp">
...
<parameters>
...
<parameter name="default_db_app_name" value="DB-ACD"/>
<parameter name="db_app_name_acd" value="DB-ACD"/>
<parameter name="db_app_name_acd_local" value="DB-Local"/>
</parameters>
<config>
<services>
<service module="LhoScpApp::LhoScpLuaService"
db_app_name="DB-ACD"
.../>
</services>
<agents>
<agent module="DBApp::DBLuaAgent"
.../>
</agents>
</config>
</application>
<application name="DB-ACD" module="DBApp">
...
<parameters>
...
<parameter name="connect" value="..."/>
</parameters>
</application>
<application name="DB-Local" module="DBApp">
...
<parameters>
...
<parameter name="connect" value="..."/>
</parameters>
</application>
Refer to the individual application configuration documentation for full details of the configuration required. The core database application should be configured to connect to the appropriate primary or replica DB node that the SVC will use. Likewise, the local database application should be configured to connect to the appropriate LDB instance.
Once N2SVCD is updated, restart the service:
systemctl | System V |
---|---|
sudo systemctl restart n2svcd |
sudo service n2svcd restart |
REP Integration
If one or more REP nodes are planned, SVC statistics measurements and EDRs must be configured to go to the appropriate REP node(s) destinations.
If no REP node is planned, statistics and EDRs may be disabled or sent to an alternative data repository. Note that if EDRs are not disabled or transferred, they may eventually fill the file system.
Firewall
The firewall (if any) on the SVC node must be updated to allow:
- Establishment of the inbound or outbound SIGTRAN and/or SIP/RTP connectivity to the core network.
- Outbound database requests to the DB node(s).
If required, the firewall (if any) on the SVC node may also be updated to allow:
- Inbound requests for the N2SVCD administrative GUI/API.
- Outbound database requests to the LDB instance.
If a non-co-hosted REP node is planned, the firewall must also allow access for:
- Outbound statistics measurements to the REP node(s).
- Outbound EDRs to the REP node(s).
Otherwise, if an alternative data repository is to be used for statistics and EDRs, the firewall must be updated to allow access for:
- Outbound statistics measurements to the repository.
- Outbound EDRs to the repository.
The exact commands to do this will depend both on the firewall on your platform and also which port(s) are in use. For
example, to allow the default PostgreSQL port when using firewalld
, the commands might be:
firewall-cmd --zone=public --add-port=5432/tcp --permanent
service firewalld restart