1 Emergency and Priority Call Handling
A certain amount of processing capacity (priority pool) can be reserved by the vMRF for emergency and priority calls. The capacityForPriorityCalls attribute of the MediaResourceFunction MO defines a fraction of the total processing capacity and internal resources that is reserved for emergency and priority calls. The attribute is a numeric value, where 1 is 1/1000 fraction of the total processing capacity. The default value is 20.
1.1 Configure the Priority Pool
This procedure describes how to set the size of the priority pool.
Prerequisites
An Ericsson Command-Line Interface (ECLI) session in Exec mode is open.
Steps
2 Manual Scaling
2.1 Manual Scaling in OpenStack
This section describes how to perform manual scaling in OpenStack environment.
2.1.1 Scale-out Procedure
Prerequisites
The vMRF VMs to be scaled-out are configured as MRFP (Media Resource Function Processor) nodes in the MTAS.
A vMRF VM identifies itself to the MTAS with a Message Id (MId) that contains the vMRF VM signaling IP address and SCTP port. Typically, the whole range of signaling IP addresses, that is, the signaling subnet, that has been configured in the OpenStack for the vMRF VNF, is configured as MRFP nodes in the MTAS.
For more information on adding an MRFP node in MTAS, refer to section Add MRFP in MTAS Media Control Management Guide, Reference [1].
Steps
2.1.2 Scale-in Procedure
3 Lock a VM
This procedure describes how to lock a VM.
| Note: |
In the procedure below, after modifying the administrativeState
attribute, the VMs are immediately locked and all ongoing traffic on the VMs stops. |
Prerequisites
Other upgrade operations are not ongoing, for example, software upgrade.
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
Steps
4 EVS Configuration
Configuring EVS bandwidth and bit rate
4.1 Configure EVS Bandwidth and Bit Rate
This procedure describes how to configure allowed bandwidth range and maximum allowed bit rate for EVS to control EVS codec configuration and negotiation.
|
Bandwidth |
Bit Rate |
|---|---|
|
Narrowband (300 – 3400 Hz) |
5.9 kbps, 7.2 kbps, 8 kbps, 9.6 kbps, 13.2 kbps, 16.4 kbps, 24.4 kbps |
|
Wideband (50 – 7000 Hz) |
5.9 kbps, 7.2 kbps, 8 kbps, 9.6 kbps, 13.2 kbps, 16.4 kbps, 24.4 kbps, 32 kbps, 48 kbps, 64 kbps, 96 kbps, 128 kbps |
|
Super-wideband (50 – 14000 Hz) |
9.6 kbps, 13.2 kbps, 16.4 kbps, 24.4 kbps, 32 kbps, 48 kbps, 64 kbps, 96 kbps, 128 kbps |
|
Fullband (20 – 20000 Hz) |
16.4 kbps, 24.4 kbps, 32 kbps, 48 kbps, 64 kbps, 96 kbps, 128 kbps |
Prerequisites
An ECLI session in Exec mode is open.
Steps
5 Announcement Configuration
This section describes the procedures for announcement configuration. If the announcement service provided by vMRF is used, this is a mandatory configuration task.
5.1 Announcement Storage
The announcement files can be stored either in an external announcement storage server, or locally, in the vMRF VMs. The storage server solution is recommended for availability reasons. The local storage should be utilized when remote storage is not available.
5.1.1 Announcement Storage Server
The recommended solution for the storage for announcements is a directory placed in a storage server, which is accessible from each VM in the cluster. A vMRF VM connects to the server with sshfs (Secure SHell FileSystem), and mounts a specified directory path. The announcement files needed for playing the announcements are stored under this directory. The announcement storage is enabled by default for vMRF.
The prerequisites for the storage server are the following:
- ssh connection support with public and private keys
- authentication of the ssh connections from the vMRF VMs
- defined user name and ssh public key
- the public key is appended to the authorized keys file using the following command:
cat .ssh/<public_key_file_name> >> .ssh/<authorized_keys_file_name>
- path for the announcement files
Configuration of the announcement storage in the vMRF is performed during instantiation by filling in the relevant HOT template parameters. Following parameters must be defined:
- user name for the announcement storage server
- ssh private key for the username
- IP address of the announcement storage server
- server port of the announcement storage server
- mount directory path
- remote server ssh host key fingerprint
For more information on the HOT template configuration see the relevant deployment instructions.
5.1.2 Local Storage
If there is no storage server available in the cloud installation, the announcement files can also be stored locally in the vMRF VMs.
In this case, the HOT template parameters for announcement storage must not be defined at deployment. If the parameters are missing, the vMRF VMs automatically start up configured for local storage of announcement files. Announcement files can be added to the VMs by using the secure copy (scp) command to copy the files to the /cluster/storage/announcements directory on the active SC. The vMRF distributes the contents of this directory from the active SC to all VMs.
If local storage is used, the announcement files must be backed up and copied during the upgrade process manually, because they are not exported and are therefore deleted during redeployment.
5.2 Modify the Default Language Code
This procedure describes how to modify the default language code of announcements. The default language code is used as language code for the basic and variable announcements in case the H.248 (or SIP) message does not contain any language code for the requested announcement.
Prerequisites
An Ericsson Command-Line Interface (ECLI) session in Exec mode is openSteps
5.3 Basic Announcements
Basic announcements are identified by the announcement ID and a language code. The combination of announcement ID and language code form a unique identity for the basic announcement. For multi-language announcements the announcement ID is the same in multiple instances of BasicAnnouncement MOs, but the language code is different.
The audio files must be available in the storage server or in the local storage before basic announcements are created. A separate BasicAnnouncement MO must be created for each audio file.
The file names and the file paths of the associated audio files are specified at basic announcement creation.
| Note: | The file names are case sensitive, and special characters, such as space, are not allowed. |
5.3.1 Create a Basic Announcement
This procedure describes how to create a BasicAnnouncement MO, that represents a single audio announcement file.
Prerequisites
An Ericsson Command-Line Interface (ECLI) session in Exec mode is open.
The announcement files are available on the announcement storage server or in the local storage.
Steps
5.4 Variable Announcements
Variable announcements are identified by the variable type and the language code. The combination of variable type and language code form a unique identity for the variable announcement. For multi-language announcements the variable type is the same in multiple instances of VariableAnnouncement MOs, but the language code is different.
The audio files and logic files have to be available in the storage server or in the local storage before variable announcements are created. A separate VariableAnnouncement MO must be created for each variable announcement logic file.
| Note: |
It is not necessary to create BasicAnnouncement MOs for the audio files used for
variable announcements. |
The file names and the file paths of the associated logic files are specified at variable announcement creation.
| Note: |
The file names are case sensitive, and special characters, such as space, are not
allowed. |
5.4.1 Logic File Type Examples
The following examples show how to create logic files in Lua for variable announcements.
Example Logic File for Variable Announcement Type Digits
Example Logic File for Announcement Type Date
Example Logic File for Announcement Type Time
5.4.2 Create Logic Files
A logic file contains the algorithm logic for a variable announcement in a form that can directly be interpreted. When a play request for a variable announcement is received by the Announcement Service, it uses the logic in the associated algorithm file, together with data sent along with the play request, to determine which output to generate.
As a service, Ericsson can provide logic files for variable announcements, or, optionally, they can be created using the Lua scripting language, based on the examples shown in Logic File Type Examples. The Lua version used in vMRF is 5.3.
For more information on the Lua scripting language, see http://www.lua.org.
Steps
5.4.2.1 Lua Restrictions in Variable Logic Definition
The functions defined in logic files are the following:
get_file_list() This function returns a table with all audio files that are used by the logic file.
get_play_list(input) This function returns a table with all audio files that are played for a specific input.
The execution environment for the variable logic is restricted to the following:
Basic library use is restricted to following functions:
pairs
ipars
tonumber
error
type
String manipulation library is fully available through the name string, for example:
string.sub(input, 1, 2)
Table manipulation library is fully available through the name table, for example:
table.insert(file list, "file2")
5.4.3 Logic File Validator Tool
The Logic File Validator (LFV) tool is used to validate logic files written by the operator without involving Ericsson in the process. It is available in the vMRF delivery package as a single file in the tools directory. The tool file name is logic-file-validator. In order to use the LFV tool, the Lua interpreter, version 5.2 or higher, needs to be downloaded and installed from http://www.lua.org.
To validate a logic file, the operator must verify that both the syntax and the behavior of the logic file is correct. A logic file that is validated by the LFV tool is compatible with the vMRF.
The LFV tool can be used by issuing the lua logic-file-validator command in the CLI.
Options without arguments:
| -h, --help |
Prints the help message and exits the LFV tool. |
Options with mandatory arguments:
| --check-syntax <logic file name> |
This option checks whether the logic file syntax is correct and the mandatory functions get_file_list() and get_play_list(input) exist. |
|||
| --execute <logic file name> |
This option tests logic file execution without input, and prints the list of audio files used by the logic file. |
|||
| --execute <logic file name> <input> |
This option tests logic file execution with the given input. It also prints
the list of audio files to be played for the given input.
|
|||
In case of errors, an error message with specific information is printed.
5.4.3.1 Check Logic File Syntax
The following procedure describes how to check logic file syntax.
There are no Lua syntax errors in the logic file
The logic file contains mandatory functions required by vMRF
Steps
5.4.3.2 Verify Logic File Behavior
The following procedure describes how to check logic file behavior.
A list of audio files used in the logic file
A list of audio files to be played for the given input
Prohibited functions in the logic file, if any
Steps
5.4.4 Create a Variable Announcement
This procedure describes how to create a VariableAnnouncement MO, that represents a single variable announcement type.
Prerequisites
An Ericsson Command-Line Interface (ECLI) session in Exec mode is open.
The announcement files are available on the announcement storage server or in the local storage.
Steps
5.5 Handling of Announcement Files
The audio announcement file is created by recording an announcement. The sample rate of the audio announcement has to be 16 kHz and the audio mode Mono. The audio announcement has to be encoded in 16 bit 16 kHz PCM and stored in Waveform Audio File Format (WAV).
When the audio files for basic and variable announcements are stored to the storage server, the recommended directory structure for the stored audio files in the storage server is the following:
/announcement_storage/basic/en-GB/
When using local storage, a similar directory structure must be created locally to ensure that vMRF can locate announcement audio files:
/cluster/storage/announcements/basic/en-GB/
When the logic files for variable announcements are stored to the storage server, the recommended directory structure for the stored logic files in the storage server is the following:
/announcement_storage/variable/en-GB/
When using local storage, a similar directory structure must be created locally to ensure that vMRF can locate variable announcement logic files:
/cluster/storage/announcements/variable/en-GB/
| Note: |
The announcement audio files are stored to cache for announcement playing. The cache
refresh
time
is
15
minutes.
After storing a new audio file with the same file name to the announcement storage,
it can take up to 15 minutes before the new audio file is taken into use for
announcement playing. |
5.6 Converting Existing Audio Files to vMRF Supported Format
If there are existing audio files which needs to be migrated from native MRF nodes to be used in vMRF, for example in PCMA or PCMU encoded headerless format, they can be converted to vMRF supported WAV 16 bit 16 kHz PCM audio format files using for example Sound eXchange (SoX) audio editing software. SoX is available in many Linux distributions and also for macOS and Windows (https://sourceforge.net/projects/sox/).
| Note: | Conversion of PCMA or PCMU encoded (NB quality) audio files with SoX to WAV 16 bit 16 kHz PCM (WB quality) audio format files does not improve the audio quality from NB to WB. To achieve WB quality announcements, the announcements must be recorded in WB quality, and encoded and stored to WAV 16 bit 16 kHz PCM audio format. |
An example using SoX from the command line in linux, macOS, or Windows for converting one headerless PCMA audio file to WAV 16 bit 16 kHz PCM audio format file:
#sox -c 1 -r 8000 -t al <INPUT_alaw> -r 16000 -b 16 -t wav <OUTPUT_linear_s16_16k>.wav
An example using SoX in linux and macOS converting all headerless PCMA audio files in a directory to WAV 16 bit 16 kHz PCM audio format files:
#for i in *; do sox -c 1 -r 8000 -t al ./$i -r 16000 -b 16 -t wav $i.wav; done
An example for linux and macOS for removing all non-WAV format files in the directory, after conversion of audio files to WAV 16 bit 16 kHz PCM audio format files:
#fdel . -type f -not -name '*.wav' -print0 | xargs -0 rm
| Note: | This command removes all files in the directory that do not have the wav file extension. |
An example using SoX in Windows for converting all headerless PCMA audio files in a directory to WAV 16 bit 16 kHz PCM audio format files:
#for %i in (*) do sox -c 1 -r 8000 -t al .\%i -r 16000 -b 16 -t wav %i.wav
An example for removing all files without file extension in the directory, after conversion of audio files to WAV 16 bit 16 kHz PCM audio format files:
#del *.
| Note: | This command removes all files in the directory that do not have any file extension. |
6 Modifying Tone Parameters
The TsTone MO represents a tone as used by the Tone Sender (TS) service in the vMRF. An instance of this MO exists for each tone type supported by the VNF. The MO instances are created automatically by the system when the ToneSenderService MO instance is created. The TsTone parameters, for example, tone type, tone duration, frequencies, levels, play and pause times, can be changed. All parameters belonging to the TsTone MO, their value ranges and default values can be found under the TsTone MO in the MOM.
Prerequisites
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
Steps
7 vMRF Configuration Export and Import
This section describes exporting and importing vMRF configuration, as shown in Figure 1.
MO configuration data
certificates
credentials
The exported archive file includes the certificates and credentials installed under the CertM MO, with the appropriate metadata to reinstall them on import. The default format of the archive file is .tar.gz.
