For the incoming SDP offer the highest priority audio codec received in the SDP offer that is supported by the vMRF is selected for the media stream. In addition, if the SDP offer included also a telephone-event corresponding to the RTP clock rate of the selected audio codec, then the telephone-event is also selected for the media stream. The selected audio codec, and possibly the selected telephone-event, is sent back in the SDP answer.

For outgoing SDP offer the following audio codecs are sent in the SDP offer in this priority order: EVS, AMR-WB, G.722, AMR, G.729, PCMA, and PCMU. The highest priority audio codec, and possibly the telephone-event corresponding to the RTP clock rate of that audio codec, received in the SDP answer is used for the media stream.

Audio announcements feature is used to provide audio announcements and to facilitate interactive services for operators and network providers. vMRF supports audio announcements through streaming of audio content from the announcement files to subscribers. Audio announcements are supported in HD quality. The sample rate of the audio announcements is 16 kHz and the audio mode is Mono. Audio announcements have to be encoded in 16 bit 16 kHz PCM and stored in Waveform Audio File Format (WAV). vMRF plays an announcement towards a subscriber when a play request is received from the controlling node over H.248. Announcement files are stored on a storage server, and referenced by an announcement ID or variable announcement type. The recently played announcement files are cached to the local disk of a vMRF VM to support faster playing of announcements for future playing requests.

vMRF supports fixed announcements and segmented announcements. A fixed announcement consists of a single basic announcement. A segmented announcement is a compilation of individual announcements referred as announcement segments. In vMRF, an announcement segment can be a basic announcement or a stand-alone variable announcement. A basic announcement is a standalone announcement file that contains audio data of a spoken word or phrase. A variable announcement is an announcement whose spoken information heard by the user depends on input data received in a play request. vMRF supports the following variable announcement types: digits, date, time, number, and money. The variable announcement has a variable announcement logic file associated to each variable announcement type.

vMRF supports announcements with multiple languages. Multi-language announcements present the operator with an option to play announcements toward end users in their preferred language. Multi-language announcements are supported for both fixed announcements and segmented announcements. Multi-language announcements are identified by a single announcement ID or variable announcement type, and different languages are identified by using language tags. This enables playing of announcements toward end users in their preferred language, and simplifies the announcement configuration in vMRF and in the controlling node.

For configuration information on audio announcements refer to vMRF Configuration Management.

DTMF digits can be detected either as inband signals from an audio stream or as separate telephone events. In case of a telephone event, the DTMF digits are detected from the RTP packets that use telephone-event payload format with dynamically established RTP payload type number. DTMF detection is done either for inband signals or for telephone event, not for both types simultaneously. If telephone event payload type has been negotiated for the audio stream, then vMRF detects DTMF telephone events, otherwise audio inband signals.

DTMF digits are specified in a dialing plan, called a digit map. The digit map resides in the vMRF and it is used to detect and report certain DTMF patterns received from the user plane. A pattern is a set of rules which express how the user is expected to dial DTMF digits, including, for example, digit names and timer values for the detection process. Up to 16 different DTMF digits can be used, corresponding to the following symbols: 0, 1, 2...9, A, B, C, D, *, #. The digit map is preloaded dynamically for each session by the controlling node over H.248. vMRF detects as many DTMF digits as it is contained in the digit map. If all digits match, vMRF notifies the controlling node that DTMF digits were collected successfully. The notification contains the digits that were collected and number of attempts that were made to detect the digits.

vMRF supports forwarding of DTMF digits through audio conference from one participant to all other participants.

The function supports detection of either telephone-event DTMF or audio DTMF from the participant, based on SDP negotiation. While detecting audio DTMF digits, the received audio DTMF digits are filtered out from the stream before mixing audio by the audio mixer. The detected DTMF digits are sent to all other participants either as telephone-event DTMF or audio DTMF, based on SDP negotiation with each participant. The context topology and termination stream mode information is checked and obeyed before forwarding DTMF digits from one participant to another participant. The function can be enabled by configuration.

vMRF supports playing of tones to the user plane based on request from the MTAS. For supported tones, see Tone Sender Service.

vMRF supports emergency and priority call handling for the following call types:

• Emergency calls

• Priority calls

• International Emergency Preference Scheme (IEPS) priority calls

A call is considered an emergency or priority call if it is indicated so in the call setup. Emergency and priority calls are treated the same way, and they are prioritized over non-emergency and non-priority calls in the case of high load on the vMRF.

A certain amount of processing capacity and internal resources are reserved by the vMRF for emergency and priority calls. This reserved fraction is called a priority pool. Normal calls are not allowed to use the priority pool. Emergency and priority calls are allowed to use resources outside of the priority pool.

The size of the priority pool can be configured in the vMRF. For more information on priority pool, refer to vMRF Configuration Management.

For emergency and priority call handling the following rules apply:

• Emergency and priority calls are never rejected because of network level admission control or high CPU load

• Emergency and priority calls can be rejected because of lack of internal resources

The audio conferencing feature provides a service that allows the connection of as many as 30 participants to a conference call. For each participant, it can be specified whether the connection is unidirectional (listening only) or bidirectional. The audio conferencing feature can dynamically mix audio from several participants. The audio from a participant is mixed to the audio conference based on active speaker logic.

Each client can have its own codec in use, and the Audio Conferencing feature provides transcoding between them. Audio mixing is performed at 16 kHz sampling rate. This guarantees wideband conferencing experience for wideband-capable terminals.

The following audio codecs are supported by vMRF: PCM, EVS, G.722, G.729, AMR-NB, AMR-WB.

To detect an overload situation in the network caused by high network traffic, the vMRF monitors the following:

• vMRF Application processor load (H.248 signaling, control of media stream processing)
• vMRF Media Stream Processing load (computationally demanding media processing, for example, transcoding)
• vMRF IP Pipeline load (simple media processing, for example, IP packet Header processing)
• vMRF IP Pipeline vSwitch load (outgoing packets are dropped if the vSwitch cannot process more packets)

In case of an overload situation, the following alarms are raised based on available processing capacity:

• When 80% of the available processing capacity is used in the vMRF functions, the MRF Instance 80% Capacity Limit Exceeded alarm is raised. It indicates that the vMRF is approaching an overload situation and new virtual machines must be created.
• When 100% of the available processing capacity is used in the vMRF functions, the MRF Instance Overloaded alarm is raised. In this case only emergency and priority calls are accepted. New virtual machines must be created to increase processing capacity. When a call is rejected because of overload, the H.248 ErrorCode 510 "Insufficient Resources" is reported.

The use of shared storage is optional in vMRF. It allows for the storage of log files, crash dump files, and configuration backups on a remote server. To use it, a remote server with SSHFS (Secure Shell Filesystem) installed must be configured. The remote server and the exported files are managed by the operator.

The following files are stored by each VM:

• log files from the /var/log directory, including journal log files

• crash dump files

• configuration backup files created by the automatic backup and restore function, described in Automatic Backup and Restore

vMRF connects to the server with SSHFS (Secure Shell Filesystem), mounts a specified directory path, and creates a subfolder for the cluster, and subfolders for the files for each VM in the cluster. This ensures that logs and other shared files of different VMs and VNF instances do not get mixed up. For authentication, an SSH key pair has to be created. This key pair can be cluster-specific, or common for all clusters. The prerequisites for the remote server are the following:

• ssh connection support with public and private keys

• authentication of the ssh connections from the vMRF virtual machines

• defined username for the SSHFS mount

• ssh public key for the SSHFS mount

• 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 files

Configuration of the shared storage in the vMRF is performed during instantiation by filling in the relevant HOT template parameters. The following parameters must be defined:

• username for the shared storage SSHFS mount

• ssh private key for the SSHFS mount

• IP address of the shared storage server

• server port of the shared storage server

• mount directory path

• remote server ssh host key fingerprint

For more information on the HOT template configuration, refer to Deployment Guide for OpenStack and Deployment Guide for Cloud Execution Environment (CEE).

vMRF performs automatic configuration backup after configuration changes. To prevent unnecessary backup operations, a new configuration is saved after an 80-second wait period following the most recent change. The 10 latest configuration backups are stored in time-stamped files in /cluster/storage/configurationbackups/. The file naming convention is the following:

<YYYYMMDD>_<hhmmss>_mrf.tar.gz

The copy of the latest backup file is also saved as in the same directory. This file is synchronized across all VMs of a cluster to enable any new SC to restore configuration after cluster restart.

When the maximum number of backup files is reached, the oldest backup file is deleted before a new backup is stored.

vMRF can perform automatic configuration restore if all VMs in a cluster reboot simultaneously. In this case, the new SC VM looks for mrsv_config.tar.gz in /cluster/storage/configurationbackups/ and imports the configuration to the VNF, if the file exists.

IPv4 addresses are 32 bits long. In written format, the address is divided into four 8-bit (1 byte) long sections, using dots as separators. For example, 172.16.254.1 (decimal digits).

IPv6 addresses are 128 bits long. In written format, the address is divided into eight 16-bit long sections (pairs of bytes), using colons as separators. For example, 2001:db8:ffff:1:201:2ff:fe03:405 (hexadecimal digits).

For alternative writing formats of IPv6 addresses, refer to RFC 4291.

Local IP addresses for all networks are fetched from a DHCP server.

Internet Control Message Protocol for IPv6 (ICMPv6) is used for fetching the next hop addresses.

Normally vMRF ignores and discards, or rejects H.248 packages and properties related to the unsupported features. To avoid confusion and unnecessary troubleshooting, all H.248-controlled features that are not supported by vMRF must be turned off in the MTAS configuration.