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.
Encodes the analogue audio captured by the microphone into digital bytes at a given bitrate.
Decodes received bytes back into audio for the speaker.
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 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 (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.
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.
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.
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:
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.
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.