Two Codec Families, One Codec
EVS (Enhanced Voice Services, 3GPP TS 26.445) is not a single codec but a codec with two families of operating modes:
EVS Primary
The “real” EVS coding modes: bitrates from 5.9 up to 128 kbit/s, audio bandwidths from narrowband to fullband, channel-aware mode, and significantly better coding efficiency than anything before it. Super-wideband at 13.2 kbit/s is the headline feature – better-than-AMR-WB quality at a lower bitrate.
EVS AMR-WB IO
Nine operating points (6.6 to 23.85 kbit/s) whose encoded bitstream is bit-identical to AMR-WB. An EVS encoder in IO mode produces frames any AMR-WB decoder can decode; an EVS decoder in IO mode consumes frames from any AMR-WB encoder. No transcoding, no signal-path degradation.
At first glance, IO mode sounds redundant. If the bitstream is identical to AMR-WB, and AMR-WB is mandatory anyway in both IR.92 (VoLTE) and NG.114 (VoNR), why would you ever negotiate EVS-IO instead of just AMR-WB?
The bitstream is only half the story
The other half is the decoder implementation, the RTP session model, and what happens to a call over its lifetime. That is where EVS-IO quietly earns its keep – three concrete advantages, none of which cost you a single bit of interoperability.
Advantage 1: A Better Decoder for the Same Bitstream
The AMR-WB standard defines what the encoder must produce; the decoder side leaves room for implementation quality. The EVS specification took that room and used it. When an EVS decoder operates in AMR-WB IO mode, it applies the improved algorithms from the EVS toolbox to the legacy bitstream:
Improved packet loss concealment
EVS ships with substantially more sophisticated error concealment than the reference AMR-WB decoder. Under packet loss – on the radio leg a question of when, not if – the same lost frames are masked noticeably better. Formal listening tests during EVS standardization showed consistent gains for the IO decoder at identical loss rates.
Improved post-processing
The IO decoder applies EVS-grade post-filtering and background noise handling without touching the bitstream. Cleaner output, same input.
EVS jitter buffer management
Endpoints implementing EVS bring along the EVS JBM design (TS 26.448), which adapts more aggressively and reconstructs timing more gracefully than many legacy AMR-WB implementations.
The practical consequence: two phones exchanging exactly the same encoded frames will sound different depending on which decoder is at the receiving end. On a clean link the difference is negligible. On a lossy radio link, EVS-IO audibly wins. You are getting a free quality upgrade on the decode side while remaining fully interoperable with the installed AMR-WB base.
Advantage 2: In-Band Mode Switching Without Re-INVITEs
This is the architecturally interesting one. EVS Primary and EVS-IO share a single RTP payload type. Switching between Primary and IO modes is an in-band operation – signalled via CMR (Codec Mode Request) inside the media path – and requires no SDP renegotiation whatsoever.
Think about what that means for real call scenarios. A call starts between two EVS-capable endpoints in Primary mode at 13.2 kbit/s super-wideband. Mid-call, the far end is transferred to a party that only supports AMR-WB – a conference bridge, a legacy VoLTE subscriber, a fixed-line gateway. With plain AMR-WB in the SDP, the network now either transcodes (adding latency and tandem coding loss) or fires a re-INVITE at the UE to change codecs (adding signalling load, media clipping risk, and a hard dependency on every element in the path handling mid-call renegotiation correctly).
With EVS negotiated, the session simply drops into IO mode. Same payload type, same RTP session, no SIP signalling. The endpoint keeps encoding, now in an AMR-WB-compatible format, and the network passes the stream through to the legacy leg. When the legacy party drops off again, the session switches back up to Primary.
A signalling-plane project becomes a media-plane detail
For operators, this collapses a whole class of mid-call interworking problems – call transfer, conferencing, break-out to interconnect partners – into an in-band media operation instead of a fragile chain of mid-call re-INVITEs.
Advantage 3: Transcoding-Free Interworking
Because IO frames are bit-identical to AMR-WB, a network element bridging an EVS-IO leg and an AMR-WB leg does not need to transcode at all. No decode, no re-encode, no DSP cycles, no added algorithmic delay, no tandem quality loss. The media function only needs to re-map the payload framing.
That last part deserves honesty, because it is the one caveat that trips people up in the lab:
EVS-IO is not wire-compatible with classic AMR-WB at the RTP layer
EVS – in Primary and IO mode – uses the EVS RTP payload format defined in TS 26.445 Annex A, which is always octet-aligned and structured differently from the AMR-WB payload format of RFC 4867 (which additionally comes in bandwidth-efficient and octet-aligned flavours). The codec bitstream is identical; the payload framing is not. Something in the path has to re-frame between the two formats.
The good news: re-framing is a trivial, per-packet header operation. Compared to transcoding it is essentially free – no codec licence exposure on the media path, no DSP capacity planning, no quality penalty. But it is not zero work, and your SBC or media gateway needs to support it explicitly. When evaluating equipment, “supports EVS-IO” should specifically mean “can re-frame EVS-IO ↔ AMR-WB without invoking a transcoder.”
Getting the SDP Right
EVS-IO only helps you if it is actually negotiated, and the negotiation has a few sharp edges worth knowing:
Pin the mode
Answering an EVS offer with a bare a=rtpmap line permits the far end to send Primary frames. If your media path can only handle IO, constrain the session with evs-mode-switch=1 in the fmtp, which locks it to AMR-WB IO operation from the start.
Constrain the rates
The mode-set parameter (values 0–8, mirroring the AMR-WB rate set) lets you exclude the lowest IO rates. If your interworking target is a wideband codec on the far leg, there is little reason to allow 6.6 kbit/s.
Prefer header-full format
Setting hf-only=1 forces the header-full payload format and avoids the size-based ambiguities of the compact format, where CMR handling in IO mode has caused real-world interop issues between implementations. Header-full is also the friendlier format to re-frame.
Keep AMR-WB in the offer anyway
EVS-IO does not replace AMR-WB in your codec list – it sits above it. Devices with EVS disabled by provisioning, and the entire pre-EVS installed base, still need the classic fallback. A sensible preference order remains EVS, then AMR-WB, then AMR.
Put together, an IO-constrained offer with a clean AMR-WB fallback looks like this – EVS locked to IO mode, header-full payload only, and a rate set that mirrors the AMR-WB fallback so the two legs stay symmetric for re-framing:
m=audio 49152 RTP/AVP 96 97
a=rtpmap:96 EVS/16000
a=fmtp:96 evs-mode-switch=1; hf-only=1; mode-set=0,1,2
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; mode-change-capability=2
a=ptime:20Where EVS-IO Does Not Help
To keep expectations calibrated: if SDP negotiation lands on the plain AMR-WB payload type, everything above is moot – IO mode only exists inside a negotiated EVS session. And EVS-IO does not improve the encoded quality: the uplink speech leaving an IO encoder is AMR-WB-class audio, full stop. The encoding-side quality jump – super-wideband, channel-aware mode, better efficiency – belongs exclusively to EVS Primary.
EVS-IO is therefore not the destination. It is the bridge: a way to deploy EVS endpoints today, harvest the decoder and session-model benefits immediately, interwork losslessly with the enormous AMR-WB installed base, and keep the door open for full Primary-mode EVS end-to-end as the rest of the ecosystem catches up.
How volte.io Puts EVS-IO to Work
Codec strategy is one of those areas where the standards give you the tools and the deployment decides whether they help. Our platform is built so that EVS-IO is a benefit you switch on, not a project you staff:
Codec policy per leg
Offer EVS toward capable devices, constrain to IO where the far leg demands it, and keep the AMR-WB and AMR fallbacks in exactly the right preference order – per interconnect, per application, without touching the endpoints.
Re-frame, don’t transcode
Where an EVS-IO leg meets a classic AMR-WB leg, our media path re-frames the payload instead of invoking a transcoder. No added delay, no tandem loss, no DSP capacity planning – the speech bits pass through untouched.
Proven on real devices
CMR handling, payload formats, and mode switching are exactly the kind of interop surface where implementations disagree. We verify codec negotiation and interworking continuously, with automated end-to-end tests on the handsets your subscribers actually carry.
Same bits on the wire. Better everything around them.
AMR-WB earned its place as the workhorse of HD Voice, and it is not going anywhere soon. But when an endpoint offers EVS, taking the IO path buys you a measurably more robust decoder on lossy links, mid-call mode agility without SIP renegotiation, and transcoding-free interworking with every AMR-WB device out there – at the cost of nothing more than a payload re-framing step and some SDP discipline. That is a rare kind of upgrade in telecoms, and it is worth negotiating for.