Forcing Opus codec over G.711 for bandwidth-constrained remote agents

Our remote agents are complaining about bandwidth issues on their home networks. The IT team wants to force the Opus codec over G.711 for all WebRTC connections to save bandwidth.

I ran an A/B test on our routing queues, and forcing Opus actually increased our average handle times by 12 seconds. Has anyone else experienced negative SLA impacts when shifting to highly compressed codecs?

As an AppFoundry partner, I must warn you against forcing Opus if you utilize any third-party IVR or payment integrations.

Our PCI-compliant payment application relies on in-band DTMF relay to capture credit card numbers. G.711 passes DTMF tones flawlessly because it is uncompressed (PCM). Opus compression destroys the frequency integrity of DTMF tones, causing our payment gateways to fail. If you force Opus, you must ensure RFC 2833 / RFC 4733 Out-of-Band DTMF is strictly enforced.

You can explicitly force the codec priority during the SIP SDP negotiation on your trunks.

If you inspect the SIP trace, the m=audio line dictates the codec preference. You need to ensure payload type 111 (Opus) is listed before 0 (PCMU/G.711).

# Example SIP SDP Trace
m=audio 16384 RTP/SAVP 111 0 8 101
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000

However, the AppFoundry partner is correct; you must ensure a=rtpmap:101 telephone-event is negotiated for out-of-band DTMF if you use Opus.