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

Asterisk Asterisk SIP
1

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:

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.

2

Hi everyone,

following up on this thread, since I haven’t received any response so far. Is there any additional information needed to troubleshoot this properly, or is there a better sub-forum/place to ask?

To help, I can provide:

  • Asterisk version + chan_pjsip settings (endpoint + global)
  • Full SDP offer/answer (INVITE/200 OK) showing codec order
  • rtp debug output demonstrating the PT 9 (G722) ↔ PT 8 (PCMA) alternation
  • Confirmation that enabling asymmetric_rtp_codec=yes stops the loop

Main question remains: what’s the recommended clean fix (and what are the side effects of asymmetric_rtp_codec=yes)?

Thanks!