User Guide 5/1553-AXM10104/1 Uen S
[ Topics hidden with current filter selection ]

vMRF Configuration Management
Virtual Multimedia Resource Function

Contents


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 Configuration of 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

  1. Navigate to the MediaResourceFunction MO and enter configure mode:
    >ManagedElement=1,MediaResourceFunction=1
    (MediaResourceFunction=1)>configure
  2. Modify the value of the capacityForPriorityCalls attribute:
    (config-MediaResourceFunction=1)>capacityForPriorityCalls=<value>
  3. Commit the changes:
    (config-MediaResourceFunction=1)>commit
  4. The job is completed.

2 Manual Scaling

This section describes how to perform manual scaling in the VNF cluster by increasing or decreasing the number of VMs in a cluster.
Note:

Continue with these procedures only if the VNF cluster to be scaled-out or scaled-in was deployed manually.

2.1 Manual Scaling in OpenStack

This section describes how to perform manual scaling in OpenStack environment.

2.1.1 Scale-out Procedure

Prerequisites

Before starting this procedure, ensure that the following conditions are met:
  • 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

  1. Log in to the OpenStack CLI.
  2. Use the heat stack-update command to increase the size of the VNF, as shown below.
    • In an OpenStack Kilo-based cloud service, use the following command:

      heat stack-update <stack_name> -e example_environment.yaml -f vbgf.yaml -P payload_instance_count=<new number of VMs>
      Note:

      The example above shows how to use the command to increase the size of the VNF while using the example_environment.yaml file.

      When using the command, all deployment parameters must have the same values as during stack creation. To ensure this, the same example_environment.yaml file must be used, and only the payload_instance_count parameter needs to be specified. Any deviation from the original values can impact the traffic.

    • In an OpenStack Mitaka-based cloud service, it is also possible to use the following command:

      heat stack-update <stack_name> -x -P payload_instance_count=<new number of VMs>

  3. Log in to the dashboard and check that the VMs belonging to the VNF are visible in the Network Topology view.
  4. Check the status of the VNF by running the following command:

    verify_vmrf_cluster_status.py

When a VM is added to the cluster during scale-out, the following VM-related MOs are created automatically:

2.1.2 Scale-in Procedure

Steps

  1. Use the following command to list all the VMs that are part of the scaling domain within the specific VNF:
    heat output-show <stack name> resource_names

    Note the name of the VM you want to delete.

  2. Identify the UUID of the VM, by using one of the following options:
    • Open the OpenStack Dashboard. The UUID and name is shown for each VM.

    • Log in to the OpenStack CLI and use the nova list command. The UUID and name is shown for each VM in the printout.

    Note:

    Make sure that the ACTIVE SC and the STANDBY SC VMs are not deleted at the same time. If both of these need to be scaled in, first delete all VMs except for the ACTIVE SC, and then the ACTIVE SC in a separate scale-in operation.

  3. To minimize traffic impact, the VM you want to delete from the cluster must be locked. Lock the MrfInstance MO that represents the VM by using the instructions described in Locking a VM.

    The MrfInstance MO that represents the VM has a reference to the ComputeResource MO with the UUID identified before.

  4. Log in to the OpenStack CLI and use the heat stack-update command to decrease the size of the VNF by deleting the selected VM:

    heat stack-update <stack_name> -e example_environment.yaml -f vmrf.yaml -P payload_instance_count=<new number of VMs> -P payload_scaling_in_list=<Locked VM index>

    The <Locked VM index> is the last number in the name of the selected VM. For example, if the name of the VM is mrsv-3, the value of 3 must be used. If the payload_scaling_in_list parameter is not specified, the VM with the highest index is deleted automatically.

    Note:

    When using the command, all deployment parameters must have the same values as during stack creation. To ensure this, the same example_environment.yaml file must be used, and only the payload_instance_count and the payload_scaling_in_list parameters need to be specified. Any deviation from the original values can impact the traffic.

  5. Log in to the dashboard and check that the VM is not visible in the Network Topology view anymore.

When a VM is removed from the cluster during scale-in, the following VM related MOs are deleted automatically:

3 Locking a VM

This procedure describes how to lock a VM. Consider graceful locking through MTAS configuration by gracefully locking the MRFP nodes in MTAS. For more information, refer to section Deactivate Gracefully in MTAS Media Control Management Guide, Reference [1]. Otherwise continue with the steps below.

Prerequisites:

  • Other upgrade operations are not ongoing, for example, software upgrade.

  • An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.

Note:

In the procedure below, after modifying the administrativeState attribute, the VMs are immediately locked and all ongoing traffic on the VMs stops.

Steps

  1. Open an SSH connection to the O&M IP address of the vMRF VNF using the following command:
    ssh <user ID>@<O&M IP address>
  2. Start a session by issuing the cliss command.
  3. Navigate to the MrfInstance MO that represents the VM and enter configure mode:
    >ManagedElement=1,MediaResourceFunction=1,MrfResource=1,MrfInstance=<mrfInstanceId>
    (MrfInstance=<mrfInstanceId>)>configure
  4. Modify the value of the administrativeState attribute:
    (config-MrfInstance=<mrfInstanceId>)>administrativeState=<LOCKED>
    The VM is locked immediately and all ongoing traffic from the VM is lost.
  5. Commit the changes:
    (config-MrfInstance=<mrfInstanceId>)>commit
  6. The job is completed.

    4 EVS Configuration

    EVS configuration consists of the following activities:
    • 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.

    EVS codec negotiation is affected by bandwidth and bit rate configurations according to the following scenarios:
    • For incoming SDP offer, the common subset of the configured bandwidth and bit rate values, and the bandwidth and bit rate values received in the offer, are sent back in the SDP answer. The bandwidth and bit rate sent in the SDP answer are used for the media stream.

    • For outgoing SDP offer, the configured bandwidth and bit rate values are sent in the SDP offer. The bandwidth and bit rate values received in the SDP answer are used for the media stream.

    The possible bandwidth and bit rate combinations are shown in Table 1.
    Table 1   EVS Bandwidth and Bit Rate Combinations

    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

    1. Navigate to the MrfConfiguration MO and enter configure mode:
      >ManagedElement=1,MediaResourceFunction=1,MrfConfiguration=1
      (MrfConfiguration=1)>configure
    2. Create an MrfData MO:
      (config-MrfConfiguration=1)>MrfData=1
    3. Navigate to the EvsService MO and enter configure mode:
      >ManagedElement=1,MediaResourceFunction=1,MsProcessing=1,EvsService=1
      (EvsService=1)>configure
    4. Create an EvsConfData MO.
      (config-EvsService=1)>EvsConfData=1
    5. Set the supported bandwidth range:
      (config-EvsConfData=1)>supportedBwRange=<supported_bandwidth_range>
    6. Set the minimum value for the supported bit rate range:
      (config-EvsConfData=1)>supportedBitRatesRangeBegin=<value>
    7. Set the maximum value for the supported bit rate range:
      (config-EvsConfData=1)>supportedBitRatesRangeEnd=<value>
    8. Commit the changes:
      (config-EvsConfData=1)>commit
    9. Navigate to the MrfData MO in which the configuration changes are needed and enter configure mode:
      >ManagedElement=1,MediaResourceFunction=1,MrfConfiguration=1,MrfData=<1>
      (MrfData=1)>configure
    10. Modify the value of the attribute evsConfDataMoRef so that it refers to the EvsConfData created in Step 4.
      (config-MrfData=1)>evsConfDataMoRef="ManagedElement=1,MediaResourceFunction=1,MsProcessing=1,EvsService=1,EvsConfData=1"
    11. Commit the changes:
      (config-MrfData=1)>commit
    12. Navigate to the MrfH248Interface MO in which the configuration changes are needed, and enter configure mode:
      >ManagedElement=1,MediaResourceFunction=1,MrfH248Control=1,MrfH248Interface=1
      (MrfH248Interface=1)>configure
    13. Modify the mrfDataMoRef attribute of the MrfH248Interface MO so that it refers to the MrfData MO that contains a reference to the EvsConfData created in Step 4.
      (config-MrfH248Interface=1)>mrfDataMoRef="ManagedElement=1,MediaResourceFunction=1,MrfConfiguration=1,MrfData=1"
    14. Commit the changes:
      (config-MrfH248Interface=1)>commit

    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 refer to 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 will automatically start up configured for local storage of announcement files. Announcement files can be added 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 will distribute 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.

    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 open

    Steps

    1. In the MOM, navigate to the Announcements MO and enter configure mode:

      >ManagedElement=1,MediaResourceFunction=1,Announcements=1

      (Announcements=1)>configure

    2. Modify the value of the defaultLanguageCode attribute:

      (config-Announcements=1)>defaultLanguageCode=<value>

      Note:

      The language code has the format of the RFC 5646 language tag.

    3. Commit the changes:

      (config-Announcements=1)>commit

    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

    1. In the MOM, navigate to ManagedElement=1,MediaResourceFunction=1,Announcements=1,BasicAnnouncements=1 and create a BasicAnnouncement MO for each audio announcement file.
    2. For each created BasicAnnouncement MO, define values for the following attributes:
      • announcementId

        An identity for the basic announcement. The combination of the announcementId and languageCode attributes form a unique identity for the basic announcement.

      • basicAnnouncementId

        The value component of the RDN.

      • fileName

        The name of the announcement file.

      • filePath

        The relative file path to the directory where the announcement file is stored. The value of this attribute is relative to the announcement_storage_server_path attribute in the deployment template. In case of local storage the value of the attribute is relative to /cluster/storage/announcements.

        Example: basic/en-GB/

      • languageCode

        Language code of the basic announcement. The combination of the announcementId and languageCode attributes form a unique identity for the basic announcement.

        Language code has the format of an RFC 5646 language tag.

        Example: en-GB

      The following attributes are optional:

      • duration

        The amount of time the announcement is to be played in milliseconds. If the specified duration is greater than the overall length of the announcement, the announcement is repeated until the duration is elapsed. The playing time is also dependent on the value of the iteration attribute. The selected playing time is always the shortest possible alternative.

      • iteration

        The number of times the announcement is repeated when played to the user.

      • userLabel

        Label for free use.

      See table Basic Announcement Attributes for details.

    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

    Example Logic File for Announcement Type Number

    Example Logic File for Announcement Type Money

    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, refer to http://www.lua.org.

    Steps

    1. Create the logic file for the variable announcement type needed, based on the example files in Logic File Type Examples.
    2. Validate the logic file using the Logic File Validator (LFV) tool, by issuing the following commands for each logic file:
      • lua logic-file-validator --check-syntax <logic file name>

      • lua logic-file-validator --execute <logic file name>

      • lua logic-file-validator --execute <logic file name> <logic input>

      For more information on the LFV tool, see Logic File Validator Tool.

    3. Copy the logic file to the storage server.
      Note:

      The path of the logic files is needed during the creation of VariableAnnouncement MOs.

    5.4.2.1 Lua Restrictions in Variable Logic Definition

    The following restrictions apply for variable announcement logic files:
    • 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.
    Note:

    It is recommended to verify all inputs to test the entire code in the logic file.

    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.

    During logic file syntax validation, the LFV tool checks the following:
    • There are no Lua syntax errors in the logic file

    • The logic file contains mandatory functions required by vMRF

    Steps

    1. Check logic file syntax with the LFV tool by issuing the following command: lua logic-file-validator --check-syntax <logic file name>

      Example

      The following example shows a successful syntax check:

      username@hostname:/home/username > lua logic-file-validator --check-syntax test/logicFiles/Digits_en-GB.lua
      SUCCESS
      

      Example

      The following example shows checking a logic file with a missing mandatory function:

      username@hostname:/home/username > lua logic-file-validator --check-syntax test/logicFiles/get_file_list_missing.lua
      lua: logic-file-validator:55: Function 'get_file_list()' not defined in logic file
      stack traceback:
              [C]: in function 'error'
              logic-file-validator:55: in function 'execute_action'
              logic-file-validator:132: in function 'main'
              logic-file-validator:148: in main chunk
              [C]: in ?
      

    5.4.3.2 Verify Logic File Behavior

    The following procedure describes how to check logic file behavior.

    During logic file behavior check, the LFV tool prints the following information:
    • 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

    1. Verify that all audio files used in the logic file are listed in the output of the lua logic-file-validator --execute <logic file name> command.

      Example

      The example below shows the audio files used by the logic file.

      username@hostname:/home/username > lua logic-file-validator --execute test/logicFiles/Digits_en-GB.lua 
      basic/en-GB/0.wav
      basic/en-GB/1.wav
      basic/en-GB/2.wav
      basic/en-GB/3.wav
      basic/en-GB/4.wav
      basic/en-GB/5.wav
      basic/en-GB/6.wav
      basic/en-GB/7.wav
      basic/en-GB/8.wav
      basic/en-GB/9.wav
      
    2. Verify that the output of the lua logic-file-validator --execute <logic file name> <logic input> command contains all audio files used for the input.

      Example

      The example below shows the audio files used in the logic file only for the given input.

      username@hostname:/home/username > lua logic-file-validator --execute test/logicFiles/Number_en-GB.lua 234567
      234567
      basic/en-GB/2.wav
      basic/en-GB/100.wav
      basic/en-GB/30.wav
      basic/en-GB/4.wav
      basic/en-GB/1000.wav
      basic/en-GB/5.wav
      basic/en-GB/100.wav
      basic/en-GB/60.wav
      basic/en-GB/7.wav
      
    3. Verify that the logic file does not use prohibited functions.

      Example

      The following example shows validation error caused by a prohibited function in the logic file.

      username@hostname:/home/username > lua logic-file-validator --execute test/logicFiles/dofile_not_allowed.lua 123
      lua: logic-file-validator.lua:73: test/logicFiles/dofile_not_allowed.lua:31: attempt to call global 'dofile' (a nil value)
      stack traceback:
              [C]: in function 'error'
              logic-file-validator.lua:73: in function 'execute_action'
              logic-file-validator.lua:138: in function 'main'
              logic-file-validator.lua:148: in main chunk
              [C]: in ?
      

    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

    1. In the MOM, navigate to ManagedElement=1,MediaResourceFunction=1,Announcements=1,VariableAnnouncements=1 and create a VariableAnnouncement MO for each variable announcement type.
    2. For each created VariableAnnouncement MO, define values for the following attributes:
      • variableAnnouncementId

        The value component of the RDN.

      • logicFileName

        The name of the variable announcement logic file.

      • logicFilePath

        The relative file path to the directory where the variable announcement logic file is stored. The value of this attribute is relative to the announcement_storage_server_path in the deployment template. In case of local storage the value of attribute is relative to /cluster/storage/announcements.

        Recommended value: variable/<languageCode>/

        Example: variable/en-GB/

      • languageCode

        The language code of the variable announcement.

        The combination of the variableAnnouncementType and languageCode attributes form a unique identity for the variable announcement.

        The language code has the format of an RFC 5646 language tag.

        Example: en-GB

      • variableAnnouncementType

        Type of the variable announcement.

        The combination of the variableAnnouncementType and languageCode attributes form a unique identity for the variable announcement.

      The following attribute is optional:

      • userLabel

        Label for free use.

      See table Basic Announcement Attributes for details.

    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/

    5.6 Convert 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 formacOS 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 will remove 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 will remove all files in the directory that do not have any file extension.

    6 vMRF Configuration Export and Import

    This section describes exporting and importing MO configuration data, certificates, and credentials from and to the vMRF Managed Object Management (MOM) model, as shown in Figure 1.

    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.

    Figure 1   Configuration Export and Import

    6.1 vMRF Configuration Export

    A configuration export of an existing VNF can be used for backup purposes or as a way of migrating the VNF configuration to a new VNF when performing an upgrade.

    Prerequisites:

    • A configured and operational vMRF VNF is available and you can log in to it as emergency user, using SSH.

    To export the configuration of a vMRF VNF instance, do the following:

    Steps

    1. Open an SSH connection to the O&M IP address of the VNF instance using the following command:
      ssh <user ID>@<O&M IP address>
    2. Export the configuration data in one of the following ways:
      Options Command and result

      Export the configuration data into a specified .tar.gz archive file (the default and recommended format)

      Use the following command:

      /opt/mrf_director/mrf_export_conf.py/ home/<user ID>/<output_file_without_extension>

      The path to the output archive file is /home/<user ID>/<output_file_without_extension>.tar.gz

      Export the configuration data with a time stamp as a file name

      Use the following command:

      /opt/mrf_director/mrf_export_conf.py /home/<user ID>/mrf_conf_{timestamp}

      The path to the output archive file is /home/<user ID>/mrsv_conf_YYYY-MM-DD_hh-mm-ss.tar.gz


    3. If you want to use the exported configuration file in another VNF, copy it out of the file system of the VNF using, for example, the scp command:
      scp <user ID>@<O&M IP address>:/home/<user ID>/mrf_conf.tar.gz .

      The example configuration file mrf_conf.tar.gz is copied to the current directory from the /home/<user ID>/ folder in the file system of the vMRF VNF.

    6.2 vMRF Configuration Import

    A configuration import can be used for rapid deployment of new VNF instances when initial configuration has been prepared in advance or during an upgrade process to import a previously exported VNF configuration.

    Prerequisites:

    • An operational vMRF VNF is available and you can log in to it as emergency user, using SSH.

    • A file containing vMRF configuration data is available.

    To import configuration data from the file, do the following:

    Steps

    1. If the configuration data file is not available in the file system of the VNF, copy a file to the VNF using, for example, the scp command:
      scp mrf_conf.tar.gz <user ID>@<O&M IP address>:/home/<user ID>

      The configuration file mrf_conf.tar.gz is copied from the current directory to the /home/<user ID>/ folder in the file system of the vMRF VNF.

    2. Open an SSH connection to the O&M IP address of the vMRF VNF instance using the following command:
      ssh <user ID>@<O&M IP address>
    3. Run the following command:
      /opt/mrf_director/mrf_import_conf.py /home/<user ID>/mrf_conf.tar.gz

    Reference List

    [1]

    MTAS Media Control Management Guide, 19/1553-AVA 901 29/9


    Copyright

    © Ericsson AB 2016, 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

    Disclaimer

    The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.