Infinite RTP codec switching (G722 <> PCMA) on PJSIP trunk – best practice?

[Julius_M]

Hi,

I’m seeing an infinite RTP codec switching loop on an outbound PJSIP trunk and would like some advice on the recommended way to handle this.

SDP negotiation

INVITE from Asterisk:

m=audio RTP/AVP 9 0 8
(G722, PCMU, PCMA)

200 OK from provider:

m=audio RTP/AVP 8 0 9
(PCMA, PCMU, G722)

Problem

After call setup, RTP payload types alternate between 9 (G722) and 8 (PCMA).
Asterisk switches its transmit codec to match incoming RTP, resulting in a continuous G722 ↔ PCMA ping-pong.

This matches the behavior described here:

Infinite codec switching

Following the severe audio quality issues I described at Choppy audio with DSP warnings, we have finally been able to run RTP debug logging during an affected call, and identified the issue. The issue is that both Asterisk and our provider’s media server appear to switch codecs when they receive a packet using a different codec from the other side. Because this is happening on both ends, some calls get into an infinite loop of switching codecs. Example call - INVITE SDP (from us): v=0 o=- 101…

Enabling:

asymmetric_rtp_codec=yes

(on both global and endpoint) stops the loop, but the linked thread mentions this is “usually not a great idea”.

Questions

1. What is the recommended / clean solution here?
2. What side effects does enabling asymmetric_rtp_codec=yes have?
3. Is there a supported way to keep G722 as preferred (HD audio) without risking this RTP loop?

Thanks for any guidance.