SBC AMR to G.711 Transcoding: How Modern Networks Bridge Mobile and IP Voice

Mobile networks and IP voice networks rarely speak the same audio codec. Mobile carriers default to Adaptive Multi-Rate (AMR), the codec engineered for cellular radio links. Enterprise IP-PBXs, SIP trunks, contact centers, and the wider PSTN run almost universally on G.711. When a call crosses that boundary, somewhere in the path a device has to convert the audio from one format to the other in real time. That device is almost always a Session Border Controller (SBC), and the conversion itself is called transcoding.
This article explains what SBC AMR to G.711 transcoding actually does, why it sits at the SBC layer rather than inside the PBX, the difference between hardware and software transcoding, and the deployment scenarios where it matters most. The aim is a clear, vendor-neutral picture of how mobile-to-IP voice interworking really happens at the network edge.

What AMR to G.711 Transcoding Actually Does

The job is straightforward to describe and surprisingly demanding to execute. On one side of the call the SBC receives RTP packets carrying AMR-encoded audio, sampled and compressed for a mobile radio link. On the other side it has to deliver RTP packets carrying G.711 audio, the format every IP-PBX, SIP trunk, and PSTN gateway expects. To bridge the two, the SBC decodes the AMR stream back to raw PCM samples, re-encodes those samples as G.711 (A-law or µ-law, depending on the destination), and forwards the result with new RTP timestamps and payload type. The same conversion runs in reverse on the return path.

AMR and G.711 Were Designed for Different Worlds

AMR exists because radio bandwidth is scarce and conditions change second to second. AMR-NB compresses 8 kHz speech down to as little as 4.75 kbps; AMR-WB pushes the sampling rate to 16 kHz for noticeably better quality but still compresses aggressively. G.711, by contrast, was designed in the 1970s for fixed-line telephony where bandwidth was cheap and latency had to be near zero. It applies a simple logarithmic compression to 8 kHz speech and produces a steady 64 kbps stream. The two codecs are not interchangeable, and no IP-PBX is going to suddenly start speaking AMR.

Where the Conversion Belongs

The PBX and the mobile core are both poor places to transcode. Asking a PBX to natively decode AMR forces every endpoint license to ship with a mobile codec stack, which most do not. Asking the mobile core to emit G.711 defeats the entire reason mobile uses AMR in the first place. Putting transcoding at the SBC keeps both sides clean: each network speaks its native codec all the way to the edge, and the conversion happens once, at the boundary, where the operator already controls signaling and media.

Why an SBC Is the Right Place to Transcode

Three properties of SBC architecture make it the natural transcoding point. The first is per-leg media control. Because an SBC terminates RTP on each side and bridges it with full B2BUA control, it can apply different codecs, packet sizes, and DTMF treatments on each leg independently. The second is SDP rewriting. The SBC sees both INVITEs and can rewrite the codec list each side advertises, telling the mobile network “I support AMR” while telling the PBX “I support G.711,” and bridging the actual media in the middle. The third is policy. Codec choice is rarely just a technical preference; it is shaped by carrier contracts, license counts, and quality targets. Pushing those policies into a per-NAP configuration on the SBC keeps them visible and auditable.

The SDP Handshake

When a mobile-originated call lands on the SBC, the inbound INVITE typically advertises AMR-WB as the preferred codec, with AMR-NB and possibly G.711 as fallbacks. The outbound INVITE the SBC sends to the IP-PBX usually offers only G.711, because that is what the PBX expects. The SBC accepts AMR on the inbound leg, accepts G.711 on the outbound leg, and transcodes between the two. As defined in RFC 4566, the SDP body is what makes this codec-mediation possible without either endpoint knowing the other exists.

Re-INVITE and Mid-Call Codec Changes

Mobile networks occasionally renegotiate codecs mid-call, for example when a handset moves between cells with different radio conditions. A B2BUA SBC absorbs the resulting re-INVITE on the mobile leg without disturbing the PBX leg, which keeps the call stable from the enterprise’s perspective.

Hardware vs Software Transcoding

Not every codec costs the same to transcode. G.711 is essentially a lookup table; converting between A-law and µ-law, or between G.711 and raw PCM, is cheap enough that any modern x86 server can do it in software for hundreds of concurrent calls. AMR is a different story. AMR-NB and AMR-WB use linear predictive coding with multiple adaptive bit rates, and the per-channel CPU cost makes pure-software transcoding impractical at carrier scale.

Why AMR Transcoding Needs DSPs Today

Hardware DSPs are purpose-built for the math AMR requires. A single 1U DSP appliance can deliver thousands of concurrent AMR-to-G.711 transcoding sessions at consistent latency, while the same workload on commodity CPU cores would consume an order of magnitude more silicon and produce less predictable jitter. For any deployment at meaningful scale, including mobile aggregation, VoLTE handoff, and managed enterprise voice with mobile breakout, hardware-accelerated transcoding is the practical default.

When Software Transcoding Is Enough

Software transcoding inside the SBC handles G.711 µ-law to A-law conversion natively, which covers the most common North-America-to-Europe interop case. It also handles RTP-to-SRTP conversion and packetization changes. The point at which a deployment crosses from “software is fine” to “you need a DSP” is the moment a complex codec like AMR enters the picture.

Sample-Rate Alignment

AMR-WB samples at 16 kHz, G.711 at 8 kHz. Transcoding has to downsample on the way out to G.711 and upsample on the return path. The downsample is straightforward; the upsample cannot recover detail that AMR-NB or G.711 never carried in the first place, which is why a wideband-to-narrowband leg sounds noticeably duller than the original mobile side. There is no SBC trick that fixes this; it is a property of the destination codec.

Common Deployment Scenarios

Mobile Carrier to IP-PBX or SIP Trunk

The classic case: a mobile operator hands a call off to an enterprise IP-PBX or to a SIP-trunk reseller. AMR-WB on the mobile leg, G.711 on the enterprise leg, transcoding at the SBC. This is the deployment most carriers and MSPs encounter first, and it scales linearly with concurrent mobile-originated traffic.

VoLTE Hand-Off into Legacy Voice

A VoLTE call placed on a 4G handset arrives as AMR-WB at the IMS edge, and from there it has to land somewhere on the wider PSTN. If the next hop is a TDM gateway or a legacy SIP trunk, the SBC sits between the IMS core and the gateway, transcoding AMR-WB to G.711 so the rest of the network never sees the wideband codec.

WebRTC and Teams Bridging

WebRTC endpoints use Opus, Microsoft Teams uses G.722, and mobile uses AMR. An SBC bridging UCaaS platforms to mobile carriers typically needs a transcoding plane that handles all three, with G.711 as the common middle codec for downstream PSTN delivery.

DTMF Alongside Voice

The same hardware that performs AMR-to-G.711 conversion also handles RFC 2833 DTMF to inband translation on the same media plane. Running both on a single transcoding plane simplifies sizing and licensing rather than spreading the work across multiple appliances.

Voice Quality Considerations

Every transcoding step costs something, both in latency and in perceived quality. The latency hit per leg is small, typically a few milliseconds when DSPs are doing the work, but it is additive across hops, and in a path with two transcoding points the cumulative delay starts to matter for echo and conversation pacing. Mean Opinion Score (MOS) also degrades each time speech is decoded and re-encoded, with the steepest drop on wideband-to-narrowband conversions where information is genuinely lost. Two practical guidelines hold: minimize the number of transcoding hops in any given path, and prefer the highest-quality codec the destination network can sustain. If the PBX leg supports G.711 at full 64 kbps, do not introduce G.729 just to save bandwidth on a leg that does not need it.

Frequently Asked Questions

Conclusion

AMR-to-G.711 transcoding is the unglamorous plumbing that keeps mobile and IP voice talking to each other. Mobile networks will continue to send AMR for as long as cellular radio remains bandwidth-constrained, and IP-PBXs will continue to demand G.711 for as long as the wider PSTN does. The SBC is the only place in the path with the per-leg media control, the SDP visibility, and the policy hooks to mediate that gap cleanly, and for production AMR workloads, hardware-accelerated transcoding is what actually delivers the throughput and consistency the use case requires. Sizing, codec policy, and quality targets are decisions the network architect owns; the SBC and its transcoding plane are how those decisions become real on the wire.