From fe982a3b5f9ec962b7b2de45efd80ded45854c79 Mon Sep 17 00:00:00 2001 From: shaunjstokes Date: Mon, 14 Oct 2024 13:18:57 +0200 Subject: [PATCH 1/2] [core/media] allow transcoding between different rates in Opus MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In vars.xml , when you use codec settings like this: `` The switch_core_media.c line 5520 only takes the OPUS default rate (48k) instead of 16k in the config. Because of this, FS won't be able to choose opus if your client asks for 16k opus. You will see same log symptom as #2226 We've found that the patch #2582 has the side effect of causing calls that fail to negotiate the same codec as Leg A for Leg B to fail with SIP 488 INCOMPATIBLE_DESTINATION. That's not an option for us, we need backwards compatibility with other codecs. Rather than apply this for all codecs it should only apply for Opus. Now calls using Opus and other codecs establish correctly on both legs, and there are no issues with codec negotiation when the codecs on Leg A and Leg B don't match. Tested-by: Jérôme Poulin Co-authored-by: magiclin99 --- src/switch_core_media.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/switch_core_media.c b/src/switch_core_media.c index de5d0eff74c..8b533fa50eb 100644 --- a/src/switch_core_media.c +++ b/src/switch_core_media.c @@ -5517,6 +5517,10 @@ SWITCH_DECLARE(uint8_t) switch_core_media_negotiate_sdp(switch_core_session_t *s uint32_t bit_rate = imp->bits_per_second; uint32_t codec_rate = imp->samples_per_second; + if (!strcasecmp(map->rm_encoding, "opus")) { + codec_rate = imp->actual_samples_per_second; + } + if (imp->codec_type != SWITCH_CODEC_TYPE_AUDIO) { continue; } From 8cd887630477937e30b6977027c6f96dca89faa8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poulin?= Date: Tue, 1 Jul 2025 15:08:25 -0400 Subject: [PATCH 2/2] [mod_opus] configure timestamp increments to be fixed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Allow transcoding between different rate without messing up the RTP timestamps after transcoding kicks-in. @celliso1: It appears this PR (#2623) has revealed a bug in the opus encoder affecting the timestamp increment. The RFC 7587 states opus always increments at 48kHz regardless of the payload sample rate, but mod_opus.c is using 16 kHz or 8kHz samples per packet. Co-authored-by: celliso1 Tested-by: Jérôme Poulin --- src/mod/codecs/mod_opus/mod_opus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mod/codecs/mod_opus/mod_opus.c b/src/mod/codecs/mod_opus/mod_opus.c index 96933e6ea59..39976aa8d65 100644 --- a/src/mod/codecs/mod_opus/mod_opus.c +++ b/src/mod/codecs/mod_opus/mod_opus.c @@ -1487,7 +1487,7 @@ SWITCH_MODULE_LOAD_FUNCTION(mod_opus_load) } /* 16 khz */ - samples = 160; + samples = 480; bytes = 320; mss = 10000; rate = 16000; @@ -1584,7 +1584,7 @@ SWITCH_MODULE_LOAD_FUNCTION(mod_opus_load) } /* 8 khz */ - samples = 80; + samples = 480; bytes = 160; mss = 10000; rate = 8000;