VoIP Mailing List Archives

[ak at hejdu.dk]

Hello,

We are getting these weird log messages from FS and I'm a little uncertain what they are (there are thousands being logged), can someone clarify?

September 23rd 2021, 10:35:40.849 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.844181 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0).September 23rd 2021, 10:35:40.749 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.744202 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type .September 23rd 2021, 10:35:40.669 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.664168 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0).September 23rd 2021, 10:35:40.569 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.564190 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type .September 23rd 2021, 10:35:40.489 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.484194 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0).September 23rd 2021, 10:35:40.389 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.384180 [WARNING] switch_core_media.c:3305 Changing current codec to PCMA (payload type .September 23rd 2021, 10:35:40.309 ms-euc1-1a 28423364-1c49-11ec-b0ec-e3438dde9495 2021-09-23 08:35:40.304190 [WARNING] switch_core_media.c:3305 Changing current codec to PCMU (payload type 0).
I'm thinking it's because we are receiving RTP packets with both types from remote?


It only happens for a specific provider, so I'm thinking it's them, I just need to tell them the problem is.
During codec negotiations we offered PCMA + PCMU and the SDP response from them also had PCMA + PCMU, that means we can choose what we want right? not that they should send us both?



Thank you...

   Allan

[s.safarov at gmail.com]

Look like on the other side used Asterisk.
In such a case, I offer only one codec and from another side, I receive a response with only one code.

Sergey


On Sun, Sep 26, 2021 at 11:40 PM Allan Kristensen <ak@hejdu.dk (ak@hejdu.dk)> wrote:

[christian.berger at fo...]

Hi Allan,

this is a very simple logical bug which exists in Asterisk (and
apparently in FreeSwitch).
If you allow for multiple codecs, Asterisk will just start with one, but
once it gets a frame from the other side with a different codec, it will
switch to that codec. If both sides do that, they start with different
codecs and the latency is high enough, they'll get semi-stuck in a codec
switching loop until one frame gets lost.

The proper bugfix would be to keep the codec choice "sticky" and not to
change the codec on every packet. (e.g. wait for n packets with a new
codec before you change to that codec) One side doing that should solve
the problem.

The workaround, as mentioned before, is to limit the codecs you speak,
but that will likely give you other slight problems regarding voice quality.

Bye
Christian Berger


Am 26.09.21 um 22:23 schrieb Allan Kristensen:

[ak at hejdu.dk]

Hello,

Thank you for your help. It's an interesting problem.

Since we are transcoding from OPUS, we could try to just offer them one codec, but I'm not sure if US calls will work.
There isn't any way to tell Freeswitch to keep the codec "sticky" for a short interval of time / packet count?



On Mon, Sep 27, 2021 at 10:06 AM Christian Berger <christian.berger@foncloud.net (christian.berger@foncloud.net)> wrote: