EVS Codec Transcoding Support

Enhanced Voice Services (EVS) is a super-wideband speech audio codec developed by 3GPP and documented in TS 26.441. EVS supports source-controlled variable bit rate, sampling rates of 8, 16, 32, or 48 kHz, dynamic payload type, and an interoperability mode for AMR-WB. The Oracle® Enterprise Session Border Controller (ESBC) supports typical transcoding features. EVS can also analyze traffic signaling, allowing it to change to the correct core EVS codec when necessary. These changes can occur at every 20ms frame boundary. The ESBC also supports transcoding EVS to and from all supported transcodable codecs unless the EVS mode is using super-wideband or fullband EVS bandwidths. Note that, by configuration, you can set the ESBC to recognize EVS-WB as transcodable, which is useful for scenarios such as supporting SRVCC handovers.

Before configuring the SBC to transcode EVS, you must enable it with the setup entitlements command. EVS codec feature support includes:

transrating
transcoding
pooled transcoding
RTCP generation
AMR-WB interoperability and payload-type mapping

Note:

See the Release Notes for any platform-based EVS transcoding limitations.

Bitrate support per bandwidth includes:

Narrowband (NB) — 5.9, 7.2, 8, 9.6, 13.2, 16.4, 24.4
Wideband (WB) — 5.9, 7.2, 8, 9.6, 13.2, 13.2 channel-aware, 16.4, 24.4, 32, 48, 64, 96, 128 (6.6 ~ 23.85 for AMR-WB IO)
Super-wideband (SWB) — 9.6, 13.2, 13.2 channel-aware, 16.4, 24.4, 32, 48, 64, 96, 128
Fullband (FB) — 16.4, 24.4, 32, 48, 64, 96, 128

EVS data is always octet-aligned in both Primary and AMR-WB interoperability mode.

Interoperation with AMR-WB

EVS' AMR-WB interoperable (IO) mode provides backwards compatibility with endpoints that support AMR-WB, but don't support EVS. Based on user configuration and SDP offers, AMR-WB IO mode allows the ESBC to deliver media between such endpoints without using trancoding resources.

EVS Supported Options

There are no required SDP Parameters for EVS. Some EVS parameters may have values that the ESBC's DSP does not support. Supported values must be verified before the ESBC makes transcoding decisions. if any of these parameter checks fail, the ESBC marks the codec as non-transcodable

Unless noted otherwise, see 3GPP TS 26.445 and related specifications for complete parameter documentation. Optional SDP parameters include:

ptime—The length of time in milliseconds represented by the media in a packet. See RFC 4566 for more details.
For both EVS Primary mode and EVS AMR-WB IO mode, the supported ptimes are 20, 40, and 60 ms.
maxptime—The maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. See RFC 4566 for more details.
For both EVS Primary mode and EVS AMR-WB IO mode, the supported maxptimes are 20, 40, and 60 ms.
evs-mode-switch—Specifies whether to support mode switching between Primary and EVS AMR-WB IO modes. The default of 0 specifies the use of primary mode.
hf-only—Specifies whether to limit the session to header-full format. The default of 0 allows both compact and header-full format in both directions.
dtx—Specifies whether or not to support discontinuous transmission. The default of 1 specifies that DTX is enabled.
dtx-recv—Sets a further condition on whether or not to support discontinuous transmission in conjunction with the dtx parameter. The default of 1 enables dtx, dependent on the dtx setting.
max-red—Specifies the maximum number of milliseconds allowed between the first transmission of a frame and a redundant transmission. See RFC 4867 for more details.
channels—Specifies the number of audio channels, with a default of 1. The ESBC supports only 1 channel for transcoding.
cmr—Specifies whether codec mode request (CMR) is supported for the session. The default of 0 enables all CMR values.

The following parameters apply only to EVS Primary mode:

br—Specifies, in kilobits per second, the range of source codec bit-rate for EVS Primary mode in the session for both send and receive directions.

Source codec bit-rates for the EVS codec

Source codec bit-rate (kbit/s)	Audio bandwidths supported	Source Controlled Operation Available
5.9 (SC-VBR)	NB, WB	Yes (Always On)
7.2	NB, WB	Yes
8.0	NB, WB	Yes
9.6	NB, WB, SWB	Yes
13.2	NB, WB, SWB	Yes
13.2 (channel aware)	WB, SWB	Yes
16.4	NB, WB, SWB, FB	Yes
24.4	NB, WB, SWB, FB	Yes
32	WB, SWB, FB	Yes
48	WB, SWB, FB	Yes
64	WB, SWB, FB	Yes
96	WB, SWB, FB	Yes
128	WB, SWB, FB	Yes

If the given br value conflicts with the given bw value, the ESBC DSP marks the codec as non-transcodable.

br-send—Specifies, in kilobits per second, the range of source codec bit-rate for EVS Primary mode in the session for the send direction.
If the given br-send value conflicts with the given bw value, the ESBC DSP marks the codec as non-transcodable.
br-recv—Specifies, in kilobits per second, the range of source codec bit-rate for EVS Primary mode in the session for the receive direction.
The ESBC's mbcd/xserv independently decode whatever bit rate is received, so it is not necessary for the DSP to include br-recv when checking if the codec is transcodable
bw—Specifies the audio bandwidth for EVS Primary mode to be used in the session for the send and the receive directions.
For transcoding, the ESBC DSP only supports nb, wb, and nb-wb.
bw-send—Specifies the bandwidth to be used in the session for the send direction.
For transcoding, the ESBC DSP only supports nb, wb, and nb-wb.
bw-recv—Specifies the bandwidth to be used in the session for the receive direction.
For transcoding, the ESBC DSP only supports nb, wb, and nb-wb.
ch-send—Specifies the number of audio channels for the send direction. The default is 1.
ch-recv—Specifies the number of audio channels for the receive direction. The default is 1.
ch-aw-recv—Enumerated setting for channel-aware mode. The default of 0 specifies that partial redundancy mode is not used for the receive direction at the start of the session.

The following parameters apply only to EVS AMR-WB IO mode. Optional parameters of AMR-WB not defined below may not be used in the EVS AMR-WB IO mode.

mode-set—Restricts the active codec mode set to a subset of all modes when the EVS codec operates in AMR-WB IO.

Source codec bit-rates for the AMR-WB Interoperable Modes of the EVS codec

Mode Indicator	Source codec bit-rate (kbit/s)
0	6.6
1	8.85
2	12.65
3	14.25
4	15.85
5	18.25
6	19.85
7	23.05
8	23.85

Note:

The ESBC supports only mode-sets 0-7 for both AMR and AMR-WB.

mode-change-period—Specifies a number of frame-blocks, N (1 or 2). This is the frame-block period at which codec mode changes are allowed for the sender. See RFC 4867 for more details.
mode-change-capability—Specifies if the client is capable of transmitting with a restricted mode change period. See RFC 4867. The default, and only allowed value is 2 in EVS AMR-WB IO.
mode-change-neighbor—Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. See RFC 4867 for more details.

Default EVS Media Profile

By default, the ESBC uses the following parameters for EVS, referenced in the configuration as EVS.

media-profile
        name                                    EVS
        subname                                 
        media-type                              audio
        payload-type                            
        transport                               RTP/AVP
        clock-rate                              16000
        req-bandwidth                           0
        frames-per-packet                       0
        parameters                              
        average-rate-limit                      6000
        peak-rate-limit                         0
        max-burst-size                          0
        sdp-rate-limit-headroom                 0
        sdp-bandwidth                           disabled
        police-rate                             0
        standard-pkt-rate                       0
        as-bandwidth                            0

CLI Commands

CLI command changes made to support EVS include:

The show sipd codecs command includes EVS Count.
The show sipd transcode command includes EVS.
The show xcode codecs command includes EVS-AMR-WB sessions.

SNMP

This section presents SNMP OID detail the ESBC uses to support EVS.

ap-codec.mib

Object Name/OID	Description
apCodecRealmCountEVS 1.3.6.1.4.1.9148.3.7.1.1.1.33	The count of SDP media streams received in the realm that negotiated to the EVS codec.

The EVS realm statistic apCodecRealmCountEVS is available in the apCodecRealmStatsEntry.

ap-smgmt.mib

Object Name/OID	Description
apSysXCodeEVSCapacity 1.3.6.1.4.1.9148.3.2.1.1.49	The percentage of licensed EVS transcoding utilization (non pollable).
apSysMgmtXCodeEVSUtilGroup 1.3.6.1.4.1.9148.3.2.4.2.35	Object to monitor licensed EVS transcoding utilization.

New Traps—The new SNMP OID apSysXCodeEVSCapacity is added to transcoding utilization statistics, as reported in the apSysMgmtGroupTrap. When utilization falls below 80%, the system sends the apSysMgmtGroupClearTrap.

Trap Name (and Clear Trap Name)	Description
apSysMgmtCPULoadAvgTrap (apSysMgmtCPULoadAvgClearTrap)	The system generates the trap when the CPU Load Average Alarm exceeds its minor alarm threshold. The system sends the clear trap when the CPU load average recedes to the minor alarm level.

Capability MIB IODs

Object Name/OID	MIB file
apSmgmtXCodeEVSUtilCap 1.3.6.1.4.1.9148.2.1.8.59	ap-smgmt.mib
apCodecRealmCodecCap9 1.3.6.1.4.1.9148.2.1.13.11	ap-codec.mib

Alarms

The Licensed EVS Transcoding Capacity Threshold Alarm is a warning triggered when the EVS transcoding utilization exceeds 95% of licensed capacity. This alarm does not affect the system's health score. The system clears this alarm when the EVS transcoding utilization falls below 80% of licensed capacity.

RADIUS

The Acme-FlowType_FS{1,2}_{F,R} AVPs reflect the use of the EVS codec.

EVS Configuration Detail

This section discusses aspects of ESBC configuration that you must consider in addition to typical transcoding configuration for EVS.

Payload Type Mapping

The user enables EVS AMR-WB IO payload type mapping using the media-manager-config option audio-payload-type-mapping=yes. If the option is not present, EVS AMR-WB IO payload type mapping is disabled.

media-manager
 …
 options
audio-payload-type-mapping=yes

Furthermore, the payload-type is not critical as long as the audio-payload-type-mapping=yes option is configured. Normally the PTI used in the network is configured in the payload-type field. But the ESBC matches against codec name/string instead of payload-type.

Adding Codecs on Egress

When there is a codec update or re-negotiation from the original codec list, the user must ensure that use of the new codecs being offered is supported by the configuration of the add-codecs-on-egress field.

codec-policy
 name CoreFacingCodecs
 allow-codecs *
add-codecs-on-egress AMR-WB::NMS:(AMR-WB::NMS)
AMR::NMS:(AMR::NMS) AMR- WB::MSC:(!AMR::MSC)
AMR::MSC:(!AMR-WB::MSC)
order-codecs AMR-WB::NMS:(AMR-WB::NMS)
AMR::NMS:(AMR::NMS) * AMR-WB::MSC AMR::MSC

In the above example, AMR::MSC and AMR-WB::MSC are media-profiles defined for AMR and AMR-WB respectively, with the specifics of the new codecs being offered for the media update or re-negotiation.

EVS Call Flow Example

The flow depicted below provides an example that uses the audio-payload-type-mapping=yes to enable payload type mapping. In addition, the flow uses add-codecs-on-egress configuration in the egress codec policy configured as EVS::PT98. The offer contains EVS in AMR-WB IO mode and the SBC adds EVS AMR-WB IO with a different payload type. The answer uses the added EVS. The offer and answer are both octet-aligned and they have intersecting mode-sets, so transcoding is not required and payload type mapping is used.

AMR-WB to EVS AMR-WB IO Transparent Call Example

This example explains how you can configure the ESBC and applicable resources to support calls between EVS and AMR-WB endpoints without requiring transcoding, and therefore not consuming ESBC transcoding resources. This use case, established by logic within the ESBC, can accommodate calls in either direction.

In this call flow a codec policy is set on the egress realm to not allow AMR-WB and to add EVS AMR-WB IO on egress. The offer contains AMR-WB. The ESBC recognizes that the incoming AMR-WB codec matches the EVS codec to be added:

They have the same octet-align
EVS codec is in interoperable mode (evs-mode-switch=1)
You have a media-profile configured that matches the parameters presented in the AMR-WB offer

The ESBC strips AMR-WB and adds EVS with the same payload type as AMR-WB even though EVS is not configured with that payload type.

codec-policy
name Transparent-AMR-WB-IO
allow-codecs * AMR-WB:no
add-codecs-on-egress EVS::WBIO
force-ptime disabled

The call proceeds transparently between AMR-WB and EVS.

The AMR-WB EVS diagram is described above.

EVS and SRVCC

The ESBC includes support and requirements that you must consider when handling call flows that include the EVS codec and Single Radio Voice Call Continuity (SRVCC) handovers. This support includes basic functionality as well as transcoding considerations when EVS is in super-wideband mode.

Media Management

Enable mm-in-realm in the core realm to support transcoding EVS within environments that include SRVCC. Oracle also recommends that you enable codec-manip-in-realm for these deployments.

Transcoding Free Operation

You can configure the ESBC to handle scenarios that cannot use transcoding, but still support super-wideband end stations. Examples of such scenarios include SRVCC handovers wherein super-wideband is established before the handover. The srvcc-trfo parameter in the realm-config allows you to establish this functionality on a per-realm basis for the EVS codec. This behavior is compliant with TS24-237 (proxy mode) for EVS calls.

For example, assume a call established from the IMS core towards a VoLTE leg is using EVS-SWB and the codec needs to change because of an SRVCC event. With this configuration in place, the ESBC forces codec renegotiation with the far end in the event of a SRVCC handover from a packet to a circuit switching environment. The codec change on the VoLTE leg needs to match what the Mobile Switching Center (MSC) server offers to establish transcoder free operation. Assume the MSC offers AMR-WB to follow the process.

The ESBC recognizes AMR-WB being presented to the VoLTE UE and refrains from sending the 200 OK as an answer to the INVITE (proxy mode).
Instead, the ESBC sends it own INVITE towards the SRVCC UE, replacing EVS SWB in the SDP to force a renegotiation. Instead of EVS SWB, this INVITE contains the SDP from the SRVCC UE (AMR-WB).
The IMS core receives the ESBC INVITE and propagates it towards the SRVCC UE.
Ultimately the SRVCC UE accepts AMR-WB as codec and replies towards the ESBC with a 200 OK.
The IMS core sends this 200 OK to the ESBC (ATU-STI).
The ESBC replies with its own 200 OK to the MSC (STN-SR).
RTP restarts using AMR-WB between the VoLTE UE and the SRVCC UE.

This codec renegotiation happens end-to-end with the ATGW in the media path.

Navigate to the core realm-config and configure this parameter using the syntax below.

ORACLE(realm-config)# srvcc-trfo evs

This 'manual' trigger by the ESBC to force SDP re-negotiation prevents the call from requiring transcoding to EVS-SWB after the handover to the circuit switching environment.

Circumventing EVS SWB Transcoding Scenarios

You can configure ESBC to maintain a call that may otherwise fail when an SRVCC event puts the ESBC in the position of having to transcode from EVS SWB. When configured, the ESBC can recognize the requirement to transcode EVS SWB, and present EVS WB to the SRVCC UE. The ESBC supports transcoding EVS WB so there is no need to drop the call. This configuration also allows the ESBC to continue to use EVS SWB for the opposing UE.

You can configure the ESBC to support these scenarions using the realm-config option, srvcc-evs-swb-to-wb.

For example, assume a call has been established with EVS SWB when an SRVCC handover occurs. EVS SWB is not available within an MSC/3G network. By default, the call would fail. But when configured with the srvcc-evs-swb-to-wb option, the ESBC internally changes the presented codec from EVS SWB to EVS WB on ingress, while continuing to present EVS SWB back to the egress. This allows the ESBC to present this transcodable codec and support the SRVCC handover, while continuing to use EVS SWB on the other side.

Configure this option using the syntax below.

ORACLE(realm-config)# options +srvcc-evs-swb-to-wb

If you type options and then the option value without the plus sign, you overwrite any previously configured options. To add a new option to an options list, pre-pend the new option with a plus sign as shown in the previous example.

In addition, this function requires that you have an EVS media profile name as an allowed codec on both sides of the call. The default EVS profile can serve this purpose.