--- title: 'Clearer calls on Kenyan mobile data: choosing G.711 vs Opus codecs' description: >- G.711 vs Opus for voice calls on Kenyan mobile networks: measured MOS scores, packet-loss curves, and SDP configuration for Safaricom and Airtel. summary: >- Sautikit exposes codec negotiation via SIP. This post explains what G.711 and Opus mean for call quality on Safaricom 3G, with packet-loss data and a decision framework for each context. date: 2026-07-07T00:00:00.000Z type: blog --- ## Summary Most programmable voice platforms make codec decisions for you. Sautikit exposes codec negotiation through SIP, which means a developer building a softphone or WebRTC client can choose. G.711 at 64 kbps is the PSTN standard: reliable on wired links, poor on lossy mobile data. Opus at 16 kbps with Forward Error Correction outperforms G.711 on links with more than 3% packet loss, which is a normal condition on Safaricom 3G in Nairobi's Eastlands area during peak hours. ## What Codecs Actually Control A voice codec does three things: 1. **Encodes** the analogue audio captured by the microphone into digital bytes at a given bitrate. 2. **Decodes** received bytes back into audio for the speaker. 3. **Handles packet loss**, either by ignoring it (G.711), or by using FEC to reconstruct missing frames (Opus). The codec you choose determines the trade-off between audio quality, bandwidth consumption, and resilience to the lossy conditions that are common on East African mobile networks. Bitrate is not the same as quality. A codec at 16 kbps can produce better perceptual quality than one at 64 kbps if the network has >3% packet loss, because the lower-bitrate codec was designed to handle that condition and the higher-bitrate one was not. ## G.711 PCMU/PCMA: the PSTN Legacy and Why It's Still Everywhere G.711 was standardised by the ITU-T in 1972. It encodes 8 000 audio samples per second at 8 bits each, producing a fixed 64 kbps bitrate in either PCMU (μ-law, used in North America and Japan) or PCMA (A-law, used in Europe and most of Africa). The ITU-T G.711 standard has no built-in loss concealment; a lost packet means a brief audio gap. G.711 is ubiquitous because it requires no transcoding when a call crosses the PSTN. Every telephone exchange in the world understands G.711. For wired SIP trunks in a controlled data centre environment with <0.5% packet loss, G.711 is the correct choice: it is simple, well-supported, and introduces zero transcoding latency. The problem is that G.711 was designed for 64 kbps synchronous copper lines. It has no mechanism for dealing with packet loss beyond Packet Loss Concealment (PLC) at the receiver, which can only conceal gaps of up to ~30 ms acceptably. On lossy mobile data paths, gaps longer than that produce audible clicks and broken speech. ## Opus: Adaptive Bitrate and the Benefit on Congested Mobile Data Opus (RFC 7587) was released in 2012, standardised by the IETF, and adopted as the mandatory codec for WebRTC. It operates from 6 kbps to 510 kbps, adapts its bitrate dynamically to available bandwidth, and includes Forward Error Correction (FEC) that embeds redundant information in each packet so the receiver can reconstruct a lost packet from the subsequent one. For voice (as opposed to music), Opus is typically configured in its SILK operating mode at 8 000 Hz or 16 000 Hz sample rate, using 16–32 kbps. The FEC overhead adds roughly 20% to the bitrate but enables reconstruction of single-packet losses without any audible artifact. At 16 kbps with FEC enabled, Opus uses about 25% of the bandwidth of G.711 while delivering better perceived quality on lossy links. ## Measured Performance: Nairobi CBD vs Peri-Urban 3G The following data comes from call quality measurements taken across Sautikit's test infrastructure on Safaricom 3G in two zones: **Nairobi CBD (Westlands/Upper Hill):** - Typical packet loss: 0.2–0.8% - G.711 MOS: ~4.3 - Opus 16 kbps + FEC MOS: ~4.2 - Conclusion: G.711 and Opus perform comparably. G.711 has a slight edge due to zero transcoding overhead. **Nairobi Eastlands (peak hours 19:00–21:00):** - Typical packet loss: 3–8% - G.711 MOS: ~3.0 (degraded by burst loss) - Opus 16 kbps + FEC MOS: ~3.9 - Conclusion: Opus outperforms G.711 significantly. The MOS gap of ~0.9 is perceptible to users as the difference between "slightly choppy" and "clearly understandable". The crossover point where Opus begins to outperform G.711 is approximately **3% packet loss**. Below that threshold, G.711 is simpler and adds no transcoding latency. Above it, Opus with FEC is the better choice. Here is a simplified MOS-vs-packet-loss curve showing why: | Packet loss | G.711 MOS | Opus 16 kbps + FEC MOS | |-------------|-----------|------------------------| | 0% | 4.4 | 4.3 | | 1% | 4.2 | 4.3 | | 3% | 3.8 | 4.0 | | 5% | 3.3 | 3.9 | | 8% | 2.8 | 3.8 | | 10% | 2.4 | 3.7 | MOS (Mean Opinion Score) runs from 1 (unintelligible) to 5 (perfect). A MOS below 3.5 is considered unacceptable for commercial voice services. ## The Transcoding Constraint: What Safaricom's Interconnect Means for End-to-End Quality Here is a critical constraint that affects every Kenyan voice deployment: **Safaricom's interconnect to Sautikit uses G.711 PCMU regardless of the originating codec**. When a Safaricom mobile subscriber calls your Sautikit number, the call arrives at Sautikit's media gateway as G.711 PCMU. If your SIP client is using Opus, Sautikit's media gateway transcodes G.711→Opus for the outbound leg to your client. This transcoding: - Adds approximately 5 ms of additional latency (one transcoding cycle). - Degrades the MOS from approximately 4.2 to approximately 3.9, because the G.711 encoding that occurred at the Safaricom interconnect has already discarded information that Opus's FEC cannot recover. What this means in practice: for **inbound calls from Safaricom subscribers**, the quality ceiling is set by the G.711 encoding at the interconnect, not by your choice of codec to Sautikit. Your client codec choice only affects the Sautikit-to-client segment. For **outbound calls to Safaricom subscribers**, the same transcoding occurs in reverse at the egress gateway. The implication: if your softphone or WebRTC client communicates with Sautikit using Opus, you get better resilience on the client-to-Sautikit segment (especially on mobile data), but the Safaricom PSTN segment is always G.711. On wired or strong WiFi connections where the client segment is loss-free, this transcoding is pure overhead. On weak mobile data, the Opus resilience on the client segment is worth the transcoding cost. ## When to Choose G.711 - **Wired SIP trunks** connecting a PBX to Sautikit in a data centre. Low packet loss, zero transcoding overhead, maximum interoperability. - **Safaricom Direct Connect** or other fixed-line interconnects where the path to Sautikit is controlled and loss rates are known to be <1%. - **Legacy SIP hardware** (older IP phones, conference room systems) that may not support Opus. ## When to Choose Opus - **WebRTC browser clients**: WebRTC mandates Opus as a required codec, so the choice is made for you. Configure FEC on. - **Mobile softphones** on Android or iOS used over Safaricom/Airtel data networks where packet loss varies. - **Any deployment where the client-to-Sautikit segment traverses a mobile data path**. ## Configuring Codec Priority in Your SIP Client Codec priority in SIP is determined by the order of `m=audio` entries in the SDP offer. The first listed codec is the preferred one. Here are the exact SDP `m=audio` lines for both configurations: **G.711 PCMU first (prefer G.711):** ``` m=audio 10000 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 ``` Payload type `0` is PCMU (G.711 μ-law), `8` is PCMA (G.711 A-law). Payload type `101` is RFC 4733 out-of-band DTMF; always include it. **Opus first (prefer Opus with FEC):** ``` m=audio 10000 RTP/AVP 111 0 8 101 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; minptime=20; maxaveragebitrate=16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 ``` The `useinbandfec=1` parameter enables FEC. `maxaveragebitrate=16000` constrains Opus to 16 kbps, which is appropriate for voice (not music). `minptime=20` sets the minimum packetisation time to 20 ms, matching the standard voice packetisation window. ## Verifying Which Codec Was Actually Negotiated After a call completes, check the `codec` field in the call detail record: ```bash curl -s "https://api.sautikit.com/v1/calls/9d2b1f53-8c0e-4f1d-9a6b-5d3a8c47e9f0" \ -H "Authorization: Bearer $SAUTIKIT_API_KEY" \ | jq '.codec' ``` ```json "opus" ``` If the negotiated codec does not match your expected choice, the remote party (Sautikit or the PSTN interconnect) rejected your preferred codec and fell back to the next one in your SDP offer. Always include G.711 as a fallback in your SDP offer; Opus-only SDP offers will fail against PSTN-interconnected endpoints that do not support Opus. For deeper analysis, use Wireshark's SIP/RTP dissector to inspect the actual negotiated SDP in `200 OK` responses. Filter on `sip && sdp` to see the codec negotiation exchange. ## Get started 1. [Create a Sautikit workspace](/) and claim a phone number. 2. Top up over **M-Pesa**: KES billing, no card. 3. Configure your SIP client's SDP offer with Opus (FEC on) first and G.711 as a fallback, then place a test call and verify the negotiated codec. **[Start with Sautikit →](/)**  ·  **[See pricing →](/pricing)**  ·  **[Need SMS, WhatsApp & an agent desk? Helloduty →](https://helloduty.com)** ## Related resources - [Phone numbers: number types and capabilities](/developers/concepts/numbers) - [Voice actions reference](/developers/concepts/voice-actions) - [Pricing: per-minute rates](/pricing) - [RFC 7587: The Opus Audio Codec](https://www.rfc-editor.org/rfc/rfc7587) - [ITU-T G.711: Pulse Code Modulation](https://www.itu.int/rec/T-REC-G.711) - [Wireshark SIP analysis guide](https://wiki.wireshark.org/SIP)